T 0490/21 (Identifying a rental car user/SAPFI KAPITAL MANAGEMENT) of 15.10.2024

Summary of Facts and Submissions

I. The appeal is against the examining division's decision to refuse European patent application No. 16701035.4 for lack of inventive step (Article 56 EPC).

II. The examining division held that the technical features in claim 1 of both the main and first auxiliary requests were typical to known connected cars and were also disclosed in D4 (US 2015/019304 A1). In their view, the remaining features pertained to the obvious implementation of non-technical administrative aspects of car rental or sharing.

III. In the statement setting out the grounds of appeal, the appellant requested that the decision under appeal be set aside and that a patent be granted on the basis of one of the refused requests. They argued that the key idea of the invention was the car's role as a communication hub, which was neither a business requirement nor obvious from the prior art.

IV. In the communication accompanying the summons to oral proceedings, the Board tended to agree with the appellant that using the car as an intermediary for communications between the phone and the server was part of the system's technical infrastructure. However, the Board was still of the opinion that claim 1 lacked an inventive step based on either D4 or D5 (US 8768565 B2), a document cited in the application.

V. By letter of 16 September 2024, the appellant filed auxiliary requests 2 and 3, along with arguments in support of inventive step.

VI. During the oral proceedings on 15 October 2024, held by videoconference, the appellant filed an additional auxiliary request 1a.

The appellant's final requests were to set aside the appealed decision and grant a patent based on the refused main request or, alternatively, based on auxiliary request 1a filed during the oral proceedings, refused auxiliary request 1, or auxiliary requests 2 or 3 filed with the letter of 16 September 2024.

VII. Claim 1 of the main request reads (feature labelling as in the grounds of appeal):

(1) System (1, 11, 111) for identifying a user of one of a plurality of vehicles (20) of a rental car or car sharing service, comprising:

(2.1) means (10, 101) for determining user identification information (10, 101) comprising means (101) for sensing a biometrical value of the user, wherein the means (101) for sensing a biometrical value of the user comprises at least one fingerprint sensor;

(2.2) said fingerprint sensor being implemented in a terminal device (100), wherein said terminal device (100) is a smartphone,

(2.3) wherein said terminal device (100) communicates with a selected one of the plurality of vehicles (20) over a bi-directional terminal communication path (106, 107, 108) which is implemented by a wireless connection,

(2.4) wherein said-bidirectional terminal communication path (106, 107, 108) is established by a specifically tailored smart phone application that establishes a dedicated data connection between a storage and processing module (202) in the vehicle and the smart phone;

(3.1) a central identification database (30, 310) being communicatively coupled to said storage and processing module (202) in said vehicle,

(3.2) wherein the central identification database (30, 310) communicates with said plurality of vehicles (20) over a first plurality of bi-directional communication paths (206, 207),

(3.3) said central identification database (30, 310) includes means (301) for comparing said user identification information to first entries in said central identification database (30, 310) and for determining a first correspondence between said user identification information and one of the first entries in said central identification database (30, 310);

(3.4) means (204) for enabling, upon determining said first correspondence, at least one operating function of said vehicle (20);

(4.1) means (401) for comparing said user identification information to permission entries of a central permission database (40) and for determining a third correspondence between said user identification information and one of the permission entries in the central permission database (40);

(4.2) said central permission database (40) communicates directly with said plurality of vehicles (20) over a second plurality of bi-directional communication paths (211, 212),

(5) means (205) for disabling, if said third correspondence cannot be determined, the at least one enabled operating function of the vehicle (20), by communicating the negative result to vehicle (20),

(6) such that the smart phone (100) communicates only with vehicle (20) by means of the smart phone application and any further communication is performed by the vehicle (20) and routed from the smart phone (100) through the vehicle (20) to central identification database (310) and central permission database (40).

VIII. Claim 1 of auxiliary request 1 reads:

System (1, 11, 111) for identifying a user of a vehicle (20) of a rental car or car sharing service, comprising:

means (10, 101) for determining user identification information (10, 101);

means (301) for comparing said user identification information to first entries in an identification database (30, 310) and for determining a first correspondence between said user identification information and one of the first entries in said identification database (30, 310);

means (204) for enabling, upon determining said first correspondence, at least one operating function of said vehicle;

characterized in that

said means (10, 101) for determining user identification information comprise means (101) for sensing a biometrical value of the user, wherein

the means (101) for sensing a biometrical value of the user comprise at least one fingerprint sensor, wherein

the at least one fingerprint sensor is implemented in a terminal device (100) and said terminal device (100) communicates with a selected one of the plurality of vehicles (20) over a respective bi-directional terminal communication path (106, 107, 108),

wherein said terminal device (100) is a smart phone,

wherein said terminal device (100) further comprises at least one of the means (10, 101) for determining user identification information, the means (301) for comparing the user identification information to first entries in an identification database (30, 310) and/or the means (301) for determining a first correspondence between the user identification information and one of the first entries in said identification database (30, 310),

