T 1468/20 (Extracting flight data/SKYSCANNER) of 6.7.2023

Summary of Facts and Submissions

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

II. The examining division found that claim 1 of the main request was obvious over D3 (US 2007/0299743 A1). The additional feature of the first auxiliary request was obvious over D3 in view of common general knowledge as exemplified in D7 (US 2005/097189 A1) or D8 (WO 2006/019941 A2). The additional features of claim 1 of the second and third auxiliary requests were obvious over D3 combined with common general knowledge summarised by D6 (ANONYMOUS: "HTML 4.0 Specification", INTERNET CITATION, published on 24 April 1998, retrieved on 25 February 2002). The additional clarifying feature of claim 1 of the fourth and fifth auxiliary requests was obvious over D3.

III. In the statement setting out the grounds of appeal, the appellant requested that the decision be set aside and a patent be granted on the basis of the refused requests.

IV. In the communication accompanying the summons to oral proceedings, the Board expressed its preliminary view that the main request was obvious over D3 in view of common general knowledge summarised by background document D9 (Wikipedia entry: "Multitier architecture", published on 10 January 2008) which the Board introduced into the proceedings under Article 114(1) EPC. The additional features of the auxiliary requests were obvious over the combination of D3 and D7 and the common general knowledge summarised by D6.

V. By letter of 5 May 2023, the appellant provided arguments in favour of inventive step of the main and first auxiliary request.

VI. The oral proceedings took place on 6 July 2023, jointly with oral proceedings for related cases T 1467/20 and T 540/20. As per appellant's request, they were held by videoconference.

VII. Claim 1 of the main request reads:

"A computer-implemented method of storing scheduled transport price data comprising the following steps:

(a) extracting scheduled transport price data from web page data using a plurality of Internet browsing clients, wherein a data receiving server is in communication with a plurality of Internet browsing clients, wherein a plurality of first web page data servers serve web page data to the plurality of Internet browsing clients responsive to each client request, wherein the served web page data comprises scheduled transport price data and executable instructions, the scheduled transport price data comprising at least one identifier of an instance of scheduled transport and at least one price associated with a said instance of scheduled transport; and the Internet browsing clients execute the executable instructions, wherein the execution of the executable instructions causes the Internet browsing clients to transmit at least a portion of the received scheduled transport price data from the served web page data to the data receiving server responsive to the execution of the executable instructions;

wherein in order to select the portion of the received scheduled transport price data to be transmitted by the Internet browsing client to the data receiving server responsive to the execution of the one or more received executable instructions, 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;

(b) storing the scheduled transport price data in a database of scheduled transport price data searchable by a scheduled transport price data search engine, wherein the data receiving server stores the extracted scheduled transport price data as a compiled price data database, wherein the compiled price data is provided to a further Internet server which is operable to select and serve price data from the compiled price data responsive to search requests from Internet browser clients;

and in which:

(c) the number of different IP addresses from which the same price of an instance of scheduled transport is received is counted to determine whether it is trusted and can hence be distributed, and

(d) IP addresses from which the scheduled transport price data was received are monitored by the data receiving server, which only considers a particular price to be trusted, and thereby suitable for distribution, once the data receiving server has received the same price from Internet browsing clients at a number of different IP addresses, wherein the data receiving server populates the scheduled transport price data database."

VIII. Claim 1 of the first auxiliary request adds to claim 1 of the main request the following wording at the end of feature (a):

"wherein the one or more received executable instructions comprise pattern matching instructions, which, when executed, cause the Internet browsing client to extract data which fulfils criteria specified by the pattern matching instructions, wherein some or all of which extracted data is transmitted to the data receiving server;"

IX. Claim 1 of the second auxiliary request adds the following two features at the end of claim 1 of the main request:

"wherein the web page data includes a reference to an address of the data receiving server from which second web page data is downloaded by an Internet browsing client and the Internet browsing client downloads second web page data from the referenced data receiving server responsive to receipt of the first web page data, such that received web page data comprises both the web page data and the second web page data,

wherein the web page data comprises one or more first executable instructions and the second web page data comprises one or more second executable instructions, the said one or more received executable instructions comprising the one or more first executable instructions and the one or more second executable instructions, wherein execution of the one or more first executable instructions causes the Internet browsing client to execute the one or more second executable instructions, wherein execution of the one or more second executable instructions by the Internet browsing client causes the Internet browsing client to transmit at least a portion of the received scheduled transport price data to the data receiving server."

X. Claim 1 of the third auxiliary request adds the same two features at the end of claim 1 of the first auxiliary request.

XI. Claim 1 of the fourth auxiliary request adds to feature (d) of claim 1 of the main request the wording "which is then distributed" after "suitable for distribution".

XII. Claim 1 of the fifth auxiliary request incorporates the same amendment into claim 1 of the first auxiliary request.

XIII. The appellant argued as follows:

In contrast to the claimed invention, the script of D3 did not extract price information from a shopping web page into which it was embedded. Rather, it received this information from the merchant server that provided the web page. The claimed solution reduced the amount of transmitted data which was a technical effect. Since D3 did not provide any hints to this solution, the skilled person, who was a computer programmer for cataloging and reporting Internet site activity data, would not have arrived at it. Although D3 mentioned web scraping as a possible alternative, this process was performed on a web scraping server, rather than within the limited programming environment of the browser.

