Rail transit charging method, device, equipment, storage medium and product

Abstract

The present application discloses a rail transit charging method, device, equipment, storage medium and product, relating to the technical field of ticket charging. The method receives first scene identification information sent by an inbound turnstile through a mobile phone NFC module, and obtains inbound station identification information based on the first scene identification information and a preset intelligent contactless proximity protocol iTAP; receives second scene identification information sent by a transfer turnstile, and obtains transfer station identification information based on the second scene identification information; receives third scene identification information sent by an outbound turnstile, and determines trip cost information based on the third scene identification information, the inbound station identification information and the transfer station identification information, so that when a user travels across cities and different types of rail transit, they only need to swipe their mobile phone NFC module to pass through, and real-time contactless charging can be realized, greatly improving the efficiency and accuracy of cross-city rail transit charging.

Description

Technical Field

[0001] The present application relates to the technical field of ticketing and billing, and in particular to a rail transit billing method, device, equipment, storage medium and product. Background Art

[0002] When passengers travel across cities, there are multiple transfer routes for the same trip. Different operators use different mileage pricing rules, which leads to the route selection directly affecting the ticket cost sharing and fund clearing. Accurate billing requires complete information on passenger transfer nodes, otherwise it will cause profit distribution disputes and system clearing errors among operators.

[0003] The current technical solutions are mainly divided into two categories: non-sensing transfer and sensing transfer: the former relies on UWB chips or face recognition technology. Although it can automatically record the transfer trajectory, there is a risk of face data privacy leakage, and the penetration rate of UWB devices is insufficient, making it difficult to meet the needs of large-scale applications; the latter uses boarding codes or mobile transportation cards to achieve transfer records, but it requires full transmission of user travel data across cities, resulting in complex background system architecture and significant delays in outbound billing. At the same time, users need to manually switch transportation cards between multiple simulated cards, which is cumbersome and easy to cause misselection. In addition, existing solutions generally have core defects such as the contradiction between privacy protection and technology popularization, low efficiency of cross-system collaboration, and fragmented user experience, which restricts the large-scale implementation of accurate billing in intercity rail transit mixed travel scenarios.

[0004] The above contents are only used to assist in understanding the technical solution of the present application and do not constitute an admission that the above contents are prior art. Summary of the invention

[0005] The main purpose of this application is to provide a rail transit billing method, device, equipment, storage medium and computer program product, aiming to improve the efficiency and accuracy of inter-city rail transit billing and enhance user experience.

[0006] To achieve the above purpose, the present application proposes a rail transit charging method, which is applied to a mobile phone NFC module and includes:

[0007] Receiving first scene identification information sent by the entry gate, and acquiring entry site identification information based on the first scene identification information and a preset intelligent non-contact proximity protocol;

[0008] Receiving second scene identification information sent by the transfer gate, so as to obtain transfer station identification information based on the second scene identification information;

[0009] Receive the third scene identification information sent by the exit gate to determine the travel cost information based on the third scene identification information, the entry station identification information and the transfer station identification information.

[0010] In one embodiment, the step of receiving the first scenario identification information sent by the inbound turnstile and obtaining the inbound station identification information based on the first scenario identification information and a preset intelligent contactless proximity protocol includes:

[0011] Receiving the first scenario identification information sent by the inbound turnstile, and selecting a target urban transportation card according to the first scenario identification information and the intelligent contactless proximity protocol;

[0012] Sending the card information of the target urban transportation card to the inbound turnstile, so that the inbound turnstile performs inbound verification according to the card information and returns the inbound station identification information after the verification passes;

[0013] Receiving the inbound station identification information returned by the inbound turnstile.

[0014] In one embodiment, the step of receiving the first scenario identification information sent by the inbound turnstile and selecting a target urban transportation card according to the first scenario identification information and the intelligent contactless proximity protocol includes:

[0015] Receiving the first scenario identification information sent by the inbound turnstile, and selecting an NFC transportation card in the preset NFC cards according to the first scenario identification information and the intelligent contactless proximity;

[0016] Selecting the target urban transportation card in the NFC transportation card according to the pre-received city identification information, where the first scenario identification information and the city identification information are generated by the inbound turnstile in response to the NFC signal of the NFC module.

[0017] In one embodiment, the step of receiving the second scenario identification information sent by the transfer turnstile and obtaining the transfer station identification information based on the second scenario identification information includes:

[0018] Receiving the second scenario identification information sent by the transfer turnstile, where the second scenario identification information is generated by the transfer turnstile in response to the NFC signal of the NFC module;

[0019] In response to the second scenario identification information sent by the transfer turnstile, sending the card information of the target urban transportation card to the transfer turnstile, so that the transfer turnstile performs transfer verification according to the card information and returns the transfer station identification information after the verification passes;

[0020] Receiving the transfer station identification information and recording the transfer time.

[0021] In one embodiment, the step of sending the card information of the target urban transportation card to the transfer turnstile in response to the second scenario identification information includes:

[0022] In response to the second scenario identification information, select an NFC transportation card from the preset NFC cards and obtain the card status. The NFC transportation card includes several urban transportation cards;

[0023] Among several urban transportation cards, determine the urban transportation cards with the card status of "already entered the station" as the candidate transportation cards and obtain the entry time of the candidate transportation cards;

[0024] If the candidate transportation cards are not unique, determine the candidate transportation card with the most recent entry time as the target urban transportation card, and send the card information of the target urban transportation card to the transfer turnstile.

[0025] In one embodiment, the step of receiving the third scenario identification information sent by the exit turnstile to determine the trip cost information based on the third scenario identification information, the entry station identification information, and the transfer station identification information includes:

[0026] In response to the third scenario identification information sent by the exit turnstile, send the transportation card information of the target urban transportation card to the exit turnstile, so that the exit turnstile performs card verification based on the transportation card information. After the card verification is passed, send the trip information corresponding to the target urban transportation card to the turnstile charging system for charging, receive the trip cost information returned by the turnstile charging system, and send the trip cost information to the mobile phone NFC module;

[0027] Receive the trip cost information sent by the exit turnstile.

[0028] In addition, to achieve the above object, the present application also proposes a rail transit charging device, which includes:

