Public transportation ticket business interconnection and intercommunication system and method for rail transit inter-city area

Abstract

The invention relates to the technical field of Internet, and discloses a public transportation ticket business interconnection and intercommunication system and method for rail transit inter-city areas, and the system comprises a unified ticket business rule module which is used for determining a unified charging rule adaptive to each operation main body; the clearing and clearing module is used for acquiring ticket business transaction data from the train dispatching system and the gate transaction system of each operation main body, and clearing and clearing the ticket business transaction data according to a preset clearing rule to obtain a clearing and clearing result; the payment adaptation module is used for establishing a unified real-name account of the user and establishing a binding relationship between the unified real-name account and different pass vouchers; the cross-subject transfer cooperation module is used for acquiring a station entry and exit request of a user; and calling the binding relationship in the payment adaptation module according to the station entry and exit request, and verifying the validity of the pass voucher in the station entry and exit request of the user according to the binding relationship. The travel experience of the user can be improved.

Description

Technical Field

[0001] This application relates to the field of Internet technology, specifically to an intercity and regional public transport ticketing interconnection system and method for rail transit. Background Technology

[0002] As the integration of urban agglomerations and metropolitan areas accelerates, passenger connections in regional rail transit networks are becoming increasingly close. However, the current regional rail transit operation system suffers from problems such as multiple operating entities and decentralized management mechanisms. Passengers face complex procedures when transferring between lines and systems, resulting in a significant reduction in cross-regional travel efficiency and a poor overall travel experience. Summary of the Invention

[0003] This application provides a system and method for interconnecting and interoperating ticketing for intercity rail transit, in order to solve the problem that the operation is complicated for passengers when transferring between lines and systems, resulting in a significant reduction in cross-regional travel efficiency and a poor overall travel experience.

[0004] Firstly, this application provides an intercity regional public transport ticketing interconnection system for rail transit. The system includes: a unified ticketing rules module, a clearing and settlement module, a payment adaptation module, and a cross-entity transfer collaboration module. The unified ticketing rules module is used to determine unified billing rules adapted to various operating entities. The clearing and settlement module is used to obtain ticketing transaction data from the train dispatching system and gate transaction system of each operating entity, and to clear and settle the ticketing transaction data according to preset clearing rules to obtain clearing and settlement results. The payment adaptation module is used to establish a unified real-name account for users and establish a binding relationship between the unified real-name account and different access tokens. The cross-entity transfer collaboration module is used to obtain the user's entry and exit requests; to call the binding relationship in the payment adaptation module according to the entry and exit requests, and to verify the validity of the access token in the user's entry and exit requests according to the binding relationship.

[0005] The system provided in this embodiment breaks down cross-regional ticketing barriers through the coordinated operation of a unified ticketing rules module, a clearing and settlement module, a payment adaptation module, and a cross-entity transfer collaboration module, addressing issues in rule unification, data processing, payment adaptation, and transfer verification. The unified ticketing rules module eliminates the billing differences among various operators, ensuring consistent billing standards for cross-entity travel. The clearing and settlement module enables centralized processing and fair revenue distribution of ticketing data from multiple entities, resolving the revenue sharing problem among operators. The payment adaptation module integrates various travel credentials through a unified real-name account, avoiding repeated binding operations for users. The cross-entity transfer collaboration module quickly verifies the validity of travel credentials, ensuring a smooth transfer process. In traditional cross-regional rail transit travel, inconsistent billing rules among operators, incompatible payment methods, and cumbersome transfer verification result in passengers needing to purchase tickets multiple times and undergo repeated verifications, leading to low travel efficiency. This system eliminates billing barriers through unified billing rules, payment barriers through multi-platform binding, and transfer barriers through cross-entity collaborative verification. Simultaneously, it ensures a balance of interests among operating entities through clearing and settlement, fundamentally simplifying cross-line and cross-system transfer operations, improving travel efficiency and experience, and precisely addressing the core pain points of traditional models. The system provided in this embodiment breaks down ticketing barriers between different operating entities within a region, achieving unified billing rules, payment carrier compatibility, smooth transfer processes, and fair revenue distribution. It effectively solves the problems of complex cross-line and cross-system transfer operations, low travel efficiency, and poor experience, providing passengers with a one-ticket, seamless transfer service, while also providing technical support for collaborative operations among multiple operating entities.

[0006] In one optional implementation, the clearing and settlement module includes: a ticketing transaction data acquisition unit, used to acquire ticketing transaction data from the train dispatching system and gate transaction system of each operating entity, and to standardize the ticketing transaction data to obtain standardized ticketing transaction data; a route revenue sharing unit, used to determine the user's travel route based on the standardized ticketing transaction data, and to determine the revenue sharing details corresponding to each operating entity based on the standardized ticketing transaction data, the clearing rules, and the travel route; and a reconciliation and auditing unit, used to acquire reconciliation data from each operating entity, compare the revenue sharing details with the reconciliation data to obtain the transaction reconciliation results corresponding to each operating entity, and to perform transaction auditing based on the transaction reconciliation results corresponding to each operating entity to obtain the transaction audit results corresponding to each operating entity.

[0007] This embodiment's clearing and settlement module achieves standardization of ticketing data, accurate revenue allocation, and standardized auditing through a ticketing transaction data collection unit, a route revenue sharing unit, and a reconciliation and auditing unit. The data collection unit standardizes ticketing data from multiple sources, resolving the issues of inconsistent data formats and difficulty in integration among different operating entities. The route revenue sharing unit, based on accurate travel route identification and combined with clearing rules, achieves a reasonable distribution of revenue, ensuring that each operating entity receives revenue according to its actual service contribution. The reconciliation and auditing unit ensures the accuracy and traceability of revenue sharing results through two-way data comparison and auditing, avoiding revenue sharing disputes. In traditional cross-entity clearing, problems such as unfair revenue sharing and data disputes often arise due to significant differences in data formats, ambiguous route identification, and a lack of effective reconciliation mechanisms. This embodiment's clearing and settlement module first standardizes data to unify the data scope, then clarifies the basis for revenue distribution through accurate route identification, and finally verifies the revenue sharing results through reconciliation and auditing, forming a closed-loop process of data collection, revenue calculation, and reconciliation and auditing. This significantly improves the efficiency and accuracy of clearing and settlement, ensures fair interests among multiple operating entities, and provides core support for the sustainable operation of ticketing interconnection. This embodiment's clearing and settlement module enables standardized processing of ticketing data throughout the entire process, improving the accuracy, transparency, and traceability of clearing and settlement. It effectively solves the problems of data incompatibility, unfair accounting, and reconciliation difficulties among multiple operating entities, ensuring the legitimate income of each operating entity and laying an economic foundation for the long-term operation of cross-regional ticketing interconnection.

[0008] In one optional implementation, the payment adaptation module includes: a real-name account creation unit, used to obtain the user's identity verification information, verify the identity verification information to obtain an identity verification result, and establish the user's unified real-name account based on the identity verification result; and a credential binding unit, used to obtain different access credentials and establish a binding relationship between the unified real-name account and the different access credentials.

[0009] This embodiment's payment adaptation module constructs a payment system that allows for one account per person and multiple credentials to be used universally, through a real-name account creation unit and a credential binding unit. The real-name account creation unit establishes a secure and reliable user account foundation through identity verification, ensuring the authenticity and security of account information. The credential binding unit supports binding various travel credentials to a unified account, allowing users to freely choose their payment method without needing to open separate payment channels for different operators. In the traditional model, passengers need to separately apply for tickets or bind payment methods for different rail transit systems, resulting in inconvenience, cumbersome operations, and fragmented accounts. This module integrates various travel credentials through a unified real-name account. Users only need to complete identity verification and credential binding once, which is then usable on all interconnected lines, significantly simplifying the user operation process. Simultaneously, real-name verification enhances account security, balancing convenience and security. The system provided in this embodiment, through the real-name account + multiple credential binding model, eliminates compatibility barriers between payment carriers of different operators, allowing users to use one account for multiple travel methods, significantly reducing the payment threshold and operational complexity of cross-regional travel, and further improving the passenger travel experience.

[0010] In one optional implementation, the system further includes: an operations management module; the operations management module includes: an operations data acquisition unit for acquiring multi-dimensional operations data; and an operations data management unit for determining operations optimization suggestions based on the multi-dimensional operations data.

[0011] This embodiment's operation management module achieves comprehensive collection and intelligent analysis of operational data through an operation data acquisition unit and an operation data management unit. The data acquisition unit obtains multi-dimensional operational data, covering core dimensions such as passenger flow, equipment, ticketing, and services, providing a data foundation for operational optimization. The data management unit outputs optimization suggestions based on data analysis, helping operators to accurately adjust operational strategies and improve operational efficiency and service quality. In rail transit operations, without comprehensive data analysis support, operational strategy adjustments often rely on experience-based judgment, resulting in problems such as weak targeting and poor effectiveness. This module achieves comprehensive perception of operational status through multi-dimensional data acquisition, and then identifies operational shortcomings (such as congested stations during peak hours, areas with high equipment failure rates) through data mining and analysis, outputting precise optimization suggestions to help operators achieve data-driven operations and improve the overall operational efficiency and service level of the network. This embodiment, through the combination of data acquisition and intelligent analysis, achieves precise and intelligent operation management, helping operators to promptly identify and resolve operational problems, optimize resource allocation, improve network operational efficiency and service quality, indirectly improve passenger travel experience, and enhance the attractiveness of cross-regional rail transit.

[0012] In one optional implementation, the system further includes: a code issuance management module; the code issuance management module includes: a request processing unit, used to obtain a code issuance request from the user's terminal device; a data assembly unit, used to assemble data to be signed according to the code issuance request; and a signature generation unit, used to sign the data to be signed to obtain signature data, and generate a ride QR code according to the signature data.

[0013] This embodiment's QR code issuance management module, through a request processing unit, a data assembly unit, and a signature generation unit, enables secure and compliant generation of QR codes for public transportation. The request processing unit quickly responds to user requests for QR codes, ensuring timely issuance. The data assembly unit assembles the data to be signed according to a unified standard, ensuring the QR code complies with interoperability specifications. The signature generation unit enhances the security of the QR code through signature processing, preventing risks such as forgery and tampering. As a virtual pass, the efficiency, compatibility, and security of the QR code directly impact user experience and operational safety. This module generates QR codes based on the Ministry of Transport's unified QR code rules, ensuring compatible recognition on devices from different operating entities. Simultaneously, double signature processing ensures QR code security, avoiding travel risks and economic losses caused by malicious attacks, achieving rapid issuance, secure use, and cross-domain usability. The QR codes generated in this embodiment conform to a unified standard, possessing compatibility, security, and timeliness. They solve the problems of incompatibility and high security risks associated with virtual tickets from different operating entities, providing users with a convenient and secure contactless travel method and further promoting the widespread adoption of cross-regional ticketing interoperability.

