Intelligent key management and control system based on face and alcohol detection

Abstract

The invention relates to the technical field of intelligent key management and control, and discloses an intelligent key management and control system based on face and alcohol detection, and the system comprises a filing authorization module which is used for face filing living body verification and threshold authorization; the taking acquisition module is used for acquiring a key taking request timestamp of a target key identifier and face alcohol; the judgment unlocking module is used for fusing judgment to unlock a single key position and writing a session voucher; the event auditing module is used for storing and generating a log chain abstract value; the presence confirmation module is used for generating presence confirmation event records according to presence confirmation intervals when the loop is not closed; the return closed loop module is used for return judgment contact consistency verification and closed loop; and the exception registration module is used for generating exception event records and storing the exception event records. According to the invention, deterministic management and control and continuous traceable recording of the whole key issuing and returning process are realized.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of intelligent key management and control, and particularly relates to an intelligent key management and control system based on face and alcohol detection. BACKGROUND

[0002] In the scenarios of vehicles, machine rooms, warehouses, equipment rooms, etc., keys are typical controlled items, and the taking and returning thereof usually requires personnel identity confirmation, authorized time period restriction, key position level issuance control, and traceable event record. Existing key management usually adopts manual registration, mechanical key cabinet, card swiping / password cabinet opening, etc. to complete issuance and recovery, or only performs one-time identity verification at the taking link. Such a mode is prone to problems that the three elements of the taking person, taking time, and taking object cannot be strictly one-to-one corresponding in the data level in actual operation, and lacks continuous process record in the holding process after taking, which leads to that subsequent review can only rely on manual recall or scattered logs, and it is difficult to form an event link that can be retrieved and sorted. In addition, in the case where the personnel identity state needs to be restricted, a single identity credential or single verification cannot cover the whole process: on the one hand, the taking process needs to jointly determine the authorized relationship, time period condition, and key position state; on the other hand, there are still management risks such as identity impersonation, wrong return, and wrong return in the holding period and the returning link, and if the consistency check associated with the session and the event library audit mechanism are lacking, abnormal branches are difficult to be standardized recorded and traced. SUMMARY

[0003] The application provides an intelligent key management and control system based on face and alcohol detection, which solves the technical problems in the related art that only relying on manual registration or single identity credential leads to difficulty in determining the correspondence of the key taking request, the taking person, the taking time, and the target key identifier, the lack of session-level continuous audit link in the taking process, and the easy occurrence of wrong return in the returning link and the difficulty in timely tracing.

[0004] The application provides an intelligent key management and control system based on face and alcohol detection, which includes: The filing authorization module is configured to collect a face template and enable a living body check, set a face matching threshold and an alcohol concentration threshold, establish an authorized relationship table, and configure a touch type recognition piece and a session credential. The taking collection module is configured to receive a key taking request, obtain a target key identifier and a key taking request timestamp, collect a face to obtain a user unique identifier and a face matching score, and collect alcohol detection data to obtain a blood alcohol concentration value. The judgment unlocking module is configured to perform fusion judgment based on the face matching score and the face matching threshold, the blood alcohol concentration value and the alcohol concentration threshold, the authorized relationship table, and the key position state, and only unlock a single key position corresponding to the target key identifier at a time, generate a session identifier, and write it into the session credential. The event auditing module is used to write access event records, presence confirmation event records, return event records, and abnormal event records into the event database, and generate log chain summary values ​​to form a continuous audit trail; The presence confirmation module is used to read the session credentials at the presence confirmation interval, collect face and alcohol detection data, and generate presence confirmation event records when the session status corresponding to the session identifier is not closed. The return closed-loop module is used to obtain the return decision result based on the session credentials, face and alcohol test data, read the contact-type identification device and perform consistency verification when the result is obtained, generate a return event record and update the session state to closed loop. The exception registration module is used to generate exception event records and write them to the event database when the fusion judgment fails, the on-site confirmation fails, or the consistency verification fails.

[0005] The beneficial effects of this invention are as follows: This invention breaks down the key management process into stages such as retrieval, presence confirmation, return, and anomaly registration, and uses session identifiers to connect the data of each stage, creating a searchable and sortable record chain in the event database for the same retrieval of personnel, time, and target key identifier. The system simultaneously introduces facial verification and alcohol detection constraints at key retrieval and return nodes, and combines the available time period and key availability status from the authorization relationship table for fusion judgment, avoiding mis-retrieval, impersonation, and unauthorized access based on a single credential. Consistency verification of the actual returned key is performed through contactless identification, reducing management distortion caused by incorrect or mixed returns. After the event record is written, a log chain summary value is generated, forming a continuous audit trail, ensuring that abnormal branches also have traceability and review basis. Overall, this invention improves the certainty, traceability, and audit efficiency of controlled key issuance and return. Attached Figure Description

[0006] Figure 1 This is a schematic diagram of a smart key control system based on face and alcohol detection according to the present invention. Detailed Implementation

[0007] The subject matter described herein will now be discussed with reference to exemplary embodiments. It should be understood that these embodiments are discussed only to enable those skilled in the art to better understand and implement the subject matter described herein, and changes may be made to the function and arrangement of the elements discussed without departing from the scope of this specification. Various processes or components may be omitted, substituted, or added as needed in the examples. Furthermore, features described in some examples may be combined in other examples.

