Ride permission verification method and device, computer device, and readable storage medium

Abstract

Embodiments of the present application provide a vehicle riding permission verification method and device, computer equipment and a readable storage medium. The method comprises: reading a certificate verification mark, a permission verification time and an identity verification mark in a vehicle riding certificate corresponding to a target object; the certificate verification mark is generated by a preset permission verification device based on the permission attribute of the vehicle riding certificate, the permission verification time is determined by the sensing time of the permission verification device on the vehicle riding certificate, and the identity verification mark is determined by the permission verification device based on the matching state between the identity information of the target object and the pre-stored identity information corresponding to the vehicle riding certificate; obtaining the reading time of the vehicle riding certificate, and obtaining the vehicle riding time interval based on the reading time and the permission verification time; determining the vehicle riding permission of the target object based on the size relationship between the certificate verification mark, the vehicle riding time interval and the preset time threshold, and the identity verification mark; and controlling the subway gate based on the vehicle riding permission.

Description

Technical Field

[0001] This application relates to the field of digital payment technology, and in particular to a method, apparatus, computer equipment, and readable storage medium for verifying ride authorization. Background Technology

[0002] In urban rail transit systems, to protect the travel rights of specific groups such as the elderly and students, operators typically issue special transit cards with fare discounts (hereinafter referred to as transit cards). Cardholders can enjoy fare reductions or free rides. However, these transit cards face a widespread problem of misuse in practice, where cardholders lend their cards to others who do not meet the discount criteria. Given the large number of subway passengers and the fact that misuse can occur frequently and over a long period, this problem can lead to significant economic losses for operators.

[0003] In related technologies, verification of transit card misuse is generally conducted through backend data analysis. Specifically, a backend verification system is built to collect and analyze historical transaction data of transit cards, including information such as card swiping time, swiping location, and swiping frequency. The system uses a preset anomaly detection algorithm to analyze transaction patterns. When an abnormal pattern is detected (such as a significant deviation between the card swiping time distribution and the cardholder's historical behavioral characteristics), it is determined that the transit card is at risk of misuse, and measures such as remote card locking and blacklisting are taken for suspicious transit cards. However, this method is a post-event verification, requires the analysis of massive amounts of data, is not timely, and has low identification efficiency and accuracy. Summary of the Invention

[0004] This application proposes a method, apparatus, computer equipment, and readable storage medium for verifying travel rights, which can ensure the timeliness of travel rights verification and improve the efficiency and accuracy of verification.

[0005] To achieve the above objectives, a first aspect of this application proposes a method for verifying travel rights, the method comprising: Read the voucher verification flag, authorization verification time, and identity verification flag from the travel voucher corresponding to the target object; The voucher verification mark is generated by a preset permission verification device based on the permission attributes of the ride voucher; the permission verification time is determined by the sensing time of the ride voucher by the permission verification device; and the identity verification mark is determined by the permission verification device based on the matching status between the identity information of the target object and the pre-stored identity information corresponding to the ride voucher. Obtain the reading time of the boarding pass, and based on the difference between the reading time and the permission verification time, obtain the boarding time interval; Based on the relationship between the credential verification mark, the travel time interval and the preset time threshold, and the identity verification mark, the travel rights of the target object are determined. Based on the aforementioned travel permissions, control the subway turnstiles.

[0006] Accordingly, a second aspect of this application provides a vehicle access verification device, the device comprising: The reading module is used to read the voucher verification flag, authorization verification time, and identity verification flag from the travel voucher corresponding to the target object. The voucher verification mark is generated by a preset permission verification device based on the permission attributes of the ride voucher; the permission verification time is determined by the sensing time of the ride voucher by the permission verification device; and the identity verification mark is determined by the permission verification device based on the matching status between the identity information of the target object and the pre-stored identity information corresponding to the ride voucher. The acquisition module is used to acquire the reading time of the travel voucher and obtain the travel time interval based on the difference between the reading time and the permission verification time. The determination module is used to determine the travel permissions of the target object based on the relationship between the credential verification mark, the travel time interval and the preset time threshold, and the identity verification mark. The control module is used to control the subway turnstiles based on the passenger access permissions.

[0007] In some implementations, the ride permission includes allowing rides, and the determining module is further configured to: Obtain the preset time-efficiency threshold for the current moment, and compare the travel time interval with the preset time-efficiency threshold to obtain the comparison result; When the credential verification flag is set, the comparison result indicates that the travel time interval is less than the preset time threshold, and the identity verification flag is set, the travel permission of the target object is determined to be allowed to travel.

[0008] In some implementations, the ride permission also includes prohibiting rides, and the determining module is further configured to: When the credential verification flag is not set, the target object's travel permission is determined to be prohibited from traveling. And / or, when the travel time interval is greater than the preset time threshold, the travel permission of the target object is determined to be prohibited from traveling; And / or, when the identity verification flag is not set, the passenger's travel permission is determined to be prohibited from taking the vehicle.

[0009] In some embodiments, the ride authorization verification device further includes a fusion module for: Obtain the current station's passenger flow density parameters, time period parameters, and station location parameters; The preset time-sensitivity threshold for the current time period is obtained by weighted fusion of the passenger flow density parameter, the time period parameter, and the station location parameter.

[0010] In some embodiments, the ride authorization verification device further includes a locking module for: When the credential verification flag is set, the travel time interval is greater than the preset time threshold, and the identity verification flag is set, obtain the current historical invalid activation count of the target object; Perform an accumulation operation on the historical invalid activation counts to obtain the target invalid activation count; When the number of invalid activations of the target exceeds a preset invalid activation threshold, the ride pass corresponding to the target object is locked.

[0011] In some embodiments, the ride authorization verification device further includes a subway gate control module, used for: Read the voucher verification flag and authorization verification time from the travel voucher corresponding to the target object; Obtain the reading time of the boarding pass, and based on the difference between the reading time and the permission verification time, obtain the boarding time interval; Based on the credential verification mark and the relationship between the travel time interval and the preset time threshold, the travel rights of the target object are determined. Based on the aforementioned travel permissions, control the subway turnstiles.

[0012] In some embodiments, the ride authorization verification device further includes a ride pass locking module, used for: The target number of times the verification flag of the travel voucher is activated within the target time window; When the number of times the target is set exceeds a preset threshold, the travel voucher corresponding to the target object is locked.

[0013] Accordingly, a third aspect of the present application provides a computer device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the vehicle access verification method of any one of the embodiments of the first aspect of the present application.

[0014] Accordingly, a fourth aspect of the embodiments of this application proposes a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the vehicle access verification method of any one of the embodiments of the first aspect of this application.

[0015] This application embodiment reads the voucher verification mark, authorization verification time, and identity verification mark from the travel pass corresponding to the target object. The voucher verification mark is generated by a preset authorization verification device based on the travel pass's authorization attributes; the authorization verification time is determined by the authorization verification device's sensing time of the travel pass; and the identity verification mark is determined by the authorization verification device based on the matching status between the target object's identity information and the pre-stored identity information corresponding to the travel pass. The travel pass reading time is obtained, and the travel validity interval is calculated based on the difference between the reading time and the authorization verification time. The travel permissions of the target object are determined based on the relationship between the voucher verification mark, the travel validity interval, and a preset validity threshold, as well as the identity verification mark. Based on the travel permissions, the subway turnstile is controlled. In this way, the verification of travel permissions can be pre-processed and integrated into a real-time determination process on the turnstile side. Specifically, this method no longer relies on offline mining and analysis of massive historical transaction data in the background. Instead, it directly uses the real-time status fields (including permission validity flag, identity verification flag, and authorization timestamp) generated on-site by the permission verification device within the card swipe to complete the permission judgment, thereby avoiding processing delays caused by data collection, transmission, and modeling analysis. Simultaneously, through on-site comparison of the travel time interval with a preset time threshold, and dual verification of the card verification flag and the identity verification flag, each gate pass can independently and accurately determine the validity based on the field status obtained immediately upon card swipe, eliminating the need for anomaly identification under complex data patterns. This allows for dual verification of permission validity and identity consistency before entering the station. In summary, this application ensures the timeliness of travel permission verification and improves the efficiency and accuracy of verification. Attached Figure Description

[0016] Figure 1 This is a schematic diagram of the architecture of the ride authorization verification system provided in the embodiments of this application; Figure 2 This is a flowchart of the vehicle access verification method provided in the embodiments of this application; Figure 3 This is a flowchart of the overall process for verifying travel rights provided in the embodiments of this application; Figure 4 This is a schematic diagram of the functional modules of the vehicle access verification device provided in the embodiments of this application; Figure 5 This is a schematic diagram of the hardware structure of the computer device provided in the embodiments of this application. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0018] It should be noted that although functional modules are divided in the device schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the device or the order in the flowchart. The terms "first," "second," etc., in the specification, claims, and the aforementioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0019] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0020] In urban rail transit systems, to protect the travel rights of specific groups such as the elderly and students, operators typically issue special transit cards with fare discounts (hereinafter referred to as transit cards). Cardholders can enjoy fare reductions or free rides. However, these transit cards face a widespread problem of misuse in practice, where cardholders lend their cards to others who do not meet the discount criteria. Given the large number of subway passengers and the fact that misuse can occur frequently and over a long period, this problem can lead to significant economic losses for operators.