[0029] An entry module, configured to receive the first scenario identification information sent by the entry turnstile, and obtain the entry station identification information based on the first scenario identification information and the preset intelligent passive proximity protocol;

[0030] A transfer module, configured to receive the second scenario identification information sent by the transfer turnstile, and obtain the transfer station identification information based on the second scenario identification information;

[0031] An exit module, configured to receive the third scenario identification information sent by the exit turnstile, and determine the trip cost information based on the third scenario identification information, the entry station identification information, and the transfer station identification information.

[0032] In addition, to achieve the above object, the present application further provides a rail transit charging device, which includes: a memory, a processor, and a computer program stored on the memory and executable on the processor, and the computer program is configured to implement the steps of the rail transit charging method as described above.

[0033] In addition, to achieve the above object, the present application further provides a storage medium, which is a computer-readable storage medium, and a computer program is stored on the storage medium, and when the computer program is executed by a processor, the steps of the rail transit charging method as described above are implemented.

[0034] In addition, to achieve the above object, the present application further provides a computer program product, which includes a computer program, and when the computer program is executed by a processor, the steps of the rail transit charging method as described above are implemented.

[0035] One or more technical solutions proposed by the present application receive first scenario identification information sent by an inbound turnstile through a mobile phone NFC module, so as to obtain inbound station identification information based on the first scenario identification information and a preset intelligent contactless proximity protocol iTAP; receive second scenario identification information sent by a transfer turnstile, so as to obtain transfer station identification information based on the second scenario identification information; receive third scenario identification information sent by an outbound turnstile, so as to determine trip cost information based on the third scenario identification information, the inbound station identification information, and the transfer station identification information, so that when a user travels across cities and different types of rail transit, they only need to swipe their mobile phone NFC module to pass through, and real-time contactless charging can be realized, greatly improving the efficiency and accuracy of cross-city rail transit charging. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] The drawings here are incorporated into the specification and form a part of this specification, showing embodiments consistent with the present application, and are used together with the specification to explain the principles of the present application.

[0037] To more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings required for use in the description of the embodiments or the prior art. Obviously, for those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0038] Figure 1 It is a schematic flowchart provided for Embodiment 1 of the rail transit charging method of the present application;

[0039] Figure 2 It is a schematic flowchart provided for Embodiment 2 of the rail transit charging method of the present application;

[0040] Figure 3Schematic diagram of the module structure of the rail transit charging device according to the embodiment of the present application;

[0041] Figure 4 Schematic diagram of the device structure of the hardware operating environment involved in the rail transit charging method according to the embodiment of the present application.

[0042] The realization of the purpose, functional characteristics and advantages of the present application will be further described with reference to the accompanying drawings in combination with the embodiments. Specific embodiments

[0043] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of the present application and are not used to limit the present application.

[0044] In order to better understand the technical solutions of the present application, the following will be described in detail in combination with the accompanying drawings of the specification and specific embodiments.

[0045] The main solution of the embodiment of the present application is: based on the iTAP technology, accurate charging for mixed travel of urban and intercity rail transit is realized. The solution solves the problems of privacy and security, cumbersome operation, slow outbound speed, etc. existing in the prior art by deploying devices supporting the iTAP technology at the mobile phone end and the gate end, as well as corresponding logic processing processes.

[0046] First, in the inbound link, the user brings the mobile phone close to the NFC base station of the inbound gate. After the NFC base station of the inbound gate senses the mobile phone NFC signal, it will send the city identification information and the inbound scene identification information to the mobile phone NFC module. The mobile phone NFC module automatically filters out the transportation card according to the received scene identification information, excluding other types of cards such as bank cards or access control cards. Then, according to the city identification information, it selects the transportation card issued by the city where the gate is located, because using the transportation card issued by the local city usually can enjoy preferential treatment. After selecting the transportation card, the mobile phone sends the information of the card to the gate, and the gate verifies the authenticity and status of the card. If the verification passes, the gate will send the inbound station identification information back to the mobile phone end and write it into the selected transportation card, and record the inbound time. At this time, the status of the transportation card becomes inbound.

[0047] In the transfer link, when the user arrives at the transfer station, bring the mobile phone close to the NFC base station of the transfer gate again. After the NFC base station of the transfer gate senses the mobile phone NFC signal, it sends the transfer scene identification information to the mobile phone NFC module. The mobile phone NFC module automatically selects the transportation card according to the transfer scene identification information and judges the status of the already inbound transportation card. If there are multiple already inbound transportation cards, the mobile phone will select the card with the latest inbound time by comparing the inbound time. After selection, the mobile phone sends the information of the transportation card to the gate. After verification, the gate sends the transfer station identification information back to the mobile phone end and writes it into the transportation card, and records the transfer time.

[0048] When exiting the station, the user places the mobile phone close to the NFC base station of the exit gate. After the NFC base station of the exit gate senses the NFC signal of the mobile phone, it sends the scene identification information to the NFC module of the mobile phone. According to the scene identification information, the NFC module of the mobile phone automatically selects the transportation card that has entered the station and has the transfer station identification, and sends the card information to the gate. After the gate verifies the card information, it sends the information of the entry station, transfer station, and exit station to the gate billing system. The gate billing system queries the cost of each trip according to the stored fare table and adds them up to calculate the total cost, and also calculates the balance in the transportation card after the trip. The NFC base station of the gate sends the balance information in the card back to the mobile phone. After the mobile phone updates the balance of the transportation card, it notifies the gate that the deduction is successful, and the gate opens the door immediately. In addition, after exiting the station, the user can query the entire trip information of the transportation card in the mobile wallet APP, including detailed information such as the entry city, entry station, transfer station, transfer scene, exit city, exit station, and total trip cost. This solution based on iTAP technology not only achieves accurate billing, but also improves user experience, reduces the complexity of the background system and the security risks of data transmission.

[0049] Since the existing technologies are mainly divided into two categories: non-sensing transfer and sensing transfer: the former relies on UWB chips or face recognition technology. Although it can automatically record the transfer trajectory, there is a risk of face data privacy leakage, and the penetration rate of UWB devices is insufficient, it is difficult to meet the needs of large-scale applications; the latter uses boarding codes or mobile transportation cards to realize transfer records, but it is necessary to transmit user travel data across cities in full, resulting in complex background system architecture and significant delays in outbound billing. At the same time, users need to manually switch transportation cards between multiple simulated cards, which is cumbersome and easy to cause misselection. In addition, the existing solutions generally have core defects such as the contradiction between privacy protection and technology popularization, low efficiency of cross-system collaboration, and fragmented user experience, which restricts the large-scale implementation of accurate billing in intercity rail transit mixed travel scenarios.