[0008] like Figure 1 As shown, a smart key control system based on facial recognition and alcohol detection includes: The document creation and authorization module 1 is used to collect face templates and enable liveness verification, set face matching thresholds and alcohol concentration thresholds, establish an authorization relationship table, and configure contact-type identification devices and session credentials. The acquisition module 2 is used to receive key retrieval requests, obtain the target key identifier and key retrieval request timestamp, collect face data to obtain the user's unique identifier and face matching score, and collect alcohol test data to obtain the blood alcohol concentration value. The judgment unlocking module 3 is used to make a fusion judgment based on the face matching score and face matching threshold, blood alcohol concentration value and alcohol concentration threshold, authorization relationship table and key presence status. When the judgment is successful, only the single key position corresponding to the target key identifier is unlocked, a session identifier is generated and written into the session credential. Event auditing module 4 is used to write access event records, presence confirmation event records, return event records, and abnormal event records into the event database, and generate log chain summary values ​​to form a continuous audit trail; The presence confirmation module 5 is used to read the session credentials at the presence confirmation interval, collect face and alcohol detection data, and generate presence confirmation event records when the session status corresponding to the session identifier is not closed. The return closed-loop module 6 is used to obtain the return decision result based on the session credentials, face and alcohol test data, read the contact-type identification device and perform consistency verification when the result is passed, generate a return event record and update the session state to closed loop. The exception registration module 7 is used to generate exception event records and write them to the event database when the fusion judgment fails, the presence confirmation fails, or the consistency verification fails.

[0009] In one embodiment of the present invention, to achieve unified management of identity verification, status verification, and authorization constraints during the key issuance and return process, the system first completes basic data archiving and rule configuration; collects face templates and enables liveness detection, sets face matching thresholds and alcohol concentration thresholds, establishes an authorization relationship table, and configures contactless identification devices and session credentials, including: Step 11: For each user, the system collects the user's facial image and generates a facial template that corresponds one-to-one with the user's unique identifier. The unique user identifier is a data identifier used to uniquely determine the user's identity within the system, and can be an employee ID, account number, or other unique code within the system. The facial template is a set of feature data extracted from the user's facial image that can be used for comparison, and is used for identity verification of the collected face during subsequent key retrieval, presence confirmation, and return processes. The generated facial template is written to a facial template library, which is a storage structure that stores multiple user facial templates and supports retrieval by user's unique identifier. Simultaneously, the system enables liveness detection for the collected facial recognition process. Liveness detection is a mechanism to verify whether the collected face originates from a real person present at the scene, used to distinguish between real faces and photos, videos, or other non-real face presentation methods, thereby ensuring the quality of facial template archiving and the reliability of identity verification during subsequent recognition.

[0010] Step 12: After completing the user's face template registration, the system sets a face matching threshold and an alcohol concentration threshold. The face matching threshold is a threshold for judging the face matching score output by face comparison. The face matching score is the similarity score obtained by comparing the collected face with the corresponding face template in the face template library. When the face matching score meets the face matching threshold condition, it indicates that the identity verification meets the preset requirements. The alcohol concentration threshold is a threshold for judging the blood alcohol concentration value output by alcohol detection. The blood alcohol concentration value is the concentration value converted or calculated from the alcohol detection data. When the blood alcohol concentration value meets the alcohol concentration threshold condition, it indicates that the status verification meets the preset requirements. The system writes the user's unique identifier, target key identifier, and available time period into the authorization relationship table, forming an entry in the authorization relationship table. The target key identifier is an identifier code used to uniquely identify a key or a set of bound key positions in the system. The available time period is the time range within which the user has access to the target key identifier, which can consist of a start and end time or a periodic time period. The authorization relationship table is a data table that stores the correspondence between user unique identifiers, target key identifiers and available time periods. It is used to perform authorization and time period verification during subsequent key retrieval determination, thereby solidifying the management rules of when a user can retrieve which key into a searchable and auditable data object.

[0011] Step 13: For each key, the system configures a contact-type identification component and registers a one-to-one correspondence between the contact-type identification component and the target key identifier. The contact-type identification component is a contact-type identification part installed on the key or key slot. It outputs or carries unique identification information through contact with the read / write contacts, enabling the system to read the key identifier of the actually returned key during the return process and verify its consistency with the target key identifier. This avoids management distortions caused by misplacement, incorrect return, or substitution with other keys. The system also sets the session credential to store only a fixed-length digest of the session identifier. The session identifier is a unique identifier generated when the key retrieval judgment is passed, used to associate the same retrieval, presence confirmation, and return loop. The fixed-length digest is a fixed-length data obtained after extracting the session identifier, used to complete session association and retrieval without directly storing the original session identifier text. The session credential is a data carrier used to store the fixed-length digest of the session identifier. Reading the session credential during the presence confirmation and return processes yields the fixed-length digest of the session identifier, thereby locating the corresponding session in the event database and maintaining data flow consistency. The system also sets an on-site confirmation interval, which is a time interval parameter that triggers the on-site confirmation process when the session state is not closed. It is used to periodically confirm the on-site status of the key holder after the key is taken and before the return of the key to close the loop, forming a continuous control link in conjunction with the face matching threshold and the alcohol concentration threshold.

[0012] Through the above-mentioned filing and configuration process, the system establishes a face template library, authorization relationship table, one-to-one correspondence between contact-type identification and target key identifier, and storage rules for session credentials at the data level. At the rule level, it also solidifies the face matching threshold, alcohol concentration threshold, and presence confirmation interval, enabling the system to integrate identity verification, status verification, authorization constraints, and key entity consistency constraints into the same management process in subsequent retrieval, presence confirmation, and return processes.

[0013] In one embodiment of the present invention, receiving a key retrieval request, obtaining a target key identifier and a key retrieval request timestamp, collecting facial data to obtain a unique user identifier and a facial matching score, and collecting alcohol detection data to obtain a blood alcohol concentration value include: Step 21: The system receives a key retrieval request and obtains the target key identifier and the key retrieval request timestamp corresponding to the request. The key retrieval request timestamp is a time stamp recorded by the system when it receives the request. It is used to compare with the available time periods in the authorization relationship table and serves as the basic field for session association and audit sorting. By fixing the target key identifier and the key retrieval request timestamp, the system can clearly identify the object and time of a single key retrieval request at the data level, avoiding confusion for similar requests in subsequent judgments and records.

