Multi-mode integrated travel ticket switching method and device based on embedded secure element, equipment and storage medium

Abstract

This application discloses a multi-mode travel integrated ticket switching method, device, equipment, and storage medium based on an embedded secure element, relating to the field of Internet of Things (IoT) technology for public transportation payment and travel services. The method includes: receiving travel contract information; determining virtual ticket identification information and corresponding transaction queue information based on travel segment information and traffic mode information in the travel contract information; determining ticket switching instruction information based on the virtual ticket identification information and the transaction queue information; and controlling the system to switch virtual tickets corresponding to the travel contract information one by one based on the ticket switching instruction information. This application can generate ticket switching instruction information within an embedded secure element to ensure that the switching timing is synchronized with the travel progress, and controls the system to switch virtual tickets one by one, achieving seamless multi-mode switching at the card end without manual operation or secondary card swiping, significantly improving the experience and efficiency of connecting travel.

Description

Technical Field

[0001] This application relates to the field of Internet of Things (IoT) technology for public transportation payment and travel services, and in particular to a method, apparatus, device, and storage medium for multi-modal travel ticket switching based on embedded security elements. Background Technology

[0002] As urbanization accelerates, the public's travel needs are becoming increasingly diversified. A single trip often requires combining multiple modes of transportation, such as subway, bus, shared bicycle, and taxi. At this time, users expect to achieve seamless connection and unified settlement across transportation modes through a single, convenient payment method, avoiding the cumbersome operation of carrying multiple physical cards or frequently switching between different apps, thereby improving the overall travel experience.

[0003] Currently, the existing practice requires users to download and use separate apps or physical transit cards for different modes of transportation such as subways, buses, bicycles, and taxis. Users manually switch payment methods when changing modes, hoping to consolidate payment records across different modes into a single account on the operator's or payment platform's backend for unified settlement. However, this approach is completely undetectable on the cardholder. Users still need to frequently switch between different apps or remove their physical cards each time they switch modes, resulting in a poor user experience. Furthermore, the balances are scattered, posing risks of delays and potential double charges, making unified management difficult, and unable to manage multiple transit mode tickets in parallel, leading to complex operations. Therefore, how to efficiently achieve seamless switching between multiple transit modes on the cardholder is a pressing issue that needs to be addressed. Summary of the Invention

[0004] The main purpose of this application is to provide a method, device, equipment and storage medium for multi-mode travel ticket switching based on embedded security elements, aiming to solve the technical problem of how to efficiently achieve seamless switching of multi-mode tickets at the card end.

[0005] To achieve the above objectives, this application proposes a multi-mode travel integrated ticketing switching method based on embedded security elements, the method comprising: Receive itinerary contract information; Based on the itinerary segment information and transportation mode information in the itinerary contract information, determine the virtual ticket identification information and the corresponding transaction queue information; The ticket switching instruction information is determined based on the virtual ticket identification information and the transaction queue information; Based on the ticket switching instruction information, the control system switches the virtual tickets corresponding to the itinerary contract information one by one.

[0006] In one embodiment, the step of receiving the itinerary contract information includes: Obtain travel request information and security channel information, wherein the travel request information includes departure point information, destination information, and travel preference information; The system calls a preset background itinerary planning service interface to process the departure point information, the destination information, and the travel preference information to determine service processing information. The itinerary contract information corresponding to the secure channel information is determined based on the service processing information.

[0007] In one embodiment, the step of determining the virtual ticket identifier information and the corresponding transaction queue information based on the trip segment information and transportation mode information in the trip contract information includes: The itinerary sequence information is determined based on the itinerary segment information in the itinerary contract information; The virtual ticket identifier is identified based on the transportation mode information in the trip contract information, and the virtual ticket identifier information is determined. The transaction queue information corresponding to the itinerary sequence information is determined based on the virtual ticket identification information.

[0008] In one embodiment, the step of determining the ticket switching instruction information based on the virtual ticket identification information and the transaction queue information includes: Obtain card swipe information; Based on the card swipe information and the virtual ticket identification information, the transaction queue information is modified to determine the transaction queue modification information; Based on the transaction queue change information, the corresponding ticket switching instruction information is determined.

[0009] In one embodiment, the card swiping information is a card swiping for entering the station; The step of modifying the transaction queue information based on the card swipe information and the virtual ticket identification information, and determining the transaction queue modification information, includes: When the card swipe information is for station entry, the virtual ticket activation instruction information is determined based on the virtual ticket identification information; Generate the corresponding entry signature certificate information based on the virtual ticket activation instruction information; The transaction queue information is modified based on the signature credential information to obtain transaction queue modification information.

[0010] In one embodiment, the card swipe information is an exit card swipe; The step of modifying the transaction queue information based on the card swipe information and the virtual ticket identification information, and determining the transaction queue modification information, includes: When the card swipe information is for exiting the station, the fare information under the preset fare rules is determined based on the virtual ticket identification information; Based on the aforementioned fee information, determine the corresponding exit signature voucher information; The transaction queue information is modified based on the outbound signature certificate information to obtain transaction queue modification information.

[0011] In one embodiment, the step of switching the virtual tickets corresponding to the itinerary contract information one by one based on the ticket switching instruction information control system includes: Obtain incremental trip contract information, which includes operation type information, insertion position information, and newly added trip segment information; The ticket switching instruction information is adjusted based on the digital signature in the incremental travel contract information to determine the ticket switching instruction adjustment information; Based on the ticket switching instruction, the adjustment information control system switches the virtual tickets corresponding to the itinerary contract information one by one.

[0012] Furthermore, to achieve the above objectives, this application also proposes a multi-mode travel integrated ticket switching device based on embedded security elements, the multi-mode travel integrated ticket switching device based on embedded security elements comprising: The acquisition module is used to receive itinerary contract information; The processing module is used to determine the virtual ticket identification information and the corresponding transaction queue information based on the itinerary segment information and transportation mode information in the itinerary contract information; The processing module is also used to determine ticket switching instruction information based on the virtual ticket identification information and the transaction queue information; The execution module is used to control the system to switch the virtual tickets corresponding to the itinerary contract information one by one based on the ticket switching instruction information.

[0013] Furthermore, to achieve the above objectives, this application also proposes a multi-mode travel integrated ticketing switching device based on embedded security elements. The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor. The computer program is configured to implement the steps of the multi-mode travel integrated ticketing switching method based on embedded security elements as described above.

[0014] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, it implements the steps of the multi-mode travel integrated ticket switching method based on embedded security elements as described above.

[0015] One or more technical solutions proposed in this application have at least the following technical effects: This embodiment proposes a multi-mode travel integrated ticket switching method based on embedded security elements, which receives travel contract information; determines virtual ticket identification information and corresponding transaction queue information based on travel segment information and traffic mode information in the travel contract information; determines ticket switching instruction information based on the virtual ticket identification information and the transaction queue information; and controls the system to switch virtual tickets corresponding to the travel contract information one by one based on the ticket switching instruction information. This application receives travel contract information to obtain a user-preset multi-mode connecting travel plan, allowing the travel route to be predicted at the card end. Based on the travel segment information and transportation mode information in the travel contract information, it determines the virtual ticket identification information and the corresponding transaction queue information. The corresponding transportation mode can be parsed from the travel contract, and an associated transaction record queue is established within the embedded security element to achieve precise mapping between ticket resources and travel segments. Based on the virtual ticket identification information and the transaction queue information, it determines ticket switching instruction information and generates ticket switching instruction information to ensure that the switching timing is synchronized with the travel progress. Thus, based on the ticket switching instruction information, the system controls the virtual tickets corresponding to the travel contract information to switch one by one. It can automatically close the current virtual ticket and switch to the next virtual ticket in the order of the travel. It achieves seamless multi-mode switching at the card end without manual operation or secondary card swiping, thereby significantly improving the connecting travel experience and efficiency. Attached Figure Description