[0021] In related technologies, verification of transit card misuse is generally conducted through backend data analysis. Specifically, a backend verification system is built to collect and analyze historical transaction data of transit cards, including information such as card swiping time, swiping location, and swiping frequency. The system uses a preset anomaly detection algorithm to analyze transaction patterns. When an abnormal pattern is detected (such as a significant deviation between the card swiping time distribution and the cardholder's historical behavioral characteristics), it is determined that the transit card is at risk of misuse, and measures such as remote card locking and blacklisting are taken for suspicious transit cards. However, this method is a post-event verification, requires the analysis of massive amounts of data, is not timely, and has low identification efficiency and accuracy.

[0022] Based on this, embodiments of this application provide a method, apparatus, computer device, and readable storage medium for verifying travel rights, which can ensure the timeliness of travel rights verification and improve the efficiency and accuracy of verification.

[0023] The ride authorization verification method, apparatus, computer equipment, and readable storage medium provided in this application are specifically described through the following embodiments. First, the ride authorization verification system in this application is described.

[0024] Please refer to Figure 1 In some embodiments, this application provides a ride authorization verification system, including a terminal 11 and a server 12.

[0025] In some implementations, terminal 11 can be used to perform pre-processing operations such as on-site reading of travel passes, generation of verification marks, and gate control. For example, terminal 11 may include a specially designed reader / writer and a subway gate deployed in the subway entrance area.

[0026] For example, a specially designed reader / writer, acting as an access verification device, can identify the access attributes (such as whether it is a discount card) when it senses a ride pass through its built-in reading / writing program and communication module. It can also generate a pass verification flag (such as setting isEnabled to 1) based on the access attributes, generate an access verification time based on the sensing time (such as recording the current timestamp), and generate an identity verification flag (such as setting isVerified to 1) based on the visual verification by security personnel or the results of local comparison.

[0027] Furthermore, the subway turnstile, as the device for enforcing boarding permissions, can read the three flags mentioned above from the credential through its built-in card reader and controller, obtain the current reading time, calculate the boarding time interval, and comprehensively determine boarding permissions based on the relationship between the credential verification flag, the time interval and the preset time threshold, as well as the identity verification flag, thereby controlling the opening or closing of the turnstile.

[0028] In some implementations, server 12 can be used to provide pre-storage of identity information, backend support for matching verification, and necessary data recording and synchronization functions. For example, server 12 can be a cloud server or a local server cluster deployed in the subway operation data center; server 12 pre-stores pre-stored identity information (such as cardholder ID photo or identity feature code) corresponding to the travel voucher, and when terminal 11 needs to verify the matching status between the target object's identity information and the pre-stored identity information, it receives the matching request sent by terminal 11 or the identity data collected on-site, and returns the matching result by running the identity comparison algorithm to assist terminal 11 in generating an identity verification mark; in addition, server 12 can also record log information of each travel permission verification for subsequent auditing or anomaly tracing.

[0029] Specifically, when the special reader / writer corresponding to terminal 11 needs to verify the identity information of the target object, terminal 11 can send the identity information collected on-site (such as the credential identifier corresponding to the confirmation signal input by security personnel) to server 12. Server 12 queries and returns the corresponding pre-stored identity information or directly returns the matching status, so that terminal 11 can generate an identity verification mark based on the returned result. When determining boarding permissions at the gate corresponding to terminal 11, since the credential verification mark, permission verification time, and identity verification mark are all pre-written into the boarding pass, the gate can independently complete real-time verification without real-time interaction with server 12, thus ensuring the timeliness and efficiency of verification. Non-real-time data synchronization between terminal 11 and server 12 is only required in scenarios such as updating the preset time limit, synchronizing the blacklist, or uploading verification records.

[0030] The method for verifying travel rights in this application can be illustrated through the following examples.

[0031] It should be noted that in all specific embodiments of this application, when processing data related to user identity or characteristics, such as user information, user behavior data, user historical data, and user location information, user permission or consent will be obtained first. Furthermore, the collection, use, and processing of this data will comply with relevant laws, regulations, and standards. In addition, when embodiments of this application require access to sensitive personal information of users, separate permission or consent from the user will be obtained through pop-ups or redirects to confirmation pages. Only after obtaining the user's separate permission or consent will the necessary user-related data for the normal operation of the embodiments of this application be obtained.

[0032] In this embodiment, the description will focus on the ride authorization verification device, which can be integrated into a computer device. See [link to relevant documentation]. Figure 2 , Figure 2 This is a flowchart illustrating the steps of the ride authorization verification method provided in this application embodiment. Taking the ride authorization verification device specifically integrated into a terminal or server as an example, the specific process when the processor on the terminal or server executes the program instructions corresponding to the ride authorization verification method is as follows: Step 101: Read the voucher verification mark, authorization verification time, and identity verification mark from the travel voucher corresponding to the target object; Among them, the voucher verification mark is generated by the preset permission verification device based on the permission attributes of the ride voucher, the permission verification time is determined by the sensing time of the ride voucher by the permission verification device, and the identity verification mark is determined by the permission verification device based on the matching status between the identity information of the target object and the pre-stored identity information corresponding to the ride voucher.

[0033] In some implementations, in order to effectively move the verification process of discount cards forward and accurately intercept misuse without adding complex and costly biometric privacy verification systems such as facial recognition or relying on post-event data analysis to stop losses, the three independent and complementary core data fields written by a dedicated device in the ride voucher—voucher verification mark, authorization verification time, and identity verification mark—can be read to form a multi-dimensional and highly secure composite verification basis during gate verification.

[0034] The target can be a natural person who holds or uses a specific preferential fare pass, such as a passenger using a senior citizen card or student card to ride the subway, who is the direct subject of the fare pass verification.

[0035] Among them, the ride pass can be a smart card with embedded integrated circuits and data storage and logic processing capabilities, such as a new type of discounted transportation card. Its storage area contains specific fields such as isEnabled and timeEnabled, which can be used to carry and record dynamic flags and time data related to ride permissions.

[0036] The voucher verification flag can be a binary data bit stored in the travel voucher memory, such as the isEnabled field, with a value of "1" (set) or "0" (not set).

[0037] The authorization verification time can be a time string accurate to the second, such as "2026-03-29 08:15:30", which is determined by the system sensing time when the special reader activates the boarding pass.

[0038] The identity verification mark can be a binary data bit stored in the travel pass's memory, such as the isVerified field. It can be set or rejected by the security inspector after manually comparing and verifying the cardholder's facial information with the ID photo on the card, or by the security inspector visually judging whether the cardholder's facial information matches the corresponding characteristics (such as age characteristics or physical defect characteristics), and then set or rejected by the security inspector on the authorization verification device (including the security inspector's confirmation button).

[0039] The permission attribute can be feature data used to identify the type and legal status of the ride pass. For example, if the system recognizes a senior citizen card or student card and its status is normal, the special reader can determine that it belongs to the type of discount card that needs to be pre-activated. This can be used as a logical condition to trigger the write operation of the pass verification flag and the permission verification time.

[0040] The sensing time can be a system timestamp recorded by the internal clock of a specially designed reader when it successfully establishes wireless communication with the travel pass and identifies its permission attributes. For example, the current time captured by the reader immediately after the security officer presses the confirmation button can be used to accurately assign a value to the timeEnabled field in the travel pass.

[0041] The pre-stored identity information can be a personal identification mark collected and solidified on the surface or inside the card when the boarding pass is issued, such as the cardholder's ID photo printed on the card.

[0042] In some implementations, when the reader of a subway gate (e.g., a discount gate or a regular gate) senses a travel pass (such as a new type of discounted transportation card) held by a target, the gate's built-in read / write control unit first performs a read operation to retrieve the pass verification flag (e.g., the isEnabled field), the authorization verification time (e.g., the timeEnabled field), and the identity verification flag (e.g., the isVerified field) from the designated storage area of ​​the travel pass.

[0043] For example, a pre-set access verification device (i.e., a specially designed reader / writer) can be placed next to the security check area at the subway entrance. When a cardholder brings their travel voucher close to the reader / writer, the reader / writer first identifies the card's type and status: if it determines that the card is a senior citizen card, student card, or other discount card and is in normal status (not reported lost, not locked), then based on its access attributes (belonging to a discount card type that requires pre-activation), the internal logic control unit generates a setting signal, changing the value of the voucher verification flag field in the card from the default 0 to 1. For example, the specially designed reader / writer sets the isEnabled field to logical "1" by writing a data block instruction to the card. If it is not a discount card, the isEnabled field is set to logical "0", or the corresponding isEnabled field is not generated at all.