[0014] Step 22: After obtaining the basic fields of the key retrieval request, the system captures a face in response to the request and performs a liveness check on the captured face. The liveness check is a mechanism to verify whether the captured face originates from a real person present, used to exclude false recognition inputs caused by photos, videos, or other non-real-person presentations. After the liveness check passes, the system compares the captured face with a face template library to obtain a unique user identifier and a face matching score.

[0015] Step 23: The system collects alcohol test data in response to the key retrieval request and obtains the blood alcohol concentration value. The alcohol test data is the test data collected and output by the alcohol testing device; by simultaneously collecting the blood alcohol concentration value during the key retrieval request stage, the system can complete the collection and solidification of key inputs for identity verification and status verification within the same request cycle, avoiding incomplete judgment links in subsequent stages due to inconsistent input sources.

[0016] After obtaining the above fields, the system combines the target key identifier, key retrieval request timestamp, user unique identifier, face matching score, and blood alcohol concentration value to generate a retrieval event draft. This retrieval event draft is a structured data object encapsulating the key elements of a key retrieval request. It is used in subsequent fusion decisions, participating in the determination along with the authorization relationship table, key availability status, and threshold conditions. After successful determination, it serves as the basic data source for the retrieval event record.

[0017] This embodiment achieves a unique correspondence between a key retrieval request and the object dimension and the time dimension by solidifying and collecting the target key identifier and the key retrieval request timestamp. By performing liveness verification on the collected face and comparing it with the face template library to output the user's unique identifier and face matching score, it achieves a definite binding between the key retrieval request and the user's identity verification result. By collecting alcohol test data to obtain the blood alcohol concentration value and combining it with the aforementioned fields to generate a retrieval event draft, it achieves consistent encapsulation and verifiable retention of identity verification input and status verification input in the same event object. Overall, it achieves the structured solidification of identity verification, status verification and retrieval elements of the key retrieval request.

[0018] In one embodiment of the present invention, a fusion judgment is made based on the face matching score and face matching threshold, blood alcohol concentration value and alcohol concentration threshold, authorization relationship table, and key presence status. Upon successful fusion, only the single key slot corresponding to the target key identifier is unlocked, a session identifier is generated, and a session credential is written, including: Step 31: The system reads the draft access event and extracts the user's unique identifier, the target key identifier, and the key retrieval request timestamp. Based on the authorization relationship table, the system retrieves the available time period corresponding to the user's unique identifier and the target key identifier, and determines whether the key retrieval request timestamp falls within an available time period, obtaining the authorization and time period verification result. The authorization and time period verification result is used to characterize whether the user has valid access rights to the target key identifier at that time.

[0019] Step 32: After completing authorization and time period verification, the system continues to read the event draft and extract the face matching score and blood alcohol concentration value, respectively. These are compared with the face matching threshold and blood alcohol concentration threshold, and the key presence status of the key slot corresponding to the target key identifier is obtained. The key presence status is a status marker indicating whether a key exists in the key slot corresponding to the target key identifier, including at least two states: present and absent. The system performs a fusion judgment on the authorization and time period verification results, the comparison results of the face matching score and face matching threshold, the comparison results of the blood alcohol concentration value and blood alcohol concentration threshold, and the key presence status: if the authorization and time period verification results pass, both comparisons meet the threshold conditions, and the key presence status is present, the fusion judgment result is considered successful; otherwise, the fusion judgment result is considered unsuccessful. The fusion judgment result is the output determining whether the current key retrieval request meets the unlocking conditions, and is used to drive subsequent key slot control actions.

[0020] Step 33: Upon successful fusion decision, the system generates a session identifier. This session identifier is generated based on the user's unique identifier, the target key identifier, and the key retrieval request timestamp. It is used to uniquely associate subsequent presence confirmations and return loops within the same retrieval process. The system extracts a fixed-length digest of the session identifier and writes it into the session credential. The fixed-length digest of the session identifier is fixed-length data obtained after digest extraction of the session identifier, used to complete session association and retrieval without directly storing the original session identifier. The system simultaneously unlocks only the single key slot corresponding to the target key identifier. The single key slot is a physical storage location or lock position that corresponds one-to-one with the target key identifier. "Unlocking only" means that at any given time, only the key slot corresponding to the target key identifier is allowed to enter the retrievable state while other key slots remain locked.

[0021] This embodiment achieves key retrieval permission and time condition constraints by performing authorization and time period verification based on the key retrieval request timestamp according to the authorization relationship table; by incorporating face matching score and face matching threshold, blood alcohol concentration value and alcohol concentration threshold, and key presence status into the fusion decision, it achieves joint gating of the unlocking action by identity verification, status verification, and key entity presence status; by generating a session identifier when the fusion decision result passes and writing a fixed-length summary of the session identifier into the session credential, it achieves continuous association between the retrieval event and the subsequent presence confirmation and return closed loop under the same session identifier; by unlocking only the single key bit corresponding to the target key identifier, it achieves bit-level isolation control of the retrieval object.

[0022] In one embodiment of the present invention, access event records, presence confirmation event records, return event records, and abnormal event records are written into an event database, and a log chain summary value is generated to form a continuous audit trail, including: Step 41: The system first sets a unified field set for the event database. This unified field set includes a session identifier, a target key identifier, a unique user identifier, and an event occurrence timestamp. Then, it writes retrieval event records, presence confirmation event records, return event records, and abnormal event records into the event database according to this unified field set. The event database is a data storage structure for storing event records, supporting retrieval by session identifier and sorting by event occurrence timestamp. The event occurrence timestamp is a timestamp recorded by the system when generating the corresponding event record, used to determine the order in which events occur under the same session identifier. By setting the unified field set, different types of event records have consistent search and sorting keys within the event database, facilitating unified retrieval and serialization management of multiple types of event records with the same session identifier in subsequent steps.

