Access control system and method for regulated devices

Abstract

Regulated embedded devices, such as electronic nicotine delivery system (ENDS) products are often targeted by unauthorized users. For instance, minors may attempt to gain access to ENDS products. The disclosure herein provides an authentication and control mechanism for (1) tracking and controlling a regulated embedded device beyond initial activation and throughout the lifetime of the device and (2) limiting sharing of credentials or active login sessions of authorized users with unauthorized users. The embedded device may establish an operative electronic communication connection to a computing device such as a smartphone of a user that runs an application or browser-based application. Via this connection, the custody of the embedded device in the possession of an authorized user may be verified. Moreover, a location of the embedded device may be determined for devices that are selectively inhibited in certain locations, and the device may be selectively inhibited.

Description

ACCESS CONTROL SYSTEM AND METHOD FOR REGULATED DEVICESCross-Reference to Related Application

[0001] This application is based upon and claims priority to U.S. Provisional Patent Application No. 63 / 540,295 entitled “ACCESS CONTROL METHOD FOR REGULATED DEVICES” and filed on September 25, 2023, the entire content of which is incorporated herein by reference.Field

[0002] The present invention is directed to access control, and more specifically, the present disclosure is directed to access control for regulated devices.Background

[0003] Regulated embedded devices, such as electronic nicotine delivery system (ENDS) products are often targeted by unauthorized users. For instance, minors may attempt to gain access to ENDS products. Current mitigation techniques focus on identify verification at a point of sale or during first-time activation. However, a cooperative authorized user may acquire such products and then share them with unauthorized users. Thus there remains a need for enhanced access control systems and methods for regulated embedded devices.Summary

[0004] In various embodiments, a system is provided for access control to an access controlled regulated device, the system may include the access-controlled embedded device having a processor, a transceiver connectable to a smartphone, and a memory. The system may include an application running on a smartphone, the application connectable to the processor via the transceiver, wherein the access-controlled embedded device connects to the smartphone to retrieve a unique device identifier from the smartphone. The system may include a verification server configured to store a private signing key. The application may be connectable via the smartphone to the verification server. The verification server may sign with the private signing key a payload including a unique device identifier of the smartphone to generate a signed payload and may send the signed payload to the access-controlled embedded device via the application running on the smartphone. The access-controlled embedded device authorizes operation of the access-controlled embedded device in response to a checking by the access-controlled embedded device of a correspondence of the unique device identifier from the signed payload and the unique device identifier from the smartphone.

[0005] In various embodiments, the device identifier may be a second public key corresponding to a second private key of a second public-private key pair. The second publicprivate key pair is generated by the phone. The second private key is in a secure element of the phone. The phone may sign a token with the second private key and may provide the signed token to the device. The device may utilize the second public key that is the device identifier to verify the authenticity of the token as being signed by the second private key. The verifying the authenticity may confirm that the smartphone is a same smartphone that has been previously controlled by a verified user. In various embodiments, a processor of thedevice may activate the device and may permit control of the device by the phone in response to the verifying of the authenticity.

[0006] In various instances, the checking the correspondence includes determining that the unique device identifiers are identical. In various embodiments, the checking the correspondence includes determining that the unique device identifiers are identical and comparing the signed payload signed by the private signing key to a verification key stored in the memory of the access-controlled embedded device to confirm that the signed payload is from the verification server and has not been modified.

[0007] The signed payload may also include data corresponding to a verified age of the user exceeding a threshold, wherein the access-controlled embedded device authorizes operation of the access-controlled embedded device further in response to a checking by the access- controlled embedded device that the verified age exceeds the threshold, and wherein the access-controlled embedded device includes an electronic nicotine delivery system (ENDS). The application running on the smartphone may access geolocation data corresponding to a location of the smartphone and may selectively deactivate the access-controlled embedded device in response to the smartphone being in a location that use of the access-controlled embedded device is forbidden.

[0008] The application running on the smartphone may periodically connect to the processor via the transceiver at a first interval and the processor of the access-controlled embedded device may deactivate the access-control embedded device in response to a period of time corresponding to the first interval passing without a connecting of the application to the processor occurring via the transceiver. In various instances, the application is a browserbased application.

[0009] An access-controlled embedded device may be provided. The device may include a processor and a transceiver connectable to a smartphone. The processor may connect to anapplication on a smartphone via the transceiver. The processor may selectively activate the access-controlled embedded device in response to a determination that a device identifier of the smartphone that is received by the transceiver corresponds to a device identifier of the smartphone contained in a payload from a verification server.

[0010] In various embodiments, the payload is a cryptographically signed payload. The cryptographically signed payload may be signed by the verification server in electronic communication with the smartphone. The access-controlled embedded device may include a memory to store a verification key. The signed payload may be signed by a private signing key of which the verification key is a paired public key. The device identifier of the smartphone may include a unique identifier of a component of the smartphone connectable to the transceiver. The component may be a Bluetooth radio transceiver and the device identifier may be a hardware address of the Bluetooth radio transceiver. The access- controlled embedded device may be an electronic nicotine delivery system (ENDS).

[0011] In various embodiments, the processor deactivates the access-controlled embedded device in response to a location determination corresponding a location that use of the access- controlled embedded device is forbidden. The location determination may be performed by a smartphone connected to the processor via the transceiver.

[0012] The processor periodically connects to the smartphone via the transceiver at a first interval and wherein the processor of the access-controlled embedded device deactivates the access-controlled embedded device in response to a period of time corresponding to the first interval passing without a connecting of the application to the processor occurring via the transceiver.

[0013] In various instances, the verification server assigns a unique user identifier to a user corresponding to a prior verification of an authorization of the user to use the access- controlled embedded device and wherein the server retrieves one or more unique identifiersof the smartphone and attributes the one or more unique identifiers of the smartphone to the unique user identifier, wherein the signed payload further includes the unique user identifier, and wherein the processor further selectively activates the access-controlled embedded device in response to a determination that the signed payload having the unique user identifier is unaltered.

