Sensor-based identity authentication and security protocol verification

Abstract

A system, apparatus, and method are described herein for sensing both acceptability of a user identity and verification of a security protocol for activity requested by a requesting user. Embodiments include at least: at least one local sensor; a local microprocessor and associated memory capable of training and actuating the local sensor, the local sensor being capable of sensing at least a first characteristic of the user identity and a second characteristic of the security protocol; and a comparator to compare the first characteristic to the first acceptable data profile and to compare the second characteristic to the second acceptable data profile, and to determine whether the first characteristic satisfies the first acceptable data profile and the second characteristic satisfies the second acceptable data profile only if the first characteristic satisfies the first acceptable data profile and the second characteristic satisfies the second acceptable data profile. An acknowledgement of the requested activity is output. The output of the confirmation actuates the requested activity only for the requesting user.

Description

[0001] Cross - Reference to Related Applications

[0002] This application claims priority to U.S. Provisional Application No. 63 / 381,857, filed on November 1, 2022, the content of which is incorporated herein by reference in its entirety. Background Technical Field

[0004] This disclosure relates to user authentication and, more particularly, to apparatuses, systems, and methods related to sensor-based identity authentication and security protocol verification. Background Art

[0005] An individual may request to participate in an activity that may be safe in some circumstances but unsafe in others. Due to many factors, the security of such activities may vary, such as the age or credentials of the requesting user, or because the activity requires peripheral aspects without which the activity is unsafe, such as the need to wear a hard hat, goggles, or other personal or other safety equipment.

[0006] Upon receiving a request to participate in certain activities, personal identification is sometimes used, such as badge scanning. For example, entering a restricted access area or building, or airline passenger identification. Summary of the Invention

[0007] The disclosed embodiments are and include a system, apparatus, and method for sensing both the acceptability of a user identity for a requested activity by a requesting user and the verification of a security protocol. The embodiments at least include: at least one local sensor; a local microprocessor and associated memory capable of training and actuating the local sensor, the local sensor being at least capable of sensing a first characteristic of the user identity and a second characteristic of the security protocol; and a comparator for comparing the first characteristic with a first acceptable data profile and the second characteristic with a second acceptable data profile and for outputting a confirmation of the requested activity only if the first characteristic satisfies the first acceptable data profile and the second characteristic satisfies the second acceptable data profile. Then, the output of the confirmation actuates only the requested activity for the requesting user.

[0008] Thus, the embodiments can sense not only an authorized user but also features that make the environment in which the user requests access safer. These embodiments provide the least cost or no increased cost compared to known identification sensing embodiments. Brief Description of the Drawings

[0009] Exemplary devices, systems, and methods will be described below with reference to the accompanying drawings, which are given by way of non-limiting example only, where like reference numerals may represent like elements, and where:

[0010] Figure 1 Aspects of an embodiment are shown;

[0011] Figure 2 Aspects of an embodiment are shown; and

[0012] Figure 3 Aspects of an embodiment are shown. Detailed Description

[0013] The accompanying drawings and description provided herein may have been simplified to illustrate aspects relevant to a clear understanding of the devices, systems, and methods described herein, and, for clarity, other aspects that may be found in typical, similar devices, systems, and methods have been eliminated. Accordingly, those skilled in the art will recognize that other elements and / or operations may be desirable and / or necessary for implementing the devices, systems, and methods described herein. However, since such elements and operations are known in the art and since they do not facilitate a better understanding of the present disclosure, a discussion of such elements and operations may not be provided herein for the sake of brevity. Nevertheless, the present disclosure is considered to still include all such elements, variations, and modifications of the described aspects that are known to those of ordinary skill in the art.

[0014] Embodiments are provided throughout the specification so that this disclosure is thorough and complete, and fully conveys the scope of the disclosed embodiments to those skilled in the art. Numerous specific details are set forth, such as examples of specific components, devices, and methods, to provide a thorough understanding of the embodiments of the present disclosure. However, it will be apparent to those skilled in the art that some specific disclosed details need not be employed, and that the embodiments may be practiced in different forms. Accordingly, the embodiments should not be construed as limiting the scope of the present disclosure. As noted above, in some embodiments, well-known processes, well-known device structures, and well-known technologies may not be described in detail.