[0044] Furthermore, the generation of the authorization verification time can be synchronized with the setting of the credential verification flag. The authorization verification device can integrate a high-precision real-time clock. When the device successfully identifies the card's authorization attributes and decides to perform the activation operation, it immediately captures the current system time (accurate to the second) and writes this time string into the card's `timeEnabled` field. For example, if activation occurs at 8:15:30 AM on March 29, 2026, then `timeEnabled` will be assigned the value "2026-03-29 08:15:30". This time serves as the starting reference point for subsequent gate checks to determine if pre-swipe has timed out.

[0045] In some implementations, particularly in a low-cost approach that avoids uploading biometric privacy data, a specially designed reader has a physical confirmation button (or touch-sensitive area) on its surface. During routine security checks (such as item scanning), on-site security personnel visually verify that the cardholder's face matches the photo printed on the card. If they match, the security personnel manually press the confirmation button, and the reader then writes a command to the card, setting the isVerified field to 1.

[0046] In some implementations, to reduce the burden of manual operation, an offline face comparison module can be integrated into a specialized reader / writer. This module only needs to store the feature values ​​of the ID photo corresponding to the card (without transmitting the original image). When the cardholder activates the card, the camera captures facial features in real time, and the real-time facial features are compared with the ID photo feature values ​​locally. If a match is found, the "isVerified" status is automatically set. Since this face comparison is only deployed at the security checkpoint, in far fewer numbers than the gates throughout the station, the hardware cost is controllable and no network connection is required, avoiding large-scale biometric privacy risks and significantly reducing deployment costs, while also preventing congestion at the gates.

[0047] For example, for certain low-risk periods or sites, operators can configure specialized readers to automatically set the identity verification flag to 1 (i.e., defaulting to identity verification) while activating the credential verification flag and authorization verification time, thereby simplifying the process. Accordingly, the turnstile can only check the credential verification flag and the validity period, achieving lightweight anti-fraud measures.

[0048] By employing the above methods, during the security check before card swiping at the gate, three key verification elements—pre-activation (credential verification mark), activation validity period (authorization verification time), and manual identity confirmation (identity verification mark)—are written into the card at once. This cleverly transforms complex and expensive centralized, online biometric verification into low-cost, distributed, offline card status verification. Thus, without increasing the gate's passage time or modifying the existing gate's main structure, it provides a solid, multi-dimensional data foundation for the subsequent gate to perform efficient and accurate authorization judgments, thereby achieving a technological leap from passive post-event inspection to proactive pre-event prevention.

[0049] Step 102: Obtain the reading time of the boarding pass, and based on the difference between the reading time and the authorization verification time, obtain the boarding time interval.

[0050] In some implementations, in order to quickly and accurately determine whether a single card swipe request is still within the valid period of pre-activation on the local gate without relying on real-time background communication and complex behavior analysis algorithms, the local reading time of the card swipe at the gate can be obtained and the difference between it and the permission verification time stored in the card can be calculated to obtain an objective and quantitative travel time interval. This effectively avoids the situation where the cardholder passes the verification but has to wait for a long time for someone else to arrive at the gate and then hand it over to someone else to use. At the same time, it provides a direct and tamper-proof timing basis for subsequent determination of whether the card swipe has expired.

[0051] The reading time can be the timestamp recorded by the local clock system of the subway gate when the reader on the subway gate establishes a communication link with the ticket and successfully initiates a data reading operation, such as "March 29, 2026 08:18:30", which can be used as the time endpoint for calculating the travel time interval.

[0052] The travel time interval can be the difference between the reading time and the authorization verification time, such as 3 minutes and 20 seconds. It is calculated by the logic unit inside the gate and can be compared with the valid time threshold agreed upon by the operator to determine whether the card swipe has expired due to timeout.