Considering only trusted prices was a data filtering process and, therefore, technical. The use of IP addresses to distinguish user devices was a technical implementation choice.

The system of D3 did not store price data in a compiled price data database.

The use of a script linked from another server, as defined in the second and third auxiliary requests, solved the technical problem of minimising disturbance to the airline's web server while amending the script. By combining D3 and D6, the skilled person might have arrived at linking the web page to an external script, but not at placing this script on another server.

Reasons for the Decision

1. The invention

1.1 The invention concerns an Internet service aggregating transport price data, e.g. flight prices, collected from users' searches of prices on transport providers' websites, see published application, paragraphs [8] and [59].

1.2 In terms of Figure 1, claim 1 of the main request specifies a method which searches and extracts flight data ("scheduled transport price data" in the claim) 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 ("compiled price data database"), see paragraphs [52], [56] and [58]. This database is searchable through the Internet via a further server 28, see paragraphs [53] and [60].

The web page containing the price data served by the airline's website also contains a script ("executable instructions"). The users' browsers (clients) 20 execute the script which searches the web page and extracts the price data, see paragraph [56].

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, see paragraph [62].

2. Main request, Article 56 EPC

2.1 The examining division found that claim 1 lacked an inventive step over D3 that also disclosed a central "data receiving server" aggregating price data from shopping web pages rendered on users' computers. The information was provided by a web script embedded on the web page, see D3, paragraphs [64], [76], [77] and [80].

2.2 Contrary to the appellant's view, the Board agrees with the examining division (decision, point 12.3) that the central database of D3 in which the collected price information is stored corresponds to the compiled price data database in feature (b) of claim 1, see D3 paragraph [64]. The Board also considers, unlike the division (decision, point 12.4.4), that the central database of D3 responds to search requests as specified in the same feature, see paragraphs [135], [143] and [144]. Thus feature (b) differs by the use of a further server for handling the search requests and the fact that the querying users are Internet browser clients.

2.3 In the communication accompanying the summons to oral proceedings, the Board tended to consider that D3 also implicitly disclosed that the script ("executable instructions") on the web page received by the user searched the rendered web page in order to extract the price data information (last part of feature (a)). However, at the oral proceedings, the Board accepted the appellant's reading of D3 that the script did not extract information from the web page but rather requested it from the merchant server. Thus, in D3, the merchant server provides the user's browser with two kinds of information: the shopping web page to be rendered and a message containing information on shown products directed to the embedded script.

2.4 Hence, claim 1 differs from D3 as follows:

Claim preamble: In that the processed data relates to scheduled transport data.

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.

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).

3. First auxiliary request, Article 56 EPC

3.1 Claim 1 of the first auxiliary request adds that the executable instructions use pattern matching instructions to extract the price information from the web page.

3.2 However, as set out at point 14.4 of the decision, it was common knowledge at the priority date that pattern matching instructions, such as regular expressions, were used in web scraping. In this respect, during the oral proceedings, the Board cited the Wikipedia articles on web scraping and regular expressions which confirm these statements.

Thus, the use of pattern matching instructions would have been obvious.

3.3 Hence, claim 1 lacks an inventive step (Article 56 EPC).

4. Second and third auxiliary requests, Article 56 EPC

4.1 Claim 1 of the second auxiliary request essentially adds that the "executable instructions" consist of "first executable instructions" and "second executable instructions". The former are executed when the web page has been loaded (e.g. by onload event handler 208 in Figure 4) and cause execution of the "second executable instructions". These instructions (e.g. the function "skygo" in Figure 5A), which have been downloaded from a given address on the data receiving server (e.g as a JavaScript using the <script> tag 206), actually cause the client to transmit the required data.

4.2 Contrary to the appellant's view, the Board agrees with the examining division (decision, point 15.4) that, starting from D3, linking the web page to a script on the central server is an obvious application of the HTML script element described in D6 at section 18.2.1.

Again, the Board views this feature as an alternative; embedding the whole script code on the page versus loading it from the data receiving server. And again, the appellant's problem of minimising disturbance to the airline server while altering the script is one of the trade-offs representing the circumstances steering the choice of alternative. Another would be the loading time of the script.

4.3 Hence, claim 1 of the second auxiliary request lacks an inventive step (Article 56 EPC). And so does claim 1 of the third auxiliary request, adding the identical feature to claim 1 of the first auxiliary request.

5. Fourth and fifth auxiliary requests, Article 56 EPC

5.1 Claim 1 of the fourth auxiliary request adds to claim 1 of the main request that trusted prices are distributed. Claim 1 of the fifth auxiliary request adds this feature to claim 1 of the first auxiliary request.

5.2 The added feature is obvious for the reasons provided in connection with the feature determining trust based on the number of different IP addresses (see point 2.6, above). Accordingly, the fourth and fifth auxiliary requests lack an inventive step (Article 56 EPC).

6. Since none of the appellant's requests are allowable, it follows that the appeal must be dismissed.

Order

For these reasons it is decided that:

The appeal is dismissed.