T 3005/18 (Bid tracking database/BLACKBERRY) of 28.10.2022

Summary of Facts and Submissions

I. This is an appeal against the examining division's decision to refuse European patent application No. 09176410.0.

II. The examining division refused the application for lack of clarity as well as lack of inventive step in view of a generic "architecture including a server implementing receiving bids from client devices". Document D1 (US 2009/012877) was cited as an example.

III. In the statement setting out the grounds of appeal, the appellant requested that the decision be set aside and that a patent be granted on the basis of the main or first to fourth auxiliary requests, filed therewith. There was also a further auxiliary request for oral proceedings.

IV. The Board informed the appellant in the communication accompanying the summons to oral proceedings that it was of the opinion that claim 1 of all requests was unclear and lacked an inventive step.

V. In response to the summons, the appellant filed auxiliary requests five to nine and provided further arguments in favour of the patentability of all requests on file.

VI. Oral proceedings were held as a videoconference on 28 October 2022. The appellant confirmed its requests submitted in writing that the decision under appeal be set aside and that a patent be granted on the basis of the main request or one of the first to fourth auxiliary requests, filed with the statement of grounds of appeal, or one of the fifth to ninth auxiliary requests, filed in response to the summons.

VII. Claim 1 of the main request reads:

"A method of managing a bid tracking database (314) at a first server (116), the method comprising:

transmitting a request (405) to a second server (112) for the at least one bid record at a pre-defined time interval after a previous request, the request being for any bid records that have been received at the second server (112) since the previous request was transmitted;

receiving (410) at least one bid record (200) at an interface (304)of the first server (116) from the second server (112), the at least one bid record having been received at the second server (112) from a mobile electronic device (104) and comprising a bid price (204), a bid timestamp(206) and a bid item identifier (202);

generating (415) a list of item identifiers based on the received bid records (316);

transmitting (420) a request for at least one auction record;

receiving (425) at least one auction record (250) at the interface (304) from a third server (108), the at least one auction record comprising a winning price (258), an end timestamp (260) and an auction item identifier (252) corresponding to the bid item identifier (202);

maintaining the at least one bid record (200) and the at least one auction record (250) in a memory (312);

determining (440) whether the bid price matches or exceeds the winning price and whether the bid timestamp matches the end timestamp; and,

when the determination is affirmative, writing (445) the bid record to the bid tracking database (314) maintained in the memory (312)."

VIII. Claim 1 of the first auxiliary request adds to the main request the expression "such that the list (318) does not contain any duplicated item identifiers" after the generating step, and the expression "the request for the at least one auction record being a request for an auction record corresponding to each item identifier present in list (318)" after the transmitting step.

IX. Claim 1 of the second auxiliary request adds to the first auxiliary request the expression "whereby one auction record is received for each item identifier for which the request for the at least one auction record was transmitted, the auction records (320), once received, being maintained in memory (312) of the first server" in the receiving step and, at the end of the claim, the expression "wherein writing (445) the bid record to the bid tracking database (314) occurs after it is determined (430) that the auction records (320) contain data for auctions that have ended; and following completion of the writing (445), or the determining (440), if the determination is negative, deleting from bid records (316) records therein having the item identifier of the or each ended auction that has been processed by the determining (440) and/or writing (445)".

X. Claim 1 of the third auxiliary request adds to the second auxiliary request "a plurality of wireless mobile electronic devices (104), the first server (116), a second server (112) configured to store bid records (200) in memory and a third server (108) configured to host an auction website and configured to maintain in memory a plurality of auction records each comprising data concerning a particular auction, and to receive bids on items represented by the auction records and maintain the received bid records in memory", and in the receiving step "wherein, for each mobile device, a first transmission (T-1) of the bid records via a wireless link (124-2) is received at the third server (108) and a second transmission (T-2) of the bid records via the wireless link (124-2) is received at the second server (112)".

XI. Claim 1 of the fourth auxiliary request adds to the third auxiliary request, at the end of the receiving step, the expression "and wherein the second transmission (T-2) of the bid records is substantially simultaneous with the first transmission (T-1); and the first transmission (T-1) additionally contains an identifier, incorporated within the bid record, for the wireless mobile electronic device, whereas the second transmission (T-2) omits such identifier".

XII. The fifth to ninth auxiliary requests change the preamble of the main and first to fourth auxiliary requests, respectively, to "A method of managing a bid tracking database (314), wherein the bid tracking database (314) is hosted at a first server (116)".

XIII. The appellant's arguments can be summarised as follows:

The invention increases resilience, scalability and flexibility, since bid records and auction records are stored, in a specific way, on servers different from the first server. In this way, in the case of a malfunction, auction records stored on the third server can be regenerated from the bid records on the second server. Requesting bid records periodically and avoiding duplicates in the generated list of item identifiers reduces both network traffic and load requirements on the third server. Sending bid data on the wireless link to both the second and third server reduces the chance that a bid is missed, thereby increasing robustness, and further guarantees the synchronisation of the data stored in the different databases. Refraining from providing the terminal identifiers to the second server further reduces the bandwidth requirements and anonymises the bid.

Reasons for the Decision

1. The invention concerns a method of managing a bid tracking database in an online bidding system including three servers (Figure 1, 116, 112 and 108, hereafter "first server", "second server" and "third server", respectively). The third server hosts auctions of a plurality of items. Users send bids for the various items to the second and third servers over wireless links using their mobile devices (paragraphs [0016], [0017], [0020]). The first server periodically requests bid records from the second server and corresponding auction records from the third server. The bid records include a time-stamp, a bid price and an item identifier for the received bids, while the auction records include a winning price, and end time-stamp and an item identifier for each concluded auction. The first server adds a received bid record to a bid tracking database if its bid price matches or exceeds the winning price for the corresponding auction, and its time-stamp corresponds to the auction's end time-stamp (in other words, if it represents the winning bid: Figure 3, 116, Figure 4, paragraphs [0022] to [0034]).