[0053] In some implementations, when the subway turnstile's reader establishes a communication connection with the fare card and successfully initiates data reading, the turnstile's built-in clock module (usually synchronized with the turnstile controller, or directly using the reader chip's system timer) records the current time as the fare card reading time. For example, when the card approaches the turnstile's sensing area, the reader emits a radio frequency field and completes card anti-collision identification, immediately capturing the system clock value, such as "March 29, 2026, 08:18:30". This reading time and the authorization verification time stored in the card (e.g., "2026-03-29 08:15:30") are both based on the same time reference (such as the turnstile clock or the BeiDou / Network time synchronized in the background) to ensure comparability.

[0054] After obtaining the reading time, the gate's logic control unit calculates the time difference between the reading time and the authorization verification time, taking its absolute value (usually the reading time is later than the authorization verification time) to obtain the boarding time interval. The calculation method can be: Boarding Time Interval = Reading Time Permission verification time. For example, if the read time is 08:18:30 and the permission verification time is 08:15:30, then the boarding time interval is 3 minutes and 0 seconds (180 seconds).

[0055] For example, in addition to directly calculating the absolute time difference, a weighted correction mechanism can be introduced. Specifically, the passenger flow density parameter of the current gate station is obtained (such as a dynamic estimate of the average gate passage interval of the gate group). When the passenger flow density is higher than a preset congestion threshold, a compensation value (e.g., extending by 5 seconds) is automatically added to the original travel time interval to obtain an updated travel time interval. This compensates for the time delay in the actual arrival of passengers at the gate caused by queuing, avoiding non-malicious timeouts caused by objective congestion. This compensation value can be dynamically adjusted according to real-time passenger flow, achieving a flexible balance between strict anti-fraud measures and user experience.

[0056] The above methods enable offline and efficient quantitative assessment of the timeliness of pre-swipe activation at the gate, eliminating the need to upload each card swipe request to the backend system for complex behavioral analysis or time comparison. This provides accurate, reliable, and unforgeable time evidence for subsequent permission judgment steps without increasing gate passage delay or consuming additional network bandwidth, thus laying a solid technical foundation for effectively intercepting circumvention methods such as pre-swipe activation followed by card transfer.

[0057] Step 103: Based on the relationship between the credential verification mark, the travel time interval and the preset time threshold, and the identity verification mark, determine the travel permissions of the target object.

[0058] In some implementations, in order to achieve accurate passage decisions locally at the gate without relying on real-time network connectivity and by comprehensively considering three independent dimensions—pre-swipe activation status, validity period, and identity verification—logic and computation can be used to jointly determine whether the credential verification flag is set, whether the travel time interval is less than a preset time threshold, and whether the identity verification flag is set, so as to uniquely determine the travel permissions of the target object, thereby completing proactive and composite interception of impersonation in a single offline card swipe operation.

[0059] Among them, the vehicle access permission can be a binary state authorization result, such as allowing or prohibiting vehicle access, which can be used as the direct instruction basis for controlling the gate to perform the action of opening and allowing or keeping closed and refusing.

[0060] In some implementations, the gate logic control unit can comprehensively determine the travel permission of a target based on the voucher verification flag read from the travel pass, the calculated travel time interval, and the identity verification flag. The specific judgment logic is as follows: when the voucher verification flag is set (e.g., value 1), the travel time interval is less than a preset time threshold (e.g., 3 minutes), and the identity verification flag is set (e.g., value 1), the travel permission is determined to be allowed, and the gate will allow passage. Conversely, if any of the above conditions are not met, the travel permission is determined to be prohibited.

[0061] For example, if the credential verification flag is 0 (not pre-swipeped), boarding is prohibited regardless of the validity period and identity verification. If the validity period is 5 minutes and the preset threshold is 3 minutes (timeout), boarding is prohibited even if the other two flags are met. Similarly, if the identity verification flag is 0 (the identity verification officer has not confirmed that the person and the card match), boarding is also prohibited. Through this three-condition and logical judgment, it is ensured that only discount cards that have been pre-activated, used within the validity period, and passed identity verification can pass through the gate.

[0062] In some implementations, the turnstiles or back-end systems can acquire passenger flow density parameters (e.g., the number of people queuing estimated in real time by the average gate interval of the turnstile group), time period parameters (e.g., morning peak, off-peak, evening peak, or nighttime), and station location parameters (e.g., city center transfer station, residential area ordinary station, suburban terminal station), and perform weighted fusion calculations on these three parameters to obtain a preset time threshold for the current time period. For example, during the morning peak period and for stations with high passenger flow in the city center, the threshold can be set to 2 minutes to strengthen anti-fraud measures; during the off-peak period and for suburban stations, the threshold can be set to 5 minutes to increase tolerance. The weighting coefficients can be determined through historical data regression or pre-trained models, with an example formula: T=α·ρ+β·τ+γ·loc, where T is the preset time threshold, ρ is the normalized value of passenger flow density, τ is the time period coefficient, loc is the station location coefficient, and α, β, and γ are the corresponding weights.

[0063] In some implementations, the preset validity period thresholds for different preferential recipients can be personalized. During the card issuance stage, the issuer pre-writes a unique preset validity period threshold into a designated storage area of ​​the travel voucher based on the cardholder's preferential type (e.g., senior citizen, disabled person, student) and specific physical condition (e.g., degree of mobility impairment). For example, for senior citizens over 80 years old or those with lower limb disabilities, considering their slow movement, their personal threshold can be set to 10 minutes; for ordinary student cards, it can be set to 3 minutes; and for visually impaired individuals, it can be set to 8 minutes. When reading the card, the gate directly extracts this personalized threshold for validity period comparison, without relying on real-time network or background queries. This method, while ensuring basic anti-fraud requirements, also considers the actual passage needs of special groups, improving the system's inclusiveness and humanization, increasing user satisfaction, and enhancing the accuracy of card and person verification.

[0064] Through the above methods, a one-time, unavoidable logical aggregation judgment can be performed at the gate. In this way, without any back-end data comparison or secondary inquiry, the possibility of fraudulent cards that only meet a single condition (such as only completing pre-activation) being allowed to pass can be fundamentally eliminated. This provides the subway operator with a low-cost, high-efficiency, and rigid access control mechanism that strictly adheres to the principle of one person, one card, and one activation.

[0065] In some implementations, to achieve an objective and quantitative judgment on the pre-swipe activation timeliness locally at the gate, and to form a triple independent access condition with the credential verification flag and the identity verification flag, a preset timeliness threshold applicable at the current time can be obtained. The travel time interval is then numerically compared with this threshold to obtain a comparison result. Only when the credential verification flag is set, the comparison result indicates that the travel time interval is less than the preset timeliness threshold, and the identity verification flag is set, is travel uniquely permitted. This allows for rigid joint verification of the three conditions—pre-swipe activation, no timeout, and identity verification—without relying on real-time network connectivity. For example, step 103 may include: (103.a1) Obtain the preset time threshold for the current time, and compare the travel time interval with the preset time threshold to obtain the comparison result; (103.a2) When the credential verification flag is set, the comparison result indicates that the travel time interval is less than the preset time threshold, and the identity verification flag is set, the travel permission of the target object is determined to be allowed to travel.

[0066] The preset time limit can be a time length value that is dynamically configured or statically set by the subway operator based on station operation strategy, passenger flow density, time period characteristics or cardholder type (such as the elderly or disabled). For example, the preset time limit can be 3 minutes, which is the benchmark boundary for judging whether the pre-swipe activation is still valid. Only swipe requests with a travel time interval of less than this threshold are considered to be within the legal validity period.

[0067] In some implementations, the gate logic control unit first obtains the preset time limit applicable at the current moment. This preset time limit can be a fixed value pre-set by the operator (e.g., a uniform 3 minutes) or a dynamically calculated value. For example, the gate can obtain the preset time limit by reading internal configuration parameters or extracting it from the personalized storage area of ​​the travel voucher (preset with personalized thresholds for different discount recipients). Subsequently, the gate compares the calculated travel time interval with the preset time limit to obtain a comparison result. For example, if the travel time interval is 180 seconds and the preset time limit is 180 seconds, the comparison result is less than or equal to (usually less than is considered passing); if the travel time interval is 200 seconds and the threshold is 180 seconds, the comparison result is greater than. The comparison result is temporarily stored as a Boolean value (true / false) or a status code for subsequent logical judgment.

[0068] Furthermore, when the credential verification flag is set (e.g., isEnabled=1), the comparison result indicates that the travel time interval is less than the preset time threshold (i.e., no timeout), and the identity verification flag is set (e.g., isVerified=1), the gate logic control unit determines that the target person's travel permission is allowed and sends a release command to the gate execution mechanism. For example, an elderly passenger completes pre-activation at the security checkpoint (isEnabled set to 1, timeEnabled=08:15:30). After the security officer confirms the identity and ID match, isVerified is set. The passenger arrives at the gate at 08:17:20 and swipes the card. The reading time is 08:17:20, and the calculated time interval is 1 minute and 50 seconds (110 seconds). The preset time threshold for the card is 3 minutes (180 seconds). 110 < 180, all three conditions are met, the gate determines that travel is allowed and opens the gate. If any condition is not met, for example, if the passenger swipes their card at 08:19:00 (3 minutes and 30 seconds interval > 180 seconds), the comparison result will be "greater than", and even if the other two flags are set, it will still be determined that the passenger is prohibited from boarding.

[0069] For example, in addition to simple greater than / less than comparisons, a buffer mechanism can be introduced. Specifically, preset timeout thresholds are divided into hard thresholds and soft thresholds: when the travel time interval is less than the soft threshold (e.g., 3 minutes), normal passage is allowed; when the interval is between the soft threshold and the hard threshold (e.g., 5 minutes), the gate allows passage but records a lenient timeout event, which accumulates to a certain number of times, triggering an increase in risk points; when the interval is greater than the hard threshold, direct rejection is achieved. In this way, a balance can be struck between strict prevention of impersonation and tolerance for occasional minor delays.

[0070] In some implementations, the comparison result can carry the time difference value in subsequent score accumulation. For example, the longer the timeout, the higher the accumulated risk score. The specific formula is: Timeout Score = min(floor(timeout seconds / 30), 10), that is, 1 point is added for every 30 seconds of timeout, up to a maximum of 10 points. This score can be used to trigger progressive actions (such as requiring manual verification or locking vouchers).

[0071] The above methods enable the turnstile to consistently and accurately determine whether each card swipe has timed out in an offline state, avoiding ambiguity in judgment caused by human or environmental factors. At the same time, the time condition is logically ANDed with the voucher verification mark and the identity verification mark to form a triple independent verification threshold for passage. This provides an accurate and reliable judgment mechanism for the subsequent control objective of allowing only discount cards that simultaneously meet the requirements of pre-activation, no timeout, and manual verification to pass through the gate.

[0072] In some implementations, to prevent any card-swiping requests that do not meet pre-activation, timeout, or identity verification requirements from passing through the gate, the system can check whether the credential verification flag is not set, whether the travel time interval is greater than a preset time threshold, and whether the identity verification flag is not set. If any condition is not met, the travel permission can be independently or in combination prohibited, thus achieving an unconditional blocking mechanism under multiple security checks. For example, step 103 may also include: (103.b1) When the credential verification flag is not set, the passenger's travel permission is determined to be prohibited from taking the vehicle; (103.b2) and / or, when the travel time interval is greater than the preset time threshold, the travel permission of the target object is determined to be prohibited from traveling; (103.b3) and / or, when the identity verification flag is not set, determine that the target person's travel permission is prohibited from traveling.

[0073] In some implementations, the gate's logic control unit can first check the credential verification flag. If this flag is not set (e.g., a value of 0, indicating the cardholder has not completed pre-activation at the special reader / writer at the security checkpoint), then the target's travel privileges are directly determined to be prohibited, without needing to check other conditions. For example, if a passenger walks directly to the gate with a discount card and swipes it, since the card has not undergone the pre-activation process at the security checkpoint, the isEnabled field in the card retains its default value of 0. After reading the card, the gate immediately determines that travel is prohibited, keeps the gate closed, and issues a prompt (e.g., "Please activate first"). In this way, cards that have not been pre-activated can be intercepted at the source.

[0074] For example, if the credential verification flag is set but the travel time interval exceeds the preset time threshold, travel permission will still be denied. For instance, a passenger completes pre-activation at the security checkpoint (isEnabled=1, timeEnabled=08:15:30), but due to prolonged lingering in the station or waiting for an imposter to swipe their card, the time read at the gate is 08:19:00, calculating a travel time interval of 3 minutes and 30 seconds. The preset time threshold is 3 minutes (180 seconds), and 3 minutes and 30 seconds > 3 minutes, resulting in a timeout. In this case, even if both the credential verification flag and the identity verification flag are satisfied, the gate will still deny travel and will issue a voice prompt: "Activation expired, please reactivate." Simultaneously, the card's internal program can automatically reset the isEnabled field to 0, forcing the passenger to pre-swipe again before entering the station next time.

[0075] For example, if the credential verification flag is set and the travel time interval has not expired, but the identity verification flag is not set, travel permission is still determined to be prohibited. For instance, a passenger completes pre-activation at security (isEnabled set to 1, timeEnabled written), but the security officer fails to press the confirmation button (or offline facial recognition fails), causing the isVerified field to remain at its default value of 0. When the passenger swipes their card at the gate, the first two conditions are met, but because the identity verification flag is not set, the gate determines that travel is prohibited and displays the message "Identity verification failed, please contact security." This design ensures that even after pre-activation, identity verification is required before passage, effectively preventing card misuse.

[0076] In some implementations, a grace period mechanism can be introduced for cases of rejection due to timeout. For example, within a single calendar day, the same discount card is allowed to expire once and can still be reactivated and used normally; however, starting from the second timeout, each time the card is rejected due to timeout, the effective observation period after the next pre-swipe is forcibly extended (e.g., requiring a 30-second wait after reactivation before passing through the gate), thereby increasing the cost of malicious timeout behavior.

[0077] Through the above methods, whether it is a card that has not been pre-activated at the security checkpoint (the identity verification mark is not set), a card that has been used after pre-activation (the time interval of the ride is greater than the preset time limit), or a card whose cardholder does not match the photo on the card but has managed to pass through the pre-activation process (the identity verification mark is not set), all of them will be directly rejected by the turnstiles without any back-end intervention or manual secondary judgment. This provides the subway operator with a zero-loophole, highly certain proactive defense capability against misuse.

[0078] In some implementations, to adapt the preset time-limited threshold to the actual operational pressure and risk level of different stations without adding extra manpower or biometric equipment, the passenger flow density parameter, time period parameter, and station location parameter of the current station can be obtained, and the three can be weighted and fused to dynamically generate the optimal preset time-limited threshold for the current time period, thereby achieving a fine balance between traffic efficiency and anti-fraud security. For example, before step 103, that is, before "determining the travel rights of the target object based on the relationship between the credential verification mark, the travel time interval, and the preset time-limited threshold, as well as the identity verification mark," the following may also be included: (A.1) Obtain the passenger flow density parameters, time period parameters, and station location parameters for the current station; (A.2) Based on the passenger flow density parameter, time period parameter, and station location parameter, a weighted fusion is performed to obtain the preset time threshold for the current time period.

[0079] Among them, the passenger flow density parameter can be a value or level used to quantify the degree of crowding in the current station's entrance area. For example, it can be the average gate interval of the entrance gate group, the queue length detected by infrared sensors, or the number of people per unit area (such as 3 people per square meter) obtained by communicating with the passenger flow detection system. It can be used to reflect the current station's traffic pressure and serve as the basis for dynamically adjusting the preset time threshold length.

[0080] Among them, the time period parameter can be a label or code used to identify the time interval type to which the current card swipe time belongs, such as morning peak (07:30-09:00), off-peak period, evening peak or nighttime period. It can be used to characterize the inherent passenger flow pattern and the probability of fraudulent use in different time periods, and serve as an important feature dimension affecting the calculation of the preset time limit threshold.

[0081] Among them, the station location parameter can be identification information used to describe the geographical area attributes or transfer complexity of the subway station, such as a transfer hub station in the city center, a regular station in a residential area, a station in a commercial area, or a terminal station in the suburbs. It can be used to reflect the inherent passenger flow base of different station locations and the historical frequency of discount card fraud, and serve as a correction factor in weighted fusion.

[0082] In some implementations, the passenger flow density parameter of the current station can be used to quantify the congestion level of the entrance area, and can be obtained in various ways. For example, infrared or laser beam sensors can be installed above each group of turnstiles to count the number of people passing through the turnstiles per unit time; or it can communicate in real time with the station's passenger flow detection system to obtain the queue length and average number of people waiting in the security check area. Alternatively, it can be estimated using the average interval between turnstile swipes: when the interval between consecutive card swipes is long (e.g., greater than 2 seconds) and the interval between consecutive card swipes is also long, it reflects a large queue and slow passage. Then, the above data is normalized, for example, assigning a density parameter of 0.8 (high density) to 3 people per square meter and 0.2 (low density) to 1 person per square meter, resulting in a passenger flow density parameter between 0 and 1, with higher density parameters having larger values.

[0083] For example, time period parameters can be obtained based on the preset time period label corresponding to the current system time. Specifically, the subway operator can divide the 24 hours of a day into multiple time periods in advance, such as morning peak (07:30-09:00, time period coefficient 0.9), off-peak (09:00-17:00, time period coefficient 0.5), evening peak (17:00-19:30, time period coefficient 0.9), night (19:30-22:30, time period coefficient 0.3), and late night (22:30-06:00 the next day, time period coefficient 0.1). After reading the internal clock, the turnstile determines the time period interval in which the current time falls and outputs the corresponding time period coefficient. The higher the coefficient, the greater the expected passenger flow and the longer the queuing time, and the higher the required preset time threshold should be.

[0084] Furthermore, station location parameters can be obtained based on the geographic attribute codes of subway stations. Specifically, operators can pre-configure location type identifiers for each station in the backend system, for example, assigning a value of 0.9 to a downtown transfer hub station, 0.7 to a commercial area station, 0.4 to a regular residential area station, and 0.2 to a suburban terminal station. The turnstiles synchronize this parameter from the backend and store it locally during initialization. A larger location parameter indicates higher historical passenger flow or a longer passageway, meaning passengers will take longer to walk from the security checkpoint to the turnstile.

[0085] In some implementations, after obtaining the passenger flow density parameter (denoted as D), time period parameter (denoted as T), and station location parameter (denoted as S), a preset timeliness threshold for the current time period can be obtained through weighted fusion calculation. For example, a linear weighted formula can be used: ,in The baseline time threshold (e.g., 2 minutes). , , The weights are all positive numbers, and their sum is usually less than 1 to avoid an excessively large threshold. D, T, and S are the normalized parameter values ​​(ranging from 0 to 1). For example, let BaseTime = 120 seconds. =0.6, =0.3, =0.3. If a station has D=0.8 (high passenger density), T=0.9 (morning peak), and S=0.7 (city center transfer station), then TimeThreshold=120×(1+0.6×0.8+0.3×0.9+0.3×0.7)=235.2 seconds (approximately 3.9 minutes). If another station has D=0.1 (low passenger flow), T=0.1 (late night), and S=0.2 (suburbs), then TimeThreshold=120×(1+0.06+0.03+0.06)=120×1.15=138 seconds (approximately 2.3 minutes). Through this positive correlation weighting, the threshold is automatically extended in high-pressure scenarios, giving passengers more time to queue and pass through; the threshold is shortened in low-pressure scenarios, reducing invalid waiting windows and maintaining the anti-fraud effect.

[0086] In some implementations, instead of updating the preset time threshold within the gate, the preset time threshold can be updated periodically, such as once every 10 minutes or 30 minutes.

[0087] For example, in addition to linear weighted fusion, a lookup table method based on historical data can also be used. Specifically, the actual average pre-swipe to card swipe interval for each station under different time periods and different passenger flow levels is statistically analyzed in advance to form a threshold recommendation table. The turnstile directly looks up the table to obtain the preset time threshold based on the real-time passenger flow density of the current station (dynamically estimated by sensors or turnstile intervals) and time period parameters. For example, if a station has a historical average interval of 4.5 minutes during the morning peak when the queue length exceeds 20 people, the threshold can be set to 5 minutes. This method does not require real-time calculation, has a faster response, and can incorporate the personalized characteristics of special stations.

[0088] In some implementations, the preset time limit threshold can be dynamically adjusted based on the cardholder's historical behavior. For example, for a discount card, if there have been no overdue violations in the past 30 days, the card's personalized threshold (the corresponding thresholds for different individuals mentioned above are written in the travel voucher) can be multiplied by an upward floating factor of 1.2 (giving more lenient time); if there are recent overdue records, the baseline threshold is restored or multiplied by 0.8, thus obtaining the personalized adjustment threshold. This scheme can be combined with the preset time limit threshold for the current time period calculated based on passenger flow density parameters, time period parameters, and station location parameters. The final preset time limit threshold is min (the original preset time limit threshold plus the personalized adjustment threshold) or max, which needs to be set according to the operational strategy to both encourage good behavior and ensure fairness.

[0089] By dynamically adjusting preset time thresholds based on passenger flow density, time period, and station location, the thresholds are adaptively extended in high-pressure scenarios to accommodate queuing time, and reasonably shortened in low-pressure scenarios to maintain anti-fraud effectiveness, thus achieving an intelligent balance between traffic efficiency and security.

[0090] Step 104: Control the subway turnstiles based on travel permissions.

[0091] In some implementations, in order to transform the abstract boarding permission decision based on multiple flags into actual control actions for opening and closing physical channels, thereby ultimately achieving rigid physical interception of impersonation, boarding permission (allowing boarding or prohibiting boarding) can be output as a control command to the execution mechanism of the subway gate, so as to drive the gate to perform physical actions of opening and allowing or keeping closed and refusing.

[0092] Among them, the subway turnstile can be a self-service passage control device installed at the station entrance and exit, equipped with a reader and a blocking mechanism (such as a fan door or a three-bar). Its built-in reader can read the voucher verification mark, authorization verification time and identity verification mark in the travel voucher, and receive the opening and closing instructions issued by the logic control unit. It can be used to physically allow or block the target object according to the execution result of the travel authorization.

[0093] In some implementations, the gate logic control unit can generate corresponding control commands based on the determined travel permissions (allowed or prohibited) and send them to the gate's actuator (such as a door motor, a three-bar electromagnetic lock, or an audible and visual prompt device). If the travel permission is allowed, the control unit outputs a high-level signal to the motor driver or sends an opening command via a serial port, driving the gate door to open rapidly (e.g., fully open within 0.3 seconds), while simultaneously playing a voice prompt requesting passage (or not playing it), and automatically closing the door after the passenger has passed (detected by an infrared beam sensor). If the travel permission is prohibited, the control unit does not send an opening signal, or sends a "keep closed" command, while simultaneously driving a buzzer to emit a short alarm sound (e.g., two beeps), and displays the refusal reason code on the gate display screen (e.g., "E01: Not activated", "E02: Timeout", "E03: Identity mismatch"). For example, if an elderly passenger with a discount card completes the pre-swiping activation, and the security officer verifies their identity within the specified time, the gate will determine that they are allowed to board the train, the gate will open automatically, and the passenger will successfully enter the station; however, if another passenger attempts to impersonate the card, the gate will determine that they are prohibited from boarding the train because the identity verification mark is not in place, the gate will remain closed and an alarm will sound, and on-site staff can intervene to handle the situation.

[0094] For example, in addition to simple binary control of allowing / restricting, differentiated auxiliary processing can be performed based on different reasons for prohibition. Specifically, when a passenger is refused entry due to an unset credential verification flag, the turnstile can simultaneously send a wake-up signal to the authorization verification device at the nearest security checkpoint, alerting the security personnel that a passenger is attempting to enter the station without activation. When a passenger is refused entry due to timeout, the turnstile can automatically send a reset command to the card, setting the isEnabled flag to 0 and providing a voice prompt to reactivate at the security checkpoint. When a passenger is refused entry due to an unset identity verification flag, the turnstile can report the refusal event to the station management terminal in real time, recording the card number and time for subsequent risk point accumulation or blacklist analysis.

[0095] In some implementations, for passengers permitted to board, the turnstile can trigger a card status reset mechanism after passage. For example, after a passenger successfully passes through the turnstile, the turnstile reader sends a command to the card to reset the credential verification flag `isEnabled` to 0, and simultaneously clear or reset the current travel data such as the access verification time `timeEnabled`. This ensures that a card can only be used once after a single pre-swipe at the station, effectively preventing the same activation status from being reused multiple times.

[0096] This application embodiment reads the voucher verification mark, authorization verification time, and identity verification mark from the travel pass corresponding to the target object. The voucher verification mark is generated by a preset authorization verification device based on the travel pass's authorization attributes; the authorization verification time is determined by the authorization verification device's sensing time of the travel pass; and the identity verification mark is determined by the authorization verification device based on the matching status between the target object's identity information and the pre-stored identity information corresponding to the travel pass. The travel pass reading time is obtained, and the travel validity interval is calculated based on the difference between the reading time and the authorization verification time. The travel permissions of the target object are determined based on the relationship between the voucher verification mark, the travel validity interval, and a preset validity threshold, as well as the identity verification mark. Based on the travel permissions, the subway turnstile is controlled. In this way, the verification of travel permissions can be pre-processed and integrated into a real-time determination process on the turnstile side. Specifically, this method no longer relies on offline mining and analysis of massive historical transaction data in the background. Instead, it directly uses the real-time status fields (including permission validity flag, identity verification flag, and authorization timestamp) generated on-site by the permission verification device within the card swipe to complete the permission judgment, thereby avoiding processing delays caused by data collection, transmission, and modeling analysis. Simultaneously, through on-site comparison of the travel time interval with a preset time threshold, and dual verification of the card verification flag and the identity verification flag, each gate pass can independently and accurately determine the validity based on the field status obtained immediately upon card swipe, eliminating the need for anomaly identification under complex data patterns. This allows for dual verification of permission validity and identity consistency before entering the station. In summary, this application ensures the timeliness of travel permission verification and improves the efficiency and accuracy of verification.

[0097] In some implementations, to identify and punish cumulative violations of repeated timeouts when a single timeout (credential verification flag set but travel time interval greater than a preset timeout threshold) is insufficient to determine malicious behavior, the historical number of invalid activations of the credential can be obtained and accumulated when the specific conditions (credential verification flag set, travel time interval greater than a preset timeout threshold, identity verification flag set) are triggered. Then, when the accumulated target number of invalid activations exceeds a preset invalid activation threshold, the travel credential is locked, thereby achieving accurate identification and progressive interception of high-frequency timeout violations. For example, the travel permission verification method may further include: (B.1) When the credential verification flag is set, the travel time interval is greater than the preset time threshold, and the identity verification flag is set, obtain the historical invalid activation count of the current target object; (B.2) Perform an accumulation operation on the historical invalid activation counts to obtain the target invalid activation count; (B.3) When the number of invalid activations of the target exceeds the preset invalid activation threshold, the travel voucher corresponding to the target object is locked.

[0098] Among them, the number of invalid activations in history can be a non-negative integer value stored in the local storage of the travel voucher or the back-end system, such as 2 times. The system records the total number of events in the past time window (such as a rolling 24-hour period) where the voucher verification flag is set but the travel time interval is greater than the preset time limit threshold. This can be used to quantify the severity of the cardholder's repeated time-out violations.

[0099] The target invalid activation count can be a new value obtained by incrementally accumulating (usually by 1) the historical invalid activation count, such as updating the original 2 counts to 3 counts. It can be used to compare with the preset invalid activation count threshold to determine whether the lock trigger condition has been met.

[0100] The preset invalid activation threshold can be an integer upper limit set by the subway operator according to the anti-fraud strategy, such as 3 times. It can be used as a critical standard to determine whether to perform the ticket locking operation. When the number of invalid activations of the target exceeds the threshold, the system will automatically trigger the locking.

[0101] In some implementations, when the gate determines that the current card swipe meets the specific conditions of the credential verification flag being set, the travel time interval being greater than a preset time limit, and the identity verification flag being set (i.e., the card has been pre-activated and the identity verification has been successful, but the passenger's card swipe has timed out), the gate's logic control unit initiates a query to the card or the back-end system to obtain the currently accumulated number of historical invalid activations for the travel credential. This number is stored in the card's non-volatile storage area (such as EEPROM) or in the back-end risk account, and is used to record the total number of times the aforementioned specific timeout event has occurred for the credential within a past time window (such as a rolling 24-hour period). For example, if a senior passenger's discount card stores 2 historical invalid activations, it means that there have been 2 previous instances where the card was pre-activated and the identity verification was successful, but the timeout occurred.

[0102] Specifically, after obtaining the historical invalid activation count, the gate (or the card itself) can perform an increment operation (usually adding 1) on the value to obtain the updated target invalid activation count, and write it back to the original storage location. For example, the above 2 counts are incremented to 3, and written back to the card's invalidActCount field. After the increment operation is completed, the system compares the target invalid activation count with a preset invalid activation count threshold (e.g., 3 times set by the operator). If the target invalid activation count is greater than the preset invalid activation count threshold (e.g., reaching 4 times), the ride pass is locked.

[0103] For example, the locking operation may include: setting the locking flag (such as isLocked) in the card to 1, or reporting the card number to the backend blacklist system, making the ride pass unusable at all turnstiles until the cardholder brings valid identification to the customer service center to unlock it. Continuing the example above, if the card previously had 3 invalid activation attempts, and this time the accumulated number of timeouts is 4, exceeding the threshold of 3, then the card is locked, and the turnstile will announce that the card is locked and request assistance from the customer service center.

[0104] For example, in addition to simple cumulative counting, a rolling time window decay mechanism can be introduced. Specifically, a risk points account is maintained for each travel pass, and points accumulate within a fixed time window (e.g., 24 hours). After each time window ends, points automatically decay by a preset percentage (e.g., 50%). For instance, if a card has two timeouts on the first day, the points are 2; if no events occur on the second day, the points decay to 1; if another timeout occurs on the third day, the points become 1+1=2, which does not reach the lockout threshold. This mechanism avoids permanent accumulation due to occasional events, more fairly reflects recent behavior, and continuously puts pressure on high-frequency violators.

[0105] In some implementations, the locking operation can be performed in stages. For example, when the number of invalid activations of a target card exceeds a first threshold (e.g., 3 times) but is less than a second threshold (e.g., 5 times), the card is only restricted to use during peak hours (e.g., prohibiting passage through the gate during the morning rush hour from 7:30 to 9:00), while normal use is allowed at other times; only when the number exceeds the second threshold is the card completely locked. This tiered approach provides opportunities for minor violations to correct their behavior while imposing severe penalties on serious violations, thus balancing educational and management effectiveness.

[0106] By employing the above methods, a progressive penalty mechanism based on the cumulative number of timeouts can be constructed. This mechanism records but does not immediately lock the pass for passengers who occasionally forget to pass through the gate within the validity period, thus avoiding unnecessary complaints due to a single mistake. For repeated timeouts (which may involve lending the pass to others or malicious delays), the pass will be automatically locked. This approach protects against unintentional mistakes by normal passengers while accurately targeting high-frequency violations, thereby providing a quantitative basis for subsequent risk classification management and differentiated handling.

[0107] In some implementations, to retain the core anti-fraud capabilities of pre-swipe activation and time-limited constraints in scenarios where identity verification flags are not configured or enabled (e.g., some stations only perform manual visual verification after the target swipes their card), the system can calculate the travel time interval by only reading the credential verification flag and the authorization verification time from the travel pass. Based on the relationship between the credential verification flag, the travel time interval, and a preset time threshold, travel authorization is determined, thereby controlling the gate. This reduces system complexity while effectively intercepting the two main types of fraudulent behavior: non-pre-swipe and expired use. For example, the travel authorization verification method may also include: (C.1) Read the voucher verification flag and authorization verification time from the travel voucher corresponding to the target object; (C.2) Obtain the reading time of the boarding pass, and based on the difference between the reading time and the authorization verification time, obtain the boarding time interval; (C.3) Determine the travel permissions of the target object based on the credential verification mark and the relationship between the travel time interval and the preset time threshold; (C.4) Control the subway turnstiles based on passenger access rights.

[0108] In some implementations, for sites where identity verification is not deployed or temporarily disabled, the turnstile executes a simplified verification process. First, the turnstile reader reads the credential verification flag (e.g., isEnabled) and the authorization verification time (e.g., timeEnabled) from the travel pass held by the target user. Then, it obtains the local reading time of the turnstile and calculates the difference between it and the authorization verification time to obtain the travel time interval. Next, the turnstile logic control unit determines travel authorization based on the credential verification flag and the relationship between the travel time interval and a preset time threshold: travel is permitted only if the credential verification flag is set and the travel time interval is less than the preset time threshold; otherwise (if the credential verification flag is not set or the timeout has expired), travel is prohibited. Finally, the turnstile is controlled to perform either grant or deny access based on the travel authorization.

[0109] For example, after a passenger pre-activates their discount card at the security checkpoint, they proceed directly to the gate to swipe their card without having a specific identity verification flag written to their name (i.e., the isVerified field is absent or always at its default value). If isEnabled=1 and the time interval of 2 minutes and 30 seconds is less than the threshold of 3 minutes, the gate allows passage. If the passenger lingers in the station for too long, causing the time interval to reach 4 minutes, the gate determines that passage is prohibited and issues a voice prompt: "Activation has expired, please reactivate."

[0110] In some implementations, after conducting routine security checks on passengers at the security checkpoint and visually confirming that the cardholder roughly matches the photo on the card (without triggering any electronic signature writing), the passenger can then enter the station with the pre-activated card. The turnstile makes its judgment solely based on the pre-swipe status and time interval. Other technical details (such as dynamic adjustment of preset time thresholds and cumulative locking of historical invalid activations) are the same as in the aforementioned embodiments and will not be repeated here. This solution is suitable for stations that can rely on manual visual supervision or have relatively low requirements for anti-fraud measures, reducing system complexity while still intercepting fraudulent activities involving cards that have not been pre-swipened or have exceeded their time limit.

[0111] For example, when the gate detects that the credential verification flag is set but the travel time interval exceeds a preset threshold by a certain range (e.g., <1 minute), the gate may not directly refuse passage but instead allow passage while recording a lenient timeout event and adding a temporary mark to the card. After the next pre-swipe activation, the card's validity period will be automatically halved (e.g., from 5 minutes to 2.5 minutes). In this way, leniency is given to passengers who occasionally exceed the time limit due to objective reasons (e.g., long queues), while malicious timeouts are suppressed through subsequent punitive reduction of the validity period.

[0112] By using the above methods, a lightweight yet robust gate access mechanism with core anti-fraud capabilities can be built without relying on identity verification tokens. This makes it suitable for transitional or low-cost deployment scenarios. It can effectively intercept most fraudulent activities (card borrowing without pre-activation and card transfer after pre-activation and timeout), while reducing the workload of on-site security personnel and equipment modification costs. This provides a smooth technical compatibility path for subsequent flexible upgrades to a complete solution that includes identity verification tokens, based on the actual needs of the site.

[0113] In some implementations, to identify and intercept abnormal usage patterns such as repeated pre-activation within a short period (which may involve activating the card multiple times and then lending it to different people) without relying on complex behavioral analysis models, the cumulative number of times the verification flag on the fare pass is set within a preset target time window can be read. When this target number of times the flag is set exceeds a preset threshold, the fare pass is locked. This proactively prevents potential large-scale misuse from a time frequency perspective. For example, after step 104, i.e., after "controlling the subway gate based on fare access," the following may also be included: (D.1) The target number of times the ticket verification flag is activated within the target time window; (D.2) When the number of times the target is set exceeds the preset threshold, the travel voucher corresponding to the target object is locked.

[0114] The target time window can be a continuous and fixed-length rolling time interval, such as the past 24 hours or the past 6 hours, set by the subway operator according to the anti-fraud strategy. Its endpoint is usually the current card swipe time, and the starting point is the current time minus the window length. It can be used to limit the effective time range of the number of times the statistical voucher verification flag is set, and avoid the infinite accumulation of historical data.

[0115] The target number of times the verification flag of the same travel voucher is successfully set from an unset state to a set state (i.e., a valid pre-activation operation is completed) within the target time window, such as 5 times, can be used to quantify the high frequency of activation of the voucher in the recent period.

[0116] The preset digit setting threshold can be an integer upper limit set by the subway operator based on the reasonable digit swiping frequency of normal passengers (such as once during the morning and evening peak hours each day), for example, 4 times / 24 hours. It can be used as a standard to determine whether to trigger the locking operation. When the target digit setting frequency is greater than the threshold, the system automatically considers that there is an abnormal high-frequency activation behavior and executes credential locking.

[0117] In some implementations, the turnstile or back-end system can read the total number of times the fare card verification flag is activated within a preset target time window, i.e., the target number of activations. This target time window can be a fixed-length rolling time window, such as the past 24 hours or the past 6 hours, with its endpoint typically being the current card swipe time and its starting point being the current time minus the window length. The fare card verification flag activation operation only occurs when the passenger completes pre-swipe activation on the special reader at the security checkpoint. Each successful activation sets the isEnabled field in the card from 0 to 1, and the system records the timestamp of that activation in local storage or card storage (such as the activationCount field). When making a determination, the turnstile extracts all activation records for the card within the target time window, counts the activation count, and obtains the target number of activations. For example, if a passenger's discount card has been successfully activated 5 times on the special reader in the past 24 hours, and the system reads these 5 records, then the target number of activations is 5.

[0118] Furthermore, when the number of times the target card is activated exceeds a preset threshold (e.g., 4 times / 24 hours as set by the operator), the system determines that the card has abnormally high-frequency activation behavior (which may involve multiple people repeatedly swiping the same card to alternate entry), and locks the travel pass. Specifically, the locking operation can include: setting the lock flag (e.g., isLocked) in the card to 1, or reporting the card number to the backend blacklist system, making the card unusable at all turnstiles until the cardholder brings valid identification to the customer service center to unlock it and receive security training. Continuing the example above, if the card is activated 5 times within 24 hours, exceeding the threshold of 4 times, the card will be locked, and any subsequent card swipes at any turnstile will display the message "Card abnormal, please go to the customer service center for processing." This mechanism can effectively curb the behavior of using the same discount card to pre-activate and enter the station for multiple people who do not meet the discount conditions within a short period of time.

[0119] For example, in addition to counting the absolute number of activations, anomaly detection of activation intervals can be introduced. Specifically, when the time interval between two consecutive activations within a target time window is less than the abnormal interval threshold (e.g., less than 2 minutes), an additional risk score is added to that activation and included in the weighted value of the target activation count. For example, a normal activation is counted as 1, and a short-term consecutive activation is counted as 3. In this way, malicious behavior patterns of repeatedly swiping a card for multiple users can be identified more accurately, avoiding misjudging normal passengers' activations once in the morning and once in the evening as abnormal.

[0120] In some implementations, the locking operation can be performed in stages. For example, when the number of times the target is set exceeds a first threshold (e.g., 4 times) but is less than a second threshold (e.g., 7 times), the card is only restricted to use during peak hours (e.g., no passage through the gate during the morning rush hour from 7:30 to 9:00), while normal use is allowed at other times; only when the number exceeds the second threshold is the card fully locked. This tiered approach provides a warning and opportunity for correction for minor violations, while imposing severe penalties on serious and frequent violators, thus balancing educational and management effectiveness.

[0121] By using the above methods, a lightweight risk control mechanism based on activation frequency can be built without adding extra gate verification steps or backend analysis. This has no impact on normal passengers (who pre-swipe 1-2 times a day), but for malicious behavior that attempts to provide entry opportunities for multiple people who do not meet the discount conditions by repeatedly pre-swiping, the card can be automatically locked after reaching the threshold. This forms an effective technical constraint on the one-card-for-many-use mode from a time dimension, significantly increasing the cost of violations for impersonators.

[0122] Please refer to Figure 3 Below, in conjunction with Figure 3 The overall process of the embodiments of this application will be introduced.

[0123] For example, the cardholder (target) can pre-activate their transit pass at the security checkpoint using a pre-set authorization verification device (i.e., a specially designed reader / writer). After recognizing the pass's authorization attributes (e.g., confirming it's a discount card and in good standing), the device sets the pass verification flag to the active state and writes the current system time as the authorization verification time. Simultaneously, based on the matching result between the target's identity information and the pre-stored identity information (e.g., the card photo) corresponding to the transit pass, the device sets the identity verification flag to the appropriate state. After activation, the cardholder can then proceed to the subway turnstiles with the pass.

[0124] Furthermore, when the turnstile reads the boarding pass, it first obtains the pass verification mark, authorization verification time, and identity verification mark from the pass, and records the current reading time. Then, it calculates the difference between the reading time and the authorization verification time to obtain the boarding time interval. Subsequently, the turnstile compares the boarding time interval with a preset time threshold and makes a comprehensive judgment based on the status of the pass verification mark and the identity verification mark.

[0125] During the judgment phase, if the voucher verification flag is not set, or the travel time interval is greater than the preset time threshold, or the identity verification flag is not set, then if any of these conditions are not met, the travel permission is determined to be prohibited, the gate remains closed, and a corresponding prompt is given. Only when all three conditions are met simultaneously—the voucher verification flag is set, the travel time interval is less than the preset time threshold, and the identity verification flag is set—is the travel permission determined to be allowed, the gate performs the release operation, and the voucher verification flag is reset to the unset state after the passenger has passed through.

[0126] For cases where travel is rejected due to timeout (the credential verification flag is set, or the identity verification flag is set but the travel time interval exceeds a preset timeout threshold), the system further accumulates the historical invalid activation counts for that credential. When the target number of invalid activations exceeds a preset invalid activation count threshold, the travel credential will be locked, prohibiting its subsequent use. In addition, the system can also count the number of times the credential verification flag is activated within a target time window; if this exceeds a preset activation count threshold, locking will also be triggered.

[0127] Throughout the process, the preset time threshold can be dynamically determined by weighted integration based on the current station's passenger flow density parameters, time period parameters, and station location parameters. Alternatively, personalized thresholds can be pre-written for different preferential groups (such as the elderly and disabled), thereby achieving an adaptive balance between passage efficiency and anti-fraud security.

[0128] Please see Figure 4 This application also provides a vehicle access verification device, which can implement the above-mentioned vehicle access verification method. The vehicle access verification device includes: Reading module 41 is used to read the voucher verification mark, permission verification time and identity verification mark from the travel voucher corresponding to the target object; Among them, the voucher verification mark is generated by the preset permission verification device based on the permission attributes of the ride voucher, the permission verification time is determined by the sensing time of the ride voucher by the permission verification device, and the identity verification mark is determined by the permission verification device based on the matching status between the identity information of the target object and the pre-stored identity information corresponding to the ride voucher. The acquisition module 42 is used to acquire the reading time of the boarding pass and obtain the boarding time interval based on the difference between the reading time and the permission verification time. The determination module 43 is used to determine the travel permissions of the target object based on the relationship between the credential verification mark, the travel time interval and the preset time threshold, and the identity verification mark. Control module 44 is used to control the subway turnstiles based on passenger access permissions.

[0129] The specific implementation of the ride authorization verification device is basically the same as the specific embodiment of the ride authorization verification method described above, and will not be repeated here. Provided that the requirements of the embodiments of this application are met, the ride authorization verification device may also be equipped with other functional modules to implement the ride authorization verification method in the above embodiments.

[0130] This application also provides a computer device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the above-described vehicle access verification method. This computer device can be any smart terminal, including tablet computers, in-vehicle computers, etc.

[0131] Please see Figure 5 , Figure 5 The hardware structure of a computer device according to another embodiment is illustrated. The computer device includes: The processor 51 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application. The memory 52 can be implemented as a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 52 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 52 and is called and executed by the processor 51 to execute the vehicle access verification method of the embodiments of this application. Input / output interface 53 is used to implement information input and output; The communication interface 54 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.). Bus 55 transmits information between various components of the device (e.g., processor 51, memory 52, input / output interface 53, and communication interface 54); The processor 51, memory 52, input / output interface 53, and communication interface 54 are connected to each other within the device via bus 55.