[0023] Step 42: After the event record is written to the event database, the system performs log chain summary value generation processing after each write of a retrieved event record, an on-site confirmation event record, a returned event record, or an abnormal event record. This involves using the serialized content of the previous log chain summary value and the current event record as input for summary calculation to obtain the current log chain summary value. During the first write, a preset log chain summary value is used as the previous log chain summary value, and the current log chain summary value is bound to the current event record and written to the event database. The log chain summary value is summary data for chaining event record sequences, used to characterize the association between an event record and its preceding records. The serialized content is the deterministic data representation of the current event record, converted according to a preset field order, which can be used for summary calculation to ensure consistent summary input for the same event record in different calculations. The preset log chain summary value is a fixed summary value used as the starting point of the chain when the event record is first written. By using the previous log chain summary value and the serialized content of the current event record as input for summary calculation, the system associates the log chain summary value corresponding to any event record with its predecessor event record, thereby forming a summary chain in the event database that is sequentially linked according to the writing order.

[0024] Step 43: The system retrieves access event records, presence confirmation event records, return event records, and exception event records from the event database based on the session identifier, and sorts them by event occurrence timestamp to obtain the event sequence corresponding to the session identifier. Simultaneously, the system reads the log chain summary value sequence corresponding to the event sequence and stores the event sequence and the log chain summary value sequence together as a continuous audit track. The event sequence is a set of event records sorted by event occurrence timestamp under the same session identifier; the log chain summary value sequence is a set of log chain summary values ​​corresponding to each event sequence; the continuous audit track is an audit data structure obtained by storing the event sequence and the log chain summary value sequence together using the same index relationship, used to support continuous review of the entire process of events corresponding to the session identifier. Through the above-mentioned associated storage, the system can obtain the full event sequence, including access, presence confirmation, return, and exception events, using the session identifier as the entry point during subsequent audits or tracing, and simultaneously obtain the corresponding log chain summary value sequence to verify the consistency of the event order and event chain.

[0025] This embodiment achieves unified management of different types of event records under the same search and sorting key system by setting a unified set of fields including session identifier, target key identifier, user unique identifier, and event occurrence timestamp, and writing them into the event database accordingly. It achieves chain-like association and verifiable summary continuity between event records by using the previous log chain summary value and the serialized content of the current event record as input for summary calculation after each event record is written, and binding this value to the event record and writing it into the event database. Furthermore, it achieves continuous traceability and consistency verification of key retrieval, presence confirmation, return, and anomaly processes corresponding to the same session identifier by retrieving based on the session identifier and sorting by event occurrence timestamp, and storing these sequences as continuous audit trails. This meets the requirement for traceable management of key handover and usage records.

[0026] In one embodiment of the present invention, when the session state corresponding to the session identifier is not closed, the session credentials are read according to the presence confirmation interval, face and alcohol detection data are collected, and a presence confirmation event record is generated, including: Step 51: When the session state corresponding to the session identifier is not closed, the system reads the event database to obtain the key retrieval request timestamp and the event occurrence timestamp of the previous presence confirmation event record. If there is no previous presence confirmation event record, the system uses the key retrieval request timestamp as the base timestamp; if there is a previous presence confirmation event record, the system uses the event occurrence timestamp as the base timestamp. The system calculates the time difference between the current system time and the base timestamp, and compares the time difference with the presence confirmation interval to determine the trigger determination. The trigger determination is a determination output used to determine whether to enter the current presence confirmation collection and verification process. When the trigger determination is triggered, the system reads the session credentials to obtain a fixed-length digest of the session identifier, and searches for the session identifier in the event database based on the fixed-length digest of the session identifier; when the search fails, the system generates an abnormal event record and writes it to the event database to leave a trace of the presence confirmation trigger where the session identifier cannot be located.

[0027] Step 52: Upon successful retrieval, the system collects a face and performs liveness verification based on the retrieved session identifier. If the liveness verification fails, the system generates an exception event record and writes it to the event database. After successful liveness verification, the system compares the collected face with the face template library to obtain the user's unique identifier and face matching score, and collects alcohol test data to obtain the blood alcohol concentration value. The collected face and alcohol test data in the presence verification process are associated with the session identifier to provide input fields for subsequent consistency comparison and threshold comparison, thereby ensuring that the presence verification and the retrieval process corresponding to the same session identifier can be continuously referenced at the data level.

[0028] Step 53: The system performs a consistency comparison between the user's unique identifier and the user's unique identifier in the retrieval event record in the event database, and compares the face matching score with the face matching threshold and the blood alcohol concentration value with the alcohol concentration threshold, respectively. When the consistency comparison passes and both comparisons meet the threshold conditions, the system generates an on-site confirmation event record and writes it into the event database; otherwise, the system generates an abnormal event record and writes it into the event database. The consistency comparison is used to confirm that the user's unique identifier collected during this on-site confirmation is consistent with the user's unique identifier in the retrieval event record corresponding to the session identifier, thereby establishing a common-source association between the on-site confirmation verification during the key-holding period and the initial retrieval identity; the on-site confirmation event record is an event record object formed when the on-site confirmation verification passes, and is used to form an intermediate node in the session link together with the retrieval event record and the return event record corresponding to the session identifier; the abnormal event record is an event record object formed when the on-site confirmation is triggered, the session identifier retrieval or verification fails to meet the conditions, and is used to leave a trace of the failed branch in the event database.

[0029] This embodiment determines the trigger judgment by establishing a base timestamp and comparing it with the on-site confirmation interval, thus solidifying the on-site confirmation trigger rules during the unclosed session state. By retrieving the session identifier, it establishes a definite association between the on-site confirmation process and the session identifier. By performing liveness verification on the collected face and comparing it with the face template library to obtain the user's unique identifier and face matching score, and by collecting alcohol detection data to obtain the blood alcohol concentration value, it generates on-site confirmation event records or abnormal event records by combining consistency comparison and threshold comparison, thus realizing event-based traceability and continuous tracking of identity verification and status verification during key holding.