[0014] In an optional implementation, the system further includes: a trip management module; the trip management module includes: a data acquisition unit, used to acquire the user's gate passage transaction data from the gate device; the gate passage transaction data includes the user's identifier, the gate device's identifier, a timestamp, and station information; a security verification unit, used to perform legality verification on the gate passage transaction data and obtain a legality verification result; the legality verification result includes legal or illegal; and a billing and settlement unit, used to acquire gate passage transaction data with a legality verification result of legal, determine the fee amount according to the preset billing rules, the exit station and the entry station in the station information, and deduct payment according to the fee amount.

[0015] This embodiment's trip management module automates the entire trip process through a data acquisition unit, a security verification unit, and a billing and settlement unit. The data acquisition unit comprehensively captures key information from gate transactions, providing complete data support for trip processing. The security verification unit verifies the legality of transaction data, preventing fare evasion, data tampering, and other violations. The billing and settlement unit accurately calculates fees based on unified billing rules and completes deductions, achieving a seamless payment experience with immediate payment upon gate passage. Traditional trip processing suffers from incomplete transaction data, missing security verification, and billing delays, easily leading to deduction errors, fare evasion, and user complaints. This module ensures complete trip information by collecting all gate passage data, prevents violations through security verification, and achieves seamless payment through real-time billing and settlement, forming an automated process of data acquisition, security verification, and billing and deduction, improving the efficiency, accuracy, and security of trip processing. This embodiment achieves automation, accuracy, and security in trip processing, effectively preventing fare evasion and deduction errors, ensuring operational revenue, providing users with a convenient seamless payment experience, and reducing trip-related operational costs and disputes.

[0016] In one optional embodiment, the system further includes: an anti-duplicate module; the anti-duplicate module includes: The station-level duplicate verification unit is used to obtain the user's identifier from the gate transaction data uploaded by the gate device when the user enters the station, compare the user's identifier with historical entry records within a preset time period, and determine whether the user's identifier exists in the historical entry records. If the user's identifier exists in the historical entry records, it is determined that the user has repeated entry and exit behavior; if the user's identifier does not exist in the historical entry records, it is determined that the user has not repeated entry and exit behavior. A network-level duplicate verification unit is used to obtain the user's identifier from the gate transaction data uploaded by the gate device and to obtain the entire network entry data when the user enters the station. The user's identifier is compared with the entire network entry data to determine whether the user's identifier exists in the entire network entry data. If the user's identifier exists in the entire network entry data, it is determined that the user has repeated entry and exit behavior; if the user's identifier does not exist in the entire network entry data, it is determined that the user has not repeated entry and exit behavior.

[0017] This embodiment constructs a comprehensive anti-duplicate entry and exit mechanism through dual duplication verification units at the station and network levels. The station-level verification unit intercepts short-term duplicate entry behavior at a single station, while the network-level verification unit manages duplicate entry behavior across the entire network. This dual verification covers different scenarios, ensuring no omissions. In cross-regional rail transit networks, due to the large number of stations and complex lines, issues such as duplicate entry and duplicate charges are prone to occur, harming user interests and disrupting operational order. This module addresses two scenarios—"short-term duplicate entry at the same station" and "duplicate entry across stations"—through dual verification at the station and network levels. By comparing user identifiers, it quickly identifies and intercepts duplicate behavior, effectively preventing duplicate charges and unauthorized entry and exit, thus protecting the interests of both users and operators. This embodiment achieves full-scenario anti-duplicate control through a dual duplication verification mechanism, effectively solving the problems of duplicate entry and duplicate charges in cross-regional rail transit networks, maintaining normal operational order, protecting user property security, and enhancing user trust in the ticketing interconnection system.

[0018] In one optional implementation, the system further includes a key management module; the key management module includes a key generation and distribution unit, used to generate keys corresponding to each operating entity and distribute the keys to the corresponding operating entities; and a key validity verification unit, used to verify the validity of keys in ticket transaction data including at least two operating entities.

[0019] This embodiment's key management module constructs a secure cross-entity data transmission and transaction environment through a key generation and distribution unit and a key validity verification unit. The key generation and distribution unit assigns exclusive keys to each operating entity to ensure the confidentiality of data transmission; the key validity verification unit verifies the legitimacy of keys during cross-entity transactions, preventing unauthorized data access and malicious attacks. In cross-entity ticketing interconnection, data transmission involves multiple operating entities, posing security risks such as data leakage, unauthorized tampering, and malicious access. This module ensures encrypted data transmission between operating entities through unified key generation and distribution, preventing data leakage; and verifies keys during transactions to ensure the legitimacy of entities accessing the system and the reliability of data, constructing a "key distribution-key verification" security protection system that provides core protection for the secure transmission and transaction of ticketing data. This embodiment constructs a multi-layered security protection system through key management, effectively preventing security risks in cross-entity data transmission and transactions, ensuring the confidentiality, integrity, and availability of ticketing data, and providing technical support for the safe and stable operation of the rail transit intercity regional public transport ticketing interconnection system.

[0020] Secondly, this application provides a method for interconnecting and interoperating ticketing for intercity and regional public transport-style rail transit. The method includes: determining a unified billing rule adapted to each operating entity; obtaining ticketing transaction data from the train dispatching system and gate transaction system of each operating entity, and clearing and settling the ticketing transaction data according to a preset clearing rule to obtain a clearing and settlement result; establishing a unified real-name account for users, and establishing a binding relationship between the unified real-name account and different access passes; obtaining the user's entry and exit requests; invoking the binding relationship according to the entry and exit requests, and verifying the validity of the access passes in the user's entry and exit requests according to the binding relationship.

[0021] Thirdly, this application provides an electronic device, including: a memory and a processor, which are interconnected and communicate with each other. The memory stores computer instructions, and the processor executes the computer instructions to perform the intercity regional public transport ticketing interconnection method of the second aspect of the above-mentioned method. Attached Figure Description

[0022] To more clearly illustrate the technical solutions in the specific embodiments of this application or the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0023] Figure 1 This is a schematic diagram illustrating an application scenario according to an embodiment of this application; Figure 2 This is a schematic diagram of an intercity regional public transport ticketing interconnection system for rail transit according to an embodiment of this application; Figure 3 This is a schematic diagram of the clearing rules according to an embodiment of this application; Figure 4 This is a schematic diagram of another rail transit intercity regional public transport ticketing interconnection system according to an embodiment of this application; Figure 5 This is a schematic diagram of the system interface according to an embodiment of this application; Figure 6 This is a schematic diagram of the QR code structure for taking a ride according to an embodiment of this application; Figure 7 This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0025] It is understood that before using the technical solutions disclosed in the various embodiments of this application, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in this application in an appropriate manner in accordance with relevant laws and regulations, and user authorization should be obtained.

[0026] As one optional application scenario in the embodiments of this application, such as Figure 1 As shown, the intercity regional public transport ticketing interconnection system for rail transit may include at least one terminal device and at least one server. Figure 1 The example illustrates a system including a computer 101, a mobile terminal 102, and a server 103, with terminal devices such as the computer 101 and mobile terminal 102 connected to the server 103 via a network 110. Specifically, a terminal device can be a mobile phone. The server 103 can be a standalone physical server, a server cluster, a distributed system, or a cloud server providing cloud services. The network 110 can be a wired or wireless network, examples of which include, but are not limited to, the Internet, an intranet, a local area network, a wide area network, a mobile communication network, and combinations thereof.

[0027] This embodiment provides an intercity regional public transport-style ticketing interconnection system for rail transit. For example... Figure 2 As shown, the intercity rail transit regional public transport ticketing interconnection system 200 includes: a unified ticketing rules module 201, a clearing and settlement module 202, a payment adaptation module 203, and a cross-entity transfer collaboration module 204. The unified ticketing rules module 201 is used to determine unified billing rules adaptable to various operating entities. The clearing and settlement module 202 is used to obtain ticketing transaction data from the train dispatching system 200 and gate transaction system 200 of each operating entity, and to clear and settle the ticketing transaction data according to preset clearing rules to obtain clearing and settlement results. The payment adaptation module 203 is used to establish a unified real-name account for users and establish a binding relationship between the unified real-name account and different access passes. The cross-entity transfer collaboration module 204 is used to obtain users' entry and exit requests. Based on the entry and exit requests, it calls the binding relationship in the payment adaptation module 203 to verify the validity of the access passes in the users' entry and exit requests.

[0028] In this embodiment, the operating entities involve those related to urban rail transit and intercity railways, specifically including: Urban rail transit operating entities: such as a municipal metro group company (responsible for the operation of urban metro and light rail lines) and a municipal rail transit development company (responsible for the operation of commuter railways within the city). Intercity railway operating entities: such as a provincial intercity railway company (responsible for the operation of intercity railways within the province) and a certain bureau of China Railway Group Co., Ltd. (a railway unit participating in the joint operation of intercity railways). Each entity must comply with the unified system access specifications, open data interaction interfaces, and participate in the negotiation and formulation of ticketing rules and clearing rules.

[0029] As an example, the unified ticketing rules module 201 can determine unified billing rules adapted to various operators by: collecting basic data such as existing billing standards (e.g., mileage-based tiered fares, transfer discount policies), line operating costs, and regional transportation development plans from each operator. Based on this basic data, unified billing rules are determined for billing dimensions (mileage / time), base price standards, tiered coefficients, transfer discount durations, and special group (elderly / student) reduction policies. These unified billing rules are then transformed into machine-readable structured data, forming a unified billing engine. For example: Single-journey tickets: fixed fares are calculated through OD route matching (e.g., a preset fare of 8 yuan is directly matched from station A to station C). Stored-value cards: a "cumulative consumption discount algorithm" is used (a 10% discount is offered for monthly spending of 100 yuan or more, and a 20% discount for spending of 200 yuan or more). Virtual tickets: dynamic pricing is supported (e.g., a 1 yuan surcharge during peak hours and a 0.5 yuan discount during off-peak hours). Finally, the billing engine is synchronized to each operator's system 200, and a rule update mechanism is established, such as quarterly evaluation, adjusting discount policies based on operational feedback.

[0030] As an example, the billing rules may include: Basic billing standard: primarily based on mileage and secondarily on time, such as "3 yuan for 0-5 kilometers, an additional 2 yuan for every additional 5 kilometers, with a maximum fare of 20 yuan. For a single trip exceeding 2 hours, an overtime fee of 50% of the basic fare will be charged." Transfer discount rules: A 1 yuan discount is offered for transfers within 30 minutes across different stations (starting from the first exit time). For two or more consecutive transfers, a 2 yuan discount is offered for the third transfer. Special group rules: Seniors aged 65 and above and full-time students enjoy a 50% discount on fares after binding their accounts with valid identification. People with disabilities enjoy free rides after binding their accounts with their disability certificates. Error handling rules: If a user is charged twice due to system failure, the highest deducted amount will be automatically refunded within 24 hours. If a user exits the station without a previous entry record, the highest fare from this station to the furthest station on the network will be charged.