[0132] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method for verifying vehicle access rights.

[0133] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0134] The embodiments described in this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0135] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this application, and may include more or fewer steps than shown, or combine certain steps, or different steps.

[0136] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0137] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0138] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0139] It should be understood that in this application, "at least one" and "several" refer to one or more, and "multiple" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0140] In the embodiments provided in this application, it should be understood that the disclosed systems and methods can be implemented in other ways. For example, the system embodiments described above are merely illustrative; for instance, the division of the units described above is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0141] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0142] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0143] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes multiple instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0144] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.

Claims

1. A method for verifying travel rights, characterized in that, The method includes: Read the voucher verification flag, authorization verification time, and identity verification flag from the travel voucher corresponding to the target object; The voucher verification mark is generated by a preset permission verification device based on the permission attributes of the ride voucher; the permission verification time is determined by the sensing time of the ride voucher by the permission verification device; and the identity verification mark is determined by the permission verification device based on the matching status between the identity information of the target object and the pre-stored identity information corresponding to the ride voucher. Obtain the reading time of the boarding pass, and based on the difference between the reading time and the permission verification time, obtain the boarding time interval; Based on the relationship between the credential verification mark, the travel time interval and the preset time threshold, and the identity verification mark, the travel rights of the target object are determined. Based on the aforementioned travel permissions, control the subway turnstiles.

