T 2137/21 03-04-2025

1. The invention

1.1 Carpooling should be made easier.

1.2 To this end, users' driving habits are analysed, matches are detected and suggestions for carpooling are made. Only when a habit value, which indicates the frequency with which a particular route is travelled, exceeds a certain threshold, a potential driver is offered to a particular passenger who is considered suitable for car sharing (main request). If no driver is found with the specified threshold, the habit value threshold is lowered (auxiliary request).

2. Main Request - inventive step

2.1 Technicality - closest prior art

The board agrees with the reasoning of the examining division regarding the technicality of the claimed subject-matter (see point 1.2 of the reasons of the impugned decision). For the sake of argument, and in order to limit the discussions on the technical character of the claimed features, the board uses D1 as starting point for the skilled person (closest prior art). The appellant also argues with D1 as the closest prior art. However, contrary to the appellant's arguments, the board concludes that D1 discloses most of features (A) to (N):

2.2 Disclosure of D1

2.2.1 D1 discloses tracking/tracing of driving habits, as well as a statistical analysis of driving habits. Trips are recorded in terms of starting point and end point (HOME, WORK, GYM, PUB, see figures 6, 7 and 12) as well as timing. Statistical analyses of the trips and the users are carried out, as explained further below.

FORMULA/TABLE/GRAPHIC

FORMULA/TABLE/GRAPHIC

D1

2.2.2 Driving patterns are referred to as "words" or "topics". Time-slots of 60 min are used for classifying the events (see section 3.3). A "routine labelling" algorithm evaluates the driver habits as a periodic routine (see section 3.5). Therefore, the approach in D1 is based on the idea that words comparing with high probability (P) are those best describing the topic. For example, only when a topic reaches a certain probability (e.g. P = 90%) is it considered sufficiently regular to qualify as a routine commuting habit (section 3.6: "We compute the number of topics composing at least 90% of the probability mass of each day in the study").

2.2.3 Therefore, the probability P can be considered a "habit value". The example value of P = 90% can be considered a threshold value for the habit value. Other example habit values indicated in D1 are "P > 50%" and "P > 10%" (see sections 3.6 and 4.1).

2.2.4 A filtering is applied in order to identify the most active and probable users (see section 4.1, were it is also disclosed that events with low probability [P < 0,1] are not taken into account). The results of the trip analyses are shown in figure 10 of D1:

FORMULA/TABLE/GRAPHIC

D1

2.2.5 Based on this data, a matching is determined (see section 4). An app/web-interface was developed that suggests car pooling for driver B and driver C (see figure 12 and section 4.2). The app proposes carpooling for specific week-days (Mondays) at specific times (8:00/9:00) for specific routes (Turin - Milano, with specific GPS coordinates).

2.2.6 The board accepts that D1 does not distinguish between driver and passenger during tracking/tracing of driving habits.

2.2.7 Reference is made to the appellant's arguments summarised in section VI.

ad (b)

2.2.8 The appellant argued that the present application took into account a variety of different routes from one point (X) to another point (Y), as long as the starting point (X) and the end point (Y) were the same. These route variants were grouped together as one trip. This was not disclosed in D1.

2.2.9 However, the board is of the opinion that the same happens in D1. In D1, various regularly visited points are determined, such as WORK, HOME, PUB, GYM (see figures 7 and 10). It is not essential which route is travelled between the points, but only how regularly one travels from point (X) to point (Y) (see figures 6, 8C and 7 of D1). The claim wording of claim 1 is silent about more details of the tracing/tracking method in the present application. Consequently, the board concludes that D1 discloses features (B) and (C).

ad (c):

2.2.10 The appellant argued that in the method described in D1 filtering by habit value took place before the matching step. Consequently, feature (J) was not disclosed in D1 in accordance with the requirement of "searching ... trips ... which have habit values above a first threshold", which means that the thresholding must take place during the searching/filtering.