[0031] Each operator's train dispatching system refers to the core control system autonomously managed by the operator to achieve full-process management of train operations. Its functions include formulating train operation plans (such as departure time, departure interval, and stops), real-time monitoring of train location and operating status, adjusting train operation order (such as making up for delays), and recording train information (such as train number, operating section, and punctuality rate). It is a key source for the system to obtain user travel route-related data (such as actual train number and arrival time). Each operator's gate transaction system is a core component of the automatic fare collection system, deployed at the boundary between the paid and unpaid areas of the station. Its functions include collecting user gate passage data (such as pass information, gate passage timestamp, gate device number, and entry / exit direction), preliminarily verifying the validity of the pass (such as whether it is a registered pass or whether it is on a blacklist), and uploading the gate passage transaction data to the back-end system in real time. It is the core terminal for ticket transaction data collection.

[0032] Clearing rules refer to a standardized rule system for allocating cross-entity ticketing revenue, pre-determined through negotiation among the operating entities. As an example, clearing rules can include: hierarchical clearing rules, equal clearing rules, and special scenario rules. Hierarchical clearing rules involve initial clearing of cross-city transactions at the city level (e.g., revenue from cross-city transactions between XX city and ZZ city is initially collected separately by the clearing centers of the two cities), followed by secondary clearing by each city's clearing center according to the route's operating entity. Equal clearing rules involve equal revenue distribution among multiple operating entities across cities based on "service mileage percentage" or "service segment contribution," avoiding a single entity dominating revenue sharing. Special scenario rules, such as shared revenue from cross-entity transfers, are allocated at a fixed ratio of 40% for the initiating transfer route and 60% for the receiving transfer route; the specific ratio can be adjusted through negotiation among the operating entities. Clearing and settlement refers to the closed-loop process of the system processing cross-entity ticketing transaction data throughout the entire process, including: firstly, standardizing the collected raw transaction data (unifying field formats and supplementing missing information). The actual travel route of the user is then identified through a probabilistic OD path revenue sharing algorithm. Finally, the revenue due to each operating entity is calculated according to the clearing rules, and after reconciliation and auditing with each entity and confirmation of discrepancies, the final fund transfer is completed, achieving accurate matching of data, revenue sharing, and funds.

[0033] As an example, the clearing and settlement results may include: revenue sharing details, transaction reconciliation results, transaction audit results, and settlement vouchers. Revenue sharing details include the number of transactions for each operating entity, the routes involved, service mileage, receivable amount, and calculation basis (e.g., mileage percentage). Transaction reconciliation results compare the system's revenue sharing details with the reconciliation data from each operating entity's own system (e.g., number of discrepancies, amount discrepancies, and reasons for discrepancies). Transaction audit results provide the audit results on the compliance of the revenue sharing process and the authenticity of the data (e.g., whether there are any abnormal transactions, and whether the revenue sharing calculation complies with the rules). Settlement vouchers are electronic vouchers used for fund transfers (e.g., settlement notices, invoice information), serving as the basis for the operating entity's financial accounting.

[0034] In this embodiment of the application, as an example, the payment adaptation module 203 may establish a user's unified real-name account by: performing identity verification, generating a user's unified real-name account after the identity verification is passed, and activating the user's unified real-name account.

[0035] Specifically, the identity verification stage supports both online and offline verification methods: Online, users upload photos of the front and back of their ID card through the system's official app (OCR automatically recognizes the name and ID number) and complete facial liveness detection (connected to the public security system's facial database for verification, ensuring "identity consistency"). Offline, users submit their original ID card at the station service counter, where staff read the information using an ID card reader and complete facial verification via a live camera. In the account generation stage, after successful verification, the system automatically generates a unique user account ID, de-identifies and stores identity information (e.g., only the first and last 4 digits of the ID number are retained, with * used to represent the middle digits), and automatically activates basic functions such as balance account, transaction record query, and voucher management. In the activation stage, the system sends an activation SMS to the user's registered mobile phone number. After clicking the link in the SMS and setting an account password, the account is officially activated. If not activated within 72 hours, the system automatically freezes the account, requiring a re-initiation of verification.

[0036] As an example, the payment adaptation module 203 can establish a binding relationship between a unified real-name account and different access credentials in the following way: collect different access credentials, verify the legality of the access credentials, bind the unified real-name account with different access credentials, and store them together. Specifically, in the credential collection stage, dedicated collection methods are provided for different types of credentials: physical credentials, users enable the NFC function in the APP, bring the physical card close to the mobile phone, and the system automatically reads information such as card number, card type, and issuing institution. Virtual credentials, users select "bind third-party transit code" in the APP, are redirected to the corresponding platform for authorization, and the system obtains the unique identifier of the transit code. Biometric credentials, users enter the "biometric binding" page in the APP, complete face shooting or fingerprint enrollment as prompted, and the system extracts the biometric template. Specifically, in the validity verification stage, the system ensures the legality and usability of the credentials through multiple verifications: for physical credentials, the system queries the issuing institution's database to confirm that the card has not been reported lost, canceled, and is in normal status. For virtual credentials, the system verifies whether the platform to which the transit code belongs is a system partner institution (such as Alipay or UnionPay QuickPass), and whether the credential has been bound to other accounts. For biometric credentials, the system verifies whether the biometric features are clear and match the account's real-name information (e.g., comparing a face with an ID card photo). Specifically, during the association and storage phase, after successful verification, the system establishes an encrypted association between the credential identifier and the "user account ID" and stores it in a dedicated credential database (using the AES-256 encryption algorithm). Simultaneously, a successful binding notification is sent to the user. The user can view and unbind the bound credential on the "My Credentials" page in the app (unbinding requires verification of the account password or face to prevent malicious operations).

[0037] A transit pass is a legal document used by users to ride rail transit. It must comply with the unified technical specifications of the Ministry of Transport and is specifically divided into three categories: physical passes, such as the national transit smart card, regional dedicated stored-value cards, and financial IC cards (supporting contactless payment); virtual passes, such as the national transit smart card QR code (generated through the official app) and third-party platform transit codes; and biometric passes, such as facial recognition or fingerprint recognition (requiring real-name binding and security verification).

[0038] In this embodiment of the application, as an example, the cross-entity transfer coordination module 204 obtains the user's entry and exit requests in the following way: When the user swipes their access pass at the gate (e.g., by scanning a code, swiping a card, or facial verification), the gate system 200 immediately collects core data (including access pass identifier, gate device number, gate timestamp, entry / exit direction, and station code), and transmits it to the cross-entity transfer coordination module 204 in real time through a dedicated encrypted network (e.g., a VPN tunnel). After receiving the data, the module automatically generates a unique "request ID" for subsequent process tracking and log querying.

[0039] As an example, the cross-entity transfer coordination module 204 can invoke the binding relationship in the payment adaptation module 203 based on the entry and exit request in the following way: the module extracts the "pass certificate identifier" (such as card number, QR code ID, facial feature value) from the entry and exit request.

[0040] A query request is initiated to the payment adaptation module 203 according to a preset interface protocol (such as RESTful API). The request content includes "request ID, credential identifier, and query timestamp," and is accompanied by a module-specific key (to ensure the legitimacy of the request source). After receiving the request, the payment adaptation module 203 retrieves the corresponding information from the database using the credential identifier, such as "user account ID, account status (normal / frozen), credential binding validity period, and whether there are any incomplete trips (e.g., entering the station but not exiting)." The payment adaptation module 203 encrypts the query results (using RSA asymmetric encryption) and returns them to the cross-entity transfer collaboration module 204, ensuring secure data transmission.

[0041] As an example, the cross-entity transfer coordination module 204 can verify the validity of the access pass in the user's entry and exit request based on the binding relationship in the following ways: perform multi-level verification, determine the verification result, feed back the verification result to the gate device / gate system, and confirm whether to allow passage based on the verification result.

[0042] The multi-layered verification stage can involve binding verification, status verification, and permission verification. Binding verification confirms the validity of the binding relationship between the credential and the user account (e.g., whether it has been unbound, whether the binding has expired). Status verification checks whether the user account is normal (e.g., whether it is frozen, whether it is on a blacklist) and whether the credential has any incomplete trips (e.g., if a user has entered station A but has not exited, they cannot enter station B again). Permission verification verifies whether the credential meets the current trip permissions (e.g., whether a student discount credential is valid, whether a free credential is suitable for the usage scenario). The result determination stage involves judging two verification results (valid or invalid). If all verification items pass (valid binding, normal account, no incomplete trips, permission matching), the credential is determined to be "valid". If any verification fails (e.g., the credential has been unbound, the account is frozen, or there are incomplete trips), the credential is determined to be "invalid", and the reason for failure is recorded. In the feedback execution stage, if the credential is valid, the module sends a "allow" command to the gate system and records the verification log (including request ID, credential identifier, and verification result). If the credential is invalid, the module sends a "reject" command to the gate system and returns a specific failure message, such as "Account has been frozen, please contact customer service" or "There is an incomplete trip, please exit the station first." The gate display screen will simultaneously display the message to guide the user in resolving the issue.

[0043] In one optional implementation, the clearing and settlement module 202 includes: a ticket transaction data acquisition unit, used to acquire ticket transaction data from the train dispatching system and gate transaction system of each operating entity, and to standardize the ticket transaction data to obtain standardized ticket transaction data; a route revenue sharing unit, used to determine the user's travel route based on the standardized ticket transaction data, and to determine the revenue sharing details corresponding to each operating entity based on the standardized ticket transaction data, clearing rules, and travel route; and a reconciliation and auditing unit, used to acquire reconciliation data from each operating entity, compare the revenue sharing details with the reconciliation data to obtain the transaction reconciliation results corresponding to each operating entity, and to perform transaction auditing based on the transaction reconciliation results corresponding to each operating entity to obtain the transaction audit results corresponding to each operating entity.

[0044] In this embodiment of the application, the standardization process includes the standardization of fields, timestamps, monetary units, etc. For example, the difference fields between different systems (such as "passenger number" of operator A and "user ID" of operator B) are unified into "unique user identifier", the timestamp is unified into the format "YYYY-MM-DD HH:MM:SS" and the monetary unit is unified into "yuan".

[0045] In this embodiment of the application, as an example, the specific method by which the route revenue sharing unit determines a user's travel route based on standardized ticketing transaction data is as follows: First, the user's entry and exit times, entry station, and exit station are extracted from the standardized ticketing transaction data. Combined with data such as departure time, departure interval, and train arrival time within the corresponding time period obtained from the train dispatching system, a set of candidate trains that the user may take is generated. Then, based on the probabilistic OD route revenue sharing algorithm, the arrival probability of each candidate train is calculated (e.g., adjusting the probability weight based on the matching degree between departure time and user entry time, and the density of departure intervals). Simultaneously, the probability weights are further corrected by considering the differences in parameters such as the average speed and punctuality rate of the routes operated by various entities. Finally, the highest probability train is selected from the candidate trains using the maximum likelihood estimation method as the actual train for the user. The complete travel route is determined by combining the entry and exit stations (e.g., the user takes train X1 from station A to station B, and then transfers to train Y2 from operator Y to station C). If the confidence level of the route identification is lower than 95%, the route is included in the manual review queue to ensure the accuracy of the route identification.

