This decision concerns an European patent application relating to a method for compilation of price data concerning scheduled transport. Here are the practical takeaways from the decision T 1468/20 of the Technical Board of Appeal 3.5.01.
Key takeaways
The specification of transport data relates to business data content and is not technical.
In the claim, the filtering boils down to disregarding prices that were not offered to a sufficient number of different users. This is a purely business idea.
The invention
The invention concerns an Internet service aggregating transport price data, e.g. flight prices, collected from users’ searches of prices on transport providers’ websites.
Claim 1 of the main request specifies a method which searches and extracts flight data from various airline web pages that users view and provide this data to a central data receiving (second) server 22 for storage in a database 26. This database is searchable through the Internet via a further server 28.
The web page containing the price data served by the airline’s website also contains a script. The users’ browsers (clients) 20 execute the script which searches the web page and extracts the price data.
In order to ensure the reliability of received flight prices, the data receiving server monitors IP addresses of the clients and only considers a flight price as trusted and suitable for distribution, after it has received this price from clients at a sufficient number of different IP addresses.
Figure 1 of EP2849130
Here is how the invention was defined in claim 1:
-
Claim 1 (main request)
Is it patentable?
The examining division found that claim 1 lacked an inventive step over D3.
The Board also considered D3 as the closest prior art and considered that claim 1 differs from D3 as follows:
- Feature (b), end: By a further Internet server which selects and serves the aggregated data from the database to browser clients.
- Features (c) and (d): In that the data receiving server monitors IP addresses from which the data was received and only considers a particular price to be trusted, and thereby suitable for distribution, once it has received the same price from Internet browser clients at a number of different IP addresses.
- Feature (a), end: In that the one or more received executable instructions cause the Internet browsing client to search at least a portion of the received web page data to extract the scheduled transport price data for transmission to the data receiving server.
The Board denied the inventive step of claim 1 based on the following reasoning:
2.5 Like the examining division, the Board judges that the specification of transport data relates to business data content and is not technical (see decision, point 12.5.1) and that the feature of the further Internet server is an obvious option (point 12.5.3). The Board adds to the examining division’s analysis of the latter feature that middleware servers sitting between a database and Internet browser clients were common knowledge at the priority date, as shown by background document D9 for example.
2.6 As for determining trust based on the number of different IP addresses, it was common ground that it produced the effect of returning only trusted prices to Internet browser clients. However, the claimed method (feature (d)) does not actually use the information about the prices’ trustworthiness while storing data in the database and it is doubtful whether the asserted effect is indeed provided.
2.7 Nevertheless, the Board agrees with the examining division that even assuming that only trusted prices are stored in the compiled price data database, this feature is obvious.
The appellant argued that any kind of data filtering was a technical process. However, in the claim, the filtering boils down to disregarding prices that were not offered to a sufficient number of different users. The Board concurs with the examining division (decision, point 12.5.5) that this is a purely business idea.
It is common ground (cf. decision, point 12.7.5) that using IP addresses to distinguish user devices is an implementation choice. However, this would have been obvious, once, in line with the COMVIK principle (see decision T 641/00 – Two identities/COMVIK), the aforementioned business idea has been given to the skilled person for implementation. The obviousness of the solution becomes even more apparent considering that in D3 the central server already receives clients’ IP addresses together with the extracted product information (paragraph [80], last sentence).
2.8 At the oral proceedings the main point of contention was the obviousness of using the script to search the received web page to extract the price data.
Firstly, the appellant argued that the skilled person was a computer programmer for cataloging and reporting Internet site activity data. However, the Board considers this to be an arbitrarily restrictive technical qualification to the particular application of D3 that does not exist in practice. In the Board’s view, the skilled person is simply a web programmer.
Secondly, the appellant considered that using the script to search the web page solved the problem of reducing the amount of transmitted data between the merchant and the browser. The Board agrees that this is certainly one effect of the invention. However, the Board sees the invention in a more general sense as being about the decision where to obtain information about products’ prices. In D3, it is done by the merchant, whereas in the invention it is the browser. Thus, the difference in a more general sense represents an alternative choice for where to perform the processing.
In this general context the amount of transmitted data is one of many trade-offs. Others would be: processing power required at the merchant/browser and programming complexity at the merchant/browser. Furthermore, the choice could be driven by non-technical considerations, such as whether the merchant or the customer wants to control the information obtained.
Thus, the Board essentially agrees with the examining division that searching and extracting information about the web page in the browser is more properly to be considered as an alternative to providing this information at the merchant. In such cases, the skilled person would consider any well known alternative in the technical field unless the closest prior art, or some other fact, teaches away from it.
As mentioned above, the skilled person is a web programmer. A web programmer knows that the solution of searching and extracting data from web pages is a well-known technique, commonly known in the art as web scraping. In fact, as stated by the examining division (decision, point 14.4), D3 at paragraph [75] actually teaches obtaining the product price information using web scraping as an alternative to obtaining this information from the embedded script, albeit at another server.
Furthermore, the Board judges that, contrary to the appellant’s view, the use of JavaScript as present in the browser in D3 to scrape pages poses no technical difficulty.
Thus, the Board agrees with the examining division’s conclusion at point 14.4 of the decision that the skilled person would have considered using a scraping functionality in the embedded script as an obvious possibility.
2.9 Hence, claim 1 lacks an inventive step (Article 56 EPC).
All the auxiliary requests were found to lack an inventive step. Finally, the Board dismissed the appeal and the European patent application was refused.
More information
You can read the whole decision here: decision T 1468/20 of the Technical Board of Appeal 3.5.01.