2. The method of claim 1, wherein The ride permission includes allowing rides. The determination of the target object's ride permission based on the relationship between the credential verification mark, the ride validity interval, and a preset validity threshold, as well as the identity verification mark, includes: Obtain the preset time-efficiency threshold for the current moment, and compare the travel time interval with the preset time-efficiency threshold to obtain the comparison result; When the credential verification flag is set, the comparison result indicates that the travel time interval is less than the preset time threshold, and the identity verification flag is set, the travel permission of the target object is determined to be allowed to travel.

3. The method of claim 2, wherein The ride-hailing permission also includes prohibition of ride-hailing. The determination of the target object's ride-hailing permission based on the relationship between the credential verification mark, the ride-hailing time interval, and a preset time threshold, as well as the identity verification mark, includes: When the credential verification flag is not set, the target object's travel permission is determined to be prohibited from traveling. And / or, when the travel time interval is greater than the preset time threshold, the travel permission of the target object is determined to be prohibited from traveling; And / or, when the identity verification flag is not set, the passenger's travel permission is determined to be prohibited from taking the vehicle.

4. The method of claim 1, wherein Before determining the travel rights of the target object based on the relationship between the credential verification mark, the travel time interval and the preset time threshold, and the identity verification mark, the method further includes: Obtain the current station's passenger flow density parameters, time period parameters, and station location parameters; The preset time-sensitivity threshold for the current time period is obtained by weighted fusion of the passenger flow density parameter, the time period parameter, and the station location parameter.

