Patent ID: 12200131

DETAILED DESCRIPTION

A process for a system100to authorize a physical action according to some embodiments is illustrated inFIG.1. Some embodiments may include the following steps:

1. A wearable device110is provided to the user and is assigned a hardware presence indicator. In some cases, the presence indicator includes data such as a token (e.g. digitally signed data, encrypted data, or the like). The presence indicator may be stored electronically in the wearable device in a secure element, a memory, or the like; may be stored physically on the wearable device in a QR code, bar code, or the like; and the like.

2. It is contemplated that when the wearable device110is first provisioned, initialized, or the like for an authorized user, the wearable device110may capture one or more samples of biometric data of the authorized user. Based upon these samples, the wearable device110may process the biometric data to build a model (using machine learning, a computation, a hash, or the like) of the authorized user's biometric data. The biometric model may be stored in a secure memory (e.g. secure element), and/or encrypted then stored in a more conventional memory, or the like. In other embodiments, the biometric model, hash of the biometric model, a digitally signed biometric model, or the like may be transferred to a local computing device, and/or transferred to a cloud-based authentication service104, or the like for storage.

In various embodiments, subsequently or at a later time:

3. In some embodiments, the wearer of the wearable device110comes in physical contact with the access control device105. For example, the wearer attempts to interact with an access control device106embodied as a control panel; the wearer attempts to use an access control device106; or the like. In some cases, the access control device106may communicate with the wearable device110via short-range communication, such as UWB, Bluetooth, BLE, NFC or the like. In various embodiments, the access control device106may use the short-range transceiver to determine the presence of the wearable device110, and in other embodiments to initiate the authorization process described below. In some cases the access control device106may initiate contact, and in other cases, the wearable device110may initiate contact.

4. In various embodiments, the wearer desires the access control device106to perform an action, but is required by the access control device110to prove the wearer is authorized before performing the action. As examples, the wearer wants to login into the access control device106, the wearer wants to perform a financial transaction (e.g. perform a trade) via the access control device106, the wearer wants to login into a service via the access control device106, the wearer wants to enter a controlled access106area via a control access point (e.g. security door, security gate, etc.), the wearer wants to run a software program upon the computer system106, the wearer wants to have network access from the access control device106, or the like.

In response, the access control device106may expect the wearable device110to return an indication of a biometric match between the wearer of the wearable device110and an authorized user of the wearable device (along with a hardware presence indicator, discussed below). In some embodiments, the access control device106expects the wearable device110to provide an authorization token, authorization data, or the like, as proof of a biometric match.

5. In some embodiments, a user of a wearable device110provides incoming wearer biometric data to the wearable device110. The wearer biometric data may include a fingerprint, a spoken message, an iris scan, a blood vessel scan, movement data, gesture data or the like. In some embodiments, the wearable device110may include a sensor that detects whether the wearer of the wearable device wears or removes the device from their person (e.g. finger, wrist, head, earlobe, etc.). For example, a smart ring embodiments may include a fingerprint scanner and a capacitive sensor, and the wearer scans their fingerprint and the capacitive sensor determines that the wearer has put the ring on. In such cases, the scanned fingerprint may be valid biometric data of the wearer, until the capacitive sensor determines that the ring has been taken off.

6. In some embodiments, the wearable device110may process the incoming wearer biometric data (e.g. perform a hash, perform a digital signature, or the like) and then compare the incoming wearer biometric data to the authorized user biometric model (hash, or the like). In some cases, a processor of the wearable device110may perform the comparison, digital signature analysis, or the like. In other cases, a secure element may receive the incoming wearer biometric data, perform any processing necessary (e.g. hash, digital signature, etc.) and then perform the comparison to the authorized user biometric data. In these cases, the secure element, or the like may return a match or no match result to the processor of the wearable device.

In other embodiments, the authentication process may not occur on the wearable device110, instead, the matching process may be performed on an access control device coupled to the wearable device (e.g. paired smart phone), in a cloud-based authentication server104, or the like. In some examples of this, the wearer biometric data may be first processed by in the wearable device110, e.g. hash, public key encryption, or the like, to protect the wearer's biometric data. Next, the processed wearer's biometric data (e.g. hash) may be transferred via short-range communications, e.g. NFC, WIFI, BLE, or the like, to a coupled access control device106. In some cases the coupled access control device106may store an authorized user's biometric data/model ahead of time and can then compare the processed wearer's biometric data to the processed authorized user's biometric model. If there is a biometric match, the wearer is biometrically authorized.

