DETAILED ACTION
This is a response to the Amendment to Application # 19/179,336 filed on August 12, 2026 in which claims 1, 5, 9, 12, 14, and 15 were amended.
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 .
Status of Claims
Claims 1-15 are pending, of which claim 8 is rejected under 35 U.S.C. § 112(d) and claims 1-15 are rejected under 35 U.S.C. § 103.
Claim Objections
Claims 1, 2, 5, 7-, 9, and 11-15 objected to because of the following informalities: “the verification key” lacks antecedent basis and should be amended to “the digital verification key.” Appropriate correction is required.
Claims 2, 3, 7, 8, 10, and 13 are objected to because of the following informalities: These claims contain “and/or” language. While definite, the preferred verbiage for such language is “at least one of A and B,” See Ex parte Gross (PTAB 2014) (App. S.N. 11/565,411), at Page 4, Footnote 1. Appropriate correction is required.
Claim Rejections - 35 U.S.C. § 112
The following is a quotation of 35 U.S.C. § 112(d):
(d) REFERENCE IN DEPENDENT FORMS.—Subject to subsection (e), a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
Claim 8 is rejected under 35 U.S.C. § 112(d) as being of improper dependent form for failing to further limit the subject matter of the claim upon which it depends, or for failing to include all the limitations of the claim upon which it depends.
Regarding claim 8, this claim only includes to alternative limitations that were both incorporated into parent claim 1 as required elements. Therefore, this claim does not further limit parent claim 1. Applicant may cancel the claim, amend the claim to place the claim in proper dependent form, rewrite the claim in independent form, or present a sufficient showing that the dependent claim complies with the statutory requirements.
Claim Rejections - 35 U.S.C. § 103
The following is a quotation of 35 U.S.C. § 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 2, 5, 8-10, 14, and 15 are rejected under 35 U.S.C. § 103 as being unpatentable over Lee et al., US Publication 2025/0115212 (hereinafter Lee), as cited on the Notice of References Cited dated May 5, 2026, in view of Manchovski, US Publication 2021/0097795 (hereinafter Manchovski).
Regarding claim 1, Manchovski discloses a user device of a user of a service for providing a lock, wherein the user device is configured to “- as part of registering for the service, - send registration data of the user to a back-end unit of the service via a communication link for the purpose of creating a user profile; - carry out a sharing process for a digital verification key with the back-end unit” (Manchovski ¶¶ 112, 129-130) where, under Scenario 1, the process registers the owner device and smart lock on the block chain network and then sharing a token between the owner device and the blockchain network. (Manchovski ¶ 112). Manchovski discloses that under Scenario 2, the process described in Scenario 1 is used except the data is sent to a cloud server (i.e., the back-end unit). Additionally, Manchovski discloses “- send first device-specific information of the user device to the back-end unit via the communication link as part of the sharing process for the verification key” (Manchovski ¶¶ 120-121, 129-130) where the owner device generates a token that is encrypted using the public key of the user device that is synchronized (i.e., sent) to the blockchain network. (Manchovski ¶ 112). Manchovski discloses that under Scenario 2, the process described in Scenario 1 is used except the data is sent to a cloud server (i.e., the back-end unit). Further, Manchovski discloses “- to use the service, - send a request to provide a digital use key for a lock to the back-end unit” (Manchovski ¶ 131) where the user device requests the token, including the smart contract (i.e., the digital use key) from the cloud server. Moreover, Manchovski discloses “- carry out a sharing process for the digital use key with the back-end unit” (Manchovski ¶ 132) by sending (i.e., sharing) the token to the user device via the cloud server. Likewise, Manchovski discloses “- send second device-specific information of the user device to the back-end unit via the communication link as part of the sharing process for the digital use key; wherein the second device-specific information and the first device-specific information are the same” (Manchovski 129, 141, Fig. 7) where the user validates the token with the blockchain via the cloud server (Manchovski ¶ 141, Fig. 7) which is done with the user’s public key (i.e., the same device-specific information, Manchovski ¶ 129). Finally, Manchovski discloses “wherein the digital verification key does not have any authorization to control one or more lock functions of the lock, and the digital use key has an authorization to control one or more lock functions of the lock” (Manchovski ¶¶ 16, 27) where the public key only unencrypts the token and does not control any lock functions, while the smart contract controls the lock functions.
Manchovski does not appear to explicitly disclose that the lock is part of a vehicle and, therefore, does not appear to explicitly disclose a “user device of a user of a service for providing a vehicle;” “- to use the service, - send a request to provide a digital use key for a vehicle to the back-end unit;” or “wherein the digital verification key does not have any authorization to control one or more vehicle functions of the vehicle, and the digital use key has an authorization to control one or more vehicle functions of the vehicle.”
However, Lee discloses a user device of a user of a service for providing a vehicle. (Lee Abstract). A person of ordinary skill in the art prior to the effective filing date would have recognized that when Lee was combined with Manchovski, the lock of Manchovski would be part of a vehicle, as taught by Lee. Therefore, the combination of Manchovski and Lee at least teaches and/or suggests the limitations “[a] user device of a user of a service for providing a vehicle;” “- to use the service, - send a request to provide a digital use key for a vehicle to the back-end unit” and “wherein the digital verification key does not have any authorization to control one or more vehicle functions of the vehicle, and the digital use key has an authorization to control one or more vehicle functions of the vehicle,” rendering them obvious.
Additionally, Lee discloses various other elements of the claimed invention. For instance, Lee discloses wherein the user device is configured to “- as part of registering for the service, - send registration data of the user to a back-end unit of the service via a communication link for the purpose of creating a user profile” (Lee ¶ 86) where a user terminal (i.e., a user device) requests issuance of a shared key and the server (i.e., a back-end unit) receives the request and information on an owner account and the phone to be given the shared key. This is part of the process of creating a user profile. (Lee ¶ 68). Further, Lee discloses “- carry out a sharing process for a digital verification key with the back-end unit” (Lee ¶ 89) where the digital key is assigned (i.e., shared) with the ID. Moreover, Lee discloses “- send first device-specific information of the user device to the back-end unit via the communication link as part of the sharing process for the verification key” (Lee ¶86) where device specific information, such an “email account of for the terminal” (i.e., device-specific information of the user device) is sent to the server. Likewise, Lee discloses “- to use the service, - send a request to provide a digital use key for a vehicle to the back-end unit” (Lee ¶ 51) where the owner of the vehicle requests the issuance of the first digital key. Lee also discloses “- carry out a sharing process for the digital use key with the back-end unit” (Lee ¶ 110) where the digital key is received. Finally, Lee discloses “- send second device-specific information of the user device to the back-end unit via the communication link as part of the sharing process for the digital use key; wherein the second device-specific information and the first device-specific information are the same” (Lee ¶ 65) where the BDC compares the first digital key to the stored keys to determine if they are the same. The BDC is part of the “back-end unit” because a person of ordinary skill in the art prior to the effective filing date understood a back-end unit to be a unit performing a task not apparent to the user, which the BDC is doing and making it part of the back-end unit. (“back-end,” Free On-Line Dictionary of Computing, April 9, 1996, Page 1). Lee discloses that the key includes the device information. (Lee ¶ 25).
Manchovski and Lee are analogous art because they are from the “same field of endeavor,” namely that of smart lock systems.
Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Manchovski and Lee before him or her to modify the smart lock of Manchovski to be implemented on the vehicle of Lee.
The motivation/rationale for doing so would have been that of simple substitution. See KSR Int’l Co v. Teleflex Inc., 550 US 398, 82 USPQ2d 1385, 1396 (U.S. 2007) and MPEP § 2143(I)(B). Manchovski differs from the claimed invention by including a location agnostic lock in place of a vehicle based lock. Further, Lee teaches that smart locks on vehicles were well known in the art. One of ordinary skill in the art could have predictably substituted the vehicle based location of Lee for the unspecified location of Manchovski because the location of the lock does not affect the process of Manchovski.
Regarding claim 2, the combination of Manchovski and Lee discloses the limitations contained in parent claim 1 for the reasons discussed above. In addition, the combination of Manchovski and Lee discloses “wherein the user device is configured to read the first and/or the second device-specific information from a secure memory of the user device and then to send it to the back-end unit; and/or store the verification key and/or the digital use key in the secure memory” (Lee ¶ 45) where both the device and the back-end server may store all information in secure digital card memory.
Regarding claim 5, the combination of Manchovski and Lee discloses the limitations contained in parent claim 1 for the reasons discussed above. In addition, the combination of Manchovski and Lee does not appear to explicitly disclose “wherein the user device is configured, in the context of the registration for the service, to - sign the registration data with the verification key to determine a verification signature; and - send the verification signature to the back-end unit via the communication link.” (Manchovski ¶ 39)
Regarding claim 8, the combination of Manchovski and Lee discloses the limitations contained in parent claim 1 for the reasons discussed above. In addition, the combination of Manchovski and Lee discloses “- the verification key does not have any authorizations to control one or more vehicle functions of the vehicle; and/or - the digital use key has an authorization to control one or more vehicle functions of the vehicle” (Manchovski ¶¶ 16, 27) where the public key only unencrypts the token and does not control any lock functions, while the smart contract controls the lock functions.
Regarding claim 9, Manchovski discloses a back-end unit for a service to provide a lock; wherein the back-end unit is configured to, “- in a context of a registration for the service, - receive registration data of a user from a first user device of the user for the purpose of creating a user profile via a communication link; - carry out a sharing process for a digital verification key with the first user device” (Manchovski ¶¶ 112, 129-130) where, under Scenario 1, the process registers the owner device and smart lock on the block chain network and then sharing a token between the owner device and the blockchain network. (Manchovski ¶ 112). Manchovski discloses that under Scenario 2, the process described in Scenario 1 is used except the data is sent to a cloud server (i.e., the back-end unit). Additionally, Manchovski discloses “- receive the first device-specific information of the first user device via the communication link as part of the sharing process for the verification key” (Manchovski ¶¶ 120-121, ¶ 129-130) where the owner device generates a token that is encrypted using the public key of the user device that is synchronized (i.e., sent) to the blockchain network. (Manchovski ¶ 112). Manchovski discloses that under Scenario 2, the process described in Scenario 1 is used except the data is sent to a cloud server (i.e., the back-end unit). Further, Manchovski discloses “- store the first device-specific information in association with the user profile” (Manchovski ¶ 121) by encrypting the token, containing the user data, with the public key. Moreover, Manchovski discloses “- for a use of the service, - receive a request relating to the stored user profile to provide a digital use key for the lock from a second user device” (Manchovski ¶ 131) where the user device requests the token, including the smart contract (i.e., the digital use key) from the cloud server. Likewise, Manchovski discloses “- carry out a sharing process for the digital use key with the second user device” (Manchovski ¶ 132) by sending (i.e., sharing) the token to the user device via the cloud server. Manchovski also discloses “- receive second device-specific information of the second user device via the communication link from the second user device as part of the sharing process for the digital use key; - compare the second device-specific information with the first device-specific information of the stored user profile; and - provide the digital use key to the second user device via the communication link depending on the comparison” (Manchovski 129, 141, Fig. 7) where the user validates the token with the blockchain via the cloud server (Manchovski ¶ 141, Fig. 7) which is done with the user’s public key to unencrypt the data. (Manchovski ¶ 129). This is a form of comparison because if the keys are different, the data will not be unencrypted. Finally, Manchovski discloses “wherein the digital verification key does not have any authorization to control one or more lock functions of the lock, and the digital use key has an authorization to control one or more lock functions of the lock” (Manchovski ¶¶ 16, 27) where the public key only unencrypts the token and does not control any lock functions, while the smart contract controls the lock functions.
Manchovski does not appear to explicitly disclose that the lock is part of a vehicle and, therefore, does not appear to explicitly disclose a “back-end unit for a service to provide a vehicle;” “- receive a request relating to the stored user profile to provide a digital use key for the vehicle from a second user device;” or “wherein the digital verification key does not have any authorization to control one or more vehicle functions of the vehicle, and the digital use key has an authorization to control one or more vehicle functions of the vehicle.”
However, Lee discloses a user device of a user of a service for providing a vehicle. (Lee Abstract). A person of ordinary skill in the art prior to the effective filing date would have recognized that when Lee was combined with Manchovski, the lock of Manchovski would be part of a vehicle, as taught by Lee. Therefore, the combination of Manchovski and Lee at least teaches and/or suggests the limitations “[a] back-end unit for a service to provide a vehicle;” “- receive a request relating to the stored user profile to provide a digital use key for the vehicle from a second user device;” and “wherein the digital verification key does not have any authorization to control one or more vehicle functions of the vehicle, and the digital use key has an authorization to control one or more vehicle functions of the vehicle,” rendering them obvious.
Additionally, Lee discloses various other elements of the claimed invention. For instance, Lee discloses wherein the back-end device is configured to “- in a context of a registration for the service, - receive registration data of a user from a first user device of the user for the purpose of creating a user profile via a communication link” (Lee ¶ 86) where a user terminal (i.e., a user device) requests issuance of a shared key and the server (i.e., a back-end unit) receives the request and information on an owner account and the phone to be given the shared key. This is part of the process of creating a user profile. (Lee ¶ 68). Further, Lee discloses “- carry out a sharing process for a digital verification key with the first user device” (Lee ¶ 89) where the digital key is assigned (i.e., shared) with the ID. Moreover, Lee discloses “- receive the first device-specific information of the first user device via the communication link as part of the sharing process for the verification key” (Lee ¶86) where device specific information, such an “email account of for the terminal” (i.e., device-specific information of the user device) is sent to the server. Likewise, Lee discloses “- store the first device-specific information in association with the user profile.” (Lee ¶ 94 and Fig. 4). Lee also discloses “- for a use of the service, - receive a request relating to the stored user profile to provide a digital use key for the vehicle from a second user device” (Lee ¶ 12) by allowing the owner to link the account to a secondary device such as a smartwatch. Lee Fig. 4 shows such accounts being linked with multiple devices, for example account number 2. In addition, Lee discloses “- carry out a sharing process for the digital use key with the second user device” (Lee ¶ 110) where the digital key is received using the same process as the first user device. In addition, Lee discloses “- receive second device-specific information of the second user device via the communication link from the second user device as part of the sharing process for the digital use key” (Lee ¶86) where device specific information, such an “email account of for the terminal” (i.e., device-specific information of the user device) is sent to the server using the same process as for the first device. Finally, Lee discloses “- compare the second device-specific information with the first device- specific information of the stored user profile; and - provide the digital use key to the second user device via the communication link depending on the comparison” (Lee ¶ 65) where the BDC compares the first digital key to the stored keys to determine if they are the same.
Manchovski and Lee are analogous art because they are from the “same field of endeavor,” namely that of smart lock systems.
Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Manchovski and Lee before him or her to modify the smart lock of Manchovski to be implemented on the vehicle of Lee.
The motivation/rationale for doing so would have been that of simple substitution. See KSR Int’l Co v. Teleflex Inc., 550 US 398, 82 USPQ2d 1385, 1396 (U.S. 2007) and MPEP § 2143(I)(B). Manchovski differs from the claimed invention by including a location agnostic lock in place of a vehicle based lock. Further, Lee teaches that smart locks on vehicles were well known in the art. One of ordinary skill in the art could have predictably substituted the vehicle based location of Lee for the unspecified location of Manchovski because the location of the lock does not affect the process of Manchovski.
Regarding claim 10, the combination of Manchovski and Lee discloses the limitations contained in parent claim 9 for the reasons discussed above. In addition, the combination of Manchovski and Lee discloses “wherein the back-end unit is configured to - provide the digital use key to the second user device if the second device-specific information and the first device-specific information are the same; and/or - prevent the provision of the digital use key to the second user device if the second device-specific information differs from the first device-specific information” (Lee ¶¶ 112-114) where each of these may be performed.
Regarding claim 14, it merely recites the method performed by the user device of claim 1. The method comprises performing the various functions. The combination of Manchovski and Lee comprises computer software modules for performing the same functions. Thus, claim 14 is rejected using the same rationale set forth in the above rejection for claim 1.
Regarding claim 15, it merely recites the method performed by the back-end unit of claim 9. The method comprises performing the various functions. The combination of Manchovski and Lee comprises computer software modules for performing the same functions. Thus, claim 15 is rejected using the same rationale set forth in the above rejection for claim 9.
Claims 3, 4, 6, 7, and 11-13 are rejected under 35 U.S.C. § 103(a) as being unpatentable over Manchovski in view of Lee, as applied to claims 1 and 9 above, and in further view of "Car Connectivity Consortium", Digital Key Release 3, Technical Specification, Version 1.2.3 (CCC-TS-101), 2023, pp. 1-539, as cited on the Information Disclosure Statement dated May 22, 2025 (hereinafter CCC).
Regarding claim 3, the combination of Manchovski and Lee discloses the limitations contained in parent claim 1 for the reasons discussed above. In addition, the combination of Manchovski and Lee does not appear to explicitly disclose “wherein the first and/or the second device-specific information contains at least one of an instance CA according to the CCC key standard and an AccountIDHash according to the CCC key standard.”
However, CCC discloses a key sharing protocol “wherein the first and/or the second device- specific information contains at least one of an instance CA according to the CCC key standard and an AccountIDHash according to the CCC key standard.” (CCC 275, 286).
Manchovski, Lee, and CCC are analogous art because they are from the “same field of endeavor,” namely that of digital key sharing.
Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Manchovski, Lee, and CCC before him or her to modify the digital key transfer protocol of Manchovski and Lee to include the standardized vehicle access protocol of CCC by substituting the unspecified protocol of Manchovski and Lee for the CCC protocol.
The motivation for doing so would have been that the CCC standard provides “a standardized Digital Key applet, standardized vehicle access protocol, and a scalable architecture to support wide-scale deployment of the Digital Key services across different Vehicle OEMs and Device OEMs,” all of which are known to be advantageous features. (CCC 36).
Regarding claim 4, the combination of Manchovski and Lee discloses the limitations contained in parent claim 1 for the reasons discussed above. In addition, the combination of Manchovski and Lee does not appear to explicitly disclose “wherein the digital verification key and the digital use key are both designed according to the Car Connectivity Consortium (CCC) key standard including CCC Release 3.”
However, CCC discloses a key sharing protocol “wherein the digital verification key and the digital use key are both designed according to the Car Connectivity Consortium (CCC) key standard including CCC Release 3” (CCC 37, § 2.1 Overview) where CCC release 3 uses both public and digital keys.
Manchovski, Lee, and CCC are analogous art because they are from the “same field of endeavor,” namely that of digital key sharing.
Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Manchovski, Lee, and CCC before him or her to modify the digital key transfer protocol of Manchovski and Lee to include the standardized vehicle access protocol of CCC by substituting the unspecified protocol of Manchovski and Lee for the CCC protocol.
The motivation for doing so would have been that the CCC standard provides “a standardized Digital Key applet, standardized vehicle access protocol, and a scalable architecture to support wide-scale deployment of the Digital Key services across different Vehicle OEMs and Device OEMs,” all of which are known to be advantageous features. (CCC 36).
Regarding claim 6, the combination of Manchovski and Lee discloses the limitations contained in parent claim 5 for the reasons discussed above. In addition, the combination of Manchovski and Lee discloses “- prompt the user via a user interface of the user device to authenticate themselves” (Lee ¶69) by prompting the user to select the digital key to be used in for management of the key. Further, the combination of Manchovski and Lee does not appear to explicitly disclose “- determine the verification signature in response to a successful authentication of the user.”
However, CCC discloses “- determine the verification signature in response to a successful authentication of the user” (CCC 159) where the signature is verified by the OEM server in response to the request to create a friend device.
Manchovski, Lee, and CCC are analogous art because they are from the “same field of endeavor,” namely that of digital key sharing.
Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Manchovski, Lee, and CCC before him or her to modify the digital key transfer protocol of v and Lee to include the standardized vehicle access protocol of CCC by substituting the unspecified protocol of Manchovski and Lee for the CCC protocol.
The motivation for doing so would have been that the CCC standard provides “a standardized Digital Key applet, standardized vehicle access protocol, and a scalable architecture to support wide-scale deployment of the Digital Key services across different Vehicle OEMs and Device OEMs,” all of which are known to be advantageous features. (CCC 36).
Regarding claim 7, the combination of Manchovski and Lee discloses the limitations contained in parent claim 1 for the reasons discussed above. In addition, the combination of Manchovski and Lee does not appear to explicitly disclose “wherein the user device is configured, in the context of registration for the service, to - receive a message from the back-end unit via the communication link to an effect that the verification key has been revoked; and - in response to a revocation of the verification key to - delete the verification key from the secure memory of the user device; and/or - terminate and/or complete the registration for the service.”
However, CCC discloses a key sharing protocol “wherein the user device is configured, in the context of registration for the service, to - receive a message from the back-end unit via the communication link to an effect that the verification key has been revoked” (CCC 195) by receiving a remote key deletion request from the owner device. Additionally, CCC discloses “- in response to a revocation of the verification key to - delete the verification key from the secure memory of the user device; and/or - terminate and/or complete the registration for the service” (CCC 199) by deleting the key.
Manchovski, Lee, and CCC are analogous art because they are from the “same field of endeavor,” namely that of digital vehicle key sharing.
Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Manchovski, Lee, and CCC before him or her to modify the digital key transfer protocol of Manchovski and Lee to include the standardized vehicle access protocol of CCC by substituting the unspecified protocol of Manchovski and Lee for the CCC protocol.
The motivation for doing so would have been that the CCC standard provides “a standardized Digital Key applet, standardized vehicle access protocol, and a scalable architecture to support wide-scale deployment of the Digital Key services across different Vehicle OEMs and Device OEMs,” all of which are known to be advantageous features. (CCC 36).
Regarding claim 11, the combination of Manchovski and Lee discloses the limitations contained in parent claim 9 for the reasons discussed above. In addition, the combination of Manchovski and Lee does not appear to explicitly disclose “wherein the back-end unit is configured, in the context of the registration for the service, to - receive a verification signature for the registration data from the first user device via the communication link; - verify the registration data using the verification signature and the verification key; wherein the registration data and/or the first device-specific information will only be included in the user profile after a successful verification.”
However, CCC discloses a key sharing protocol “wherein the back-end unit is configured, in the context of the registration for the service, to - receive a verification signature for the registration data from the first user device via the communication link” (CCC 202) where the OEM obtains a signature provided through an app. Additionally, CCC discloses “- verify the registration data using the verification signature and the verification key” (CCC 159) where the signature is verified by the OEM server in response to the request to create a friend device. Finally, CCC discloses “wherein the registration data and/or the first device-specific information will only be included in the user profile after a successful verification” (CCC 145) where the key is encoded with the profile, which can only happen after verification, otherwise the process would be highly insecure.
Manchovski, Lee, and CCC are analogous art because they are from the “same field of endeavor,” namely that of digital vehicle key sharing.
Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Manchovski, Lee, and CCC before him or her to modify the digital key transfer protocol of Manchovski and Lee to include the standardized vehicle access protocol of CCC by substituting the unspecified protocol of Manchovski and Lee for the CCC protocol.
The motivation for doing so would have been that the CCC standard provides “a standardized Digital Key applet, standardized vehicle access protocol, and a scalable architecture to support wide-scale deployment of the Digital Key services across different Vehicle OEMs and Device OEMs,” all of which are known to be advantageous features. (CCC 36).
Regarding claim 12, the combination of Manchovski and Lee discloses the limitations contained in parent claim 9 for the reasons discussed above. In addition, the combination of Manchovski and Lee does not appear to explicitly disclose “wherein the back-end unit is configured, as part of the registration for the service, to send a message to the first user device via the communication link to the effect that the verification key has been revoked.”
However, CCC discloses a key sharing protocol “wherein the back-end unit is configured, as part of the registration for the service, to send a message to the first user device via the communication link to the effect that the verification key has been revoked” (CCC 164) where an IN_TERMINATION message is send to the device to notify the user of a termination of the key.
Manchovski, Lee, and CCC are analogous art because they are from the “same field of endeavor,” namely that of digital vehicle key sharing.
Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Manchovski, Lee, and CCC before him or her to modify the digital key transfer protocol of Manchovski and Lee to include the standardized vehicle access protocol of CCC by substituting the unspecified protocol of Manchovski and Lee for the CCC protocol.
The motivation for doing so would have been that the CCC standard provides “a standardized Digital Key applet, standardized vehicle access protocol, and a scalable architecture to support wide-scale deployment of the Digital Key services across different Vehicle OEMs and Device OEMs,” all of which are known to be advantageous features. (CCC 36).
Regarding claim 13, the combination of Manchovski and Lee discloses the limitations contained in parent claim 9 for the reasons discussed above. In addition, the combination of Manchovski and Lee does not appear to explicitly disclose “wherein the back-end unit is configured to - ensure that no certificate is sent to the vehicle for the verification key; and/or - cause a certificate to be sent to the vehicle for the use key; wherein the certification enables the vehicle to verify the use key.”
However, CCC discloses a key sharing protocol “wherein the back-end unit is configured to - ensure that no certificate is sent to the vehicle for the verification key; and/or - cause a certificate to be sent to the vehicle for the use key; wherein the certification enables the vehicle to verify the use key” (CCC 276) where Fig. 16-1 shows the certificate being sent from the server to the owner, who may then sign (i.e., verify) the key.
Manchovski, Lee, and CCC are analogous art because they are from the “same field of endeavor,” namely that of digital vehicle key sharing.
Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Manchovski, Lee, and CCC before him or her to modify the digital key transfer protocol of Manchovski and Lee to include the standardized vehicle access protocol of CCC by substituting the unspecified protocol of Manchovski and Lee for the CCC protocol.
The motivation for doing so would have been that the CCC standard provides “a standardized Digital Key applet, standardized vehicle access protocol, and a scalable architecture to support wide-scale deployment of the Digital Key services across different Vehicle OEMs and Device OEMs,” all of which are known to be advantageous features. (CCC 36).
Response to Arguments
Applicant’s arguments filed August 12, 2026, with respect to the rejections of claims 1-15 under 35 U.S.C. §§ 102 and 103, respectively, (Remarks 10-12) have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground of rejection is made in view of Manchovski and Lee.
Applicant's arguments filed August 12, 2026, with respect to the objections to the claims have been fully considered but they are not persuasive. Specifically, Applicant argues that the present amendments overcome the objections. (Remarks 10). The examiner disagrees because only some of the objects were address with the present amendments. Therefore, Applicant’s argument is unpersuasive.
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 C.F.R. § 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 C.F.R. § 1.17(a)) pursuant to 37 C.F.R. § 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 ANDREW R DYER whose telephone number is (571)270-3790. The examiner can normally be reached Monday-Thursday 7:30-4:30.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Aniss Chad can be reached on 571-270-3832. 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.
/ANDREW R DYER/Primary Examiner, Art Unit 3662
Prosecution Insights