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 .
DETAILED ACTION
Status of Claims
Claims 1-3, 6-10 are subject to examination. Claims 4-5 are cancelled.
Drawings
The figures submitted on 2/27/26 are acknowledged.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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 of this title, 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, 2, 3, 6, 8, 9, 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over GHABRA, 20210209873 in view of HATTON et al., 20190143937 and Jakobsson, 20120284783.
Referring to claim(s) 1, GHABRA substantially discloses a method for initializing a secure connection, comprising: - reception, by a control unit of a vehicle, of a first secret
[0041] FIG. 1 shows a vehicle access system 28 that performs as a PEPS system and a PAK system. The vehicle access system 28 includes a vehicle 30 and may include a key fob 32, a mobile phone 34, and/or other portable access devices, such as a wearable device, a laptop computer, or other portable network device. The portable access devices may be, for example, a Bluetooth®-enabled communication device, such as a smart phone, smart watch, wearable electronic device, key fob, tablet device, or other device associated with a user of the vehicle 30.
[0003] The PEPS module (i) performs an authentication process to determine if the key fob is authorized to access the vehicle, and (ii) determines a location of the key fob relative to the vehicle. The authentication process may include the exchange of an encrypted password or signature. If the password or signature is correct, then the key fob is determined to be authorized. Location of the key fob may be determined based on, for example, strength of a signal received from the key fob. If the key fob is authenticated and is located within an authorized zone of the vehicle, then access to the interior of the vehicle is permitted.
[0004] In response to pushing the button, the key fob communicates with the PEPS module and if the key fob is authenticated and within a predetermined distance of the vehicle, the PEPS module performs the stated function (e.g., starts the vehicle, opens a door, sets off an alarm, etc.) associated with the button pressed on the key fob.
and set-up of a secure communication channel between the control unit of the vehicle and a user terminal, provided that the first secret and a second secret stored by the user terminal satisfy a predefined condition, wherein the control unit of the vehicle receives the first secret from the device via a wireless communication requiring proximity between the device and the control unit
[0005] A phone as a key (PAK) vehicle access system can operate similarly as the stated PEPs system, except the vehicle is accessed using a mobile phone rather than a key fob. As an example, the mobile phone can communicate with a PAK module or a telematics control unit (TCU) in the vehicle to begin an access pairing process. The mobile phone and either the PAK module or the TCU perform the access pairing process to establish a trust relationship. The pairing process can include Bluetooth® pairing whereby: security information is exchanged between the mobile phone and the vehicle directly; a mobile phone address, a mobile phone identity resolving key, a reservation identifier and/or an encryption key are exchanged via a cloud-based network; and/or the mobile phone presents a certificate to the vehicle, where the certificate is signed by (i) the mobile phone, (ii) a trusted security signing authority such as a manufacturer of the vehicle, and/or (iii) a trusted third party. In the case of a certificate, the certificate can include an identifier of a person authorized to access a vehicle, an identifier of a cloud-based network authorized to transfer the certificate, an identifier of a rental or lease agreement of the vehicle, an identifier of the vehicle, a date and time period during which the vehicle is permitted for use by the authorized person, and/or other restrictions and/or access/license information.
Note: the predefined condition being the secret/key/certificate being usable/valid/trustable/etc.
GHABRA also discloses provided that an identifier specific to the device transmitted by the control unit of the vehicle to the system and a reference identifier specific to the vehicle stored in a database of the system are identical to a first identifier and second identifier transmitted by the user terminal to the system, respectively,
[0005] A phone as a key (PAK) vehicle access system can operate similarly as the stated PEPs system, except the vehicle is accessed using a mobile phone rather than a key fob. As an example, the mobile phone can communicate with a PAK module or a telematics control unit (TCU) in the vehicle to begin an access pairing process. The mobile phone and either the PAK module or the TCU perform the access pairing process to establish a trust relationship. The pairing process can include Bluetooth® pairing whereby: security information is exchanged between the mobile phone and the vehicle directly; a mobile phone address, a mobile phone identity resolving key, a reservation identifier and/or an encryption key are exchanged via a cloud-based network; and/or the mobile phone presents a certificate to the vehicle, where the certificate is signed by (i) the mobile phone, (ii) a trusted security signing authority such as a manufacturer of the vehicle, and/or (iii) a trusted third party. In the case of a certificate, the certificate can include an identifier of a person authorized to access a vehicle, an identifier of a cloud-based network authorized to transfer the certificate, an identifier of a rental or lease agreement of the vehicle, an identifier of the vehicle, a date and time period during which the vehicle is permitted for use by the authorized person, and/or other restrictions and/or access/license information.
requiring proximity between the user terminal and the device
[0064] As an example, the vehicle control module 204 may determine the location of the portable access device based on, for example, the patterns of the RSSI values corresponding to signals received from the portable access device by the antenna modules 38. A strong (or high) RSSI value indicates that the portable access device is close to the vehicle 30 and a weak (or low) RSSI value indicates that the portable access device is further away from the vehicle 30. By analyzing the RSSI values, the control module 204 may determine a location of and/or a distance to the portable access device relative to the vehicle 30. Additionally or alternatively, angle of arrival, angle of departure, round trip timing, unmodulated carrier tone exchange, or time difference of arrival measurements for the signals sent between the portable access device and the control module 204 may also be used by the control module 204 or the portable access device to determine the location of the portable access device. Additionally or alternatively, the antenna modules 38 may determine the location of and/or distance to the portable access device based on the measured information and communicate the location or distance to the control module 204.
[0065] Based on the determined location of or distance to the portable access device relative to the vehicle 30, the modules 211, 212 of FIG. 2 may then authorize and/or perform a vehicle function, such as unlocking a door of the vehicle 30, unlocking a trunk of the vehicle 30, starting the vehicle 30, and/or allowing the vehicle 30 to be started. As another example, if the portable access device is less than a first predetermined distance from the vehicle 30, the modules 211, 212 may activate interior or exterior lights of the vehicle 30. If the portable access device is less than a second predetermined distance from the vehicle 30, the modules 211, 212 may unlock doors or a trunk of the vehicle 30. If the portable access device is located inside of the vehicle 30, the modules 211, 212 may allow the vehicle 30 to be started. Based on the determined location of or distance to the portable access device relative to the vehicle 30, the polling reduction module 214 may also perform certain operations as further described below.
GHABRA also discloses wherein the first secret is configured to permit set-up of the secure communication channel between the control unit of the vehicle and the user terminal provided that a candidate password transmitted by the user terminal to the control unit of the vehicle matches the second secret
[0003] The PEPS module (i) performs an authentication process to determine if the key fob is authorized to access the vehicle, and (ii) determines a location of the key fob relative to the vehicle. The authentication process may include the exchange of an encrypted password or signature. If the password or signature is correct, then the key fob is determined to be authorized. Location of the key fob may be determined based on, for example, strength of a signal received from the key fob. If the key fob is authenticated and is located within an authorized zone of the vehicle, then access to the interior of the vehicle is permitted.
[0005] A phone as a key (PAK) vehicle access system can operate similarly as the stated PEPs system, except the vehicle is accessed using a mobile phone rather than a key fob. As an example, the mobile phone can communicate with a PAK module or a telematics control unit (TCU) in the vehicle to begin an access pairing process. The mobile phone and either the PAK module or the TCU perform the access pairing process to establish a trust relationship. The pairing process can include Bluetooth® pairing whereby: security information is exchanged between the mobile phone and the vehicle directly; a mobile phone address, a mobile phone identity resolving key, a reservation identifier and/or an encryption key are exchanged via a cloud-based network; and/or the mobile phone presents a certificate to the vehicle, where the certificate is signed by (i) the mobile phone, (ii) a trusted security signing authority such as a manufacturer of the vehicle, and/or (iii) a trusted third party. In the case of a certificate, the certificate can include an identifier of a person authorized to access a vehicle, an identifier of a cloud-based network authorized to transfer the certificate, an identifier of a rental or lease agreement of the vehicle, an identifier of the vehicle, a date and time period during which the vehicle is permitted for use by the authorized person, and/or other restrictions and/or access/license information.
GHABRA does not disclose, which HATTON discloses a first secret transmitted beforehand by a system to a device and after the device has received the first secret from the system (server to key fob transmission prior to the pairing of the key fob with the vehicle/device/phone, para 62, 68), the first identifier and second identifier being transmitted beforehand by the device to the user terminal via a wireless communication (transmission prior to the pairing of among the devices/ vehicle /phone, para 62, 68).
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by GHABRA to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing the key/secret/certificate of the key fob. The server or a remote device would provide the key/secret/certificate for the key fob, which would be stored in the key fob and would be available prior to pairing the key fob. The key/secret/certificate of the key fob would enable operating the device in a secure manner as the secret is not known to others, para 62, 68.
GHABRA and HATTON does not disclose, which Jakobsson discloses a password checker.
[0066] FIG. 4 is a block diagram of a computer system 400 suitable for implementing one or more embodiments of the present disclosure. In various implementations, computer system 400 may be used to check a password strength, communicate with a user, communicate with a password checker, or communicate with a system or site requiring password entry. The system or device may comprise a personal computing device (e.g., a personal computer, laptop, smart phone, PDA, Bluetooth device, key FOB, badge, etc.) capable of communicating with a network.
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by GHABRA to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing the password checker. What rules to apply and how to score the password depends on the password checker. The password check would enable verifying a number insertion that have a lower weight than a word insertion. Hence, the password check would enable ensuring higher score, to require strong password, para 36.
Referring to claim(s) 2, GHABRA discloses a method for initializing a secure connection, comprising: reception, by a device, of a first secret
[0041] FIG. 1 shows a vehicle access system 28 that performs as a PEPS system and a PAK system. The vehicle access system 28 includes a vehicle 30 and may include a key fob 32, a mobile phone 34, and/or other portable access devices, such as a wearable device, a laptop computer, or other portable network device. The portable access devices may be, for example, a Bluetooth®-enabled communication device, such as a smart phone, smart watch, wearable electronic device, key fob, tablet device, or other device associated with a user of the vehicle 30. The user may be an owner, driver, or passenger of the vehicle 30 and/or a technician for the vehicle 30.
[0003] The PEPS module (i) performs an authentication process to determine if the key fob is authorized to access the vehicle, and (ii) determines a location of the key fob relative to the vehicle. The authentication process may include the exchange of an encrypted password or signature. If the password or signature is correct, then the key fob is determined to be authorized. Location of the key fob may be determined based on, for example, strength of a signal received from the key fob. If the key fob is authenticated and is located within an authorized zone of the vehicle, then access to the interior of the vehicle is permitted.
[0004] In response to pushing the button, the key fob communicates with the PEPS module and if the key fob is authenticated and within a predetermined distance of the vehicle, the PEPS module performs the stated function (e.g., starts the vehicle, opens a door, sets off an alarm, etc.) associated with the button pressed on the key fob.
transmission by the device of the first secret to a control unit of a vehicle via a wireless communication requiring proximity between the device and the control unit of the vehicle, the control unit of the vehicle being configured to set up a secure communication channel with a user terminal, provided that the first secret and a second secret stored by the user terminal satisfy a predefined condition
[0005] A phone as a key (PAK) vehicle access system can operate similarly as the stated PEPs system, except the vehicle is accessed using a mobile phone rather than a key fob. As an example, the mobile phone can communicate with a PAK module or a telematics control unit (TCU) in the vehicle to begin an access pairing process. The mobile phone and either the PAK module or the TCU perform the access pairing process to establish a trust relationship. The pairing process can include Bluetooth® pairing whereby: security information is exchanged between the mobile phone and the vehicle directly; a mobile phone address, a mobile phone identity resolving key, a reservation identifier and/or an encryption key are exchanged via a cloud-based network; and/or the mobile phone presents a certificate to the vehicle, where the certificate is signed by (i) the mobile phone, (ii) a trusted security signing authority such as a manufacturer of the vehicle, and/or (iii) a trusted third party. In the case of a certificate, the certificate can include an identifier of a person authorized to access a vehicle, an identifier of a cloud-based network authorized to transfer the certificate, an identifier of a rental or lease agreement of the vehicle, an identifier of the vehicle, a date and time period during which the vehicle is permitted for use by the authorized person, and/or other restrictions and/or access/license information.
Note: the predefined condition being the secret/key/certificate being usable/valid/trustable/etc.
GHABRA also discloses provided that an identifier specific to the device transmitted by the control unit of the vehicle to the system and a reference identifier specific to the vehicle stored in a database of the system are identical to a first identifier and second identifier transmitted by the user terminal to the system, respectively,
[0005] A phone as a key (PAK) vehicle access system can operate similarly as the stated PEPs system, except the vehicle is accessed using a mobile phone rather than a key fob. As an example, the mobile phone can communicate with a PAK module or a telematics control unit (TCU) in the vehicle to begin an access pairing process. The mobile phone and either the PAK module or the TCU perform the access pairing process to establish a trust relationship. The pairing process can include Bluetooth® pairing whereby: security information is exchanged between the mobile phone and the vehicle directly; a mobile phone address, a mobile phone identity resolving key, a reservation identifier and/or an encryption key are exchanged via a cloud-based network; and/or the mobile phone presents a certificate to the vehicle, where the certificate is signed by (i) the mobile phone, (ii) a trusted security signing authority such as a manufacturer of the vehicle, and/or (iii) a trusted third party. In the case of a certificate, the certificate can include an identifier of a person authorized to access a vehicle, an identifier of a cloud-based network authorized to transfer the certificate, an identifier of a rental or lease agreement of the vehicle, an identifier of the vehicle, a date and time period during which the vehicle is permitted for use by the authorized person, and/or other restrictions and/or access/license information.
requiring proximity between the user terminal and the device
[0064] As an example, the vehicle control module 204 may determine the location of the portable access device based on, for example, the patterns of the RSSI values corresponding to signals received from the portable access device by the antenna modules 38. A strong (or high) RSSI value indicates that the portable access device is close to the vehicle 30 and a weak (or low) RSSI value indicates that the portable access device is further away from the vehicle 30. By analyzing the RSSI values, the control module 204 may determine a location of and/or a distance to the portable access device relative to the vehicle 30. Additionally or alternatively, angle of arrival, angle of departure, round trip timing, unmodulated carrier tone exchange, or time difference of arrival measurements for the signals sent between the portable access device and the control module 204 may also be used by the control module 204 or the portable access device to determine the location of the portable access device. Additionally or alternatively, the antenna modules 38 may determine the location of and/or distance to the portable access device based on the measured information and communicate the location or distance to the control module 204.
[0065] Based on the determined location of or distance to the portable access device relative to the vehicle 30, the modules 211, 212 of FIG. 2 may then authorize and/or perform a vehicle function, such as unlocking a door of the vehicle 30, unlocking a trunk of the vehicle 30, starting the vehicle 30, and/or allowing the vehicle 30 to be started. As another example, if the portable access device is less than a first predetermined distance from the vehicle 30, the modules 211, 212 may activate interior or exterior lights of the vehicle 30. If the portable access device is less than a second predetermined distance from the vehicle 30, the modules 211, 212 may unlock doors or a trunk of the vehicle 30. If the portable access device is located inside of the vehicle 30, the modules 211, 212 may allow the vehicle 30 to be started. Based on the determined location of or distance to the portable access device relative to the vehicle 30, the polling reduction module 214 may also perform certain operations as further described below.
GHABRA also discloses wherein the first secret is configured to permit set-up of the secure communication channel between the control unit of the vehicle and the user terminal provided that a candidate password transmitted by the user terminal to the control unit of the vehicle matches the second secret
[0003] The PEPS module (i) performs an authentication process to determine if the key fob is authorized to access the vehicle, and (ii) determines a location of the key fob relative to the vehicle. The authentication process may include the exchange of an encrypted password or signature. If the password or signature is correct, then the key fob is determined to be authorized. Location of the key fob may be determined based on, for example, strength of a signal received from the key fob. If the key fob is authenticated and is located within an authorized zone of the vehicle, then access to the interior of the vehicle is permitted.
[0005] A phone as a key (PAK) vehicle access system can operate similarly as the stated PEPs system, except the vehicle is accessed using a mobile phone rather than a key fob. As an example, the mobile phone can communicate with a PAK module or a telematics control unit (TCU) in the vehicle to begin an access pairing process. The mobile phone and either the PAK module or the TCU perform the access pairing process to establish a trust relationship. The pairing process can include Bluetooth® pairing whereby: security information is exchanged between the mobile phone and the vehicle directly; a mobile phone address, a mobile phone identity resolving key, a reservation identifier and/or an encryption key are exchanged via a cloud-based network; and/or the mobile phone presents a certificate to the vehicle, where the certificate is signed by (i) the mobile phone, (ii) a trusted security signing authority such as a manufacturer of the vehicle, and/or (iii) a trusted third party. In the case of a certificate, the certificate can include an identifier of a person authorized to access a vehicle, an identifier of a cloud-based network authorized to transfer the certificate, an identifier of a rental or lease agreement of the vehicle, an identifier of the vehicle, a date and time period during which the vehicle is permitted for use by the authorized person, and/or other restrictions and/or access/license information.
GHABRA does not disclose, which HATTON discloses a first secret transmitted beforehand by a system to a device and after the device has received the first secret from the system (server to key fob transmission prior to the pairing of the key fob with the vehicle/device/phone, para 62, 68), the first identifier and second identifier being transmitted beforehand by the device to the user terminal via a wireless communication (transmission prior to the pairing of among the devices/ vehicle /phone, para 62, 68).
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by GHABRA to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing the key/secret/certificate of the key fob. The server or a remote device would provide the key/secret/certificate for the key fob, which would be stored in the key fob and would be available prior to pairing the key fob. The key/secret/certificate of the key fob would enable operating the device in a secure manner as the secret is not known to others, para 62, 68.
GHABRA and HATTON does not disclose, which Jakobsson discloses a password checker.
[0066] FIG. 4 is a block diagram of a computer system 400 suitable for implementing one or more embodiments of the present disclosure. In various implementations, computer system 400 may be used to check a password strength, communicate with a user, communicate with a password checker, or communicate with a system or site requiring password entry. The system or device may comprise a personal computing device (e.g., a personal computer, laptop, smart phone, PDA, Bluetooth device, key FOB, badge, etc.) capable of communicating with a network.
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by GHABRA to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing the password checker. What rules to apply and how to score the password depends on the password checker. The password check would enable verifying a number insertion that have a lower weight than a word insertion. Hence, the password check would enable ensuring higher score, to require strong password, para 36.
Referring to claim 3, GHABRA discloses, a method for initializing a secure connection, comprising: transmission, by a system, of a first secret to a device, the device being configured to transmit the first secret to a control unit of a vehicle via a wireless communication
[0041] FIG. 1 shows a vehicle access system 28 that performs as a PEPS system and a PAK system. The vehicle access system 28 includes a vehicle 30 and may include a key fob 32, a mobile phone 34, and/or other portable access devices, such as a wearable device, a laptop computer, or other portable network device. The portable access devices may be, for example, a Bluetooth®-enabled communication device, such as a smart phone, smart watch, wearable electronic device, key fob, tablet device, or other device associated with a user of the vehicle 30.
[0003] The PEPS module (i) performs an authentication process to determine if the key fob is authorized to access the vehicle, and (ii) determines a location of the key fob relative to the vehicle. The authentication process may include the exchange of an encrypted password or signature. If the password or signature is correct, then the key fob is determined to be authorized. Location of the key fob may be determined based on, for example, strength of a signal received from the key fob. If the key fob is authenticated and is located within an authorized zone of the vehicle, then access to the interior of the vehicle is permitted.
requiring proximity between the device and the control unit of the vehicle, transmission by the system of a second secret to a user terminal, the user terminal being configured to set up a secure communication channel with the control unit of the vehicle, provided that the first secret and second secret satisfy a predefined condition.
[0005] A phone as a key (PAK) vehicle access system can operate similarly as the stated PEPs system, except the vehicle is accessed using a mobile phone rather than a key fob. As an example, the mobile phone can communicate with a PAK module or a telematics control unit (TCU) in the vehicle to begin an access pairing process. The mobile phone and either the PAK module or the TCU perform the access pairing process to establish a trust relationship. The pairing process can include Bluetooth® pairing whereby: security information is exchanged between the mobile phone and the vehicle directly; a mobile phone address, a mobile phone identity resolving key, a reservation identifier and/or an encryption key are exchanged via a cloud-based network; and/or the mobile phone presents a certificate to the vehicle, where the certificate is signed by (i) the mobile phone, (ii) a trusted security signing authority such as a manufacturer of the vehicle, and/or (iii) a trusted third party. In the case of a certificate, the certificate can include an identifier of a person authorized to access a vehicle, an identifier of a cloud-based network authorized to transfer the certificate, an identifier of a rental or lease agreement of the vehicle, an identifier of the vehicle, a date and time period during which the vehicle is permitted for use by the authorized person, and/or other restrictions and/or access/license information.
Note: the predefined condition being the secret/key/certificate being usable/valid/trustable/etc.
GHABRA also discloses provided that an identifier specific to the device transmitted by the control unit of the vehicle to the system and a reference identifier specific to the vehicle stored in a database of the system are identical to a first identifier and second identifier transmitted by the user terminal to the system, respectively,
[0005] A phone as a key (PAK) vehicle access system can operate similarly as the stated PEPs system, except the vehicle is accessed using a mobile phone rather than a key fob. As an example, the mobile phone can communicate with a PAK module or a telematics control unit (TCU) in the vehicle to begin an access pairing process. The mobile phone and either the PAK module or the TCU perform the access pairing process to establish a trust relationship. The pairing process can include Bluetooth® pairing whereby: security information is exchanged between the mobile phone and the vehicle directly; a mobile phone address, a mobile phone identity resolving key, a reservation identifier and/or an encryption key are exchanged via a cloud-based network; and/or the mobile phone presents a certificate to the vehicle, where the certificate is signed by (i) the mobile phone, (ii) a trusted security signing authority such as a manufacturer of the vehicle, and/or (iii) a trusted third party. In the case of a certificate, the certificate can include an identifier of a person authorized to access a vehicle, an identifier of a cloud-based network authorized to transfer the certificate, an identifier of a rental or lease agreement of the vehicle, an identifier of the vehicle, a date and time period during which the vehicle is permitted for use by the authorized person, and/or other restrictions and/or access/license information.
requiring proximity between the user terminal and the device
[0064] As an example, the vehicle control module 204 may determine the location of the portable access device based on, for example, the patterns of the RSSI values corresponding to signals received from the portable access device by the antenna modules 38. A strong (or high) RSSI value indicates that the portable access device is close to the vehicle 30 and a weak (or low) RSSI value indicates that the portable access device is further away from the vehicle 30. By analyzing the RSSI values, the control module 204 may determine a location of and/or a distance to the portable access device relative to the vehicle 30. Additionally or alternatively, angle of arrival, angle of departure, round trip timing, unmodulated carrier tone exchange, or time difference of arrival measurements for the signals sent between the portable access device and the control module 204 may also be used by the control module 204 or the portable access device to determine the location of the portable access device. Additionally or alternatively, the antenna modules 38 may determine the location of and/or distance to the portable access device based on the measured information and communicate the location or distance to the control module 204.
[0065] Based on the determined location of or distance to the portable access device relative to the vehicle 30, the modules 211, 212 of FIG. 2 may then authorize and/or perform a vehicle function, such as unlocking a door of the vehicle 30, unlocking a trunk of the vehicle 30, starting the vehicle 30, and/or allowing the vehicle 30 to be started. As another example, if the portable access device is less than a first predetermined distance from the vehicle 30, the modules 211, 212 may activate interior or exterior lights of the vehicle 30. If the portable access device is less than a second predetermined distance from the vehicle 30, the modules 211, 212 may unlock doors or a trunk of the vehicle 30. If the portable access device is located inside of the vehicle 30, the modules 211, 212 may allow the vehicle 30 to be started. Based on the determined location of or distance to the portable access device relative to the vehicle 30, the polling reduction module 214 may also perform certain operations as further described below.
GHABRA also discloses wherein the first secret is configured to permit set-up of the secure communication channel between the control unit of the vehicle and the user terminal provided that a candidate password transmitted by the user terminal to the control unit of the vehicle matches the second secret
[0003] The PEPS module (i) performs an authentication process to determine if the key fob is authorized to access the vehicle, and (ii) determines a location of the key fob relative to the vehicle. The authentication process may include the exchange of an encrypted password or signature. If the password or signature is correct, then the key fob is determined to be authorized. Location of the key fob may be determined based on, for example, strength of a signal received from the key fob. If the key fob is authenticated and is located within an authorized zone of the vehicle, then access to the interior of the vehicle is permitted.
[0005] A phone as a key (PAK) vehicle access system can operate similarly as the stated PEPs system, except the vehicle is accessed using a mobile phone rather than a key fob. As an example, the mobile phone can communicate with a PAK module or a telematics control unit (TCU) in the vehicle to begin an access pairing process. The mobile phone and either the PAK module or the TCU perform the access pairing process to establish a trust relationship. The pairing process can include Bluetooth® pairing whereby: security information is exchanged between the mobile phone and the vehicle directly; a mobile phone address, a mobile phone identity resolving key, a reservation identifier and/or an encryption key are exchanged via a cloud-based network; and/or the mobile phone presents a certificate to the vehicle, where the certificate is signed by (i) the mobile phone, (ii) a trusted security signing authority such as a manufacturer of the vehicle, and/or (iii) a trusted third party. In the case of a certificate, the certificate can include an identifier of a person authorized to access a vehicle, an identifier of a cloud-based network authorized to transfer the certificate, an identifier of a rental or lease agreement of the vehicle, an identifier of the vehicle, a date and time period during which the vehicle is permitted for use by the authorized person, and/or other restrictions and/or access/license information.
GHABRA does not disclose, which HATTON discloses a first secret transmitted beforehand by a system to a device and after the device has received the first secret from the system (server to key fob transmission prior to the pairing of the key fob with the vehicle/device/phone, para 62, 68), the first identifier and second identifier being transmitted beforehand by the device to the user terminal via a wireless communication (transmission prior to the pairing of among the devices/ vehicle /phone, para 62, 68).
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by GHABRA to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing the key/secret/certificate of the key fob. The server or a remote device would provide the key/secret/certificate for the key fob, which would be stored in the key fob and would be available prior to pairing the key fob. The key/secret/certificate of the key fob would enable operating the device in a secure manner as the secret is not known to others, para 62, 68.
GHABRA and HATTON does not disclose, which Jakobsson discloses a password checker.
[0066] FIG. 4 is a block diagram of a computer system 400 suitable for implementing one or more embodiments of the present disclosure. In various implementations, computer system 400 may be used to check a password strength, communicate with a user, communicate with a password checker, or communicate with a system or site requiring password entry. The system or device may comprise a personal computing device (e.g., a personal computer, laptop, smart phone, PDA, Bluetooth device, key FOB, badge, etc.) capable of communicating with a network.
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by GHABRA to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing the password checker. What rules to apply and how to score the password depends on the password checker. The password check would enable verifying a number insertion that have a lower weight than a word insertion. Hence, the password check would enable ensuring higher score, to require strong password, para 36.
Referring to claim 10, GHABRA discloses, A system comprising: a communication interface configured to transmit a first secret to a device, the device being configured to transmit the first secret to a control unit of a vehicle via a wireless communication requiring proximity between the device and the control unit of the vehicle;
[0041] FIG. 1 shows a vehicle access system 28 that performs as a PEPS system and a PAK system. The vehicle access system 28 includes a vehicle 30 and may include a key fob 32, a mobile phone 34, and/or other portable access devices, such as a wearable device, a laptop computer, or other portable network device. The portable access devices may be, for example, a Bluetooth®-enabled communication device, such as a smart phone, smart watch, wearable electronic device, key fob, tablet device, or other device associated with a user of the vehicle 30.
[0003] The PEPS module (i) performs an authentication process to determine if the key fob is authorized to access the vehicle, and (ii) determines a location of the key fob relative to the vehicle. The authentication process may include the exchange of an encrypted password or signature. If the password or signature is correct, then the key fob is determined to be authorized. Location of the key fob may be determined based on, for example, strength of a signal received from the key fob. If the key fob is authenticated and is located within an authorized zone of the vehicle, then access to the interior of the vehicle is permitted.
a second communication interface configured to transmit a second secret to a user terminal, the user terminal being configured to set up a secure communication channel with the control unit of the vehicle, provided that the first secret and second secret satisfy a predefined condition.
[0005] A phone as a key (PAK) vehicle access system can operate similarly as the stated PEPs system, except the vehicle is accessed using a mobile phone rather than a key fob. As an example, the mobile phone can communicate with a PAK module or a telematics control unit (TCU) in the vehicle to begin an access pairing process. The mobile phone and either the PAK module or the TCU perform the access pairing process to establish a trust relationship. The pairing process can include Bluetooth® pairing whereby: security information is exchanged between the mobile phone and the vehicle directly; a mobile phone address, a mobile phone identity resolving key, a reservation identifier and/or an encryption key are exchanged via a cloud-based network; and/or the mobile phone presents a certificate to the vehicle, where the certificate is signed by (i) the mobile phone, (ii) a trusted security signing authority such as a manufacturer of the vehicle, and/or (iii) a trusted third party. In the case of a certificate, the certificate can include an identifier of a person authorized to access a vehicle, an identifier of a cloud-based network authorized to transfer the certificate, an identifier of a rental or lease agreement of the vehicle, an identifier of the vehicle, a date and time period during which the vehicle is permitted for use by the authorized person, and/or other restrictions and/or access/license information.
Note: the predefined condition being the secret/key/certificate being usable/valid/trustable/etc.
GHABRA also discloses provided that an identifier specific to the device transmitted by the control unit of the vehicle to the system and a reference identifier specific to the vehicle stored in a database of the system are identical to a first identifier and second identifier transmitted by the user terminal to the system, respectively,
[0005] A phone as a key (PAK) vehicle access system can operate similarly as the stated PEPs system, except the vehicle is accessed using a mobile phone rather than a key fob. As an example, the mobile phone can communicate with a PAK module or a telematics control unit (TCU) in the vehicle to begin an access pairing process. The mobile phone and either the PAK module or the TCU perform the access pairing process to establish a trust relationship. The pairing process can include Bluetooth® pairing whereby: security information is exchanged between the mobile phone and the vehicle directly; a mobile phone address, a mobile phone identity resolving key, a reservation identifier and/or an encryption key are exchanged via a cloud-based network; and/or the mobile phone presents a certificate to the vehicle, where the certificate is signed by (i) the mobile phone, (ii) a trusted security signing authority such as a manufacturer of the vehicle, and/or (iii) a trusted third party. In the case of a certificate, the certificate can include an identifier of a person authorized to access a vehicle, an identifier of a cloud-based network authorized to transfer the certificate, an identifier of a rental or lease agreement of the vehicle, an identifier of the vehicle, a date and time period during which the vehicle is permitted for use by the authorized person, and/or other restrictions and/or access/license information.
requiring proximity between the user terminal and the device
[0064] As an example, the vehicle control module 204 may determine the location of the portable access device based on, for example, the patterns of the RSSI values corresponding to signals received from the portable access device by the antenna modules 38. A strong (or high) RSSI value indicates that the portable access device is close to the vehicle 30 and a weak (or low) RSSI value indicates that the portable access device is further away from the vehicle 30. By analyzing the RSSI values, the control module 204 may determine a location of and/or a distance to the portable access device relative to the vehicle 30. Additionally or alternatively, angle of arrival, angle of departure, round trip timing, unmodulated carrier tone exchange, or time difference of arrival measurements for the signals sent between the portable access device and the control module 204 may also be used by the control module 204 or the portable access device to determine the location of the portable access device. Additionally or alternatively, the antenna modules 38 may determine the location of and/or distance to the portable access device based on the measured information and communicate the location or distance to the control module 204.
[0065] Based on the determined location of or distance to the portable access device relative to the vehicle 30, the modules 211, 212 of FIG. 2 may then authorize and/or perform a vehicle function, such as unlocking a door of the vehicle 30, unlocking a trunk of the vehicle 30, starting the vehicle 30, and/or allowing the vehicle 30 to be started. As another example, if the portable access device is less than a first predetermined distance from the vehicle 30, the modules 211, 212 may activate interior or exterior lights of the vehicle 30. If the portable access device is less than a second predetermined distance from the vehicle 30, the modules 211, 212 may unlock doors or a trunk of the vehicle 30. If the portable access device is located inside of the vehicle 30, the modules 211, 212 may allow the vehicle 30 to be started. Based on the determined location of or distance to the portable access device relative to the vehicle 30, the polling reduction module 214 may also perform certain operations as further described below.
GHABRA also discloses wherein the first secret is configured to permit set-up of the secure communication channel between the control unit of the vehicle and the user terminal provided that a candidate password transmitted by the user terminal to the control unit of the vehicle matches the second secret
[0003] The PEPS module (i) performs an authentication process to determine if the key fob is authorized to access the vehicle, and (ii) determines a location of the key fob relative to the vehicle. The authentication process may include the exchange of an encrypted password or signature. If the password or signature is correct, then the key fob is determined to be authorized. Location of the key fob may be determined based on, for example, strength of a signal received from the key fob. If the key fob is authenticated and is located within an authorized zone of the vehicle, then access to the interior of the vehicle is permitted.
[0005] A phone as a key (PAK) vehicle access system can operate similarly as the stated PEPs system, except the vehicle is accessed using a mobile phone rather than a key fob. As an example, the mobile phone can communicate with a PAK module or a telematics control unit (TCU) in the vehicle to begin an access pairing process. The mobile phone and either the PAK module or the TCU perform the access pairing process to establish a trust relationship. The pairing process can include Bluetooth® pairing whereby: security information is exchanged between the mobile phone and the vehicle directly; a mobile phone address, a mobile phone identity resolving key, a reservation identifier and/or an encryption key are exchanged via a cloud-based network; and/or the mobile phone presents a certificate to the vehicle, where the certificate is signed by (i) the mobile phone, (ii) a trusted security signing authority such as a manufacturer of the vehicle, and/or (iii) a trusted third party. In the case of a certificate, the certificate can include an identifier of a person authorized to access a vehicle, an identifier of a cloud-based network authorized to transfer the certificate, an identifier of a rental or lease agreement of the vehicle, an identifier of the vehicle, a date and time period during which the vehicle is permitted for use by the authorized person, and/or other restrictions and/or access/license information.
GHABRA does not disclose, which HATTON discloses a first secret transmitted beforehand by a system to a device and after the device has received the first secret from the system (server to key fob transmission prior to the pairing of the key fob with the vehicle/device/phone, para 62, 68), the first identifier and second identifier being transmitted beforehand by the device to the user terminal via a wireless communication (transmission prior to the pairing of among the devices/ vehicle /phone, para 62, 68).
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by GHABRA to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing the key/secret/certificate of the key fob. The server or a remote device would provide the key/secret/certificate for the key fob, which would be stored in the key fob and would be available prior to pairing the key fob. The key/secret/certificate of the key fob would enable operating the device in a secure manner as the secret is not known to others, para 62, 68.
GHABRA and HATTON does not disclose, which Jakobsson discloses a password checker.
[0066] FIG. 4 is a block diagram of a computer system 400 suitable for implementing one or more embodiments of the present disclosure. In various implementations, computer system 400 may be used to check a password strength, communicate with a user, communicate with a password checker, or communicate with a system or site requiring password entry. The system or device may comprise a personal computing device (e.g., a personal computer, laptop, smart phone, PDA, Bluetooth device, key FOB, badge, etc.) capable of communicating with a network.
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by GHABRA to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing the password checker. What rules to apply and how to score the password depends on the password checker. The password check would enable verifying a number insertion that have a lower weight than a word insertion. Hence, the password check would enable ensuring higher score, to require strong password, para 36.
Referring to claim(s) 6, HATTON discloses near-field communication, or optical read-out, by the control unit of the vehicle, of a pattern representative of the first secret and displayed by the device, the pattern being a bar code or a QR code (para 52).
Referring to claim(s) 8, GHABRA substantially discloses A control unit for a vehicle, the control unit comprising: a first communication interface configured to receive a first secret transmitted to a device
[0041] FIG. 1 shows a vehicle access system 28 that performs as a PEPS system and a PAK system. The vehicle access system 28 includes a vehicle 30 and may include a key fob 32, a mobile phone 34, and/or other portable access devices, such as a wearable device, a laptop computer, or other portable network device. The portable access devices may be, for example, a Bluetooth®-enabled communication device, such as a smart phone, smart watch, wearable electronic device, key fob, tablet device, or other device associated with a user of the vehicle 30.
[0003] The PEPS module (i) performs an authentication process to determine if the key fob is authorized to access the vehicle, and (ii) determines a location of the key fob relative to the vehicle. The authentication process may include the exchange of an encrypted password or signature. If the password or signature is correct, then the key fob is determined to be authorized. Location of the key fob may be determined based on, for example, strength of a signal received from the key fob. If the key fob is authenticated and is located within an authorized zone of the vehicle, then access to the interior of the vehicle is permitted.
[0004] In response to pushing the button, the key fob communicates with the PEPS module and if the key fob is authenticated and within a predetermined distance of the vehicle, the PEPS module performs the stated function (e.g., starts the vehicle, opens a door, sets off an alarm, etc.) associated with the button pressed on the key fob.
a second communication interface configured to set up a secure communication channel between the control unit of the vehicle and a user terminal, provided that the first secret and a second secret stored by the user terminal satisfy a predefined condition, wherein the first communication interface is configured to receive the first secret from the device via a wireless communication requiring proximity between the device and the control unit
[0005] A phone as a key (PAK) vehicle access system can operate similarly as the stated PEPs system, except the vehicle is accessed using a mobile phone rather than a key fob. As an example, the mobile phone can communicate with a PAK module or a telematics control unit (TCU) in the vehicle to begin an access pairing process. The mobile phone and either the PAK module or the TCU perform the access pairing process to establish a trust relationship. The pairing process can include Bluetooth® pairing whereby: security information is exchanged between the mobile phone and the vehicle directly; a mobile phone address, a mobile phone identity resolving key, a reservation identifier and/or an encryption key are exchanged via a cloud-based network; and/or the mobile phone presents a certificate to the vehicle, where the certificate is signed by (i) the mobile phone, (ii) a trusted security signing authority such as a manufacturer of the vehicle, and/or (iii) a trusted third party. In the case of a certificate, the certificate can include an identifier of a person authorized to access a vehicle, an identifier of a cloud-based network authorized to transfer the certificate, an identifier of a rental or lease agreement of the vehicle, an identifier of the vehicle, a date and time period during which the vehicle is permitted for use by the authorized person, and/or other restrictions and/or access/license information.
Note: the predefined condition being the secret/key/certificate being usable/valid/trustable/etc.
GHABRA does not disclose, which HATTON discloses a first secret transmitted beforehand by a system to a device and after the device has received the first secret from the system (server to key fob transmission prior to the pairing of the key fob with the vehicle/device/phone, para 62, 68)
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by GHABRA to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing the key/secret/certificate of the key fob. The server or a remote device would provide the key/secret/certificate for the key fob, which would be stored in the key fob and would be available prior to pairing the key fob. The key/secret/certificate of the key fob would enable operating the device in a secure manner as the secret is not known to others, para 62, 68.
Note: the predefined condition being the secret/key/certificate being usable/valid/trustable/etc.
GHABRA also discloses provided that an identifier specific to the device transmitted by the control unit of the vehicle to the system and a reference identifier specific to the vehicle stored in a database of the system are identical to a first identifier and second identifier transmitted by the user terminal to the system, respectively,
[0005] A phone as a key (PAK) vehicle access system can operate similarly as the stated PEPs system, except the vehicle is accessed using a mobile phone rather than a key fob. As an example, the mobile phone can communicate with a PAK module or a telematics control unit (TCU) in the vehicle to begin an access pairing process. The mobile phone and either the PAK module or the TCU perform the access pairing process to establish a trust relationship. The pairing process can include Bluetooth® pairing whereby: security information is exchanged between the mobile phone and the vehicle directly; a mobile phone address, a mobile phone identity resolving key, a reservation identifier and/or an encryption key are exchanged via a cloud-based network; and/or the mobile phone presents a certificate to the vehicle, where the certificate is signed by (i) the mobile phone, (ii) a trusted security signing authority such as a manufacturer of the vehicle, and/or (iii) a trusted third party. In the case of a certificate, the certificate can include an identifier of a person authorized to access a vehicle, an identifier of a cloud-based network authorized to transfer the certificate, an identifier of a rental or lease agreement of the vehicle, an identifier of the vehicle, a date and time period during which the vehicle is permitted for use by the authorized person, and/or other restrictions and/or access/license information.
requiring proximity between the user terminal and the device
[0064] As an example, the vehicle control module 204 may determine the location of the portable access device based on, for example, the patterns of the RSSI values corresponding to signals received from the portable access device by the antenna modules 38. A strong (or high) RSSI value indicates that the portable access device is close to the vehicle 30 and a weak (or low) RSSI value indicates that the portable access device is further away from the vehicle 30. By analyzing the RSSI values, the control module 204 may determine a location of and/or a distance to the portable access device relative to the vehicle 30. Additionally or alternatively, angle of arrival, angle of departure, round trip timing, unmodulated carrier tone exchange, or time difference of arrival measurements for the signals sent between the portable access device and the control module 204 may also be used by the control module 204 or the portable access device to determine the location of the portable access device. Additionally or alternatively, the antenna modules 38 may determine the location of and/or distance to the portable access device based on the measured information and communicate the location or distance to the control module 204.
[0065] Based on the determined location of or distance to the portable access device relative to the vehicle 30, the modules 211, 212 of FIG. 2 may then authorize and/or perform a vehicle function, such as unlocking a door of the vehicle 30, unlocking a trunk of the vehicle 30, starting the vehicle 30, and/or allowing the vehicle 30 to be started. As another example, if the portable access device is less than a first predetermined distance from the vehicle 30, the modules 211, 212 may activate interior or exterior lights of the vehicle 30. If the portable access device is less than a second predetermined distance from the vehicle 30, the modules 211, 212 may unlock doors or a trunk of the vehicle 30. If the portable access device is located inside of the vehicle 30, the modules 211, 212 may allow the vehicle 30 to be started. Based on the determined location of or distance to the portable access device relative to the vehicle 30, the polling reduction module 214 may also perform certain operations as further described below.
GHABRA also discloses wherein the first secret is configured to permit set-up of the secure communication channel between the control unit of the vehicle and the user terminal provided that a candidate password transmitted by the user terminal to the control unit of the vehicle matches the second secret
[0003] The PEPS module (i) performs an authentication process to determine if the key fob is authorized to access the vehicle, and (ii) determines a location of the key fob relative to the vehicle. The authentication process may include the exchange of an encrypted password or signature. If the password or signature is correct, then the key fob is determined to be authorized. Location of the key fob may be determined based on, for example, strength of a signal received from the key fob. If the key fob is authenticated and is located within an authorized zone of the vehicle, then access to the interior of the vehicle is permitted.
[0005] A phone as a key (PAK) vehicle access system can operate similarly as the stated PEPs system, except the vehicle is accessed using a mobile phone rather than a key fob. As an example, the mobile phone can communicate with a PAK module or a telematics control unit (TCU) in the vehicle to begin an access pairing process. The mobile phone and either the PAK module or the TCU perform the access pairing process to establish a trust relationship. The pairing process can include Bluetooth® pairing whereby: security information is exchanged between the mobile phone and the vehicle directly; a mobile phone address, a mobile phone identity resolving key, a reservation identifier and/or an encryption key are exchanged via a cloud-based network; and/or the mobile phone presents a certificate to the vehicle, where the certificate is signed by (i) the mobile phone, (ii) a trusted security signing authority such as a manufacturer of the vehicle, and/or (iii) a trusted third party. In the case of a certificate, the certificate can include an identifier of a person authorized to access a vehicle, an identifier of a cloud-based network authorized to transfer the certificate, an identifier of a rental or lease agreement of the vehicle, an identifier of the vehicle, a date and time period during which the vehicle is permitted for use by the authorized person, and/or other restrictions and/or access/license information.
GHABRA does not disclose, which HATTON discloses a first secret transmitted beforehand by a system to a device and after the device has received the first secret from the system (server to key fob transmission prior to the pairing of the key fob with the vehicle/device/phone, para 62, 68), the first identifier and second identifier being transmitted beforehand by the device to the user terminal via a wireless communication (transmission prior to the pairing of among the devices/ vehicle /phone, para 62, 68).
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by GHABRA to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing the key/secret/certificate of the key fob. The server or a remote device would provide the key/secret/certificate for the key fob, which would be stored in the key fob and would be available prior to pairing the key fob. The key/secret/certificate of the key fob would enable operating the device in a secure manner as the secret is not known to others, para 62, 68.
GHABRA and HATTON does not disclose, which Jakobsson discloses a password checker.
[0066] FIG. 4 is a block diagram of a computer system 400 suitable for implementing one or more embodiments of the present disclosure. In various implementations, computer system 400 may be used to check a password strength, communicate with a user, communicate with a password checker, or communicate with a system or site requiring password entry. The system or device may comprise a personal computing device (e.g., a personal computer, laptop, smart phone, PDA, Bluetooth device, key FOB, badge, etc.) capable of communicating with a network.
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by GHABRA to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing the password checker. What rules to apply and how to score the password depends on the password checker. The password check would enable verifying a number insertion that have a lower weight than a word insertion. Hence, the password check would enable ensuring higher score, to require strong password, para 36.
Referring to claim(s) 9, GHABRA substantially discloses A device, such as a chip card: memory storing a first secret, a first communication interface configured to receive a first secret transmitted to a device
[0041] FIG. 1 shows a vehicle access system 28 that performs as a PEPS system and a PAK system. The vehicle access system 28 includes a vehicle 30 and may include a key fob 32, a mobile phone 34, and/or other portable access devices, such as a wearable device, a laptop computer, or other portable network device. The portable access devices may be, for example, a Bluetooth®-enabled communication device, such as a smart phone, smart watch, wearable electronic device, key fob, tablet device, or other device associated with a user of the vehicle 30.
[0003] The PEPS module (i) performs an authentication process to determine if the key fob is authorized to access the vehicle, and (ii) determines a location of the key fob relative to the vehicle. The authentication process may include the exchange of an encrypted password or signature. If the password or signature is correct, then the key fob is determined to be authorized. Location of the key fob may be determined based on, for example, strength of a signal received from the key fob. If the key fob is authenticated and is located within an authorized zone of the vehicle, then access to the interior of the vehicle is permitted.
[0004] In response to pushing the button, the key fob communicates with the PEPS module and if the key fob is authenticated and within a predetermined distance of the vehicle, the PEPS module performs the stated function (e.g., starts the vehicle, opens a door, sets off an alarm, etc.) associated with the button pressed on the key fob.
a communication interface configured to transmit the first secret to a control unit of a vehicle via a wireless communication requiring proximity between the device and the control unit, the control unit of the vehicle being configured to set up a secure communication channel with a user terminal, provided that the first secret and a second secret stored by the user terminal satisfy a predefined condition
[0005] A phone as a key (PAK) vehicle access system can operate similarly as the stated PEPs system, except the vehicle is accessed using a mobile phone rather than a key fob. As an example, the mobile phone can communicate with a PAK module or a telematics control unit (TCU) in the vehicle to begin an access pairing process. The mobile phone and either the PAK module or the TCU perform the access pairing process to establish a trust relationship. The pairing process can include Bluetooth® pairing whereby: security information is exchanged between the mobile phone and the vehicle directly; a mobile phone address, a mobile phone identity resolving key, a reservation identifier and/or an encryption key are exchanged via a cloud-based network; and/or the mobile phone presents a certificate to the vehicle, where the certificate is signed by (i) the mobile phone, (ii) a trusted security signing authority such as a manufacturer of the vehicle, and/or (iii) a trusted third party. In the case of a certificate, the certificate can include an identifier of a person authorized to access a vehicle, an identifier of a cloud-based network authorized to transfer the certificate, an identifier of a rental or lease agreement of the vehicle, an identifier of the vehicle, a date and time period during which the vehicle is permitted for use by the authorized person, and/or other restrictions and/or access/license information.
Note: the predefined condition being the secret/key/certificate being usable/valid/trustable/etc.
GHABRA does not disclose, which HATTON discloses a first secret transmitted beforehand by a system to a device and after the device has received the first secret from the system (server to key fob transmission prior to the pairing of the key fob with the vehicle/device/phone, para 62, 68)
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by GHABRA to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing the key/secret/certificate of the key fob. The server or a remote device would provide the key/secret/certificate for the key fob, which would be stored in the key fob and would be available prior to pairing the key fob. The key/secret/certificate of the key fob would enable operating the device in a secure manner as the secret is not known to others, para 62, 68.
Note: the predefined condition being the secret/key/certificate being usable/valid/trustable/etc.
GHABRA also discloses provided that an identifier specific to the device transmitted by the control unit of the vehicle to the system and a reference identifier specific to the vehicle stored in a database of the system are identical to a first identifier and second identifier transmitted by the user terminal to the system, respectively,
[0005] A phone as a key (PAK) vehicle access system can operate similarly as the stated PEPs system, except the vehicle is accessed using a mobile phone rather than a key fob. As an example, the mobile phone can communicate with a PAK module or a telematics control unit (TCU) in the vehicle to begin an access pairing process. The mobile phone and either the PAK module or the TCU perform the access pairing process to establish a trust relationship. The pairing process can include Bluetooth® pairing whereby: security information is exchanged between the mobile phone and the vehicle directly; a mobile phone address, a mobile phone identity resolving key, a reservation identifier and/or an encryption key are exchanged via a cloud-based network; and/or the mobile phone presents a certificate to the vehicle, where the certificate is signed by (i) the mobile phone, (ii) a trusted security signing authority such as a manufacturer of the vehicle, and/or (iii) a trusted third party. In the case of a certificate, the certificate can include an identifier of a person authorized to access a vehicle, an identifier of a cloud-based network authorized to transfer the certificate, an identifier of a rental or lease agreement of the vehicle, an identifier of the vehicle, a date and time period during which the vehicle is permitted for use by the authorized person, and/or other restrictions and/or access/license information.
requiring proximity between the user terminal and the device
[0064] As an example, the vehicle control module 204 may determine the location of the portable access device based on, for example, the patterns of the RSSI values corresponding to signals received from the portable access device by the antenna modules 38. A strong (or high) RSSI value indicates that the portable access device is close to the vehicle 30 and a weak (or low) RSSI value indicates that the portable access device is further away from the vehicle 30. By analyzing the RSSI values, the control module 204 may determine a location of and/or a distance to the portable access device relative to the vehicle 30. Additionally or alternatively, angle of arrival, angle of departure, round trip timing, unmodulated carrier tone exchange, or time difference of arrival measurements for the signals sent between the portable access device and the control module 204 may also be used by the control module 204 or the portable access device to determine the location of the portable access device. Additionally or alternatively, the antenna modules 38 may determine the location of and/or distance to the portable access device based on the measured information and communicate the location or distance to the control module 204.
[0065] Based on the determined location of or distance to the portable access device relative to the vehicle 30, the modules 211, 212 of FIG. 2 may then authorize and/or perform a vehicle function, such as unlocking a door of the vehicle 30, unlocking a trunk of the vehicle 30, starting the vehicle 30, and/or allowing the vehicle 30 to be started. As another example, if the portable access device is less than a first predetermined distance from the vehicle 30, the modules 211, 212 may activate interior or exterior lights of the vehicle 30. If the portable access device is less than a second predetermined distance from the vehicle 30, the modules 211, 212 may unlock doors or a trunk of the vehicle 30. If the portable access device is located inside of the vehicle 30, the modules 211, 212 may allow the vehicle 30 to be started. Based on the determined location of or distance to the portable access device relative to the vehicle 30, the polling reduction module 214 may also perform certain operations as further described below.
GHABRA also discloses wherein the first secret is configured to permit set-up of the secure communication channel between the control unit of the vehicle and the user terminal provided that a candidate password transmitted by the user terminal to the control unit of the vehicle matches the second secret
[0003] The PEPS module (i) performs an authentication process to determine if the key fob is authorized to access the vehicle, and (ii) determines a location of the key fob relative to the vehicle. The authentication process may include the exchange of an encrypted password or signature. If the password or signature is correct, then the key fob is determined to be authorized. Location of the key fob may be determined based on, for example, strength of a signal received from the key fob. If the key fob is authenticated and is located within an authorized zone of the vehicle, then access to the interior of the vehicle is permitted.
[0005] A phone as a key (PAK) vehicle access system can operate similarly as the stated PEPs system, except the vehicle is accessed using a mobile phone rather than a key fob. As an example, the mobile phone can communicate with a PAK module or a telematics control unit (TCU) in the vehicle to begin an access pairing process. The mobile phone and either the PAK module or the TCU perform the access pairing process to establish a trust relationship. The pairing process can include Bluetooth® pairing whereby: security information is exchanged between the mobile phone and the vehicle directly; a mobile phone address, a mobile phone identity resolving key, a reservation identifier and/or an encryption key are exchanged via a cloud-based network; and/or the mobile phone presents a certificate to the vehicle, where the certificate is signed by (i) the mobile phone, (ii) a trusted security signing authority such as a manufacturer of the vehicle, and/or (iii) a trusted third party. In the case of a certificate, the certificate can include an identifier of a person authorized to access a vehicle, an identifier of a cloud-based network authorized to transfer the certificate, an identifier of a rental or lease agreement of the vehicle, an identifier of the vehicle, a date and time period during which the vehicle is permitted for use by the authorized person, and/or other restrictions and/or access/license information.
GHABRA does not disclose, which HATTON discloses a first secret transmitted beforehand by a system to a device and after the device has received the first secret from the system (server to key fob transmission prior to the pairing of the key fob with the vehicle/device/phone, para 62, 68), the first identifier and second identifier being transmitted beforehand by the device to the user terminal via a wireless communication (transmission prior to the pairing of among the devices/ vehicle /phone, para 62, 68).
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by GHABRA to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing the key/secret/certificate of the key fob. The server or a remote device would provide the key/secret/certificate for the key fob, which would be stored in the key fob and would be available prior to pairing the key fob. The key/secret/certificate of the key fob would enable operating the device in a secure manner as the secret is not known to others, para 62, 68.
GHABRA and HATTON does not disclose, which Jakobsson discloses a password checker.
[0066] FIG. 4 is a block diagram of a computer system 400 suitable for implementing one or more embodiments of the present disclosure. In various implementations, computer system 400 may be used to check a password strength, communicate with a user, communicate with a password checker, or communicate with a system or site requiring password entry. The system or device may comprise a personal computing device (e.g., a personal computer, laptop, smart phone, PDA, Bluetooth device, key FOB, badge, etc.) capable of communicating with a network.
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by GHABRA to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing the password checker. What rules to apply and how to score the password depends on the password checker. The password check would enable verifying a number insertion that have a lower weight than a word insertion. Hence, the password check would enable ensuring higher score, to require strong password, para 36.
Claim(s) 7 is/are rejected under 35 U.S.C. 103 as being unpatentable over GHABRA, 20210209873 in view of HATTON et al., 20190143937, Jakobsson, 20120284783 and Voss, 20220210153.
Referring to claim(s) 7, GHABRA, Jakobsson and HATTON do not discloses wherein the device is a chip card, which Voss discloses, para 10. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by GHABRA to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing the chip card. The chip card being an alternative slim device would enable storing the secret/key/certificate so the vehicle functions such as open/close window/door lock/etc would be operated, para 10.
Response to Arguments
Remarks/Arguments filed 2/27/26, pages 8-13 have been fully considered but they are not persuasive. Therefore, rejection of claims 1-3, 6-10 is maintained.
Regarding the remarks for the amended claims, the rejections are addressed accordingly. Please refer to the updated rejections for the combined limitations.
Regarding the remarks, Ghabra is directed to a mobile device is provided and includes a sensor and a control module. The sensor is configured to detect movement of the mobile device. The control module is configured to: based on an output of the sensor, determine whether the mobile device is moving; when the mobile device is moving, transmit via a transceiver at least one signal to a vehicle indicating movement of the mobile device and an indication of presence of the mobile device; based on the at least one signal, receive an instruction signal or an information signal from the vehicle via the transceiver; based on the instruction signal or an information signal, at least one of reduce a polling rate of the mobile device, cease to indicate presence of the mobile device or transition to a sleep mode; and transition from the sleep mode to an awake mode in response to movement of the mobile device; the teachings of the Ghabra are not limited as concluded by the Applicant. Please see the relied potions of the Ghabra in the rejections.
With regard to the features of previous Claim 4 (now applicable to amended Claim 1), the Office Action does not mention if Ghabra discloses this feature is a prerequisite for "the second secret is transmitted to the user terminal by the system" as was required in Claim 4; the rejections are under 35 U.S.C. 103 rejections under obviousness. Ghabra does not mention that the second secret cannot be transmitted to the user terminal by the system before and/or after it. As per Ghabra the second secret can be transmitted in any sequence.
Hatton is directed to a method in which a vehicle that includes a paired or registered, key fob remote control capability has a wireless signal range extended by autonomous, remote web-based server and mobile phone. The Office Action cites to paragraphs [0062] and [0068] of Hatton, which are shown below. [0062] In response to key fob signals received from the remote server, which include AC(s) 285 and RCC(s) 290, the onboard controller(s) in other variations of vehicle 100 are configured to autonomously modify operation of at least one component of vehicle 100, according to the RCC(s) 290. The controller(s) of vehicle 100 according to the disclosure continuously monitor for, detect, and respond to such RCC(s) 290 and AC(s) 285 without user interaction, such that the autonomous capability is enabled. Such operation of the at least one component, components, and/or systems of vehicle 100, include for purposes of example without limitation, adjusting components and systems of vehicle 100 according to one or more driver preferences that may be stored in repository 180 and associated with key fob(s) 280, AC(s) 285, and/or RCC(s) 290. Such RCC(s) 290 include, for purposes of example without limitation, commands that at least one of lock or unlock a door or trunk of vehicle 100, start or power off engine 115 and/or EM 120, charge the battery(ies) 130, adjust a cabin temperature of vehicle 100, adjust passenger seat temperatures or positions, arm or disarm a security system, and adjust one or more other components, systems, and/or devices of vehicle 100, such as an infotainment system, according to driver preferences stored in repository 180, among others. [0068] The disclosure also contemplates the controller(s) of vehicle configured to respond to the mobile devices or NMDs 275 being configured as independent and/or standalone KFOB-NMDs 275, and to generate the key fob signals WS, which include the AC(s) 285 and/or RCC(s) 290. In this arrangement, the disclosure is directed to the KFOB-NMDs 275 being paired with and/or registering the key fobs 280 to receive and store both, the AC(s) 285, and the various possible RCC(s) 290 that are enabled by the original equipment key fobs 280. Further, such KFOB-mobile-devices 275 can then be utilized independent of key fobs 275, to generate and/or communicate AC(s) 285 and/or RCC(s) 290 from communication to remote server(s) and/or directly to the transceiver(s) WRTs 240 of vehicle 100. As with other adaptations, the controller(s) of vehicle 100 also monitor for, detect, and respond to the either of the key fobs 280 and/or the NMDs-as-key fobs or KFOB- NMDs 275, being in range and out of range of the vehicle transceivers WRTs 240, and to switch between monitoring for key fob signals WS directly from key fobs 280, NMDs 275, KFOB-NMDs 275, and/or remote server(s).
Hatton does disclose that the mobile device can be configured to have the same authentication codes (ACs 285) and remote control commands (RCCs 290) that the original key fob 280 utilizes.
However, Hatton does not disclose that anything equivalent to the first identifier and second identifier are transmitted beforehand by the device to the user terminal via a wireless communication, which then results in the "second secret" being transmitted later to the user terminal by the system, where it is the second secret that is used to authenticate the user terminal when the secure communication channel is being established.
The limitations, “ the first identifier and second identifier are transmitted beforehand by the device to the user terminal via a wireless communication, which then results in the "second secret" being transmitted later to the user terminal by the system, where it is the second secret that is used to authenticate the user terminal when the secure communication channel is being established”, are rejected by combined teachings of the cited references. In response to Remarks/Arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986).
Further, the rejections are made under 35 U.S.C. 103 obviousness, and Hatton does not mention to the first identifier and second identifier cannot be transmitted beforehand and/or after by the device to the user terminal via a wireless communication. The claimed subject matter also contains comprising which includes that the claim allows addition of the first identifier and second identifier to be transmitted after also. As, claimed first secret is not limited to different and/or same secret. The first claimed secret is not limited to characters, numbers, encrypted, code, etc., The second claimed secret is not limited to characters, numbers, encrypted, code, etc. The claimed first identifier, second identifier, reference identifier is not limited to any characters, numbers, encrypted, code, etc. Also, the claimed subject matter is not limited to that the first secret and the second secret is not used for initializing a secure communication several times, in which the first secret and/or second secret would be beforehand and/or after for setting up several secure communication channel.
HATTON discloses the relied upon limitations, a first secret transmitted beforehand by a system to a device and after the device has received the first secret from the system (server to key fob transmission prior to the pairing of the key fob with the vehicle/device/phone, para 62, 68), the first identifier and second identifier being transmitted beforehand by the device to the user terminal via a wireless communication (transmission prior to the pairing of among the devices/ vehicle /phone, para 62, 68).
Conclusion
As per the prosecution history, claims 3, 10 dated 3/19/24 were rejected under 35 U.S.C. 102(a)(1) as being anticipated by GHABRA, 20210209873 in office action dated 12/8/25. Claims 4, 5 dated 3/19/24 were rejected under 35 U.S.C. 103 rejections in office action dated 12/8/25. The claimed subject matter of the rejected claims 4 and 5 dated 3/19/24 is merely added in the independent claims dated 2/27/26.
The cited references do not limit that the communications must happen beforehand/after other processing.
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HARESH PATEL whose telephone number is (571)272-3973. The examiner can normally be reached on M-F 9-5:30.
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, Jorge L. Ortiz-Criado, can be reached at (571) 272-7624. The fax phone number for the organization where this application or proceeding is assigned is (571) 273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/HARESH N PATEL/Primary Examiner, Art Unit 2496