2.2.11 However, the board is of the opinion that the condition in feature (J) is also fulfilled if the sorting out of trips with a habit value below a threshold already takes place before searching for certain riding requirements. If feature (J) had been explicitly worded to indicate that the filtering takes place during the search, then D1 would not have disclosed feature (J). Since this is not the case, the board concludes that D1 discloses features (F) and (J).

ad (d)

2.2.12 The board agrees with the appellant that D1 only partially discloses feature (G), namely that D1 does not unambiguously disclose that, when a trip is analysed, it is examined and stored whether the user travelled the route as a driver or as a passenger.

2.3 Disclosure of D1 with respect to the claim wording

2.3.1 Therefore, D1 discloses (wording of claim 1, references to D1):

(A) a computer implemented method for recommending car resources for a user as a passenger (section 4.2) according to mobility habits for the user, comprising:

(B) acquiring (figures 1 to 7) mobility habit data for users generated by: extracting (figure 7) a trip including a start ("HOME") and a destination ("WORK") from location data of the user,

(C) wherein paths ("HOME-WORK-GYM-WORK" with its legs "HOME-WORK", "WORK-GYM", "GYM-WORK") with the same start and the same destination are clustered into one trip (figures 6, 7, 8, 10, 12);

(D) generating (figure 6) time information corresponding to the trip, according to time data corresponding to the paths clustered into the trip (slots of 60 minutes, section 3.3),

(E) wherein the time information includes a range of departure time (slots of 60 minutes, section 3.3); and

(F) calculating (figures 6 and 8) a frequency of occurrences for one trip within a predetermined time period as a habit value (P) of the trip for the user,

(G) wherein the trip including the start ("HOME") and the destination ("WORK"), the time information corresponding to the trip (time slots), the habit value of the trip (P), and transport modality information indicating the user as a driver [deleted: or a passenger] are used together as the mobility habit data for the user;

(H) receiving (the passenger queries with a "ride sharing" request, section 4.2) a riding requirement from the user as the passenger,

(I) wherein the riding requirement includes a start (GPS data of "HOME"), a destination (GPS of "WORK") and a departure time (time slot, "8:00", "9:00", section 4.2);

(J) searching (section 4.2), from mobility habit data for users as a driver, trips which match the riding requirement and have habit values ("topics" having at least P = 90% probability in section 3.6 or P > 10% in section 4.1, matching algorithm in section 4) above a first threshold (P > 90%) as target trips, according to the received riding requirement;

(M) sending (email to the driver, section 4.2) the riding requirement to users as the driver related to the target trips; and

(N) recommending the users as the driver to the user as the passenger after confirmation information ("on acceptance" in section 4.2) is received from the users as the driver.

2.4 Difference

D1 therefore fails only to disclose a part of feature (G) of present claim 1, namely "indicating the user as a driver or a passenger".

2.5 Technical effect

2.5.1 Assuming, for the sake of argument, that this difference achieves a technical effect, although the board doubts that this is the case (see also the reasoning in the impugned decision, section 1.2.1.1, in particular "Re I"), such an effect could be identified in that when searching for a suitable driver for a passenger, only persons who regularly undertake a desired journey as a driver themselves are suggested, so that incorrect matches can be excluded and the allocation of a carpooling becomes more efficient.

2.5.2 This means that less data has to be sent over the data network from the outset and the load on the data network is reduced.

2.6 Technical problem to be solved

2.6.1 Like the examining division, the board regards the above effect as a consequence of a boundary condition ("constraint") for a purely organisational and administrative task (see T 641/00, catchword, and G 1/19, grounds 31 to 34), since this procedural step in particular is part of a purely organisational scheme, unlike, for example, an algorithm that determines a "routine" (e.g. "routine labelling" and "routine identification" in sections 3.5 and 3.6 of D1). In this regard, reference is made in particular to the arguments set out in sections 2.7.4 and 2.7.5, below.

2.6.2 In terms of T 641/00 and G 1/19, the identified non-technical constraint ("record driver and passenger data") would be given to the skilled person (a programmer) for implementation, and any technical problem apparent would relate to the implementation in the D1 system. Therefore, the technical problem could be formulated to register whether the recorded journeys were made as driver or passenger, i.e. in D1 journeys that are not carried out as a driver are labelled as such (i.e. at least implicitly as "passenger").