[0050] The present application provides a solution, which receives the first scene identification information sent by the entry gate through the NFC module of the mobile phone, so as to obtain the entry site identification information based on the first scene identification information and the preset intelligent contactless proximity protocol iTAP; receives the second scene identification information sent by the transfer gate, so as to obtain the transfer site identification information based on the second scene identification information; receives the third scene identification information sent by the exit gate, so as to determine the travel cost information based on the third scene identification information, the entry site identification information and the transfer site identification information, so that when the user travels across cities and across rail transit, he only needs to swipe the card with the NFC module of the mobile phone to pass, and the real-time billing can be realized without any feeling, which greatly improves the efficiency and accuracy of cross-city rail transit billing.

[0051] It should be noted that the execution subject of this embodiment can be a computing service device with data processing, network communication, and program running functions, such as a tablet computer, a personal computer, a mobile phone, etc., or an electronic device, a rail transit billing system, etc. that can implement the above functions. Hereinafter, taking the rail transit billing system as an example, this embodiment and the following embodiments will be described.

[0052] Based on this, an embodiment of the present application provides a rail transit billing method, referring to Figure 1 , Figure 1 which is a schematic flowchart of the first embodiment of the rail transit billing method of the present application.

[0053] In this embodiment, the method is applied to the mobile phone NFC module, and includes steps S1000 to S3000:

[0054] Step S1000: Receive the first scenario identification information sent by the inbound gate, and obtain the inbound station identification information based on the first scenario identification information and the preset intelligent touchless and awareless proximity protocol iTAP;

[0055] It should be noted that in the embodiment of the present application, the intelligent touchless and awareless proximity protocol iTAP (intelligent Touchless&Awareless Proximity) refers to an enhanced NFC communication protocol that allows the gate end to actively push structured scenario data to the mobile terminal to achieve two-way information interaction and intelligent decision-making between devices. The first scenario identification information refers to the encoded data pre-configured by the gate end according to the operation scenario type, including the city identification (such as "sz" representing City A), the scenario type identification (such as "00" representing the urban subway scenario), and the inbound station number (such as "S001"). The inbound station identification information is specifically the unique code of the station to which the gate belongs in the rail transit network, and is used to locate the starting point of the passenger's journey.

[0056] In the embodiment of the present application, the intelligent screening of the transportation card and the writing of the inbound data are realized through the iTAP protocol: the gate end actively pushes the first scenario identification information through the NFC base station, triggers the mobile phone NFC module to automatically exclude non-transportation virtual cards (such as access control cards, bank cards) according to the scenario type, and matches the corresponding city transportation card stored locally in combination with the city identification (such as the national interoperable card issued in City A), thereby avoiding the user's manual card switching operation. In a possible implementation manner, the first scenario identification information is dynamically generated by the NFC base station in the inbound gate, and its encoding rule includes the combination of the city administrative division code, the operation entity code, and the station serial number.

[0057] For example, in a specific embodiment, when the user holds the mobile phone close to the entry gate of Station A of the subway in City A, the NFC base station of the gate sends the first scene identification information containing "sz-00-A001" through the iTAP protocol. After the NFC module of the mobile phone parses this information, it automatically filters out the traffic cards in City A that have been activated and sends the card information back to the gate to complete the authentication. After the gate verification passes, it returns "A001" as the entry station identification, and the mobile phone writes this identification and the entry time into the storage area of the traffic card.

[0058] Step S2000: Receive the second scene identification information sent by the transfer gate to obtain the transfer station identification information based on the second scene identification information;

[0059] It should be noted that in the embodiments of the present application, the second scene identification information refers to the composite coding data of the transfer scenario, including the transfer type identification (such as "cs-cj" indicating the transfer from the urban subway to the intercity rail) and the transfer station number (such as "H001"). The transfer station identification information is the topological node coding of the transfer channel in the cross-line network, which is used to mark the passenger path switching point.

[0060] In the embodiments of the present application, the problem of abnormal occupation of multiple cards is solved by dynamically locking the valid traffic card and recording the transfer path: after the NFC module of the mobile phone receives the second scene identification information, it preferentially selects the traffic card in the "already entered the station" state. If there are multiple abnormally entered cards, the card with the most recent valid entry is selected based on the entry timestamp to ensure the continuity of the transfer link. In a possible implementation, the NFC base station of the transfer gate generates the second scene identification information according to the physical location and the relationship of the connected operation lines. For example, "H001-cs-cj" means transferring from the urban subway to the intercity rail at Station H001.

[0061] In addition, it should be noted that the card status management mechanism includes the entry status marking, timestamp writing, and automatic isolation of abnormal cards. When it is detected that there are two or more traffic cards in the "already entered the station" state in the same device, the system will trigger the timestamp comparison logic to exclude the historical abnormal entry records.

[0062] For example, in a specific embodiment, when the user transfers at the South Station of City B, the transfer gate sends the second scene identification information of "gz-cj-H005". After the NFC module of the mobile phone parses it, it automatically selects the activated traffic card in City B (because its entry time is earlier than the abnormally staying card in City A), and writes the transfer station "H005" and the transfer time into the card, forming a travel link of "entry A001 → transfer H005".

[0063] Step S3000: Receive the third scenario identification information sent by the outbound turnstile, and determine the trip fare information based on the third scenario identification information, the inbound station identification information, and the transfer station identification information.

[0064] It should be noted that in the embodiment of the present application, the third scenario identification information includes an outbound scenario type identifier (e.g., "01" indicates intercity rail outbound) and an outbound station number (e.g., "C002"). The trip fare information refers to the total fare calculated by the segment accumulation billing rule, specifically the sum of the fares from the entry station to the first transfer point, between each transfer point, and from the last transfer point to the exit station.