[0016] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a flowchart illustrating an embodiment of the multi-mode travel integrated ticketing switching method based on embedded security elements provided in this application. Figure 2 This is a schematic diagram illustrating the establishment of security channel information for the multi-mode travel integrated ticketing switching method based on embedded security elements in this application; Figure 3 This is a schematic diagram illustrating the trip contract issuance method for the multi-mode travel integrated ticketing switching method based on embedded security elements in this application; Figure 4 This is a schematic diagram illustrating the transaction reporting and settlement of the multi-mode travel integrated ticketing switching method based on embedded security elements in this application; Figure 5This is a schematic diagram illustrating the anomaly handling of the multi-mode travel integrated ticketing switching method based on embedded security elements in this application; Figure 6 This is a flowchart illustrating Embodiment 2 of the multi-mode travel integrated ticketing switching method based on embedded security elements provided in this application; Figure 7 This is a schematic diagram of the multi-mode travel integrated ticket switching method based on embedded security elements for card swiping to enter the station, as described in this application. Figure 8 This is a schematic diagram of the multi-mode travel integrated ticket switching method based on embedded security elements for exiting the station by swiping a card; Figure 9 This is a schematic diagram illustrating the mode switching of the multi-mode travel integrated ticketing switching method based on embedded security elements in this application; Figure 10 A simplified flowchart illustrating the multi-mode travel integrated ticketing switching method based on embedded security elements provided in this application embodiment; Figure 11 This is a schematic diagram of the module structure of the multi-mode travel integrated ticket switching device based on embedded security elements according to an embodiment of this application; Figure 12 This is a schematic diagram of the device structure of the hardware operating environment involved in the multi-mode travel integrated ticket switching method based on embedded security elements in the embodiments of this application.

[0019] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0020] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0021] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0022] The main solution of this application embodiment is: receiving travel contract information; determining virtual ticket identification information and corresponding transaction queue information based on travel segment information and traffic mode information in the travel contract information; determining ticket switching instruction information based on the virtual ticket identification information and the transaction queue information; and controlling the system to switch the virtual tickets corresponding to the travel contract information one by one based on the ticket switching instruction information.

[0023] In this embodiment, for ease of description, the following description will focus on identifying a multi-mode travel integrated ticketing switching device based on embedded security elements.

[0024] Because the existing technology has no awareness of the card, users still need to frequently switch between different applications or take out their physical cards from their pockets to replace them when performing a second card swipe operation each time, resulting in a very poor experience. In addition, the balances are scattered, which poses the risk of delays and possible double charges. It is difficult to manage them in a unified manner and cannot manage multiple modes of transportation tickets in parallel, making the operation complicated.

[0025] This application provides a solution that receives travel contract information to obtain a user-preset multi-mode connecting travel plan, allowing the travel route to be predicted at the card end. Based on the travel segment information and transportation mode information in the travel contract information, virtual ticket identification information and corresponding transaction queue information are determined. The corresponding transportation mode can be parsed from the travel contract, and an associated transaction record queue is established within the embedded security element to achieve precise mapping between ticket resources and travel segments. Ticket switching instruction information is determined based on the virtual ticket identification information and the transaction queue information, and ticket switching instruction information can be generated to ensure that the switching timing is synchronized with the travel progress. Thus, the system controls the switching of virtual tickets corresponding to the travel contract information one by one according to the ticket switching instruction information. The current virtual ticket can be automatically closed and the next virtual ticket can be switched one by one according to the travel sequence. This achieves seamless multi-mode switching at the card end without manual operation or secondary card swiping, thereby significantly improving the connecting travel experience and efficiency.

[0026] It should be understood that the multi-mode travel integrated ticketing switching method based on embedded secure elements can be applied to a multi-mode travel integrated ticketing switching system based on embedded secure elements. This system consists of a user terminal, a super SIM card (including an eSE), and backend services. The user terminal includes a smartphone or NFC POS terminal supporting the NFC-A / B / F protocol, and a travel app and NFC driver and middleware running on it. The travel app submits a trip planning request containing departure point, destination, and travel preferences, receives the trip contract (TC), and displays the travel status. The NFC driver and middleware are responsible for transmitting APDU commands and, based on the GlobalPlatform specification, initializes the SCP03 secure channel with the eSE using INITIALIZE UPDATE and EXTERNAL AUTHENTICATE commands to ensure the confidentiality and integrity of data transmission. The super SIM card's built-in secure chip eSE supports the installation and parallel management of multiple virtual applications and has a GP 3.1 compatible applet loading mechanism. The eSE uses a Java Card... Applets (VTAs) are stored in parallel to represent each mode of transportation, including subways, buses, shared bikes, and taxis. Each VTA is distinguished by a unique AID. An internal fare calculation module dynamically calculates costs (e.g., subway fares are calculated per station, buses per mileage, and shared bike fares per time). A dedicated SM2 private key is stored for tamper-proof signing of entry (tap_in) and exit (tap_out) transaction credentials. A transaction cache temporarily stores entry records for the current trip for fare calculation upon exit. The AID mapping table for all VTAs is stored in NVM to ensure data integrity during power outages. When the backend transmits JSON data via a secure channel… After the compressed TC is sent to the NVM of the eSE, the eSE automatically closes the current VTA and activates the corresponding VTA for the next segment when the user completes the exit swipe of the card for the current segment, based on the current trip segment parsed by the TC. This achieves a completely seamless ticket switching for the user. If the target VTA is not installed, it triggers OTA download to achieve dynamic expansion. At the same time, the SM2 private key of each VTA is stored independently to prevent cross-mode key leakage. The transaction queue (TQ) is encrypted and stored in the card swipe log area using the SM4 session key to record the entry and exit credentials for each trip segment and ensure that the transaction records are tamper-proof. The trip planning module of the background service generates segmented trips and corresponding ticket mapping tables based on GIS services and traffic big data and sends TCs through REST API. The ticket management module manages the version and configuration of VTA Applets for each mode and supports OTA download and encrypted signature. After receiving the reported TQ, the clearing module verifies the SM2 signature and timestamp of all credentials and calculates the total cost according to the segmented billing rules in the TC to trigger the deduction and settlement process.

[0027] Based on this, the embodiments of this application provide a multi-mode travel integrated ticketing switching method based on embedded security elements, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the multi-mode travel integrated ticket switching method based on embedded security elements in this application.

[0028] In this embodiment, the multi-mode travel integrated ticket switching method based on embedded security elements includes steps S10~S40: Step S10: Receive itinerary contract information; It should be noted that the trip contract information is a digital travel plan pre-planned by the user when traveling. It may include a list of trip segments, each of which carries a transportation mode identifier and its corresponding billing rules, origin and destination stations, etc. It defines the complete path from the user's origin to the destination, the required means of transportation and their switching sequence, and is transmitted through a secure channel to ensure integrity and confidentiality. The secure channel information is the information of an encrypted communication link established between the mobile terminal and the Super SIM Card (eSE) through two-way authentication. It is used to ensure the security of command and data interaction and prevent eavesdropping or tampering. The Super SIM Card is a smart card that integrates a security chip (eSE) with a higher security level and larger storage capacity on the basis of a traditional SIM card.