In still other embodiments, to reduce the computation load on the coupled access control device or wearable device110, and to enable use of a more powerful algorithms, the access control device or wearable device110may upload the processed wearer's biometric data to a cloud-based authentication service104. In particular, the processed wearer's biometric data may be transferred108from the access control device or wearable device to the cloud-based authentication service via wide-area network (e.g. WIFI, Ethernet, 4G, 5G, or the like). In some cases the cloud-based authentication service104may store the authorized user's biometric data/model (e.g. hash) ahead of time and can then compare the processed wearer's biometric data to the stored authorized user's biometric model. In such cases, the authentication service104may return a match or no match result112to the access control device104or wearable device110.

7. In some embodiments, if there is a biometric match determined in the wearable device110, the wearable device may provide a digitally signed token114, or the like as output for the coupled access control device. In some examples, a message, such as a unique hardware identifier of the wearable device or a hashed version of the hardware ID, a current time stamp, or the like may be encrypted with a private key associated with the wearable device104. It is contemplated that the access control device106or the cloud-based authentication service104knows the public key associated with the wearable device. This token may be provided114to the access control device106by short-range method, such as UWB, BLE, NFC, and the like, as mentioned above.

8. Upon receipt of the token, the access control device106(or the cloud-based authentication service) may use the known public key of the wearer device to decrypt the token and return the message. If successful, the message can be compared to a variety of parameters. For example, if the message includes a time stamp, the access control device may determine whether the time stamp is fresh or recent, e.g. within the last few minutes. In another example, if the message includes a hardware identifier, the access control device may determine if the hardware identifier (or hashed hardware identifier) is in a list of authorized hardware identifiers, or the like.

In some cases, the authentication processes may not occur on the wearable device110, instead, the matching process may be performed on an access control device104coupled to the wearable device, in a cloud-based authentication server104, or the like. In some examples of this, the wearer biometric data may be first processed by in the wearable device110, e.g. hash, public key encryption, or the like, to protect the wearer's biometric data. Next, the processed wearer's biometric data may be transferred116via short-range transceiver to a coupled access control device106. In some cases the coupled access control device106may store an authorized user's biometric data/model, biometric public key, or the like and then compare the processed wearer's biometric data to the processed authorized user's biometric model, or determine whether the wearer's biometric data falls within the authorized user's biometric model.