Main and first to fourth auxiliary requests - clarity

2. Claim 1 of the main request is for "a method of managing a bid tracking database at a first server", but also defines the manner in which information is exchanged between the two other servers and the wireless mobile devices. It can be questioned whether protection is sought for all the claimed steps, or only those implemented on the first server. The claim is therefore not clear (Article 84 EPC). The same objection applies, for the same reasons, to the first to fourth auxiliary requests.

Fifth to ninth auxiliary requests - inventive step

3. The Board finds it expedient to start with the analysis of the ninth auxiliary request, which is the most specific.

4. Apart from a minor amendment introduced to overcome the Board's clarity objection, the subject matter of the ninth auxiliary request essentially corresponds to that of the refused fourth auxiliary request. According to the contested decision, the subject matter of that request was an obvious implementation, on notorious technical means, of non-technical steps for managing an auction, that is, an inherently business-related activity (see point 39 combined with points 14 to 18).

5. The Board arrives at the same conclusions in respect of claim 1 of the ninth auxiliary request. In the Board's view, the only technical features are the three network-connected computers, the user terminals as well as the establishment of wireless links between the servers and the terminals. These were indisputably known at the application's filing date. The remaining features define a non-technical scheme for exchanging, processing and storing bid-related information. They are not based on technical considerations and therefore, in accordance with the well-established "Comvik" approach, cannot support an inventive step (see decision T 641/00, Headnote, as well as the Case Law of the Boards of Appeal, 10th edition 2022, I.D. 9.1 and 9.2).

6. The appellant argued that the invention provided increased resilience and flexibility, since bid records and auction records were stored on servers different from the first server. The data to be stored was selected so that, in the case of a malfunction of one of the servers, essential data could be regenerated from the information available from the other two. The appellant also argued that the simultaneous transmission of the bid records to the second and third server increased the robustness of the system (particularly in the case of poor wireless connections) and its reliability by avoiding synchronisation errors.

6.1 The Board finds these arguments unconvincing. The definition of the pieces of information which are "essential" to an auction as well as the cognitive content of the information provided to each server are part of the underlying non-technical requirements. Moreover, as observed by the examining division, the application as a whole does not mention increasing resilience, ensuring robustness or preserving data integrity. Therefore, in the Board's view also the feature of simultaneously providing auction-related information in parallel to different servers does not have technical character, as it may be derived from merely administrative considerations. For example, different entities may be in charge of verifying the correctness of the auction results.

6.2 Transmitting data simultaneously over different channels and storing the data on different servers may indeed increase resilience and robustness by providing redundancy. However, for the reasons discussed above these are considered "bonus effects" following from the implementation of an essentially non-technical scheme.

6.3 The Board further observes that the use of redundancy in data transmission and storage is an obvious way of ensuring data integrity, and that achieving synchronisation by simultaneously transmitting the same information to both servers is self-evident. Hence, even if these features were considered to be technical, they would not render claim 1 inventive.

7. The appellant further argued that requesting bid records at periodic intervals reduced network traffic and the servers' processing load, and provided the advantage that the polling interval could be chosen so as to minimise the bandwidth requirements. Generating a list of item identifiers without duplicates further reduced network traffic requirements. Therefore, these features had a technical character.

7.1 The Board notes that the application does not deal with the problems of reducing bandwidth occupancy or managing computational resources. Therefore, in the context of the invention, requesting bid records and the respective auction records on a periodic basis (for example, once a week, see paragraph [0025]) is considered non-technical. Moreover, this feature does not necessarily reduce the overall network traffic or the system load, because data requests are transmitted to the second server even if no new bid records are available. The Board further observes that it is not apparent, neither from the application, nor from the appellant's arguments, which polling interval would minimise the bandwidth requirements (short of an infinite interval, that is, sending no requests at all).

7.2 The steps of generating a duplicate-free list of item identifiers and requesting the auction records corresponding to the items on the list implement the non-technical requirement of retrieving the auction records corresponding to the bids received in a given period. Any improvements in terms of reduced bandwidth requirements or reduced server load are not due to technical considerations, but are inherent in the efficiency of the implementing algorithm, which is not considered a technical effect (see for example T 1784/06, Reasons, point 3.1.2; T 42/10, Reasons, point 2.11; T 2418/12, Reasons, points 3.2 to 3.5). Therefore, these steps cannot support an inventive step.

8. It was further argued that providing the terminal identifiers only to the third server anonymised the bid, and that the system provided scalability, because auctions with a small number of bids could be hosted by the first server, while bigger auctions could be hosted by the third server. During oral proceedings the appellant also argued that omitting the terminal identifiers reduced the bandwidth requirements.

The Board finds also these arguments unconvincing, for the following reasons:

8.1 Anonymising the bids is not a technical problem, and the decision as to which server should receive the mobile identifiers is a non-technical one.

8.2 Claim 1 does not mention at all the possibility of hosting the auctions on different servers based on the number of bids. The alleged increase in scalability is therefore entirely speculative.

8.3 Reducing bandwidth occupancy by omitting part of the information to be transmitted (that is, the identifiers of the mobile devices) merely circumvents the problem, rather than solving it by technical means.

9. In the absence of any technical contribution going beyond the straightforward implementation of a non-technical scheme, the Board judges that claim 1 of the ninth auxiliary request lacks an inventive step (Article 56 EPC).

10. The same objections of lack of inventive step apply, a fortiori, to the fifth to eighth auxiliary requests, which are more general.

Order

For these reasons it is decided that:

The appeal is dismissed.