[0029] In a specific embodiment, travel request information and secure channel information are obtained. The travel request information includes departure point information, destination information, and travel preference information. Specifically, users can actively input or voice-record "departure point information" (e.g., "Station A"), "destination information" (e.g., "Station B"), and "travel preference information" (e.g., "minimum transfers, shortest travel time") through the interactive interface of a travel app integrated into their smartphones, thereby generating travel request information. Furthermore, the phone's NFC driver and the eSE within the Super SIM card, based on the GlobalPlatform specification, initialize the SCP03 secure channel with the eSE using INITIALIZE UPDATE and EXTERRNAL AUTHENTICATE instructions to ensure the confidentiality and integrity of data transmission. The GlobalPlatform specification is an open standard system developed by the international standards organization GlobalPlatform for the field of secure chip technology (such as eSE, SIM cards, smart cards, etc.). It defines the hardware architecture of the secure element (SE), security domain management, application (applet) installation and lifecycle management, and secure channel protocols (such as SCP03), providing a standardized technical framework for the parallel isolated operation of multiple applications within a secure chip, secure instruction transmission, and identity authentication. For example, ... Figure 2 As shown, Figure 2 This diagram illustrates the establishment of secure channel information for the multi-mode travel integrated ticketing switching method based on embedded secure elements in this application. The NFC smart terminal transmits: eSE: 00 50 00 00 08<HostChallenge 8B> The Super SIM card eSE verifies the HostChallenge, generates the CardChallenge, and returns secure channel information (Sequence Counter, CMAC). NFC smartly uses the key diversification algorithm to derive the SMAC key, calculates and sends the command data CMAC. After verification by the Super SIM card eSE, the SCP03 session is activated, thereby establishing an SCP03 secure channel that is tamper-proof and prevents eavesdropping, ensuring the confidentiality and integrity of subsequent sensitive data interactions, thus obtaining the secure channel information.

[0030] The system calls a preset backend travel planning service interface to process the departure point information, destination information, and travel preference information to determine service processing information. Based on the service processing information, it determines the travel contract information corresponding to the security channel information. Specifically, the mobile app can act as a client, calling the preset cloud-based backend travel planning module's REST API interface (POST / api / travel / plan) to send a user request data packet containing the departure point, destination, and preference settings to the backend. The backend service internally uses a GIS geographic information system engine and a real-time traffic big data model to comprehensively process the data, generating at least one segmented connecting travel plan list containing specific transportation mode combinations, transfer stations, and estimated costs. This yields the service processing information, dynamically responding to user preferences and planning a personalized travel script that balances efficiency and cost from a globally optimal perspective. The mobile app encapsulates the optimal plan selected by the user from the service processing information (e.g., selecting a connecting travel plan of "3 yuan for the subway + 2 yuan for the bus") into JSON format travel contract data and sends it through the established security channel using a specific "80 E2 00 00" message. <lc><TC data>The "00" APDU command transmits the data completely to the eSE non-volatile memory (NVM) of the Super SIM card. After eSE verification and parsing, it returns a "90 00" success status code to the phone. This allows the unique trip contract information bound to this secure channel to be identified, for example, such as... Figure 3 As shown, Figure 3 This diagram illustrates the trip contract issuance method for the multi-mode travel integrated ticketing switching approach based on embedded secure elements, as described in this application. The user's travel app initiates a POST request to ` / api / travel / plan`, containing `{origin, destination, preferences}`. The background trip planning module in the cloud-based backend service system returns TC JSON data. NFC smart devices then send a PUT TC_APDU: 80E2 00 00 via a secure channel. <lc><TC data>00; The Super SIM card eSE verifies and stores the TC, returning 90 00, thereby transforming the user's macro travel intention into a digital segmented contract that the eSE can directly recognize and execute. This enables the card to predict the traffic mode of the entire route, and to seamlessly schedule and switch the corresponding virtual fare card (VTA), effectively preventing man-in-the-middle attacks and ensuring that the trip contract is not maliciously tampered with or forged.

[0031] In one feasible implementation, step S10 may include steps A11 to A13: Step A11: Obtain travel request information and security channel information, wherein the travel request information includes departure point information, destination information, and travel preference information; It should be noted that the travel request information is the planning request data submitted by the user through the terminal application interface to complete a connecting trip involving multiple modes of transportation. This data includes the trip's origin, destination, and personalized needs and preferences. The security channel information is the identification information of a transmission channel established between the terminal's NFC driver and the embedded security element built into the Super SIM card.

[0032] Understandably, departure information is used to identify the starting point of a user's trip, destination information is used to identify the target point of a user's trip, and travel preference information is used to express the user's personalized constraints on the trip planning scheme, such as the fewest transfers, the shortest total time, the lowest overall cost, or the preference for a specific mode of transportation.

[0033] Step A12: Call the preset background itinerary planning service interface to process the departure information, the destination information, and the travel preference information, and determine the service processing information; It should be noted that the service processing information is the planning result data returned by the background trip planning service after optimizing the trip requirements submitted by the user. It can be a list of one or more travel options, and each option includes a sequence of transportation mode combinations, transfer stations or connection points for each segment, and estimated travel time and cost for each segment.

[0034] Understandably, the backend itinerary planning service interface is a web application programming interface deployed on a cloud server and conforming to the RESTful design specification. It can receive itinerary planning request data packets sent by user terminals and execute optimal path search and combination algorithms to provide dynamic travel plan services.

[0035] Step A13: Determine the itinerary contract information corresponding to the secure channel information based on the service processing information.

[0036] It is understood that the travel contract information can be directly identified and executed by the embedded security element, thereby predicting the entire traffic mode and switching sequence, and realizing seamless scheduling and automatic switching of virtual tickets.

[0037] Step S20: Based on the itinerary segment information and transportation mode information in the itinerary contract information, determine the virtual ticket identification information and the corresponding transaction queue information; It should be noted that the virtual ticket identification information is an application identifier that uniquely identifies the virtual ticket application instance corresponding to the transportation mode. It is used by the eSE to accurately activate and call the corresponding virtual ticket applet when the user approaches the card reader to perform entry and exit card swiping and signature calculations. The transaction queue information is a log data structure that is pre-initialized by the eSE in the security domain for this trip segment after the target virtual ticket application instance is determined. It is protected by SM4 session key encryption and is used to sequentially record the entry and exit vouchers in this trip segment. After the trip is completed, it will be reported to the background clearing module to complete the fee verification and settlement.

[0038] In a specific embodiment, the itinerary sequence information is determined based on the itinerary segment information in the itinerary contract information. That is, according to the itinerary segment information in the itinerary contract information, the embedded security element (eSE) reads and parses out the start and end stations, transfer nodes and execution order of each segment of the itinerary in sequence to obtain the itinerary sequence information, which is used for ticket activation.

[0039] Based on the traffic mode information in the trip contract information, the virtual ticket identifier is identified and determined. Specifically, according to the traffic mode information in the trip contract information, eSE calls the corresponding traffic mode-AID mapping table query function to match the mode string describing the current trip segment with the pre-generated traffic mode identifier in the table. This identifies and locks the application identifier of the virtual ticket application instance that uniquely corresponds to the trip segment, thus obtaining the virtual ticket identifier information for precise positioning and seamless switching.