[0065] In this embodiment, a local billing engine is used to achieve fast fare clearing. After the outbound turnstile verifies the validity of the transportation card, it extracts the complete trip chain (inbound station, transfer point sequence, and timestamp) stored in the card. The turnstile-end billing system performs segment matching calculations based on a preset fare table, avoiding delays and system coupling caused by cross-city data transmission. In a possible implementation manner, the fare table is stored in a matrix structure, with the row index being the starting station, the column index being the ending station, and the matrix element being the fare for the corresponding interval, supporting seamless integration of different pricing rules for multiple operating entities.

[0066] For example, in a specific implementation manner, when the user exits the station, the turnstile sends the third scenario identification information of "dg-01-D003", and the mobile phone returns the information of the transportation card in City A containing the transfer path of "A001→H005→H008". The turnstile billing system queries the fare table, calculates the fare for the subway section from "A001 to H005", the fare for the intercity section from "H005 to H008", and the fare for the urban rail section from "H008 to D003" respectively, accumulates them to generate the total fare and deducts it from the card balance in real time, and at the same time writes back the deduction result and trip details to the mobile phone.

[0067] In a feasible implementation manner, step S1000 may include steps S1100~S1300:

[0068] Step S1100: Receive the first scenario identification information sent by the inbound turnstile, and select the target city transportation card according to the first scenario identification information and the intelligent contactless proximity protocol;

[0069] Step S1200: Send the card information of the target city transportation card to the inbound turnstile, so that the inbound turnstile performs inbound verification according to the card information and returns the inbound station identification information after the verification passes;

[0070] Step S1300: Receive the inbound station identification information returned by the inbound turnstile.

[0071] It should be noted that in this embodiment, the first scenario identification information is composite encoded data actively pushed by the entry gate through the iTAP protocol, specifically including a city identifier (such as "sz" representing City A), a scenario type identifier (such as "00" representing the urban subway scenario), and a gate location code (such as "A001" which is the unique station number). The iTAP protocol (Intelligent Touchless Access Protocol) refers to the new generation of NFC technology, whose core lies in allowing the gate side to store structured data and actively push it to the mobile terminal through near-field communication, triggering intelligent decision-making on the terminal side. The target city transportation card refers to the virtual transportation card in the user's mobile wallet that matches the current city's operation entity. For example, in the subway scenario of City A, the national interoperable card issued by City A is automatically selected.

[0072] When the user's mobile phone approaches the entry gate, the gate side actively pushes the first scenario identification information containing the city attributes and scenario type based on the iTAP protocol, triggering the mobile phone's NFC module to automatically exclude non-transportation virtual cards (such as bank cards and access control cards), and preferentially screen the corresponding city transportation cards stored locally. In a possible implementation manner, the city identifier adopts the administrative division code of GB / T 2260-2007. For example, "4403" represents City A, and the scenario type identifier is defined by the operation entity. For example, "01" represents the intercity rail scenario. The entry verification process includes verifying the authenticity of the transportation card (by matching the card number and the encryption key) and checking the status (such as insufficient balance and blacklist interception). After successful verification, the gate side returns the standardized station code corresponding to the physical location to the mobile phone side.

[0073] In addition, it should be noted that the card information includes the unique identification code of the transportation card (such as "SZ-IC-00123456"), the dynamic encryption key, and the current balance data. When the entry station identification information is written into the transportation card storage area, a timestamp accurate to milliseconds is synchronously recorded for subsequent time sequence verification of the transfer path. This mechanism can avoid billing errors caused by the residual historical entry records when users travel across lines between multiple cities.

[0074] For example, in a feasible implementation manner, when the user enters the subway at Station A in City A, the gate NFC base station sends the first scenario identification information "sz-00-FT001" through the iTAP protocol. After parsing by the mobile phone's NFC module, the bank cards and access control cards in the wallet are automatically filtered, and the activated virtual transportation card of City A (card number "SZ-IC-00889900") is selected and its card information is sent to the gate. After verifying the validity and balance status of the card, the gate returns the entry station identification "FT001" and the timestamp "2024-05-20 08:30:15.255". The mobile phone side writes the above information into the transportation card storage area, completes the entry record, and activates the card's entry status.

[0075] In a feasible implementation, step S1100 may include steps S1110 to S1120:

[0076] Step S1110: Receive the first scenario identification information sent by the inbound turnstile, and select the NFC transportation card in the preset NFC card according to the first scenario identification information and the intelligent passive proximity;

[0077] Step S1120: Select the target city transportation card in the NFC transportation card according to the pre-received city identification information. The first scenario identification information and the city identification information are generated by the inbound turnstile in response to the NFC signal of the NFC module.

[0078] It should be noted that in this embodiment, the first scenario identification information is a composite encoded data actively pushed by the inbound turnstile based on the iTAP protocol, including a city identification (such as "gz" representing City B), a scenario type identification (such as "01" representing the intercity rail scenario), and a turnstile physical location code (such as "GZCR001"). The NFC transportation card refers to the virtualized transportation payment card already opened in the user's mobile phone wallet, including the national interoperable card issued in multiple cities. Its card data is stored in the mobile phone security chip and supports NFC near-field communication reading and writing. The target city transportation card specifically refers to the virtual card matching the current inbound city operation entity. For example, in the intercity rail scenario of City B, the transportation card issued by City B is automatically selected to ensure the enjoyment of local riding discounts.

[0079] In this embodiment, accurate card selection is achieved through a two-level screening mechanism. First, after the mobile phone NFC module receives the first scenario identification information, non-transportation cards (such as bank cards and access control cards) are filtered according to the scenario type identification (such as "01"), and only the NFC transportation card set is retained. Secondly, combined with the city identification information (such as "gz"), the locally issued cards are matched from the transportation card set to avoid manual switching operations by users due to holding transportation cards of multiple cities. In a possible implementation, the city identification information uses the administrative division code associated with the turnstile geographical location (such as "4401" corresponding to City B), and the local attribute of the NFC transportation card is automatically mapped through the card surface issuing institution code (such as "GD-GZ-IC" representing the transportation card of City B, Province X).