[0046] As an example, the route revenue sharing unit determines the revenue sharing details for each operating entity based on standardized ticketing transaction data, clearing rules, and travel routes. Specifically, it first breaks down the service segments and corresponding mileage for each operating entity based on the determined travel routes (e.g., in the above route, operating entity X serves from station A to station B, a distance of 10 kilometers; operating entity Y serves from station B to station C, a distance of 15 kilometers). Then, it calculates the service mileage percentage for each operating entity (operating entity X's percentage = 10 / (10+15) = 40%, operating entity Y's percentage = 15 / (10+15) = 60%). Next, it extracts the user's total travel cost from the standardized ticketing transaction data and, combined with preset clearing rules (e.g., cross-entity equal clearing principle), calculates the basic revenue sharing amount for each operating entity based on the service mileage percentage (e.g., if the total cost is 10 yuan, operating entity X should receive 4 yuan, and operating entity Y should receive 6 yuan). If there are special scenarios such as cross-entity transfer discounts or exemptions for special groups, the revenue sharing amount needs to be adjusted according to the special terms in the clearing rules (e.g., if the transfer discount reduces the total cost by 2 yuan, the reduced portion is shared by "the initiating transfer entity bearing 60% and the receiving transfer entity bearing 40%), and finally a revenue sharing detail including the name of each operating entity, service area, mileage percentage, amount due, and reason for adjustment is generated.

[0047] In one optional implementation, the payment adaptation module 203 includes: a real-name account creation unit, used to obtain the user's identity verification information, verify the identity verification information to obtain the identity verification result, and establish the user's unified real-name account based on the identity verification result; and a credential binding unit, used to obtain different access credentials and establish a binding relationship between the unified real-name account and the different access credentials.

[0048] In one optional implementation, the intercity regional public transport ticketing interconnection system 200 further includes an operation management module. The operation management module includes: an operation data acquisition unit for acquiring multi-dimensional operation data; and an operation data management unit for determining operation optimization suggestions based on the multi-dimensional operation data.

[0049] In this embodiment, the multi-dimensional operational data includes data related to ticketing transactions, passenger flow distribution, equipment operation, and user feedback. Ticketing transaction data covers the number of transactions, transaction amount, ticket type ratio (e.g., single-journey ticket ratio, virtual ticket ratio), and frequency of discount usage for each operating entity. Passenger flow distribution data includes the number of people entering / exiting each station, passenger flow density during peak hours (7:00-9:00, 17:00-19:00), number of people transferring between different entities, and the distribution of transfer stations. Equipment operation data includes gate failure rate, gate passage speed, code issuance system response time, and server load. User feedback data includes APP rating, complaint type (e.g., "abnormal deduction," "QR code invalid"), and complaint processing time.

[0050] As an example, operational optimization suggestions can be determined based on passenger flow distribution data and equipment operation data: By analyzing passenger flow density during peak hours at each station, if it is found that the number of people entering Station A during the morning peak exceeds the gate capacity for a consecutive week (the maximum throughput of the gate is 2,000 people per hour, but the actual throughput reaches 2,500 people), and the gate speed is lower than the industry standard (the industry average is 3 seconds per person, but the actual speed is 5 seconds per person), it is recommended to add two temporary gates at Station A and upgrade the firmware of the existing gates to improve the speed. Simultaneously, combining cross-site transfer data, if the number of people transferring from Station B to Station C accounts for 60% of the total number of transfers at Station B, and the walking time for the transfer exceeds 8 minutes, it is recommended to optimize the transfer channel signage at Station B and add automatic walkways to shorten the transfer time. Furthermore, based on the ticket type distribution in ticket transaction data, if the usage rate of virtual tickets reaches 70% but the number of complaints about third-party platforms (such as Alipay) is high (accounting for 40% of total complaints), it is recommended to work with third-party platforms to optimize the QR code issuance interface and reduce QR code loading failures.

[0051] In one optional implementation, the intercity regional public transport ticketing interconnection system 200 further includes: a code issuance management module. The code issuance management module includes: The request processing unit is used to obtain code issuance requests from the user's terminal device. Specifically, when a user opens the ride code page of the official app or a third-party partner platform (such as Alipay) on their terminal device (mobile phone), the terminal device automatically sends a code issuance request to the code issuance management module. The request content includes the user's account ID, the terminal device's MAC address, the request timestamp, and the platform identifier (such as "official app" or "Alipay"). After receiving the request, the request processing unit first verifies the legitimacy of the request source through a token authentication mechanism (checking whether the platform identifier is on the partner list and whether the request timestamp is within a valid range (±5 minutes)). Then, it checks the user's account status to confirm whether the account is normal (not frozen) and whether real-name verification has been completed. If the request is legitimate and the account status is normal, the request is forwarded to the data assembly unit. If the request is illegitimate (e.g., the platform is not partnered with) or the account is abnormal (e.g., frozen), a "request failed" message and the reason are returned to the terminal device.

[0052] The data assembly unit assembles the data to be signed based on the code issuance request. Specifically, based on the user account ID in the code issuance request, the data assembly unit extracts basic information from the system database, such as the associated card issuer's public key certificate, payment account number, and user account type (e.g., "regular user," "student user"), etc. In accordance with the Ministry of Transport's IC card QR code specifications, the unit determines the field composition of the data to be signed, including the card issuer code, code issuance platform number, payment account number (anonymized), user account number, QR code validity period (default 120 seconds), single transaction limit, and card issuer-defined fields (e.g., user discount level). Following the format "field name-field value-field length," the unit assembles the above information into structured data (e.g., "card issuer code: 1001, length: 4. payment account number: 000****1111, length: 10"), ensuring that the field order and format conform to the specifications. After generating the data to be signed, it is transmitted to the signature generation unit.

[0053] The signature generation unit is used to sign the data to be signed to obtain signature data, and then generate a QR code for boarding based on the signature data. Specifically, the signature generation unit first calls the dedicated private key allocated by the key management module and uses the RSA asymmetric encryption algorithm to encrypt the data to be signed, generating signature data, and attaching a public key identifier (for subsequent signature verification). Then, the signature data and the data to be signed are merged according to the Ministry of Transport's QR code specification format, supplementing fields such as QR code version number and generation timestamp to form complete code data. Finally, a QR code generation tool (such as the ZXing library) is called to convert the complete code data into QR code image data conforming to visual recognition standards, and then encrypted and transmitted to the user's terminal device. After receiving the data, the terminal device displays the QR code image on the screen via the APP for the gate to scan and recognize, and simultaneously records the code issuance log (including user ID, QR code validity period, and generation time).

[0054] In an optional implementation, the intercity regional public transport ticketing interconnection system 200 further includes a trip management module. The trip management module includes a data acquisition unit for acquiring user gate transaction data from the gate equipment. The gate transaction data includes the user's identifier, the gate equipment's identifier, a timestamp, and station information. Specifically, when a user swipes their access pass (by scanning a code, swiping a card, or using facial recognition) at the gate equipment, the gate equipment automatically collects the gate transaction data: extracting the user's identifier (such as account ID or card number) by reading the pass information; obtaining the gate equipment's unique identifier (such as "GZ-001-01," representing gate number 1 at a certain station in a certain province); recording the timestamp of the gate operation (accurate to the second); and determining the corresponding station information (station code, station name, operating entity) based on the station to which the gate belongs. The gate equipment then uploads the gate transaction data containing the above information to the data acquisition unit of the trip management module in real time via a Socket protocol message. After receiving the data, the unit performs a preliminary check on the data integrity (such as whether the user identifier or timestamp is missing). If it is missing, it sends a "retransmit" command to the gate. If it is complete, it temporarily stores the data in the memory database, waiting for subsequent security verification.

[0055] The security verification unit is used to verify the legality of gate passage transaction data and obtain a legality verification result. The legality verification result is either legal or illegal. Specifically, the security verification unit extracts the gate passage transaction data from the in-memory database and performs multi-dimensional legality verification: First, data integrity verification, checking whether the user identifier, gate identifier, timestamp, and site information are complete, and whether the field format conforms to the standard (e.g., the timestamp is "YYYY-MM-DD HH:MM:SS"). Second, user permission verification, linking to the payment adaptation module 203, confirming whether the user account is normal (not frozen) and whether the passage certificate is valid (not unbound and within the validity period). Third, anti-tampering verification, calculating the hash value of the transaction data through a hash algorithm and comparing it with the hash value attached when the gate was uploaded to confirm that the data has not been tampered with. Fourth, blacklist verification, querying the system's blacklist database to confirm that the user identifier is not on the blacklist (e.g., no fare evasion record). If all verification items pass, a "legal" legality verification result is generated. If any verification fails (e.g., data tampering, invalid credentials), an "invalid" result is generated, and the reason for the failure is recorded (e.g., "data hash value mismatch" or "user is on the blacklist").

