VIP hall user identity automatic verification and service right real-time synchronization method
By combining multimodal biometric data collection with blockchain technology, along with multi-threshold decision-making and real-time resource scheduling, the problem of real-time synchronization of user identity verification and service rights in VIP lounges has been solved. This has enabled efficient and secure user identity verification and rights synchronization, improving the operational efficiency and user experience of VIP services.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- BEIJING YUETU TRAVEL TECH (GRP) CO LTD
- Filing Date
- 2026-02-06
- Publication Date
- 2026-06-23
AI Technical Summary
In existing technologies, the user identity verification of VIP lounges cannot perceive the dynamic changes in user rights in real time, making it difficult to identify multiple user rights and intelligently match the optimal service options, resulting in delayed rights realization, misallocation of service resources, and a disconnect between user experience and reality.
By collecting and preprocessing multimodal identity features, extracting and encrypting dynamic rights features, verifying blockchain identity and querying rights status, making multi-threshold decisions and handling anomalies, and synchronizing rights and resources in real time, a high-precision, anti-counterfeiting digital identity is constructed, enabling seamless access within seconds and instant redemption of dynamic rights.
It achieves seamless access in seconds and instant redemption of dynamic benefits while ensuring extremely high security, significantly improving the operational efficiency, accuracy, and consistency of user experience of VIP services, and ensuring data security and service stability.
Smart Images