5. The method of claim 1, wherein The method further includes: When the credential verification flag is set, the travel time interval is greater than the preset time threshold, and the identity verification flag is set, obtain the current historical invalid activation count of the target object; Perform an accumulation operation on the historical invalid activation counts to obtain the target invalid activation count; When the number of invalid activations of the target exceeds a preset invalid activation threshold, the ride pass corresponding to the target object is locked.

6. The method of claim 1, wherein The method further includes: Read the voucher verification flag and authorization verification time from the travel voucher corresponding to the target object; Obtain the reading time of the boarding pass, and based on the difference between the reading time and the permission verification time, obtain the boarding time interval; Based on the credential verification mark and the relationship between the travel time interval and the preset time threshold, the travel rights of the target object are determined. Based on the aforementioned travel permissions, control the subway turnstiles.

7. The method for verifying travel rights according to claim 1, characterized in that, After controlling the subway turnstiles based on the aforementioned travel permissions, the process also includes: The target number of times the verification flag of the travel voucher is activated within the target time window; When the number of times the target is set exceeds a preset threshold, the travel voucher corresponding to the target object is locked.

8. A device for verifying a ride permission, characterized by comprising: The device includes: The reading module is used to read the voucher verification flag, authorization verification time, and identity verification flag from the travel voucher corresponding to the target object. The voucher verification mark is generated by a preset permission verification device based on the permission attributes of the ride voucher; the permission verification time is determined by the sensing time of the ride voucher by the permission verification device; and the identity verification mark is determined by the permission verification device based on the matching status between the identity information of the target object and the pre-stored identity information corresponding to the ride voucher. The acquisition module is used to acquire the reading time of the travel voucher and obtain the travel time interval based on the difference between the reading time and the permission verification time. The determination module is used to determine the travel permissions of the target object based on the relationship between the credential verification mark, the travel time interval and the preset time threshold, and the identity verification mark. The control module is used to control the subway turnstiles based on the passenger access permissions.

9. A computer device, comprising: The computer device includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the vehicle access verification method according to any one of claims 1 to 7.

10. A computer readable storage medium, the storage medium having stored thereon a computer program, characterized in that, When the computer program is executed by the processor, it implements the vehicle access verification method according to any one of claims 1 to 7.

Images