DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 09/29/2025 has been entered.
Applicant argued in the remark that Cooper does not present a concreter NFC-based direct communication scenario between a terminal and vehicle.
Examiner respectfully disagrees. Lambert discloses 0037 The device-to-device interface 32 device, i.e. terminal, can be configured to utilize any suitable protocol for establishing a secure connection such as Bluetooth secure pairing, NFC pairing, Wi-Fi, etc. and communicates with a device-to-device interface 52 Vehicle in the vehicle key sharing module 50.
Applicant argued in the remark that Santiano also does not specify vehicles, nor does it disclose NFC-based d direct communication scenario between a terminal and vehicle.
Examiner respectfully disagrees. Lambert discloses 0037 The device-to-device interface 32 device, i.e. terminal, can be configured to utilize any suitable protocol for establishing a secure connection such as Bluetooth secure pairing, NFC pairing, Wi-Fi, etc. and communicates with a device-to-device interface 52 Vehicle in the vehicle key sharing module 50.
Moreover, Lambert discloses provides a concrete procedure in which a shared digital key is updated via NFC communication between a user terminal and a vehicle, and the result is explicitly included in a response message for confirmation, while also managing permission types such as opening/closing vehicle doors and starting the vehicle. This procedure is neither disclosed in the cited references nor would it be readily derived from their combination( 0042 The device 10 sends the generated response to the vehicle 12 at step 138. It can be appreciated that this response could be a signature on the challenge data, a key agreement computation (e.g. Diffie-Hellman), or other suitable cryptographic challenge/response technique. And 0037 The device-to-device interface 32 can be configured to utilize any suitable protocol for establishing a secure connection such as Bluetooth secure pairing, NFC pairing, Wi-Fi, etc. and communicates with a device-to-device interface 52 in the vehicle key sharing module 50. And 0040 The vehicle 12 then issues a signed confirmation of ownership message containing the new owner's certificate, and the vehicle's certificate, signed by the vehicle's private key to the owner's device 10 at step 118. The owner's device 10 receives this confirmation at step 120, and may then forward this message to the key sharing server 18 at step 122, to track the car-owner relationship and fig.4, 0043] The vehicle 12 receives the response at step 140, and verifies that the response is correct at step 142. If it is determined at step 144 that the response is correct, the vehicle 12 will allow access at step 146 ).
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1-3,5, and 10-14 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Lambert et al US 2017/0104589.
As per claim 1. Lambert discloses a method performed by an electronic device for managing a shared digital key, the method comprising:
triggering management of the shared digital key (0038 The vehicle owner uses an electronic device 10, such as a smartphone, to register, i.e. triggering management of shared digital key, with the key sharing server 18. key sharing server 18. 0037 a device-to-device interface 32 for communicating,), wherein the management of the shared digital key includes updating the shared digital key, ( 0037 fig.2, the device 10 can include a device key sharing module 30, i.e. management of the shared digital key, having a device-to-device interface 32 for communicating with a vehicle key sharing module 50, i.e. management of the shared digital key, in the vehicle 12.. ) and wherein the electronic device is a user terminal (fig.1, an electronic device 10 is equal to the terminal, the owner has a digital key stored on the electronic device such as a smartphone );
in response to the triggering, generating a request message to manage the shared digital key (0042 The vehicle is then able to present the electronic device 10 with a cryptographic challenge at step 134, which is received by the device 100042 The device 10 uses the owner's cryptographic private key, which is associated with the certificate stored in the registration process, to calculate the response to the challenge at step 136 );
transmitting, to a target device, the generated request message based on a near field communication (NFC), wherein the target device is a vehicle (0042 The device 10 sends the generated response to the vehicle 12 at step 138. It can be appreciated that this response could be a signature on the challenge data, a key agreement computation (e.g. Diffie-Hellman), or other suitable cryptographic challenge/response technique. And 0037 The device-to-device interface 32 can be configured to utilize any suitable protocol for establishing a secure connection such as Bluetooth secure pairing, NFC pairing, Wi-Fi, etc. and communicates with a device-to-device interface 52 in the vehicle key sharing module 50. );
receiving, from the target device, a response message in response to the request message to manage the shared digital key based on the NFC, wherein the response message includes response information comprising data indicating a result of the updating the shared digital key (0040 The vehicle 12 then issues a signed confirmation of ownership message containing the new owner's certificate, and the vehicle's certificate, signed by the vehicle's private key to the owner's device 10 at step 118. The owner's device 10 receives this confirmation at step 120, and may then forward this message to the key sharing server 18 at step 122, to track the car-owner relationship);
verifying information included in the received response message; and managing the shared digital key based on the verified information, wherein the shared digital key of the electronic device is managed by updating information for a permission type of the shared digital key ( fig.4, 0043] The vehicle 12 receives the response at step 140, and verifies that the response is correct at step 142. If it is determined at step 144 that the response is correct, the vehicle 12 will allow access at step 146.) , and
wherein the permission type includes a permission to open or close a door of a-the vehicle and a permission to start the vehicle (0043] the vehicle 12 will allow access at step 146).
As per claim 2. Lambert discloses The method of The method of wherein the request message includes at least one of information about the shared digital key, request information, routing information, or a signature of the electronic device transmitting the request message, and wherein the response message includes at least one of information about the shared digital key, routing information, or a signature of the target device transmitting the response message ( 0013 enabling a third party device to access an access point on a vehicle based on a permission granted by an owner device, the method comprising: receiving at the vehicle, a notice of a valid signature on the permission and a valid identity certificate associated with the third party device; sending a cryptographic challenge to the third party device; receiving a response to the cryptographic challenge from the third party device; verifying the response and determining any restrictions imposed on the third party device by the owner device; and blocking or allowing access to the access point according to the verifying and the determined restrictions. And 0042 The device 10 sends the generated response to the vehicle 12 at step 138. It can be appreciated that this response could be a signature on the challenge data, a key agreement computation (e.g. Diffie-Hellman), or other suitable cryptographic challenge/response and 0049 once the digital permission is received, the other party can execute the following process to access the vehicle 12. The other party will initiate communication between their electronic device and the vehicle 12 at steps 200 and 202 using a secure channel (e.g., similar to device 10 shown in FIG. 1) and provide the digital permission to the vehicle 12 for verification at step 204. The vehicle 12 cryptographically verifies the signature on the digital permission as belonging to the owner (and to the signing server 18 if applicable) using stored identity certificates at step 206. The vehicle will also verify that the identity certificate presented by the owner device matches the identity supplied in the digital permission at step 208. 0050 0050] If the signature and certificate supplied are valid, the vehicle 12 presents a cryptographic challenge to the other party's device at step 210. The other party's device uses the other party's cryptographic private key to complete the challenge at step 212, and the device sends the response to the vehicle 12 at step 214. A similar cryptographic primitive as that described above can be used, such as signature or key-agreement. The vehicle 12 verifies that the response is correct at step 216, and also that the restrictions in the digital permission are satisfied at step 218. If so, the vehicle 12 will allow access at step 220. It may be noted that, as above, no communication was required between the vehicle 12 and the key sharing server 18 in order to share the key. and [0053] The next time the owner unlocks the vehicle 12 using their electronic device 10 at steps 240 and 242, the vehicle 12 verifies the signature on the permission revocation request at step 242, and if successful, the list of revoked digital permissions stored in the vehicle 12 is updated to prevent revoked third parties from accessing the vehicle 12 using the revoked digital permission in a subsequent attempt at steps 246 and 248. 0055 FIG. 8, the owner can use their electronic device 10 to generate a registration code replacement request at step 260. The device 10 uses the owner's cryptographic private key to cryptographically sign the request at step 262, and the device 10 forwards the request to the key sharing server 18 at step 264. The key sharing server 18 receives the request and verifies the signature on the request at step 266. If the signature is valid and belongs to the owner, the key sharing server 18 generates a new registration code at step 268. And 0057 [0057] The key sharing server 18 assembles the data at step 278 and sends the encrypted registration code and the signed (and perhaps encrypted) hash of the registration code to the device 10 at step 280. The device 10 receives the data and verifies the signature on the hash as belonging to the key sharing server 18, decrypts the new registration code and displays the code to the owner at step 282. The new code can be displayed only once and never stored on the device 10 to ensure it cannot be reused. And 0060 [0060] After receiving the request at step 316, the key sharing server 18 verifies the signature on the request and, if the signature is valid and belongs to the current owner, the key sharing server 18 generates a new registration code at step 318. Since this can be considered a very sensitive operation, the key sharing server 18 may require the involvement of a human operator for this operation. And 0061] The key sharing server 18 encrypts the new registration code using the new owner's cryptographic public key at step 326. The key sharing server 18 also separately generates a secure hash of the registration code at step 320, cryptographically signs that value (or an encrypted version of the hash using the cryptographic public key of the vehicle) using the cryptographic private key of the server 18 at step 322 and encrypts the hash to the vehicle at step 324. The key sharing server 18 then assembles the data at step 328 to enable it to send the encrypted registration code and the signed version of the hash to the new owner's electronic device at step 328. The new owner's device receives the encrypted code at step 330 and verifies the signature of the hash, decrypts the new registration code and displays the code to the new owner at step 332. The new code can be configured to be displayed only once and never stored on the device to ensure it cannot be reused. The key sharing server 18 sends the encrypted hash of the registration code to the current owner's electronic device at step 334. The current owner's device receives the code at step 336 and then cryptographically counter-signs the encrypted hash of the registration code using the current owner's cryptographic private key at step 338. The current owner then initiates communication between their electronic device 10 and the vehicle 12 at steps 340 and 342, and sends the encrypted hash, signed version of the hash (possibly also encrypted) of the registration code, and the counter-signed version of the hash to the vehicle 12 at step 344. ).
As per claim 3. Lambert discloses The method of The method of wherein the request information includes information requesting the management of the shared digital key ([0007] Another existing key sharing mechanism is server-based key sharing. In this scheme the owner has a digital key stored on an electronic device such as a smartphone. To share a key with another party the owner transfers a new unique digital key to the other party via a key sharing server. The new digital key is also sent to the vehicle via the key sharing server. The drawbacks with a server-based key sharing scheme include that: the vehicle needs have a connection to the key sharing server to receive new digital keys (that is, if the vehicle does not have a connection, the new digital key will not be recognized as valid), and if the owner revokes a digital key, that vehicle will not receive that information until it is able to connect to the key sharing server. This leaves a possible period of time where the holder of the revoked key can gain unauthorized access to the car. ),
As per claim 5. Lambert discloses The method of claim 3, further comprising: transmitting, to a third electronic device, at least one request information or response information([0012] In another aspect, there is provided a communication system comprising an access point, an owner device and a third party device to be granted access by the owner device; wherein the owner device and the third party device each possess certificates and associated private keys, and wherein the owner's certificate is known and trusted by the access point; wherein the owner signs a message granting permission to the third party, the identity of the third party being included in the permission to indicate the third party's certificate).
As per claim 10. Lambert discloses a method performed by a target device for managing a shared digital key, the method comprising:
receiving, from an electronic device, a request message to manage the shared digital key based on a near field communication (NFC), wherein the electronic device is a user terminal, ( 0038 The vehicle owner uses an electronic device 10, such as a smartphone, to register, i.e. triggering management of shared digital key, with the key sharing server 18. key sharing server 18. 0037 a device-to-device interface 32 for communicating; 0037 fig.2, the device 10 can include a device key sharing module 30, i.e. management of the shared digital key, having a device-to-device interface 32 for communicating with a vehicle key sharing module 50, i.e. management of the shared digital key, in the vehicle 12.. fig.1, an electronic device 10 is equal to the terminal, the owner has a digital key stored on the electronic device such as a smartphone )
wherein the request message is received in response to triggering of management of the shared digital key by an electronic device (0042 The vehicle is then able to present the electronic device 10 with a cryptographic challenge at step 134, which is received by the device 100042 The device 10 uses the owner's cryptographic private key, which is associated with the certificate stored in the registration process, to calculate the response to the challenge at step 136 ), and wherein the management of the shared digital key includes updating the shared digital key (0042 The device 10 sends the generated response to the vehicle 12 at step 138. It can be appreciated that this response could be a signature on the challenge data, a key agreement computation (e.g. Diffie-Hellman), or other suitable cryptographic challenge/response technique. And 0037 The device-to-device interface 32 can be configured to utilize any suitable protocol for establishing a secure connection such as Bluetooth secure pairing, NFC pairing, Wi-Fi, etc. and communicates with a device-to-device interface 52 in the vehicle key sharing module 50. And 0040 The vehicle 12 then issues a signed confirmation of ownership message containing the new owner's certificate, and the vehicle's certificate, signed by the vehicle's private key to the owner's device 10 at step 118. The owner's device 10 receives this confirmation at step 120, and may then forward this message to the key sharing server 18 at step 122, to track the car-owner relationship );
verifying information included in the request message; generating a response message in response to the request message based on the verified information, wherein the response message includes response information comprising data indicating a result of the updating the shared digital key (fig.4, 0043] The vehicle 12 receives the response at step 140, and verifies that the response is correct at step 142. If it is determined at step 144 that the response is correct, the vehicle 12 will allow access at step 146 ); and
transmitting, to the electronic device, the generated response message based on the NFC, wherein the shared digital key of the target device is managed by updating information for a permission type of the shared digital key (0040 The vehicle 12 then issues a signed confirmation of ownership message containing the new owner's certificate, and the vehicle's certificate, signed by the vehicle's private key to the owner's device 10 at step 118. The owner's device 10 receives this confirmation at step 120, and may then forward this message to the key sharing server 18 at step 122, to track the car-owner relationship),
wherein the target device is a vehicle, and wherein the permission type includes a permission to open or close a door of a-the vehicle and a permission to start the vehicle ( fig.4, 0043] The vehicle 12 receives the response at step 140, and verifies that the response is correct at step 142. If it is determined at step 144 that the response is correct, the vehicle 12 will allow access at step 146).
As per claim 11. Lambert discloses the method of The method of wherein the request message includes at least one of information about the shared digital key, request information, routing information, or a signature of the electronic device transmitting the request message, and wherein the response message includes at least one of information about the shared digital key, response information, routing information, or a signature of the target device transmitting the response message (( 0013 enabling a third party device to access an access point on a vehicle based on a permission granted by an owner device, the method comprising: receiving at the vehicle, a notice of a valid signature on the permission and a valid identity certificate associated with the third party device; sending a cryptographic challenge to the third party device; receiving a response to the cryptographic challenge from the third party device; verifying the response and determining any restrictions imposed on the third party device by the owner device; and blocking or allowing access to the access point according to the verifying and the determined restrictions. And 0042 The device 10 sends the generated response to the vehicle 12 at step 138. It can be appreciated that this response could be a signature on the challenge data, a key agreement computation (e.g. Diffie-Hellman), or other suitable cryptographic challenge/response and 0049 once the digital permission is received, the other party can execute the following process to access the vehicle 12. The other party will initiate communication between their electronic device and the vehicle 12 at steps 200 and 202 using a secure channel (e.g., similar to device 10 shown in FIG. 1) and provide the digital permission to the vehicle 12 for verification at step 204. The vehicle 12 cryptographically verifies the signature on the digital permission as belonging to the owner (and to the signing server 18 if applicable) using stored identity certificates at step 206. The vehicle will also verify that the identity certificate presented by the owner device matches the identity supplied in the digital permission at step 208. 0050 0050] If the signature and certificate supplied are valid, the vehicle 12 presents a cryptographic challenge to the other party's device at step 210. The other party's device uses the other party's cryptographic private key to complete the challenge at step 212, and the device sends the response to the vehicle 12 at step 214. A similar cryptographic primitive as that described above can be used, such as signature or key-agreement. The vehicle 12 verifies that the response is correct at step 216, and also that the restrictions in the digital permission are satisfied at step 218. If so, the vehicle 12 will allow access at step 220. It may be noted that, as above, no communication was required between the vehicle 12 and the key sharing server 18 in order to share the key. and [0053] The next time the owner unlocks the vehicle 12 using their electronic device 10 at steps 240 and 242, the vehicle 12 verifies the signature on the permission revocation request at step 242, and if successful, the list of revoked digital permissions stored in the vehicle 12 is updated to prevent revoked third parties from accessing the vehicle 12 using the revoked digital permission in a subsequent attempt at steps 246 and 248. 0055 FIG. 8, the owner can use their electronic device 10 to generate a registration code replacement request at step 260. The device 10 uses the owner's cryptographic private key to cryptographically sign the request at step 262, and the device 10 forwards the request to the key sharing server 18 at step 264. The key sharing server 18 receives the request and verifies the signature on the request at step 266. If the signature is valid and belongs to the owner, the key sharing server 18 generates a new registration code at step 268. And 0057 [0057] The key sharing server 18 assembles the data at step 278 and sends the encrypted registration code and the signed (and perhaps encrypted) hash of the registration code to the device 10 at step 280. The device 10 receives the data and verifies the signature on the hash as belonging to the key sharing server 18, decrypts the new registration code and displays the code to the owner at step 282. The new code can be displayed only once and never stored on the device 10 to ensure it cannot be reused. And 0060 [0060] After receiving the request at step 316, the key sharing server 18 verifies the signature on the request and, if the signature is valid and belongs to the current owner, the key sharing server 18 generates a new registration code at step 318. Since this can be considered a very sensitive operation, the key sharing server 18 may require the involvement of a human operator for this operation. And 0061] The key sharing server 18 encrypts the new registration code using the new owner's cryptographic public key at step 326. The key sharing server 18 also separately generates a secure hash of the registration code at step 320, cryptographically signs that value (or an encrypted version of the hash using the cryptographic public key of the vehicle) using the cryptographic private key of the server 18 at step 322 and encrypts the hash to the vehicle at step 324. The key sharing server 18 then assembles the data at step 328 to enable it to send the encrypted registration code and the signed version of the hash to the new owner's electronic device at step 328. The new owner's device receives the encrypted code at step 330 and verifies the signature of the hash, decrypts the new registration code and displays the code to the new owner at step 332. The new code can be configured to be displayed only once and never stored on the device to ensure it cannot be reused. The key sharing server 18 sends the encrypted hash of the registration code to the current owner's electronic device at step 334. The current owner's device receives the code at step 336 and then cryptographically counter-signs the encrypted hash of the registration code using the current owner's cryptographic private key at step 338. The current owner then initiates communication between their electronic device 10 and the vehicle 12 at steps 340 and 342, and sends the encrypted hash, signed version of the hash (possibly also encrypted) of the registration code, and the counter-signed version of the hash to the vehicle 12 at step 344).
As per claim 12. Lambert discloses an electronic device comprising: a transceiver; at least one processor; and memory storing one or more programs including computer-executable instructions that, when executed by the at least one processor (0077 computer readable media such as storage media, computer storage media, or data storage devices), cause the electronic device to:
triggering management of the shared digital key ( 0038 The vehicle owner uses an electronic device 10, such as a smartphone, to register, i.e. triggering management of shared digital key, with the key sharing server 18. key sharing server 18. 0037 a device-to-device interface 32 for communicating,), wherein the management of the shared digital key includes updating the shared digital key, ( 0037 fig.2, the device 10 can include a device key sharing module 30, i.e. management of the shared digital key, having a device-to-device interface 32 for communicating with a vehicle key sharing module 50, i.e. management of the shared digital key, in the vehicle 12.. ) and wherein the electronic device is a user terminal (fig.1, an electronic device 10 is equal to the terminal, the owner has a digital key stored on the electronic device such as a smartphone );
in response to the triggering, generating a request message to manage the shared digital key (0042 The vehicle is then able to present the electronic device 10 with a cryptographic challenge at step 134, which is received by the device 100042 The device 10 uses the owner's cryptographic private key, which is associated with the certificate stored in the registration process, to calculate the response to the challenge at step 136 );
transmitting, to a target device, the generated request message based on a near field communication (NFC), wherein the target device is a vehicle (0042 The device 10 sends the generated response to the vehicle 12 at step 138. It can be appreciated that this response could be a signature on the challenge data, a key agreement computation (e.g. Diffie-Hellman), or other suitable cryptographic challenge/response technique. And 0037 The device-to-device interface 32 can be configured to utilize any suitable protocol for establishing a secure connection such as Bluetooth secure pairing, NFC pairing, Wi-Fi, etc. and communicates with a device-to-device interface 52 in the vehicle key sharing module 50. );
receiving, from the target device, a response message in response to the request message to manage the shared digital key based on the NFC, wherein the response message includes response information comprising data indicating a result of the updating the shared digital key (0040 The vehicle 12 then issues a signed confirmation of ownership message containing the new owner's certificate, and the vehicle's certificate, signed by the vehicle's private key to the owner's device 10 at step 118. The owner's device 10 receives this confirmation at step 120, and may then forward this message to the key sharing server 18 at step 122, to track the car-owner relationship);
verifying information included in the received response message; and managing the shared digital key based on the verified information, wherein the shared digital key of the electronic device is managed by updating information for a permission type of the shared digital key ( fig.4, 0043] The vehicle 12 receives the response at step 140, and verifies that the response is correct at step 142. If it is determined at step 144 that the response is correct, the vehicle 12 will allow access at step 146.) , and
wherein the permission type includes a permission to open or close a door of a-the vehicle and a permission to start the vehicle (0043] the vehicle 12 will allow access at step 146).
As per claim 13. Lambert discloses The electronic device of The electronic device of wherein the request message includes at least one of information about the shared digital key, request information, routing information, or a signature of the electronic device transmitting the request message, and wherein the response message includes at least one of information about the shared digital key, response information, routing information, or a signature of the target device transmitting the response message (0013 enabling a third party device to access an access point on a vehicle based on a permission granted by an owner device, the method comprising: receiving at the vehicle, a notice of a valid signature on the permission and a valid identity certificate associated with the third party device; sending a cryptographic challenge to the third party device; receiving a response to the cryptographic challenge from the third party device; verifying the response and determining any restrictions imposed on the third party device by the owner device; and blocking or allowing access to the access point according to the verifying and the determined restrictions. And 0042 The device 10 sends the generated response to the vehicle 12 at step 138. It can be appreciated that this response could be a signature on the challenge data, a key agreement computation (e.g. Diffie-Hellman), or other suitable cryptographic challenge/response and 0049 once the digital permission is received, the other party can execute the following process to access the vehicle 12. The other party will initiate communication between their electronic device and the vehicle 12 at steps 200 and 202 using a secure channel (e.g., similar to device 10 shown in FIG. 1) and provide the digital permission to the vehicle 12 for verification at step 204. The vehicle 12 cryptographically verifies the signature on the digital permission as belonging to the owner (and to the signing server 18 if applicable) using stored identity certificates at step 206. The vehicle will also verify that the identity certificate presented by the owner device matches the identity supplied in the digital permission at step 208. 0050 0050] If the signature and certificate supplied are valid, the vehicle 12 presents a cryptographic challenge to the other party's device at step 210. The other party's device uses the other party's cryptographic private key to complete the challenge at step 212, and the device sends the response to the vehicle 12 at step 214. A similar cryptographic primitive as that described above can be used, such as signature or key-agreement. The vehicle 12 verifies that the response is correct at step 216, and also that the restrictions in the digital permission are satisfied at step 218. If so, the vehicle 12 will allow access at step 220. It may be noted that, as above, no communication was required between the vehicle 12 and the key sharing server 18 in order to share the key. and [0053] The next time the owner unlocks the vehicle 12 using their electronic device 10 at steps 240 and 242, the vehicle 12 verifies the signature on the permission revocation request at step 242, and if successful, the list of revoked digital permissions stored in the vehicle 12 is updated to prevent revoked third parties from accessing the vehicle 12 using the revoked digital permission in a subsequent attempt at steps 246 and 248. 0055 FIG. 8, the owner can use their electronic device 10 to generate a registration code replacement request at step 260. The device 10 uses the owner's cryptographic private key to cryptographically sign the request at step 262, and the device 10 forwards the request to the key sharing server 18 at step 264. The key sharing server 18 receives the request and verifies the signature on the request at step 266. If the signature is valid and belongs to the owner, the key sharing server 18 generates a new registration code at step 268. And 0057 [0057] The key sharing server 18 assembles the data at step 278 and sends the encrypted registration code and the signed (and perhaps encrypted) hash of the registration code to the device 10 at step 280. The device 10 receives the data and verifies the signature on the hash as belonging to the key sharing server 18, decrypts the new registration code and displays the code to the owner at step 282. The new code can be displayed only once and never stored on the device 10 to ensure it cannot be reused. And 0060 [0060] After receiving the request at step 316, the key sharing server 18 verifies the signature on the request and, if the signature is valid and belongs to the current owner, the key sharing server 18 generates a new registration code at step 318. Since this can be considered a very sensitive operation, the key sharing server 18 may require the involvement of a human operator for this operation. And 0061] The key sharing server 18 encrypts the new registration code using the new owner's cryptographic public key at step 326. The key sharing server 18 also separately generates a secure hash of the registration code at step 320, cryptographically signs that value (or an encrypted version of the hash using the cryptographic public key of the vehicle) using the cryptographic private key of the server 18 at step 322 and encrypts the hash to the vehicle at step 324. The key sharing server 18 then assembles the data at step 328 to enable it to send the encrypted registration code and the signed version of the hash to the new owner's electronic device at step 328. The new owner's device receives the encrypted code at step 330 and verifies the signature of the hash, decrypts the new registration code and displays the code to the new owner at step 332. The new code can be configured to be displayed only once and never stored on the device to ensure it cannot be reused. The key sharing server 18 sends the encrypted hash of the registration code to the current owner's electronic device at step 334. The current owner's device receives the code at step 336 and then cryptographically counter-signs the encrypted hash of the registration code using the current owner's cryptographic private key at step 338. The current owner then initiates communication between their electronic device 10 and the vehicle 12 at steps 340 and 342, and sends the encrypted hash, signed version of the hash (possibly also encrypted) of the registration code, and the counter-signed version of the hash to the vehicle 12 at step 344.).
As per claim 14. Lambert discloses The electronic device of the electronic device of wherein the request information includes information requesting the management of the shared digital key(([0007] Another existing key sharing mechanism is server-based key sharing. In this scheme the owner has a digital key stored on an electronic device such as a smartphone. To share a key with another party the owner transfers a new unique digital key to the other party via a key sharing server. The new digital key is also sent to the vehicle via the key sharing server. The drawbacks with a server-based key sharing scheme include that: the vehicle needs have a connection to the key sharing server to receive new digital keys (that is, if the vehicle does not have a connection, the new digital key will not be recognized as valid), and if the owner revokes a digital key, that vehicle will not receive that information until it is able to connect to the key sharing server. This leaves a possible period of time where the holder of the revoked key can gain unauthorized access to the car).
Allowable Subject Matter
Claims 8-9 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims (the claims 8-9 incorporated into all the independents claims).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 ABU S SHOLEMAN whose telephone number is (571)270-7314. The examiner can normally be reached EST: 9am-5pm.
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 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 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.
/ABU S SHOLEMAN/Primary Examiner, Art Unit 2496
Prosecution Insights