In some cases, the access control device106may upload the processed wearer's biometric data116to a cloud-based authentication service104for processing. These embodiments reduce the computation requirement capability of the coupled access control device106, and to enables the access control device106use of a less powerful, lower cost processor (e.g. embedded system, microcontroller, etc.). In particular, the processed wearer's biometric data may be transferred118from the coupled access control device106to the cloud-based authentication service104via wide-area network (e.g. WIFI, Ethernet, 4G, 5G, or the like. In some cases the cloud-based authentication service104may store the authorized user's biometric data/model and then compare the processed wearer's biometric data to the stored authorized user's biometric model. In such cases, the service may return120a biometric match or no biometric match result to the access control device.

9. In addition to matching the wearer's biometric data to the authorized user's biometric model, in various embodiments, the wearable device110must also provide a hardware identifier122to the access control device106(and in some cases the cloud-based authentication server). In some embodiments, the hardware identifier may tangible, such as an optical code (e.g. QR code, bar code, laser-engraved pattern, pattern displayed on a display of the wearable device, or the like). In these cases, the computer system may use an optical scanner (e.g. camera, laser scanner, or the like) to acquire the optical code data. The computer system may then verify if the optical code data is authorized to access the computer system. If the optical code data is authorized and there is a biometric match, the computer system may be accessed by the wearer.

In other embodiments, the hardware identifier may be intangible and be provided electronically. For example, the hardware presence identifier may be based upon a physically unclonable function (PUF) upon a hardware element. In some cases the PUF is used to generate a public private key pair, where the public key is provided ahead of time to the computer system and/or to the cloud-based authentication server104. In some embodiments, if there is a biometric match, the wearable device110may encrypt a biometric match message using the PUF based private key. The computing device104(or cloud-based authentication server) may then decrypt the encrypted message using the PUF public key to recover the biometric match message. In some cases, the message payload may include a time stamp, an identifier associated with the user (e.g. real name, employee ID, account information, a nonce, or the like).

In other cases, the hardware presence identifier need not be PUF based, and the public/private key pair may be assigned during provisioning. For example, when first assigned to a specific user, the public/private key pair may be computed based upon data such as the user's name, user ID, a hardware serial number, or the like. Once computed, the wearable device110may store the private key in a secure memory, while the public key is registered with the cloud-based authentication server104. As the wearable device110is provisioned to be access or to perform actions on a specific computing device (e.g. use and trade on a specific computer), the public key for the wearable device110is downloaded from the cloud-based authentication server104to the specific computing device106.

In still other embodiments, hardware identifiers may be provided by any numerous methods, such as via NFC, via other rf channels (UWB, ZigBee, Wi-Fi, etc.) via vibrations, via infrared or other optical method, and the like.

In some embodiments discussed herein, the wearable device110may identify itself to the access control device via an ephemeral identifier (ID) that is not-permanently associated with the wearable device (e.g. changes every hour, 8 hours, 1 day, 3 days, etc.). The cloud-based authentication service104may maintain an association between the ephemeral IDs and the data (e.g. biometric hash, hardware hash, public keys (e.g. biometric public key, hardware public key, or the like), or the like associated with the authorized wearer the wearable device/the wearable device110. During peer to peer communications, the wearable device110uses the ephemeral ID to identify itself to access control devices106. The access control devices106then provide124the ephemeral IDs to the cloud-based authentication service104to perform the authentication process. These data or public keys may be used by the authentication service104to perform the authentication process, and to notify the access control device106whether the wearable device is authorized or not. In such embodiments, as ephemeral IDs associated with wearable devices110change, the access control device106or multiple access control devices will not be able to track wearable devices over any appreciable time period.

10. In various embodiments, after the access control device/cloud-based authorization104server verifies that wearer of the wearable device has proven the biometric match and has provided the hardware presence identifier, the access control device106may provide access to the user/wearer to assets controlled by the access control device106, as specified by specific policies. More specifically, in some embodiments, the authorization may be provided132to a cloud-based policy server126, based upon identification of the wearer and the wearable device110, that controls access to specific services or assets. In turn, the policy server may communicate with a cloud-based service provider128to authorize the services130to the wearable device upon the access control device.

In some examples, the wearer may operate a peripheral device134such as a vehicle, a keypad, a control, etc.; the wearer may be provided access to specific locations via a security door, a security gate, a turnstile, etc.; the wearer may be provided with a tangible good such as a key-card, key, equipment, etc.; or the like.

In other examples, the wearer may be provided access to services, such as being able to run specific programs on or on a device controlled by the access control device; to obtain computing services such as internet access, access to protected directories, access to software services (e.g. paid), etc.; to perform financial transactions (e.g. stock transfers, money transfers between accounts, purchase goods or services from specific accounts); and the like.

In some embodiments, wearer biometric authentication as well as hardware presence identifiers may be initially required by the computer system106. In additional embodiments, the biometric and hardware authentication may also be required, on-demand, when the wearer is attempting to perform specific actions. In some examples, each time a wearer attempts to perform stock trades, re-authentication is required; each time a wearer attempts to open a file or access a new directory, re-authentication is required; and the like. In various embodiments, the reauthentication may not be readily apparent to the wearer, for example, for a smart ring embodiment, capillary and blood vessel patterns may be scanned without wearer intervention; for smart watch embodiment, heartbeat patterns may be acquired without wearer intervention; and the like. Periodic re-authentication enables relatively seamless access of the wearer to the good or service.

11. In other embodiments, as discussed above, the access control device106may also monitor the wearer use of the wearable device110. In some cases, the access control device106may periodically request the wearable device110to reauthenticate the wearer. For example, every hour, the wearer may have to reenter their biometric data and/or provide the hardware presence indicator.

In some examples, if a smart ring, smart watch, smart glass, or the like determines that the wearer has not taken off the wearable device, the wearable device may provide the results of the last wearer biometric data match without the wearer having to reenter their biometric data.

In some embodiments, if the wearer is not reauthenticated, full access to the assets (e.g. peripheral device or services) may be terminated. For example, access to specific software program/services may be stopped or may be limited (e.g. limiting further use, reducing functionality or services, or the like). In other examples, access to certain physical secure areas may be limited (e.g. security doors will not open), security personnel may be notified of the presence of the not reauthenticated wearer, and the like. In still other examples, a device may have limited functionality, for example a vehicle may enforce a speed limit, an elevator control panel will only provide access to a specified floor (e.g. lobby, security services floor, etc.), and the like.

In other embodiments, access to the peripheral devices134or services may not be terminated, but the wearer access may be monitored/recorded by the access control device for evidentiary purposes. In other embodiments, wearer access to specific services may be directed to a honeypot-type region, or the like.

A more detailed process for a wearable device200to provide authorization data is illustrated inFIG.2. Some embodiments may include initial provisioning of the wearable:

1. In various embodiments, the hardware of the wearable device has one or more electrical components that have characteristic hardware performance202, such as inherent resistance, inherent capacitance, memory performance, and the like that can be measured. These values are typically different from wearable device to wearable device based upon fabrication differences during semiconductor manufacturing, battery fabrication, assembly and the like.

2. In light of these differences in hardware performance, in some embodiments, one or more physical unclonable functions (PUF)204are implemented to determine a seed number, pseudo random number, random number, or the like. Any number of algorithms may be used to determine the seed206based upon hardware performance, e.g. leakage current, capacitance, signal latency, and the like.

3. In various embodiments, the PUF output (e.g. seed) may be used by a processor208to determine a cryptographic key pair (e.g. hardware public key210, hardware private key212). Any number of algorithms may be used to determine the hardware key pair, based upon the PUF output. In other embodiments, symmetric and other types of cryptographic keys may be used.

4. During initial provisioning of the wearable device, the hardware public key210may be output to the cloud-based authentication server, via a smart device (e.g. smart phone) paired to the wearable device (e.g. smart ring) or directly by the wearable device (e.g. smart watch) itself, as discussed above inFIG.1. In response, the cloud-based authentication server104may create an account136for the (authorized) user, if one does not already exist, and store and associate the hardware public key with the user account.

Subsequently, in some embodiments, if an access control device106is provisioned to allow access by the authorized user, the hardware public key of the authorized user may be downloaded into the access control device106. In other embodiments, the access control device106does not receive the hardware public key and relies upon the cloud-based authentication server104to determine if the hardware of the wearable device is authentic.

5. In some embodiments, the hardware private key212may be stored in a secure element (that includes a secure memory, or the like)214within the wearable device. It is contemplated that the hardware public/private key determination may be performed in the factory, before the wearable device is provided to an end user. Advantages to this includes that the wearable device may be coupled via direct electrical connections to the authorization server, or the like. In some cases, the authorization server may directly provide the seed for the hardware public/private key generation, accordingly a direct electrical connection provides secure transfer of the seed. After the wearable device determines the hardware keys, it may also directly transfer the hardware public key back to the authorization server, providing additional security. Additionally, in various embodiments, the wearable device may store the hardware private key in a secure element. This is advantageous as the wearable device does not have to re-compute the cryptographic keys in real-time (costing energy and delay), when the hardware private key212is needed to encrypt payload data. By having the hardware private key (and biometric private key) pre-computed and stored in the secure element, the wearer and hardware authentication process described herein is greatly facilitated.

6. During initial provisioning of the wearable device, the authorized user may provide their biometric data216via a biometric acquisition device218. As mentioned above, this may take the form of a fingerprint, blood vessel pattern, audio input, heartbeat patterns, gestures, or the like. In some embodiments, multiple biometric captures are used to create an authorized user biometric model.

7. The authorized biometric data or model may also be stored in the secure element220(that includes a secure memory, or the like) or in other memory of the wearable device.

8. In some embodiments, the authorized biometric data or model230may also be used by a key generator232to generate an authorized wearer biometric data public222/private key224pair, or other type of cryptographic data.

9. The biometric private key may also be stored in the secure element214(that includes the secure memory, or the like) or other memory of the wearable device.

10. During initial provisioning of the wearable device, in some embodiments, the biometric public key222may be output to the cloud-based authentication server104, via a smart device (e.g. smart phone) paired to the wearable device (e.g. smart ring) or directly by the wearable device (e.g. smart watch) itself. In response, the cloud-based authentication server104may create an account for the (authorized) user, if one does not already exist, and store and associate the biometric public key222with the authorized user account.

Subsequently, in some embodiments, if an access control device is provisioned to allow access by the authorized user, the biometric public key of the authorized user may be downloaded into the access control device. In other embodiments, the access control device does not receive the biometric public key and relies upon the cloud-based authentication server to determine if the hardware of the wearable of the device is authorized.

Subsequently, in various embodiments, the following steps may be taken (referring toFIGS.1and2):

1. In some embodiments, the wearable device110provides identifying information to the cloud-based authentication server104along with an ephemeral ID (non-permanent)138/238.

2. The access control device106advertises its presence to the wearable device110(e.g. BLE advertisement signals, or the like).

3. The wearable device110provides the ephemeral ID140signal to the access control device106.

4. A wearer of the wearable device110may enter their biometric data216to the wearable device200. As discussed above, this may be a deliberate action, (e.g. swiping their fingertip across a sensor, making a gesture, etc.), or a passive action, e.g. wearing the device and having the device sense biometric data (e.g. heartbeat pattern, a blood vessel pattern, or the like).

5. In these embodiments, the wearer biometric data228may be provided to a secure element214of the wearable device where storage and processing of sensitive data, e.g. authorized user biometric model, biometric private key, hardware private key, and the like is stored.

6. In some embodiments, the incoming user biometric data may be compared by a process234to the authorized wearer biometric data model. Conventional techniques, such as vector matching may be used in some examples to determine a quality of match. If the quality exceeds a threshold, e.g. 80%, 90%, or the like, a match is confirmed.

7. As illustrated inFIG.2, if the biometric match236is confirmed, payload data may be provided, such as the authorized wearer name, account number, wearable device stamp, hardware serial number, or the like. In some embodiments, payload data may be provided244by the computer system that is requesting the authentication.

In such cases, the computer system may provide data such as a computer system time stamp, a serial number, a nonce, or the like. By providing this data to the wearable device reduces the chance that a duplicate or clone wearable device may have pre-programmed outputs, regardless of whether the wearer biometric data is actually captured and authenticated.

8. In the illustrated embodiments, if the biometric match is confirmed, the payload data may be encrypted by a process240using the biometric private key and the hardware private key. This encrypted data242is then output to the access control device and/or the authentication service.

In other embodiments, biometric public/private keys are not needed, and the payload data may be encrypted using the hardware private key. More specifically, the secure element processor, or the like will proceed to encrypt the payload data when there is a biometric match. Accordingly in such embodiments, no biometric data or biometric derived data (e.g. biometric public key, hash of biometric, or the like) leaves the control of the secure element. In other words, the wearable device is primarily responsible for storing biometric data, and verifying or not verifying that the wearer is an authorized user. Additionally, the only cryptographic key output by the wearable device may be the hardware public key, discussed above.

In some examples, upon provisioning the specific wearable device the cloud-based authentication server maintains the hardware public key associated with the specific wearable device. In some embodiments, when a policy server, or the like determines that an authorized wearable of a specific wearable device should be able to control an access control device, the cloud-based authentication server may provide the hardware public key to the access control device. In other embodiments, the hardware public key may be maintained on the authentication server. Accordingly, when a policy server, or the like determines that an authorized wearer of a specific wearable device should be able to control an access control device, the cloud-based authentication server may be configured so that the access control device will contact the authentication service to decrypted and verify the encrypted payload data using the hardware public key. Upon successful verification of the payload data, the access control device may receive a token or other message from the cloud-based authentication server.

In other embodiments, no hardware private key is used, and the hardware serial number may be provided as part of the payload data. Subsequently, the hardware serial number is compared to a list of wearable devices stored in the cloud-based authentication server and provisioned for access in the computer system.

In still other embodiments, the hardware serial number may be provided to the access control device via NFC tag, via optical code (e.g. QR code, etc.).

9. As discussed above, the access control device106may decrypt the encrypted data using the public biometric key and public hardware key to recover the payload, and then determine if the payload is authentic. In some examples, the payload may be an identifier of the computer system, a nonce provided by the computer system, or the like.

In other embodiments, the access control device does not store the public biometric key or hardware public key. Instead, the encrypted data, the payload data, and the ephemeral ID are provided from the access control device to the cloud-based authentication server. In turn, the authentication server determines the hardware public key and/or biometric public key using the ephemeral ID, and decrypts the encrypted message. If recovered payload data matches the provided payload data, the authentication service may provide a token (encrypted with a private key of the authentication server) or other authorization message back to the access control device. If the access control device verifies the validity of the token (e.g. decrypts with a public key of the authentication server), the access control device may authorize the action or service to the wearer of the wearable device.

FIG.3illustrates a functional block diagram of various embodiments of the present invention. More specifically, it is contemplated that from user smart devices to cloud-based servers may be implemented with a subset or superset of the below illustrated components. InFIG.3, a computing device300typically includes an applications processor302, memory304, a display306, an image acquisition device310, audio input/output devices312, and the like. Additional communications from and to computing device300can be provided by via a wired interface314(e.g. dock, plug, controller interface to peripheral devices); a GPS/Wi-Fi/Bluetooth interface/UWB316; RF interfaces318and driver320, and the like. Also included in some embodiments are physical sensors322(e.g. (MEMS-based) accelerometers, gyros, magnetometers, pressure sensors, temperature sensors, bioimaging sensors etc.).

In various embodiments, computing device300may be a hand-held computing device (e.g. Apple iPad, Microsoft Surface, Samsung Galaxy Note, an Android Tablet); a smart phone (e.g. Apple iPhone, Google Pixel, Samsung Galaxy S); a portable computer (e.g. netbook, laptop, convertible), a media player (e.g. Apple iPod); a reading device (e.g. Amazon Kindle); a fitness tracker (e.g. Fitbit, Apple Watch, Garmin or the like); a headset or glasses (e.g. Oculus Rift, HTC Vive, Sony PlaystationVR, Magic Leap, Microsoft HoloLens); a wearable device (e.g. Motiv smart ring, smart headphones); an implanted device (e.g. smart device medical) or the like. Typically, computing device300may include one or more processors302. Such processors302may also be termed application processors, and may include a processor core, a video/graphics core, and other cores. Processors302may include processor from Apple (A12, A13), NVidia (Tegra), Intel (Core), Qualcomm (Snapdragon), Samsung (Exynos), ARM (Cortex), MIPS technology. In some embodiments, processing accelerators may also be included, e.g. an AI accelerator, Google (Tensor processing unit), a GPU, or the like. It is contemplated that other existing and/or later-developed processors may be used in various embodiments of the present invention.

In various embodiments, memory304may include different types of memory (including memory controllers), such as flash memory (e.g. NOR, NAND), SRAM, DDR SDRAM, or the like. Memory304may be fixed within computing device300and may include removable (e.g. SD, SDHC, MMC, MINI SD, MICRO SD, CF, SIM). The above are examples of computer readable tangible media that may be used to store embodiments of the present invention, such as computer-executable software code (e.g. firmware, application programs), security applications, application data, operating system data, databases or the like. Additionally, in some embodiments, a secure device including secure memory and/or a secure processor are provided. The secure device It is contemplated that other existing and/or later-developed memory and memory technology may be used in various embodiments of the present invention.

In various embodiments, display306may be based upon a variety of later-developed or current display technology, including LED or OLED status lights; touch screen technology (e.g. resistive displays, capacitive displays, optical sensor displays, electromagnetic resonance, or the like); and the like. Additionally, display306may include single touch or multiple-touch sensing capability. Any later-developed or conventional output display technology may be used for the output display, such as LED IPS, OLED, Plasma, electronic ink (e.g. electrophoretic, electrowetting, interferometric modulating), or the like. In various embodiments, the resolution of such displays and the resolution of such touch sensors may be set based upon engineering or non-engineering factors (e.g. sales, marketing). In some embodiments, display306may integrated into computing device300or may be separate.

In some embodiments of the present invention, acquisition device310may include one or more sensors, drivers, lenses and the like. The sensors may be visible light, infrared, and/or UV sensitive sensors that are based upon any later-developed or convention sensor technology, such as CMOS, CCD, or the like. In some embodiments of the present invention, image recognition algorithms, image processing algorithms or other software programs for operation upon processor302, to process the image data. For example, such software may pair with enabled hardware to provide functionality such as: facial recognition (e.g. Face ID, head tracking, camera parameter control, or the like); fingerprint capture/analysis; blood vessel capture/analysis; iris scanning capture/analysis; otoacoustic emission (OAE) profiling and matching; and the like. In various embodiments of the present invention, imaging device310may provide user input data in the form of a selfie, biometric data, or the like.

In various embodiments, audio input/output312may include conventional microphone(s)/speakers. In various embodiments, voice processing and/or recognition software may be provided to applications processor302to enable the user to operate computing device300by stating voice commands. In various embodiments of the present invention, audio input312may provide user input data in the form of a spoken word or phrase, or the like, as described above. In some embodiments, audio input/output312may be integrated into computing device300or may be separate.

In various embodiments, wired interface314may be used to provide data or instruction transfers between computing device300and an external source, such as a computer, a remote server, a storage network, another computing device300, a client device, a peripheral device to control, or the like. Embodiments may include any later-developed or conventional physical interface/protocol, such as: USB, micro USB, mini USB, USB-C, Firewire, Apple Lightning connector, Ethernet, POTS, custom dock, or the like. In some embodiments, wired interface314may also provide electrical power, or the like to power source324, or the like. In other embodiments interface314may utilize close physical contact of device300to a dock for transfer of data, magnetic power, heat energy, light energy, laser energy or the like. Additionally, software that enables communications over such networks is typically provided.

In various embodiments, a wireless interface316may also be provided to provide wireless data transfers between computing device300and external sources, such as computers, storage networks, headphones, microphones, cameras, or the like. As illustrated inFIG.3, wireless protocols may include Wi-Fi (e.g. IEEE 802.11 a/b/g/n, WiMAX), Bluetooth, Bluetooth Low Energy (BLE) IR, near field communication (NFC), ZigBee, Ultra-Wide Band (UWB), Wi-Fi, mesh communications, and the like. As described above, data transmissions between computing device300and identity reader1104may occur via UWB, Bluetooth, ZigBee, Wi-Fi, a mesh network, or the like.

GPS receiving capability may also be included in various embodiments of the present invention. As illustrated inFIG.3, GPS functionality is included as part of wireless interface316merely for sake of convenience, although in implementation, such functionality may be performed by circuitry that is distinct from the Wi-Fi circuitry, the Bluetooth circuitry, and the like. In various embodiments of the present invention, GPS receiving hardware may provide user input data in the form of current GPS coordinates, or the like, as described above.

Additional wireless communications may be provided via RF interfaces318and drivers320in various embodiments. In various embodiments, RF interfaces318may support any future-developed or conventional radio frequency communications protocol, such as CDMA-based protocols (e.g. WCDMA), GSM-based protocols, HSUPA-based protocols, G4, G5, or the like. In the embodiments illustrated, driver320is illustrated as being distinct from applications processor302and wireless interface316. However, in some embodiments, various functionality are provided upon a single IC package, for example the Marvel PXA330 processor, and the like. It is contemplated that some embodiments of computing device300need not include the wide area RF functionality provided by RF interface318and driver320.

In various embodiments, any number of future developed, current operating systems, or custom operating systems may be supported, such as iPhone OS (e.g. iOS), Google Android, Linux, Windows, MacOS, or the like. In various embodiments of the present invention, the operating system may be a multi-threaded multi-tasking operating system. Accordingly, inputs and/or outputs from and to display306and inputs/or outputs to physical sensors322may be processed in parallel processing threads. In other embodiments, such events or outputs may be processed serially, or the like. Inputs and outputs from other functional blocks may also be processed in parallel or serially, in other embodiments of the present invention, such as acquisition device310and physical sensors322.

In some embodiments of the present invention, physical sensors322(e.g. MEMS-based) accelerometers, gyros, magnetometers, pressure sensors, temperature sensors, imaging sensors (e.g. blood oxygen, heartbeat, blood vessel, iris data, etc.), thermometer, otoacoustic emission (OAE) testing hardware, and the like may be provided. The data from such sensors may be used to capture data associated with device300, and a user of device300. Such data may include physical motion data, pressure data, orientation data, or the like. Data captured by sensors322may be processed by software running upon processor302to determine characteristics of the user, e.g. gait, gesture performance data, or the like. In some embodiments, sensors322may also include physical output data, e.g. vibrations, pressures, and the like.

In some embodiments, a power supply324may be implemented with a battery (e.g. LiPo), ultracapacitor, or the like, that provides operating electrical power to device300. In various embodiments, any number of power generation techniques may be utilized to supplement or even replace power supply324, such as solar power, liquid metal power generation, thermoelectric engines, rf harvesting (e.g. NFC) or the like.

In some embodiments, PUF hardware components may also be provided, e.g. capacitive devices, resistive devices, memory devices, or the like.

FIG.3is representative of an access control300, a wearable device or an authentication server capable of embodying the present invention. It will be readily apparent to one of ordinary skill in the art that many other hardware and software configurations are suitable for use with the present invention. Embodiments of the present invention may include at least some but need not include all of the functional blocks illustrated inFIG.3. For example, a smart phone (e.g. access control device) configured to perform may of the functions described above includes most if not all of the illustrated functionality. As another example, a wearable device, e.g. a smart ring (electronic devices enclosed in a ring-shaped shell, enclosure, or form factor), may include some of the functional blocks inFIG.3, but it need not include a high-resolution display330or a touch screen, a speaker/microphone360, wired interfaces370, or the like. In still other examples, a cloud-based server or a virtual machine (VM) may not include image acquisition device312, MEMs devices322, GPS capability316, and the like, further components described above may be distributed among multiple computers, virtual machines, or the like.

It is to be understood that the present disclosure is not to be limited to the specific examples illustrated and that modifications and other examples are intended to be included within the scope of the appended claims. Moreover, although the foregoing description and the associated drawings describe examples of the present disclosure in the context of certain illustrative combinations of elements and/or functions, it should be appreciated that different combinations of elements and/or functions may be provided by alternative implementations without departing from the scope of the appended claims. Accordingly, parenthetical reference numerals in the appended claims are presented for illustrative purposes only and are not intended to limit the scope of the claimed subject matter to the specific examples provided in the present disclosure.

Further embodiments can be envisioned to one of ordinary skill in the art after reading this disclosure. For example, in some embodiments, a wearable device may be a ring, a smart watch, a fitness tracker, smart glasses, smart earbuds or earphones, a patch worn on the skin, and the like. Additionally, the computing device interacting with the wearable device may be a smart tablet, a smart phone, a computer, a control access system, and the like. Further, the cloud-based authentication server may provide service for one organization or multiple organizations and may be implemented as virtual machines, and the like. Additionally, different methods for providing or combining biometric match and hardware presence indicators are contemplated. In light of the current patent disclosure, one of ordinary skill in the art will recognize other criteria that can be incorporated into alternative embodiments of the present invention.

In the various embodiments above, to maintain privacy of the wearable device with respect to the access control device, the following techniques may be incorporated. More specifically, to maintain privacy, the wearable device may identify itself with an ephemeral identifier (ID). This ephemeral identifier is non-permanent and temporary, and is unique to the wearable device for a relatively short amount of time, e.g. 1 hour, 8 hours, 1 day, or the like. In some embodiments, for example, a BLE MAC address associated with the wearable device may be used, although other identifiers may also be used. In various embodiments, the cloud-based authentication service may be used to resolve the ephemeral ID to a specific wearable device, and the access control system may not be able to resolve the ephemeral ID without assistance from the cloud-based authentication service.

In operation, the wearable device will periodically (or on demand) communicate with the cloud-based authentication service (facilitated by a paired smart device or directly via wide-area network) and provide the current ephemeral ID and a unique hardware identifier, both currently associated with the wearer and wearable device, and the cloud-based authentication server will maintain that association.

Next, when the wearable device approaches an access control device, the access control device advertises its presence. In some embodiments, in response, the wearable device provides its current ephemeral ID to the access control device, and the access control device may provide some payload data to the wearable device, (via short-range transceiver) in any order. In some examples, the access control device then contacts the cloud-based authentication server and provides the ephemeral ID (e.g. via wide-area network). In response, the authentication server uses the ephemeral ID to determine the specific wearable device currently associated with the ephemeral ID and the associated biometric public key and/or hardware public key, and may return the public key(s) back to the access control device (e.g. via wide-area network). The access control device receives the encrypted data (as discussed above, payload data encrypted with a hardware private key and/or a biometric private key) from the wearable device (via short-range transceiver) and then uses the public key(s) to recover data encrypted data. As discussed above, if the data matches the payload data the access control device previously provided, the wearable device is deemed to be authenticated. The access control device then authorizes the desired access, e.g. directs a peripheral device to perform an action, (e.g. opening of a door), allows directly or in directly (e.g. with use of a policy server), the wearer of the wearable device to use computer resources, to allow a user to perform a stock trade, or the like.

The above embodiments are believed to be very useful for access control systems as they will not store or maintain data that can trace or track wearers or wearable devices. More specifically, throughout the day, it is contemplated that multiple wearable devices will be within the range of the access control device, and the access control devices may attempt to authenticate these wearable devices. Digital traces of each attempt may be stored in one form or another within the access control device, such as communications identity, serial number, hardware ID, or the like of the wearable device; the hardware public keys used to authenticate the wearable devices, and the like. As it is contemplated that the usage of the above techniques will be widespread, such digital traces for each access control device may be used to track wearable devices throughout the day or other time period. Accordingly, hackers, state-actors, or other non-state actors may be motivated to hack access control devices to gain information on specific users, users' accounts, and user transactions. These attacks are detrimental to the access control devices as they may be damaged due to repeated attacks, for example, they may have corrupted or misconfigured data and software, they may have spyware installed, they may be attacked with denial of service attacks, and the like. In the above embodiments, since the access control devices do not necessarily maintain the identity of the authenticated wearers of the wearable devices (but only ephemeral identifiers), it greatly reduces the value of identity data of wearable devices that are stored on these devices. Accordingly, it is believed that access control devices will be subject to fewer harmful and malicious attacks.

In other embodiments, combinations or sub-combinations of the above disclosed invention can be advantageously made. The block diagrams of the architecture and flow charts are grouped for ease of understanding. However, it should be understood that combinations of blocks, additions of new blocks, re-arrangement of blocks, and the like are contemplated in alternative embodiments of the present invention.

The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense. It will, however, be evident that various modifications and changes may be made thereunto without departing from the broader spirit and scope of the invention as set forth in the claims.