[0030] In one embodiment of the present invention, a return decision is obtained based on session credentials, facial recognition data, and alcohol detection data. Upon successful verification, a contactless identification device is read and consistency is checked. A return event record is generated, and the session state is updated to a closed loop. This includes: Step 61: The system reads the session credentials to obtain a fixed-length digest of the session identifier, and retrieves the session identifier and access event record from the event database based on the fixed-length digest of the session identifier. Through the joint retrieval of the session credentials and the event database, the system establishes a definite correspondence between this return operation and the existing access event record, providing a reference basis for subsequent identity consistency comparison and key identifier consistency verification. The fixed-length digest of the session identifier mentioned here is used to complete session location without directly reading the original session identifier; the access event record is used to provide the access subject information and access object information corresponding to the session identifier.

[0031] Step 62: After retrieving the access event record, the system obtains the user's unique identifier, face matching score, and blood alcohol concentration value based on the face and alcohol detection data. It then performs a consistency comparison between the user's unique identifier and the unique identifier in the access event record, and simultaneously compares the face matching score with the face matching threshold and the blood alcohol concentration value with the blood alcohol concentration threshold. If the consistency comparison passes and both comparisons meet the threshold conditions, the system determines that the return decision is successful; otherwise, it determines that the return decision is unsuccessful and generates an abnormal event record, which is written to the event database. The return decision result is the output of the judgment on whether the current return operation meets the return conditions; the threshold comparison is used to impose conditional constraints on the face matching score and blood alcohol concentration value at the time of return, thereby ensuring that the return decision has a definite input and output relationship.

[0032] Step 63: When the return judgment result is passed, the system reads the contact-type identification to obtain the target key identifier of the actual returned key and performs a consistency check with the target key identifier of the retrieval event record. This consistency check determines whether the target key identifier of the actual returned key matches the target key identifier corresponding to the retrieval event record. When the consistency check passes, the system generates a return event record and writes it to the event database, updates the session state corresponding to the session identifier to closed loop in the event database, and clears the fixed-length digest of the session identifier stored in the session credential. When the consistency check fails, the system generates an exception event record and writes it to the event database. By performing closed-loop update of the session state and clearing of the session credential under the successful return path, the system ensures that the process termination condition for the same session identifier has a definite endpoint and avoids the repeated reference of the same session credential.

[0033] This embodiment achieves a definite association between the return process and the access link corresponding to the session identifier by reading the session credentials and retrieving the session identifier and access event records. By obtaining the user's unique identifier, face matching score and blood alcohol concentration value, and combining consistency comparison and threshold comparison to determine the return decision result, it achieves a unified judgment of the consistency constraint between the returning subject and the access subject and the return condition constraint. By reading the contact-type identification and performing consistency verification with the target key identifier when the return decision result is passed, it achieves the event-based solidification of the consistency verification of the returning object and the session closed-loop termination condition, thereby enabling the return link of the key control process to have a traceable and verifiable closed-loop record link.

[0034] In one embodiment of the present invention, when a fusion decision fails, an on-site confirmation fails, or a consistency check fails, an abnormal event record is generated and written to an event database, including: Step 71: The system receives anomaly trigger signals indicating fusion decision failure, presence confirmation failure, or consistency verification failure and determines the failure type. The failure type is a classification field used to distinguish different failure sources, serving as the core index field for anomaly event records and driving subsequent field extraction paths. The system determines the extraction source of the anomaly-related fields based on the failure type: when the failure type is fusion decision failure, the system extracts the target key identifier, user unique identifier, and event timestamp from the event draft; when the failure type is presence confirmation failure or consistency verification failure, the system reads the session credential to obtain a fixed-length digest of the session identifier, and retrieves the session identifier from the event database based on the fixed-length digest, while simultaneously extracting the target key identifier, user unique identifier, and event timestamp. Thus, without relying on a single unified source, the system establishes association anchors with the access request or session link for different failure scenarios, ensuring that anomaly event records can establish a definite correspondence with the corresponding key object, user object, and time of occurrence.

[0035] Step 72: After completing the basic field extraction, the system extracts the comparison values ​​of failure nodes corresponding to the failure type and generates anomaly event records. The comparison values ​​of failure nodes are record fields used to characterize the failure node criteria. The source of these criteria corresponds to the failure type and is used to reflect at least the comparison or verification results generated during the fusion decision, on-site confirmation, or consistency verification stages. The anomaly event records generated by the system include the event occurrence timestamp, failure type, target key identifier, user unique identifier, and the comparison values ​​of the failure nodes. When a session identifier is retrieved, it is written into the anomaly event record, and then the anomaly event record is written into the event database. By writing the session identifier as an optional associated field into the anomaly event record, the system allows the anomaly event record to cover both scenarios where a session link has not yet been formed, such as fusion decision failure, and scenarios where a session link has been formed, such as on-site confirmation failure and consistency verification failure, thereby avoiding breaks in the anomaly record structure at different failure stages.

[0036] Step 73: After the abnormal event record is written to the event database, the system performs chained digest binding and session link association processing: the digest value of the previous log chain and the serialized content of the abnormal event record are used as inputs for digest calculation to obtain the current log chain digest value, and the current log chain digest value is bound to the abnormal event record and written to the event database. The comparison value of the failed node and the event occurrence timestamp jointly participate in the formation of the serialized content of the abnormal event record, so that the generated log chain digest value can form a definite binding to the abnormal record content. Further, when a session identifier is retrieved, the system retrieves the retrieval event record, the presence confirmation event record, the return event record, and the abnormal event record in the event database based on the session identifier, and sorts them according to the event occurrence timestamp to obtain the event sequence corresponding to the session identifier, thereby incorporating the abnormal event record into the event link corresponding to the session identifier, forming a complete session sequence including the failed node.