[0015] The terms used herein are for the purpose of describing particular embodiments only and are not intended to be limiting. For example, as used herein, the singular forms "a", "an" and "the" may also be intended to include the plural forms, unless the context clearly indicates otherwise. The terms "comprising", "including", "containing" and "having" are inclusive and thus specify the presence of the stated features, integers, steps, operations, elements and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components and / or groups thereof. Unless specifically identified as the preferred or required order of performance, the steps, processes and operations described herein should not be construed as necessarily requiring them to be performed in the particular order discussed or shown. It should also be understood that additional or alternative steps may be employed in place of or in conjunction with the disclosed aspects.

[0016] When an element or layer is referred to as being "on", "above", "connected to" or "coupled to" another element or layer, it can be directly on, above, connected to or coupled to the other element or layer, or intervening elements or layers may be present, unless otherwise explicitly stated. In contrast, when an element or layer is referred to as being "directly on", "directly above", "directly connected to" or "directly coupled to" another element or layer, intervening elements or layers may not be present. Other words used to describe the relationship between elements should be interpreted in a similar manner (e.g., "between" versus "directly between", "adjacent" versus "directly adjacent", etc.). In addition, as used herein, the term "and / or" includes any and all combinations of one or more of the associated listed items.

[0017] In addition, although the terms first, second, third, etc. may be used herein to describe various elements, components, regions, layers and / or portions, these elements, components, regions, layers and / or portions should not be limited by these terms. These terms are only used to distinguish one element, component, region, layer or portion from another. Terms such as "first", "second" and other numerical terms, when used herein, do not imply an order or sequence unless the context clearly indicates otherwise. Thus, the first element, component, region, layer or portion discussed below may be referred to as the second element, component, region, layer or portion without departing from the teachings of the embodiments.

[0018] The present disclosure relates to processor-implemented modules, systems, and methods that can provide access to and transformation of various types of digital content, including but not limited to video, images, text, audio, metadata, algorithms, identifiers, interactive, and document content, which individually or in combination track, deliver, manipulate, transform, transceive, and report the accessed content to control and execute the processes discussed herein. Embodiments of these modules, systems, and methods processed by a processing system are intended to be exemplary and not limiting.