[0040] Based on the virtual ticket identification information, the transaction queue information corresponding to the itinerary sequence information is determined. That is, according to the virtual ticket identification information, after receiving the activation instruction, the eSE dynamically creates the corresponding transaction queue information for the segment of the itinerary based on the segment number in the itinerary sequence information. The transaction queue information is stored in encrypted form with the SM4 session key, and the timestamps of entry and exit and the SM2 digital signature certificate are recorded sequentially. This achieves strict isolation and sequential auditing of transaction records for different modes of transportation, and ensures that each transaction is tamper-proof and traceable, thus guaranteeing the safety and reliability of the entire multi-modal travel process.

[0041] In one feasible implementation, step S20 may include steps B11-B13: Step B11: Determine the itinerary sequence information based on the itinerary segment information in the itinerary contract information; It should be noted that the itinerary sequence information is a list arranged according to the dependencies between itinerary segments. Each itinerary segment is assigned a unique segment sequence number, and a connection identifier is defined between the itinerary segment and the end point of the previous segment and the start point of the next segment. This is used to activate the tickets of each segment in sequence, thereby ensuring that the execution of the entire itinerary strictly follows the planned path.

[0042] Step B12: Identify the virtual ticket identifier based on the transportation mode information in the trip contract information to determine the virtual ticket identifier information; It should be noted that the virtual ticket identification information is an application identifier that uniquely points to the virtual ticket application instance corresponding to the traffic mode. This enables the embedded security element (eSE) to quickly and accurately locate and activate the correct virtual ticket applet from multiple coexisting security ticket applications without the user's awareness.

[0043] Step B13: Determine the transaction queue information corresponding to the itinerary sequence information based on the virtual ticket identification information.

[0044] Understandably, when the embedded security element (eSE) activates the virtual ticket applet specified by the virtual ticket identifier information based on the current segment sequence in the trip sequence information, it will immediately dynamically create a transaction queue information that is uniquely bound to the identifier and strictly associated in sequence for that trip segment, and record the timestamps and SM2 signature credentials generated when entering and leaving the station in sequence. At this time, segmented fee verification and intelligent billing can be completed independently simply by reporting the transaction queue information.

[0045] Step S30: Determine ticket switching instruction information based on the virtual ticket identification information and the transaction queue information; It should be noted that the ticket switching instruction information is a secure switching instruction carrying the virtual ticket identifier of the target transportation mode, used to switch the virtual ticket Applet corresponding to the next transportation mode, so as to achieve seamless switching across transportation modes.

[0046] In a specific embodiment, card swiping information can be obtained by the embedded security element (eSE) capturing the raw data frames generated by the user's card swiping operation in real time, and parsing key fields such as entry / exit identifier, card swiping timestamp, and card reader device number from them to obtain card swiping information.

[0047] Based on the card swipe information and the virtual ticket identification information, the transaction queue information is modified to determine the transaction queue change information. That is, the embedded security element (eSE) can pass the card swipe information to the currently active virtual ticket applet. The applet calls the transaction queue record uniquely bound to the virtual ticket identification information, and writes the timestamp of this card swipe in the corresponding position of the queue with the SM4 session key according to the entry or exit type. It also generates the current entry / exit signature certificate based on the SM2 algorithm, thus obtaining the transaction queue change information containing the complete entry / exit time pair and the dual signature certificate.

[0048] Based on the transaction queue change information, the corresponding ticket switching instruction information is determined. This means that the transaction queue change information can be continuously monitored. When the transaction queue change information has valid SM2 signature credentials for both entry and exit and there is a next to-be-executed travel segment in the travel sequence information, a ticket switching instruction information carrying the virtual ticket identifier (AID) corresponding to the next transportation mode is generated. This enables auditing of the transaction status of different travel segments and realizes segment-by-segment verification of transaction records and ticket switching without the user's awareness.

[0049] Step S40: Based on the ticket switching instruction information, the system switches the virtual tickets corresponding to the itinerary contract information one by one.

[0050] Understandably, a virtual ticket is a ticket application instance (applet) pre-installed within an embedded secure element (eSE) and uniquely bound to a specific transportation mode. It uses an application identifier (AID) as a globally unique index and embeds an SM2 key pair and an SM4 session key, which are responsible for the encrypted storage and signature calculation of entry and exit transaction records for the corresponding transportation mode.

[0051] In a specific embodiment, incremental trip contract information is obtained. This incremental trip contract information includes operation type information, insertion location information, and new trip segment information. Specifically, when a user actively initiates a route change through a travel app (e.g., clicking "detour" or "change mode of transportation") or the backend detects traffic anomalies (e.g., subway shutdown) and actively pushes adjustment suggestions, the cloud-based trip planning service generates an incremental trip contract (Delta-TC). This contract can be encapsulated in JSON format. The "operation type information" is defined by the "action" field as either "insert" or "update." The "insertion location information" is specified by the "segmentIndex" field, indicating that the new trip will be inserted after the corresponding trip segment in the original trip contract (TC). The "new trip segment information" includes complete fields such as the new transportation mode identifier, origin and destination stations, and fare rules. At this time, the backend can use a custom APDU command (e.g., 80 E3 00 00) through the established SCP03 security channel. <lc><Delta-TC data>00) Delivering the incremental trip contract information to an embedded Secure Element (eSE), allowing dynamic hot update of trips at the electronic ticket level, and ensuring that the card end can flexibly respond to temporary route change requirements in practice.

[0052] Adjusting the ticket switching instruction information based on the digital signature in the incremental trip contract information, and determining ticket switching instruction adjustment information, that is, adjusting the ticket switching instruction information according to the digital signature in the incremental trip contract information: if it is an insertion operation, inserting a new trip segment after the specified insertion position information and automatically reordering the "segmentIndex" of all trip segments; if it is an update operation, replacing the original trip segment data. After the update is completed, the pre-generated original ticket switching instruction queue can be corrected, and the ticket switching instruction adjustment information including the Application Identifier (AID) of the virtual ticket corresponding to the newly inserted transportation mode can be re-determined, so as to ensure that the switching logic is consistent with the updated trip contract and eliminate switching confusion caused by trip changes.

[0053] Controlling the system to switch the virtual tickets corresponding to the trip contract information one by one based on the ticket switching instruction adjustment information, that is, monitoring the change status of the outbound transaction queue of the current trip segment according to the ticket switching instruction adjustment information. After confirming that the user completes the current trip segment, executing a RESET CHANNEL instruction to terminate the current virtual ticket Applet session according to the adjusted instruction sequence, and sending a SELECT instruction carrying a new AID to activate the virtual ticket corresponding to the next trip segment. According to the adjusted sequence, the virtual tickets of all subsequent trips are activated and managed one by one without the user's perception, so that the user can respond to temporary path changes immediately, and still maintain a completely non-perceptive integrated card swiping experience in multi-segment transfers, without requiring the user to take out a mobile phone or perform a secondary card swiping operation throughout the whole process.

