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 .
Priority
The instant application claims priority to provisional application 63/618,151 filed on 05 January 2024. At this time, the priority claim complies with all applicable rules and regulations. Therefore, the effective filing date of the claims is 05 January 2024.
Response to Arguments
Applicant’s arguments, see pages 8-10, filed 02 July 2026, with respect to the previous 35 USC 101 rejection have been fully considered and are persuasive in view of the new claim amendments and the remarks stating that the claims are directed to the improvement of computer functionality using citations to the specification. The 35 USC 101 rejection of claims 1 and 3-20 has been withdrawn.
Applicant's additional arguments filed 02 July 2026 have been fully considered but they are not persuasive.
In response to applicant’s arguments that “Manchovski fails to disclose that ‘network access is not available to the endpoint device,” stated on page 11, the examiner respectfully disagrees.
Manchovski discloses an “online” and an “offline” solution, where offline and online refers to an internet connectivity of the asset or respective smart lock. “Offline”, herein refers to scenarios where the smart lock is never or almost never connected to the internet. For example, in an “offline” scenarios, the smart lock may not have the capability and necessary technical features to independently connect to the internet, but it may be temporarily connected to the internet through another device with which it pairs up using a wire or wireless short distance data connection (Para. 85).
Claim 1 states “obtaining, by the endpoint device and from a requesting device via a direct connection while network access is not available to the endpoint device, a request for a service from the endpoint device”.
Paragraph 85 indicates that in an offline solution the smart lock may never be connected to the internet and may not have the capability and necessary technical features to independently connect to the internet. Therefore, “network access is not available to the endpoint device”.
Therefore, Manchovski teaches the aforementioned limitation.
Examiner note: the limitation does not indicate the type of network or whether the device is not technically capable of the network access. The limitation may be interpreted as referring to a cellular network, for example, but the device may be Internet capable and have Internet access. According to the independent claims, the endpoint device has the capability to connect to the requesting device via a direct network connection, so it has at least one network available to it.
The examiner suggests amending the independent claims to clarify what type of “network” is being referred to and how the network access is not available to the endpoint device, e.g., the device does not have the capability or the network is not available.
In response to applicant’s arguments that the cited prior art does not teach “attempting, by the endpoint device, to establish a certificate chain between a root of trust and a public key usable to verify a signature of the signed response”, stated on page 11, the examiner respectfully disagrees.
As stated above, Manchovski discloses an “online” and an “offline” solution, where offline and online refers to an internet connectivity of the asset or respective smart lock. “Offline”, herein refers to scenarios where the smart lock is never or almost never connected to the internet. For example, in an “offline” scenarios, the smart lock may not have the capability and necessary technical features to independently connect to the internet, but it may be temporarily connected to the internet through another device with which it pairs up using a wire or wireless short distance data connection (Para. 85).
Manchovski further discloses mutual digital signature validation includes each of the smart lock and user device generating a challenge message for the other device, which is then sent to the respective other device wherein the other device signs the challenge using its private key and returns the signed message, so that the authenticity can be confirmed using the public key of the respective device which signed the challenge (Para. 39).
Rombouts discloses the host, e.g., endpoint device, receives 294 and verifies the response, wherein the host checks 296 the signature with the public key from the device authentication certificate, wherein the host then checks 302 the certificate chain up to the trusted party authentication root certificate, wherein as part of checking the certificate chain, the host may verify 302 the device authentication certificate using the public key of the next level certificate, and if the next level certificate is the trusted party authentication root certificate, then the process stops here and the certificate chain is verified, and if the next level certificate was an intermediate authentication certificate, this certificate is verified using the public key of the certificate above it (Para. 82).
Applicant further states “’a public key’ is a term of the art, which is not disclosed in Rombouts” on page 11. However, Rombouts discloses a public key in multiple places including paragraph 82 cited above.
Applicant also states “[t]his is in direct contradiction to ‘network access is not available to the endpoint device’” on page 11. This element is taught by Manchovski—"it may be temporarily connected to the internet through another device with which it pairs up using a wire or wireless short distance data connection” (Para. 85). The independent claims state that the endpoint device communicates with the requesting device via a direct connection. Manchovski discloses that the lock may not have Internet capability, so it may utilize a “short distance data connection”, e.g., a direct connection” to have network access.
Furthermore, there is no indication in Rombouts that the host, e.g., endpoint device, would have to have network access to perform the certificate chain process. Paragraph 82 indicates that the host then checks 302 the certificate chain up to the trusted party authentication root certificate. As part of checking the certificate chain, the host may verify 302 the device authentication certificate using the public key of the next level certificate. If the next level certificate is the trusted party authentication root certificate, then the process stops here and the certificate chain is verified. However, if the next level certificate was an intermediate authentication certificate, this certificate is verified using the public key of the certificate above it.
Therefore, the combination of the cited prior art teaches the aforementioned limitation.
The examiner suggests amending the independent claims to clarify how the certificate chain is being established. For example, the limitation may be interpreted to include the checking of the certificate chain as the establishing aspect as in the chain is being established as each certificate is being checked.
Claim Objections
Claims 8, 21, and 23 are objected to because of the following informalities:
Regarding claim 8, line 4—“a certificate chain” appears to be referring to “a certificate chain” of claim 1, line 14. This objection may be overcome by amending, in accordance with the original disclosure, line 4 to state --the certificate chain-- if it is referring to claim 1, line 14 or to state --a second certificate chain-- if it is different.
Regarding claim 8, line 4—“a root of trust” appears to be referring to “a root of trust” of claim 1, lines 14-15. This objection may be overcome by amending, in accordance with the original disclosure, line 4 to state --the root of trust-- if it is referring to claim 1, lines 14-15 or to state --a second root of trust-- if it is different.
Claims 21 and 23 include similar limitations and are similarly analyzed.
Regarding claim 8, line 5—“a public key” appears to be referring to “a public key” of claim 1, line 15. This objection may be overcome by amending, in accordance with the original disclosure, line 5 to state --the public key-- if it is referring to claim 1, line 15 or to state --a second public key-- if it is different.
Claims 21 and 23 include similar limitations and are similarly analyzed.
Regarding claim 8, line 5—“a signature of the permission certificate” appears to be referring to “a signature of the signed response” of claim 1, lines 15-16. This objection may be overcome by amending, in accordance with the original disclosure, claim 8, line 3 to state --reading, by the endpoint device, a permission certificate from the request, wherein the permission certificate comprises the signature-- and line 5 to state --to verify the signature-- if it is referring to claim 1, lines 15-16 or amending line 5 to state --a second signature-- if it is different.
Claims 21 and 23 include similar limitations and are similarly analyzed.
Appropriate correction is required.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-3, 8-11, 16, and 21-23 are rejected under 35 U.S.C. 103 as being unpatentable over Manchovski (US 2021/0097795 A1) in view of Rombouts (US 2013/0290735 A1).
Regarding claim 1, Manchovski teaches a method for managing endpoint devices, the method comprising:
after an onboarding of an endpoint device, e.g., smart lock 4/sharable asset 204/asset 44/smart lock 504/asset 84 (Fig. 1, el. 4; Fig. 2, el. 204; Fig. 4, el. 44; Fig. 5, el. 504; Fig. 8, el. 84), of the endpoint devices that cryptographically establishes an owner of the endpoint device, e.g., FIG. 4 shows the setup procedure of a smart lock or respective asset 44 using the mobile phone 41 of the owner of the asset (Fig. 4; Para. 89);
S408: After the asset 44 has generated its keys, it sends its own public key to the mobile phone 41 (Fig. 4, el. S408; Para. 97);
S410: The mobile phone 41 then sends its public key to the asset 44 (Fig. 4, el. S410; Para. 99);
S416: After receiving the finalize-setup message, the asset 44 changes to operational mode (Fig. 4, el. S416; Para. 105):
obtaining, by the endpoint device and from a requesting device, e.g., user device 3/user device B203/user device 503/user device 83 (Fig. 1, el. 3; Fig. 2, el. B203; Fig. 5, el. 503; Fig. 8, el. 83), via a direct connection, e.g., a secure Bluetooth Connection 208/Bluetooth radio short distance data connection 508 (Fig. 2, el. 208; Fig. 5, el. 508), while network access is not available to the endpoint device, a request for a service from the endpoint device, e.g., “Offline”, herein refers to scenarios where the smart lock is never or almost never connected to the internet (Para. 85);
the smart lock 504 only has a short distance data connection, such as a Bluetooth radio 508 and, in particular, does not have an internet connection (Para. 110);
the user then sends the validated token to the lock using the UUID of the lock as indicated by the token (Step S707) and the lock approves access (Step S708) (Fig. 7, el. S707, S708; Para. 142);
S805: The user device 83 approaches the smart lock of the asset 84 and, S806, contacts the smart lock of the asset using the Bluetooth ID of the smart lock of the asset 84 (Fig. 8, el. S805; Para. 147);
after the token 506 has been verified and a secure Bluetooth connection has been established between the user device 503 and the smart lock 504, a command, such as a command to open the smart lock 504, may be sent from the user device 503 to the smart lock 504 (Para. 124);
S819: Afterwards the user device 83 can send action instructions such as “open” or “close” instructions to the smart lock of the asset 84 (Fig. 8, el. S819; Para. 160);
attempting, by the endpoint device, to cryptographically verify authority of the requesting device over the endpoint device using, at least in part, information from an ownership voucher used during the onboarding of the endpoint device, e.g., after receiving the token 506, before the smart lock 504 performs any actions such as opening the smart lock 504, an authentication of the smart lock 504 with the user device 503 is necessary, and the smart lock 504 furthermore confirms the authenticity of the token 506 by verifying the digital signature of the owner device 501 using the public key of the owner device 501 (Para. 122);
S815: The smart lock of the asset 84 can confirm that the token was created by the owner device using the owner devices public key and the smart lock of the asset 84 then knows the public key of the correct user device from the smart contract (Fig. 8, el. S815; Para. 156);
the token contains all relevant information regarding the smart contract, so that the terms “token” and “smart contract” may be used interchangeably (Para. 116);
before such a token for granting access to the smart lock 504 can be generated and shared by the owner device 501, the owner device needs to register the smart lock 504 on the Blockchain network 505, so that identity information regarding the smart lock 504 and identity information regarding the owner device 501 are associated with each other in such a way that ownership of the smart lock 504 by the owner device 501 is registered on the Blockchain, wherein this registration may be achieved by creating a respective smart contract—ownership voucher-- (Para. 112);
the owner device generates a respective smart contract—ownership voucher--, which is registered on the Blockchain network for auditing purposes and for verifying the permission of the user and/or the owner (Para. 114),
wherein attempting to cryptographically verify the authority comprises:
issuing, by the endpoint device, a challenge to the requesting device, e.g., S816: The smart lock of the asset 84 creates and sends a challenge for the user device in order to confirm the identity of the user device (Fig. 8, el. S816; Para. 157);
obtaining, by the endpoint device, a signed response to the challenge from the requesting device, e.g., S817: The user device 83 encrypts the challenge using its own private key and sends the signed response, and upon receiving the signed response, the smart lock of the asset 84 can confirm that this is the correct user device (Fig. 8, el. S817; Para. 158); and
…a public key usable to verify a signature of the signed response, e.g., S818: The asset 84 can now verify the identity of the mobile phone using the received information (Fig. 8, el. S818; Para. 159);
mutual digital signature validation includes each of the smart lock and user device generating a challenge message for the other device, which is then sent to the respective other device wherein the other device signs the challenge using its private key and returns the signed message, so that the authenticity can be confirmed using the public key of the respective device which signed the challenge (Para. 39);
in a first instance of the attempting where the authority is not successfully verified: refusing, by the endpoint device, the request, e.g., the second contract information can be used by the user device and the smart lock for mutual authentication, after which the smart lock and user device may pair up for exchanging messages, such as messages to open or lock the smart lock, in accordance with the rules and permissions of the smart contract (Para. 32);
said token 506 which is used for accessing an asset without an internet connection can be described as a self-contained collection of data which the smart lock 504 needs in order to validate the user device 503 against the smart contract and also in order for the smart lock 504 to obtain details of the smart contract such as rules regarding access properties (when, for how long is access permitted) (Para. 123);
the token 506 may furthermore comprise additional rules and restrictions which are part of the smart contract, such as a rental period, how often and/or with which frequency access may be repeated, whether the key can be re-shared with others, whether the ownership rights change sue to the smart contract and/or whether an ability to transfer the owner is provided by the smart contract (Para. 121);
Preferably, if the authentication test fails, the asset should remain in setup mode and the setup procedure should be restarted (Para. 106); and
in a second instance of the attempting where the authority is successfully verified: performing, by the endpoint device, at least one action to service the request, e.g., the second contract information can be used by the user device and the smart lock for mutual authentication, after which the smart lock and user device may pair up for exchanging messages, such as messages to open or lock the smart lock, in accordance with the rules and permissions of the smart contract (Para. 32);
said token 506 which is used for accessing an asset without an internet connection can be described as a self-contained collection of data which the smart lock 504 needs in order to validate the user device 503 against the smart contract and also in order for the smart lock 504 to obtain details of the smart contract such as rules regarding access properties (when, for how long is access permitted) (Para. 123);
the token 506 may furthermore comprise additional rules and restrictions which are part of the smart contract, such as a rental period, how often and/or with which frequency access may be repeated, whether the key can be re-shared with others, whether the ownership rights change sue to the smart contract and/or whether an ability to transfer the owner is provided by the smart contract (Para. 121);
S820: The smart lock of the asset 84 responds by performing the respective action and providing access to the user or the user device 83 (Fig. 8, el. S820; Para. 161);
Preferably, after successful authentication between the user device and the smart lock, …. Other messages and requests which are sent from the user device to the smart lock may furthermore also cause the smart lock to perform respective actions (Para. 40).
Examiner Note: The limitations involving the “first instance” and the “second instance” are contingent limitations in that the “refusing” and “performing” steps are performed contingent on the authority being verified.
See MPEP 2111.04(II)—"The broadest reasonable interpretation of a method (or process) claim having contingent limitations requires only those steps that must be performed and does not include steps that are not required to be performed because the condition(s) precedent are not met. For example, assume a method claim requires step A if a first condition happens and step B if a second condition happens. If the claimed invention may be practiced without either the first or second condition happening, then neither step A or B is required by the broadest reasonable interpretation of the claim. If the claimed invention requires the first condition to occur, then the broadest reasonable interpretation of the claim requires step A.”
Manchovski does not clearly teach attempting, by the endpoint device, to establish a certificate chain between a root of trust and a public key usable to verify a signature of the signed response.
Rombouts teaches issuing, by the endpoint device, e.g., host (Fig. 8), a challenge to the requesting device, e.g., authentication device (Fig. 8);
the authentication operation 280 is performed beginning with the host issuing 284 an authentication request containing a challenge to the authentication device (Fig. 8, el. 284; Para. 81);
obtaining, by the endpoint device, a signed response to the challenge from the requesting device, e.g., in response, the authentication device constructs 288 a response message containing this challenge and signs this response message with its private key (Fig. 8, el. 288; Para. 81); and
attempting, by the endpoint device, to establish a certificate chain between a root of trust and a public key usable to verify a signature of the signed response, e.g., the host receives 294 and verifies the response, wherein the host checks 296 the signature with the public key from the device authentication certificate, wherein the host then checks 302 the certificate chain up to the trusted party authentication root certificate, wherein as part of checking the certificate chain, the host may verify 302 the device authentication certificate using the public key of the next level certificate, and if the next level certificate is the trusted party authentication root certificate, then the process stops here and the certificate chain is verified, and if the next level certificate was an intermediate authentication certificate, this certificate is verified using the public key of the certificate above it (Para. 82).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Manchovski to include attempting, by the endpoint device, to establish a certificate chain between a root of trust and a public key usable to verify a signature of the signed response, using the known method of a host verifying a signed response by checking the certificate chain using the public key, as taught by Rombouts, in combination with the authentication system of Manchovski, for the purpose of increasing the security of the communication channel by providing extra verification of the devices.
Regarding claim 2, Manchovski in view of Rombouts teaches the method of claim 1, wherein the endpoint device is a consumer product, and performing the at least one action comprises activating at least one actuator of the consumer product to change a physical state of the consumer product, e.g., after the token 506 has been verified and a secure Bluetooth connection has been established between the user device 503 and the smart lock 504, a command, such as a command to open the smart lock 504, may be sent from the user device 503 to the smart lock 504, causing the smart lock 504 to unlock wherein “unlocking” may either be a mechanical action, such as a motor which physically moves a bolt of a door, or an electronic or even virtual action through which access to a previously (mechanically, electronically or virtually) locked entity is achieved (Manchovski-Para. 124);
S820: The smart lock of the asset 84 responds by performing the respective action and providing access to the user or the user device 83 (Manchovski-Fig. 8, el. S820; Para. 161).
Regarding claim 3, Manchovski in view of Rombouts teaches the method of claim 1, wherein the direct connection is a point to point connection via a wireless channel, e.g., a secure Bluetooth Connection 208/Bluetooth radio short distance data connection 508 (Manchovski-Fig. 2, el. 208; Fig. 5, el. 508).
Regarding claim 8, Manchovski in view of Rombouts teaches the method of claim 1.
Manchovski further teaches wherein attempting to cryptographically verify the authority comprises: reading, by the endpoint device, a permission certificate, e.g., token 506 (Manchovski-Fig. 5, el. 506), from the request, e.g., data necessary for opening (or other respective actions) of the smart lock 504 is transmitted to the smart lock 504 in the form of a token 506 which represents a smart contract to which the owner device 501 and the user device 503 have agreed with respect to the asset protected by the smart lock 504 (Manchovski-Para. 111);
the user then sends the validated token to the lock using the UUID of the lock as indicated by the token (Step S707) and the lock approves access (Step S708) (Manchovski-Fig. 7, el. S707, S708; Para. 142); and
…a public key usable to verify a signature of the permission certificate, e.g., the token 506 is digitally signed by the owner device 501, wherein the token 506 comprises the public key of the user device 503 and the public key of the smart lock 504 (Manchovski-Para. 44);
the smart lock 504 furthermore confirms the authenticity of the token 506 by verifying the digital signature of the owner device 501 using the public key of the owner device 501 (Manchovski-Para. 122).
Manchovski does not clearly teach attempting, by the endpoint device, to establish a certificate chain between a root of trust and a public key usable to verify a signature of the permission certificate.
Rombouts teaches attempting, by the endpoint device, e.g., host (Fig. 8), to establish a certificate chain between a root of trust and a public key usable to verify a signature of the permission certificate, e.g., the host receives 294 and verifies the response, wherein the host checks 296 the signature with the public key from the device authentication certificate, wherein the host then checks 302 the certificate chain up to the trusted party authentication root certificate, wherein as part of checking the certificate chain, the host may verify 302 the device authentication certificate using the public key of the next level certificate, and if the next level certificate is the trusted party authentication root certificate, then the process stops here and the certificate chain is verified, and if the next level certificate was an intermediate authentication certificate, this certificate is verified using the public key of the certificate above it (Para. 82).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Manchovski to include attempting, by the endpoint device, to establish a certificate chain between a root of trust and a public key usable to verify a signature of the permission certificate, using the known method of a host verifying a signed response by checking the certificate chain using the public key, as taught by Rombouts, in combination with the authentication system of Manchovski, for the purpose of increasing the security of the communication channel by providing extra verification of the devices.
Regarding claim 9, Manchovski in view of Rombouts teaches the method of claim 8, wherein attempting to cryptographically verify the authority further comprises: in an instance of the attempting to establish the certificate chain where the chain is established: comparing a permission delegated to the requesting device by the permission certificate to an action to be performed by the endpoint device as specified by the request to ascertain whether the action is within the permission delegated to the requesting device, e.g., the second contract information can be used by the user device and the smart lock for mutual authentication, after which the smart lock and user device may pair up for exchanging messages, such as messages to open or lock the smart lock, in accordance with the rules and permissions of the smart contract (Manchovski-Para. 32);
said token 506 which is used for accessing an asset without an internet connection can be described as a self-contained collection of data which the smart lock 504 needs in order to validate the user device 503 against the smart contract and also in order for the smart lock 504 to obtain details of the smart contract such as rules regarding access properties (when, for how long is access permitted) (Manchovski-Para. 123);
the token 506 may furthermore comprise additional rules and restrictions which are part of the smart contract, such as a rental period, how often and/or with which frequency access may be repeated, whether the key can be re-shared with others, whether the ownership rights change sue to the smart contract and/or whether an ability to transfer the owner is provided by the smart contract (Manchovski-Para. 121);
S820: The smart lock of the asset 84 responds by performing the respective action and providing access to the user or the user device 83 (Manchovski-Fig. 8, el. S820; Para. 161);
the host receives 294 and verifies the response, wherein the host then checks 302 the certificate chain up to the trusted party authentication root certificate, wherein as part of checking the certificate chain, the host may verify 302 the device authentication certificate using the public key of the next level certificate, and if the next level certificate is the trusted party authentication root certificate, then the process stops here and the certificate chain is verified, and if the next level certificate was an intermediate authentication certificate, this certificate is verified using the public key of the certificate above it (Rombouts-Para. 82).
Regarding claim 10, Manchovski in view of Rombouts teaches the method of claim 1, wherein the requesting device is not owned by the owner of the endpoint device, e.g., in order to share assets, such as houses, apartments, cars or other property items between different users, it is generally necessary that the primary owner of said asset gives a key of the asset to the temporary or additional user (Manchovski-Para. 3);
the proposed solution is generally directed at scenarios, where an owner of a property wants to grant access to a user, wherein the asset is generally protected by a smart lock as defined below and the owner and user each have an associated mobile device, referred to as the owner device and user device in the following, and the owner and user may communicate with each other using their respective mobile devices and they may also send messages to the smart lock of the asset using their respective devices (Manchovski-Para. 8).
Regarding claim 11, the claim is analyzed with respect to claim 1. Manchovski in view of Rombouts further teaches a non-transitory machine-readable medium having instructions stored therein, which when executed by a processor, cause the processor to perform operations for managing endpoint devices, e.g., the methods described herein may be implemented by software programs that are tangibly embodied in a processor-readable medium and that may be executed by a processor (Manchovski-Para. 53).
Regarding claim 16, the claim is analyzed with respect to claim 1. Manchovski in view of Rombouts further teaches an endpoint device, e.g., smart lock 4/sharable asset 204/asset 44/smart lock 504/asset 84 (Manchovski-Fig. 1, el. 4; Fig. 2, el. 204; Fig. 4, el. 44; Fig. 5, el. 504; Fig. 8, el. 84), comprising: a processor; and a memory coupled to the processor to store instructions, which when executed by the processor, cause the endpoint device to perform operations, e.g., the methods described herein may be implemented by software programs that are tangibly embodied in a processor-readable medium and that may be executed by a processor (Manchovski-Para. 53).
Regarding claim 21, the claim is analyzed with respect to claim 8.
Regarding claim 22, the claim is analyzed with respect to claim 10.
Regarding claim 23, the claim is analyzed with respect to claim 8.
Claims 5, 13, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Manchovski in view of Rombouts and further in view of Osborne et al. (US 2017/0180132 A1).
Regarding claim 5, Manchovski in view of Rombouts teaches the method of claim 1.
Manchovski further teaches wherein performing the at least one action comprises:…a key specified by the request…enrolling the key with the endpoint device, e.g., the token 506 comprises the public key of the user device 503—key specified by the request--, the public key of the smart lock 504—key specified by the request--, the local ID—key specified by the request--, such as for example the Bluetooth ID, of the smart lock 504 and the Blockchain address of the smart lock and the smart contract Application Binary Interface (ABI) (Manchovski-Para. 121);
after receiving the token 506, before the smart lock 504 performs any actions such as opening the smart lock 504, an authentication of the smart lock 504 with the user device 503 is necessary, and the smart lock 504 furthermore confirms the authenticity of the token 506 by verifying the digital signature of the owner device 501 using the public key of the owner device 501 (Manchovski-Para. 122).
Manchovski in view of Rombouts does not clearly teach wherein performing the at least one action comprises: generating, by the endpoint device, a supplemental certificate using a key specified by the request, the supplemental certificate enrolling the key with the endpoint device.
Osborne teaches wherein performing the at least one action comprises: generating, by the endpoint device, e.g., Data processing system 200 (Fig. 2, el. 200), a supplemental certificate using a key specified by the request, the supplemental certificate enrolling the key with the endpoint device, e.g., when transferring device ownership control directly to a known entity, device ownership transfer manager 246 may issue a transition certificate designating the known entity as the next owner of the device (Fig. 2, el. 246; Para. 49);
Digital certificate 226 includes public key 228 and current owner identity 230, wherein public key 228 corresponds to the current owner of data processing system 200 (Para.39);
the processor unit 204 receives a request to transfer the ownership of the device from the current device owner set in the current owner register of the processor unit to a service key device owner—key specified in the request-- and designates a successor device owner with a device ownership reversibility control bit not set in the request (step 1006) (Fig. 2, el. 204; Fig. 10, el. 1006; Para. 118).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Manchovski in view of Rombouts to include wherein performing the at least one action comprises: generating, by the endpoint device, a supplemental certificate using a key specified by the request, the supplemental certificate enrolling the key with the endpoint device, using the known method of receiving, by a data processing system, a request to transfer ownership that includes an indication of a service key device owner as the next owner and generating, by the data processing system, a certificate that designates the next owner, as taught by Osborne, in combination with the authentication system of Manchovski in view of Rombouts, for the purpose of providing a more effective system of managing the ownership of a device by keeping track of current and previous ownership.
Regarding claim 13, the claim is analyzed with respect to claim 5.
Regarding claim 18, the claim is analyzed with respect to claim 5.
Claims 6, 7, 14, 15, 19, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Manchovski in view of Rombouts in view of Osborne and further in view of Zhu (US 8,120,460 B1).
Regarding claim 6, Manchovski in view of Rombouts in view of Osborne teaches the method of claim 5.
Manchovski further teaches after performing the at least one action to service the request:
obtaining, by the endpoint device and from a…requesting device, e.g., user device 3/user device B203/user device 503/user device 83 (Fig. 1, el. 3; Fig. 2, el. B203; Fig. 5, el. 503; Fig. 8, el. 83), via a second direct connection, e.g., a secure Bluetooth Connection 208/Bluetooth radio short distance data connection 508 (Fig. 2, el. 208; Fig. 5, el. 508), while the network access is not available to the endpoint device, a second request, e.g., “Offline”, herein refers to scenarios where the smart lock is never or almost never connected to the internet (Para. 85);
the smart lock 504 only has a short distance data connection, such as a Bluetooth radio 508 and, in particular, does not have an internet connection (Para. 110);
the user then sends the validated token to the lock using the UUID of the lock as indicated by the token (Step S707) and the lock approves access (Step S708) (Fig. 7, el. S707, S708; Para. 142);
S805: The user device 83 approaches the smart lock of the asset 84 and, S806, contacts the smart lock of the asset using the Bluetooth ID of the smart lock of the asset 84 (Fig. 8, el. S805; Para. 147);
after the token 506 has been verified and a secure Bluetooth connection has been established between the user device 503 and the smart lock 504, a command, such as a command to open the smart lock 504, may be sent from the user device 503 to the smart lock 504 (Para. 124);
S819: Afterwards the user device 83 can send action instructions such as “open” or “close” instructions to the smart lock of the asset 84 (Fig. 8, el. S819; Para. 160); and
attempting, by the endpoint device, to cryptographically verify authority of the…requesting device over the endpoint device using, at least in part, the information from the ownership voucher used during the onboarding of the endpoint device…, e.g., after receiving the token 506, before the smart lock 504 performs any actions such as opening the smart lock 504, an authentication of the smart lock 504 with the user device 503 is necessary, and the smart lock 504 furthermore confirms the authenticity of the token 506 by verifying the digital signature of the owner device 501 using the public key of the owner device 501 (Para. 122);
S815: The smart lock of the asset 84 can confirm that the token was created by the owner device using the owner devices public key and the smart lock of the asset 84 then knows the public key of the correct user device from the smart contract (Fig. 8, el. S815; Para. 156);
the token contains all relevant information regarding the smart contract, so that the terms “token” and “smart contract” may be used interchangeably (Para. 116);
before such a token for granting access to the smart lock 504 can be generated and shared by the owner device 501, the owner device needs to register the smart lock 504 on the Blockchain network 505, so that identity information regarding the smart lock 504 and identity information regarding the owner device 501 are associated with each other in such a way that ownership of the smart lock 504 by the owner device 501 is registered on the Blockchain, wherein this registration may be achieved by creating a respective smart contract—ownership voucher-- (Para. 112);
the owner device generates a respective smart contract—ownership voucher--, which is registered on the Blockchain network for auditing purposes and for verifying the permission of the user and/or the owner (Para. 114).
Manchovski in view of Rombouts does not clearly teach after performing the at least one action to service the request:
obtaining, by the endpoint device and from a second requesting device via a second direct connection while the network access is not available to the endpoint device, a second request; and
attempting, by the endpoint device, to cryptographically verify authority of the second requesting device over the endpoint device using, at least in part, the information from the ownership voucher used during the onboarding of the endpoint device and the supplemental certificate.
Rombouts further teaches attempting, by the endpoint device, to cryptographically verify authority…over the endpoint device using, at least in part, the information from the ownership voucher used during the onboarding of the endpoint device and the supplemental certificate, e.g., the host receives 294 and verifies the response, wherein the host checks 296 the signature with the public key from the device authentication certificate, wherein the host then checks 302 the certificate chain up to the trusted party authentication root certificate, wherein as part of checking the certificate chain, the host may verify 302 the device authentication certificate using the public key of the next level certificate, and if the next level certificate is the trusted party authentication root certificate, then the process stops here and the certificate chain is verified, and if the next level certificate was an intermediate authentication certificate, this certificate is verified using the public key of the certificate above it (Para. 82).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Manchovski to include attempting, by the endpoint device, to cryptographically verify authority over the endpoint device using, at least in part, the information from the ownership voucher used during the onboarding of the endpoint device and the supplemental certificate, using the known method of a host verifying a signed response by checking the certificate chain using the public key, as taught by Rombouts, in combination with the authentication system of Manchovski, using the same motivation as in claim 4.
Note: Osborne also discloses when transferring device ownership control directly to a known entity, device ownership transfer manager 246 may issue a transition certificate—supplemental certificate-- designating the known entity as the next owner of the device (Fig. 2, el. 246; Para. 49). Digital certificate 226 includes public key 228 and current owner identity 230, wherein public key 228 corresponds to the current owner of data processing system 200 (Para.39). The processor unit 204 receives a request to transfer the ownership of the device from the current device owner set in the current owner register of the processor unit to a service key device owner and designates a successor device owner with a device ownership reversibility control bit not set in the request (step 1006) (Fig. 2, el. 204; Fig. 10, el. 1006; Para. 118).
Manchovski in view of Rombouts in view of Osborne does not clearly teach after performing the at least one action to service the request:
obtaining, by the endpoint device and from a second requesting device via a second direct connection while the network access is not available to the endpoint device, a second request; and
attempting, by the endpoint device, to cryptographically verify authority of the second requesting device over the endpoint device using, at least in part, the information from the ownership voucher used during the onboarding of the endpoint device and the supplemental certificate.
Zhu teaches obtaining, by the endpoint device and from a second requesting device, e.g., second mobile electronic device 103 (Fig. 1, el. 103), via a second direct connection while the network access is not available to the endpoint device, a second request, e.g., In block 324, the second mobile electronic device 103 is enabled to lock and unlock the electronic lock 104 via near-field-communications (Fig. 4, el. 324; Col. 8, lines 55-57);
attempting, by the endpoint device, to…verify authority of the second requesting device over the endpoint device…, e.g., in block 218, the additional electronic access codes can be transmitted from the mobile electronic device 102 to the additional mobile electronic devices, via near-field-communications, which are then enabled to lock and unlock the electronic lock 104 (Col. 6, lines 62-66).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Manchovski in view of Rombouts in view of Osborne to include after performing the at least one action to service the request: obtaining, by the endpoint device and from a second requesting device via a second direct connection while the network access is not available to the endpoint device, a second request; and attempting, by the endpoint device, to cryptographically verify authority of the second requesting device over the endpoint device using, at least in part, the information from the ownership voucher used during the onboarding of the endpoint device and the supplemental certificate, using the known method of changing ownership of an electronic lock and providing the new owner with the new code to unlock the lock, as taught by Zhu, in combination with the authentication system of Manchovski in view of Rombouts in view of Osborne, for the purpose of enabling a permanent option for transferring the ownership of an electronic lock.
Regarding claim 7, Manchovski in view of Rombouts in view of Osborne in view of Zhu teaches the method of claim 6, wherein the supplemental certificate indicates that a public key maintained by the second requesting device has authority over the endpoint device, e.g., the host then checks 302 the certificate chain up to the trusted party authentication root certificate, wherein as part of checking the certificate chain, the host may verify 302 the device authentication certificate using the public key of the next level certificate, and if the next level certificate is the trusted party authentication root certificate, then the process stops here and the certificate chain is verified, and if the next level certificate was an intermediate authentication certificate, this certificate is verified using the public key of the certificate above it (Rombouts-Para. 82);
In block 324, the second mobile electronic device 103 is enabled to lock and unlock the electronic lock 104 via near-field-communications (Zhu-Fig. 4, el. 324; Col. 8, lines 55-57);
Note: Osborne also discloses when transferring device ownership control directly to a known entity, device ownership transfer manager 246 may issue a transition certificate—supplemental certificate-- designating the known entity as the next owner of the device (Fig. 2, el. 246; Para. 49). Digital certificate 226 includes public key 228 and current owner identity 230, wherein public key 228 corresponds to the current owner of data processing system 200 (Para.39). The processor unit 204 receives a request to transfer the ownership of the device from the current device owner set in the current owner register of the processor unit to a service key device owner and designates a successor device owner with a device ownership reversibility control bit not set in the request (step 1006) (Fig. 2, el. 204; Fig. 10, el. 1006; Para. 118).
Regarding claim 14, the claim is analyzed with respect to claim 6.
Regarding claim 15, the claim is analyzed with respect to claim 7.
Regarding claim 19, the claim is analyzed with respect to claim 6.
Regarding claim 20, the claim is analyzed with respect to claim 7.
Relevant Prior Art
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Loreskar (US 2019/0074980 A1)—Loreskar discloses each OEM may then certify as valid particular electronic devices who may have their own certificates 30-D generated as children of the OEM certificates within the chain of trust. Hence, the chain of trust provides a tree of certificates, where a child certificate is attested as valid by an attestor associated with a parent certificate in the chain of trust (Para. 40).
Yacoub et al. (US 2016/0205097 A1)—Yacoub et al. discloses establishing ownership of a component of an internet of things (“IoT”) device (Abstract).
Ur et al. (US 2021/0150527 A1)—Ur et al. discloses receiving a transaction request, for transferring ownership of a product from a current owner to a subsequent owner, the transaction request being signed by the current owner (Abstract).
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JEREMY DUFFIELD whose telephone number is (571)270-1643. The examiner can normally be reached Monday - Friday, 7:00 AM - 3:00 PM (ET).
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, Yin-Chen Shaw can be reached at (571) 272-8878. 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.
02 September 2026
/Jeremy S Duffield/Primary Examiner, Art Unit 2498
Prosecution Insights