[0037] This embodiment achieves the determination and location of abnormal records by determining the failure type and extracting the target key identifier, user unique identifier, and event occurrence timestamp from the event draft or session credentials and event database according to the failure type; by generating abnormal event records containing comparison values ​​of failure nodes and writing them into the event database and binding log chain summary values, an event sequence corresponding to the session identifier is formed when the session identifier is retrieved, thus realizing the structured traceability and continuous audit association of failure branches.

[0038] In one embodiment of the present invention, the system performs a validity check when the session credential is read to constrain the usable time range of the session credential. This ensures that the session credential has a defined time limit for its use in subsequent stages such as presence confirmation and return closure, thereby cooperating with the session association mechanism of the session identifier to form controllable session credential usage rules, specifically including: Step 81: When the system writes the fixed-length digest of the session identifier into the session credential, it simultaneously writes the credential generation timestamp into the session credential and sets the credential validity period. The credential generation timestamp is a timestamp recorded when the session credential is generated or updated, used to characterize the generation time of the current content of the session credential; the credential validity period is a parameter used to limit the time length during which the session credential can be read and participate in session location, used as a comparison benchmark for validity verification. By simultaneously storing the fixed-length digest of the session identifier and the credential generation timestamp in the session credential, the system provides a verifiable basis for timeliness determination for subsequent reading processes.

[0039] Step 82: When the presence confirmation module or the return closed-loop module reads the session credential, the system reads the fixed-length digest of the session identifier and the credential generation timestamp, calculates the time difference between the current system time and the credential generation timestamp, and compares the time difference with the credential validity duration. The time difference, representing the elapsed time of the current system time relative to the credential generation timestamp, characterizes the duration of the session credential at the current reading time. This validity comparison determines whether the session credential is still within a preset validity window. Through this comparison, the system can provide a definite validity judgment when the reading action occurs.

[0040] Step 83: When the time difference exceeds the validity period of the credential, the system generates an exception event record and writes it to the event database, and clears the fixed-length summary of the session identifier and the credential generation timestamp stored in the session credential; when the time difference does not exceed the validity period of the credential, the system keeps the session credential unchanged. By recording exception events and clearing session credentials in timeout scenarios, the system incorporates the status changes of invalid session credentials into the event database record system; by keeping session credentials unchanged in non-timeout scenarios, the system ensures that valid session credentials can be consistently read and referenced in subsequent processes.

[0041] This embodiment achieves the solidification of session credential validity parameters by synchronously writing the credential generation timestamp and setting the credential validity period when writing the session credential; it achieves the determination of session credential validity by comparing the time difference with the credential validity period when reading the session credential by the presence confirmation module or the return closed-loop module; and it achieves event-based traceability and controllable updates of session credential invalidation status by generating abnormal event records and clearing the session credential in timeout scenarios, and keeping the session credential unchanged in non-timeout scenarios, thus enabling the session association links of the key management system to have auditable validity boundaries.

[0042] In one embodiment of the present invention, after the system achieves a fusion decision and unlocks only the single key slot corresponding to the target key identifier, it executes a retrieval closed-loop confirmation process to establish a consistent state verification link between the unlocking action and the actual key retrieval state. If the retrieval conditions are not met, an abnormal event record is generated and a lock is reclaimed, thus forming a verifiable closed loop at the key slot state level during the retrieval process. Specifically, this includes: Step 91: When the fusion judgment result is passed and the system only unlocks the single key slot corresponding to the target key identifier, the system obtains the key's presence status of the single key slot and writes it into the retrieval event record. Simultaneously, a retrieval time limit is set based on the key retrieval request timestamp. The retrieval time limit is a time window boundary set for this retrieval operation, used to limit the time range within which the key is allowed to change from a present state to an absent state after unlocking. Setting the retrieval time limit based on the key retrieval request timestamp establishes a definite correspondence between the retrieval time limit and the time of occurrence of this retrieval operation, thus facilitating the subsequent reference of the retrieval judgment time benchmark. Writing the key's presence status into the retrieval event record ensures that the retrieval event record contains the key slot status information corresponding to the unlocking time, providing a comparable record basis for subsequent judgments of status changes.

[0043] Step 92: After setting a retrieval time limit, the system reads the key's presence status of the single key slot within the time limit and determines whether the key's presence status has changed from present to absent. This determination is used to ascertain whether the key slot undergoes a state change consistent with key retrieval after unlocking. "Present" and "absent" are two possible values ​​for the key's presence status, where "present" indicates the key is in the key slot, and "absent" indicates the key is not in the key slot. By reading the key's presence status and performing a state change determination within the retrieval time limit, the system transforms the retrieval status into a verifiable state condition.

[0044] Step 93: When the key's "in-position" status fails to change to "out-of-position" within the retrieval time limit, the system generates an abnormal event record and writes it to the event database, and updates the single key position to a locked state. This update to a locked state involves performing a lock reset control action on the single key position, causing the key to return from an unlocked state to a locked state and stopping further retrieval operations. By generating abnormal event records and writing them to the event database for scenarios where the key is not retrieved within the time limit, the system incorporates the retrieval loop failure branch into the event-based recording system, enabling subsequent audits to locate the corresponding abnormal node based on the session identifier or target key identifier.

[0045] This embodiment achieves a definitive binding between the unlocking status record and the retrieval time window by obtaining the key's presence status after unlocking a single key position and writing it into the retrieval event record, and setting a retrieval time limit based on the key retrieval request timestamp; by reading the key's presence status within the retrieval time limit and determining the change from presence to absence, the retrieval action is verifiable at the key position status level; by generating an abnormal event record and updating the single key position to a locked state when the change to absence does not occur within the retrieval time limit, the event-based traceability and lock control recovery of the retrieval closed-loop failure branch are achieved, enabling the key retrieval process to have a closed-loop status and traceable abnormal control link.