[0054] It should be understood that, as Figure 4 shown, Figure 4 This diagram illustrates the transaction reporting and settlement process of the multi-mode travel integrated ticketing switching method based on embedded secure elements in this application. After a user completes all travel segments, the terminal collects the complete transaction queue (TQ) and calls the interface of the backend settlement module to upload the data. The backend settlement module uses the SM4 key derived synchronously with the secure element to decrypt the encrypted records in the TQ and verifies the SM2 digital signatures of all entry and exit credentials one by one to ensure that each transaction record has not been tampered with since its generation and that its source is trustworthy. The backend uses the contract number (contractId) as an index to match the corresponding travel contract (TC), strictly checks the continuity of the indexes of each segment in the transaction queue to confirm that there are no omissions or jumps in the travel. Then, it accumulates the fees of each segment according to the order of the travel segments defined in the travel contract. For example, in a connecting trip from subway station A to bus station B, the system first calculates the 3 yuan fare for the subway segment based on distance, and then adds the 2 yuan fixed rate fare for the bus segment, thus merging them into a single bill of 5 yuan. If a certain segment of the trip is missing an exit record, the system will activate the anti-missed deduction logic and deduct the fee according to the preset maximum rate for that segment to reduce the risk of bad debt. Ultimately, the backend generates a unified settlement statement containing details of all modes of transportation, itemized costs, and the total amount, triggering the user's bill. This achieves "one-time payment, one-time settlement" for costs of multiple segmented trips, significantly improving fund clearing efficiency, reducing bank transaction costs, and providing users with a clear and transparent consolidated bill. Taking a subway and bus trip as an example, it can be represented as follows: Input data: { "contractId": "TC20230715_001", "segments": [ {"index": 1, "mode": "subway", "from": "Station A", "to": "Transfer Station", "priceRule": "mileage"}, {"index": 2, "mode": "bus", "from": "transfer station", "to": "B station", "priceRule": "fixed"}] } TQ (Transaction Queue) (Decrypted): [ { "type": "in", "mode": "subway", "contractId": "TC20230715_001", "segmentIndex": 1, "time": "08:30", "signature": "SM2_3A2B..." }, { "type": "out", "mode": "subway", "contractId": "TC20230715_001", "segmentIndex": 1, "time": "08:45", "fee": 3.00, "signature": "SM2_5D6E..." }, { "type": "in", "mode": "bus", "contractId": "TC20230715_001", "segmentIndex": 2, "time": "08:50", "signature": "SM2_7F8G..." }, { "type": "out", "mode": "bus", "contractId": "TC20230715_001", "segmentIndex": 2, "time": "09:10", "fee": 2.00, "signature": "SM2_9H0I..." } ] At this point, the TQ is decrypted using the SM4 key, the SM2 signature of each record is verified (to ensure it has not been tampered with), the TC is matched by contractId, all records in the TQ are confirmed to belong to the same trip, the segmentIndex continuity is checked, and the cost is accumulated in segment order: Metro segment (segment 1): 3.00 yuan; Bus segment (segment 2): 2.00 yuan; Total cost: 5.00 yuan. If a segment is missing tap_out, the highest rate preset for that segment in the TC is deducted (e.g., a full metro fare of 5 yuan).

[0055] This allows the generation of a settlement statement: { "contractId": "TC20230715_001", "totalFee": 5.00, "details": [ {"mode": "subway", "fee": 3.00, "distance": "5km"}, {"mode": "bus", "fee": 2.00, "line": "Bus123"} ], "timestamp": "2023-07-15T09:15:00Z" } The backend clearing module returns the clearing results, and the user's travel app displays a trip summary.

[0056] To address complex scenarios such as system communication failures, business logic errors, and dynamic changes in travel itineraries, such as... Figure 5 As shown, Figure 5 This diagram illustrates the anomaly handling of the multi-mode travel integrated ticketing switching method based on embedded secure elements in this application. At the interaction level, if a timeout occurs during any step of the NFC terminal's execution, the APDU command will be automatically resent up to three times. If the retry limit is exceeded, the user will be prompted with "Card swipe failed, please retry" to ensure the instantaneous reliability of communication. At the transaction level, if the outbound deduction process fails abnormally, the embedded secure element will roll back the ticket status transaction to the state before entry based on the inbound log in the transaction queue, and simultaneously notify the cloud service system to retry the settlement, thereby ensuring the security of account funds. At the functional expansion level, the cloud service system can issue the latest VTA and TC templates, and the eSE can dynamically update the Applet during idle time through INSTALL / LOAD commands to ensure functional expansion.

[0057] To handle users' temporary route changes (such as detours, adjustments to transfer strategies, etc.), a dynamic segment insertion interface can be designed in the TC (Travel Control Center) to support real-time updates of unplanned segments and synchronization with the eSE (Electronic Service Provider). For example, users can proactively initiate route changes through the travel app (e.g., clicking "detour" or "change mode of transportation"). If the backend detects traffic anomalies (such as subway closures), it proactively pushes adjustment suggestions. The cloud service generates incremental TCs (Delta-TCs), containing newly added or modified travel segments, represented in the following format: { "action": "insert / update", / / Operation type "segmentIndex": 2, / / Insertion position (after the original TC's segmentIndex) "newSegment": / / Add new segment data { "mode": "bus", "from": "Temporary Site A", "to": "Target Site B", "priceRule": "fixed" } } Incremental TCs are sent to the eSE via the secure channel (SCP03). Example of an APDU command: 80 E3 00 00 <lc><Delta-TC Data>00 / / Incremental update identified by custom command code E3 At this time, after verifying the Delta-TC signature, the eSE merges it with the original TC: if it is an insert operation, insert the new Segment after the specified segmentIndex, and subsequent indexes will be automatically rearranged; if it is an update operation, replace the original Segment and retain the historical record (for settlement traceability); if the newly added segment involves an inactivated VTA (such as switching from subway to taxi), the eSE triggers a preload check, and initiates OTA download if there is a missing resource; when the user arrives at the starting point of the dynamic segment, the eSE automatically activates the corresponding VTA, the process is consistent with Section 5.2.5, and the switching time is still kept <100ms; if the user does not travel according to the dynamic segment, the eSE compares the tap_in timestamp in the TQ with the TC and triggers secondary confirmation by the backend; during backend clearing, the preset cost of the dynamic segment is overwritten according to the actual travel segment (TQ records) to ensure accurate billing, and realizes high fault tolerance and high adaptability of the full-link closed loop.

[0058] In a feasible implementation, step S40 may include steps C11 to C13: Step C11: acquiring incremental trip contract information, wherein the incremental trip contract information includes operation type information, insertion position information and newly added trip segment information; It should be noted that the incremental trip contract information is a structured data packet dynamically generated due to the user's temporary route change or the backend detection of traffic abnormality, which enables the card end to flexibly respond to actual trip changes without power off or reset.

[0059] It can be understood that the operation type information is an identification field used to identify the specific behavior of the current incremental operation, for example, insert indicates inserting a new trip segment into the original trip, and update indicates replacing the original trip segment; the insertion position information is a positioning field used to specify the index position of the incremental operation in the trip segment sequence of the original trip contract, for example, inserting after the second trip segment; the newly added trip segment information is a data field that carries the complete description of the newly added or replaced trip segment, and includes parameters such as the transportation mode identifier corresponding to the trip segment, the name of the starting station, the name of the destination station, and the applicable fare billing rules, so as to ensure that the embedded secure element can accurately identify and activate the virtual ticket application required by the newly added segment.

[0060] Step C12: adjusting the ticket switching instruction information based on the digital signature in the incremental trip contract information, and determining ticket switching instruction adjustment information; It should be noted that the ticket switching instruction adjustment information is an instruction update sequence obtained by verifying the digital signature in the incremental trip contract information, which is used to ensure that the switching logic is consistent with the changed trip contract, and can eliminate switching confusion caused by trip changes.

[0061] Step C13: Based on the ticket switching instruction, adjust the information control system to switch the virtual tickets corresponding to the itinerary contract information one by one.

[0062] Understandably, the embedded security element can automatically terminate the current virtual ticket application session after the user completes the exit card swipe for the current travel segment, and seamlessly activate the virtual ticket application corresponding to the next travel segment in the adjusted order. The entire switching process is completed without the user's awareness, without the need for manual operation or a second card swipe, thereby significantly improving the integrated experience of multi-mode connecting travel and flexibly responding to dynamic scenarios such as temporary route changes.

