European Case Law Identifier: | ECLI:EP:BA:2015:T173411.20150113 | ||||||||
---|---|---|---|---|---|---|---|---|---|
Date of decision: | 13 January 2015 | ||||||||
Case number: | T 1734/11 | ||||||||
Application number: | 05759549.8 | ||||||||
IPC class: | G06Q 10/00 G06Q 30/00 |
||||||||
Language of proceedings: | EN | ||||||||
Distribution: | D | ||||||||
Download and more information: |
|
||||||||
Title of application: | METHOD AND SYSTEM FOR PRESENTING RATES FOR TRAVEL SERVICES | ||||||||
Applicant name: | Expedia, Inc. | ||||||||
Opponent name: | - | ||||||||
Board: | 3.5.01 | ||||||||
Headnote: | - | ||||||||
Relevant legal provisions: |
|
||||||||
Keywords: | Inventive step (no - presentation of information) | ||||||||
Catchwords: |
- |
||||||||
Cited decisions: |
|
||||||||
Citing decisions: |
|
Summary of Facts and Submissions
I. This is an appeal against the decision of the Examining Division to refuse European patent application No. 05759549.8. The application was published as WO2006/009647 A2.
II. The Examining Division refused the application, in oral proceedings on 1 March 2011, for lack of inventive step (main request and auxiliary requests one to three). The fourth auxiliary request was not admitted under Rule 137(3) EPC, because the amended features did not overcome the objections under Article 56 EPC, and because compliance with Article 123(2) EPC was not immediately apparent.
The Examining Division argued that the presentation of rates for travel services was a method of doing business and of presenting information, and that the technical character of the invention resided only in the automation of the method using a data processing system comprising a client, a server, an interactive interface, and a database having a cache. Starting from a notorious client-server system, the Examining Division could not derive any technical problem solved by the invention; therefore, an inventive step could not be established.
III. In the statement setting out the grounds of appeal, dated 27 July 2011, the appellant requested that the decision to refuse the application be set aside and that a patent be granted on the basis of one of the main, the first auxiliary, and the second auxiliary requests underlying the impugned decision, or, based on newly-filed third to fifth auxiliary requests.
IV. The Board summoned the appellant to oral proceedings. In a communication accompanying the summons, the Board provisionally agreed with the Examining Division that the invention did not involve an inventive step over the notorious client-server system.
V. In reply to the Board's communication, the appellant filed, on 12 December 2014, a set of requests denoted auxiliary requests 6 to 9, and presented arguments in favour of inventive step.
VI. Oral proceedings before the Board took place on 13 January 2015. The appellant submitted auxiliary request 6a and withdrew the first and third to fifth auxiliary requests. The appellant's final requests were that the a patent be granted on the basis of the main request, the second auxiliary request, or one of auxiliary requests 6, 6a, and 7 to 9.
VII. Claim 1 of the main request reads:
"A method for presenting rates for travel services, the method comprising:
receiving at a travel server (106) a consumer's selection of a travel service relayed from a client device (102),
upon the travel server (106) receiving the consumer's selection of a travel service, determining a proposed date of travel from the received consumer selection, and obtaining a dynamic range of available rates for a travel service from a least expensive rate to a most expensive rate from rate plan data, including calling (630) a cache of an inventory database (108) to obtain rate plan data associated with the travel service and retrieving (640) the rate plan data from the cache,
subdividing the dynamic range of available rates into a limited number of pricing bands, wherein each pricing band represents a portion of the dynamic range of available rates,
determining an approximate rate for the travel service based on the pricing band corresponding to the portion of the dynamic range of available rates within which an exact rate for the travel service falls, and
presenting to the client device (102) the approximate rate for the travel service in an interactive interface using a characteristic keyed to the corresponding pricing band, the characteristic including at least one of a graphical and audio characteristic that conveys a relative expense of the approximate rate for the travel service compared to other approximate rates for the travel service presented in the same interface,
wherein obtaining the dynamic range of available rates for the travel service from the least expensive rate to the most expensive rate from the rate plan data includes obtaining rates available during or close to the proposed date of travel, and presenting the approximate rate for the travel service is presenting the approximate rate for the travel services for a particular date during or close to the proposed date of travel."
VIII. The second auxiliary request differs from the main request in that the following text is added to the second method step of claim 1:
"comprising determining which months of the rate plan data for the consumer's selection of the travel service to obtain from the cache of rate plan data obtained from the inventory database, wherein the cache is a subset of the rate plan data stored in a memory (450) of the travel server (106) and periodically refreshed to facilitate rapid access to current rate plan data while minimizing database access delays"
Claim 1 of the second auxiliary request also specifies that the "subdividing" and "determining" steps are performed "by the travel server".
IX. Claim 1 of the sixth auxiliary requests builds on claim 1 of the second auxiliary request and includes the further limitations that there are "no more than five" pricing bands, that the step of obtaining the dynamic range of available rates includes "obtaining rates available during a period of time, the period of time including a month during or close to which the proposed date of travel occurs plus an additional number of months proximate to the month during or close to which the proposed data of travel occurs", and that "the interactive interface is an interactive calendar in which the characteristic keyed to the corresponding pricing band is displayed in a particular cell of the interactive calendar that represents the particular date during or close to the proposed date of travel and the cells of the interactive calendar represent a month in which the particular data during or close to the proposed data of travel occurs and a month proximate to the month in which the particular date during or close to the proposed date of travel occurs".
X. Auxiliary request 6a differs from auxiliary request 6 in that claim 1 specifies that the period of time during which the available rates are obtained is "six months starting with a month during which the proposed date of travel occurs".
XI. Auxiliary request 7 builds on auxiliary request 6 and adds the following feature at the end of claim 1: "the method further comprising determining (738) if consumer input to the interactive calendar changing the proposed date of travel causes a change in the period of time for which rates are obtained in obtaining the dynamic range of available rates, and if yes, redetermining, by the travel server, the period of time and recomputing, by the travel server, the pricing bands accordingly".
XII. Claim 1 according to auxiliary request 8 reorders the features of claim 1 according to the second auxiliary request and introduces the limitation that, in addition to the approximate rates, the exact rates are presented to the client device. Claim 1 according to auxiliary request 8 reads in full:
"A method for presenting rates for travel services, the method comprising:
receiving at a travel server (106) a consumer's selection of a travel service relayed from a client device (102) via an interactive interface that is accessible to the client device (102),
upon the travel server (106) receiving the consumer's selection of a travel service, the travel server (106) determining a proposed date of travel from the received consumer selection, and the travel server (106) obtaining a dynamic range of available rates for a travel service from a least expensive rate to a most expensive rate from rate plan data, including the travel server (106) calling (630) a cache of an inventory database (108) to obtain rate plan data associated with the travel service and the travel server (106) retrieving (640) the rate plan data from the cache, comprising determining which months of the rate plan data for the consumer's selection of a travel service to obtain from the cache of rate plan data obtained from the inventory database (108), wherein the cache is a subset of the rate plan data stored in a memory (450) of the travel server (106) and periodically refreshed to facilitate rapid access to current rate plan data while minimizing database access delays, wherein obtaining the dynamic range of available rates for the travel service from the least expensive to the most expensive rate from the rate plan data includes obtaining rates available during or close to the proposed date of travel,
subdividing, by the travel server (106), the dynamic range of available rates into a limited number of pricing bands, wherein each pricing band represents a portion of the dynamic range of available rates,
determining, by the travel server (106), an approximate rate for the travel service based on the pricing bands corresponding to the portion of the dynamic range of available rates within which an exact rate for the travel service falls, and
presenting to the client device (102) in the interactive interface for a particular date during or close to the proposed date of travel the approximate rate for the travel service by a characteristic keyed to the corresponding pricing band, the characteristic including at least one of a graphical and audio characteristic that conveys a relative expense of the approximate rate for the travel service compared to other approximate rates for the travel service presented in the same interface, and, in addition, the exact rate."
XIII. Auxiliary request 9 differs from auxiliary request 8 in that the further limitations of auxiliary request 6 as defined above are added to claim 1.
XIV. The appellant's arguments may be summarised as follows:
The use of a notorious client-server system could not be the starting point for assessing inventive step. That would result in a disproportionate hurdle for the applicant, because it was difficult, if at all possible, to identify a technical problem with respect to such prior art. A general purpose computer system had no drawbacks, because it was just a set of machines suitable for performing some tasks; there would be no reason to improve it.
Where there was documentary prior art available in the same or a similar technical field (in the present case electronic travel service systems), it was mandatory to assess inventive step vis-à-vis such prior art. The prior art closest to the invention was the published patent application GB2366403A, which was cited in the international search report.
The invention concerned a particular technical implementation of presenting travel rates to a user, comprising computing pricing bands and presenting those bands in an interactive user interface using a characteristic keyed to the corresponding band. This particular implementation contributed to the solution of a technical problem by providing a technical effect: the pricing bands allowed the user quickly to compare rates, without having to look at the exact rates, which reduced user interaction.
By calculating the pricing bands from six months of available exact rates, while displaying only two months of approximate rates, the user could quickly grasp whether the rates on or close to the proposed date of travel were good in comparison to other rates during a six-month period, without having to scroll to other months of the whole six-month period. Furthermore, since only two months were displayed, less screen estate could be used. This was similar to T 928/03-Video game/KONAMI, where the Board considered the conflicting requirement of displaying a zoomed-in image and keeping an overview of a zone of interest larger than the display area to be a technical requirement.
The solution using pricing bands was based on the notion that an online travel service system involved the processing of large amounts of complex information, which was to be presented to the user on a relatively small screen. In other words, the solution relied on a technical understanding of the underlying travel service system, and, consequently, it lay within the scope of a technically qualified person and not that of the business or administrative person (T 844/09, point 5.3 of the reasons). While the business person might have come up with the general idea of improving user interaction, the solution of using pricing bands would have to be provided by a technically skilled person.
The pricing bands provided a reduction in the amount of data transmitted from the travel server to the client device; it would take less data to send the limited number of pricing bands than to send the full range of exact rates.
The solution of calculating the pricing bands at the travel server was particularly surprising since they would only be of interest to the querying consumer; it would make more sense to calculate the pricing bands in the client device. Furthermore, as the complex calculations would increase the query response time of the server, the calculations were only made possible by a specifically adapted cache.
Reasons for the Decision
1. The invention concerns the online presentation of rates for travel services.
2. When booking a holiday online, a consumer typically has to navigate through numerous web pages and to digest large amounts of detailed information. This makes it difficult to compare different offers, and to get an overview of available rates (see page 3, lines 1-14, of the published application).
3. The invention seeks to overcome this by providing a limited number of "pricing bands" representing approximate rates for travel services. The pricing bands are presented to the consumer using a "characteristic" keyed to each band, e.g. one colour for the least expensive band, another for the next, and so on (published application, page 3, lines 23-30; and figure 10).
4. The invention is implemented in a system comprising a "travel server" and a "client device". There is also an "inventory database", having a cache, for storing the "rate plan data". The travel server receives the consumer's selection of a travel service, determines a proposed date of travel from the consumer's selection, computes the pricing bands, and transmits them to the consumer's client device where they are presented, using the characteristics, in an "interactive interface".
5. Auxiliary request 6a
5.1 Since auxiliary request 6a is more narrowly defined than any of the main request, auxiliary request 2, and auxiliary request 6, the Board finds it convenient to consider this request first.
5.2 Claim 1 defines a method for presenting rates for travel services, making use of the travel service system comprising a travel server and a client device.
In this request, the travel server calculates the pricing bands by dividing the dynamic range of available rates into no more than five bands. The available rates cover a period of six months starting from the month in which the proposed date of travel occurs. Moreover, the interactive interface of the client device is an "interactive calendar" displaying the pricing bands for two months: the month in which a "particular date during or close to the proposed date of travel" occurs, and a month proximate to it.
5.3 In the decision under appeal, the Examining Division assessed inventive step starting from a notorious data processing system comprising: a server; a client device having an interactive interface; and a database having a cache. The appellant did not contest that such a system was known, but argued that it was not the "closest prior art" and, consequently, not an appropriate starting point for assessing inventive step.
5.4 The Board is not convinced by the appellant's argument concerning the "closest prior art". Inventive step is assessed against the state of the art, meaning all prior art. One obvious route from a reasonable starting point is enough to demonstrate a lack of inventive step. In the Board's view, the notorious client-server system represents a reasonable starting point because it relates to the overall architecture of the system used in the method of claim 1.
5.5 The invention according to claim 1 differs from the notorious client-server system by the method for presenting rates for travel services, the method being implemented in the system to the effect that the server receives a request from the client, calculates the pricing bands, and transmits the results to the client device where they are presented. Thus, according to established case law of the Boards of Appeal, the question to be decided is whether this difference makes a technical contribution which supports the presence of an inventive step (see in particular T 641/00-Two identities/COMVIK, Headnote 1, OJ EPO 2003, 352).
5.6 The appellant argued that the presentation of rates, involving pricing bands and the display of two months out of six, was technical because it required less user interaction, could occupy a smaller screen area, and reduced the amount of data to be transmitted.
5.7 In the Board's view, however, a reduction of user interaction does not necessarily convey technical character to the means for achieving the reduction. For example, a travel agent who acts as an intermediary between providers of travel services and a prospective traveller also has the effect of reducing the interaction between the end consumer and the providers of those services. The travel agent collects and processes information, and presents the results to the customer in a suitable form. This is, in the Board's view, an administrative process which can be performed without technical means and without the need of technical skill.
5.8 In relation to inputting information to a machine and reducing the burden of doing so, while these may be technical tasks a priori (at least in the sense that they are not listed in Article 52(2) EPC), not everything that supports a technical task has itself a technical character (T 1741/08-GUI layout/SAP, point 2.1.12).
5.9 On the other hand, presenting (i.e. outputting) information is deemed to be non-technical a priori (Article 52(2)(d) EPC). However, in contrast to the presentation of the state of a technical machine, which may have technical character (T 115/85-Computer-related invention/IBM, OJ EPO 1990, 30), the Board considers that the presentation of pricing information, for example by colour coding, no matter how skilful that might be, is a non-technical aspect even if it helps the user to conduct a price-sensitive travel query more efficiently.
5.10 The particular manner of calculating the pricing bands depends on the information to be presented and on the requirements of the requesting consumer. A consumer might ask a travel agent for information about rates for a particular date. The question posed by the consumer might be whether the rates were good in comparison to other rates over a six-month period. This is a non-technical requirement, and not a technical solution to a technical problem.
5.11 The Board does not accept that two months necessarily take up a smaller area of the screen than a six months. That depends on display parameters such as font size and resolution, which are not defined in claim 1. In any event, the Board considers this to be a direct consequence of the non-technical requirement to present two months instead of six months. This may be put in contrast to T 928/03, where the conflict between the limited display area and the information to be conveyed, arose in the context of a video game and, was resolved using technical means, namely a guide mark indicating what is happening outside the displayed area. In the Board's view, T 928/03 does not support the proposition that the display of any global property on a local display is technical.
5.12 The Board is not convinced that the pricing bands lead to bandwidth reduction. The appellant's argument seems to compare the invention with a method that transmits exact prices. That, however, is not the starting point for the assessment of inventive step.
Furthermore, claim 1 does not specify any relationship between the number of pricing bands and the number of exact rates, so it might well take more data to define the pricing bands than to send the exact rates. Indeed, claim 1 according to auxiliary request 8 shows that transmission of the exact rates in addition to the pricing bands is not excluded, and that would lead to an increase of data to be transmitted. Thus, the effect of bandwidth reduction does not appear to be obtained even when the invention is compared to the method of transmitting exact prices only.
5.13 For these reasons, the Board does not see that the particular manner of presenting rates for travel services, using pricing bands and the corresponding characteristics, contributes to the solution of a technical problem by providing a technical effect. In the Board's judgment, this is a matter of presentation of information, which does not contribute to the technical character of the invention (Article 52(2)(d) EPC). To continue the example of 5.105.10 , above, the agent would not normally list all rates for a six-month period, but would rather say that the best rate is on such and such a date, or that October is the best month and that the cheapest rates are in the first week.
5.14 Therefore, the Board considers that the technical contribution of the invention over the notorious client-server system lies in how the method is implemented, and in particular in how the method steps are distributed between the client and the server.
5.15 The Board considers the particular distribution of tasks between a server and a client in a distributed computing environment to be a routine choice. The skilled person would choose between centralized and decentralized solutions depending on factors such as the available computational resources and transmission bandwidth. The application does not show any consideration of such factors, let alone a particular, optimal balance. The fact that there may be other, more obvious solutions does not create a prejudice against the invention. The question to be answered is whether the invention would have been obvious, not whether it would have been most obvious. The Board considers that, at least when the server and client are such that the former is relatively more powerful, calculation by the server would have been obvious.
5.16 It is common ground that the use of a cache to provide fast access to data was known at the date of the invention.
In the Board's view, the effect of the cache in claim 1 is independent of the calculation of the pricing bands. A cache would reduce latency of data access, with or without pricing bands. Similarly, the complexity of the calculation of the pricing bands does not depend on the use of a cache. Thus, the Board does not share the appellant's view that the use of a cache for accessing the rate plan data provides any surprising advantage. On the contrary, this is nothing more than using a cache for what it was designed for.
5.17 For these reasons, the Board considers that the implementation of the method for presenting travel services on the notorious client-server system would have been straightforward, and obvious for the skilled person.
5.18 In conclusion, auxiliary request 6a cannot be allowed, because the subject-matter of claim 1 does not involve an inventive step (Article 56 EPC 1973).
6. Main request, auxiliary request 2, and auxiliary request 6
The subject matter of claim 1 according to auxiliary request 6a is within the scopes of claim 1 of the main request, of auxiliary request 2, and of auxiliary request 6. Thus, for the same reasons as above, these requests are not allowable for lack of inventive step (Article 56 EPC 1973).
7. Auxiliary request 7
7.1 Compared to auxiliary request 6, claim 1 adds that, if the consumer input to the interactive calendar changes, the pricing bands are recalculated accordingly.
7.2 In the Board's view, this feature is a direct consequence of the interactive nature of the method. Furthermore, if it is obvious to perform the method once, based on first input data, it would be equally obvious to repeat the method, based on second input data. Therefore, auxiliary request 7 is no more allowable than auxiliary request 6.
8. Auxiliary request 8
8.1 Claim 1 according to this request differs from auxiliary request 2 essentially in that, in addition to the characteristic keyed to the corresponding pricing band, the exact rate is presented.
8.2 The Board considers this feature to be a matter of choosing which information to present, which cannot support the presence of an inventive step. Choosing to display the exact rates is no more technical than choosing to display the pricing bands.
9. Auxiliary request 9
Claim 1 is based on auxiliary request 8 and includes further limitations as in auxiliary request 6. Since neither auxiliary request 6 nor auxiliary request 8 provides a technical contribution over the notorious client-server system, nor does auxiliary request 9, which is consequently not allowable for lack of inventive step (Article 56 EPC 1973).
Order
For these reasons it is decided that:
The appeal is dismissed.