[0014] A method of activating an embedded device by a user is provided. The method may include sending, by an application on a smartphone, an activation request to a server. The activation request may include an authentication token of the application and an unique identifier of the embedded device to be activated and a one-time random challenge generated by the device. The method may include receiving, by the server, the activation request. In various embodiments, the method may include receiving, by the server and from the application on the smartphone, an activation request, wherein the activation request includes an authentication token of the application, and a unique identifier of the embedded device to be activated, and a one-time random challenge generated by the device. The method may include verifying, by the server, a validity of the authentication token of the application. The method may include verifying, by the server, that the user has previously been added as an authorized user to a database accessible by the server. The method may include extracting, by the server, the unique identifier and the one-time random challenge from the activation request. The method may include digitally signing, by a private key of the server, an activation command that includes (i) a unique identifier of the smartphone, (ii) the device identifier, and (iii) the one-time random challenge. The method may include sending, by the server the activation command to the device through the application.

[0015] The method may include one or more further aspect. For instance, in various embodiments, the device receives the activation command and, in response to receiving the activation command, the device performs certain verifications. For instance, the verificationsmay include (i) the digital signing by the private key of the server using a stored verification key of the server; (ii) that the device identifier is correct; and (iii) that the one-time challenge is correct. The method may include that the device activates in response to the verifying.

[0016] In various embodiments, a method of granting access to an access-controlled embedded device is provided. The method may include signing, by a verification server, a payload including a unique device identifier of a smartphone to generate a signed payload. The method may include sending the signed payload to the access-controlled embedded device via an application running on a smartphone. The method may include authorizing, by the access-controlled embedded device, operation of the access-controlled embedded device in response to a checking by the access-controlled embedded device of a correspondence of the unique device identifier from the signed payload to the unique device identifier from the smartphone.Brief Description of Figures

[0017] A more complete understanding of the present invention may be derived by referring to the detailed description and claims when considered in connection with the Figures, where like reference numbers refer to similar elements throughout the Figures, and:

[0018] FIG. 1A is a diagram of a system for access control of regulated devices, in accordance with various embodiments;

[0019] FIG. IB is a diagram of an embedded device, in accordance with various embodiments;

[0020] FIG. 2 is a diagram of an example method of user verification, in accordance with various embodiments;

[0021] FIG. 3 is a diagram of an example method of verifying that a phone being used to activate an embedded device is a same phone on which the user verification of FIG. 2 took place, in accordance with various embodiments;

[0022] FIG. 4 depicts a diagram of method of activating an embedded device by a user, in accordance with various embodiments; and

[0023] FIG. 5 depicts a diagram of a method of granting access to an access-controlled regulated device, in accordance with various embodiments.Detailed Description

[0024] The following description is of various exemplary embodiments only, and is not intended to limit the scope, applicability, or configuration of the present disclosure in any way. Rather, the following description is intended to provide a convenient illustration for implementing various embodiments including the best mode. As will become apparent, various changes may be made in the function and arrangement of the elements described in these embodiments without departing from the scope of the appended claims.

[0025] Regulated embedded devices, such as electronic nicotine delivery system (ENDS) products are often targeted by unauthorized users. For instance, minors may attempt to gain access to ENDS products. Current mitigation techniques focus on identify verification at a point of sale or during first-time activation. However, a cooperative authorized user may acquire such products and then share them with unauthorized users.

[0026] Prior efforts include requiring a user account to buy or activate a device. However, user account credentials may be stolen. In further instances, user account credentials may be deliberately shared among authorized and unauthorized users. Yet furthermore, an active login session can be reused across multiple devices that share and synchronize the same login session information or browser cookies.

[0027] The disclosure herein provides for (1) tracking and controlling a regulated embedded device beyond initial activation and throughout the lifetime of the device and (2) limiting sharing of credentials or active login sessions of authorized users with unauthorized users.

[0028] A system may provide for identification of a phone of an authorized user and linking of the phone to an account of the authorized user. An application running on the phone, such as a smartphone application may provide for user verification and for device control over a wireless connection such as Bluetooth Low Energy (BLE) or Bluetooth Classic.

[0029] In various embodiments, rather than providing for a smartphone application, a web browser application communicating with a remote server may be utilized. The web browser application may run on the smartphone on a web browser that supports Bluetooth or Bluetooth Low Energy and provides wireless remote control for the server to control the device over Bluetooth, such as by using the Web Bluetooth specification.

[0030] In an example embodiment, user verification may include collecting of one or more unique identified s) of the user’s phone(s). An example process is illustrated in FIG. 2, which will be discussed further herein. If the verification process is completed successfully and the embedded device is to be activated, the system verifies that the phone being used to activate the device is the same phone on which the user verification process took place. An example process is illustrated in FIG. 3.

[0031] In various embodiments, further integrity of the access control system and method is enhanced by a requirement for the regulated embedded device and the smartphone to remain in adequate proximity to maintain a wireless connection such as by Bluetooth Low Energy (or Classic Bluetooth). Upon disconnection, the regulated embedded device may operate for a short grace period prior to shutting off until reconnected to the smartphone.

[0032] Yet furthermore, phone identifiers may be bound to user login sessions so that user login sessions may not be reused on different phones than the one the user login session is created on. A number of concurrent login sessions for a given user may also be limited by the server, as well as a number of concurrent active devices connected to the user’s phone. Moreover, the application may collect geolocation data from the phone and shut the device off in areas where use is forbidden. For instance, in some locations such as schools, use ofENDS devices may be forbidden.

[0033] The phone identifiers mentioned above may include one or more aspect. For instance, in various embodiments, the phone identifier includes the phone’s Bluetooth identity address.In further instance, the phone identifier may include a public key of a public-private key pair. In further instance, the phone identifier may include a private key of a public-private key pair. If abuse of certain phone identifiers is discovered, the phone identifiers can be blacklisted (e.g., blocked). One example of abuse is a private key that has been compromised and published online.