[0063] This embodiment proposes a multi-mode travel integrated ticket switching method based on embedded security elements, which receives travel contract information; determines virtual ticket identification information and corresponding transaction queue information based on travel segment information and traffic mode information in the travel contract information; determines ticket switching instruction information based on the virtual ticket identification information and the transaction queue information; and controls the system to switch virtual tickets corresponding to the travel contract information one by one based on the ticket switching instruction information. This invention solves the technical problem of how to efficiently achieve seamless switching of multi-mode tickets on the card end. Compared with existing technologies, this application receives travel contract information to obtain the user's preset multi-mode connecting travel plan, allowing the travel route to be predicted on the card end. Based on the travel segment information and transportation mode information in the travel contract information, virtual ticket identification information and corresponding transaction queue information are determined. The corresponding transportation mode can be parsed from the travel contract, and an associated transaction record queue is established in the embedded security element to achieve precise mapping between ticket resources and travel segments. Ticket switching instruction information is determined based on the virtual ticket identification information and the transaction queue information, and ticket switching instruction information can be generated to ensure that the switching timing is synchronized with the travel progress. Thus, the system controls the switching of virtual tickets corresponding to the travel contract information one by one according to the ticket switching instruction information. The current virtual ticket can be automatically closed and the next virtual ticket can be switched one by one according to the travel sequence, realizing seamless switching of multi-mode tickets on the card end without manual operation or secondary card swiping, thereby significantly improving the connecting travel experience and efficiency.

[0064] Based on the first embodiment of this application, in the second embodiment of this application, the same or similar content as the first embodiment can be referred to the above description, and will not be repeated hereafter.

[0065] In this embodiment, refer to Figure 6 , Figure 6 This is a flowchart illustrating Embodiment 2 of the multi-mode travel integrated ticketing switching method based on embedded security elements in this application. Step S30 specifically includes steps S31 to S33: Step S31: Obtain card swipe information; It should be noted that the card swipe information is the raw transaction data frame captured in real time by the embedded secure element (eSE) from an external card reader via the near field communication (NFC) interface, and may include fields such as entry / exit identifier, card swipe timestamp, card reader device number, and contract identifier associated with the current travel segment.

[0066] Understandably, card swipe information is a digital record generated on the card terminal for each physical card swipe action by the user. It is used to distinguish between entry and exit operations. Only by accurately acquiring and parsing card swipe information can the embedded security element be ensured to correctly process the activation, billing, and switching of the current ticket in the correct sequence of operations.

[0067] In a specific embodiment, when a user approaches the NFC reader of a subway entrance gate with a mobile phone containing a built-in super SIM card (including eSE), the reader initiates a transaction request via the ISO / IEC 14443 protocol. The mobile phone's NFC controller transmits the instruction sent by the reader (such as the SELECT AID instruction) to the eSE. The eSE parses the instruction according to the currently active Virtual Ticket Application (VTA) and extracts the card swiping information, which includes the entrance identifier (e.g., command byte 80 01 01 00), timestamp (e.g., 2025-06-02 08:30:25), gate number (e.g., 010203), and contract index (contractId+segmentIndex). The eSE can then transmit the card swiping information to the running subway VTA, where the VTA's entrance processing module generates a signature credential and records it in the transaction queue. Simultaneously, it returns a status code 90 00 to inform the NFC controller that the transaction was successful, and the gate immediately opens.

[0068] Step S32: Modify the transaction queue information based on the card swipe information and the virtual ticket identification information, and determine the transaction queue change information; It should be noted that the transaction queue change information is a new set of queue records obtained by writing the data generated by swiping the card into the original transaction queue in the order of the travel segment, representing the complete transaction status of the current travel segment from entering the station to exiting the station.

[0069] In a specific embodiment, when the card swipe information is for station entry, virtual ticket activation instruction information is determined based on the virtual ticket identification information; corresponding entry signature credential information is generated based on the virtual ticket activation instruction information; and the transaction queue information is modified based on the signature credential information to obtain transaction queue modification information, i.e., as follows. Figure 7 As shown, Figure 7 This is a schematic diagram illustrating the multi-mode travel integrated ticketing switching method based on embedded secure elements for station entry via card swiping. NFC smart listening 14443-4 is triggered, querying the current segment index of the TC; the Super SIM card activates the corresponding virtual ticket activation instruction information VTA AID: 00 A4 04 00. <lc> <aid>00; NFC Smart Transmission Inbound Request APDU: 80 xx 0100 <lc><contractId + segmentIndex + timestamp>00; The Super SIM VTA uses the SM2 private key to sign the data and generate signature credential information Ticket_in = {contractId, segmentIndex, inTime,signature}; The Super SIM VTA calls the UPDATE RECORD instruction to write Ticket_in into the TQ block and obtain transaction queue change information; NFC smart receives 90 00, and the traffic gate system allows passage.

[0070] When the card swipe information indicates an exit swipe, the fare information under the preset fare rules is determined based on the virtual ticket identification information; the corresponding exit signature voucher information is determined based on the fare information; and the transaction queue information is modified according to the exit signature voucher information to obtain transaction queue modification information, i.e., as follows. Figure 8 As shown, Figure 8 This is a schematic diagram illustrating the multi-mode travel integrated ticketing switching method based on embedded secure elements for exiting the station by swiping a card. The NFC smart device reactivates the same VTA; the NFC smart device sends an exit request APDU: 80 xx 02 00 <lc><contractId + segmentIndex +outTime>00; The Super SIM card VTA verifies the validity of inTime and calculates the fee information according to the fare rules; The Super SIM card constructs the outbound signature credential information Ticket_out = {contractId, segmentIndex, outTime, fee,signature}; The Super SIM card writes Ticket_out to TQ to obtain the transaction queue change information and performs symmetric encryption using the SM4 session key; The Super SIM card returns 90 00 and sends it back to the backend service, displaying the deduction result.

[0071] It should be understood that, such as Figure 9 As shown, Figure 9 This is a schematic diagram illustrating the mode switching method of the multi-mode travel integrated ticket switching method based on embedded security elements in this application. When a user swipes their card to exit the station, the VTA's tap_out execution is triggered. The SE reads the TC, increments the segmentIndex by 1, and determines whether there is a next VTA segment. If the next segment is a bus, the VTA is switched: the current Applet session is terminated (RESET CHANNEL); an APDU command is sent to terminate the current session (to avoid conflicts): 80 7000 00 00; the next VTA segment is activated, such as activating the bus VTA (see the tap_in step); a SELECT AID command is sent to activate the target Applet (such as the bus VTA): 00 A4 04 00 07 A0000001VTA02 00; the switching process is completed automatically without user interaction or a second card swipe; a SELECT AID command is sent to activate the target Applet (such as the bus VTA): a signature credential Ticket_in is generated and written to the TQ.

[0072] In one feasible implementation, step S32 may include steps D11 to D13: Step D11: When the card swipe information is for station entry, determine the virtual ticket activation instruction information based on the virtual ticket identification information; It should be noted that the virtual ticket activation instruction information is an APDU instruction used to start or wake up the specific virtual ticket application (VTA), such as 00 A4 04 00 <lc> <aid>00 allows eSE to accurately select the virtual ticket (VTA) instance that matches the current traffic pattern from multiple application environments.