2.7 Obviousness of the solution

2.7.1 The board considers that the solution given is obvious and self-evident alone from the problem to be solved. In the board's opinion, the skilled person would add the use of relevant labelling ("driver", "passenger") of the logged trips in the system of D1 (e.g. as an additional option in the app) only by appropriate programming, using only common general knowledge:

2.7.2 In general, it is obvious to obtain and record a specific parameter in a database in order to be able to apply a filter later that filters out unnecessary data records of the specific parameter. If the skilled person is tasked with minimising the network load, they will always try to structure the searched data sets so that a targeted and reduced search of data sets is possible. It is a basic principle of databases that, if possible, all parameters that can be captured should be stored in separate, indexed data fields so that targeted and unambiguous search queries can be carried out as quickly and easily as possible.

2.7.3 Consequently, if the information is available as to whether a route was travelled by a user as a driver or as a passenger, it is immediately obvious to a skilled person to write this information in a separate data field and to take it into account when conducting a search.

2.7.4 However, the present patent application does not provide any information as to how it is determined whether a car user is driving or is a passenger. During the oral proceedings, the appellant stated that at the time of the oral proceedings, this complex problem was solved by registering biometric data of possible users and by AI-supported recognition using cameras to determine who was using the vehicle and in what role, as driver or passenger. However, this procedure is not even hinted at in the application, and it is questionable whether such a procedure was even possible at the time of filing. In this respect, the question arises as to whether the skilled person could even carry out this feature (feature (G)) at the time of the invention (Article 83 EPC). On the other hand, other simpler solutions would also be possible, namely that the user of a car indicates his identity and role (driver/passenger) by filling out an electronic (or "paper") questionnaire. This could also be done using an app on a phone (as used in D1). But the application is completely silent on this point as well.

2.7.5 Since there are no technical details about the technical realisation of the feature (G), this feature can be seen as a purely administrative act, namely as including the possibility of filling out a "questionnaire" and storing the answers in a database. Consequently, such an administrative feature has no technical effect and can be included in the problem to be solved as a constraint, as described above, whose solution is then intrinsically obvious.

2.7.6 Furthermore, such a "questionnaire" can also be integrated into the telephone app described in D1 without any technical difficulties (see, for example, figure 8 of D1).

2.7.7 Therefore, if the skilled person were entrusted with the problem of reducing the communication load, they would try to optimise the database structure to such an extent that more specifically targeted queries are possible. Detecting and storing the user role (driver/passenger) in a separate data field in the app in D1 is therefore considered as straightforward and obvious.

2.8 Consequently, the subject-matter of the main request lacks inventive step (Article 56 EPC).

3. Auxiliary request - inventive step

3.1 Amendments

The auxiliary request adds that if no suitable driver is found for a first threshold, a window is considered where the habit value is below the first threshold but above a second (lower) threshold (features (K) and (L)).

3.2 Obviousness

3.2.1 The board considers that it to be a general common practice, when searching for a match, that the search thresholds (search range) are varied, if necessary extended to a wider range if the searching with the initial range does not provide a match. D1 teaches different thresholds, e.g. P > 90%, P > 50% and P > 10%(see above).

3.2.2 The board considers that it would be obvious for the skilled person, also in view of the teachings of D1, to extend the range P > 90% by the range P > 50%, if still no confirmation of a driver (i.e. a match) is received.

3.3 Therefore, the subject-matter of claim 1 of the auxiliary request does not involve an inventive step within the meaning of Article 56 EPC either.

4. Summary

Summarising, the board agrees with the Examining Division that the main request and the auxiliary request do not meet the requirements of Article 56 EPC. Since none of the requests on file meets the requirements of the EPC, the Examining Division's decision refusing the application is confirmed. Consequently the appeal has to be dismissed (Articles 97(2) EPC and 111(1) EPC).