[0034] For instance, in an embodiment with a phone identifier that is the phone’s Bluetooth identity address, since applications cannot access the phone’s Bluetooth identify address on modem phones for privacy reasons, the embedded device is configured to retrieve the phone’s address and send it to the application, which in turn sends it to the server. If the phone is using ephemeral random Bluetooth addresses for privacy, the device may need to bond with the phone to retrieve the identity address.

[0035] In an embodiment with a phone identifier that is a public key, the public key may correspond to a private key that is generated inside of a secure element (SE) or a trusted execution environment (TEE) on the phone. The private key never leaves the phone’s SE or TEE and is used to authenticate the phone to the device by digitally signing a device’s challenge or a pairing transcript.

[0036] Turning now to FIGs. 1A-B, in an example system for access control of regulated devices (system 2), a user 4 may desire to access a device 6. The device 6 may be a regulated device. The device 6 may have a processor, and may be an embedded device, thus being a device with embedded processing functionality. Moreover, the embedded device may be access-controlled, meaning systems and methods for access control of regulated devices are implemented thereon. The device 6 may be a nicotine delivery device. For instance, the device 6 may be an aspect of an electronic nicotine delivery system (ENDS).

[0037] The device 6 may have several components. The device 6 may have a processor 60. The processor 60 may be any computing device, such as an embedded processor ormicrocontroller. The device 6 may have a memory 62. The memory 62 may be any electronic memory connectable to the processor 60 and providing working memory and / or storage memory. The memory 62 may store electronic keys, such as one or more key of one or more public-private key pair. The memory 62 may store a corresponding verification key (public key) associated with a private signing key (which may be retained by a server 10 such as a verification server). The transceiver 64 may be an electronic communication device connected to the processor 60 to enable the processor 60 to communicate with other devices. For instance, the transceiver 64 may be a radio transceiver, such as a Bluetooth transceiver, and may be operatively connectable to a phone 5 of the user 4 to enable the processor 60 to communicate with the phone 5 of the user 4.

[0038] The system 2 may include an application 8. The application 8 may be associated with verifying custody of the device 6 by an authorized user 4. For instance, the application 8 may run on a phone 5. The phone 5 may contain data corresponding to a unique identifier attributable to an identity of the user 4. The smartphone may run the one or more application 8, which may be a smartphone application, or a web application running in a browser session. The application 8 may have the unique identifier attributable to the identity of the user 4. In this manner, the device 6 may connect to the application 8 running on the phone 5 and selectively enable or disable use of the device 6 based on verification of an authorized user 4.

[0039] The system 2 may include a server 10. The server 10 may have one or more verification component to verify authenticity of the identity and / or unique identifier attributable to the identity, of the user 4. In various embodiments, the server 10 contains a private signing key associated with the verification key (public key) in the memory 62 of the device 6.

[0040] Thus, with reference to the combination of FIGs. 1A and IB, a system 2 may include an access-controlled embedded device 6. The access-controlled embedded device 6 mayrequire activation before a first use. The embedded device 6 may be equipped with a processor 60, a memory 62, and a transceiver 64 such as a Bluetooth transceiver. The Bluetooth transceiver may support Bluetooth low energy (BLE) and / or Classic Bluetooth. The system 2 may include an application 8. The application 8 may be running on a phone 5 or other device. The application 8 may be for user verification and device control. The application 8 may be a native smartphone application. The application 8 may be a web application running on a browser of a phone 5 supporting Web Bluetooth. The system 2 may include a server 10. The server 10 may be a verification server. The server 10 may store a private signing key. A corresponding verification key that corresponds to the private signing key may be stored on the device 6.

[0041] In one example embodiment, the server 10 may assign a unique identifier to each user 4. The server 10 may require the user 4 to complete a user verification process on the application 8 to verify that the user 4 is authorized to use the device 6. As part of the user verification process, the server 10 may be configured to retrieve one or more unique identifiers of the phone 5 running the application 8 (e.g, the phone 5 of the user 4), and attribute the one or more unique identifiers to the user’s identifier.

[0042] In various embodiments, a Bluetooth identity address of the phone 5 running the application 8 (user’s phone or the phone 5 of the user 4) may be a phone identifier of the phone 5 of the user 4. In some instances, the application 8 is configured to connect to the device 6, and the device 6 is configured to retrieve the Bluetooth identity address of the phone 5 on which the application 8 is running. Retrieving the identity address of the phone 5 may require bonding to be completed between the device 6 and the phone 5. The device 6 is configured to send the Bluetooth identity address of the phone 5 to the application 8, and the application 8 is in turn configured to send the Bluetooth identity address of the phone 5 to theserver 10. The server 10 may be configured to use the Bluetooth identity address of the phone 5 as a phone identifier.

[0043] In various embodiment, the phone identifier may be a hardware-backed key of the phone 5. For instance, the application 8 may be configured to generate a cryptographic key pair, inside a Trusted Execution Environment (TEE) of the phone 5 or Secure Element (SE) of the phone 5. For an Android phone 5, the application 8 may be configured to generate a cryptographic key pair inside an Android keystore. For an iOS phone 5, the application 8 may be configured to generate a cryptographic key pair inside an iOS secure enclave. The cryptographic key pair may include a private key (the private key of the application 8) that never leaves the TEE or SE and the corresponding public key (the public key of the application 8) that the operating system (OS) of the phone 5 returns to the application 8.

[0044] The application 8 may perform one or more further operations. For instance, the application 8 may be configured to use key attestation APIs provided by an operating system of the phone 5 to generate an operating system certificate chain for the public key of the application 8. The chain may attest that the private key of the application 8 is generated in a hardware-backed TEE or SE. The application 8 may send the key certificate chain to the server 10.

[0045] The server 10 may perform one or more further operations. For instance, the server 10 may verify the OS certificate chain using an OS root key or using OS manufacturer servers. If this verification is successful, the server 10 may use the public key of the application 8 extracted from the OS certificate chain as a phone identifier of the phone 5.

