DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 04/07/2025 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1, 5, 8, 10-11, 14, 18 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over ZHAO et al., US-20260027991-A1 (hereinafter “ZHAO ‘991”) in view of Batie et al., US-20250018946-A1 (hereinafter “Batie ‘946”).
Per claim 1 (independent):
ZHAO ‘991 discloses: A method for providing service data relating to a vehicle by a key device, wherein the key device has a digital key for interacting with the vehicle, which is stored in a secure storage unit of the key device, the method comprising:
receiving service data via a wireless communication connection between the key device and the vehicle;
storing the service data in the secure storage unit; and
(FIGS. 1B and 1D, [0077], a flowchart of standard authentication; [0078], a mobile terminal (a key device) with a digital vehicle key may interact with a vehicle (the key device has a digital key for interacting with the vehicle) in the following step B1 to step B15; the vehicle and the mobile terminal may have the structure of the vehicle and the mobile terminal, respectively, in the TEE-based (according to [0059] and [0061], the TEE provides a secure area – a secure storage unit of the key device – within the mobile terminal, while the TA, executing in the TEE, realizes the construction and storage of key data) Bluetooth digital vehicle key system architecture shown in FIG. 1B. Standard authentication shown in FIG. 1D may be performed by, for example, the vehicle DK (Digital vehicle Key) authentication system in the vehicle; [0081], B2. The vehicle (the vehicle) sends a public key exchange request to the mobile terminal (the key device), and transmits a vehicle temporary public key and a vehicle ID (to the mobile terminal, that is, receiving service data via a wireless communication connection between the key device and the vehicle); FIG. 1A, [0064], The mobile terminal may interact with the vehicle via near field communication (NFC), Bluetooth (BLE), and ultrawideband (UWB) protocols, examples of a wireless communication connection; [0087], B8. If the verification of the vehicle authentication information signature is passed, the mobile terminal generates digital vehicle key authentication information including the digital vehicle key temporary public key (the digital key stored in the secure storage unit of the key device), the vehicle temporary public key and vehicle ID related information (i.e., the service data stored in the secure storage unit via “the digital vehicle key TA” of FIG. 1B). After that, in B8, using a digital vehicle key private key to sign the digital vehicle key authentication information).
ZHAO ‘991 does not disclose but Batie ‘946 discloses: providing the service data in response to a request from a vehicle application executed on the key device (FIG. 1A, [0053], The processor 113 (of the first vehicle 102 of FIG. 1A) may collect data from one or more sensors 115 of the first vehicle 102 and transmit the collected data to the mobile device 107 (the key device) over the network 104. Operating behavior data may include one or more of: vehicle telematics such as operating speed ... vehicle stored data associated with engine and transmission hours, maintenance schedules ... or vehicle settings; [0055], the mobile device 107 sends operating behavior data (providing the service data) for the first vehicle 102 over the network to the connected vehicle system 125; [0056], The connected vehicle system 125 includes a server 126 and a memory 128 ... The mobile device 107 may include a mobile application 127 (that is, responding to a request from a vehicle application executed on the key device) provided by and/or associated with the connected vehicle system 125).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified ZHAO ‘991 with the sending of operating behavior data transmitted from a vehicle to the connected vehicle system via the mobile device as taught by Batie ‘946 because the system would improve interoperability across different manufacturers’ connected vehicle platforms and enable a consistent user experience [0054]. Additionally, Batie ‘946 is analogous to the claimed invention because it teaches the mobile device 107 sends operating behavior data for the first vehicle 102 over the network to the connected vehicle system 125 [0055].
Per claim 5 (dependent on claim 1):
ZHAO ‘991 in view of Batie ‘946 discloses the elements detailed in the rejection of claim 1 above, incorporated herein by reference.
ZHAO ‘991 does not disclose but Batie ‘946 discloses: The method according to claim 1,
wherein the service data are made available to the vehicle application,
the method comprising causing the service data to be able to be transmitted to an external unit
(FIG. 1A, [0053], The processor 113 (of the first vehicle 102 of FIG. 1A) may collect data from one or more sensors 115 of the first vehicle 102 and transmit the collected data to the mobile device 107 over the network 104. Operating behavior data may include one or more of: vehicle telematics such as operating speed ... vehicle stored data associated with engine and transmission hours, maintenance schedules ... or vehicle settings; [0055], the mobile device 107 sends (transmits) operating behavior data (the service data) for the first vehicle 102 over the network to the connected vehicle system 125 (to an external unit); [0056], The connected vehicle system 125 includes a server 126 and a memory 128 ... The mobile device 107 may include a mobile application 127 (the vehicle application) provided by and/or associated with the connected vehicle system 125).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified ZHAO ‘991 with the sending of operating behavior data transmitted from a vehicle to the connected vehicle system via the mobile device as taught by Batie ‘946 because the system would improve interoperability across different manufacturers’ connected vehicle platforms and enable a consistent user experience [0054].
Per claim 8 (dependent on claim 1):
ZHAO ‘991 in view of Batie ‘946 discloses the elements detailed in the rejection of claim 1 above, incorporated herein by reference.
ZHAO ‘991 discloses: The method according to claim 1,
wherein the communication connection between the key device and the vehicle comprises a Bluetooth Low Energy (BLE) communication connection and/or a Near Field Communication (NFC) communication connection
(FIG. 1A, [0064], The mobile terminal (the key device) may interact with the vehicle (the vehicle) via near field communication (NFC), Bluetooth (BLE), and ultrawideband (UWB) protocols).
Per claim 10 (dependent on claim 1):
ZHAO ‘991 in view of Batie ‘946 discloses the elements detailed in the rejection of claim 1 above, incorporated herein by reference.
ZHAO ‘991 discloses: The method according to claim 1, comprising:
carrying out the method by a key applet of the secure storage unit.
(FIGS. 1B and 1D, [0077], a flowchart of standard authentication; [0078], a mobile terminal with a digital vehicle key may interact with a vehicle in the following step B1 to step B15; the vehicle and the mobile terminal may have the structure of the vehicle and the mobile terminal, respectively, in the TEE-based (according to [0059] and [0061], the TEE provides a secure area – the secure storage unit – within the mobile terminal, while the TA, i.e., a key applet, executing in the TEE, realizes the construction and storage of key data) Bluetooth digital vehicle key system architecture shown in FIG. 1B. Standard authentication shown in FIG. 1D may be performed by, for example, the vehicle DK authentication system in the vehicle).
Per claim 11 (dependent on claim 1):
ZHAO ‘991 in view of Batie ‘946 discloses the elements detailed in the rejection of claim 1 above, incorporated herein by reference.
ZHAO ‘991 discloses: The method according to claim 1, wherein the service data comprise:
a vehicle identification number;
a model and/or a model variant of the vehicle;
a date of manufacture and/or registration of the vehicle;
a color code of a color of the vehicle;
condition information relating to a condition of the vehicle comprising a mileage of the vehicle and/or a filling level of a fuel tank or a high-voltage store of the vehicle; and/or diagnostic information relating to one or more fault messages of the vehicle
(FIG. 1D, [0081], B2. The vehicle sends a public key exchange request to the mobile terminal, and transmits a vehicle temporary public key and a vehicle ID).
Per claim 14 (independent):
The limitations of the claim(s) correspond(s) to features of claim 1 and the claim(s) is/are rejected for the reasons detailed with respect to claim 1.
Per claim 18 (dependent on claim 14):
ZHAO ‘991 in view of Batie ‘946 discloses the elements detailed in the rejection of claim 14 above, incorporated herein by reference.
The limitations of the claim(s) correspond(s) to features of claim 5 and the claim(s) is/are rejected for the reasons detailed with respect to claim 5.
Per claim 20 (dependent on claim 14):
ZHAO ‘991 in view of Batie ‘946 discloses the elements detailed in the rejection of claim 14 above, incorporated herein by reference.
The limitations of the claim(s) correspond(s) to features of claim 8 and the claim(s) is/are rejected for the reasons detailed with respect to claim 8.
Claim(s) 2 and 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over ZHAO ‘991 in view of Batie ‘946 and HAN et al., US-20200005571-A1 (hereinafter “HAN ‘571”).
Per claim 2 (dependent on claim 1):
ZHAO ‘991 in view of Batie ‘946 discloses the elements detailed in the rejection of claim 1 above, incorporated herein by reference.
ZHAO ‘991 discloses: The method according to claim 1, comprising:
the digital key stored in the secure storage unit
(FIGS. 1B and 1D, [0078], the vehicle and the mobile terminal may have the structure of the vehicle and the mobile terminal, respectively, in the TEE-based (according to [0059] and [0061], the TEE provides a secure area – the secure storage unit – within the mobile terminal, while the TA, executing in the TEE, realizes the construction and storage of key data) Bluetooth digital vehicle key system architecture shown in FIG. 1B. Standard authentication shown in FIG. 1D may be performed by, for example, the vehicle DK (Digital vehicle Key) authentication system in the vehicle; [0087], B8. If the verification of the vehicle authentication information signature is passed, the mobile terminal generates digital vehicle key authentication information including the digital vehicle key temporary public key (the digital key stored in the secure storage unit), the vehicle temporary public key and vehicle ID related information. After that, in B8, using a digital vehicle key private key to sign the digital vehicle key authentication information).
ZHAO ‘991 in view of Batie ‘946 does not disclose but HAN ‘571 discloses: before receiving the service data:
establishing the communication connection between the key device and the vehicle; and
authenticating the key device at the vehicle via the digital key
(FIG. 3, [0040], authenticating a smart key; [0041], A vehicle 305 may perform a smart key authentication operation (authenticating the key device at the vehicle) ... When the smart key device 300 (the key device) and the vehicle 305 (the vehicle) are located within a given range (for establishing the communication connection between the key device and the vehicle; [0078]-[0079] discloses that the smart key includes a module for short-distance communication. Furthermore, the specification indicates that the vehicle and the user-carried smart key communicate with each other to determine whether the smart key is located within a predetermined distance of the vehicle), the smart key device may receive the authentication request and transmit an authentication response at step 313. The authentication response may include information on the smart key device 300, for example, user information or device ID information (i.e., the digital key); [0042], At step 315, the vehicle 305 may authenticate the smart key device 300 (authenticating the key device at the vehicle via the digital key) by identifying whether the smart key device is a registered valid key (via the digital key) and whether a relay attack is present; [0043], If the smart key device 300 has been validly authenticated (authentication has to be done successfully before receiving the service data), at step 317, the vehicle 305 may transmit an approach confirmation signal (Adv; the service data) to the smart key device 300).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified ZHAO ‘991 in view of Batie ‘946 with the authentication of the smart key device at the vehicle by determining whether the smart key device is a registered valid key prior to transmitting the Adv as taught by HAN ‘571 because the system would improve security by detecting relay attacks during smart-key authentication and allow vehicle control only for an authenticated key determined to be proximate to the vehicle. Additionally, HAN ‘571 is analogous to the claimed invention because it teaches FIG. 3 is a diagram showing a method of authenticating a smart key [0040].
Per claim 15 (dependent on claim 14):
ZHAO ‘991 in view of Batie ‘946 discloses the elements detailed in the rejection of claim 14 above, incorporated herein by reference.
The limitations of the claim(s) correspond(s) to features of claim 2 and the claim(s) is/are rejected for the reasons detailed with respect to claim 2.
Claim(s) 3 and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over ZHAO ‘991 in view of Batie ‘946 and Mathias et al., US-20200052905-A1 (hereinafter “Mathias ‘905”).
Per claim 3 (dependent on claim 1):
ZHAO ‘991 in view of Batie ‘946 discloses the elements detailed in the rejection of claim 1 above, incorporated herein by reference.
ZHAO ‘991 in view of Batie ‘946 does not disclose but Mathias ‘905 discloses: The method according to claim 1, wherein the service data are stored in a mailbox of the digital key (FIG. 2, [0036], the mobile device exchanging short-lived public key pairs with the system ... A secure circuit of the mobile device may also generate a public key pair to allow the system to authenticate the mobile device – the mobile device corresponds to the digital key; [0049], mobile device 130 further includes a secure enclave processor (SEP) 210; [0051], SEP 210 is isolated from the rest of the mobile device 130 except for a carefully controlled interface ... a secure mailbox mechanism ... external devices may transmit messages to an inbox ... Response messages (the service data) from the SEP processor 212 may be transmitted through an outbox (after being stored in a mailbox of the digital key) ... Other circuitry may not be able to access internal resources of SEP 210 other than via the mailbox mechanism).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified ZHAO ‘991 in view of Batie ‘946 with the transmission of response messages through an outbox via the secure enclave processor in the mobile device as taught by Mathias ‘905 because this would allow sensitive data to be exchanged over a secure channel with enhance protections against spoofing, tampering, and unauthorized disclosure [0031][0051]. Additionally, Mathias ‘905 is analogous to the claimed invention because it teaches including the mobile device exchanging short-lived public key pairs with the system and a processor of the mobile device generating a shared secret [0036].
Per claim 16 (dependent on claim 14):
ZHAO ‘991 in view of Batie ‘946 discloses the elements detailed in the rejection of claim 14 above, incorporated herein by reference.
The limitations of the claim(s) correspond(s) to features of claim 3 and the claim(s) is/are rejected for the reasons detailed with respect to claim 3.
Claim(s) 4, 9 and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over ZHAO ‘991 in view of Batie ‘946 and KWON et al., US-20230147516-A1 (hereinafter “KWON ‘516”).
Per claim 4 (dependent on claim 1):
ZHAO ‘991 in view of Batie ‘946 discloses the elements detailed in the rejection of claim 1 above, incorporated herein by reference.
ZHAO ‘991 in view of Batie ‘946 does not disclose but KWON ‘516 discloses: The method according to claim 1, comprising:
receiving a Message Authentication Code (MAC) and/or a signature for the service data; and
verifying integrity of the service data on a basis of the MAC and/or the signature and via the digital key
(FIG. 12, [0211], sharing a digital key; [0224], In operation 1223, the vehicle 201 may allow the control of the vehicle on the basis of the authentication of the information. (after receiving a signature) The vehicle 201 may signature-verify (verifying integrity of the service data) the second driver identification information (the service data) by the first digital key (via the digital key). When the second mobile identity document information and the second driver identification information are successfully authenticated, the vehicle 201 may allow the second electronic device 203 to control the vehicle).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified ZHAO ‘991 in view of Batie ‘946 with the signature-verification of driver identification information via the digital key as taught by KWON ‘516 because this would improve security by preventing unauthorized users from controlling the vehicle using a transferred or compromised digital key. Additionally, KWON ‘516 is analogous to the claimed invention because it teaches sharing a digital key for a vehicle between electronic devices [FIG. 12].
Per claim 9 (dependent on claim 1):
ZHAO ‘991 in view of Batie ‘946 discloses the elements detailed in the rejection of claim 1 above, incorporated herein by reference.
ZHAO ‘991 in view of Batie ‘946 does not disclose but KWON ‘516 discloses: The method according to claim 1,
wherein the digital key is configured in accordance with the Car Connectivity Consortium (CCC) key standard
(FIG. 2A, [0068], The owner of the vehicle 201 may possess a vehicle key (for example, a physical vehicle key) of the vehicle 201, get in the vehicle 201, and make a request for issuing a digital key ... A processor for issuing the digital key (the digital key) may, for example, follow the specification defined by car connectivity consortium (CCC; the Car Connectivity Consortium (CCC) key standard) as owner pairing).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified ZHAO ‘991 in view of Batie ‘946 with the issuance of the digital key based on the specification defined by car connectivity consortium as taught by KWON ‘516 because it would provide interoperability between the vehicle and different electronic devices and enable secure and standardized digital-key provisioning.
Per claim 17 (dependent on claim 14):
ZHAO ‘991 in view of Batie ‘946 discloses the elements detailed in the rejection of claim 14 above, incorporated herein by reference.
The limitations of the claim(s) correspond(s) to features of claim 4 and the claim(s) is/are rejected for the reasons detailed with respect to claim 4.
Claim(s) 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over ZHAO ‘991 in view of Batie ‘946 and Bart et al., US-20230325484 -A1 (hereinafter “Bart ‘484”).
Per claim 6 (dependent on claim 5):
ZHAO ‘991 in view of Batie ‘946 discloses the elements detailed in the rejection of claim 5 above, incorporated herein by reference.
ZHAO ‘991 does not disclose but Batie ‘946 discloses: The method according to claim 5,
wherein causing the service data to be able to be transmitted to an external unit comprises:
([0055], the mobile device 107 sends (transmits) operating behavior data (the service data) for the first vehicle 102 over the network to the connected vehicle system 125 (an external unit); [0056], The connected vehicle system 125 includes a server 126 and a memory 128 ... The mobile device 107 may include a mobile application 127 provided by and/or associated with the connected vehicle system 125).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified ZHAO ‘991 with the sending of operating behavior data transmitted from a vehicle to the connected vehicle system via the mobile device as taught by Batie ‘946 because the system would improve interoperability across different manufacturers’ connected vehicle platforms and enable a consistent user experience [0054].
ZHAO ‘991 in view of Batie ‘946 does not disclose but Bart ‘484 discloses: generating and displaying a machine-readable code representing the service data; and/or
causing the service data to be sent to the external unit via short-range communication
(FIG. 3, [0039], a process 300 for authentication and validation based on user credential and biometric data; [0039], a user providing 302 a code (e.g., as a QR code displayed at a smartphone, tablet, etc.; a machine-readable code representing the service data) at a user device regarding how (e.g., via Bluetooth, Wi-Fi, NFC, etc.; short-range communication) a client device should receive a user credential (e.g., an mID; the service data); [0042], Client device 102 reads 304 the code, connects to the user device (e.g., via Bluetooth, Wi-Fi, NFC, etc.) and receives 306 data regarding the mID (the service data to be sent to the external unit via the short-range communication, which is step 306 of FIG. 3). Validation system 104 (of FIG. 1; the external unit) then validates 308 the mID).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified ZHAO ‘991 in view of Batie ‘946 with the validation of user credential by initiating transferring them through a QR code based on short-range communication as taught by Bart ‘484 because the system would enable hands-free identity verification while reducing the need for manual credential handling. Additionally, Bart ‘484 is analogous to the claimed invention because it teaches reading of a code (e.g., a quick response (QR) code) on a mobile device and transfer of data to start the process of validation/authentication [0014].
Claim(s) 7 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over ZHAO ‘991 in view of Batie ‘946 and Reiter et al., US-20250315243-A1 (hereinafter “Reiter ‘243”).
Per claim 7 (dependent on claim 1):
ZHAO ‘991 in view of Batie ‘946 discloses the elements detailed in the rejection of claim 1 above, incorporated herein by reference.
ZHAO ‘991 in view of Batie ‘946 does not disclose but Reiter ‘243 discloses: The method according to claim 1,
wherein providing the service data comprises:
determining a signature of the service data via the digital key; and/or
verifying the service data via the signature
(FIG. 1, [0023], the vehicle 101 and/or the user 107 of the vehicle was recognized as a valid sender of vehicle field data 105; [0025], Checking the digital signatures of the vehicle 102 and/or of a user of the vehicle 103 may include querying a public key of the relevant signature 102, 103 in the common register 108. In some examples, a sender of the vehicle field data 105 (providing the service data) may be considered a valid sender if the digital signature 102, 103 can be verified – verifying the service data via the signature).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified ZHAO ‘991 in view of Batie ‘946 with the verification of vehicle field data by checking the digital signatures of the vehicle and the user of the vehicle as taught by Reiter ‘243 because the system would allow the origin of vehicle field data to be verified so that only trusted data sources are used for software updates of vehicles [0006][0051]. Additionally, Reiter ‘243 is analogous to the claimed invention because it teaches a trusted update of control software of a vehicle based on vehicle field data [ABSTRACT].
Per claim 19 (dependent on claim 14):
ZHAO ‘991 in view of Batie ‘946 discloses the elements detailed in the rejection of claim 14 above, incorporated herein by reference.
The limitations of the claim(s) correspond(s) to features of claim 7 and the claim(s) is/are rejected for the reasons detailed with respect to claim 7.
Claim(s) 12 is/are rejected under 35 U.S.C. 103 as being unpatentable over ZHAO ‘991 in view of HAN ‘571.
Per claim 12 (independent):
ZHAO ‘991 discloses: A method for providing service data relating to a vehicle on a key device, wherein the key device has a digital key for interacting with the vehicle, which is stored in a secure storage unit of the key device, the method comprising:
sending service data to the secure storage unit of the key device via the wireless communication connection between the key device and the vehicle
(FIG. 1D, [0077], a flowchart of standard authentication; [0078], a mobile terminal (a key device) with a digital vehicle key may interact with a vehicle (the key device has a digital key for interacting with the vehicle) in the following step B1 to step B15; the vehicle and the mobile terminal may have the structure of the vehicle and the mobile terminal, respectively, in the TEE-based (according to [0059] and [0061], the TEE provides a secure area – a secure storage unit of the key device – within the mobile terminal, while the TA, executing in the TEE, realizes the construction and storage of key data) Bluetooth digital vehicle key system architecture shown in FIG. 1B. Standard authentication shown in FIG. 1D may be performed by, for example, the vehicle DK authentication system in the vehicle; [0081], B2. The vehicle sends a public key exchange request to the mobile terminal (the key device), and transmits a vehicle temporary public key and a vehicle ID (sending service data to the secure storage unit of the key device via the wireless communication connection between the key device and the vehicle); FIG. 1A, [0064], The mobile terminal may interact with the vehicle via near field communication (NFC), Bluetooth (BLE), and ultrawideband (UWB) protocols, examples of a wireless communication connection; [0087], B8. If the verification of the vehicle authentication information signature is passed, the mobile terminal generates digital vehicle key authentication information including the digital vehicle key temporary public key (the digital key stored in the secure storage unit of the key device), the vehicle temporary public key and vehicle ID related information (i.e., the service data sent to the secure storage unit via “the digital vehicle key TA” of FIG. 1B). After that, in B8, using a digital vehicle key private key to sign the digital vehicle key authentication information)
ZHAO ‘991 does not disclose but HAN ‘571 discloses: authenticating the key device via the digital key via a wireless communication connection between the key device and the vehicle; and
in response to the authentication, sending service data to the key device
(FIG. 3, [0040], authenticating a smart key; [0041], A vehicle 305 may perform a smart key authentication operation (authenticating the key device) ... When the smart key device 300 (the key device) and the vehicle 305 (the vehicle) are located within a given range (for establishing a wireless communication connection between the key device and the vehicle; [0078]-[0079] discloses that the smart key includes a module for short-distance communication. Furthermore, the specification indicates that the vehicle and the user-carried smart key communicate with each other to determine whether the smart key is located within a predetermined distance of the vehicle), the smart key device may receive the authentication request and transmit an authentication response at step 313. The authentication response may include information on the smart key device 300, for example, user information or device ID information (i.e., the digital key); [0042], At step 315, the vehicle 305 may authenticate the smart key device 300 (authenticating the key device via the digital key) by identifying whether the smart key device is a registered valid key (via the digital key) and whether a relay attack is present; [0043], If the smart key device 300 has been validly authenticated (in response to the authentication), at step 317, the vehicle 305 may transmit an approach confirmation signal (Adv; service data) to the smart key device 300 – sending the service data to the key device).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified ZHAO ‘991 in view of Batie ‘946 with the authentication of the smart key device at the vehicle by determining whether the smart key device is a registered valid key prior to transmitting the Adv as taught by HAN ‘571 because the system would improve security by detecting relay attacks during smart-key authentication and allow vehicle control only for an authenticated key determined to be proximate to the vehicle.
Claim(s) 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over ZHAO ‘991 in view of HAN ‘571 and KWON ‘516 and HOMMA et al., US-20250206262-A1 (hereinafter “HOMMA ‘262”).
Per claim 13 (dependent on claim 12):
ZHAO ‘991 in view of HAN ‘571 discloses the elements detailed in the rejection of claim 12 above, incorporated herein by reference.
ZHAO ‘991 in view of HAN ‘571 does not disclose but KWON ‘516 discloses: generating a Message Authentication Code (MAC) and/or a signature for the service data via the digital key (FIG. 12, [0211], sharing a digital key; [0224], In operation 1223, the vehicle 201 may allow the control of the vehicle on the basis of the authentication of the information. The vehicle 201 may signature-verify (after generating a signature) the second driver identification information (the service data) by the first digital key (via the digital key). When the second mobile identity document information and the second driver identification information are successfully authenticated, the vehicle 201 may allow the second electronic device 203 to control the vehicle).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified ZHAO ‘991 in view of HAN ‘571 with the signature-verification of driver identification information via the digital key as taught by KWON ‘516 because this would improve security by preventing unauthorized users from controlling the vehicle using a transferred or compromised digital key.
ZHAO ‘991 in view of HAN ‘571 and KWON ‘516 does not disclose but HOMMA ‘262 discloses: sending the MAC and/or the signature to the key device via the wireless communication connection between the key device and the vehicle (FIG. 2, [0031], the vehicle 10 generates an electronic signature SIG2 ... encrypts the hash value with the public temporary key PK1 received from the mobile information terminal 20 to generate the electronic signature SIG2; [0032], the vehicle 10 (the vehicle) imparts the electronic signature SIG2 to the public key PK4 and performs transmission thereof to the mobile information terminal 20 (sending the MAC and/or the signature to the key device); [0033],the mobile information terminal 20 decrypts the electronic signature SIG2 received from the vehicle 10; [0028], pairing between the mobile information terminal 20 (the key device) and the vehicle 10 (the vehicle) is performed using any one of BLE communication, UWB communication, and NFC (S10) , that is, the wireless communication connection between the key device and the vehicle).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified ZHAO ‘991 in view of HAN ‘571 and KWON ‘516 with the sending of the electronic signature to the mobile information terminal from the vehicle via wireless communication connection as taught by HOMMA ‘262 because it would improve the reliability of digital key registration and facilitates diagnosis failures. Additionally, HOMMA ‘262 is analogous to the claimed invention because it teaches the registration processing of the digital key [0027].
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Matsushita et al., US-20240227730-A1 – by registering the guest key through BLE communication between the vehicle and the guest terminal, the system eliminates the need for the owner terminal to be present for guest key activation. This reduces the owner’s burden while enabling efficient and flexible activation of digital keys when the vehicle has no network connectivity.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SANGSEOK PARK whose telephone number is (571)272-4332. The examiner can normally be reached Monday-Friday 7:30-5:30 and Alternate Fridays 9:00 am-5:00 pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, PHILIP CHEA can be reached at (571)272-3951. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/SANGSEOK PARK/Primary Examiner, Art Unit 2499
Prosecution Insights