[0073] Step D12: Generate the corresponding entry signature certificate information based on the virtual ticket activation instruction information; It should be noted that the entry signature credential information is an encrypted data packet generated by the currently active Virtual Ticket Application (VTA) after receiving the entry card swipe request, which facilitates entry.

[0074] Step D13: Modify the transaction queue information according to the signature certificate information to obtain transaction queue change information.

[0075] It is understandable that by writing the entry signature certificate information into the transaction queue corresponding to the current trip segment, the transaction queue changes from an empty state or a state waiting to be written to a new state containing a complete entry record, thereby effectively preventing trip forgery or duplicate charges.

[0076] In one feasible implementation, step S32 may further include steps E11 to E13: Step E11: When the card swipe information is an exit card swipe, determine the fee information under the preset fare rules based on the virtual ticket identification information; It should be noted that the fee information is the amount to be deducted for this trip segment calculated by the currently activated Virtual Ticketing Application (VTA) after receiving the exit card swipe request, based on the fare calculation rules built into the transportation mode and combined with parameters such as time, station or distance in the entry record, without relying on real-time query in the background.

[0077] Step E12: Determine the corresponding outbound signature certificate information based on the fee information; It should be noted that the outbound signature credential information is an encrypted data packet generated by the current Virtual Ticket Application (VTA) after calculating the fee, which facilitates outbound processing.

[0078] Step E13: Modify the transaction queue information according to the outbound signature certificate information to obtain transaction queue change information.

[0079] It is understandable that writing the exit signature certificate information into the transaction queue corresponding to the current travel segment can effectively prevent fee tampering and travel segment omission.

[0080] Step S33: Determine the corresponding ticket switching instruction information based on the transaction queue change information.

[0081] It is understood that the ticket switching instruction information can enable the embedded security element (eSE) to terminate the current virtual ticket application session and activate the virtual ticket required for the next segment of the journey, thereby achieving a seamless switch from the current transportation mode to the next transportation mode.

[0082] This embodiment proposes a multi-mode travel integrated ticket switching method based on embedded security elements. The method involves acquiring card swipe information; modifying transaction queue information based on the card swipe information and the virtual ticket identifier information to determine transaction queue modification information; and determining the corresponding ticket switching instruction information based on the transaction queue modification information. This solves the technical problem of how to efficiently achieve seamless switching of multi-mode tickets at the card end. Compared to existing technologies, this application avoids misjudgments or delays caused by signal ambiguity at the card end by acquiring card swipe information. Modifying the transaction queue information based on the card swipe information and the virtual ticket identifier information ensures that entry and exit operations for each segment of the journey are paired, data is complete, and tamper-proof. Therefore, determining the corresponding ticket switching instruction information based on the transaction queue modification information enables automatic closure of the current ticket and seamless activation of the next ticket, all completed at the card end. This allows users to complete seamless switching without secondary card swipes or manual operation.

[0083] For example, to help understand the implementation process of the multi-mode travel integrated ticketing switching method based on embedded security elements obtained by combining this embodiment with the above embodiment one, please refer to... Figure 10 , Figure 10 A simplified flowchart of a multi-mode travel integrated ticket switching method based on embedded security elements is provided, specifically: The travel app on the user terminal (smartphone or NFC POS terminal) initiates a trip planning request to the trip planning module of the backend service. The backend can combine GIS services and traffic big data to generate segmented trip contracts (TCs) and send them to the NFC driver and middleware on the user terminal via a secure channel through REST API. The NFC middleware establishes an SCP03 secure channel with the eSE in the super SIM card and transmits the TC to the eSE for storage. The eSE manages multiple virtual ticket applications (VTAs) in parallel, corresponding to transportation modes such as subway, bus, bicycle, and taxi. It also has built-in SM2 private key, SM4 session key, and fare calculation module. When the user swipes the card, the eSE automatically activates the VTA corresponding to the current segment based on the TC, completes the entry signature, exit fare calculation, and encrypted update of the transaction queue (TQ), and seamlessly switches to the next VTA at the end of the segment. After the entire trip is completed, the terminal reports the complete TQ to the backend clearing module. The clearing module verifies the signature, decrypts the record, adds the fee according to the TC, triggers the deduction settlement, and returns the clearing result to the travel app and synchronizes it with the external payment system and operator system, thus realizing one-card access.

[0084] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the multi-mode travel integrated ticket switching method based on embedded security elements in this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0085] This application also provides a multi-mode travel integrated ticket switching device based on embedded security elements. Please refer to [link / reference]. Figure 11 The multi-mode travel integrated ticket switching device based on embedded security elements includes: Module 10 is used to receive itinerary contract information; Processing module 20 is used to determine virtual ticket identification information and corresponding transaction queue information based on the itinerary segment information and transportation mode information in the itinerary contract information; Processing module 20 is further configured to determine ticket switching instruction information based on the virtual ticket identification information and the transaction queue information; The execution module 30 is used to control the system to switch the virtual tickets corresponding to the itinerary contract information one by one based on the ticket switching instruction information.

[0086] The acquisition module 10 is also used to acquire travel request information and security channel information, wherein the travel request information includes departure information, destination information and travel preference information; The system calls a preset background itinerary planning service interface to process the departure point information, the destination information, and the travel preference information to determine service processing information. The itinerary contract information corresponding to the secure channel information is determined based on the service processing information.

[0087] The processing module 20 is further configured to determine the itinerary sequence information based on the itinerary segment information in the itinerary contract information; The virtual ticket identifier is identified based on the transportation mode information in the trip contract information, and the virtual ticket identifier information is determined. The transaction queue information corresponding to the itinerary sequence information is determined based on the virtual ticket identification information.

[0088] The processing module 20 is also used to acquire card swipe information; Based on the card swipe information and the virtual ticket identification information, the transaction queue information is modified to determine the transaction queue modification information; Based on the transaction queue change information, the corresponding ticket switching instruction information is determined.

[0089] The processing module 20 is further configured to determine virtual ticket activation instruction information based on the virtual ticket identification information when the card swipe information is for station entry card swipe; Generate the corresponding entry signature certificate information based on the virtual ticket activation instruction information; The transaction queue information is modified based on the signature credential information to obtain transaction queue modification information.

[0090] The processing module 20 is also used to determine the fee information under the preset fare rules based on the virtual ticket identification information when the card swipe information is an exit card swipe. Based on the aforementioned fee information, determine the corresponding exit signature voucher information; The transaction queue information is modified based on the outbound signature certificate information to obtain transaction queue modification information.

[0091] The execution module 30 is also used to obtain incremental trip contract information, which includes operation type information, insertion position information, and newly added trip segment information; The ticket switching instruction information is adjusted based on the digital signature in the incremental travel contract information to determine the ticket switching instruction adjustment information; Based on the ticket switching instruction, the adjustment information control system switches the virtual tickets corresponding to the itinerary contract information one by one.

[0092] The multi-mode travel integrated ticketing device based on embedded secure elements provided in this application, employing the multi-mode travel integrated ticketing method based on embedded secure elements in the above embodiments, can solve the technical problem of how to efficiently achieve seamless switching of multi-mode tickets at the card end. Compared with the prior art, the beneficial effects of the multi-mode travel integrated ticketing device based on embedded secure elements provided in this application are the same as those of the multi-mode travel integrated ticketing method based on embedded secure elements provided in the above embodiments, and other technical features in the multi-mode travel integrated ticketing device based on embedded secure elements are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0093] This application provides a multi-mode travel integrated ticketing switching device based on embedded security elements. The multi-mode travel integrated ticketing switching device based on embedded security elements includes: at least one processor; and a memory communicatively connected to at least one processor; wherein the memory stores instructions executable by at least one processor, and the instructions are executed by at least one processor to enable at least one processor to execute the multi-mode travel integrated ticketing switching method based on embedded security elements in the above embodiment 1.