[0046] Returning to a discussion of the user verification process, as previously mentioned, the server 10 may assign a unique identifier to each user 4. The server 10 may require the user 4 to complete a user verification process on the application 8 to verify that the user 4 is authorized to use the device 6. As part of the user verification process, the server 10 may beconfigured to retrieve one or more unique identifiers of the phone 5 running the application 8 (e.g, the phone 5 of the user 4), and attribute the one or more unique identifiers to the user’s identifier. Phone identifiers may be used in this user verification process. For example, in various embodiments, the server 10 may issue an authentication token to the application 8 on the phone 5. The authentication token may include various items. For instance, the authentication token may include a unique identifier of the user 4. The authentication token may include the one or more unique identifiers of the phone 5 of the user 4. The authentication token may include validity (expiry) information. The authentication token may include a digital signature or message authentication code. The digital signature or message authentication code may authenticate the values in the authentication token fields. The digital signature or message authentication code may be generated using the private key of the server 10.

[0047] In various embodiments, the server 10 returns the authentication token to the application 8. The server 10 may return the authentication token as a Jason Web Token (JWT). The server 10 may return the authentication token as a digital certificate. The server 10 may return the authentication token as both a Jason Web Token (JWT) and a digital certificate.

[0048] As a part of the user verification, the application 8 may be configured to send a user verification request to the server 10. The request may include various aspects. For example, the user verification request may include the user information that is necessary for user verification. The user verification request may include the authentication token received from the server 10. Upon receiving the user verification request, the server 10 may also perform steps.

[0049] For instance, upon receiving the user verification request, the server 10 may verify an authenticity and / or validity of the authentication token of the application 8. The server 10may consider the user verification process successful if the verification of both the authentication token of the application 8 and also the user information of the user 4 is successful. In response to the user verification proceeding successfully, the server 10 may update the authentication token of the application 8 to indicate that the user 4 is verified and update the authentication token’s signature or message authentication code accordingly. In embodiments where the application 8 is a web application, the server 10 may be further configured to return the issued authentication token in the HTTP response as part of the Set- Cookie header. As such, the browser of the phone 5 running the web application may store such a token as a secure, HTTP-only cookie. The cookie may be stored by the browser of the phone 5 and may be stored so that it cannot be accessed by the application 8.

[0050] Phone identifiers may be used in device activation of the device 6. For instance, the application 8 may be configured to allow a user 4 who is a verified user 4 to activate the device 6. In this case, the application 8 may send an activation request to the server 10. The activation request may include the authentication token of the application 8 and the unique identifier of the device 6. For instance, the unique identifier may be the Bluetooth address of the device 6. In various embodiments, the device 6 may generate a one-time random challenge and the application 8 on the phone 5 may include the one-time challenge in the activation request for device activation of the device 6. When the server 10 receives the activation request, then the server 10 is configured to take various responsive actions. For instance, the server 10 may verify the authenticity and the validity of the authentication token of the application 8. The server 10 may verify that the authentication token of the application 8 and / or the database of the server 10 indicate that the user 4 is verified. The server 10 may extract one or more phone identifier(s) of the phone 5 from the authentication token. The server 10 may extract, from the activation request, the device identifier of the device 6 and the one-time random challenge of the device 6 (if applicable). The server 10 may digitallysign, using a private key of the server 10, an activation command. The activation command may include the one or more phone identifier(s) of the phone 5. The activation command may include a device identifier of the device 6. The activation command may include a one-time random challenge of the device 6 (if applicable). The server 10 may send the activation command to the device 6 through the application 8 of the phone 5. The device 6 may take responsive actions in response to receiving the activation command from the server 10 through the application 8 of the phone 5.

[0051] The device 6 may take actions including one or more of the following. For instance, the device 6 may verify the server’s signature of the server 10 by using the stored server’s verification key of the server 10. The device 6 may verify that the device identifier of the device 6 and the one-time challenge (if applicable) in the activation command match the values known to the device 6. The device 6 may reject the activation command and disconnect if any of the aforementioned items (e.g., the server’s signature of the server 10, the device identifier of the device 6, and the one-time challenge (if applicable)) fail verification such as by not matching an expected value.

[0052] In some examples, the Bluetooth identity address of the phone 5 is included in the activation command. The device 6 may be configured to reject the activation command and disconnect if the Bluetooth identity of the phone 5 extracted from the activation command is not the same as the Bluetooth identity address of the phone 5 that is connected to the device 6.

[0053] In some examples, the public key of the application 8 is one of the phone identifiers included in the activation command. The device 6 may be configured to perform one or more following aspect. For instance, the device 6 may be configured to receive the application’s signature over a one-time challenge from the device 6 or a pairing transcript. The device 6 may be configured to verify the signature of the application 8 (application’s signature) usingthe public key of the application 8 extracted from the activation command. The device 6 may reject the activation command and disconnect if the verification fails. If the activation succeeds, the device 6 may store the phone identifiers of the phone 5 upon successful activation.

[0054] To elaborate further on the use of asymmetric cryptographic keys in connection with a device identifier (such as the phone identifier(s)) discussed above, in various instances, a device identifier such as a phone identifier may be a public key of a public-private key pair. For instance, the device identifier may be a second public key corresponding to a second private key of a second public-private key pair. The device identifier (that the server 10 certifies) can be a second public key corresponding to a second private key generated inside a secure element of the phone 5. This key pair associated with the phone 5 may be different than any key pair associated with the server 10. The device 6 may take actions to verify that a present smartphone 5 attempting to activate the device 6 is a same smartphone as a smartphone that has been previously associated with a verified user 4. For instance, the device 6 may verify a second signature (such as may be applied to a token) and may perform this verification using the second public key.