[0080] In addition, it should be noted that the iTAP protocol adopts a dynamic encryption mechanism during the communication process. The first scenario identification information generated by the turnstile end contains a timestamp signature to prevent replay attacks. When the mobile phone NFC module parses the city identification, it preferentially matches the transportation card with the highest local discount. For example, when the user holds both the ordinary transportation card of City B and the same-city discount card of City B and City C at the same time, the latter is automatically selected to reduce the travel cost. This mechanism is implemented through the "preferential priority" field in the card metadata, which is written by the card issuing institution when opening the card.

[0081] For example, in a feasible embodiment, when the user enters the B City South Station intercity rail turnstile with a mobile phone, the turnstile NFC base station sends the first scenario identification information "gz-01-GZCR001" through the iTAP protocol. After the mobile phone NFC module parses it, it first filters out all NFC transportation cards (such as B City Card, A City Card, C City Card) according to the scenario type identification "01", and then matches the local cards based on the city identification "gz". If it is detected that the user holds both a "B City subway ordinary card" and a "regional co-branded discount card" at the same time, the co-branded card will be automatically selected according to the preset preferential priority (the co-branded card has a higher priority than the ordinary card). After selecting the card, the mobile phone terminal sends the co-branded card information (including the encrypted card number and dynamic key) to the turnstile. After the turnstile verifies and passes, it returns the inbound station identification "GZCR001" and the timestamp "2024-05-20 09:15:30.500" to complete the writing of the inbound record.

[0082] This embodiment provides a rail transit charging method. By receiving the first scenario identification information sent by the inbound turnstile through the mobile phone NFC module, based on the first scenario identification information and the preset intelligent contactless proximity protocol iTAP, the inbound station identification information is obtained; receiving the second scenario identification information sent by the transfer turnstile, based on the second scenario identification information, the transfer station identification information is obtained; receiving the third scenario identification information sent by the outbound turnstile, based on the third scenario identification information, the inbound station identification information and the transfer station identification information, the itinerary cost information is determined, so that when the user travels across cities and different types of rail transit, only the mobile phone NFC module needs to swipe the card to pass, and the contactless real-time charging can be realized, greatly improving the efficiency and accuracy of cross-city rail transit charging.

[0083] Based on the first embodiment of the present application, in the second embodiment of the present application, the same or similar content as in the above-mentioned embodiment 1 can be referred to the above introduction and will not be repeated hereinafter. On this basis, please refer to Figure 2 wherein, step S2000 of the rail transit charging method further includes steps S2100 to S2300:

[0084] Step S2100: Receive the second scenario identification information sent by the transfer turnstile, and the second scenario identification information is generated by the transfer turnstile in response to the NFC signal of the NFC module;

[0085] Step S2200: In response to the second scenario identification information sent by the transfer turnstile, send the card information of the target city transportation card to the transfer turnstile, so that the transfer turnstile performs transfer verification according to the card information and returns the transfer station identification information after the verification passes;

[0086] Step S2300: Receive the transfer station identification information and record the transfer time.

[0087] It should be noted that in this embodiment, the second scenario identification information is dynamic encoded data generated by the transfer gate based on the iTAP protocol, including the transfer type (such as "intercity rail transfer to urban subway"), the unique number of the transfer station (such as "HCZ-001"), and the operator identification (such as "GZ-CJ" representing the intercity in City B). The transfer verification refers to the validity verification of the transportation card and the verification of the transfer permission by the transfer gate, including the matching of the card status (such as whether it is in the state of having entered the station but not exited) and the cross-line transfer rule (such as whether it belongs to the jointly operated line). The transfer station identification information is the topological node code of the transfer channel in the cross-line network (such as "HCZ-001→SZ-MT-005" represents transferring from the intercity station HCZ-001 to the subway station SZ-MT-005 in City A).

[0088] The mobile phone NFC module realizes the construction of the transfer link through the dynamic card locking and path tracking mechanism: when the user holds the mobile phone close to the transfer gate, the gate actively pushes the second scenario identification information based on the iTAP protocol, triggering the mobile phone to preferentially screen the transportation cards in the active state (that is, the cards that have been recorded as entering the station but not completed the exit), and excluding the historical abnormal entry records through timestamp comparison. In a possible implementation manner, the transfer type identification adopts a multi-level coding structure. For example, "01-02" represents transferring from intercity (01) to subway (02), and the transfer station code is generated by combining the line code (such as "GZ-CJ-L1" representing Line 1 of the intercity in City B) and the node serial number (such as "N15").

[0089] In addition, it should be noted that the card information contains encrypted itinerary chain data (such as the entry time, transfer times limit identification). The transfer gate verifies the integrity of the itinerary chain through a decryption algorithm during the verification process, and judges the transfer legality based on the jointly operated rule library (such as whether it is within the valid transfer time window). If it is detected that the transfer path violates the preset rules (such as exceeding the maximum number of transfers or transferring across non-cooperating lines), the gate will trigger an alarm and refuse to write the transfer identification.

[0090] For example, in a feasible implementation, when a user transfers from Station b of the intercity rail in City D to Station d of the subway in City A, the transfer gate sends the second scenario identification information "cj-cs-HCZ-008-DG-CJ". After being parsed by the mobile phone NFC module, the activated intercity transportation card of City D (card number "DG-IC-00998877") is automatically selected, and the card information is sent to the gate. After the gate verifies that the card status is normal and complies with the cross-city transfer rules, it returns the transfer station identification "HCZ-008→SZ-MT-008" and the transfer time "2024-05-20 12:30:45.800". The mobile phone terminal writes the above information into the storage area of the transportation card, forming a travel link of "boarding at DG-CJ-001→transfer at HCZ-008→transfer at SZ-MT-008", providing complete path data for subsequent segmented billing.

[0091] In a feasible implementation, "selecting the target city transportation card based on the second scenario identification information" in step S2200 may include steps S2210 to S2230:

[0092] Step S2210: In response to the second scenario identification information, select the NFC transportation card in the preset NFC cards and obtain the card status. The NFC transportation card includes several city transportation cards;

[0093] Step S2220: Among the several city transportation cards, determine the city transportation card with the card status of "already boarded" as the candidate transportation card and obtain the boarding time of the candidate transportation card;

[0094] Step S2230: If the candidate transportation cards are not unique, determine the candidate transportation card with the most recent boarding time as the target city transportation card, and send the card information of the target city transportation card to the transfer gate.