[0094] The following is for reference. Figure 12 This document illustrates a structural schematic diagram of a multi-mode travel integrated ticketing device based on embedded secure elements, suitable for implementing embodiments of this application. The multi-mode travel integrated ticketing device based on embedded secure elements in embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital radio receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), and in-vehicle terminals (e.g., in-vehicle navigation terminals), as well as fixed terminals such as digital TVs and desktop computers. Figure 12 The multi-mode travel integrated ticketing device based on embedded security elements shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0095] like Figure 12 As shown, the multi-mode travel ticketing device based on embedded security elements may include a processing unit 1001 (e.g., a central processing unit, a graphics processor, etc.), which can perform various appropriate actions and processes according to a program stored in ROM (Read Only Memory) 1002 or a program loaded from storage device 1003 into RAM (Random Access Memory) 1004. RAM 1004 also stores various programs and data required for the operation of the multi-mode travel ticketing device based on embedded security elements. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via bus 1005. Input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the multi-modal travel ticketing device based on embedded secure elements to communicate wirelessly or wiredly with other devices to exchange data. Although the figure shows a multi-modal travel ticketing device based on embedded secure elements with various systems, it should be understood that it is not required to implement or have all the systems shown. More or fewer systems can be implemented alternatively.

[0096] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0097] The multi-mode travel integrated ticketing device based on embedded secure elements provided in this application, employing the multi-mode travel integrated ticketing method based on embedded secure elements in the above embodiments, can solve the technical problem of how to efficiently achieve seamless switching of multi-mode tickets at the card end. Compared with the prior art, the beneficial effects of the multi-mode travel integrated ticketing device based on embedded secure elements provided in this application are the same as those of the multi-mode travel integrated ticketing method based on embedded secure elements provided in the above embodiments, and other technical features in this multi-mode travel integrated ticketing device based on embedded secure elements are the same as those disclosed in the previous embodiment method, and will not be repeated here.

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

[0099] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0100] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, which are used to execute the multi-mode travel integrated ticketing switching method based on embedded security elements in the above embodiments.

[0101] The computer-readable storage medium provided in this 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 thereof. More specific examples of computer-readable storage media 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 fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0102] The aforementioned computer-readable storage medium may be included in a multi-mode travel integrated ticketing switching device based on an embedded secure element; or it may exist independently and not be assembled into a multi-mode travel integrated ticketing switching device based on an embedded secure element.

[0103] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by a multi-mode travel integrated ticketing switching device based on an embedded secure element, the device causes the following actions: receiving travel contract information; determining virtual ticket identification information and corresponding transaction queue information based on travel segment information and traffic mode information in the travel contract information; determining ticket switching instruction information based on the virtual ticket identification information and the transaction queue information; and controlling the system to switch virtual tickets corresponding to the travel contract information one by one based on the ticket switching instruction information.

[0104] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

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

[0106] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0107] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described multi-mode travel integrated ticketing switching method based on embedded security elements. This solves the technical problem of how to efficiently achieve seamless switching of multi-mode tickets at the card end. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the multi-mode travel integrated ticketing switching method based on embedded security elements provided in the above embodiments, and will not be repeated here.

[0108] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.< / aid> < / lc> < / lc> < / lc> < / aid> < / lc> < / lc> < / lc> < / lc> < / lc>

Claims

1. A multi-modal integrated ticketing switching method based on an embedded secure element, characterized in that, The method includes: Receive itinerary contract information; Based on the itinerary segment information and transportation mode information in the itinerary contract information, determine the virtual ticket identification information and the corresponding transaction queue information; The ticket switching instruction information is determined based on the virtual ticket identification information and the transaction queue information; Based on the ticket switching instruction information, the control system switches the virtual tickets corresponding to the itinerary contract information one by one.

2. The method of claim 1, wherein, The steps for receiving travel contract information include: Obtain travel request information and security channel information, wherein the travel request information includes departure point information, destination information, and travel preference information; The system calls a preset background itinerary planning service interface to process the departure point information, the destination information, and the travel preference information to determine service processing information. The itinerary contract information corresponding to the secure channel information is determined based on the service processing information.

3. The method of claim 1, wherein, The step of determining the virtual ticket identifier information and the corresponding transaction queue information based on the itinerary segment information and transportation mode information in the itinerary contract information includes: The itinerary sequence information is determined based on the itinerary segment information in the itinerary contract information; The virtual ticket identifier is identified based on the transportation mode information in the trip contract information, and the virtual ticket identifier information is determined. The transaction queue information corresponding to the itinerary sequence information is determined based on the virtual ticket identification information.

4. The method of claim 1, wherein, The step of determining the ticket switching instruction information based on the virtual ticket identification information and the transaction queue information includes: Obtain card swipe information; Based on the card swipe information and the virtual ticket identification information, the transaction queue information is modified to determine the transaction queue modification information; Based on the transaction queue change information, the corresponding ticket switching instruction information is determined.

5. The method of claim 4, wherein, The card swipe information refers to the card swipe for entering the station; The step of modifying the transaction queue information based on the card swipe information and the virtual ticket identification information, and determining the transaction queue modification information, includes: When the card swipe information is for station entry, the virtual ticket activation instruction information is determined based on the virtual ticket identification information; Generate the corresponding entry signature certificate information based on the virtual ticket activation instruction information; The transaction queue information is modified based on the signature credential information to obtain transaction queue modification information.

6. The method as described in claim 4, characterized in that, The card swipe information is for exiting the station. The step of modifying the transaction queue information based on the card swipe information and the virtual ticket identification information, and determining the transaction queue modification information, includes: When the card swipe information is for exiting the station, the fare information under the preset fare rules is determined based on the virtual ticket identification information; Based on the aforementioned fee information, determine the corresponding exit signature voucher information; The transaction queue information is modified based on the outbound signature certificate information to obtain transaction queue modification information.

7. The method as described in claim 1, characterized in that, The step of switching virtual tickets corresponding to the itinerary contract information one by one based on the ticket switching instruction information control system includes: Obtain incremental trip contract information, which includes operation type information, insertion position information, and newly added trip segment information; The ticket switching instruction information is adjusted based on the digital signature in the incremental travel contract information to determine the ticket switching instruction adjustment information; Based on the ticket switching instruction, the adjustment information control system switches the virtual tickets corresponding to the itinerary contract information one by one.

8. A multi-mode travel integrated ticket switching device based on embedded security elements, characterized in that, The device includes: The acquisition module is used to receive itinerary contract information; The processing module is used to determine the virtual ticket identification information and the corresponding transaction queue information based on the itinerary segment information and transportation mode information in the itinerary contract information; The processing module is also used to determine ticket switching instruction information based on the virtual ticket identification information and the transaction queue information; The execution module is used to control the system to switch the virtual tickets corresponding to the itinerary contract information one by one based on the ticket switching instruction information.

9. A multi-mode travel integrated ticket switching device based on embedded security elements, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the multi-mode travel integrated ticketing switching method based on embedded security elements as described in any one of claims 1 to 7.

10. 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. When the computer program is executed by a processor, it implements the steps of the multi-mode travel integrated ticket switching method based on embedded security elements as described in any one of claims 1 to 7.

Images