[0055] Thus, the device identifier may comprise a second public key corresponding to a second private key of a second public-private key pair, wherein the second public-private key pair is generated by the phone 5 and wherein the second private key is in a secure element of the phone 5. The phone 5 may sign a token with the second private key and may provide the signed token to the device 6. The device 6 may utilize the second public key that is the device identifier to verify the authenticity of the token as being signed by the second private key. In various embodiments, a processor 60 of the device may activate the device 6 and may permit control of the device 6 by the phone 5 in response to the verifying of the authenticity.

[0056] In various embodiments, revocation lists may be used during one or both of user verification of the user 4 and device activation of the device 6. For instance, the server 10 may maintain a revocation list (blacklist). The server 10 may maintain multiple revocation lists. For instance, the server 10 may maintain revocation list(s) of user identifiers. The server 10 may maintain revocation list(s) of phone identifiers. The server 10 may reject a user verification request and / or a device activation request if any of the user identifier(s) or phone identified s) in the request are found in the revocation lists.

[0057] Phone identifiers may also be used to ameliorate potential abuse after device activation of a device 6. In various instances, the application 8 on the phone 5 maintains a connection with a device 6 that has been activated while the device 6 is in proximity to a phone 5 of the user 4. The application 8 may support background mode operation and maintain the connection with the device 6 while the application 8 is in the background on the phone 5. Furthermore, the application 8 may be configured so that if the application 8 is suspended by the operating system of the phone 5, the application 8 is restored to memory (e.g., returned to non-suspended status by the operating system of the phone 5) upon wireless detection of the device 6 in proximity to the phone 5 having the application 8. In various embodiments, the application 8 may be configured so that if the application 8 is suspended by the operating system of the phone 5, the application 8 is restored to memory (e.g., returned to non-suspended status by the operating system of the phone 5) upon expiry of a local timer or upon receiving a remote notification from the server 10. In various instances, the application 8 may be configured so that the application 8 restores the Bluetooth connection of the phone 5 having the application 8 to the device 6 upon the device 6 being found in proximity to the phone 5 following a disconnecting of the phone 5 and the device 6. In various instances, the device 6 continues to function for a pre-defined duration (e.g., “grace period”) following disconnecting of the device 6 from the phone 5 having the application 8. Following expiry ofthe pre-defined duration, the device 6 may shut off until the device 6 is connected again to the application 8 of the phone 5. In further instances, a connection between the device 6 and the application 8 of the phone 5 may be established, and afterward the device 6 may whitelist the Bluetooth address of the phone 5 while blocking connection attempts from any different address.

[0058] In further scenarios of using a phone identifier to ameliorate potential abuse, a public key of the application 8 is the phone identifier. Upon a Bluetooth reconnection of the device 6 that has previously been connected to and activated with the phone 5, the device 6 performs various functions. For instance, the device 6 may receive the application signature of the application 8 over a one-time challenge from the device 6 or a pairing transcript. The device 6 may verify the application signature of the application 8 using a public key of the application 8 stored in the device 6. The device 6 may disconnect from the phone 5 having the application 8 upon a failing of the verification.

[0059] In some instances, the application 8 and the device 6 enhance the integrity of the communication to ameliorate potential abuse by using one or more authentication or encryption methods. For instance, the application 8 and the device 6 may derive an Elliptic- Curve-Diffie-Hellman (ECDH) shared secret to authenticate and / or encrypt communication between the device 6 and the application 8. In various instances, the application 8 and the device 6 may derive one or more session keys from a shared secret to authenticate and / or encrypt communication between the device 6 and the application 8. Various other authentication and / or encryption mechanisms may be used.

[0060] Furthermore, the application 8 and the device 6 may enhance the integrity of the communication by other mechanisms. For instance, the application 8 may send periodic status messages to the device 6 to ensure that the connection between the device 6 and the application 8 is still active. The periodic status messages may be digitally signed by theprivate key of the application 8 on the phone 5. The periodic status messages may be authenticated. For instance, the periodic status messages may be authenticated using the aforementioned shared secret. In instances having a session key, the periodic status messages may be authenticated using the aforementioned session key. In various embodiments, the periodic status messages may be associated with disconnecting the device 6 from the phone 5. For instance, the device 6 may disconnect from the phone 5 having the application 8 in response to the device 6 not receiving any periodic status messages within a predefined duration.

[0061] The application 8 may also operate to ameliorate potential abuse via a limit on a number of concurrent devices 6 that can be activated and / or that can maintain concurrent Bluetooth connections with the phone 5 having the application 8. For instance, the application 8 may be configured to activate multiple devices 6 and maintain concurrent Bluetooth connections with such devices 6 up to a limit on the number of concurrent active devices 6. When the limit is reached, the application 8 may ask the user 4 to deactivate one of the existing devices 6 before activating a new device 6. In various embodiments, the server 10 may be configured to use phone identifiers as introduced herein to limit a number of concurrent logins on multiple phones 5 attributed to a same user identifier of a user 4. When a maximum number of allowed concurrent logins is reached, the server 10 may be configured to request that the user 4 logout of an existing phone 5 before allowing a login on a new phone 5.

[0062] Finally, various geofencing features are contemplated. For example, the server 10 may store a database of geolocations where using the device 6 is forbidden. The application 8 on the phone 5 may periodically collect location information and send it to the server 10. The server 10 may verify the location sent by the application 8 against a database of geolocations where using the device 6 is forbidden. The server 10 may inform the application 8 on thephone 5 whether the usage of the device 6 is allowed in the location sent by the application 8. In response to the server 10 indicating that device usage is not allowed in the location sent by the application 8, the application 8 shuts off the device 6. If the server 10 indicates that device usage is allowed in the location sent by the application 8, the application 8 unlocks the device 6.