wherein said bi-directional terminal communication path (106, 107, 108) is implemented by at least one of a wireless connection or a cable connection,

wherein said-bidirectional [sic] terminal communication path (106, 107, 108) is provided by a specifically tailored smart phone application that establishes a connection between the vehicle and the smart phone;

the system (1, 11, 111) further comprises

means (401) for comparing said user identification information to permission entries of a permission database (40) and for determining a third correspondence between said user identification information and one of the permission entries in the permission database (40); and

means (205) for disabling, if said third correspondence cannot be determined, the at least one enabled operating function of the vehicle (20),

wherein said permission database (40) is a central permission database (40) and said central permission database (40) communicates directly with said plurality of vehicles (20) over a second plurality of bi-directional communication paths (211, 212).

IX. Claim 1 of auxiliary request 2 adds to the end of feature (6):

"and any communication coming from each of said central identification database (30, 310) and central permission database (40) is routed through vehicle (20) to smart phone (100)."

X. In claim 1 of auxiliary request 1a, feature (1) of claim 1 of auxiliary request 2 is replaced with:

"System (1, 11, 111) for identifying a user of one of a plurality of vehicles (20) of a rental car or car sharing service, for enabling or disabling at least one operating function of said vehicle (20) comprising:"

XI. Claim 1 of auxiliary request 3 adds to the end of feature (2.4) in claim 1 of auxiliary request 2:

"wherein the bi-directional communication path (106, 107, 108) is an infrared connection or a Bluetooth connection."

Reasons for the Decision

1. The invention

The invention concerns identifying a user wishing to rent a vehicle and granting access to this vehicle (published application, first paragraph).

Looking at Figure 5, fingerprint sensor 101 of smartphone 100 captures the fingerprint of a user who wishes to rent car 20. The smartphone then sends the fingerprint data to the car, which forwards them to a central identification database 30 to match them against the data of registered users. A successful identification is communicated back to the car, which then enables the user to access it. The car also communicates with a central permission database 40 to verify certain user permissions, such as a valid driver's license. If the required permissions are missing, access to the car is disabled (page 19, line 18 to page 20, line 2).

2. Auxiliary requests 1a, 2, and 3 - admittance

The Board admits auxiliary requests 1a, 2, and 3 into the appeal proceedings, as they were filed in response to the Board's inventive step objections in view of D5, which were raised for the first time on appeal. In the Board's judgement these are cogent reasons that justify the exceptional circumstances required by Article 13(2) RPBA.

3. Auxiliary request 1a - inventive step

3.1 The Board finds it convenient to analyse claim 1 of the more specific auxiliary request 1a first before considering the main request.

3.2 The Board judges that this claim lacks an inventive step over D5.

3.3 D5 describes a system for accessing and managing rental vehicles (abstract). Looking at Figure 4, an onboard control module of car 303 communicates with an app on phone 162 and remote server(s) 970 of the car rental company (column 7, first paragraph). This setup corresponds to features (2.5), (3.1), (3.2), and (4.2) of claim 1.

As in the claimed invention, the user is identified remotely before being granted access to the vehicle. In particular, the server communicates with the phone to obtain the user's identity, verifies it against registered users, and checks for a valid reservation and payment (column 16, lines 20 to 25 and 56 to 60). Upon successful identification and verification, the server sends a command to unlock the car doors, enabling access to the vehicle (column 7, third paragraph; column 15, second paragraph). At the end of the reservation, the server disables the vehicle's operation (column 17, lines 42 to 48). These events correspond to features (3.3), (4.1), and (5) of claim 1.

3.4 D5 outlines two embodiments for the phone-server communications. In the first, the phone obtains a car identifier (e.g. by reading a QR code or from the control module via NFC) and sends it, along with the user identifier, to the server via a cellular network or the Internet (Figure 4, column 7, third paragraph). In the second, the car's control module retrieves the user identifier from the phone using RFID and sends it to the server (column 15, third paragraph).

The Board assesses inventive step starting from this latter embodiment. Although the embodiment has no corresponding figure, it is clear from the description in column 15 that it requires replacing the route from the vehicle to the server through the phone in Figure 4 with a route from the phone to the server through the vehicle. This communication path corresponds to the first part of feature (6), where the car is used to route communications from the phone to the server.

3.5 Claim 1 differs in that:

(i) The phone includes a fingerprint sensor and the user's fingerprint is used for their identification (features (2.1) and (2.2)).

(ii) The wireless communication path between the phone and the vehicle is bi-directional (features (2.3) and (2.4)).

(iii) The claimed system is suitable for routing communications from the server to the phone through the vehicle (second part of feature (6)).

3.6 As explained in the application (see page 3, first paragraph and page 5, fourth paragraph), using fingerprint data allows for more reliable user identification. This is because biometric identifiers are unique, inherently linked to an individual and difficult to forge. In contrast, D5 identifies the user based on their phone number or mobile account (column 16, lines 52 to 54), which are more prone to misuse.