[0056] The billing and settlement unit is used to obtain gate passage transaction data with valid legality verification results. Based on preset billing rules and the exit and entry stations in the station information, it determines the fee amount and deducts payment accordingly. Specifically, the billing and settlement unit first filters gate passage transaction data with "valid" legality verification results. Based on the user identifier in the data, it queries the user's entry record (or exit record if it's an exit transaction) to determine the complete journey (entry station, exit station, and entry / exit time). Then, it calls the preset fee rules in the unified ticketing rules module 201, combining the mileage of the entry and exit stations (queried from the system's station mileage database) to calculate the basic fee amount (e.g., 3 yuan for 0-5 km, 5 yuan for 5-10 km). If there are preferential policies (e.g., 10% discount for accumulated spending of 100 yuan with a stored-value card), the discount is automatically applied to calculate the final fee amount. Finally, based on the payment method bound to the user's unified real-name account (e.g., balance, linked bank card, third-party payment), it initiates a payment deduction request: if the account balance is sufficient, the corresponding amount is deducted directly. If the balance is insufficient, the system will automatically redirect to the linked third-party payment platform to complete the deduction. After successful deduction, a detailed trip fare statement (entry station, exit station, fare amount, and discount amount) will be sent to the user. If the deduction fails (e.g., insufficient bank card balance), a "Deduction Failed" notification will be sent to the user, reminding them to make the additional payment.

[0057] In one optional implementation, the intercity regional public transport-style ticketing interconnection system 200 further includes an anti-duplicate module. The anti-duplicate module includes: a station-level duplicate verification unit, used to obtain the user's identifier from the gate transaction data uploaded by the gate equipment when the user enters the station, compare the user's identifier with historical entry records for a preset time period, and determine whether the user's identifier exists in the historical entry records. If the user's identifier exists in the historical entry records, it is determined that the user has engaged in duplicate entry and exit behavior. If the user's identifier does not exist in the historical entry records, it is determined that the user has not engaged in duplicate entry and exit behavior. A network-level duplicate verification unit is used to obtain the user's identifier from the gate transaction data uploaded by the gate equipment when the user enters the station, and to obtain the entire network's entry data, compare the user's identifier with the entire network's entry data, and determine whether the user's identifier exists in the entire network's entry data. If the user's identifier exists in the entire network's entry data, it is determined that the user has engaged in duplicate entry and exit behavior. If the user's identifier does not exist in the entire network's entry data, it is determined that the user has not engaged in duplicate entry and exit behavior.

[0058] In this embodiment, the station-level duplicate verification unit is deployed in the local system of a single station. When a user enters the station, the user identifier (such as account ID or card number) is obtained in real time from the gate transaction data uploaded by the gate device. Historical entry records (including user identifier, entry time, and gate number) for the station within a preset time period (default 5 minutes) are retrieved from the local cache database. The current user identifier is compared with each historical entry record to check for any instances of the same user identifier without a corresponding exit record. If such instances exist, it is determined that the user has engaged in duplicate entry / exit behavior (e.g., the same user re-enters the station within 5 minutes without exiting), and a "Reject Entry" command is sent to the gate device, with the gate display showing "Do not re-enter." If no records of the same user identifier without exiting are found, it is determined that the user has not engaged in duplicate entry / exit behavior, allowing the user to enter. Simultaneously, this entry record is stored in the local cache database and synchronized to the network-level database.

[0059] In this embodiment, the network-level duplicate verification unit is deployed in the network center system. When a user enters the station, the user identifier is first obtained from the gate's transaction data. Then, the entire network's entry database (containing entry records for all stations, updated in real time) is retrieved through the data synchronization interface. The current user identifier is compared with the entire network's entry data, with a focus on checking for any record of the user identifier not exiting at any station (i.e., "entered but not exited" status). If the entire network's entry data contains a record of the user identifier not exiting, it is determined that the user has engaged in duplicate entry and exit behavior across stations (e.g., the user entered at station A but did not exit, and then attempted to enter at station B). A "reject entry" instruction is returned to the gate, and the user is prompted to "please complete the previous exit first." If the entire network's entry data does not contain a record of the user identifier not exiting, it is determined that the user has not engaged in duplicate entry and exit behavior, and entry is allowed. At the same time, the entry record is updated to the entire network's entry database for subsequent verification. When the network is interrupted, it automatically switches to the station-level duplicate verification unit to ensure basic anti-duplicate functions.

[0060] In one optional implementation, the intercity regional public transport ticketing interconnection system 200 further includes a key management module. The key management module includes a key generation and distribution unit, used to generate keys corresponding to each operating entity and distribute the keys to the corresponding operating entities. Specifically, the key generation and distribution unit uses the SM2 asymmetric encryption algorithm recognized by the State Cryptography Administration to generate a pair of exclusive keys (private key and public key) for each operating entity: the private key is used by the operating entity to sign its own ticketing transaction data, and the public key is used by the system and other operating entities to verify the authenticity of the data. After key generation, the private key is securely distributed to the corresponding operating entity offline (delivered by a designated person carrying an encrypted USB key) or online (dedicated VPN channel + digital signature encrypted transmission), and the operating entity is required to provide a confirmation message of "key received" upon receipt. Simultaneously, the public keys of each operating entity are stored in the system 200 key repository, establishing a key management ledger to record the key generation time, distribution recipient, and validity period (default 1 year). Thirty days before the key expires, the operating entity is automatically reminded to change the key, and the above distribution process is repeated after generating a new key to ensure key timeliness and security.

[0061] The key validity verification unit is used to verify the validity of keys in ticketing transaction data involving at least two operating entities. Specifically, when the system receives ticketing transaction data involving at least two operating entities (such as transactions arising from cross-entity transfers), the key validity verification unit first extracts the signature information and public key identifiers attached to each operating entity from the transaction data. Based on the public key identifier, it retrieves the corresponding operating entity's public key from the system key repository. Using the SM2 algorithm, it decrypts the signature information in the transaction data using the public key. If the decrypted data matches the original transaction data, the key is initially determined to be valid. The validity period of the public key is then checked to confirm that it has not exceeded the expiration time recorded in the key management ledger and that the operating entity has not submitted a key loss report. If decryption is successful, the public key is within its validity period, and it has not been reported lost, the key in the ticketing transaction data is determined to be valid, and the transaction data is allowed to proceed to the subsequent clearing and settlement process. If decryption fails (e.g., signature tampering), the public key expires, or it has been reported lost, the key is determined to be invalid, the transaction data is rejected, and a "key anomaly" notification is sent to the corresponding operating entity, requesting investigation into the key issue.

[0062] In this application, the various modules and units achieve functional collaboration through close information interaction. For example, the unified ticketing rules module sends unified billing rules to the clearing and settlement module and the trip management module, providing a rule basis for clearing, settlement, and trip billing; the ticketing transaction data collection unit of the clearing and settlement module obtains and standardizes ticketing transaction data from the train dispatching system and gate transaction system of each operating entity, and then sends it to the route revenue sharing unit to determine the travel route and revenue sharing details. The route revenue sharing unit then sends the revenue sharing details to the reconciliation and auditing unit, which obtains reconciliation data from each operating entity, compares it, and generates audit results; the payment adaptation module's real-name authentication... The account creation unit obtains and verifies user identity verification information to establish a unified real-name account, and sends the account information to the credential binding unit. The credential binding unit obtains different access credentials and establishes binding relationships, then sends the binding relationships to the cross-entity transfer collaboration module and the code issuance management module. The cross-entity transfer collaboration module obtains access credential information from user entry and exit requests, calls the payment adaptation module to verify the validity of the binding relationships, and obtains the duplicate behavior judgment result from the anti-duplicate module, sending a pass or refuse instruction to the gate device. The request processing unit of the code issuance management module obtains code issuance requests from user terminals and sends them to the data assembly unit to assemble the number of signatures to be generated. According to the data assembly unit, after obtaining user account information from the payment adaptation module, it sends the data to be signed to the signature generation unit. The signature generation unit combines the key distributed by the key management module to generate a boarding QR code and sends it to the user terminal. The data acquisition unit of the trip management module obtains the gate transaction data and sends it to the security verification unit to verify its legality. The security verification unit sends the legal data to the billing and settlement unit. The billing and settlement unit calls the billing rules of the unified ticketing rules module to calculate the fee and then initiates a deduction request to the third-party payment platform. The station-level duplicate verification unit of the anti-duplicate module obtains the user identifier from the gate device and compares it with the preset time. The system compares historical entry records, and the network-level duplicate verification unit obtains data from the entire network's entry database for comparison. Both units send the judgment results to the cross-entity transfer collaboration module. The key management module's key generation and distribution unit generates keys and sends them to each operating entity, the code issuance management module, and the clearing and settlement module. The key validity verification unit obtains ticket transaction data from the clearing and settlement module and the code issuance management module, verifies the key validity, and then returns the result. The operation management module's operation data collection unit obtains multi-dimensional operation data from each module, sends it to the operation data management unit for analysis and generation of operation optimization suggestions, and then sends the suggestions to each operating entity's system and related modules.

[0063] It should be noted that the contents not described in detail in this application specification are common knowledge to those skilled in the art.

[0064] Currently, with the accelerated integration of urban agglomerations and metropolitan areas, passenger transport connections between urban rail transit and intercity railways are becoming increasingly close. However, due to the diverse operating entities, independent ticketing systems, and inconsistent settlement mechanisms, passengers often face problems such as multiple ticket purchases, repeated security checks, and complex fee settlements when transferring between lines and systems, seriously affecting travel efficiency and experience. At the same time, the lack of an efficient and fair settlement mechanism among the various operating entities also restricts the development of regional rail transit networks and public transport-like operations.

[0065] The intercity regional public transport-style ticketing interconnection system provided in this application integrates the ticketing systems of urban rail transit and intercity railways by constructing a unified ticketing rule base and clearing and settlement platform. It supports passengers using the same ticket card or mobile payment method to travel continuously across multiple lines and multiple operators in a single trip, achieving one-time ticket purchase and one-code access. The system possesses real-time transaction reconciliation and clearing and settlement capabilities across lines and operators. Based on actual travel mileage, section, and operator-agreed rules, it automatically completes fee allocation and settlement, ensuring seamless transfers for passengers and guaranteeing accurate, transparent, and traceable revenue for all parties. The application of this system will significantly improve the overall service level and operational efficiency of regional rail transit, break down ticketing barriers, and promote the realization of a true rail-based urban cluster. It also provides fundamental support for subsequent extended services such as smart travel and big data analysis of passenger flow. The intercity regional public transport-style ticketing interconnection system provided in this application implements integrated ticketing and network clearing and settlement, promoting unified pricing rules, ticket system compatibility, and ticket interoperability for intercity railways within the province through the realization of a public transport-style diversified payment ticketing system. Establish a provincial-level clearing and settlement center, build a provincial-level independent ticketing clearing and settlement system, and formulate unified clearing and settlement rules to achieve ticketing interoperability and clearing and settlement functions among various operating entities and lines. Unify standards and ensure ticketing system compatibility: standardize the types and technical standards of tickets used by urban rail transit and intercity passengers, such as using the Ministry of Transport's unified card and code-based system, and biometric technology standards. Unify the overall back-end system for ticketing processing, ensuring compatibility with interoperable ticketing rules, achieving unified overall business operations after unified ticketing, and unifying access standards for various operating entities. Establish data sharing channels to share data with the systems of various ticketing operating entities and achieve reciprocal clearing.

[0066] Interconnection and interoperability access rules include ticketing rules, billing rules, and clearing rules.

[0067] Ticketing Rules: Single-journey tickets: Paper QR code / biometric single-journey tickets. Stored-value cards: National unified card, regional unified card, etc. Virtual tickets: National unified card QR code, QR code issued by the interoperable integrated code issuing platform. The interoperable ticketing system generally adopts tickets with unified standards from the Ministry of Transport, or tickets with unified standards defined jointly by the interoperable regions, facilitating compatibility and recognition by both parties' equipment and systems. Ticketing rules are closely integrated with billing rules. Billing rules calculate fees based on the ticket type defined by the ticketing rules, with different ticket types corresponding to different billing strategies and discount rules. For example, single-journey tickets use fixed OD route billing, stored-value cards enjoy cumulative discounts, and virtual tickets support dynamic pricing. The technical effect is to achieve unified management of ticketing and billing, ensuring fair billing for different ticket types in interoperable scenarios, eliminating ticketing barriers, and improving the consistency of the passenger payment experience. The specific manifestation of the integration of billing rules and ticketing rules is that after the system identifies the ticket type, it automatically calls the corresponding billing engine to calculate the fee. Single-journey tickets calculate a fixed price through OD (Original Direction) path matching; stored-value cards apply a cumulative discount algorithm on top of the base price; and virtual tickets adjust pricing according to operational strategies. For example, virtual tickets accessed through Alipay or UnionPay apps can use coupons to offset part of the ticket price. This combination ensures the automation and accuracy of the billing process while supporting a unified billing standard across operating entities.

[0068] Billing Rules: Based on a probabilistic OD (Original Departure-Exit) route revenue sharing algorithm, the system accurately identifies routes based on departure time, departure interval, arrival time, and differences in operating entities, improving algorithm accuracy. 1. Data Collection: The system collects basic data such as passenger entry / exit times, departure times, departure intervals, and operating entity information. Specifically, this includes: obtaining passenger ID, entry station, exit station, and entry / exit timestamps from turnstiles; obtaining departure times, departure intervals, and train schedule information from the train dispatching system; and obtaining difference parameters such as line characteristics and service levels from the operating entity database. 2. Route Probability Calculation: Possible train services are calculated based on departure time and departure interval, and an OD route probability matrix is ​​established by combining these with arrival time. The arrival probability of each candidate train service is calculated based on departure time, departure interval, and arrival time parameters, establishing a candidate route set. A basic probability weight is calculated for each candidate route. 3. Operating Entity Difference Analysis: The path probability weights are adjusted to consider differences in line characteristics and service levels among different operating entities. Specifically, this includes: 4. **Accurate Route Identification:** Analyzing indicators such as the average speed, punctuality rate, and service facility level of each operating entity, and assigning differential weighting factors to each entity. These weighting factors are then applied to the probability calculation of candidate routes. 5. **Precise Route Identification:** Selecting the most probable actual travel route from candidate routes using the maximum likelihood estimation method. The maximum likelihood estimation algorithm is applied to all candidate routes, and the route with the highest probability is selected as the identification result. A confidence threshold is also calculated; routes below the threshold are entered into a manual review queue. 6. **Fee Allocation:** Based on the identified precise route, fare revenue is distributed according to mileage or segment ratio. Specifically, this includes: calculating the mileage ratio R_k borne by each operating entity based on the identified route. The total fare is allocated proportionally: Fee_k = Total Fare × R_k. A detailed revenue sharing record is generated, including route identification parameters, allocation ratio, and settlement amount.

[0069] The algorithm's technical advantages lie in significantly improving the accuracy of route identification, raising it from traditional experience-based judgment to over 95% precision. This effectively addresses the issue of unfair fare allocation across different operating entities, ensuring fairness in the revenue distribution for all parties. Furthermore, by quantifying uncertainty using probabilistic methods, the algorithm's robustness and interpretability are enhanced, providing a reliable data foundation for subsequent clearing and settlement.

[0070] Clearing rules: For intercity transactions, multiple operators clear the transactions on an equal footing; within each operator, clearing is further done by line operator. Treating intercity transactions as two stations, cross-city transactions are first cleared by city, and then each city allocates the remaining amount to the line according to its own regional clearing ratio and amount. For example... Figure 3As shown, the total cost of this intercity transaction is 7 yuan. The initial clearing is completed at the city level: XX City ACC (clearing center): responsible for the city's route service, clearing amount is 4 yuan. ZZ City ACC (clearing center): responsible for the city's route service, clearing amount is 3 yuan. The initial clearing ratio (4:3) is based on the "intercity equal clearing principle" negotiated between XX City and ZZ City (e.g., determined by the service mileage ratio of the two cities' routes in the intercity trip). After completing the intercity clearing, the two city ACCs further split their clearing amounts according to the route operators: XX City ACC's 4 yuan clearing: allocated to XXA line (route operator): 1 yuan. Allocated to XXB line (route operator): 3 yuan. The splitting ratio (1:3) is determined by negotiation among the route operators within XX City (e.g., based on the service mileage / segment contribution of XXA and XXB lines in this intercity trip). ZZ City ACC's 3 yuan clearing: allocated to ZZ line 1 (route operator): 1 yuan. The allocation to ZZ Line 2 (line operator): 2 yuan. The split ratio (1:2) will be determined through negotiation among the line operators within ZZ City (similarly based on service contribution). Ultimately, the clearing result of this intercity transaction of 7 yuan is: XXA Line 1 yuan, XXB Line 3 yuan, ZZ Line 1 yuan, and ZZ Line 2 yuan, achieving a hierarchical and equitable distribution through "intercity clearing → city clearing → line clearing".

[0071] As an example, the overall architecture diagram of the intercity regional public transport ticketing interconnection system is as follows: Figure 4 As shown, this architecture uses the "City A Metro Clearing Center" as the core hub, constructing a multi-entity collaborative system of "Line Layer - Station Layer - Clearing Layer - Service Layer" to achieve cross-regional (such as City A and City C) ticketing interconnection and interoperability. The specific modules and collaborative logic are as follows: The Metro Clearing Center in City A, serving as the core for processing regional ticketing data, integrates multiple functional subsystems: Basic Support Subsystem: Includes modules for key management and ticket issuance, responsible for generating / distributing encryption keys for various operating entities and uniformly issuing physical / virtual tickets. Clearing Subsystem: Completes clearing calculations for cross-entity ticketing transactions through biometric / multi-factor authentication, and also connects to the "Motorized Vehicle Line Center" to achieve data exchange between rail transit and surface public transport. Line Layer: Includes the line ticketing system and ticket clearing center, responsible for collecting gate transaction and train dispatch data for the line, processing it initially, and uploading it to the clearing center. Station Layer: Deploys station AFC systems (including ticketing / ticket checking / query equipment) and mobile payment devices, directly connecting to passenger ticket purchase / gate access requests, and supporting the "City APP" QR code / facial recognition boarding functions, synchronizing gate access data to the clearing center in real time.

[0072] The intercity ticketing clearing service center in City A undertakes the function of cross-city ticketing collaboration, interconnecting with the intercity ticketing system of City C through a "data synchronization" interface. It integrates modules such as clearing and settlement, and reconciliation management to complete cross-city transaction clearing between Cities A and C. It also connects to the public transportation ticketing system to realize combined ticketing for rail transit and buses (such as "metro + bus" combined discounts). It provides unified clearing reports and transaction query services to support reconciliation and auditing for cross-regional operating entities. This architecture, through a hierarchical design of "local clearing + cross-city collaboration," achieves data interoperability, rule unification, and clearing and settlement for ticketing across multiple modes of transportation (metro, bus) and multiple cities within the region, providing passengers with a "one code / one card" cross-regional public transportation service.

[0073] The overall architecture of the intercity regional public transport ticketing interconnection system mainly consists of the systems of the Metro Clearing Center in City A and the Intercity Ticketing Clearing Center in City A. The two systems interact with each other and collaborate on business through standard interfaces, forming a complete ticketing interconnection.

[0074] City A Metro Clearing Center: Network Layer: Primarily the metro clearing system, including the clearing and operation system, real-name account system, biometric system, and diversified ticketing system. Within the network layer, the metro clearing system also interconnects with the clearing systems of other cities. The clearing and operation system includes clearing and settlement, and operation management functions; the real-name account system includes user system functions; the biometric system specifically manages biometric tickets in virtual tickets; and the diversified ticketing system includes trip management, code issuance management, and key management functions. Line Layer: Primarily for interfacing with various metro line systems and tram line center systems. Station Layer: Primarily for metro station-level systems and metro station equipment.

[0075] City A Intercity Ticketing Clearing Center: Network Layer: Primarily the intercity ticketing clearing system, including ticketing marketing, biometric identification, passenger management, code issuance management, invoice management, equipment management, and a public transport-style intercity ticketing system. Within the network layer, the intercity ticketing system also interconnects with other cities' intercity ticketing systems. Ticketing marketing includes clearing and settlement, operations management, itinerary management, and key management functions; passenger management includes user system functions; and biometric identification specifically manages biometric tickets within virtual tickets. Route Layer: Managed by a unified public transport-style intercity ticketing system. Station Layer: Primarily station-level systems and station equipment.

[0076] An interface diagram of the intercity regional public transport ticketing interconnection system is shown below. Figure 5As shown, the interface interaction logic of various participants in the system (third-party payment, card companies, operating entities, etc.) revolves around the "Intercity Center" to build a cross-entity, cross-level interface collaboration system. Specifically, it is divided into two categories: external interface connections and internal collaboration interfaces. I. External Interface Connections (for passengers / service providers): Payment Interfaces: Third-party payment and UnionPay / Digital RMB connect to the Intercity Center through the "Payment Reconciliation" interface to achieve real-time deduction of fares, transaction data synchronization, and fund reconciliation, supporting the cross-regional use of multiple payment methods. Certificate Interfaces: Card companies (national unified card / city unified card) connect to the Intercity Center through the "Revenue Reconciliation" interface to upload physical card transaction data and receive revenue distribution details, ensuring the cross-regional interoperability of physical certificates. Real-Name Interfaces: The public security real-name authentication system connects to the Intercity Center through the "Real-Name Registration" interface to verify passenger identity information and synchronize real-name accounts, providing a secure foundation for biometric identification and certificate binding. Interchange Media Interface: Interchange media such as national smart cards / city cards, QR codes / UnionPay QuickPass, financial IC cards, and biometrics are used. These interfaces connect with the intercity station's front-end system via biometric gates and self-service terminals to verify credentials and collect pass data. II. Internal Collaboration Interface (for Operating Entities): Intercity-Metro Center Interface: The intercity center (intercity ticketing clearing system) and the metro center (metro clearing center) are interconnected via a dedicated network to achieve four core content interfaces: Internet key system (metro and intercity key exchange), passenger real-name system (information synchronization), biometric system (feature information synchronization), and clearing system (transaction reconciliation and parameter synchronization), enabling basic data interoperability across operating entities. Intercity Center-Other Intercity Center Interface: Different intercity centers (such as the intercity clearing centers in City A and City B) are interconnected via an intercity transmission network to synchronize cross-regional transaction data and unify clearing rules, supporting ticketing interoperability between multiple cities. Intercity Center-Intercity Station Interface: The Intercity Center, through the station's front-end system, connects to biometric gates and self-service terminals to achieve real-time collection of gate passage data and processing of passenger service requests (such as self-service top-up and credential binding). This interface system, through a two-tiered design of "external connection to passenger services and internal collaboration with operating entities," enables cross-regional interoperability of payment methods, access credentials, real-name information, and clearing data, providing technical support for "one code / one card / one face" intercity public transport travel.

[0077] The functions of the intercity regional public transport ticketing interconnection system are as follows: (1) Clearing and settlement: Clearing and settlement is the core function of the intercity regional public transport ticketing interconnection system. The system uses clearing algorithms to split the overall network ticketing revenue according to different clearing criteria and reconcile the revenue with various entities and institutions. The core function of the clearing and settlement system is to clear and settle the ticketing data of the intercity, and to provide accurate and timely statistical data such as passenger flow, revenue sharing and income required for operation, as a strong support for operation and financial statements. For ticketing transaction data processing of various types of interfaces, the system outputs fine-grained clearing results based on key data such as line station, equipment type, equipment number, time segment, ticket type, ticket number, shift number, operator, discount, data source, deduction entity, and card issuing entity, and combines and summarizes them according to multi-dimensional business needs such as passenger flow and revenue sharing. The metro and intercity clearing are carried out in an equal operation clearing mode. The ticket clearing systems of the various entities operating on an equal footing are at the same level. The entities formulate clearing agreements, establish ticket processing and clearing rules, and have a transaction interaction and interoperability model. They conduct equal clearing by formulating ticket processing rule agreements, issue clearing reconciliation documents to each other, and conduct transaction audits and revenue reconciliation.

[0078] (2) User system: Shift from ticketing service to passenger service. Establish a diversified, convenient and integrated ticketing system with the passenger user system as the core. It integrates multiple payment methods, multiple ticket types and multiple ticket purchase methods. It establishes a binding relationship with passengers through different access credentials such as national all-in-one card / city card, ride code, UnionPay QuickPass, financial IC card and biometric identification, so as to realize the mixed use of multiple gate passage methods for passengers and provide passengers with a convenient travel experience.

[0079] (3) Operations Management: Operations management includes functions such as clearing operations, ticketing operations, multi-operator operations, internet channel operations, route operations, station operations, and equipment operations. It also includes functions such as equipment transaction data management, system permission management, equipment status management, operations report management, system ticketing parameters, passenger blacklist parameter management, and network security management.

[0080] The specific implementation details of each function in operations management are described below: Clearing and Settlement Operations: Through the data processing engine of the clearing and settlement center, transaction data from various operating entities is collected in real time, and revenue is automatically distributed according to preset clearing rules. The technological effect is automated clearing and settlement, reducing manual intervention and improving clearing efficiency and accuracy. Ticketing Operations: The system manages ticketing parameter configurations, including fare standards, discount rules, and ticket types, enabling flexible adjustments to ticketing strategies through parameterized management. The technological effect is support for rapid response to market changes and the provision of differentiated ticketing services. Multi-Operating Entity Operations: A unified operating entity management platform is established to monitor the operational status and service quality of each entity and coordinate cross-entity business collaboration. The technological effect is breaking down operational barriers and achieving resource sharing and collaborative optimization. Internet Channel Operations: The system manages the user experience and transaction process of online ticketing channels, providing data analysis and channel optimization suggestions. The technological effect is improved online service quality and an increased proportion of contactless services. Route Operations: The system monitors passenger flow, equipment operating status, and operational efficiency of each route, providing route optimization suggestions. The technological effect is precise operational management and improved route resource utilization. Station Operations: Real-time monitoring of station equipment status and alarm events, handling of anomalies and complaints. The technical effect is to ensure station operational safety and improve passenger satisfaction. Equipment Operations: Centralized management of the configuration, maintenance, and upgrades of all network equipment, achieving remote monitoring and fault early warning through IoT technology. The technical effect is to reduce equipment failure rates and improve system availability. System Access Control: Based on a role-based access control model, fine-grained management of user permissions ensures data security. The technical effect is to prevent internal risks and improve system security. Network Security Management: Implementation of comprehensive security protection, including firewalls, intrusion detection, and data encryption measures. The technical effect is to ensure system and data security and prevent cyberattacks.

[0081] (4) Trip Management: After passengers pass through the gates, the station's gate equipment uploads transaction data to the backend system. The system analyzes the transactions and verifies their security, legality, and validity. It monitors duplicate entry and exit routes, monitors blacklists and ticketing rules, matches OD (Original Departure) fares according to billing rules, calculates OD fees and applicable discounts based on the fare rules, and connects to third-party payment platforms to handle trip payment deductions and trip payment status processing. It supports multiple internet access channels, including cash, card payments, and internet payments.

[0082] The specific implementation details of each functional module in the itinerary management system are described below: Transaction Data Assembly and Upload: The turnstiles collect passenger card / QR code swiping information, assemble data packets containing parameters such as passenger ID, device ID, timestamp, and station information, and upload them to the backend system in real time via Socket protocol messages. This achieves efficient data collection and transmission, ensuring the integrity and timeliness of transaction information. Transaction Security Verification: The system performs digital signature verification, data integrity checks, and replay attack detection on received data packets to ensure the credibility of the transaction source. This prevents data tampering and forgery attacks, ensuring transaction security. Trip Duplicate Detection: An integrated anti-duplicate system monitors passenger entry and exit behavior patterns in real time, identifying abnormal duplicate entry or exit situations. This effectively prevents duplicate charges and improves the system's anti-fraud capabilities. Blacklist Monitoring: Real-time comparison of passenger information with a blacklist database blocks suspicious individuals from passing. This ensures operational safety and prevents security risks. Ticketing Rule Monitoring: Dynamically loading the latest ticketing rule parameters verifies the validity and usage rights of passenger tickets. This ensures consistent execution of ticketing rules and maintains a fair charging order. OD Route Matching and Billing: Matches fare parameters based on station information for entry and exit routes to calculate accurate OD fees and discounts. This technology enables precise billing, reducing disputes and complaints. Diverse Payment Integration: Integrates with third-party payment interfaces such as Alipay, WeChat Pay, and UnionPay, supporting seamless switching between multiple payment methods. This technology improves payment convenience and caters to different passenger payment preferences. Trip Status Management: Tracks the entire lifecycle of a transaction from initiation to completion in real time, recording key status changes. This technology manages the entry and exit status of tickets, preventing one-sided deductions due to duplicate entries / exits or missing trips.

[0083] (5) Code Issuance Management: The system uses the Ministry of Transport's QR code rules as its code issuance rules, is compatible with the nationally interconnected QR code system for public transportation, and integrates with a flexible ticketing operation system to issue various virtual tickets. The Ministry of Transport's QR code structure (field names and field lengths) is as follows: Figure 6As shown, the QR code for public transport includes: QR code version (length 1): Identifies the technical specification version followed by the QR code, used for compatibility with the parsing logic of different systems. QR code data length (length 2): Records the total byte length of the entire QR code data, facilitating data integrity verification by the parser. Issuing institution public key certificate (length 117): Stores the digital certificate information of the issuing institution, used to verify the legality and source credibility of the QR code. Payment account number (length 16): The user's unique identifier in the payment system, associated with the corresponding payment fund account. User account number (length 10): The user's unified real-name account identifier in the ticketing interoperability system, used to associate user information with the credential binding relationship. Issuing institution code (length 4): Identifies the issuing entity corresponding to the QR code (e.g., a city transportation card company), facilitating cross-institutional clearing and identification. Issuing platform code (length 4): Identifies the platform that generated the QR code (e.g., official APP, third-party payment), distinguishing different issuing channels. User account type (length 1): Identifies the user account attribute (e.g., ordinary user, student user), used to match the corresponding fare discount rules. Single Transaction Amount Limit (Length 3): Limits the maximum fare deducted for a single ride using this QR code, preventing malicious fraud. Payment Account User Public Key (Length 33): The public key corresponding to the user's payment account, used to encrypt payment information and ensure transaction security. Payment Account System Authorization Expiration Time (Length 4): Records the valid expiration time of the payment account authorization; the QR code automatically expires after this period. QR Code Validity Time (Length 2): Sets the lifespan of the QR code (e.g., 120 seconds) to avoid security risks associated with prolonged validity. Issuing Institution Custom Field Length (Length 1): Identifies the length of the "Issuing Institution Custom Field," used to accommodate personalized information from different institutions. Issuing Institution Custom Field (Length 32): Stores personalized data from the issuing institution (e.g., user discount level, card type). Issuing Institution Authorization Signature (Length 65): The issuing institution's digital signature on the QR code data, used to verify that the data has not been tampered with. QR Code Generation Time (Length 4): Records the timestamp of the QR code's generation, combined with the validity time to determine its current usability. Payment account user private key signature (length 65): The user's payment account private key signature is used to verify the legitimacy of the user's payment authorization.

[0084] The QR code issuance process involves the mobile app sending a code generation request to the backend. Upon receiving the request, the backend assembles the QR code data (ticket data) according to business rules and then signs the data. After receiving the returned code data from the backend, the mobile app assembles the complete code data based on the system time, performs a final signature, and then uses a QR code drawing tool to create the QR code image. The process is as follows: When a user opens the QR code on their phone, the subway / intercity transit code app requests the code from the backend. The backend receives the request and calls the code generation interface of the code issuance management system. The code issuance management system receives the request and assembles the QR code data to be signed by the issuing institution (issuing institution public key certificate, payment institution public key certificate, payment account number, user account number, issuing institution code, code issuance platform number, user account type, single transaction limit, payment account user public key, payment account system authorization expiration time, QR code validity period, issuing institution custom field length, and issuing institution custom field). The code issuance management system then signs the data to be signed by the issuing institution. The code issuance management system generates a user's private key signature according to the transportation smart card QR code specification, then assembles the complete code data and returns it to the internet ticketing system, thus ending the process.

[0085] (6) Key Management: The intercity regional public transport ticketing interconnection system, as the certificate management center, is responsible for uniformly distributing and managing the keys of different card issuers, verifying the validity of keys in cross-domain transactions, and ensuring the authenticity of the ticketing system and equipment identity and the confidentiality, integrity and security of information transmission.

[0086] (7) Anti-duplicate system (anti-duplicate module): As the core anti-duplicate mechanism of trip management, the anti-duplicate system is divided into station-level anti-duplicate system and network-level anti-duplicate system according to the deployment level: Station-level anti-duplicate system (station-level duplicate verification unit): Deployed within a single station, the specific execution steps are as follows: (1) When a passenger enters the station using a QR code, the station-level anti-duplicate system receives parameters such as passenger ID, entry time, and entry device ID uploaded by the gate device. (2) The system compares the passenger ID with the most recent entry record in the local cache and checks whether there is a record of the same passenger ID that has not exited the station within the set time window (e.g., 5 minutes). (3) If there is a record of not exiting the station, the entry operation is rejected, and a "duplicate entry" prompt message is returned to the gate device. The gate device displays the corresponding prompt and remains closed. (4) If there is no record of not exiting the station, the entry is allowed and the entry information is recorded in the local cache and uploaded to the central database at the same time. (5) Upon exiting the station, the system verifies whether the passenger ID has a valid entry record. If no valid record is found, exit is refused and an invalid exit message is displayed to prevent duplicate exit charges. Network-level anti-duplicate system (network-level duplicate verification unit): Deployed at the network-level center, the network-level anti-duplicate system has the same function as the station-level anti-duplicate system. When network support is available, the network-level anti-duplicate system is accessed first; in the event of a network outage, the station-level anti-duplicate system is used. The technical effect of the anti-duplicate system is to effectively prevent passengers from being charged repeatedly through a multi-level verification mechanism, improving system security and reliability, and ensuring the accuracy of operational revenue.

[0087] The proposed intercity and regional public transport ticketing interconnection system for rail transit offers the following advantages: It enables seamless cross-regional travel with a single ticket: By establishing unified ticketing rules and a clearing and settlement mechanism, passengers can use the same payment method to seamlessly transfer between rail transit and intercity lines operated by different entities within a single trip. This effectively solves problems such as multiple ticket purchases and repeated security checks, significantly improving the efficiency of cross-regional travel. It enhances the passenger travel experience: The system supports one-time ticket purchase and one-code access, reducing interruptions and delays caused by incompatible ticketing systems and complex settlement processes. This greatly improves the convenience and comfort of cross-line travel, enhancing the attractiveness and satisfaction of public transport services. It establishes a fair and efficient clearing and settlement system: Relying on a cross-system and cross-line clearing and settlement platform, it achieves automatic, accurate, and transparent distribution of passenger revenue among multiple operating entities, protecting the interests of all parties and providing institutional and technical guarantees for the networked operation of regional rail transit.

[0088] The realization of this technological advantage relies on the aforementioned technical features and their corresponding solutions: Employing a probabilistic OD (Original Distance) path revenue sharing algorithm, through precise route identification and cost allocation, it achieves fairness and accuracy in fare allocation across operating entities, ensuring that each entity receives revenue proportional to its actual mileage. The clearing rules design adopts a multi-operator peer-to-peer clearing model between intercity routes and a hierarchical clearing solution within operating entities, constructing a transparent and traceable clearing system to guarantee the fairness of revenue distribution for all parties. The clearing and settlement center architecture, through the data processing engine of the provincial clearing and settlement center and automated clearing and settlement technology, automates revenue distribution, reduces the risk of human intervention, and improves clearing efficiency. The peer-to-peer clearing model, along with the technical solutions for ticketing processing rules and transaction interaction, enables operating entities to issue clearing reconciliation documents to each other, conduct transaction audits and revenue reconciliation, ensuring the transparency and auditability of the clearing process. The key management center ensures the security and integrity of clearing and settlement data transmission through a unified key distribution and management system and a technical solution for verifying the validity of cross-domain transactions, providing security guarantees for the reliability of clearing and settlement. Supporting the integrated development of regional transportation, the system breaks down ticketing barriers between different rail transit systems, promoting the formation of urban clusters along rail lines, helping to optimize regional passenger flow organization, improve overall network operating efficiency, and lay the foundation for the subsequent expansion of smart mobility services. Strengthening data collaboration and system scalability, while achieving ticketing interoperability, the system possesses excellent data recording, reconciliation, and integration capabilities. This not only ensures transaction security and revenue integrity but also provides big data support for passenger flow analysis and operational decision-making, demonstrating strong scalability and adaptability.

[0089] This embodiment also provides a method for interconnecting and interoperating ticketing for intercity rail transit in regional public transportation. The method includes: determining unified billing rules suitable for various operating entities; obtaining ticketing transaction data from the train dispatching system and gate transaction system of each operating entity; clearing and settling the ticketing transaction data according to preset clearing rules to obtain clearing and settlement results; establishing a unified real-name account for users and establishing a binding relationship between the unified real-name account and different access passes; obtaining users' entry and exit requests; invoking the binding relationship based on the entry and exit requests; and verifying the validity of the access passes in the users' entry and exit requests based on the binding relationship.

[0090] Figure 7 This is a schematic diagram of an electronic device provided in an embodiment of this application. See below for details. Figure 7The electronic device may include a processor (e.g., a central processing unit, a graphics processing unit, etc.) 501, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 502 or a program loaded from memory 508 into random access memory (RAM) 503. The RAM 503 also stores various programs and data required for the operation of the electronic device. The processor 501, ROM 502, and RAM 503 are interconnected via bus 504. An input / output (I / O) interface 505 is also connected to bus 504. Typically, the following devices may be connected to the I / O interface 505: input devices 506 including, for example, a touchscreen, touchpad, keyboard, mouse, camera, microphone, accelerometer, gyroscope, etc.; output devices 507 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; memory 508 including, for example, magnetic tape, hard disk, etc.; and a communication device 509. The communication device 509 allows the electronic device to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 7 Electronic devices with various devices are shown; however, it should be understood that it is not required to implement or possess all of the shown devices, and more or fewer devices may be implemented or possessed alternatively. In particular, embodiments of this application include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods described above. In such embodiments, the computer program can be downloaded and installed from a network via communication device 509, or installed from memory 508, or installed from ROM 502. When the computer program is executed by processor 501, it performs the functions defined in the methods described in the embodiments of this application. Figure 7 The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0091] This application also provides a computer-readable storage medium. The methods described in this application can be implemented in hardware or firmware, or implemented as computer code that can be recorded on a storage medium, or implemented as computer code downloaded via a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc. Further, the storage medium may also include combinations of the above types of memory. It is understood that a computer, processor, microprocessor, or programmable hardware includes storage components capable of storing or receiving software or computer code. When the software or computer code is accessed and executed by the computer, processor, or hardware, the methods shown in the above embodiments are implemented. A portion of this application can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can invoke or provide the methods and / or technical solutions according to this application through the operation of the computer.

[0092] Although embodiments of this application have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of this application, and all such modifications and variations fall within the scope defined by the appended claims.

Claims

1. A city-wide intercity rail transit ticketing and interoperability system, characterized in that, The system includes: Unified ticketing rules module, clearing and settlement module, payment adaptation module, and cross-entity transfer collaboration module; The unified ticketing rules module is used to determine unified billing rules that are compatible with all operating entities; The clearing and settlement module is used to obtain ticket transaction data from the train dispatching system and gate transaction system of each operating entity, and to clear and settle the ticket transaction data according to the preset clearing rules to obtain the clearing and settlement results. The payment adaptation module is used to establish a unified real-name account for users and to establish a binding relationship between the unified real-name account and different access credentials; The cross-entity transfer coordination module is used to obtain the user's entry and exit requests; call the binding relationship in the payment adaptation module according to the entry and exit requests, and verify the validity of the pass in the user's entry and exit requests according to the binding relationship.

2. The system according to claim 1, characterized in that, The clearing and settlement module includes: The ticketing transaction data acquisition unit is used to acquire ticketing transaction data from the train dispatching system and gate transaction system of various operating entities, and to standardize the ticketing transaction data to obtain standardized ticketing transaction data. The route revenue sharing unit is used to determine the user's travel route based on the standardized ticketing transaction data, and to determine the revenue sharing details for each operating entity based on the standardized ticketing transaction data, the clearing rules, and the travel route. The reconciliation and auditing unit is used to obtain reconciliation data from each operating entity, compare the revenue distribution details with the reconciliation data to obtain the transaction reconciliation results for each operating entity, and perform transaction auditing based on the transaction reconciliation results for each operating entity to obtain the transaction audit results for each operating entity.

3. The system according to claim 1, characterized in that, The payment adaptation module includes: The real-name account creation unit is used to obtain the user's identity verification information, verify the identity verification information to obtain the identity verification result, and establish the user's unified real-name account based on the identity verification result; The credential binding unit is used to obtain different access credentials and establish the binding relationship between the unified real-name account and the different access credentials.

4. The system according to claim 1, characterized in that, The system also includes: an operations management module; The operations management module includes: The operational data collection unit is used to acquire multi-dimensional operational data; The operations data management unit is used to determine operations optimization suggestions based on the multi-dimensional operations data.

5. The system according to claim 1, characterized in that, The system also includes: a code issuance management module; The code issuance management module includes: The request processing unit is used to obtain a code sending request from the user's terminal device; The data assembly unit is used to assemble the data to be signed according to the code issuance request; The signature generation unit is used to sign the data to be signed to obtain signature data, and generate a ride QR code based on the signature data.

6. The system according to claim 1, characterized in that, The system also includes: a trip management module; The trip management module includes: The data acquisition unit is used to acquire the user's gate passage transaction data from the gate device; the gate passage transaction data includes the user's identifier, the gate device's identifier, timestamp, and site information. A security verification unit is used to verify the legality of the gate passage transaction data and obtain a legality verification result; the legality verification result includes legal or illegal. The billing and settlement unit is used to obtain gate passage transaction data whose legality verification result is valid, determine the fee amount according to the preset billing rules and the exit station and entry station in the station information, and make payment and deduction according to the fee amount.

7. The system according to claim 1, characterized in that, The system also includes: an anti-duplication module; The anti-duplication module includes: The station-level duplicate verification unit is used to obtain the user's identifier from the gate transaction data uploaded by the gate device when the user enters the station, compare the user's identifier with historical entry records within a preset time period, and determine whether the user's identifier exists in the historical entry records. If the user's identifier exists in the historical entry records, it is determined that the user has repeated entry and exit behavior; if the user's identifier does not exist in the historical entry records, it is determined that the user has not repeated entry and exit behavior. A network-level duplicate verification unit is used to obtain the user's identifier from the gate transaction data uploaded by the gate device and to obtain the entire network entry data when the user enters the station. The user's identifier is compared with the entire network entry data to determine whether the user's identifier exists in the entire network entry data. If the user's identifier exists in the entire network entry data, it is determined that the user has repeated entry and exit behavior; if the user's identifier does not exist in the entire network entry data, it is determined that the user has not repeated entry and exit behavior.

8. The system according to claim 1, characterized in that, The system also includes: a key management module; The key management module includes: A key generation and distribution unit is used to generate keys corresponding to each operating entity and distribute the keys to the corresponding operating entities. The key validity verification unit is used to verify the validity of keys in ticketing transaction data involving at least two operating entities.

9. A method for interconnecting and interoperating ticketing systems for intercity and regional rail transit, characterized in that, The method includes: Establish unified billing rules that are compatible with all operating entities; Ticket transaction data is obtained from the train dispatching system and gate transaction system of each operating entity, and the ticket transaction data is cleared and settled according to the preset clearing rules to obtain the clearing and settlement results; Establish a unified real-name account for users, and establish the binding relationship between the unified real-name account and different access credentials; Obtain the user's entry / exit request; invoke the binding relationship based on the entry / exit request, and verify the validity of the access credential in the user's entry / exit request based on the binding relationship.

10. An electronic device, characterized in that, include: The system includes a memory and a processor, which are interconnected and communicate with each other. The memory stores computer instructions, and the processor executes the computer instructions to perform the intercity regional public transport ticketing interconnection method for rail transit as described in claim 9.

Images