[0095] It should be noted that in this embodiment, the second scenario identification information is composite coding data generated by the transfer gate based on the iTAP protocol, including transfer type identification (such as "cs-cj" indicating transferring from the city subway to the intercity rail), unique transfer station number (such as "hcz002"), and operation entity identification (such as "sz" indicating City A). The NFC transportation card refers to a collection of multi-city virtual transportation cards already activated in the user's mobile phone wallet, which is stored in a secure chip and supports NFC reading and writing and iTAP protocol communication. The card status refers to the current usage status mark of the transportation card, including "already boarded", "already exited", "abnormally locked", etc., and is used to determine whether the card participates in the current travel link.

[0096] This step realizes multi-card conflict resolution through a dynamic screening and timestamp comparison mechanism: when the user brings the mobile phone close to the transfer turnstile, after the mobile phone NFC module receives the second scenario identification information, it first filters out the NFC transportation card set according to the transfer type identification (such as "cs-cj"), and then traverses all the cards and extracts the card status field, only retaining the cards in the "already entered the station" status as the candidate set. If there are multiple eligible cards (such as multi-card activation caused by historical abnormal exits), the entry timestamps of each card are further compared, and the card with the most recent time is selected as the target city transportation card to ensure the continuity of the itinerary link and the accuracy of billing. In a possible implementation manner, the transfer type identification adopts a multi-layer coding structure. For example, in "01-02-001", the first two digits represent the current line type (01 is the subway), the middle two digits represent the target line type (02 is the intercity), and the last three digits are the transfer node serial number. The entry timestamp adopts the ISO 8601 standard format (such as "2024-05-20T14:30:45.500Z"), supporting millisecond-level accuracy comparison.

[0097] In addition, it should be noted that the card status management mechanism and timestamp writing are both automatically completed by the mobile phone NFC module. When it is detected that there are two or more transportation cards in the "already entered the station" status in the same device, the system will trigger an abnormal alarm and record the log for subsequent manual verification. This mechanism ensures data integrity through a hardware-level security chip, preventing malicious users from forging travel records by modifying timestamps.

[0098] For example, in a feasible implementation manner, when the user transfers from subway station a in City A to the intercity rail between City A and City B, the transfer turnstile sends the second scenario identification information "cs-cj-hcz002-sz". After parsing by the mobile phone NFC module, the subway card of City A (card number "SZ-IC-0088") and the intercity card of City B (card number "GZ-IC-0099") in the NFC transportation card set are filtered out. It is detected that the status of the subway card of City A is "already entered the station" (entry time "2024-05-20 14:25:30.200"), while the intercity card of City B is still in the "already entered the station" status due to the previous abnormal exit (entry time "2024-05-20 13:50:15.100"). The system automatically selects the subway card of City A as the target city transportation card, sends its card information to the turnstile for verification, and writes the transfer station identification "hcz002" and the transfer time "2024-05-20 14:35:00.500" to form a transfer record of "station a → hcz002", providing an accurate data basis for subsequent segment billing.

[0099] In a feasible implementation manner, step S3000 may include steps S3100 to S3300:

[0100] Step S3100: In response to the third scenario identification information sent by the outbound turnstile, send the transportation card information of the target urban transportation card to the outbound turnstile, so that the outbound turnstile verifies the card based on the transportation card information. After the card verification is passed, send the trip information corresponding to the target urban transportation card to the turnstile charging system for charging, receive the trip cost information returned by the turnstile charging system, and send the trip cost information to the mobile phone NFC module;

[0101] Step S3200: Receive the trip cost information sent by the outbound turnstile.

[0102] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the rail transit charging method of this application. Based on this technical concept, more forms of simple transformation are within the protection scope of this application.

[0103] It should be noted that in this embodiment, the third scenario identification information is dynamic coding data generated by the outbound turnstile based on the iTAP protocol, including the outbound scenario type identification (such as "01" indicating the intercity rail outbound scenario), the unique number of the outbound station (such as "DG-EXIT-003"), and the operation entity identification (such as "dg" indicating City D). The target urban transportation card refers to a virtual transportation card that is activated during the inbound and transfer processes and records a complete trip chain. It is stored in the mobile phone security chip and contains key data such as the inbound station, transfer node sequence, and timestamp. The turnstile charging system refers to a distributed computing module deployed locally at the outbound turnstile, which has a built-in urban intercity rail transit fare table and stores the sectional fares between stations in a matrix structure (such as the fare from Station a of the subway in City A to Transfer Station hcz001 is 5 yuan, and the fare from hcz001 to Intercity Station b in City D is 12 yuan).

[0104] This step realizes efficient clearing through end-side data aggregation and local charging: when the user holds the mobile phone close to the outbound turnstile, after the mobile phone NFC module receives the third scenario identification information, it automatically filters the target urban transportation cards that have been activated and contain a complete transfer path, and sends its encrypted card number, dynamic key, and trip chain data to the turnstile side. After the turnstile side decrypts and verifies the card's legitimacy, it extracts the inbound station, transfer station, and outbound station information in the trip chain, and the local charging system performs sectional cumulative calculation based on the fare table to avoid cross-city data transmission delay. In a possible implementation manner, the fare table is stored in a hash table structure, with the key being the combination of "starting station - ending station" (such as "sz-ft001→hcz001"), and the value being the fare for the corresponding interval, supporting high-speed query of different pricing rules for multiple operation entities.

[0105] In addition, it should be noted that the card verification process includes dynamic key matching (to prevent duplicate card attacks) and real-time blacklist comparison (such as lost card interception). If an illegal transfer node is detected in the itinerary chain (such as unauthorized cross-line transfer), the gate will trigger a security alarm and freeze the transaction, and return an error code to the mobile phone to prompt the user to handle it manually.

[0106] For example, in a feasible implementation, a user enters the subway station a in city A, transfers to the transfer station hcz001, and exits the intercity station b in city D. The exit gate sends the third scene identification information "cj-01-DG-EXIT-003". After parsing by the mobile phone NFC module, it automatically selects the city A transportation card (card number "SZ-IC-0088") that has recorded the itinerary chain of "station a→hcz001→station b", and sends the card information to the gate. After the gate verifies the validity of the card, it extracts the itinerary chain data and queries the fare table: the fare from station a to hcz001 for the subway section is 5 yuan, the fare from hcz001 to station b for the intercity section is 12 yuan, and the total fare is 17 yuan. The gate billing system deducts 17 yuan from the balance in the card, and returns the updated balance "83 yuan" and the itinerary details (including the segment fee list) to the mobile phone. The mobile phone updates the data in the card and notifies the gate that the deduction is successful, and the gate opens the door to let people pass. Users can view the detailed cost structure and deduction records of this trip in the mobile wallet APP.