The Board is of the opinion that the skilled person, faced with the problem of improving the reliability of user identification, would have considered using biometric information, particularly fingerprints, as an obvious option (e.g. T 1314/20 - Biometric transaction authentication using mobile devices/CHIPTEC, points 14, 15).

3.7 Fingerprint identification requires suitable means for capturing and transmitting the user's fingerprint to the server.

Since fingerprint sensors were standard smartphone features at the application's priority date (2015), the skilled person would have chosen a smartphone with such capabilities as a matter of routine design, thus arriving at feature (i) in an obvious manner.

Furthermore, the skilled person would have recognised that the RFID communication between the phone and the vehicle in D5 has limited data capacity, making it unsuitable for transmitting fingerprint data. To remedy this, they would have replaced the RFID with more appropriate local communication means. Given that D5 explicitly suggests NFC as an alternative to RFID (see e.g., column 6, first paragraph), it would have been an obvious choice which the skilled reader of D5 would have contemplated for the second embodiment using the car as a communication hub (column 15, third paragraph). As NFC is known to enable bi-directional communication, the person skilled in the art would have arrived at feature (ii) without any inventive effort.

This modified system would feature two bi-directional communication paths: one between the phone and the vehicle and another between the vehicle and the server. In this way, the phone and the server can communicate in both directions via the vehicle, as required by feature (iii).

Hence, the skilled person, aiming to improve the reliability of user identification in D5, would have arrived at the subject-matter of claim 1 in an obvious manner.

3.8 The appellant argued that in the second embodiment of D5, the car only acted as an intermediary for some communications, specifically those related to the car and user identification. Other information, such as reservation confirmations and bills, was still sent directly from the server to the phone via cellular communication or the Internet, without involving the vehicle. Although NFC supported bi-directional communication, the path from the server to the phone through the vehicle was never used. In contrast, feature (6) required that all communications between the phone and the server were routed exclusively through the vehicle. The appellant argued that this exclusive routing improved the reliability and security of the communication while reducing network congestion.

3.9 The Board does not find these arguments convincing.

3.9.1 Firstly, the Board considers that according to the wording of claim 1 the communications between the phone and server mentioned in feature (6) are limited to those concerning the identification of the user and the vehicle's enablement/disablement. This is indicated in the preamble ("[s]ystem for identifying a user ..., for enabling or disabling at least one operating function of said vehicle") and implied by the preceding claim features, which relate only to these activities. Interpreting feature (6) as encompassing all types of communication would also be counterintuitive, since activities like vehicle reservation and billing may occur outside the rental period, when the smartphone is not in the vicinity of the vehicle and cannot use it as a communication hub.

Therefore, it is irrelevant that D5 discloses a direct communication in some cases, as these cases do not fall within the scope of claim 1.

3.9.2 Furthermore, the Board notes that feature (6) requires that the phone communicates only with the vehicle and that other communications to or from the server are routed through the vehicle. This feature thus merely describes how the system, as defined by the preceding features, is to be used. According to the jurisprudence of the Boards of Appeal, an indicated use only limits a claimed system insofar as it is suitable for that use. Consequently, a specific use cannot be used to distinguish a claimed system from another, structurally identical system which is also suitable for that use, even if the specific use itself is new and inventive (e.g., Case Law of the Boards of Appeal, 10th edition, I.C.8.1.5).

This means that the system in claim 1 is indistinguishable from the system in D5 when adapted to use NFC for communication between the phone and the vehicle, as this adaptation makes it suitable for routing all relevant communications between the phone and the server through the vehicle. Any advantages related to the reliability and security of the communication, or the network usage, if indeed achieved, would be inherent to this modified system.

3.10 For the reasons set out above, the Board judges that claim 1 of auxiliary request 1a does not involve an inventive step (Article 56 EPC).

4. Main request - inventive step

Since claim 1 of the main request is broader than claim 1 of auxiliary request 1a, it lacks an inventive step (Article 56 EPC) for the same reasons.

5. Auxiliary requests 1 to 3 - inventive step

5.1 Claim 1 of auxiliary request 1 rearranges the features of claim 1 of the main request but is otherwise identical in substance. Therefore, it lacks an inventive step (Article 56 EPC) for the same reasons.

5.2 Claim 1 of auxiliary request 2 is broader than that of auxiliary request 1a. Hence, it does not involve an inventive step (Article 56 EPC) for the same reasons.

5.3 Claim 1 of auxiliary request 3 adds to claim 1 of auxiliary request 2 that the bi-directional communication path between the smartphone and the vehicle is an infrared or Bluetooth connection.

Since the infrared and Bluetooth protocols were generally known at the application's priority date, the Board considers that replacing the RFID/NFC communication in D5 with either option would have been within the normal competence of the person skilled in the art. Hence, claim 1 does not involve an inventive step (Article 56 EPC).

Order

For these reasons it is decided that:

The appeal is dismissed.