DETAILED ACTION
Notice of Pre-AIA or AIA Status
In the present application, filed on or after March 16, 2013, claims 1-20 have been considered and examined under the first inventor to file provisions of the AIA .
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 11/18/2024 is in compliance with the provision of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by Examiner.
Claim Rejections – 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. For example, claims 1-8 recite the limitations of “a method of enhancing smart key security for a vehicle, the method comprising: receiving, by a diagnostic device, a customer personal information number (PIN) code for a smart key registration; verifying, by a vehicle integrated controller, validity of the customer PIN code; encrypting and storing, by the vehicle integrated controller, the customer PIN code based on a result of verifying the validity of the customer PIN code; and displaying, by the diagnostic device, whether the smart key registration is completed based on a result of the storing of the customer PIN code.”
The limitation of receiving, by a diagnostic device, a customer personal information number (PIN) code; verifying, by a vehicle integrated controller, validity of the customer PIN code; encrypting and storing, by the vehicle integrated controller, the customer PIN code based on a result of verifying the validity of the customer PIN code; and displaying, by the diagnostic device, whether the smart key registration is completed based on a result of the storing of the customer PIN code, as drafted, is a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components. That is, other than reciting “by a diagnostic device” or “by a vehicle integrated controller” nothing in the claim element precludes the step from practically being performed in the mind. For example, but for the “by a diagnostic device” or “by a vehicle integrated controller” language, “receiving, verifying, encrypting and storing, and displaying” in the context of this claim encompasses the user manually perform verifying validity of the PIN code.
If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
This judicial exception is not integrated into a practical application. In particular, the claim only recites one additional element – using a processor to perform the receiving, verifying, encrypting and storing, and displaying steps. The processor in the steps is recited at a high-level of generality (i.e., as a generic processor performing a generic computer function of receiving, verifying, encrypting and storing, and displaying) such that it amounts no more than mere instructions to apply the exception using a generic computer component. Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea.
The claim is directed to an abstract idea. The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional element of using a processor to perform the receiving, verifying, encrypting and storing, and displaying steps amounts to no more than mere instructions to apply the exception using a generic computer component. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. The claim is not patent eligible.
Claims 9-16 and claims 17-20 are rejected for the same analysis as stated in the above analysis because claims 9-16 and 17-20 are directed to an abstract idea without significantly more.
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, 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.
Claims 1 and 9-16 are rejected under 35 U.S.C. 103 as being unpatentable over Brombach et al. (Brombach – US 2019/0047514 A) in view of Johnson et al. (Johnson – US 2020/0013241 A1).
As to claim 1, Brombach discloses a method of enhancing smart key security for a vehicle, the method comprising:
receiving, by a diagnostic device (Brombach: FIG. 1 the user device 106), a customer personal information number (PIN) code for a smart key registration (Brombach: [0018], [0029]-[0030], [0034]-[0036], [0044]-[0047], FIG. 1, and FIG. 3: a key for the vehicle 102 may be received, such as by the key manager 124 or the key service 128. The key may be in the form of a biometric, a password, or a token 134 of a user device 106. In an example, the key manager 124 may receive the key via the HMI 116 of the vehicle 102, or more particularly via the biometric reader 118 or the keypad 120 of the vehicle 102. Alternatively, the key manager 124 may receive the key from the user device 106, such as over the local area connection 133, automatically when the user device 106 enters within communication range for the local area connection 133, or when a user directs the user device 106, such as via user input to the app 132, to transmit the key over the local area connection 133);
verifying, by a vehicle integrated controller (FIG. 1 the access controller 110), validity of the customer PIN code (Brombach: [0045]-[0046], [0065]-[0066], FIG. 1, and FIG. 3: a determination may be made of whether the received key is valid. For example, the key manager 124 or the key service 128 may perform one or more validity checks, such as checking that the key is in a valid format. Furthermore, the key manager 124 or the key service 128 may query the key database 126 or the server database 130, respectively, to determine whether the received key is registered with the vehicle 102. Responsive to determining that the received key fails one or more validity checks (“No” branch of block 304), an “invalid key” message may be displayed in block 306, such as via the display 121 of the vehicle 102 or a display of the user device 106…Responsive to determining that the received key is valid (“Yes” branch of block 304), in block 308, a status for the received key may be determined);
storing, by the vehicle integrated controller, the customer PIN code based on a result of verifying the validity of the customer PIN code (Brombach: [0045]-[0046], [0065]-[0066], FIG. 1, and FIG. 3-4: the screen 400 may include a passcode display element 402 that provides the current passcode of a received key, namely “1-9-6-2”. A user may interact with the passcode display element and input a new passcode. The screen 400 may also include a save object 404 and a clear object 406. Interaction with the save object 404 may cause an updated passcode entered into the passcode display element 402 to be stored in the key database 126 and/or the server database 130 (e.g., block 314) as an operable key); and
displaying, by the diagnostic device, whether the smart key registration is completed based on a result of the storing of the customer PIN code (Brombach: [0045]-[0046], [0065]-[0066], FIG. 1, and FIG. 3-4: the screen 400 may include a passcode display element 402 that provides the current passcode of a received key, namely “1-9-6-2”. A user may interact with the passcode display element and input a new passcode. The screen 400 may also include a save object 404 and a clear object 406. Interaction with the save object 404 may cause an updated passcode entered into the passcode display element 402 to be stored in the key database 126 and/or the server database 130 (e.g., block 314) as an operable key).
Brombach does not explicitly disclose encrypting the customer PIN code.
However, it has been known in the art of key managements to implement encrypting the customer PIN code, as suggested by Johnson, which discloses encrypting the customer PIN code (Johnson: Abstract, [0022], [0024]-[0026], [0041]-[0043], [0047]-[0049], and FIG. 1-2: the server adapted to identify a set of unique information based on the set of captured communications, and to store the set of unique information in the encrypted data store).
Therefore, in view of teachings by Brombach and Johnson, it would have been obvious to one of the ordinary skill in the art before ethe effective filing date of the claimed invention to implement in the key management of Brombach to include encrypting the customer PIN code, as suggested by Johnson. The motivation for this is to secure collected information.
As to claim 9, Brombach discloses a method of enhancing smart key security for a vehicle, the method comprising:
receiving, by a diagnostic device (Brombach: FIG. 1 the user device 106), a customer personal information number (PIN) code for smart key registration (Brombach: [0018], [0029]-[0030], [0034]-[0036], [0044]-[0047], FIG. 1, and FIG. 3: a key for the vehicle 102 may be received, such as by the key manager 124 or the key service 128. The key may be in the form of a biometric, a password, or a token 134 of a user device 106. In an example, the key manager 124 may receive the key via the HMI 116 of the vehicle 102, or more particularly via the biometric reader 118 or the keypad 120 of the vehicle 102. Alternatively, the key manager 124 may receive the key from the user device 106, such as over the local area connection 133, automatically when the user device 106 enters within communication range for the local area connection 133, or when a user directs the user device 106, such as via user input to the app 132, to transmit the key over the local area connection 133);
receiving, by the diagnostic device, driver specific information for authentication (Brombach: [0016], [0025], [0027]-[0029], [0044], FIG. 1, and FIG. 3: The user device 106 may be configured to store the token 134 such that a user is unable to view and/or modify the token 134, and may be configured to transmit the token 134 to the vehicle 102 responsive to the user device 106 coming into local communication range of the vehicle 102. In some instances, the user device 106 may also include a keypad and/or biometric reader (not shown), and a user may cause the user device 106, via interaction with an app 132 installed thereon, to wirelessly transmit the token 134, a biometric read by the biometric reader of the user device 106, and/or a passcode entered into the keypad of the user device 106, to the vehicle 102);
performing, by a vehicle integrated controller, an authentication using the driver specific information (Brombach: Abstract, [0025], [0028]-[0031], [0045]-[0046], and FIG. 1: In some instances, the biometric reader 118 and the keypad 120 may include an external portion accessible from outside the vehicle 102, and an internal portion accessible from inside the vehicle 102. The external portion may be for unlocking the vehicle 102 based on a received biometric or passcode, and the internal portion may be for starting the vehicle 102 based on a received biometric or passcode);
verifying, by the vehicle integrated controller (Brombach: FIG. 1 the access controller 110), validity of the customer PIN code based on a result of the authentication (Brombach: [0045]-[0046], [0065]-[0066], FIG. 1, and FIG. 3: a determination may be made of whether the received key is valid. For example, the key manager 124 or the key service 128 may perform one or more validity checks, such as checking that the key is in a valid format. Furthermore, the key manager 124 or the key service 128 may query the key database 126 or the server database 130, respectively, to determine whether the received key is registered with the vehicle 102. Responsive to determining that the received key fails one or more validity checks (“No” branch of block 304), an “invalid key” message may be displayed in block 306, such as via the display 121 of the vehicle 102 or a display of the user device 106…Responsive to determining that the received key is valid (“Yes” branch of block 304), in block 308, a status for the received key may be determined);
storing, by the vehicle integrated controller, the customer PIN code based on a result of verifying the validity of the customer PIN code (Brombach: [0045]-[0046], [0065]-[0066], FIG. 1, and FIG. 3-4: the screen 400 may include a passcode display element 402 that provides the current passcode of a received key, namely “1-9-6-2”. A user may interact with the passcode display element and input a new passcode. The screen 400 may also include a save object 404 and a clear object 406. Interaction with the save object 404 may cause an updated passcode entered into the passcode display element 402 to be stored in the key database 126 and/or the server database 130 (e.g., block 314) as an operable key); and
displaying, by the diagnostic device, whether the smart key registration is completed based on a result of the storing of the customer PIN code (Brombach: [0045]-[0046], [0065]-[0066], FIG. 1, and FIG. 3-4: the screen 400 may include a passcode display element 402 that provides the current passcode of a received key, namely “1-9-6-2”. A user may interact with the passcode display element and input a new passcode. The screen 400 may also include a save object 404 and a clear object 406. Interaction with the save object 404 may cause an updated passcode entered into the passcode display element 402 to be stored in the key database 126 and/or the server database 130 (e.g., block 314) as an operable key).
Brombach does not explicitly disclose encrypting the customer PIN code.
However, it has been known in the art of key managements to implement encrypting the customer PIN code, as suggested by Johnson, which discloses encrypting the customer PIN code (Johnson: Abstract, [0022], [0024]-[0026], [0041]-[0043], [0047]-[0049], and FIG. 1-2: the server adapted to identify a set of unique information based on the set of captured communications, and to store the set of unique information in the encrypted data store).
Therefore, in view of teachings by Brombach and Johnson, it would have been obvious to one of the ordinary skill in the art before ethe effective filing date of the claimed invention to implement in the key management of Brombach to include encrypting the customer PIN code, as suggested by Johnson. The motivation for this is to secure collected information.
As to claim 10, Brombach and Johnson discloses the limitations of claim 9 further comprising the method of claim 9, wherein the driver specific information includes at least one of an original equipment manufacturer (OEM) PIN code (Johnson: Abstract, [0023]-[0025], [0038]-[0040], [0058]-[0059], and FIG. 1-2: The system works by storing a copy of the data from an OEM key along with other information necessary to replace the OEM key in a key bank. The data collected is processed and stored such that a customer can order a universal replacement from the key bank programmed with the stored data to emulate the prior paired OEM key), a vehicle identification number (VIN) (Johnson: Abstract, [0023]-[0025], [0038]-[004], [0043], [0057]-[0059], [0062], and FIG. 1-4: For any type of key enrollment and data capture for the Key Bank service, the VIN capture 410 is performed. In the VIN capture 410 process, a user or technician records the VIN manually or takes a picture of the VIN or VIN barcode on the vehicle at step 412. In step 414, the VIN is securely uploaded or transmitted to the Key Bank servers. The VIN is then encrypted and securely stored at step 416 until a replacement URHK is needed), ordering customer information, or a combination thereof.
As to claim 11, Brombach and Johnson discloses the limitations of claim 10 further comprising the method of claim 10, wherein the driver specific information includes a portion of a serial VIN (Johnson: Abstract, [0023]-[0025], [0038]-[004], [0043], [0057]-[0059], [0062], and FIG. 1-4: The set of unique information includes transponder information associated with the key being analyzed, vehicle security information, i.e., rolling code encryption keys and states, a unique PIN code used in a pairing process, and the vehicle under test 20 VIN code. The set of unique information is supplemented with a set of customer information 26 and is stored in the encrypted data storage 14. The Key Bank server 12 transmits the information stored in the encrypted data storage 14 to the key generation device 30 when it receives an authenticated signal or request for a replacement vehicle key from the customer 18).
As to claim 12, Brombach and Johnson discloses the limitations of claim 10 further comprising the method of claim 10, wherein performing the authentication comprises:
transmitting, by the diagnostic device, the driver specific information to a logic processing module of the vehicle integrated controller (Brombach: [0016], [0025], [0027]-[0029], [0044], FIG. 1, and FIG. 3: The user device 106 may be configured to store the token 134 such that a user is unable to view and/or modify the token 134, and may be configured to transmit the token 134 to the vehicle 102 responsive to the user device 106 coming into local communication range of the vehicle 102. In some instances, the user device 106 may also include a keypad and/or biometric reader (not shown), and a user may cause the user device 106, via interaction with an app 132 installed thereon, to wirelessly transmit the token 134, a biometric read by the biometric reader of the user device 106, and/or a passcode entered into the keypad of the user device 106, to the vehicle 102);
transmitting, by the logic processing module, the driver specific information and a pre-stored default value to a security processing module of the vehicle integrated controller (Brombach: [0016], [0025], [0027]-[0029], [0044], FIG. 1, and FIG. 3: The user device 106 may be configured to store the token 134 such that a user is unable to view and/or modify the token 134, and may be configured to transmit the token 134 to the vehicle 102 responsive to the user device 106 coming into local communication range of the vehicle 102. In some instances, the user device 106 may also include a keypad and/or biometric reader (not shown), and a user may cause the user device 106, via interaction with an app 132 installed thereon, to wirelessly transmit the token 134, a biometric read by the biometric reader of the user device 106, and/or a passcode entered into the keypad of the user device 106, to the vehicle 102);
verifying, by the security processing module, equality on the driver specific information and the default value (Brombach: [0025], [0028]-[0031], [0045]-[0046], and FIG. 1: a determination may be made of whether the received key is valid. For example, the key manager 124 or the key service 128 may perform one or more validity checks, such as checking that the key is in a valid format. Furthermore, the key manager 124 or the key service 128 may query the key database 126 or the server database 130, respectively, to determine whether the received key is registered with the vehicle 102. Responsive to determining that the received key fails one or more validity checks (“No” branch of block 304), an “invalid key” message may be displayed in block 306, such as via the display 121 of the vehicle 102 or a display of the user device 106…Responsive to determining that the received key is valid (“Yes” branch of block 304), in block 308, a status for the received key may be determined ); and
transmitting, by the security processing module, a result of verifying the equality to the diagnostic device via the logic processing module (Brombach: 0025], [0028]-[0031], [0045]-[0046], and FIG. 3-8: accordingly, responsive to determining that a received key is registered with the vehicle 102, and to identifying one or more vehicle features enabled and/or disabled for the key, the access control module 122 may be configured to enable the vehicle features enabled for the key, and to disable vehicle features that are restricted or disabled for the key within the key database 126. For example, the access control module 122 may be configured to send enabling signals to controllers 112 to enable those vehicle features enabled for the key within the key database 126, and/or may be configured to send disabling control signals to the controllers 112 to disable vehicle features that are disabled for the key within the key database 126).
As to claim 13, Brombach and Johnson discloses the limitations of claim 12 further comprising the method of claim 12, wherein receiving the driver specific information for authentication comprises: displaying, by the diagnostic device, a user interface (UI) allowing the OEM PIN code to be entered (Brombach: [0045]-[0046], [0065]-[0066], FIG. 1, and FIG. 3-4: the screen 400 may include a passcode display element 402 that provides the current passcode of a received key, namely “1-9-6-2”. A user may interact with the passcode display element and input a new passcode. The screen 400 may also include a save object 404 and a clear object 406. Interaction with the save object 404 may cause an updated passcode entered into the passcode display element 402 to be stored in the key database 126 and/or the server database 130 (e.g., block 314) as an operable key and Johnson: Abstract, [0023]-[0025], [0038]-[0040], [0058]-[0059], and FIG. 1-2: The system works by storing a copy of the data from an OEM key along with other information necessary to replace the OEM key in a key bank. The data collected is processed and stored such that a customer can order a universal replacement from the key bank programmed with the stored data to emulate the prior paired OEM key); and transmitting, by the diagnostic device, the OEM PIN code entered via the user interface to the logic processing module (Brombach: [0045]-[0046], [0065]-[0066], FIG. 1, and FIG. 3-4: the screen 400 may include a passcode display element 402 that provides the current passcode of a received key, namely “1-9-6-2”. A user may interact with the passcode display element and input a new passcode. The screen 400 may also include a save object 404 and a clear object 406. Interaction with the save object 404 may cause an updated passcode entered into the passcode display element 402 to be stored in the key database 126 and/or the server database 130 (e.g., block 314) as an operable key and Johnson: Abstract, [0023]-[0025], [0038]-[0040], [0058]-[0059], and FIG. 1-2: The system works by storing a copy of the data from an OEM key along with other information necessary to replace the OEM key in a key bank. The data collected is processed and stored such that a customer can order a universal replacement from the key bank programmed with the stored data to emulate the prior paired OEM key).
As to claim 14, Brombach and Johnson discloses the limitations of claim 13 further comprising the method of claim 13, further comprising: when a value of the OEM PIN code and a value of a default OEM PIN code are the same, transmitting, by the security processing module, a positive response to the logic processing module (Brombach: [0045]-[0046], [0065]-[0066], FIG. 1, and FIG. 3-4: the screen 400 may include a passcode display element 402 that provides the current passcode of a received key, namely “1-9-6-2”. A user may interact with the passcode display element and input a new passcode. The screen 400 may also include a save object 404 and a clear object 406. Interaction with the save object 404 may cause an updated passcode entered into the passcode display element 402 to be stored in the key database 126 and/or the server database 130 (e.g., block 314) as an operable key and Johnson: Abstract, [0023]-[0025], [0038]-[0040], [0058]-[0059], and FIG. 1-2: The system works by storing a copy of the data from an OEM key along with other information necessary to replace the OEM key in a key bank. The data collected is processed and stored such that a customer can order a universal replacement from the key bank programmed with the stored data to emulate the prior paired OEM key).
As to claim 15, Brombach and Johnson discloses the limitations of claim 13 further comprising the method of claim 13, further comprising: when a value of the OEM PIN code and a value of a default OEM PIN code are different, transmitting, by the security processing module, a negative response to the logic processing module (Brombach: [0045]-[0046], [0065]-[0066], FIG. 1, and FIG. 3-4: the screen 400 may include a passcode display element 402 that provides the current passcode of a received key, namely “1-9-6-2”. A user may interact with the passcode display element and input a new passcode. The screen 400 may also include a save object 404 and a clear object 406. Interaction with the save object 404 may cause an updated passcode entered into the passcode display element 402 to be stored in the key database 126 and/or the server database 130 (e.g., block 314) as an operable key and Johnson: Abstract, [0023]-[0025], [0038]-[0040], [0058]-[0059], and FIG. 1-2: The system works by storing a copy of the data from an OEM key along with other information necessary to replace the OEM key in a key bank. The data collected is processed and stored such that a customer can order a universal replacement from the key bank programmed with the stored data to emulate the prior paired OEM key).
As to claim 16, Brombach and Johnson discloses the limitations of claim 12 further comprising the method of claim 12, wherein the default value includes a value stored to correspond to the driver specific information at a time of initial vehicle production (Brombach: [0027], [0031]-[0032], [0034], [0045]-[0048], and FIG. 3).
Claims 2-7 and 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over Brombach et al. (Brombach – US 10,293,787 B2) in view of Johnson et al. (Johnson – US 2020/0013241 A1) and further in view of Gervais et al. (Gervais – US 2020/0111097 A1).
As to claim 2, Brombach and Johnson disclose the limitations of claim 1 except for the claimed limitations of the method of claim 1, wherein receiving the customer PIN code comprises:
transmitting, by the diagnostic device, customer PIN code entry request information to a logic processing module of the vehicle integrated controller to request the customer PIN code be entered;
transmitting, by the logic processing module, the customer PIN code entry request information to a security processing module of the vehicle integrated controller;
confirming, by the security processing module, customer PIN code assignment information assigned for the customer PIN code based on the customer PIN code entry request information; and
transmitting, by the security processing module, response information to the diagnostic device via the logic processing module.
However, it has been known in the art of authentication users to implement wherein receiving the customer PIN code comprises:
transmitting, by the diagnostic device, customer PIN code entry request information to a logic processing module of the vehicle integrated controller to request the customer PIN code be entered;
transmitting, by the logic processing module, the customer PIN code entry request information to a security processing module of the vehicle integrated controller;
confirming, by the security processing module, customer PIN code assignment information assigned for the customer PIN code based on the customer PIN code entry request information; and
transmitting, by the security processing module, response information to the diagnostic device via the logic processing module, as suggested by Gervais, which discloses wherein receiving the customer PIN code comprises:
transmitting, by the diagnostic device, customer PIN code entry request information to a logic processing module of the vehicle integrated controller to request the customer PIN code be entered (Gervais: Abstract, [0024], [0044], [0064]-[0066], [0076]-[0081], FIG. 2-3 the processing unit 126, FIG. 5, and FIG. 10-13 the change PIN 1106: The interface 1200 also includes a context indicator 1206, which provides information about the context of the currently displayed interface 1200. In this case, the context indicator 1206 indicates that the interface 1200 is part of the interface sequence for changing an authentication code. The interface 1200 may also provide information 1208 that may help to guide user selection of a new authentication code);
transmitting, by the logic processing module, the customer PIN code entry request information to a security processing module of the vehicle integrated controller (Gervais: Abstract, [0024], [0044], [0064]-[0066], [0076]-[0081], FIG. 2-3 3 the processing unit 126, FIG. 5, and FIG. 10-13: the automated device compares the first input into the first field 1202 with the second input into the second field 1204. If the first input and the second input are different, the automated device may generate an output (e.g., a visual display) to indicate that the first and second inputs do not match and to request the user to input the new authentication code again into the fields 1202, 1204);
confirming, by the security processing module, customer PIN code assignment information assigned for the customer PIN code based on the customer PIN code entry request information (Gervais: Abstract, [0024], [0044], [0064]-[0066], [0076]-[0081], FIG. 2-3 3 the processing unit 126, FIG. 5, and FIG. 10-13: If the first input and the second input match, then the automated device at 512 transmits the inputted new authentication code to the server…the server then updates the account to be associated with the new authentication code. After the server has completed the update, the server transmits a signal to the automated device to indicate that the authentication code was successfully changed to the new authentication code); and
transmitting, by the security processing module, response information to the diagnostic device via the logic processing module (Gervais: Abstract, [0024], [0044], [0064]-[0066], [0076]-[0083], FIG. 2-3 3 the processing unit 126, FIG. 5, and FIG. 10-13: the server then updates the account to be associated with the new authentication code. After the server has completed the update, the server transmits a signal to the automated device to indicate that the authentication code was successfully changed to the new authentication code).
Therefore, in view of teachings by Brombach, Johnson, and Gervais, it would have been obvious to one of the ordinary skill in the art before ethe effective filing date of the claimed invention to implement in the key management of Brombach and Johnson, to include wherein receiving the customer PIN code comprises:
transmitting, by the diagnostic device, customer PIN code entry request information to a logic processing module of the vehicle integrated controller to request the customer PIN code be entered;
transmitting, by the logic processing module, the customer PIN code entry request information to a security processing module of the vehicle integrated controller;
confirming, by the security processing module, customer PIN code assignment information assigned for the customer PIN code based on the customer PIN code entry request information; and
transmitting, by the security processing module, response information to the diagnostic device via the logic processing module, as suggested by Gervais. The motivation for this is to allow users to update/create authentication code for his/her account.
As to claim 3, Brombach, Johnson, and Gervais disclose the limitations of claim 2 further comprising the method of claim 2, wherein receiving the customer PIN code comprises:
displaying, by the diagnostic device, a user interface (UI) allowing the customer PIN code to be entered based on the response information (Brombach: [0045]-[0046], [0065]-[0066], FIG. 1, and FIG. 3-4: the screen 400 may include a passcode display element 402 that provides the current passcode of a received key, namely “1-9-6-2”. A user may interact with the passcode display element and input a new passcode. The screen 400 may also include a save object 404 and a clear object 406. Interaction with the save object 404 may cause an updated passcode entered into the passcode display element 402 to be stored in the key database 126 and/or the server database 130 (e.g., block 314) as an operable key and Gervais: Abstract, [0024], [0044], [0064]-[0066], [0076]-[0081], FIG. 2-3 3 the processing unit 126, FIG. 5, and FIG. 10-13: the automated device compares the first input into the first field 1202 with the second input into the second field 1204. If the first input and the second input are different, the automated device may generate an output (e.g., a visual display) to indicate that the first and second inputs do not match and to request the user to input the new authentication code again into the fields 1202, 1204); and
transmitting, by the diagnostic device, the customer PIN code entered via the user interface to the logic processing module (Gervais: Abstract, [0024], [0044], [0064]-[0066], [0076]-[0081], FIG. 2-3 3 the processing unit 126, FIG. 5, and FIG. 10-13: If the first input and the second input match, then the automated device at 512 transmits the inputted new authentication code to the server…the server then updates the account to be associated with the new authentication code. After the server has completed the update, the server transmits a signal to the automated device to indicate that the authentication code was successfully changed to the new authentication code).
As to claim 4, Brombach, Johnson, and Gervais disclose the limitations of claim 3 further comprising the method of claim 3, wherein encrypting and storing the customer PIN code comprises:
performing, by the logic processing module, validation for the entered customer PIN code (Brombach: [0045]-[0046], [0065]-[0066], FIG. 1, FIG. 3-4 and FIG. 8: the screen 400 may include a passcode display element 402 that provides the current passcode of a received key, namely “1-9-6-2”. A user may interact with the passcode display element and input a new passcode. The screen 400 may also include a save object 404 and a clear object 406. Interaction with the save object 404 may cause an updated passcode entered into the passcode display element 402 to be stored in the key database 126 and/or the server database 130 (e.g., block 314) as an operable key and Gervais: Abstract, [0024], [0044], [0064]-[0066], [0076]-[0081], FIG. 2-3 3 the processing unit 126, FIG. 5, and FIG. 10-13: If the first input and the second input match, then the automated device at 512 transmits the inputted new authentication code to the server…the server then updates the account to be associated with the new authentication code. After the server has completed the update, the server transmits a signal to the automated device to indicate that the authentication code was successfully changed to the new authentication code);
providing, by the logic processing module, the security processing module with an encryption request based on a result of the validation ( Johnson: Abstract, [0022], [0024]-[0026], [0041]-[0043], [0047]-[0049], and FIG. 1-2: the server adapted to identify a set of unique information based on the set of captured communications, and to store the set of unique information in the encrypted data store and Gervais: Abstract, [0024], [0044], [0064]-[0066], [0076]-[0081], FIG. 2-3 3 the processing unit 126, FIG. 5, and FIG. 10-13: If the first input and the second input match, then the automated device at 512 transmits the inputted new authentication code to the server…the server then updates the account to be associated with the new authentication code. After the server has completed the update, the server transmits a signal to the automated device to indicate that the authentication code was successfully changed to the new authentication code);
generating, by the security processing module, an encryption key for the entered customer PIN code in response to the encryption request (Johnson: Abstract, [0022], [0024]-[0026], [0041]-[0043], [0047]-[0049], and FIG. 1-2: the server adapted to identify a set of unique information based on the set of captured communications, and to store the set of unique information in the encrypted data store and Gervais: Abstract, [0024], [0044], [0064]-[0066], [0076]-[0081], FIG. 2-3 3 the processing unit 126, FIG. 5, and FIG. 10-13: If the first input and the second input match, then the automated device at 512 transmits the inputted new authentication code to the server…the server then updates the account to be associated with the new authentication code. After the server has completed the update, the server transmits a signal to the automated device to indicate that the authentication code was successfully changed to the new authentication code); and
returning, by the security processing module, the encryption key to the logic processing module to store the encryption key therein (Johnson: Abstract, [0022], [0024]-[0026], [0041]-[0043], [0047]-[0049], and FIG. 1-2: the server adapted to identify a set of unique information based on the set of captured communications, and to store the set of unique information in the encrypted data store).
As to claim 5, Brombach, Johnson, and Gervais disclose the limitations of claim 4 further comprising the method of claim 4, wherein performing the validation comprises determining whether the entered customer PIN code is a PIN code having at least a predetermined number of digits and including two or more character (Brombach: [0045]-[0046], [0065]-[0066], FIG. 1, and FIG. 3-4: a determination may be made of whether the received key is valid. For example, the key manager 124 or the key service 128 may perform one or more validity checks, such as checking that the key is in a valid format. Furthermore, the key manager 124 or the key service 128 may query the key database 126 or the server database 130, respectively, to determine whether the received key is registered with the vehicle 102. Responsive to determining that the received key fails one or more validity checks (“No” branch of block 304), an “invalid key” message may be displayed in block 306, such as via the display 121 of the vehicle 102 or a display of the user device 106…the screen 400 may include a passcode display element 402 that provides the current passcode of a received key, namely “1-9-6-2”. A user may interact with the passcode display element and input a new passcode. The screen 400 may also include a save object 404 and a clear object 406. Interaction with the save object 404 may cause an updated passcode entered into the passcode display element 402 to be stored in the key database 126 and/or the server database 130 (e.g., block 314) as an operable key and Gervais: Abstract, [0024], [0044], [0064]-[0066], [0076]-[0081], FIG. 2-3 3 the processing unit 126, FIG. 5, and FIG. 10-13: the automated device compares the first input into the first field 1202 with the second input into the second field 1204. If the first input and the second input are different, the automated device may generate an output (e.g., a visual display) to indicate that the first and second inputs do not match and to request the user to input the new authentication code again into the fields 1202, 1204).
As to claim 6, Brombach, Johnson, and Gervais disclose the limitations of claim 4 further comprising the method of claim 4, wherein the entered customer PIN code comprises an initially entered customer PIN code and a re-entered customer PIN code (Brombach: [0045]-[0046], [0065]-[0066], FIG. 1, and FIG. 3-4: a determination may be made of whether the received key is valid. For example, the key manager 124 or the key service 128 may perform one or more validity checks, such as checking that the key is in a valid format. Furthermore, the key manager 124 or the key service 128 may query the key database 126 or the server database 130, respectively, to determine whether the received key is registered with the vehicle 102. Responsive to determining that the received key fails one or more validity checks (“No” branch of block 304), an “invalid key” message may be displayed in block 306, such as via the display 121 of the vehicle 102 or a display of the user device 106…the screen 400 may include a passcode display element 402 that provides the current passcode of a received key, namely “1-9-6-2”. A user may interact with the passcode display element and input a new passcode. The screen 400 may also include a save object 404 and a clear object 406. Interaction with the save object 404 may cause an updated passcode entered into the passcode display element 402 to be stored in the key database 126 and/or the server database 130 (e.g., block 314) as an operable key and Gervais: Abstract, [0024], [0044], [0064]-[0066], [0076]-[0081], FIG. 2-3 3 the processing unit 126, FIG. 5, and FIG. 10-13: the automated device compares the first input into the first field 1202 with the second input into the second field 1204. If the first input and the second input are different, the automated device may generate an output (e.g., a visual display) to indicate that the first and second inputs do not match and to request the user to input the new authentication code again into the fields 1202, 1204).
As to claim 7, Brombach, Johnson, and Gervais disclose the limitations of claim 6 further comprising the method of claim 6, wherein performing the validation comprises determining whether a value of the initially entered customer PIN code matches a value of the re-entered customer PIN code (Gervais: Abstract, [0024], [0044], [0064]-[0066], [0076]-[0081], FIG. 2-3 3 the processing unit 126, FIG. 5, and FIG. 10-13: If the first input and the second input match, then the automated device at 512 transmits the inputted new authentication code to the server…the server then updates the account to be associated with the new authentication code. After the server has completed the update, the server transmits a signal to the automated device to indicate that the authentication code was successfully changed to the new authentication code).
As to claim 17, Brombach discloses a method of enhancing smart key security for a vehicle, the method comprising:
receiving, by the diagnostic device (Brombach: FIG. 1 the user device 106), a re-entered customer PIN code (Brombach: [0018], [0029]-[0030], [0034]-[0036], [0044]-[0047], FIG. 1, and FIG. 3: a key for the vehicle 102 may be received, such as by the key manager 124 or the key service 128. The key may be in the form of a biometric, a password, or a token 134 of a user device 106. In an example, the key manager 124 may receive the key via the HMI 116 of the vehicle 102, or more particularly via the biometric reader 118 or the keypad 120 of the vehicle 102. Alternatively, the key manager 124 may receive the key from the user device 106, such as over the local area connection 133, automatically when the user device 106 enters within communication range for the local area connection 133, or when a user directs the user device 106, such as via user input to the app 132, to transmit the key over the local area connection 133);
verifying, by the vehicle integrated controller (FIG. 1 the access controller 110), validity of the customer PIN code (Brombach: [0045]-[0046], [0065]-[0066], FIG. 1, and FIG. 3: a determination may be made of whether the received key is valid. For example, the key manager 124 or the key service 128 may perform one or more validity checks, such as checking that the key is in a valid format. Furthermore, the key manager 124 or the key service 128 may query the key database 126 or the server database 130, respectively, to determine whether the received key is registered with the vehicle 102. Responsive to determining that the received key fails one or more validity checks (“No” branch of block 304), an “invalid key” message may be displayed in block 306, such as via the display 121 of the vehicle 102 or a display of the user device 106…Responsive to determining that the received key is valid (“Yes” branch of block 304), in block 308, a status for the received key may be determined);
storing, by the vehicle integrated controller, the customer PIN code based on a result of verifying the validity of the customer PIN code (Brombach: [0045]-[0046], [0065]-[0066], FIG. 1, and FIG. 3-4: the screen 400 may include a passcode display element 402 that provides the current passcode of a received key, namely “1-9-6-2”. A user may interact with the passcode display element and input a new passcode. The screen 400 may also include a save object 404 and a clear object 406. Interaction with the save object 404 may cause an updated passcode entered into the passcode display element 402 to be stored in the key database 126 and/or the server database 130 (e.g., block 314) as an operable key); and
displaying, by the diagnostic device, whether the smart key registration is completed based on a result of the storing of the customer PIN code (Brombach: [0045]-[0046], [0065]-[0066], FIG. 1, and FIG. 3-4: the screen 400 may include a passcode display element 402 that provides the current passcode of a received key, namely “1-9-6-2”. A user may interact with the passcode display element and input a new passcode. The screen 400 may also include a save object 404 and a clear object 406. Interaction with the save object 404 may cause an updated passcode entered into the passcode display element 402 to be stored in the key database 126 and/or the server database 130 (e.g., block 314) as an operable key).
Brombach does not explicitly disclose after an initially entered customer personal information number (PIN) code for smart key registration is generated, receiving, by a diagnostic device, the initially entered customer PIN code in response to a customer PIN code change request from a driver;
verifying, by a vehicle integrated controller, equality on the initially entered customer PIN code and a pre-stored customer PIN code in response to the customer PIN code change request;
receiving, by the diagnostic device, a re-entered customer PIN code based on a result of verifying the equality;
register the re-entered customer PIN code and the customer PIN code; and
encrypting the customer PIN code.
However, it has been known in the art of key managements to implement encrypting the customer PIN code, as suggested by Johnson, which discloses encrypting the customer PIN code (Johnson: Abstract, [0022], [0024]-[0026], [0041]-[0043], [0047]-[0049], and FIG. 1-2: the server adapted to identify a set of unique information based on the set of captured communications, and to store the set of unique information in the encrypted data store).
Therefore, in view of teachings by Brombach and Johnson, it would have been obvious to one of the ordinary skill in the art before ethe effective filing date of the claimed invention to implement in the key management of Brombach to include encrypting the customer PIN code, as suggested by Johnson. The motivation for this is to secure collected information.
The combination of Brombach and Johnson does not explicitly disclose after an initially entered customer personal information number (PIN) code for smart key registration is generated, receiving, by a diagnostic device, the initially entered customer PIN code in response to a customer PIN code change request from a driver;
verifying, by a vehicle integrated controller, equality on the initially entered customer PIN code and a pre-stored customer PIN code in response to the customer PIN code change request;
receiving, by the diagnostic device, a re-entered customer PIN code based on a result of verifying the equality; and
register the re-entered customer PIN code and the customer PIN code.
However, it has been known in the art of authentication users to implement after an initially entered customer personal information number (PIN) code for smart key registration is generated, receiving, by a diagnostic device, the initially entered customer PIN code in response to a customer PIN code change request from a driver;
verifying, by a vehicle integrated controller, equality on the initially entered customer PIN code and a pre-stored customer PIN code in response to the customer PIN code change request;
receiving, by the diagnostic device, a re-entered customer PIN code based on a result of verifying the equality; and
register the re-entered customer PIN code and the customer PIN code, as suggested by Gervais, which discloses
after an initially entered customer personal information number (PIN) code for smart key registration is generated (Gervais: [0057]-[0059] and FIG. 8: The interface 800 provides a field 802 for entry of an authentication code (e.g., PIN) associated with the account. For example, a user may use the keypad of the automated device to provide input into the field 802. The keypad may also provide the ability to backspace or cancel input. Other input mechanisms may also be used. The interface 800 provides a confirmation button 804 to confirm entry of the authentication code. The interface 800 also provides the general options 710 as discussed above. When the confirmation button 804 is selected, the input into the field 802 is received by the automated device. In some examples, instead of selecting the confirmation button 804, the user may use a physical button (e.g., a physical confirmation button or “OK” button, which may be part of the keypad) to confirm entry of the authentication code), receiving, by a diagnostic device, the initially entered customer PIN code in response to a customer PIN code change request from a driver (Gervais: [0074]-[008], FIG. 2-3 the processing unit 126, FIG. 5, and FIG. 10-13 the change PIN 1106 and the current PIN 1102: The interface 1200 also includes a context indicator 1206, which provides information about the context of the currently displayed interface 1200. In this case, the context indicator 1206 indicates that the interface 1200 is part of the interface sequence for changing an authentication code. The interface 1200 may also provide information 1208 that may help to guide user selection of a new authentication code);
verifying, by a vehicle integrated controller, equality on the initially entered customer PIN code and a pre-stored customer PIN code in response to the customer PIN code change request (Gervais: [0074]-[008], FIG. 2-3 the processing unit 126, FIG. 5, and FIG. 10-13 the change PIN 1106 and the current PIN 1102: when input is received via the interface 1100 (e.g., an entry has been inputted into the field 1102 and the confirmation button 1104 has been selected), the automated device at 506 transmits a signal to a server (e.g., a server associated with the service provider that owns the automated device), for example using a communication module of the automated device. The server may be a backend server that stores and/or manages data for accounts of the service provider. The server may be the server 306 of FIG. 3. In the context of FIG. 3, the automated device 100 may transmit a signal to the server 306 via the communication network 304. The signal includes the input received via the interface 1100 of FIG. 11…The server performs validation on the received input, to check whether the received input matches the current authentication code that is set for the account. If validation fails, the server sends a signal to the automated device to indicate that the validation failed, and the automated device may provide output (e.g., visual display) to indicate that the received input does not match the current authentication code. The automated device may again present the interface 1100 to re-enter the authentication code. If validation is successful, the server sends a signal to the automated device to indicate that the validation was successful);
receiving, by the diagnostic device, a re-entered customer PIN code based on a result of verifying the equality (Gervais: Abstract, [0024], [0044], [0064]-[0066], [0076]-[0081], FIG. 2-3 the processing unit 126, FIG. 5, and FIG. 10-13: the automated device compares the first input into the first field 1202 with the second input into the second field 1204. If the first input and the second input are different, the automated device may generate an output (e.g., a visual display) to indicate that the first and second inputs do not match and to request the user to input the new authentication code again into the fields 1202, 1204); and
register the re-entered customer PIN code and the customer PIN code (Gervais: Abstract, [0024], [0044], [0064]-[0066], [0076]-[0081], FIG. 2-3 3 the processing unit 126, FIG. 5, and FIG. 10-13: If the first input and the second input match, then the automated device at 512 transmits the inputted new authentication code to the server…the server then updates the account to be associated with the new authentication code. After the server has completed the update, the server transmits a signal to the automated device to indicate that the authentication code was successfully changed to the new authentication code).
Therefore, in view of teachings by Brombach, Johnson, and Gervais, it would have been obvious to one of the ordinary skill in the art before ethe effective filing date of the claimed invention to implement in the key management of Brombach and Johnson, to include after an initially entered customer personal information number (PIN) code for smart key registration is generated, receiving, by a diagnostic device, the initially entered customer PIN code in response to a customer PIN code change request from a driver;
verifying, by a vehicle integrated controller, equality on the initially entered customer PIN code and a pre-stored customer PIN code in response to the customer PIN code change request;
receiving, by the diagnostic device, a re-entered customer PIN code based on a result of verifying the equality; and
register the re-entered customer PIN code and the customer PIN code, as suggested by Gervais. The motivation for this is to allow users to update/create authentication code for his/her account.
As to claim 18, Brombach, Johnson, and Gervais disclose the limitations of claim 17 further comprising the method of claim 17, wherein receiving the initially entered customer PIN code comprises: transmitting, by the diagnostic device, customer PIN code entry request information to a logic processing module of the vehicle integrated controller in response to the customer PIN code change request from the driver (Gervais: Abstract, [0024], [0044], [0064]-[0066], [0076]-[0081], FIG. 2-3 the processing unit 126, FIG. 5, and FIG. 10-13 the change PIN 1106: The interface 1200 also includes a context indicator 1206, which provides information about the context of the currently displayed interface 1200. In this case, the context indicator 1206 indicates that the interface 1200 is part of the interface sequence for changing an authentication code. The interface 1200 may also provide information 1208 that may help to guide user selection of a new authentication code);
transmitting, by the logic processing module, the customer PIN code entry request information to a security processing module of the vehicle integrated controller (Gervais: Abstract, [0024], [0044], [0064]-[0066], [0076]-[0081], FIG. 2-3 3 the processing unit 126, FIG. 5, and FIG. 10-13: the automated device compares the first input into the first field 1202 with the second input into the second field 1204. If the first input and the second input are different, the automated device may generate an output (e.g., a visual display) to indicate that the first and second inputs do not match and to request the user to input the new authentication code again into the fields 1202, 1204);
confirming, by the security processing module, customer PIN code assignment information assigned for the initially entered customer PIN code based on the customer PIN code entry request information (Gervais: Abstract, [0024], [0044], [0064]-[0066], [0076]-[0081], FIG. 2-3 3 the processing unit 126, FIG. 5, and FIG. 10-13: If the first input and the second input match, then the automated device at 512 transmits the inputted new authentication code to the server…the server then updates the account to be associated with the new authentication code. After the server has completed the update, the server transmits a signal to the automated device to indicate that the authentication code was successfully changed to the new authentication code); and
transmitting, by the security processing module, response information to the diagnostic device via the logic processing module (Gervais: Abstract, [0024], [0044], [0064]-[0066], [0076]-[0083], FIG. 2-3 3 the processing unit 126, FIG. 5, and FIG. 10-13: the server then updates the account to be associated with the new authentication code. After the server has completed the update, the server transmits a signal to the automated device to indicate that the authentication code was successfully changed to the new authentication code).
As to claim 19, Brombach, Johnson, and Gervais disclose the limitations of claim 18 further comprising the method of claim 18, wherein verifying the equality comprises:
when values of the initially entered customer PIN code and the pre-stored customer PIN code are the same, transmitting, by the security processing module, a positive response to the diagnostic device via the logic processing module; and when the values of the initially entered customer PIN code and the customer PIN code stored are not the same, transmitting, by the security processing module, a negative response to the diagnostic device via the logic processing module (Brombach: [0045]-[0046], [0065]-[0066], FIG. 1, and FIG. 3-4: a determination may be made of whether the received key is valid. For example, the key manager 124 or the key service 128 may perform one or more validity checks, such as checking that the key is in a valid format. Furthermore, the key manager 124 or the key service 128 may query the key database 126 or the server database 130, respectively, to determine whether the received key is registered with the vehicle 102. Responsive to determining that the received key fails one or more validity checks (“No” branch of block 304), an “invalid key” message may be displayed in block 306, such as via the display 121 of the vehicle 102 or a display of the user device 106…the screen 400 may include a passcode display element 402 that provides the current passcode of a received key, namely “1-9-6-2”. A user may interact with the passcode display element and input a new passcode. The screen 400 may also include a save object 404 and a clear object 406. Interaction with the save object 404 may cause an updated passcode entered into the passcode display element 402 to be stored in the key database 126 and/or the server database 130 (e.g., block 314) as an operable key and Gervais: Abstract, [0024], [0044], [0064]-[0066], [0076]-[0081], FIG. 2-3 3 the processing unit 126, FIG. 5, and FIG. 10-13: the automated device compares the first input into the first field 1202 with the second input into the second field 1204. If the first input and the second input are different, the automated device may generate an output (e.g., a visual display) to indicate that the first and second inputs do not match and to request the user to input the new authentication code again into the fields 1202, 1204).
As to claim 20, Brombach, Johnson, and Gervais disclose the limitations of claim 19 further comprising the method of claim 19, further comprising: when the diagnostic device receives a positive response, receiving, by the diagnostic device, a new customer PIN code different from the initially entered customer PIN code; and when the diagnostic device receives a negative response, terminating, by the diagnostic device, a customer PIN code changing process (Brombach: [0045]-[0046], [0065]-[0066], FIG. 1, and FIG. 3-4: a determination may be made of whether the received key is valid. For example, the key manager 124 or the key service 128 may perform one or more validity checks, such as checking that the key is in a valid format. Furthermore, the key manager 124 or the key service 128 may query the key database 126 or the server database 130, respectively, to determine whether the received key is registered with the vehicle 102. Responsive to determining that the received key fails one or more validity checks (“No” branch of block 304), an “invalid key” message may be displayed in block 306, such as via the display 121 of the vehicle 102 or a display of the user device 106…the screen 400 may include a passcode display element 402 that provides the current passcode of a received key, namely “1-9-6-2”. A user may interact with the passcode display element and input a new passcode. The screen 400 may also include a save object 404 and a clear object 406. Interaction with the save object 404 may cause an updated passcode entered into the passcode display element 402 to be stored in the key database 126 and/or the server database 130 (e.g., block 314) as an operable key and Gervais: Abstract, [0024], [0044], [0064]-[0066], [0076]-[0081], FIG. 2-3 3 the processing unit 126, FIG. 5, and FIG. 10-13: the automated device compares the first input into the first field 1202 with the second input into the second field 1204. If the first input and the second input are different, the automated device may generate an output (e.g., a visual display) to indicate that the first and second inputs do not match and to request the user to input the new authentication code again into the fields 1202, 1204).
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Brombach et al. (Brombach – US 10,293,787 B2) in view of Johnson et al. (Johnson – US 2020/0013241 A1) and Gervais et al. (Gervais – US 2020/0111097 A1) and further in view of Wang (Wang – US 2020/0324666 A1).
As to claim 8, Brombach, Johnson, and Gervais disclose the limitations of claim 2 further comprising the method of claim 2, wherein the customer PIN code assignment information is information representing a customer PIN code assignment state including an initial state in which the customer PIN code is not assigned and a key registered state in which the customer PIN code is assigned (Brombach: [0018], [0029]-[0030], [0034]-[0036], [0044]-[0047], FIG. 1, and FIG. 3: a key for the vehicle 102 may be received, such as by the key manager 124 or the key service 128. The key may be in the form of a biometric, a password, or a token 134 of a user device 106. In an example, the key manager 124 may receive the key via the HMI 116 of the vehicle 102, or more particularly via the biometric reader 118 or the keypad 120 of the vehicle 102, Johnson: Abstract, [0022], [0024]-[0026], [0041]-[0043], [0047]-[0049], and FIG. 1-2: the server adapted to identify a set of unique information based on the set of captured communications, and to store the set of unique information in the encrypted data store, and Gervais: [0057]-[0059] and FIG. 8: The interface 800 provides a field 802 for entry of an authentication code (e.g., PIN) associated with the account. For example, a user may use the keypad of the automated device to provide input into the field 802. The keypad may also provide the ability to backspace or cancel input. Other input mechanisms may also be used. The interface 800 provides a confirmation button 804 to confirm entry of the authentication code. The interface 800 also provides the general options 710 as discussed above. When the confirmation button 804 is selected, the input into the field 802 is received by the automated device. In some examples, instead of selecting the confirmation button 804, the user may use a physical button (e.g., a physical confirmation button or “OK” button, which may be part of the keypad) to confirm entry of the authentication code), except for the claimed limitations of wherein the customer PIN code assignment information is not returned to the initial state after the customer PIN code assignment information is recorded as the key registered state.
However, it has been known in the art of coding applications to implement wherein the customer PIN code assignment information is not returned to the initial state after the customer PIN code assignment information is recorded as the key registered state, as suggested by Wang, which discloses wherein the customer PIN code assignment information is not returned to the initial state after the customer PIN code assignment information is recorded as the key registered state (Wang: Abstract, [0005]-[0007], [0009], [0028]-[0029], [0032], and FIG. 3-6: The storage unit 122 (e.g., a memory) can store and record related data, such as registered/authenticated codes, and information about predetermined usage condition corresponding to each registered/authenticated code. It is noted that, above data is merely examples of the application, and the present invention is not limited thereto.. when the charging code CC matches one of the pre-stored authenticated codes (Yes in step S410), it means that the charging code CC has been previously authenticated, and then, in step S430, a current condition corresponding to the charging code CC is obtained and a predetermined usage condition corresponding to the charging code CC is obtained from the storage unit. To be more specific, as mentioned above, each authenticated code has a corresponding predetermined usage condition. Therefore, when the charging code CC matches a pre-stored authenticated code D, the predetermined usage condition for the charging Code CC is set as the predetermined usage condition for the authenticated code D. In this embodiment, the server can record the usage time, the number of code-usages, or the like of each charge code, and generate a corresponding record accordingly, and then obtain the current conditions corresponding to the charge code CC according to the content of the predetermined usage condition to perform further determination).
Therefore, in view of teachings by Brombach, Johnson, Gervais, and Wang, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to implement in the key management of Brombach, Johnson, and Gervais to include wherein the customer PIN code assignment information is not returned to the initial state after the customer PIN code assignment information is recorded as the key registered state, as suggested by Wang. The motivation for this is to managing conditions of an authentication code.
Citation of Pertinent Art
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure:
Rule et al., US 2025/0308316 A1, discloses contactless card and personal identification system.
Hurry et al., US 2025/0219833 A1, discloses offline access for vehicles.
Lee, US 2025/0115212 A1, discloses method for providing a digital key service, a vehicle and a management server for the same.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to QUANG PHAM whose telephone number is (571)-270-3668. The examiner can normally be reached 09:00 AM - 05: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, QUAN-ZHEN WANG can be reached at (571)-272-3114. 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.
/QUANG PHAM/Primary Examiner, Art Unit 2685