This decision relates to a European patent application concerning a method, system and apparatus for managing a bid tracking database. Here are the practical takeaways from the decision T 3005/18 (Bid tracking database/BLACKBERRY) of 28.10.2022 of Technical Board of Appeal 3.5.01:
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. 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.
Figure 1 of EP2325796
Here is how the invention was defined in claim 1:
Claim 1 (main request)
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).
Is it patentable?
According to the decision from the examining division, 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.
The Board finds it expedient to start with the analysis of the ninth auxiliary request, which is the most specific. 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.
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 ) 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).
Since none of the auxiliary requests could overcome the objection of lack of inventive step, the application was finally refused.
You can read the whole decision here: T 3005/18 (Bid tracking database/BLACKBERRY) of 28.10.2022 of Technical Board of Appeal 3.5.01.