[0019] In addition, it will be understood that the terms "module" or "engine" as used herein do not limit functionality to a particular physical module, but may include any number of tangibly embodied software and / or hardware components that have the above-described transformative effect on at least a portion of the system. Generally, a computer program product according to an embodiment includes a tangible computer-usable medium (e.g., standard RAM, optical disc, USB drive, etc.) having computer-readable program code embodied therein / thereon, where the computer-readable program code is adapted to be executed by a processor (e.g., working in conjunction with an operating system) to implement one or more of the functions and methods described throughout this document. In this regard, the program code can be implemented in any desired language and can be implemented as machine code, assembly code, byte code, interpretable source code, etc. (e.g., via C, C++, C#, Java, Actionscript, Objective-C, Javascript, CSS, XML, etc.).

[0020] Embodiments of the present invention can sense security features of an authorized user prior to activity approval, such as building or area access - as opposed to a worker visually ensuring that a field equipment operator is wearing a safety helmet or a laboratory technician ensuring that those entering the laboratory are wearing a laboratory coat, goggles, and gloves.

[0021] Embodiments of the present invention can be employed that can sense not only an authorized user but also features that make the environment in which the user requests access safer.

[0022] As a non-limiting example, one or more modules can be provided that, when associated with a microprocessor, process data from a camera and discern content within the field of view of the camera providing the data. Thus, the (one or more) modules can discern the identity of a person within the field of view of the camera and the presence of one or more safety garments worn by the identified person. In other embodiments, the camera can be used in combination with other access restriction or tracking technologies, such as a marker or code reader to capture similar data.

[0023] Embodiments of the present invention may provide sensor-based authentication and sensor-based security protocol verification. These aspects may be provided using any of the following: multi-sensor embodiments, in which multiple different sensors are employed to provide these features; single-sensor embodiments, in which a single sensor provides these features; or a single combined sensor, in which a single sensor provides multiple functions that allow the provision of the two aforementioned features.

[0024] Regarding the sensing performed to provide authentication, it will be understood from the discussion herein that many different types of sensing may be provided. By way of non-limiting example, suitable (one or more) sensors for providing authentication may include cameras, fingerprint readers, barcode readers, QR code readers, card readers (such as those that "see" or otherwise read identification cards or similar scannable cards), profile scanners, biometric scanners (such as eye scanners), NFC tag readers, and the like.

[0025] Similarly, it will be understood that many different types of (one or more) sensing / sensors may be employed to provide the security protocol verification aspect of the disclosed embodiments. Suitable sensors for performing security protocol verification may include, but are not limited to, cameras, air property readers, infrared / temperature sensors, barcode sensors, QR code sensors (e.g., any code scanner capable of reading and identifying tags such as those on a laboratory coat or safety helmet), pressure sensors, weight sensors, biometric scanners, profile scanners, NFC tag readers, and the like.

[0026] Thus, as is apparent from the foregoing listing of different sensor types, there is overlap between the different types of sensors capable of performing any or both of the functions / aspects of the disclosed embodiments. That is, as described above, authentication and security protocol verification may be performed using different sensors to perform the respective functions from each of the foregoing lists in an independent multi-sensor format; in a single combined sensor format, such as where both a camera and a scanner are used; or in a single-sensor multi-functional format, such as in embodiments where a camera is used to perform both authentication and security protocol verification. It goes without saying that in some cases, single-sensor embodiments may be more preferred than multi-sensor embodiments, for example due to: the cost of multiple sensors; the difficulty of packaging multi-sensors, such as based on packaging size; the processing overhead required to process the outputs from multiple sensors, such as in on-site, fat client embodiments; or the communication and protocol overhead required to communicate with multiple sensors in thin client embodiments. In other implementations, multiple sensors may be required in order to support, for example, a combination of magnetic card reading capabilities and heat sensing.

[0027] Thus, the choice of the number of sensors used to provide the listed functionality can be determined by balancing many design factors. These factors can include, but are not limited to, available sensing time, the cost of one or more sensors, the reason for sensing, i.e., the level of risk associated with the activity the user is attempting to engage in, the processing required on-site, the available space on-site for the sensing package, and the like.

[0028] As a non-limiting example, the sensing performed can depend largely on the time, location, and activity the user is attempting to engage in. For example, the sensing can attempt to discern, upon user request, that the requesting user is identified as authorized to gain access / engage in the activity and that the required safety equipment is present to allow for safe engagement in the activity / gaining access. In such an embodiment, the user can first be identified / classified / categorized, and then, by way of example, it can be evaluated whether any one or more of the following are present in association with the user: a hard hat; safety goggles; a lab coat; cleanroom gear; protective boots or gloves; and so on.

[0029] Other embodiments can discern other safety protocol verifications, but can focus more on discerning unauthorized users. For example, an identified user may need but may be lacking proof of performing a particular activity, such as a user attempting to drive or operate a forklift, in which case the user may need a forklift operator's license. In such a case, the proof of user authorization can be specific to one or more users or can be classified as authorized or unauthorized users. That is, the user can "sense" his or her forklift license, and / or the user can sense his or her identity and can compare that identity to a list of authorized forklift operators known to have a forklift operator's license.

[0030] As a further example, with respect to user identification only, a user can request access to a home liquor cabinet. In such a case, any user identified as being over a certain predetermined age (e.g., the legal drinking age in the state where access is requested) can be allowed access to the liquor cabinet, while any user identified as being below that age can be prohibited from accessing the liquor cabinet. Similarly, only users identified as being on an authorized user list (i.e., the homeowner, spouse, and grandparents) can be authorized access to the liquor cabinet, regardless of the age provided by the sensing.

[0031] In addition, there can be a time aspect to the operation of the sensing. For example, a denial of access event can include a temporary exclusion, such as where a certified user is sensed by a breathalyzer safety protocol to have had too much to drink, or where a motor vehicle operator is certified but is temporarily excluded from operating a vehicle because he or she is not wearing the driving glasses required based on a scan of his or her driver's license.

[0032] This temporal aspect may similarly include timing for correcting actions. According to the above example, a forklift operator may be identified as an authorized operator but may also be identified as lacking a safety helmet necessary to perform the requested operation. In such a case, the commandeered forklift may remain "idle" for 10 minutes while waiting for the authorized user to return and put on the safety helmet. The user may or may not be allowed to avoid re-identification upon return, and in cases where there is a higher demand for access or participation in an activity, such an embodiment would be quite important.

[0033] Additionally, it will be understood that in typical embodiments, identity authentication sensing and security protocol verification sensing may be performed at a local level, i.e., generally will be performed geographically at the location where the user attempts to participate in the activity. Of course, this may not always be the case.

[0034] In any case, the processing of the sensed data and thus the decision-making associated with the sensed data may be performed locally or remotely. Additionally, the processing requirements may be distributed between local and remote processing, such as based on the amount of processing required in a particular embodiment. That is, if minimal processing is required, for example where an authorized automotive user is first evaluated and then must pass a breathalyzer test or then must pass a camera sensing test by repeatedly placing a finger on the nose, before the vehicle can be operated, if the amount of processing of the sensed data required is minimal, the processing may be performed on the user's mobile device or by the vehicle's on-board computer. However, if more significant processing is required, such as where specialized pixel analysis is needed to ensure that the user's goggles have a certain amount of thickness or UV protection, the processing may be performed remotely after the sensed data is transmitted from the local site to remote processing.

[0035] Regardless of whether the computation is performed locally, remotely, or distributed between local and remote processing or in a cloud-type environment, one or more local sensors will typically read the data and upload or otherwise transmit the collected data, whether it is magnetic code scanning or pixel data from a camera. User authorization may be evaluated first or later, and the security protocol may be verified first or later, and when the required criteria for both sensing aspects are met, an activity lock or unlock, e.g., granting access, is issued. This is typically performed by one or more conventional computing devices receiving the sensor data to compare a list of authorized users, security verification protocols, and their respective associated data profiles with the received sensor data. For example, Figure 1 and 2 illustrate local data processing and remote data processing embodiments, respectively.

[0036] Figure 1An embodiment of a processing environment 100 is shown, where sensing is performed locally and the sensed data 102 is provided to a local microprocessor 104. The local microprocessor 104 includes local access to data profiles, such as data profiles corresponding to an authenticated (Auth) user 108 and a protocol 106, which are acceptable for user authorization and security protocol verification, respectively. As a non-limiting example, the data profiles may reside in a comparison / relational database resident in the aforementioned memory associated with the microprocessor 104, such as databases 116 and 118.

[0037] These acceptable profiles are fed into one or more comparators, such as comparators 110, 112, and 114, which compare the incoming sensor data 102 with the acceptable data profiles 106 and 108 in accordance with instructions from the microprocessor 104 and issue multiple outputs based on the comparison. The comparator can be hardware or firmware, or preferably can be algorithmic software, and in each case, the comparator is implemented / activated by the microprocessor 104, where the comparator inputs include the sensor data feed and the acceptable data profiles.

[0038] Possible outputs from the comparator include: two "no" for compliance with user authorization and security protocol, one "yes" for compliance with user authorization and one "no" for compliance with security protocol, one "no" for compliance with user authorization and one "yes" for compliance with security protocol, and "yes" for compliance with both user authorization and security protocol verification. Only if both data comparisons provide a "yes" for the compliance result with the acceptable data profiles, can the requested activity be enabled, for example, by an unlock or activation output command 120 from the local microprocessing system 104.

[0039] Of course, there may be a local display or other similar indication at the sensing site associated with Figure 1 system 104. This indication can detail to the requesting user that the requested activity has been confirmed, or if there are not two "yes" for compliance with the two aspects of sensing, the reasons why the requested activity has not been confirmed and actuated.

[0040] Figure 2 An embodiment of a processing environment 200 is shown, which differs from Figure 1 at least in that the local microprocessing system 204 is associated with a communication system 206, which uploads the data to the cloud 210 when the local microprocessing system 204 receives the sensed data 202, for example, via wired or wireless communication 208, such as but not limited to cellular, Wi-Fi, Bluetooth, etc. That is, Figure 2 a "thin client" embodiment is shown.

[0041] When the remote microprocessing system 212 receives the sensed data 202 from the cloud 210, the remote system 212 compares the necessity of conforming to the acceptable data profile for user authorization and security protocol verification, such as the acceptable data profile corresponding to the authenticated user 214 and the protocol 218, and if it is sensed based on the sensor data 202 from the local site that both the authorized user and the security protocol are conformed to, then the activity is enabled again, for example, by issuing an unlock or activation output command 224 to enable the activity. Thus, in both local or remote processing cases, the comparator 222 compares the "streams" of sensor data from the two sensed data outputs with two sets of confirmation data, namely, identity authorization and security protocol compliance. The local or remote comparator may preferably include the software as described above. Although in the above embodiment, where the comparator 222 is hardware or firmware, as an example, the firmware of one or more sensor chip sets may be used to execute the comparator 222.

[0042] The comparison can occur in parallel, that is, the compliance of the sensed data for both identification and security protocol with the acceptable data can be compared simultaneously. Alternatively, the comparison can be serial. In the case of serial comparison, it may be preferred that the identity authorization can occur first, because the lack of user authorization indicates that there is no need to participate in the processing required for security protocol data comparison.

[0043] It is worth noting that regardless of the fat or thin client nature of the processing, that is, whether the processing occurs locally or remotely, the comparator 222 outputs the unlock or activation command 224 only when two data sets are confirmed. This double confirmation can occur only when the two data streams indicate exact data points via the comparison, or can occur when both data sets are within the allowable matching range of the data. As a non-limiting example, regarding user identification, specific matching data may require specifically identifying a certain user; on the other hand, if an allowable matching range is provided, user identification may only require identifying the user as, for example, over 21 years old.

[0044] If both data sets are within the allowable range or meet the required specific data, the requested function can be unlocked, activated, or otherwise allowed to occur via the confirmation output of the data comparison performed by the microprocessor 204. As described throughout, this comparison function can be a hardware function or a software function. Taking non-limiting examples, in any case, the comparison is performed only under the instruction of the microprocessor 204.

[0045] More particularly, the allowable matching range can vary based on any number of factors. For example, the matching range can vary according to the sensor type. Similarly, the matching range can vary according to the requested activity or the activity accessed by the request. As a non-limiting example, a forklift may strictly require that the individual requesting authorization hold a specific certification or permit to operate and wear a hard hat and safety gloves. On the other hand, the opening of a liquor cabinet may require that the identified individual be of a specific age, which may depend on the state in which the liquor cabinet is located, and may additionally require the user to pass a breathalyzer test to ensure that the user is not intoxicated. In this case, the breathalyzer may include a security protocol to be verified. Further regarding the allowable range of data comparison, the breathalyzer test may have a maximum allowable blood alcohol content, which also varies according to the state in which the liquor cabinet is located.

[0046] In addition, meeting two separate comparison data sets, namely user authorization and security protocol compliance, may be interdependent with each other and may result in variability between each other, or may not. For example, the security protocol compliance check may only be sensed after the requesting user has been identified as an authorized user. Similarly, meeting the criteria within a matching range for one data set may cause a change in the data matching threshold required in the other data set. For example, both undergraduate and PhD students in electrical engineering at a particular university may be authorized to enter a laboratory clean room. However, when a PhD requests access, the security protocol compliance may be less strict because it can be assumed that the PhD is aware of a higher level of clean room equipment actually required to enter the facility than an undergraduate student is aware of the safety equipment actually required to enter the clean room.

[0047] Additionally, it may be the case that the embodiments preferably include one or more learning modules in a remote, cloud-based format. These learning modules can learn from data monitoring, such as based on global monitoring of input data sets regarding user identification and security protocol compliance, and from additional input data, such as third-party data regarding accidents, incidents, arrests, or other reports, to modify the manner in which the comparator performs the required data matching for the two data sets. More specifically, when learning occurs, the learning module can modify one or more data matching ranges. For example, the learning module can compare an event report with the category of authorized user identification, and thereby require security protocol compliance to obtain a matching range for the security protocol, which can vary, i.e., become more strict, for the identified user category that has experienced a higher number of negative events.

[0048] As a non-limiting example, Figure 3Shown is a processing environment 300 for a learning module that can modify the matching range of at least one of two datasets either automatically or using a manual permission, and a comparator 308 performs a comparison on the matching range to unlock or activate the requested function. In this illustration, a cloud-based learning module 310 receives a local data stream from one or more sensors, where a user requests permission to unlock or activate the requested function. Also received by the cloud-based learning module 310 are event and incident reports by user category, such as from multiple third-party sources. Notably, the learning module 310 can also receive a large amount of data for such requests, such as data from a geographical area.

[0049] The learning module 310 starts with an initial permissible matching range for user identification and security protocol compliance. This can include, for example, training data. However, when feedback is received based on incoming events and incident reports 324, 326, and 328, the matching range 314 can be modified for user identification or security protocol compliance. Then, the modified matching range can be applied upon a subsequent user request to unlock or activate the requested function.

[0050] As a non-limiting example, the disclosed embodiments can be application (app)-based or can operate based on a simple remote server principle. In an app-based embodiment, a local administrator or app administrator can be enabled to modify, for example, a list of authorized users and / or the security protocols against which compliance is compared. Additionally, as discussed throughout this document, a sensor system can include one or more sensors and can be controlled via an app. Further, an administrator can be enabled to change, for example, via an app, the type of sensing used to obtain a data stream for comparison by the comparator. As an example, this can allow for the replacement of a faulty sensor locally or the elimination of a secondary sensor in a use case where a single sensor can sense both user identification and security protocol compliance.

[0051] In short, various aspects of the disclosed embodiments can be managed, controlled, read, and / or processed by a user application (app), such as one that can reside on a mobile device. Thus, the user app can be used to actuate and / or otherwise "wake up" local sensors to allow for user identification and security protocol compliance sensing. For example, the user app can be used to set up sensors, input information, input parameters, etc. Similarly, the user app can act as a processing for sensors or scanners that can be associated with the mobile device on which the user app resides.

[0052] Thus, a mobile device having a resident user app thereon can act as a gateway for some or all aspects of the disclosed embodiments, such as for both user identification and for security protocol compliance, or for either measure. As a non-limiting example, the user app can then communicate with a locally accessible or actuatable entry point, appliance, or machine. Once the applicant's mobile device confirms that the user read by the mobile device is correctly identified as an authorized user and is in security compliance, the requested activity or functionality can be confirmed by the mobile device as available to the user. In this way, the functionality can be provided locally, such as by NFC tag reading by the mobile device, Bluetooth communication from the mobile device, cellular communication from the mobile device, Wi-Fi communication from the mobile device, and the like.

[0053] It should be understood that various identifications may be performed in the disclosed embodiments to confirm the availability of the requested functionality. As non-limiting examples, such identifications may include: age; license; education; presence of an ID card; presence of a payment card; identification information based on a mobile device; facial recognition; eye print or similar biometric identification; presence of one or more fingerprints; identification of a specific person or class of people; identification of an infrared signature of a person of a certain size; etc.

[0054] Likewise, in embodiments, compliance with various security protocols may be evaluated. As non-limiting examples, such security protocols may include: presence of equipment; presence of specific clothing; presence of specific biometric states; presence of electronic keys; presence of specific environmental conditions; presence in a specific time frame; presence in a specific location; etc.

[0055] The aforementioned identification confirmation and security protocol compliance confirmation can realize various specific functions and usage environments. As non-limiting examples, such usage environments may include: operation of vehicles; operation of heavy equipment, such as forklifts, bulldozers, etc.; operation of motorcycles; operation of aircraft or similar flying equipment; operation of water-based vehicles; accessibility to restricted locations; and availability of restricted access based on predetermined conditions, such as access to chemical cabinets based on education, or access to wine cabinets based on age.

[0056] Accordingly, the present disclosure teaches a system, apparatus, and method for verifying both the acceptability of a user identity for an activity requested by a requesting user and a security protocol. The apparatus, system, and method can at least include: at least one local sensor; a local microprocessor and associated memory capable of training and actuating the local sensor, the local sensor being capable of sensing at least a first characteristic of the user identity and a second characteristic of the security protocol; and a comparator for comparing the first characteristic with a first acceptable data profile and the second characteristic with a second acceptable data profile, and for outputting an affirmation of the requested activity only if the first characteristic satisfies the first acceptable data profile and the second characteristic satisfies the second acceptable data profile. Then, the output of the affirmation can actuate the requested activity for the requesting user individually.

[0057] In certain embodiments of the present invention, a camera can advantageously be used to sense the identity and whether the user is using mandatory personal safety equipment, such as a safety helmet, face mask, or shoe covers. This can be implemented extensively in a computing environment to provide an improved access restriction system without the need for additional sensors. Conventional image recognition methods can be used in conjunction with the data provided by the camera to achieve enhanced access control. Additionally, or alternatively, visually recognizable features (such as barcodes or QR codes) on personal safety equipment (such as safety helmets or laboratory coats) can be used in conjunction with one or more such cameras (such as one or more additional cameras with different fields of view or different operating ranges) to facilitate processing and access control, thereby sensing the user's body temperature. In this case, a separate fever scan of the user can be avoided because access is not approved by the access restriction system unless the sensed user temperature is within one or more acceptable ranges.

[0058] In the above detailed description, for the sake of brevity of the present disclosure, various features may be combined together in various embodiments. This method of the present disclosure should not be construed as reflecting an intention that any subsequently claimed embodiment requires more features than those explicitly recited.

[0059] Furthermore, the present disclosure is provided to enable any person skilled in the art to make or use the disclosed embodiments. Those skilled in the art will readily appreciate various modifications to the present disclosure, and the general principles defined herein can be applied to other variations without departing from the spirit or scope of the present invention. Therefore, the present disclosure is not intended to be limited to the examples and designs described herein, but should be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A system for sensing both the acceptability of a user identity for an activity requested by a requesting user and the verification of a security protocol, comprising: A single local sensor; A local microprocessor and associated memory, the local microprocessor and associated memory being capable of training and actuating the single local sensor, the single local sensor being capable of sensing at least a first characteristic of the user identity and a second characteristic of the security protocol; And A comparator for comparing the first characteristic with a first acceptable data profile and the second characteristic with a second acceptable data profile, and for outputting a confirmation of the requested activity only if the first characteristic meets the first acceptable data profile and the second characteristic meets the second acceptable data profile; Wherein the output of the confirmation is only for the requesting user to actuate the requested activity.

2. The system according to claim 1, wherein the single sensor is one of a fingerprint reader, a barcode reader, a QR code reader, a card reader, a profile scanner, a biometric scanner, an NFC tag reader, a camera, an environmental sensor, an infrared sensor, a pressure sensor, and a weight sensor.

3. The system according to claim 1, wherein the second characteristic is the presence of at least one of the following: a safety helmet; goggles; a laboratory coat; cleanroom equipment; protective boots; and gloves.

4. The system according to claim 1, wherein the first characteristic includes the presence of an operator's permit.

5. The system according to claim 1, wherein the requested activity is access to a wine cabinet, and wherein, The first characteristic includes age and the second characteristic includes blood alcohol content.

6. The system according to claim 1, wherein the rejection of the requested activity is temporary.

7. The system according to claim 1, wherein the rejection of the requested activity includes the idle time of a treatment measure performed by the requesting user.

8. The system according to claim 7, wherein during the idle time, any confirmed characteristic is not re-sensed.

9. The system according to claim 1, wherein the second characteristic includes the presence of prescription lenses.

10. The system according to claim 1, wherein the comparator is associated with the local microprocessor.

11. The system according to claim 1, further comprising a remote microprocessor associated with the comparator.

12. The system according to claim 11, wherein the local microprocessor controls the communication with the remote microprocessor.

13. The system according to claim 12, wherein the communication includes one of cellular communication or Wi-Fi communication.

14. The system according to claim 11, wherein the remote microprocessor is located in the cloud relative to the local microprocessor.

15. The system according to claim 11, wherein the comparator is distributed between the local microprocessor and the remote microprocessor.

16. The system according to claim 1, wherein the comparison of the first characteristic with the first acceptable data profile occurs before the comparison of the second characteristic with the second acceptable data profile.

17. The system according to claim 1, wherein the first acceptable data profile and the second acceptable data profile are stored in a relational database residing in the associated memory.

18. The system according to claim 1, wherein the single local sensor is managed via a mobile application.

19. The system according to claim 18, wherein the confirmation of the requested activity occurs via the mobile application.

20. The system according to claim 19, wherein the confirmation includes wireless communication from the mobile application to the firmware of the hardware lock.

21. The system according to claim 1, wherein the comparator serially compares the first characteristic and the second characteristic.

22. The system according to claim 21, wherein the comparison of the first characteristic occurs first.

23. The system according to claim 1, wherein the comparator compares the first characteristic and the second characteristic in parallel.

24. The system according to claim 1, wherein the comparison made by the comparator is a comparison with a specific data point in the acceptable data profile.

25. The system according to claim 24, wherein the specific data point for the first characteristic in the first acceptable data profile is age.

26. The system according to claim 24, wherein the specific data point for the first characteristic in the first acceptable data profile is educational level.

27. The system according to claim 24, wherein the specific data point for the first characteristic in the first acceptable data profile is proof level.

28. The system according to claim 1, wherein the comparison made by the comparator is a comparison with a data range in the acceptable data profile.

29. The system according to claim 28, wherein the data range of the second characteristic depends on the comparison of the first characteristic.

30. The system according to claim 1 further includes a learning module that modifies the first acceptable data profile and the second acceptable data profile based on a plurality of comparisons made by the comparator.

31. The system according to claim 30, wherein the modification is further based on available third - party data.

32. The system according to claim 31, wherein the third - party data includes accident, incident, or arrest reports.

33. The system according to claim 1, wherein the first acceptable data profile includes at least one of the following: age; license; education; presence of an identification card; presence of a payment card; mobile - device - based identification information; facial recognition; biometric identification; fingerprint; identification of a specific person or a specific category of persons; or infrared signature.

34. The system according to claim 1, wherein the second acceptable data profile includes at least one of the following: presence of equipment; presence of specific clothing; presence of a specific biometric condition; presence of an electronic key; presence of specific environmental conditions; occurrence of a specific time frame; or presence at a specific location.

35. The system according to claim 1, wherein the requested activity includes one of the following: operation of a vehicle; operation of heavy equipment; operation of a motorcycle; operation of an aircraft; operation of a water - based vehicle; access to a restricted location; or access to a restricted item.

Images