[0063] Thus, having discussed various aspects of the disclosure, reference to specific embodiments is useful. For instance, in various embodiments, a system 2 is provided for access control to an access controlled regulated device 6, the system 2 may include the access-controlled embedded device 6 comprising a processor 60, a transceiver 64 connectable to a smartphone 5, and a memory 62. The system 2 may include an application 8 running on a smartphone 5, the application 8 connectable to the processor 60 via the transceiver 64, wherein the access-controlled embedded device 6 connects to the smartphone 5 to retrieve a unique device identifier from the smartphone 5. The system 2 may include a verification server 10 configured to store a private signing key. The application 8 may be connectable via the smartphone 5 to the verification server 10. The verification server 10 may sign with the private signing key a payload including a unique device identifier of the smartphone 5 to generate a signed payload and may send the signed payload to the access-controlled embedded device 6 via the application 8 running on the smartphone 5. The access-controlled embedded device 6 authorizes operation of the access-controlled embedded device 6 in response to a checking by the access-controlled embedded device 6 of a correspondence of the unique device identifier from the signed payload and the unique device identifier from the smartphone 5.

[0064] In various instances, the checking the correspondence includes determining that the unique device identifiers are identical. In various embodiments, the checking the correspondence includes determining that the unique device identifiers are identical andcomparing the signed payload signed by the private signing key to a verification key stored in the memory 62 of the access-controlled embedded device 6 to confirm that the signed payload is from the verification server 10 and has not been modified.

[0065] The signed payload may also include data corresponding to a verified age of the user 4 exceeding a threshold, wherein the access-controlled embedded device 6 authorizes operation of the access-controlled embedded device 6 further in response to a checking by the access-controlled embedded device 6 that the verified age exceeds the threshold, and wherein the access-controlled embedded device 6 comprises an electronic nicotine delivery system (ENDS). The application 8 running on the smartphone 5 may access geolocation data corresponding to a location of the smartphone 5 and may selectively deactivate the access- controlled embedded device 6 in response to the smartphone 5 being in a location that use of the access-controlled embedded device 6 is forbidden.

[0066] The application 8 running on the smartphone 5 may periodically connect to the processor 60 via the transceiver 64 at a first interval and the processor 60 of the access- controlled embedded device 6 may deactivate the access-control embedded device 6 in response to a period of time corresponding to the first interval passing without a connecting of the application 8 to the processor 60 occurring via the transceiver 64. In various instances, the application 8 is a browser-based application.

[0067] An access-controlled embedded device 6 may be provided. The device 6 may include a processor 60 and a transceiver 64 connectable to a smartphone 5. The processor 60 may connect to an application 8 on a smartphone 5 via the transceiver 64. The processor 60 may selectively activate the access-controlled embedded device 6 in response to a determination that a device identifier of the smartphone 5 that is received by the transceiver 64 corresponds to a device identifier of the smartphone 5 contained in a payload from a verification server10.

[0068] In various embodiments, the payload is a cryptographically signed payload. The cryptographically signed payload may be signed by the verification server 10 in electronic communication with the smartphone 5. The access-controlled embedded device 6 may include a memory 62 to store a verification key. The signed payload may be signed by a private signing key of which the verification key is a paired public key. The device identifier of the smartphone 5 may include a unique identifier of a component of the smartphone 5 connectable to the transceiver 64. The component may be a Bluetooth radio transceiver 64 and the device identifier may be a hardware address of the Bluetooth radio transceiver 64. The access-controlled embedded device 6 may be an electronic nicotine delivery system (ENDS).

[0069] In various embodiments, the processor 60 deactivates the access-controlled embedded device 6 in response to a location determination corresponding a location that use of the access-controlled embedded device 6 is forbidden. The location determination may be performed by a smartphone 5 connected to the processor 60 via the transceiver 64.

[0070] The processor 60 periodically connects to the smartphone 5 via the transceiver 64 at a first interval and wherein the processor 60 of the access-controlled embedded device 6 deactivates the access-controlled embedded device 6 in response to a period of time corresponding to the first interval passing without a connecting of the application 8 to the processor 60 occurring via the transceiver 64.

[0071] In various instances, the verification server 10 assigns a unique user identifier to a user 4 corresponding to a prior verification of an authorization of the user 4 to use the access- controlled embedded device 6 and wherein the server 10 retrieves one or more unique identifiers of the smartphone 5 and attributes the one or more unique identifiers of the smartphone 5 to the unique user identifier, wherein the signed payload further includes the unique user identifier, and wherein the processor 60 further selectively activates the access-controlled embedded device 6 in response to a determination that the signed payload having the unique user identifier is unaltered.

[0072] Having introduced various operative scenarios and embodiments, attention is directed to FIG. 2, in addition to ongoing reference to elements illustrated in FIGs. 1A-1B, for a detailed discussion of one example embodiment of user verification. As mentioned, user verification may include collecting one or more unique identifier(s) of the user’s phone 5.

[0073] A method of user verification 200 may include a user 4 signing up, meaning creating identification credentials (User ID) such as a user name, password, or the like (block 202). The user 4 may sign up by creating these credentials on an interface of an application 8 on a phone 5. The application 8 may then communicate with a server 10 to create a new account (block 204). The server 10 may assign a unique identifier to the user 4. The server 10 may create an authentication token such as a first Jason Web Token (JWT 1). The JWT 1 may include the user ID. The server 10 may sign JWT 1. The server 10 may provide the first Jason Web Token (JWT 1) to the application 8 (block 208). The application 8 may then scan, for a connectable device 6, such as via Bluetooth of a phone 5; the application 8 may connect to the device 6; and the application 8 may bond to the device 6 to facilitate connection persistence and reconnection (block 210). The device 6 is configured to send the Bluetooth identity address of the phone 5 to the application 8 (block 212). The application 8, in cooperation with other aspects of the phone 5, may then create hardware-backed key pair and retrieve key certificates (block 214). The application 8 may provide a public key, certificates, Bluetooth identity address of the phone 5, JWT 1, and / or other data to the server 10 (block 218). The server 10 may verify the certificates, create a second Jason Web Token (JWT 2) which may include phone identified s) and sign the second Jason Web Token (JWT 2) (block 218). The server 10 may provide JWT 2 to the application 8 on the phone 5 (block 220). Theapplication 8 may then indicate to the user 4 via a human-readable visual, auditory, or tactile display, that the signing up was successful (block 222).