Figure CN122268614A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of identity authentication and service management technology, and in particular to a method for automatic verification of user identity and real-time synchronization of service rights for VIP lounges. Background Technology
[0002] In the VIP service sector, user identity verification and matching of service benefits have always been core elements in ensuring service quality and operational efficiency. VIP lounges, as key service nodes in airports, high-speed rail stations, high-end banks, and corporate clubs, receive a large number of users with different backgrounds and levels of benefits every day. The traditional service model heavily relies on manual operation: upon arrival, users must proactively present their ID, boarding pass, membership card, or electronic information, which staff then verify visually or with specialized equipment. After confirming identity, staff manually match corresponding service benefits, such as meal service, rest time, or fast-track access, based on the user's membership level or ticket type. However, this manual-centric process has revealed fundamental limitations in today's high-concurrency, fast-paced service environment. Long queues at verification windows during peak hours have become the norm, significantly diminishing the convenience and efficiency that VIP services should offer. More importantly, human verification is prone to oversights. Whether it's inaccurate identification of documents or incorrect determination of privilege levels, it can directly lead to service disputes. Existing technical solutions typically treat identity verification as a one-time action and privileges linked to identity as static, pre-set data. However, in real-world scenarios, a user's privilege status is dynamic. For example, a customer might trigger a membership upgrade while en route, or an airline passenger might temporarily gain access to a higher-level lounge due to flight delays. Under existing systems, these real-time privilege changes cannot be immediately perceived by on-site service nodes. The terminals held by staff often display outdated historical data. As a result, users cannot enjoy the services they deserve and must undergo cumbersome on-site communication and verification processes. This not only disrupts the seamless service experience but also renders the company's carefully designed real-time marketing and customer maintenance strategies ineffective at the final stage. Furthermore, system barriers between different service providers constitute another obstacle. A user may simultaneously hold airline elite memberships, bank platinum cards, and third-party lounge privileges. Under current technology, VIP lounges can typically only recognize credentials within their own partner system. They cannot identify, compare, or recommend other parallel, potentially better benefits for users. This leads to a waste of potential user benefits and suboptimal resource allocation for operators. Furthermore, there is a break in the "service context." Current technology focuses on verifying "who you are" and "what you possess," but cannot coherently understand "what kind of service journey you are in." For example, during a user's journey from the city terminal to the airport main VIP lounge, the benefits used at different points cannot be transferred to the next point, potentially leading to duplicate service provision or incorrect arrangements. Value-added services temporarily purchased by users within the lounge via a mobile app (such as meeting room usage time) often cannot be automatically synchronized to the offline scheduling system and still require manual activation. This can easily create a fragmented customer experience due to the disconnect between real-time benefit increments and offline resources. Therefore, there is an urgent need in the market for a new method for automatic user identity verification and real-time synchronization of service benefits for VIP lounges. Summary of the Invention
[0003] The purpose of this invention is to provide a method for automatic user identity verification and real-time synchronization of service rights for VIP lounges. This addresses the problems in existing traditional service systems during user identity verification, such as the inability to perceive dynamic changes in user rights in real time, difficulty in identifying multiple user rights and intelligently matching the optimal service option, and the lack of contextual coherence maintenance for the complete service journey across nodes, leading to delayed rights realization, service resource mismatch, and fragmented user experience. The specific technical solution is as follows: This invention provides a method for automatic user identity verification and real-time synchronization of service rights for VIP lounges, including: S1. Multimodal identity feature acquisition and data preprocessing: User facial images are acquired through a dual-spectrum face recognition camera deployed at the entrance of the VIP lounge, and user gait features are captured through millimeter-wave radar; the acquired data is then preprocessed. S2. Dynamic rights feature extraction and encrypted transmission: Facial feature vectors and gait cycle features are extracted from preprocessed data, weighted and fused to generate hybrid feature vectors, the feature data is encrypted using an encryption algorithm, and a timestamp is attached. S3. Blockchain Identity Verification and Rights Status Inquiry: Upload the hash value of the encrypted feature to the blockchain, compare it with the pre-stored identity anchor on the chain through smart contracts, and query the user's multi-source rights status. S4. Multi-threshold decision-making and anomaly handling: Based on identity matching degree and rights status, execute hierarchical decisions, including triggering fast-pass process, initiating multi-factor enhanced verification, or adopting security interception mechanism; S5. Real-time rights synchronization and resource scheduling: After verification, the rights update instruction is broadcast to the terminals in the hall through the message queue, and resource scheduling is performed.
[0004] Furthermore, the multimodal identity feature acquisition in S1 includes continuously acquiring data at a rate of 25 frames / second and aligning the multi-source data streams through a time synchronization module; data preprocessing includes using an adaptive histogram equalization algorithm to enhance the contrast of facial images; and using a Kalman filter with a process noise covariance of 0.01 and an observation noise covariance of 0.001 to eliminate environmental interference for gait data.
[0005] Furthermore, in S2, the facial feature vector is extracted as a 512-dimensional ArcFace embedding, and the gait cycle feature is extracted as a 128-dimensional GaitNet sequence. During weighted fusion, the facial feature vector weight is 0.6, and the gait cycle feature weight is 0.4, generating a 640-dimensional hybrid feature vector. The encrypted feature data uses the national cryptographic algorithm SM4 with a key length of 256 bits and adopts CBC block mode. The additional timestamp is generated by quantum random numbers with an accuracy of 1 millisecond to prevent replay attacks. In S3, the hash value of the encrypted feature is calculated using the SHA-256 algorithm and then uploaded to the consortium blockchain built on Hyperledger Fabric 2.4. The consortium blockchain adopts the BFT-SMaRt consensus mechanism. The multi-source equity status includes airline alliance level, bank privileges and temporary upgrade permissions, and the validity of the equity is verified through smart contracts, including checking the expiration time and usage limit.
[0006] Furthermore, the specific rules for hierarchical decision-making in S4 include: if the identity matching degree is ≥98% and the rights status is valid, a fast-track process is triggered; if the identity matching degree is in the range of 90%-98% and no abnormal credentials are detected, multi-factor enhanced verification is initiated; if the identity matching degree is <90% or credential tampering or invalid rights status is detected, a security interception mechanism is adopted.
[0007] Furthermore, initiating multi-factor enhanced validation in S4 includes the following steps: SA41. Retrieve user historical behavior data to generate a behavior fingerprint. The retrieved behavior data includes the access frequency and average dwell time in the last 30 days. The generated behavior fingerprint is encoded using a 256-bit Bloom filter. SA42. Read the anti-counterfeiting mark of the user's electronic certificate through the NFC card reader. The NFC card reader operates at a frequency of 13.56MHz and a transmission rate of 424kbps. The anti-counterfeiting mark read is a unique identification code encrypted with AES-128. SA43, integrate behavioral fingerprint and electronic voucher data, and perform secondary verification using a support vector machine classifier with kernel function RBF and penalty factor C=1.0; SA44. If the confidence level of the secondary verification is ≥95%, update the rights status and authorize access.
[0008] Furthermore, the security interception mechanism employed in S4 includes the following steps: SB41. Immediately freeze all rights associated with this identity and trigger an audible and visual alarm; SB42. Encrypt and upload the abnormal features to the audit chain. The abnormal features include biometric data that triggered the event, device MAC address, and geolocation information. SB43. Send a Level-1 security alert to the administrator terminal; SB44. Generate a disposal log and store the log in the IPFS distributed file system.
[0009] Furthermore, the message queue in S5 uses a Kafka cluster with a throughput of no less than 50,000 messages per second; the in-hall terminals include smart seats, catering robots, and displays; the rights update instructions include service type, resource quota, and timeliness parameters, where service type includes priority dining rights and exclusive rest area, resource quota includes free dining times, and timeliness parameters include a stay countdown. If a user's location change is detected in S5, service resources are dynamically adjusted, including the following steps: SA51. Predict the next requirement based on the user's movement trajectory. The prediction uses an LSTM model with 64 hidden layer units and a prediction step size of 3. SA52, Preheat the target area equipment. The preheating operation includes adjusting the air conditioning temperature to 22±0.5℃ and heating the coffee machine to 85℃. SA53, resource allocation strategy through edge computing nodes; SA54. After verifying the resource conflict rate, perform scheduling. The prerequisite for performing scheduling is that the verified resource conflict rate is lower than the threshold of 5%. If a sudden change in the status of rights is detected in S5, an emergency authorization mechanism is employed, including the following steps: SB51. Retrieve the latest permissions from the rights database; SB52. Compare historical permissions to generate a list of differences; SB53. Synchronize to all terminals using a differential update algorithm, with a data compression rate of no less than 70% for the differential update algorithm; SB54. Record a change of rights log, including timestamp, reason for change, and information of authorized personnel.
[0010] Furthermore, the method also includes: S6, service closed-loop audit and key rotation: after the service is completed, an audit event is generated, its hash value is anchored to the blockchain, and the encryption key is updated periodically; S7. System performance optimization and disaster recovery backup: Adopt a dual-active server architecture and perform regular data backups; In S6, audit event logs include service content, time consumption, and resource consumption information; the block interval of the blockchain is set to 10 minutes. If the amount of audited data reaches a threshold in S6, a batch anchoring strategy is adopted, with the threshold set at 1GB, including the following steps: SA61. Divide the audit data into blocks according to time windows, with each time window being 5 minutes and each data block not exceeding 100MB in size. SA62, Calculate the root hash of each block's Merkle tree; SA63. Write root hashes to the blockchain in batches, with no more than 10 root hashes written in a single batch. SA64. After verifying the number of block confirmations, delete the local cache. You need to wait for the number of block confirmations to reach or exceed 6. In step S7, the heartbeat detection interval of the dual-active server architecture is 1 second, and the failover delay is no more than 3 seconds; incremental backups are performed every day from 2:00 to 3:00 AM, with a data compression rate of no less than 60%.
[0011] Furthermore, the key rotation cycle in S6 is 24 hours, and the key rotation includes the following steps: SB61. Generate new key pairs based on elliptic curve cryptography, using secp256k1 as the elliptic curve. SB62. Re-encrypt and migrate historical data permissions through a proxy; SB63. New and old keys are verified in parallel, with the overlap period of parallel verification not exceeding 5 minutes; SB64. Destroy the old key and overwrite the storage area. The overwrite operation involves repeatedly writing random data three times. Step S6 also includes a new unified service management platform key collaborative update mechanism, which is executed synchronously with the 24-hour key rotation cycle. Key generation uses the elliptic curve cryptography algorithm based on the secp256k1 elliptic curve. Historical data permission migration uses the proxy re-encryption technology. The overlap period of parallel verification of new and old keys is controlled within 5 minutes. The old key destruction uses the overwrite storage method of repeatedly writing random data 3 times.
[0012] Furthermore, S6 also includes building a unified service management and control platform and an operation and maintenance monitoring platform to monitor identity synchronization status, rights data synchronization accuracy and full-domain operation and maintenance indicators in real time, linking anomaly monitoring modules, setting three-level alarm thresholds, and controlling the administrator terminal push response time limit to within 5 seconds. S6's global anomaly collaborative handling includes: identity synchronization anomaly handling, where when cross-platform identity verification fails, the corresponding identity's rights and permissions are frozen, triggering a multi-source identity re-comparison; after successful comparison, permissions are unlocked and the identity log is synchronously updated to the audit chain; rights synchronization anomaly handling, where when the time difference between the last update time of a rights record and the latest record in the data lake exceeds a threshold, a data backtracking mechanism is triggered, obtaining the latest valid snapshot data from the data lake to overwrite the anomaly record, and calling the rights verification interface for secondary confirmation; and service orchestration anomaly handling, where when command issuance fails, authorization commands are automatically retried, with a retry count of 3 times and an interval of 100ms; if the retry fails, a backup service link is switched.
[0013] A computer device includes a processor and a memory, the memory storing instructions executable by the processor, characterized in that the instructions, when executed by the processor, implement the method described above.
[0014] A computer-readable storage medium having a computer program stored thereon that, when executed by a processor, implements the steps of the method.
[0015] The beneficial effects of this invention are as follows: By seamlessly collecting and fusing multimodal biometric features, a high-precision, anti-counterfeiting digital identity is constructed. Blockchain technology is used for trusted identity verification and real-time rights inquiry. Based on multi-threshold intelligent decision-making, rapid passage, enhanced verification, or security interception are achieved. At the same time, through high-performance message bus and edge computing, rights instructions are synchronized and resources are scheduled in seconds. Ultimately, it replaces the traditional manual verification mode. Under the premise of ensuring extremely high security, it achieves seamless passage in seconds and instant redemption of dynamic rights, significantly improving the operational efficiency, accuracy, and consistency of user experience of VIP services. Meanwhile, through a full-link security closed loop and system collaborative operation, data security and service stability are guaranteed.
[0016] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. Attached Figure Description
[0017] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings: Figure 1 This is a flowchart of a method for automatic user identity verification and real-time synchronization of service rights for VIP lounges, according to an embodiment of this application. Detailed Implementation
[0018] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.
[0019] like Figure 1 As shown, this embodiment of the invention proposes a method for automatic user identity verification and real-time synchronization of service rights for VIP lounges, including the following steps: S1. Multimodal identity feature acquisition and data preprocessing: User facial images are acquired by a dual-spectrum face recognition camera deployed at the entrance of the VIP lounge, and user gait features are captured by millimeter-wave radar.
[0020] Specifically, the acquisition device continuously acquires data at a rate of 25 frames per second, aligning the multi-source data streams through a time synchronization module. Data preprocessing includes enhancing the contrast of facial images using an adaptive histogram equalization algorithm with a grid size of 8×8; and eliminating environmental interference by using a Kalman filter with a process noise covariance of 0.01 and an observation noise covariance of 0.001 for gait data.
[0021] S2. Dynamic rights feature extraction and encrypted transmission: Facial feature vectors and gait cycle features are extracted from preprocessed data, and a 640-dimensional hybrid feature vector is generated by weighted fusion. The feature data is encrypted using the national cryptographic SM4 algorithm, and a timestamp generated by quantum random number is attached to prevent replay attacks.
[0022] Specifically, the facial feature vector is extracted as a 512-dimensional ArcFace embedding, and the gait cycle feature is extracted as a 128-dimensional GaitNet sequence. The facial feature vector weight is set to 0.6 and the gait cycle feature weight is set to 0.4. Weighted fusion is performed to generate a 640-dimensional hybrid feature vector. The feature data is encrypted using the national cryptographic SM4 algorithm with a key length of 256 bits and CBC block mode. A timestamp generated by quantum random numbers with an accuracy of 1 millisecond is added to prevent replay attacks.
[0023] S3. Blockchain Identity Verification and Rights Status Inquiry: The encrypted feature hash value (SHA-256) is uploaded to the consortium blockchain, and the identity anchor points pre-stored on the chain are compared through smart contracts; the query process simultaneously retrieves the user's multi-source rights status and verifies the validity of the rights.
[0024] Specifically, the encrypted feature hash value (SHA-256) is uploaded to a consortium blockchain built on Hyperledger Fabric 2.4 for verification. This blockchain uses the BFT-SMaRt consensus mechanism to ensure high consistency and fault tolerance. The multi-source stake status includes airline alliance level, bank privileges and temporary upgrade permissions. Verifying the validity of stakes includes checking expiration time and usage limit.
[0025] S4. Multi-threshold decision-making and anomaly handling: The system performs the following tiered decision-making based on identity matching degree and credential status: Specifically, if the identity matching degree is ≥98% and the rights status is valid, a fast-pass process is triggered; if the matching degree is in the 90%-98% range and no credential anomaly is detected, multi-factor enhanced verification is initiated; if the identity matching degree is <90% or credential tampering or invalid rights status is detected, a security interception mechanism is adopted.
[0026] Because real-world scenarios may experience interference such as sudden changes in lighting or abnormal user posture, the verification strategy needs to be dynamically adjusted.
[0027] In step S4, if the matching degree is between 90% and 98%, multi-factor enhanced verification is used, and the specific steps are as follows: SA41: Retrieves user historical behavior data to generate a behavioral fingerprint. The retrieved behavioral data includes the frequency of visits and average dwell time over the past 30 days. The generated behavioral fingerprint is encoded using a 256-bit Bloom filter. SA42: Reads the anti-counterfeiting mark of the user's electronic voucher via an NFC reader. Specifically, the NFC reader operates at a frequency of 13.56MHz and a transmission rate of 424kbps. The anti-counterfeiting mark read is a unique identification code encrypted with AES-128. SA43: Integrates behavioral fingerprint and electronic voucher data, and uses a support vector machine classifier with kernel function RBF and penalty factor C=1.0 for secondary verification; SA44: If the confidence level of the secondary verification is ≥95%, update the rights status and authorize access.
[0028] The auxiliary verification process can be completed within 3 seconds.
[0029] In step S4, if the matching degree is less than 90% or credential tampering is detected, a security interception mechanism is employed. The credential tampering is determined based on hash value mismatch. The specific steps are as follows: SB41: Immediately freeze all rights associated with this identity and trigger an audible and visual alarm; SB42: Encrypt and upload the abnormal features to the audit chain; the abnormal features include biometric data that triggered the event, device MAC address, and geographic location information; SB43: Send a Level-1 security alert to the administrator terminal; SB44: Generate a disposal log; specifically, the log will be stored in the IPFS distributed file system.
[0030] S5. Real-time rights synchronization and resource scheduling: After verification, the rights update instruction is broadcast to the in-hall terminals via a message queue. The in-hall terminals include smart seats, catering robots and displays. The instruction includes service type, resource quota and timeliness parameters. Service type includes priority meal selection right, exclusive rest area, etc.; resource quota such as number of free meals; timeliness parameters such as stay countdown.
[0031] Specifically, the message queue uses a Kafka cluster with a throughput of no less than 50,000 messages per second.
[0032] Because user rights may change dynamically, synchronization must be achieved within seconds. These dynamic changes include scenarios such as lounge access upgrades triggered by flight delays.
[0033] In step S5, if a change in the user's location is detected (via a UWB positioning system with an accuracy of ±15cm), service resources are dynamically adjusted. SA51: Predicts the next demand based on the user's movement trajectory. Specifically, the prediction uses an LSTM model with 64 hidden layer units and a prediction step size of 3. SA52: Preheat the target area equipment. The preheating operation includes adjusting the air conditioning temperature to 22±0.5℃ and heating the coffee machine to 85℃. SA53: Resource allocation strategy through edge computing nodes; SA54: Perform scheduling after verifying the resource conflict rate. The prerequisite for performing scheduling is that the verified resource conflict rate is lower than the 5% threshold.
[0034] In S5, if a sudden change in the status of benefits is detected (such as a membership level upgrade), an emergency authorization mechanism is employed. The specific steps are as follows: SB51: Retrieve the latest permissions from the rights database; SB52: Compare historical permissions to generate a list of differences; SB53: Synchronize to all terminals via a differential update algorithm, specifically, the data compression rate of the differential update algorithm is no less than 70%; SB54: Records a change of rights log, specifically including timestamps, reasons for changes, and authorized personnel.
[0035] S6. Service closed-loop audit and key rotation: An audit event is generated after the service is completed, and its hash value is anchored to the blockchain; the audit event record includes service content, time consumption and resource consumption information; the block interval of the blockchain is set to 10 minutes.
[0036] Due to security requirements, encryption keys need to be updated regularly.
[0037] In step S6, if the amount of audited data reaches a threshold, a batch anchoring strategy is adopted. The threshold is 1GB. The specific steps are as follows: SA61: Divides audit data into blocks based on time windows. The time window is 5 minutes, and each data block size does not exceed 100MB; SA62: Calculate the root hash of each block's Merkle tree; SA63: Write root hashes to the blockchain in batches, with no more than 10 root hashes written in a single batch. SA64: Delete the local cache after verifying the number of block confirmations. Specifically, it requires waiting for the number of block confirmations to reach or exceed 6.
[0038] If the key rotation cycle is reached in step S6, a two-way verification update mechanism is adopted. The key rotation cycle is 24 hours. The specific steps are as follows: SB61: Generates new key pairs based on elliptic curve cryptography, specifically using the secp256k1 elliptic curve. SB62: Re-encrypt and migrate historical data permissions via proxy; SB63: Parallel verification of old and new keys, with an overlap period of no more than 5 minutes; SB64: Destroy the old key and overwrite the storage area. Specifically, the overwrite operation involves repeatedly writing random data three times.
[0039] S7. System performance optimization and disaster recovery backup: Adopt a dual-active server architecture and perform regular data backups; the heartbeat detection interval of the dual-active architecture is 1 second, and the failure switching delay is no more than 3 seconds; incremental backups are performed every day from 2:00 to 3:00 am, and the data compression rate is no less than 60%.
[0040] In one embodiment, the dual-spectrum face recognition camera has a resolution of 3840×2160 and acquires user facial information by simultaneously acquiring visible light and infrared light images. The millimeter-wave radar operates at a frequency of 76-81GHz and has a detection range of 0.1-15 meters.
[0041] In one embodiment, identity matching calculation includes generating an identity matching score after the smart contract compares the identity anchor points pre-stored on the chain. Specifically, the matching score calculation uses a cosine similarity algorithm, comparing the 640-dimensional hybrid feature vector generated in step S2 with the user's pre-stored baseline feature vector on the chain, and calculating the cosine value of the angle between them. The formula is similarity = (A·B) / (||A|| * ||B||), where A is the hybrid feature vector collected in real time, and B is the pre-stored baseline feature vector on the chain. The calculated similarity value ranges from [0, 1], and converting it into a percentage form is the identity matching score.
[0042] The principles and effects of the above embodiments are as follows: This invention constructs a high-precision, anti-counterfeiting digital identity through the seamless collection and fusion of multimodal biometric features (facial and gait); it utilizes blockchain technology (consortium blockchain) for trusted identity verification and real-time querying of multi-source, dynamic rights status; based on a multi-threshold intelligent decision-making mechanism, it achieves rapid passage, assisted verification, or proactive security interception; through a high-performance message bus and edge computing, it synchronizes and schedules verified rights instructions to various service terminals in real time and accurately, while constructing a full-link security closed loop from data encryption and service auditing to key rotation. Its beneficial effects are that it replaces the traditional manual verification mode, achieving seamless passage in seconds and instant redemption of dynamic rights while ensuring extremely high security, significantly improving the operational efficiency, accuracy, and user experience consistency of VIP services.
[0043] In one embodiment, the multimodal identity feature collection and data preprocessing also includes building a unified identity and unified service management platform, using the generated 640-dimensional hybrid feature vector as the core identity anchor, and synchronously connecting to airline frequent flyer systems, bank customer management systems, and third-party service platform account systems; the data preprocessing also includes supplementing the collection of user-reserved fingerprints and voiceprints as alternative biometric features (not participating in the generation of the 640-dimensional hybrid feature vector, but only activated when the main feature verification is abnormal), combining the user's real-name information and account identifiers of each platform, generating a 128-bit globally unique digital identity ID encoded with UUID v4, which is bound to the local identity identifier of the VIP lounge through the identity association interface to achieve bidirectional synchronous mutual recognition of single-point identity and global identity; the activation logic of alternative biometric features is that when the main feature matching degree of face and gait is in the range of 90%-98%, they participate in multi-factor enhanced verification together with behavioral fingerprints and electronic vouchers; when the main feature matching degree is <90%, they are not used as an admission basis alone, but only for anomaly tracing.
[0044] Furthermore, the multimodal identity feature acquisition and data preprocessing also includes identity normalization operations, specifically including the following: A string similarity algorithm is used to establish a mapping between local identity identifiers and multi-platform accounts. Specifically, the "name" and "ID number" attributes of the local identity identifier are extracted and matched with the corresponding attributes of each platform account using the Jaro-Winkler algorithm. If the similarity exceeds 95%, a mapping relationship is established, and the mapping rules are written into the consortium blockchain smart contract. Cross-platform identity feature collaborative training is performed using the FedAvg federated learning framework. The specific steps are as follows: each platform node uses its locally stored user identity feature data as training samples; the feature data is a 512-dimensional ArcFace embedding; the central server aggregates the model weight parameters uploaded by each node in each iteration; the identity unified service management platform server initializes each federated learning node using a pre-trained ArcFace model as the baseline model, and sets the iteration count to 50 and the learning rate to 0.01 for training. Deploy a unified identity authentication gateway that supports the OAuth2.0 / OpenID Connect protocol, directly connect to the Hyperledger Fabric 2.4 consortium blockchain identity verification node, realize single sign-on, control the identity authentication response time within 300ms, and control the cross-platform identity synchronization accuracy within ±50ms.
[0045] The multimodal identity feature collection and data preprocessing also includes a new identity lifecycle management module. This module works in conjunction with the audit module to record the entire process of identity registration, activation, change, and cancellation. The logs are hashed using the national cryptographic SM3 algorithm and then anchored to the consortium blockchain. A new identity management smart contract is linked with the identity verification contract, and identity change logs are synchronously pushed to the administrator terminal.
[0046] In one embodiment, the dynamic rights feature extraction and encrypted transmission also includes building a unified rights data service management platform. This unified service management platform includes three sub-modules: rights metadata management, real-time data synchronization, and rights feature extraction. It uses multi-source rights data sources and interface formats such as airline alliance levels, bank privileges, and temporary upgrade permissions that have been connected to expand the scope of rights collection to all travel scenarios such as ground transportation and hotel booking.
[0047] The rights and benefits metadata management module also includes defining a standardized rights and benefits model. This model covers six core fields: rights and benefits type, applicable scenarios, validity period, number of uses, priority, and redemption rules. The VIP lounge-related rights and benefits fields that have already been covered can be directly reused, and the fields remain compatible, realizing unified adaptation and classification management of rights and benefits across the entire domain. The classification rules are synchronized to the rights and benefits management module.
[0048] The real-time data synchronization also includes capturing benefit change data from source systems (such as MySQL) that support database logs using Debezium-based CDC technology. This is achieved by collecting the binlog of the `benefits_table` from the Debezium connector. For source systems that only provide an API, a scheduled task calls their `GetBenefitUpdates` interface every 30 seconds to retrieve change data. All change data is converted to a unified Avro format and then sent to the Kafka cluster. Data storage uses Iceberg format, and a data consistency verification module ensures that benefit data is not lost and is consistent with the benefit status in real time. This verification module compares the benefit status on the unified service management platform with the real-time query results from the source system's API; if inconsistencies are found, the source system's status is used for correction.
[0049] The extraction of rights and benefits features also includes structured parsing of rights and benefits data, prioritizing the extraction of already covered rights and benefits features, adding new full-domain rights and benefits scenario tags, continuing the weighted scoring approach, setting a user level weight of 0.7 and a rights and benefits value weight of 0.3, generating a 256-dimensional rights and benefits feature vector and binding it to the full-domain digital identity ID, and synchronizing it to the rights and benefits database through a data interface to achieve bidirectional access to full-domain rights and VIP lounge rights.
[0050] In a preferred embodiment, the blockchain identity verification and rights status query also includes building a full-journey service orchestration engine. This engine connects to all-domain scenario systems such as flight dynamics system, check-in system, and security check system, deeply integrates with VIP lounge service system, and reuses TCP / IP and MQTT dual protocol connection methods.
[0051] The blockchain identity verification and rights status query also includes collecting user's entire journey data, integrating user biometrics, gait data, UWB positioning data (accuracy ±15cm), and behavioral data such as access frequency and average stay time in the last 30 days, to build a full journey context engine. The context data is synchronized to the service scheduling module in real time, solving the problem of service context breakage that can easily be caused by only covering the VIP lounge scenario.
[0052] The construction of the full journey context engine also includes LSTM time series data modeling, setting 128 hidden layer units and a prediction step size of 5, reusing the core logic and training weights of LSTM demand prediction, expanding the prediction dimension, associating the user's full domain identity, journey nodes, rights status and retained historical behavior data, generating a full journey service context with a data update frequency of 1 second / time, and synchronously pushing the prediction results to the terminal scheduling node.
[0053] The service orchestration engine also includes encapsulating terminal scheduling capabilities such as VIP lounge verification, smart seats, and catering robots into standardized service units, reusing terminal control interfaces and command formats, and uniformly encapsulating service capabilities such as rapid security check authorization and priority baggage check-in from various platforms. Service linkage rules are defined through the BPEL process orchestration language, supporting visual configuration and dynamic adjustment, and enabling the direct issuance of full-domain service commands to terminal devices.
[0054] In a preferred embodiment, the multi-threshold decision-making and anomaly handling further includes using the NSGA-Ⅲ multi-objective decision-making algorithm based on full-domain digital identity, integrated rights data, and full-journey context to achieve intelligent selection of cross-system rights. Specifically, the multi-objective optimization problem is defined as follows: the decision variable is a binary selection variable xi, which represents whether to recommend rights i; the objective function is to simultaneously optimize the following three objectives: first, the fit objective, maximizing ∑(xi×match_scorei), where match_scorei is calculated based on the matching degree between rights i and the current scenario label; second, the preference objective, maximizing ∑(xi×preference_scorei), where preference_scorei is calculated based on the frequency of the user's historical use of rights i; and third, the value objective, maximizing ∑(xi×monetary_valuei), where monetary_valuei is the monetary value of rights i. The constraint condition of this problem is ∑xi≤3 (maximum of 3 rights recommended), and xi∈{0,1}. The algorithm is set to iterate 100 times to solve the problem.
[0055] The cross-system intelligent optimization of rights and interests also includes the following operations: Trip Node Recognition: The full journey context engine determines the user's current stage, which includes the VIP lounge access scenario. It generates feature tags compatible with scenario identifiers to achieve seamless switching between the full-domain scenario and the VIP lounge scenario. Stake Filtering: Available stakes are filtered based on scenario tags. The Hyperledger Fabric 2.4 consortium blockchain verification mechanism and BFT-SMaRt consensus mechanism are reused. New stake rule verification logic is embedded in the smart contract to exclude expired or overused stakes. Verification results are synchronized bidirectionally. Multi-dimensional scoring: The selected benefits are scored in three dimensions: suitability, preference, and value. The weighted summation logic is reused, and the comprehensive score is calculated by setting three equal weights. The preference score takes priority to refer to the retained user behavior data to maintain a consistent scoring standard. Optimal benefits output: Select the benefits with the highest overall score. If there are benefits with the same score, prioritize recommending the benefit types that users use frequently. Generate benefit usage suggestions and push them to the user's terminal. Support one-click confirmation of use. At the same time, synchronize with the VIP lounge service system and benefit management module to achieve two-way retention of benefit usage records.
[0056] The anomaly handling also includes a new multi-source rights conflict resolution mechanism. It follows the core idea of conflict handling, optimizes the conflict resolution rules to prioritize high priority > high user preference > high rights value, embeds the conflict resolution logic into the rights handling module, controls the response time to within 500ms, and pushes the processing results to the administrator terminal synchronously.
[0057] In a preferred embodiment, the real-time rights synchronization and resource scheduling also include the service orchestration engine automatically triggering the corresponding service unit linkage after the user confirms the use of rights, and issuing authorization instructions to each system terminal through standardized APIs. The authorization channel and instruction format are directly reused for the VIP lounge scenario, without the need to add new authorization interfaces. The authorization instructions are synchronized to the rights management module to ensure that the rights status of both parties is consistent, and the rights usage records share the audit log.
[0058] The real-time rights synchronization also includes continuing the national cryptographic SM4 encryption transmission and blockchain hash verification technology; reusing edge computing nodes and adding multi-scenario deployments to keep the latency within 10ms, and sharing computing resources with edge scheduling nodes; continuing UWB positioning technology, reusing positioning devices and data to achieve user location tracking and precise service scheduling in all scenarios, and bidirectionally synchronizing positioning data to the location management module.
[0059] The resource scheduling also includes a new itinerary anomaly adaptation mechanism. When itinerary anomalies such as flight delays are detected, the full journey context engine triggers rights adaptation adjustments, reuses the core logic of emergency authorization and emergency handling module, automatically filters rights that are adapted to the delay scenario, including the right to use the VIP lounge for an extended period, generates an adjustment plan and pushes it to the user, and merges and retains the emergency handling log and the emergency log.
[0060] In a preferred embodiment, the service closed-loop audit and key rotation also includes building a unified service management and control platform operation and maintenance monitoring platform to monitor the identity synchronization status, rights data synchronization accuracy and other full-domain operation and maintenance indicators in real time, deeply linking with the anomaly monitoring module, sharing monitoring terminals, reusing audible and visual alarm parameters (85dB, red light wavelength 650nm), optimizing the alarm response mechanism, controlling the administrator terminal push response time limit within 5 seconds, setting three-level alarm thresholds, realizing collaborative monitoring and unified alarms for full-domain anomalies and VIP room single-point anomalies, and displaying alarm information according to alarm classification standards.
[0061] The service closed-loop audit also includes collaborative handling of anomalies across the entire domain, as detailed below: Identity synchronization anomaly handling: When an identity synchronization anomaly occurs, such as cross-platform identity verification failure, the rights and permissions of the corresponding identity are frozen, triggering a multi-source identity re-comparison. The comparison process reuses the multimodal feature comparison logic and matching degree threshold. After the comparison is successful, the permissions are unlocked and the identity log is synchronously updated to the audit chain and stored in conjunction with the audit data. Handling of rights synchronization anomalies: When the time difference between the last update time of a rights record and the latest record in the data lake exceeds a threshold (e.g., 1 hour), a data backtracking mechanism is triggered. This mechanism retrieves the latest valid snapshot data of the rights within the last hour from the data lake to overwrite the abnormal records in the unified service management platform database. It also calls the rights verification interface for secondary confirmation to ensure data consistency. The data verification algorithm is reused to verify the rights usage records, corrects the abnormal data, and synchronizes it to all related platforms to ensure consistency with the rights data. The data correction log is synchronously retained in the audit module. Service orchestration anomaly handling: When service orchestration anomalies such as command issuance failure occur, the authorization command will be automatically retried. The retry count is set to 3 times with an interval of 100ms. If the retry fails, the backup service link will be switched. At the same time, the IPFS distributed storage will be reused to record the anomaly details to the audit chain. The anomaly handling process follows the administrator approval mechanism.
[0062] The key rotation also includes a new unified service management platform key collaborative update mechanism, which is executed synchronously with the 24-hour key rotation cycle to ensure that the entire system and key management are consistent. Key generation uses the elliptic curve cryptography algorithm based on the secp256k1 elliptic curve, historical data permission migration uses proxy re-encryption technology, the overlap period of parallel verification of old and new keys is controlled within 5 minutes, and the old key destruction uses the overwrite storage method of repeatedly writing random data 3 times.
[0063] In a preferred embodiment, the system performance optimization and disaster recovery backup also includes deploying three unified service management platforms using a distributed cluster architecture, co-constructing a full-domain dual-active system with a dual-active server architecture, and sharing a heartbeat detection module. The identity unified service management platform and the rights data unified service management platform are each deployed with 3 nodes, and the service orchestration engine is deployed with 4 nodes. The heartbeat detection interval between nodes is 500ms. In coordination with the heartbeat detection mechanism (interval of 1s), the failure switching delay is controlled within 2s, ensuring that the failure of any node in the full-domain system and the VIP room system does not affect the normal operation of the other system.
[0064] The disaster recovery backup also includes reusing backup strategies and expanding the backup scope, sharing backup equipment and storage resources, performing a full backup every day from 1:00 to 2:00 AM, which includes data from the three unified service management platforms and system data, performing incremental backups every day from 2:00 to 3:00 AM, with the incremental backup data compression rate controlled at over 65%, and storing backup data in an off-site disaster recovery center more than 100km away from the main center, building redundancy together with the backup data, continuing data destruction and secure storage standards, and maintaining consistency in the backup and recovery process.
[0065] The system performance optimization also includes optimizing high-concurrency processing capabilities through Nginx and Keepalived load balancing. A weighted round-robin allocation strategy is adopted, working in conjunction with the load balancing module, to cover peak concurrency scenarios (over 500 users / hour) and extend to peak concurrency scenarios across the entire domain (over 2000 users / hour). This achieves a global identity authentication response time of less than 500ms, a rights selection response time of less than 800ms, a service linkage success rate of over 99.95%, and a rights synchronization accuracy rate of over 99.98%. Dynamic resource allocation ensures that service performance is not affected and avoids resource contention.
[0066] This preferred embodiment reuses core technology assets, only expanding software modules and interfaces to minimize integration costs. At the same time, it achieves unified identity across all domains, real-time fusion of multi-source rights and interests, and linkage of services throughout the entire journey. It effectively solves the pain points of services in uncovered scenarios across all domains. Moreover, the system is seamlessly connected and operates collaboratively, ensuring data security and operational stability, and meeting the intelligent and integrated needs of all-domain travel services.
[0067] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the systems, devices, and units described above is explained.
[0068] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.
Claims
1. A method for automatic user identity verification and real-time synchronization of service rights for VIP lounges, characterized in that: include: S1. Multimodal identity feature acquisition and data preprocessing: User facial images are acquired by a dual-spectrum face recognition camera deployed at the entrance of the VIP lounge, and user gait features are captured by millimeter-wave radar; The collected data is then preprocessed. S2. Dynamic rights feature extraction and encrypted transmission: Facial feature vectors and gait cycle features are extracted from preprocessed data, weighted and fused to generate hybrid feature vectors, the feature data is encrypted using an encryption algorithm, and a timestamp is attached. S3. Blockchain Identity Verification and Rights Status Inquiry: Upload the hash value of the encrypted feature to the blockchain, compare it with the pre-stored identity anchor on the chain through smart contracts, and query the user's multi-source rights status. S4. Multi-threshold decision-making and anomaly handling: Based on identity matching degree and rights status, execute hierarchical decisions, including triggering fast-pass process, initiating multi-factor enhanced verification, or adopting security interception mechanism; S5. Real-time rights synchronization and resource scheduling: After verification, the rights update instruction is broadcast to the terminals in the hall through the message queue, and resource scheduling is performed.
2. The method as described in claim 1, characterized in that, The multimodal identity feature acquisition in S1 includes continuously acquiring data at a rate of 25 frames per second and aligning multi-source data streams through a time synchronization module; Data preprocessing includes enhancing the contrast of facial images using an adaptive histogram equalization algorithm; and eliminating environmental interference by using a Kalman filter with a process noise covariance of 0.01 and an observation noise covariance of 0.001 on gait data.
3. The method as described in claim 1, characterized in that, S2 extracts facial feature vectors as 512-dimensional ArcFace embeddings and gait cycle features as 128-dimensional GaitNet sequences. During weighted fusion, the facial feature vector weight is 0.6, and the gait cycle feature weight is 0.4, generating a 640-dimensional hybrid feature vector. The encrypted feature data uses the national cryptographic algorithm SM4 with a key length of 256 bits and adopts CBC block mode. The additional timestamp is generated by quantum random numbers with an accuracy of 1 millisecond to prevent replay attacks. In S3, the hash value of the encrypted feature is calculated using the SHA-256 algorithm and then uploaded to the consortium blockchain built on Hyperledger Fabric 2.
4. The consortium blockchain adopts the BFT-SMaRt consensus mechanism. The multi-source equity status includes airline alliance level, bank privileges and temporary upgrade permissions, and the validity of the equity is verified through smart contracts, including checking the expiration time and usage limit.
4. The method as described in claim 1, characterized in that, The specific rules for tiered decision-making in S4 include: if the identity matching degree is ≥98% and the rights status is valid, a fast-track process is triggered; if the identity matching degree is in the range of 90%-98% and no abnormal credentials are detected, multi-factor enhanced verification is initiated; if the identity matching degree is <90% or credential tampering or invalid rights status is detected, a security interception mechanism is adopted.
5. The method as described in claim 1, characterized in that, Initiating multifactor enhanced validation in S4 involves the following steps: SA41. Retrieve user historical behavior data to generate a behavior fingerprint. The retrieved behavior data includes the access frequency and average dwell time in the last 30 days. The generated behavior fingerprint is encoded using a 256-bit Bloom filter. SA42. Read the anti-counterfeiting mark of the user's electronic certificate through the NFC card reader. The NFC card reader operates at a frequency of 13.56MHz and a transmission rate of 424kbps. The anti-counterfeiting mark read is a unique identification code encrypted with AES-128. SA43, integrate behavioral fingerprint and electronic voucher data, and perform secondary verification using a support vector machine classifier with kernel function RBF and penalty factor C=1.0; SA44. If the confidence level of the secondary verification is ≥95%, update the rights status and authorize access.
6. The method as described in claim 1, characterized in that, The security interception mechanism employed in S4 includes the following steps: SB41. Immediately freeze all rights associated with this identity and trigger an audible and visual alarm; SB42. Encrypt and upload the abnormal features to the audit chain. The abnormal features include biometric data that triggered the event, device MAC address, and geolocation information. SB43. Send a Level-1 security alert to the administrator terminal; SB44. Generate a disposal log and store the log in the IPFS distributed file system.
7. The method as described in claim 1, characterized in that, The message queue in S5 uses a Kafka cluster with a throughput of no less than 50,000 messages per second; the in-hall terminals include smart seats, catering robots and displays; the rights update instructions include service type, resource quota and timeliness parameters, where service type includes priority meal selection right and exclusive rest area, resource quota includes free meal times, and timeliness parameters include stay countdown; If a user's location change is detected in S5, service resources are dynamically adjusted, including the following steps: SA51. Predict the next requirement based on the user's movement trajectory. The prediction uses an LSTM model with 64 hidden layer units and a prediction step size of 3. SA52, Preheat the target area equipment. The preheating operation includes adjusting the air conditioning temperature to 22±0.5℃ and heating the coffee machine to 85℃. SA53, resource allocation strategy through edge computing nodes; SA54. After verifying the resource conflict rate, perform scheduling. The prerequisite for performing scheduling is that the verified resource conflict rate is lower than the threshold of 5%. If a sudden change in the status of rights is detected in S5, an emergency authorization mechanism is employed, including the following steps: SB51. Retrieve the latest permissions from the rights database; SB52. Compare historical permissions to generate a list of differences; SB53. Synchronize to all terminals using a differential update algorithm, with a data compression rate of no less than 70% for the differential update algorithm; SB54. Record a change of rights log, including timestamp, reason for change, and information of authorized personnel.
8. The method as described in claim 1, characterized in that, The method also includes: S6, service closed-loop audit and key rotation: after the service is completed, an audit event is generated, its hash value is anchored to the blockchain, and the encryption key is updated regularly; S7. System performance optimization and disaster recovery backup: Adopt a dual-active server architecture and perform regular data backups; In S6, audit event logs include service content, time consumption, and resource consumption information; the block interval of the blockchain is set to 10 minutes. If the amount of audited data reaches a threshold in S6, a batch anchoring strategy is adopted, with the threshold set at 1GB, including the following steps: SA61. Divide the audit data into blocks according to time windows, with each time window being 5 minutes and each data block not exceeding 100MB in size. SA62, Calculate the root hash of each block's Merkle tree; SA63. Write root hashes to the blockchain in batches, with no more than 10 root hashes written in a single batch. SA64. After verifying the number of block confirmations, delete the local cache. You need to wait for the number of block confirmations to reach or exceed 6. In step S7, the heartbeat detection interval of the dual-active server architecture is 1 second, and the failover delay is no more than 3 seconds; incremental backups are performed every day from 2:00 to 3:00 AM, with a data compression rate of no less than 60%.
9. The method as described in claim 8, characterized in that, In S6, the key rotation cycle is 24 hours. Key rotation includes the following steps: SB61. Generate new key pairs based on elliptic curve cryptography, using secp256k1 as the elliptic curve. SB62. Re-encrypt and migrate historical data permissions through a proxy; SB63. New and old keys are verified in parallel, with the overlap period of parallel verification not exceeding 5 minutes; SB64. Destroy the old key and overwrite the storage area. The overwrite operation involves repeatedly writing random data three times. Step S6 also includes a new unified service management platform key collaborative update mechanism, which is executed synchronously with the 24-hour key rotation cycle. Key generation uses the elliptic curve cryptography algorithm based on the secp256k1 elliptic curve. Historical data permission migration uses the proxy re-encryption technology. The overlap period of parallel verification of new and old keys is controlled within 5 minutes. The old key destruction uses the overwrite storage method of repeatedly writing random data 3 times.
10. The method as described in claim 8, characterized in that, S6 also includes building a unified service management and control platform and an operation and maintenance monitoring platform to monitor identity synchronization status, rights data synchronization accuracy and full-domain operation and maintenance indicators in real time, linking the anomaly monitoring module, setting three-level alarm thresholds, and controlling the administrator terminal push response time to within 5 seconds. S6's global anomaly collaborative handling includes: identity synchronization anomaly handling, where when cross-platform identity verification fails, the corresponding identity's rights and permissions are frozen, triggering a multi-source identity re-comparison; after successful comparison, permissions are unlocked and the identity log is synchronously updated to the audit chain; rights synchronization anomaly handling, where when the time difference between the last update time of a rights record and the latest record in the data lake exceeds a threshold, a data backtracking mechanism is triggered, obtaining the latest valid snapshot data from the data lake to overwrite the anomaly record, and calling the rights verification interface for secondary confirmation; and service orchestration anomaly handling, where when command issuance fails, authorization commands are automatically retried, with a retry count of 3 times and an interval of 100ms; if the retry fails, a backup service link is switched.