[0107] In this embodiment, by receiving the second scene identification information sent by the transfer gate, the second scene identification information is generated by the transfer gate in response to the NFC signal of the NFC module; based on the second scene identification information, the target city transportation card is selected, and the card information of the target city transportation card is sent to the transfer gate, so that the transfer gate performs transfer verification according to the card information and returns the transfer station identification information after passing; the transfer station identification information is received and the transfer time is recorded. Through the above method, the passenger's transfer information is determined according to the second scene identification information, and then the transfer information is used to charge in the final stage of determining the trip cost. There is no need for passengers to be charged after exiting the station and then re-entering the station, which greatly improves the billing efficiency of the cross-city travel stage.

[0108] Please refer to Figure 3 The present application also provides a rail transit charging device, the rail transit charging device comprising:

[0109] The station entry module 31 is used to receive the first scene identification information sent by the station entry gate, so as to obtain the station entry site identification information based on the first scene identification information and the preset intelligent non-contact proximity protocol iTAP;

[0110] The transfer module 32 is used to receive the second scene identification information sent by the transfer gate, so as to obtain the transfer station identification information based on the second scene identification information;

[0111] An outbound module 33, configured to receive third scenario identification information sent by an outbound turnstile, and determine trip fare information based on the third scenario identification information, the inbound station identification information, and the transfer station identification information.

[0112] The rail transit billing device provided by this application adopts the rail transit billing method in the above embodiment, and can solve the technical problems of rail transit billing. Compared with the prior art, the beneficial effects of the rail transit billing device provided by this application are the same as those of the rail transit billing method provided by the above embodiment, and other technical features in the rail transit billing device are the same as the features disclosed in the method of the above embodiment, and will not be elaborated here.

[0113] This application provides a rail transit billing device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein, the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the rail transit billing method in the first embodiment above.