[0074] Turning now to FIG. 3, and with periodic reference to aspects of FIGs. 1A-1B, if the verification process is completed successfully and the embedded device 6 is to be activated, the system 2 verifies that the phone 5 being used to activate the device 6 is the same phone 5 on which the user verification process took place. An example process is illustrated in FIG. 3. FIG 3 illustrates a method of verifying an identity of an activating phone (method 300), confirming that the phone 5 is a same phone 5 as that used for the user verification of FIG. 2. In various embodiments, the method 300 includes a user 4 interacting with an application 8 on a phone 5 to complete a user verification process (block 302). The application 8 may provide the user verification information and JWT 2 to the server 10 (block 304). The server 10 may update the JWT 2 if the user 4 is verified and sign a third Jason Web Token (JWT 3) (block 306). The server 10 may provide the JWT 3 and / or a certificate to the application 8 on the phone 5 (block 308). The application 8 may provide the JWT 3 to the user 4 (block 310), and the user 4 may activate device 6 by communication with the application 8 (block 312). The application 8 may interoperate with the device 6 to provide a device challenge (block 316) and the device 6 may return a device ID and the device challenge (block 316). The application 8 may provide an activation request including the device ID and the device challenge and the JWT 3 to the server 10 (block 318). The server 10 may verify the JWT 3 (block 320) and may transmit a signed activation command to the application 8 (block 322). The application 8 may transmit the signed activation command to the device 6 (block 324), which verifies the command and the phone identifiers (block 326) of the phone 5 having the application 8 and that the device 6 is in communication with. Upon a successful verification, the device 6 provides a notification of success (block 328) to the application 8 which thenindicates to the user 4 via a human-readable visual, auditory, or tactile display that the device 6 was successfully activated (block 330).

[0075] Stated differently, and with reference to FIGs. 1A-B and FIG. 4, a method of activating an embedded device 6 by a user 4 may include one or more aspects from among the preceding discussion. Specifically, the method 400 of activating the embedded device 6 by the user 2 may include sending, by an application 8 on a smartphone 5, an activation request to a server 10 (block 402). The activation request may include an authentication token of the application 8 and a unique identifier of the embedded device 6 to be activated, and a one-time random challenge generated by the device 6. The method may include receiving, by the server 10, the activation request (block 404). The method may include verifying, by the server 10, a validity of the authentication token of the application 8 (block 406). The method may include verifying, by the server 10, that the user 4 has previously been added as an authorized user to a database accessible by the server 10 (block 408). The method may include extracting, by the server 10, the unique identifier (and optionally, the one-time random challenge) from the activation request (block 410). The method may include digitally signing, by a private key of the server 10, an activation command (block 412). The activation command may include (i) a unique identifier of the smartphone 5, (ii) the device identifier, and (iii) the one-time random challenge. The method may include sending, by the server 10, the activation command to the device 6 through the application 8 (block 414).

[0076] In various embodiments, the device 6 receives the activation command and, in response to receiving the activation command, the device 6 performs a verification (block 416), the verification including verifying: (i) the digital signing by the private key of the server using a stored verification key of the server, (ii) that the device identifier is correct, and (iii) that the one-time challenge is correct. Finally, the device may activate in response to the performing the verification (block 418).

[0077] With reference to FIGs. 1A-B and FIG. 5, a method 500 of granting access to an access-controlled regulated device (embedded device 6) is provided. The method may include signing, by a verification server (server 10), a payload (e.g., a data structure, data byte, or collection of data bytes) comprising a unique device identifier of a smartphone 5 to generate a signed payload (block 502). The method may include sending the signed payload to the access-controlled regulated device (embedded device 6) via an application 8 running on the smartphone 5 (block 504). The method may include authorizing, by the access-controlled embedded device (embedded device 6), operation of the access-controlled embedded device (embedded device 6) in response to a checking by the access-controlled embedded device (embedded device 6) of a correspondence of the unique device identifier from the signed payload to the unique device identifier from the smartphone 5 (block 506).

[0078] The present disclosure has been described with reference to various embodiments. However, one of ordinary skill in the art appreciates that various modifications and changes can be made without departing from the scope of the present disclosure. For example, features of different embodiments may be combined. Accordingly, the specification is to be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of the present disclosure.

[0079] For the sake of brevity, conventional techniques for manufacturing and construction may not be described in detail herein. Furthermore, the connecting lines shown in various figures contained herein are intended to represent exemplary functional relationships and / or physical couplings between various elements. It should be noted that many alternative or additional functional relationships or physical connections may be present in a practical method of construction. As used herein, mechanical communication means any joint, connection, bond, or arrangement whereby an article is held, retained, or fixed in relatively static spatial relationship to another article. As used herein, electronic communication meansany wired, wireless, analog, digital, or other mechanism whereby information is communicated between machines, circuits, or devices.

[0080] Benefits, other advantages, and solutions to problems have been described herein with regard to various embodiments. However, the benefits, advantages, solutions to problems, and any elements that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as critical, required, or essential features or elements of the invention. Moreover, where a phrase similar to “at least one of A, B, and C” or “at least one of A, B, or C” is used in the claims or specification, it is intended that the phrase be interpreted to mean that A alone may be present in an embodiment, B alone may be present in an embodiment, C alone may be present in an embodiment, or that any combination of the elements A, B and C may be present in a single embodiment; for example, A and B, A and C, B and C, or A and B and C.

[0081] As used herein, the singular forms “a,” “an,” and “the” include plural referents unless the context clearly dictates otherwise. As used herein, the terms “for example,” “for instance,” “such as,” or “including” are meant to introduce examples that further clarify more general subject matter. Unless otherwise specified, these examples are embodiments of the present disclosure, and are not meant to be limiting in any fashion.

[0082] Furthermore, no element, component, or method step in the present disclosure is intended to be dedicated to the public regardless of whether the element, component, or method step is explicitly recited in the claims. No claim element herein is to be construed under the provisions of 35 U.S.C. 112(f) unless the element is expressly recited using the phrase “means for.” As used herein, the terms “comprises,” “comprising,” or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only thoseelements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus.