[0046] It should be noted that the range and threshold size are set for ease of comparison. The size of the threshold depends on the amount of sample data and the number of bases set by those skilled in the art for each set of sample data, as long as it does not affect the ratio between the parameter and the quantized value.

[0047] The embodiments of the present invention have been described above, but the present invention is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms based on the guidance of the present embodiments, all of which are within the protection scope of the present embodiments.

Claims

1. A smart key control system based on facial recognition and alcohol detection, characterized in that, include: The document creation and authorization module is used to collect face templates and enable liveness detection, set face matching thresholds and alcohol concentration thresholds, establish an authorization relationship table, and configure touch-type identification devices and session credentials. The acquisition module is used to receive key retrieval requests, obtain the target key identifier and key retrieval request timestamp, collect face data to obtain the user's unique identifier and face matching score, and collect alcohol test data to obtain the blood alcohol concentration value. The judgment unlocking module is used to make a fusion judgment based on the face matching score and face matching threshold, blood alcohol concentration value and alcohol concentration threshold, authorization relationship table and key presence status. If the judgment is successful, only the single key position corresponding to the target key identifier is unlocked, a session identifier is generated and written into the session credential. The event auditing module is used to write access event records, presence confirmation event records, return event records, and abnormal event records into the event database, and generate log chain summary values ​​to form a continuous audit trail; The presence confirmation module is used to read the session credentials at the presence confirmation interval, collect face and alcohol detection data, and generate presence confirmation event records when the session status corresponding to the session identifier is not closed. The return closed-loop module is used to obtain the return decision result based on the session credentials, face and alcohol test data, read the contact-type identification device and perform consistency verification when the result is obtained, generate a return event record and update the session state to closed loop. The exception registration module is used to generate exception event records and write them to the event database when the fusion judgment fails, the on-site confirmation fails, or the consistency verification fails.

2. The intelligent key control system based on face and alcohol detection according to claim 1, characterized in that, Collect face templates and enable liveness detection, set face matching thresholds and alcohol concentration thresholds, establish an authorization relationship table, and configure touch-based identification devices and session credentials, including: Step 11: Collect the face of each user and generate a face template that corresponds one-to-one with the user's unique identifier. Write the face template into the face template library and enable liveness verification for the recognition processing of the collected faces. Step 12: Set the face matching threshold and alcohol concentration threshold, and write the user's unique identifier, target key identifier and available time period into the authorization relationship table to form the table entries of the authorization relationship table; Step 13: Configure a contact-type identifier for each key and register the one-to-one correspondence between the contact-type identifier and the target key identifier. Set the session credential to store only a fixed-length summary of the session identifier and set the presence confirmation interval.

3. The intelligent key control system based on face and alcohol detection according to claim 1, characterized in that, Upon receiving a key retrieval request, the system obtains the target key identifier and the key retrieval request timestamp; it also collects facial data to obtain the user's unique identifier and facial matching score; and collects alcohol test data to obtain the blood alcohol concentration value, including: Step 21: Receive the key retrieval request, obtain the target key identifier, and obtain the key retrieval request timestamp corresponding to the key retrieval request; Step 22: Collect the face for the key retrieval request and perform liveness verification. After the liveness verification is passed, compare the collected face with the written face template library to obtain the user's unique identifier and face matching score. Step 23: Collect alcohol test data to obtain the blood alcohol concentration value for the key retrieval request, and combine the target key identifier, key retrieval request timestamp, user unique identifier, face matching score and blood alcohol concentration value to generate a retrieval event draft.

4. The intelligent key control system based on face and alcohol detection according to claim 1, characterized in that, A fusion judgment is made based on the face matching score and face matching threshold, blood alcohol concentration value and blood alcohol concentration threshold, authorization relationship table, and key presence status. If successful, only the single key slot corresponding to the target key identifier is unlocked, a session identifier is generated, and a session credential is written, including: Step 31: Read the retrieval event draft and extract the user's unique identifier, the target key identifier, and the key retrieval request timestamp. Based on the authorization relationship table, retrieve the available time period corresponding to the user's unique identifier and the target key identifier, and determine whether the key retrieval request timestamp is within the available time period to obtain the authorization and time period verification results. Step 32: Read the event draft and extract the face matching score and blood alcohol concentration value, compare them with the face matching threshold and blood alcohol concentration threshold respectively, and obtain the key presence status of the key position corresponding to the target key identifier; when the authorization and time period verification results pass and both comparisons meet the threshold conditions and the key presence status is in place, the fusion decision result is determined to be passed; otherwise, the fusion decision result is determined to be failed. Step 33: When the fusion judgment result is passed, a session identifier is generated. The session identifier is generated based on the user's unique identifier, the target key identifier, and the key retrieval request timestamp. A fixed-length digest of the session identifier is extracted and written into the session credential, and only the single key slot corresponding to the target key identifier is unlocked.

5. The intelligent key control system based on face and alcohol detection according to claim 1, characterized in that, The event logs for access, presence confirmation, return, and exceptions are written to the event database, and a log chain summary value is generated to form a continuous audit trail, including: Step 41: Set a unified field set for the event database. The unified field set includes session identifier, target key identifier, user unique identifier and event occurrence timestamp, and write access event records, presence confirmation event records, return event records and abnormal event records into the event database according to the unified field set. Step 42: After each write of a retrieved event record, an on-site confirmation event record, a returned event record, or an abnormal event record, the serialized content of the previous log chain summary value and the current event record is used as the input for summary calculation to obtain the current log chain summary value. During the first write, the preset log chain summary value is used as the previous log chain summary value, and the current log chain summary value is bound to the current event record and written to the event database. Step 43: Based on the session identifier, retrieve the event records, presence confirmation event records, return event records, and abnormal event records in the event database, and sort them by the event occurrence timestamp to obtain the event sequence corresponding to the session identifier. At the same time, read the log chain summary value sequence corresponding to the event sequence, and associate and store the event sequence and the log chain summary value sequence as a continuous audit track.