[0114] Next, refer to Figure 4 , which shows a schematic structural diagram of a rail transit billing device suitable for implementing the embodiments of this application. The rail transit billing device in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptop computers, digital broadcast receivers, PDAs (Personal Digital Assistant), PADs (Portable Application Description), PMPs (Portable Media Player), in-vehicle terminals (such as in-vehicle navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 4 The rail transit billing device shown is only an example, and should not impose any limitations on the functions and usage scope of the embodiments of this application.

[0115] As Figure 4As shown, the rail transit charging device may include a processing device 1001 (such as a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to the program stored in the read-only memory 1002 or the program loaded from the storage device 1003 into the random access memory 1004. In the random access memory 1004, various programs and data required for the operation of the rail transit charging device are also stored. The processing device 1001, the read-only memory 1002, and the random access memory 1004 are connected to each other through a bus 1005. The input / output interface 1006 is also connected to the bus. Generally, the following systems can be connected to the input / output interface 1006: an input device 1007 including, for example, a touch screen, a touchpad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; an output device 1008 including, for example, a liquid crystal display (LCD: Liquid Crystal Display), a speaker, a vibrator, etc.; a storage device 1003 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 1009. The communication device 1009 can allow the rail transit charging device to communicate with other devices wirelessly or wiredly to exchange data. Although the figure shows a rail transit charging device with various systems, it should be understood that it is not required to implement or have all the shown systems. Instead, more or fewer systems can be implemented or had.

[0116] Specifically, according to the embodiments disclosed in the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present application include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program contains program codes for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from the network through the communication device, or installed from the storage device 1003, or installed from the read-only memory 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiments disclosed in the present application are executed.

[0117] The rail transit charging device provided by the present application adopts the rail transit charging method in the above embodiments. Compared with the prior art, the beneficial effects of the rail transit charging device provided by the present application are the same as those of the rail transit charging method provided by the above embodiments, and other technical features in the rail transit charging device are the same as those disclosed in the method of the previous embodiment, and will not be elaborated here.

[0118] It should be understood that the various parts disclosed in the present application can be implemented by hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in a suitable manner in any one or more embodiments or examples.

[0119] As described above, it is only the specific implementation manner of the present application. However, the protection scope of the present application is not limited thereto. Any person skilled in the art can easily think of changes or substitutions within the technical scope disclosed in the present application, and all of them should be covered by the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claimed rights.

[0120] The present application provides a computer-readable storage medium having computer-readable program instructions (i.e., computer programs) stored thereon, and the computer-readable program instructions are used to execute the rail transit charging method in the above embodiments.

[0121] The computer-readable storage medium provided by the present application may be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination of the above. More specific examples of the computer-readable storage medium may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM) or flash memory, optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the above. In this embodiment, the computer-readable storage medium may be any tangible medium that contains or stores a program, and the program can be used by or combined with an instruction execution system, device, or device. The program code contained on the computer-readable storage medium can be transmitted by any appropriate medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination of the above.

[0122] The above computer-readable storage medium may be included in the rail transit charging device; it may also exist separately and not be assembled into the rail transit charging device.

[0123] Computer program code for performing the operations of this application can be written in one or more programming languages or combinations thereof. The above-mentioned programming languages include object-oriented programming languages such as Java, Smalltalk, C++, and also include conventional procedural programming languages such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, executed as an independent software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer can be connected to the user's computer through any kind of network, including a local area network (LAN: Local Area Network) or a wide area network (WAN: Wide Area Network), or it can be connected to an external computer (for example, by using an Internet service provider to connect through the Internet).

[0124] The flowcharts and block diagrams in the accompanying drawings illustrate the possible architectures, functions, and operations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in the flowchart or block diagram can represent a module, a program segment, or a part of the code, and this module, program segment, or part of the code contains one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the accompanying drawings. For example, two consecutively represented blocks can actually be executed substantially in parallel, and they can sometimes be executed in the reverse order, depending on the functions involved. It should also be noted that each block in the block diagram and / or flowchart, and the combination of blocks in the block diagram and / or flowchart, can be implemented by a dedicated hardware-based system for performing the specified functions or operations, or can be implemented by a combination of dedicated hardware and computer instructions.

[0125] The modules described in the embodiments of this application can be implemented in software or in hardware. Among them, the name of the module does not constitute a limitation to the unit itself in some cases.

[0126] The readable storage medium provided by this application is a computer-readable storage medium. The computer-readable storage medium stores computer-readable program instructions (i.e., computer programs) for performing the above-mentioned rail transit charging method, and can solve the technical problems of rail transit charging. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided by this application are the same as those of the rail transit charging method provided by the above embodiments, and will not be elaborated here.

[0127] The present application also provides a computer program product, including a computer program which, when executed by a processor, implements the steps of the rail transit charging method as described above.

[0128] The computer program product provided by the present application can solve the technical problem of rail transit charging. Compared with the prior art, the beneficial effects of the computer program product provided by the present application are the same as those of the rail transit charging method provided by the above embodiments, and will not be elaborated here.

[0129] The above are only some embodiments of the present application, and thus do not limit the patent scope of the present application. Any equivalent structural transformation made under the technical concept of the present application by using the content of the specification and drawings of the present application, or direct / indirect application in other related technical fields, is included in the patent protection scope of the present application.

Claims

1. A rail transit billing method, characterized in that, The method is applied to the mobile phone NFC module and includes: Receiving first scenario identification information sent by the inbound turnstile to obtain inbound station identification information based on the first scenario identification information and a preset intelligent touchless proximity protocol; Among them, the step of receiving the first scenario identification information sent by the inbound turnstile to obtain the inbound station identification information based on the first scenario identification information and the preset intelligent touchless proximity protocol includes: Receiving the first scenario identification information sent by the inbound turnstile and selecting a target urban transportation card according to the first scenario identification information and the intelligent touchless proximity protocol; Sending the card information of the target urban transportation card to the inbound turnstile so that the inbound turnstile performs inbound verification according to the card information and returns the inbound station identification information after the verification passes; Receiving the inbound station identification information returned by the inbound turnstile; Receiving second scenario identification information sent by the transfer turnstile to obtain transfer station identification information based on the second scenario identification information; Receiving third scenario identification information sent by the outbound turnstile to determine trip cost information based on the third scenario identification information, the inbound station identification information, and the transfer station identification information.

2. The method according to claim 1, characterized in that, The step of receiving the first scenario identification information sent by the inbound turnstile and selecting a target urban transportation card according to the first scenario identification information and the intelligent touchless proximity protocol includes: Receiving the first scenario identification information sent by the inbound turnstile and selecting an NFC transportation card in the preset NFC cards according to the first scenario identification information and the intelligent touchless proximity protocol; Selecting the target urban transportation card in the NFC transportation card according to the pre-received city identification information, where the first scenario identification information and the city identification information are generated by the inbound turnstile in response to the NFC signal of the NFC module.

3. The method according to claim 1, characterized in that, The step of receiving the second scenario identification information sent by the transfer turnstile to obtain the transfer station identification information based on the second scenario identification information includes: Receiving the second scenario identification information sent by the transfer turnstile, where the second scenario identification information is generated by the transfer turnstile in response to the NFC signal of the NFC module; In response to the second scenario identification information sent by the transfer turnstile, sending the card information of the target urban transportation card to the transfer turnstile so that the transfer turnstile performs transfer verification according to the card information and returns the transfer station identification information after the verification passes; Receiving the transfer station identification information and recording the transfer time.

4. The method according to claim 3, characterized in that, The step of, in response to the second scenario identification information, sending the card information of the target urban transportation card to the transfer turnstile includes: In response to the second scenario identification information, selecting an NFC transportation card in the preset NFC cards and obtaining the card status, where the NFC transportation card includes several urban transportation cards; Determining the urban transportation card with the card status of the inbound state among the several urban transportation cards as the candidate transportation card and obtaining the inbound time of the candidate transportation card; If the candidate transportation card is not unique, determine the candidate transportation card with the latest entry time as the target city transportation card, and send the card information of the target city transportation card to the transfer turnstile.

5. The method according to claim 1, characterized in that, The step of receiving the third scenario identification information sent by the exit turnstile to determine the travel cost information based on the third scenario identification information, the entry station identification information, and the transfer station identification information includes: In response to the third scenario identification information sent by the exit turnstile, send the transportation card information of the target city transportation card to the exit turnstile, so that the exit turnstile performs card verification based on the transportation card information, and after the card verification is passed, send the travel information corresponding to the target city transportation card to the turnstile billing system for charging, receive the travel cost information returned by the turnstile billing system, and send the travel cost information to the mobile phone NFC module; Receive the travel cost information sent by the exit turnstile.

6. A rail transit charging device, characterized in that, The device includes: An entry module, configured to receive the first scenario identification information sent by the entry turnstile, and based on the first scenario identification information and a preset intelligent passive proximity protocol, obtain the entry station identification information; Wherein, the entry module is further configured to receive the first scenario identification information sent by the entry turnstile, and select the target city transportation card according to the first scenario identification information and the intelligent passive proximity protocol; Send the card information of the target city transportation card to the entry turnstile, so that the entry turnstile performs entry verification according to the card information and returns the entry station identification information after the verification is passed; Receive the entry station identification information returned by the entry turnstile; A transfer module, configured to receive the second scenario identification information sent by the transfer turnstile, and based on the second scenario identification information, obtain the transfer station identification information; An exit module, configured to receive the third scenario identification information sent by the exit turnstile, and determine the travel cost information based on the third scenario identification information, the entry station identification information, and the transfer station identification information.

7. A rail transit charging device, characterized in that, The device includes: a memory, a processor, and a computer program stored on the memory and executable on the processor, where the computer program is configured to implement the steps of the rail transit billing method according to any one of claims 1 to 5.

8. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium, and when the computer program is executed by the processor, it implements the steps of the rail transit billing method according to any one of claims 1 to 5.

9. A computer program product, characterized in that, The computer program product includes a computer program, and when the computer program is executed by the processor, it implements the steps of the rail transit billing method according to any one of claims 1 to 5.

Images