Claims

WHAT IS CLAIMED IS:

1. A system for access control to an access controlled regulated device, the system comprising: the access-controlled embedded device comprising a processor, a transceiver connectable to a smartphone, and a memory; an application running on a smartphone, the application connectable to the processor via the transceiver, wherein the access-controlled embedded device connects to the smartphone to retrieve a unique device identifier from the smartphone; a verification server configured to store a private signing key, wherein the application is connectable via the smartphone to the verification server, wherein the verification server signs with the private signing key a payload comprising a unique device identifier of the smartphone to generate a signed payload and sends the signed payload to the access-controlled embedded device via the application running on the smartphone, and wherein the access-controlled embedded device authorizes operation of the access- controlled embedded device in response to a checking by the access-controlled embedded device of a correspondence of the unique device identifier from the signed payload and the unique device identifier from the smartphone.

2. The system according to claim 1, wherein the unique identifier comprises a further public key corresponding to a further private key of a further public-private key pair, wherein the further public-private key pair is generated by the smartphone, wherein the second private key is in a secure element of the smartphone,wherein the phone signs a token with the second private key and provides the signed token to the device, wherein the device uses the signed token and the further public key that is the device identifier to verify the authenticity of the token as being signed by the second private key, and wherein the verifying the authenticity confirms that the smartphone is a same smartphone that has been previously controlled by a verified user.

3. The system according to claim 1, wherein the checking the correspondence comprises determining that the unique device identifiers are identical.

4. The system according to claim 1, wherein the checking the correspondence comprises determining that the unique device identifiers are identical and comparing the signed payload signed by the private signing key to a verification key stored in the memory of the access- controlled embedded device to confirm that the signed payload is from the verification server and has not been modified.

5. The system according to claim 1, wherein the signed payload also includes data corresponding to a verified age of the user exceeding a threshold, wherein the access- controlled embedded device authorizes operation of the access-controlled embedded device further in response to a checking by the access-controlled embedded device that the verified age exceeds the threshold, and wherein the access-controlled embedded device comprises an electronic nicotine delivery system (ENDS).

6. The system according to claim 1, wherein the application running on the smartphone accesses geolocation data corresponding to a location of the smartphone and selectively deactivates the access-controlled embedded device in response to the smartphone being in a location that use of the access-controlled embedded device is forbidden.

7. The system according to claim 1, wherein the application running on the smartphone periodically connects to the processor via the transceiver at a first interval and wherein the processor of the access-controlled embedded device deactivates the access-control embedded device in response to a period of time corresponding to the first interval passing without a connecting of the application to the processor occurring via the transceiver.

8. An access-controlled embedded device comprising: a processor, and a transceiver connectable to a smartphone, wherein the processor connects to an application on a smartphone via the transceiver; wherein the processor selectively activates the access-controlled embedded device in response to a determination that a device identifier of the smartphone that is received by the transceiver corresponds to a device identifier of the smartphone contained in a payload from a verification server.

9. The access-controlled embedded device according to claim 8, wherein the payload is a cryptographically signed payload.

10. The access-controlled embedded device according to claim 9, wherein the cryptographically signed payload is signed by the verification server in electronic communication with the smartphone.

11. The access-controlled embedded device according to claim 9, further comprising a memory to store a verification key and wherein the signed payload is signed by a private signing key of which the verification key is a paired public key.

12. The access-controlled embedded device according to claim 8, wherein the device identifier of the smartphone comprises a unique identifier of a component of the smartphone connectable to the transceiver.

13. The access-controlled embedded device according to claim 12, wherein the component is a Bluetooth radio transceiver and the device identifier is a hardware address of the Bluetooth radio transceiver.

14. The access-controlled embedded device according to claim 8, wherein the access- controlled embedded device comprises an electronic nicotine delivery system (ENDS).

15. The access controlled embedded device according to claim 8, wherein the processor deactivates the access-controlled embedded device in response to a location determination corresponding a location that use of the access-controlled embedded device is forbidden.

16. The access-controlled embedded device according to claim 15, wherein the location determination is performed by a smartphone connected to the processor via the transceiver.

17. The access-controlled embedded device according to claim 8, wherein the processor periodically connects to the smartphone via the transceiver at a first interval and wherein the processor of the access-controlled embedded device deactivates the access-controlled embedded device in response to a period of time corresponding to the first interval passing without a connecting of the application to the processor occurring via the transceiver.

18. The access-controlled embedded device according to claim 8, wherein the verification server assigns a unique user identifier to a user corresponding to a prior verification of an authorization of the user to use the access-controlled embedded device and wherein the server retrieves one or more unique identifiers of the smartphone and attributes the one or more unique identifiers of the smartphone to the unique user identifier, wherein the signed payload further includes the unique user identifier, and wherein the processor further selectively activates the access-controlled embedded device in response to a determination that the signed payload having the unique user identifier is unaltered.

19. A method of activating an embedded device by a user, the method comprising: receiving, by a server and from an application on a smartphone, an activation request, wherein the activation request includes an authentication token of the application, and a unique identifier of the embedded device to be activated, and a one-time random challenge generated by the device; verifying, by the server, a validity of the authentication token of the application; verifying, by the server, that the user has previously been added as an authorized user to a database accessible by the server;extracting, by the server, the unique identifier and the one-time random challenge from the activation request; digitally signing, by a private key of the server, an activation command that includes(i) a unique identifier of the smartphone, (ii) the device identifier, and (iii) the one-time random challenge, and sending, by the server the activation command to the device through the application.

20. The method of claim 19, wherein the device receives the activation command and, in response to receiving the activation command, the device verifies:(i) the digital signing by the private key of the server using a stored verification key of the server,(ii) that the device identifier is correct,(iii) that the one-time challenge is correct, and wherein the device activates in response to the verifying.

Images