6. The intelligent key control system based on face and alcohol detection according to claim 1, characterized in that, When the session state corresponding to the session identifier is not closed, the session credentials are read according to the presence confirmation interval, face and alcohol detection data are collected, and a presence confirmation event record is generated, including: Step 51: When the session state corresponding to the session identifier is not closed, read the event database to obtain the key retrieval request timestamp and the event occurrence timestamp of the last presence confirmation event record. If there is no previous presence confirmation event record, use the key retrieval request timestamp as the base timestamp, calculate the time difference between the current system time and the base timestamp, and compare it with the presence confirmation interval to determine the trigger judgment. After triggering, read the session credentials to obtain the fixed-length digest of the session identifier and search for the session identifier in the event database. If the search fails, generate an exception event record and write it to the event database. Step 52: When the retrieval is successful, collect the face based on the retrieved session identifier and perform liveness verification. If the liveness verification fails, generate an abnormal event record and write it into the event database. After the liveness verification passes, compare it with the face template database to obtain the user's unique identifier and face matching score, and collect alcohol detection data to obtain the blood alcohol concentration value. Step 53: Perform a consistency comparison between the user's unique identifier and the user's unique identifier in the event database for retrieving the event record, and compare the face matching score with the face matching threshold and the blood alcohol concentration value with the alcohol concentration threshold respectively. If the consistency comparison passes and both comparisons meet the threshold conditions, generate an presence confirmation event record and write it into the event database; otherwise, generate an abnormal event record and write it into the event database.

7. The intelligent key control system based on face and alcohol detection according to claim 1, characterized in that, The return decision is derived based on session credentials, facial recognition, and alcohol test data. Upon successful return, the contactless identification device is read and its consistency is verified. A return event record is generated, and the session state is updated to a closed loop, including: Step 61: Read the session credentials to obtain a fixed-length digest of the session identifier, and retrieve the session identifier and event records from the event database based on the fixed-length digest of the session identifier; Step 62: Based on the face and alcohol detection data, obtain the user's unique identifier, face matching score and blood alcohol concentration value. Perform a consistency comparison between the user's unique identifier and the user's unique identifier in the access event record. Compare the face matching score with the face matching threshold and the blood alcohol concentration value with the alcohol concentration threshold respectively. If the consistency comparison passes and both comparisons meet the threshold conditions, the return decision is determined to be successful. Otherwise, the return decision is determined to be unsuccessful and an abnormal event record is generated and written to the event database. Step 63: When the return judgment result is passed, read the contact-type identification to obtain the target key identifier of the actual returned key and perform consistency verification with the target key identifier of the retrieval event record. When the consistency verification is passed, generate a return event record and write it to the event database. In the event database, update the session state corresponding to the session identifier to closed loop and clear the fixed-length digest of the session identifier stored in the session credential. When the consistency verification fails, generate an exception event record and write it to the event database.

8. The intelligent key control system based on face and alcohol detection according to claim 1, characterized in that, When a fusion decision fails, an on-site confirmation fails, or a consistency check fails, an exception event record is generated and written to the event database, including: Step 71: Receive abnormal trigger signals for fusion decision failure, presence confirmation failure, or consistency verification failure and determine the failure type. When the failure type is fusion decision failure, extract the target key identifier, user unique identifier, and event occurrence timestamp from the event draft. When the failure type is presence confirmation failure or consistency verification failure, read the session credential to obtain a fixed-length digest of the session identifier and retrieve the session identifier in the event database based on the fixed-length digest of the session identifier. At the same time, extract the target key identifier, user unique identifier, and event occurrence timestamp. Step 72: Extract the comparison value of the failure node corresponding to the failure type based on the failure type and generate an abnormal event record. The abnormal event record includes the event occurrence timestamp, failure type, target key identifier, user unique identifier and the comparison value of the failure node. When the session identifier is retrieved, the session identifier is written into the abnormal event record and the abnormal event record is written into the event database. Step 73: After the abnormal event record is written to the event database, the digest value of the previous log chain and the serialized content of the abnormal event record are used as inputs for digest calculation to obtain the current log chain digest value, which is then bound to the abnormal event record and written to the event database. When the session identifier is retrieved, the event records to be retrieved, the presence confirmation event records, the return event records, and the abnormal event records are retrieved from the event database based on the session identifier and sorted by the event occurrence timestamp to obtain the event sequence corresponding to the session identifier.

9. The intelligent key control system based on face and alcohol detection according to claim 1, characterized in that, Session credentials undergo validity checks upon reading, including: Step 81: When writing the fixed-length digest of the session identifier into the session certificate, simultaneously write the certificate generation timestamp into the session certificate and set the certificate validity period; Step 82: When the presence confirmation module or the return closed-loop module reads the session credential, it reads the fixed-length summary of the session identifier and the credential generation timestamp, calculates the time difference between the current system time and the credential generation timestamp, and compares it with the credential validity period. Step 83: When the time difference exceeds the validity period of the credential, generate an exception event record and write it to the event database, and clear the fixed-length summary of the session identifier and the credential generation timestamp stored in the session credential. When the time difference does not exceed the validity period of the credential, keep the session credential unchanged.

10. The intelligent key control system based on face and alcohol detection according to claim 1, characterized in that, After unlocking with a single key, a retrieval closed-loop confirmation is performed, including: Step 91: When the fusion judgment result is passed and only the single key position corresponding to the target key identifier is unlocked, the key position status of the single key position is obtained and written into the retrieval event record, and the retrieval time limit is set based on the key retrieval request timestamp. Step 92: Within the retrieval time limit, read the key presence status of the single key position and determine whether the key presence status has changed from present to absent. Step 93: If the key is in position but does not change to out position within the retrieval time limit, generate an abnormal event record and write it into the event database, and update the single key position to the locked state.

Images