Secure payment method and system

Abstract

The invention discloses a secure payment method and system, and the method comprises the steps: recognizing a consumption scene according to the real-time position data of an electronic student identity card, and generating a payment account activation instruction corresponding to the consumption scene; loading a matched payment account according to the payment account activation instruction, completing a transaction, and packaging a consumption amount, transaction time and position coordinates to generate a consumption-positioning associated data packet with a scene label; based on the consumption-positioning associated data packet with the scene label, integrating according to a timestamp sequence to form a consumption-track space-time sequence data set containing multi-scene payment information and continuous position information; and executing space-time correlation analysis on the consumption-trajectory space-time sequence data set to generate abnormal early warning information containing abnormal behavior types and abnormal positions. According to the embodiment of the invention, multi-dimensional perception and real-time risk judgment of student payment behaviors can be realized, and the security and controllability of campus payment are improved.

Description

Technical Field

[0001] This invention belongs to the field of smart education technology, specifically a secure payment method and system. Background Technology

[0002] In recent years, with the continuous advancement of campus informatization, electronic student IDs have gradually become an important tool for student identification and daily management. In the payment field, existing technologies typically link electronic student IDs to prepaid accounts, enabling convenient consumption within the campus. However, traditional payment methods mainly focus on the transaction itself, lacking dynamic perception of the consumption scenario and security risk control capabilities, and are unable to effectively identify abnormal consumption behavior. Especially when minors use these systems, there are often risks such as account theft, irrational consumption, or abnormal location, which existing systems struggle to monitor and warn of in a timely manner. Furthermore, conventional payment systems do not fully integrate the spatiotemporal behavioral characteristics of students for comprehensive analysis, resulting in a single dimension of risk control judgment and a delayed response, failing to meet the needs of real-time monitoring and intelligent intervention of payment behavior in campus security management. Summary of the Invention

[0003] The purpose of this invention is to provide a secure payment method and system to address the shortcomings of existing technologies, enabling multi-dimensional perception and real-time risk assessment of student payment behavior, thereby improving the security and controllability of campus payments.

[0004] One embodiment of this application provides a secure payment method, the method comprising: The system identifies the consumption scenario based on the real-time location data of the electronic student ID and generates a corresponding payment account activation instruction. The matching payment account is loaded according to the payment account activation instruction and the transaction is completed. After the transaction is completed, the real-time location coordinates of the electronic student ID are obtained, and the consumption amount, transaction time and location coordinates are packaged to generate a consumption-location associated data package with scene tags. Based on consumption-location associated data packets with scene labels, the student's historical consumption records and historical trajectory data are retrieved synchronously and integrated in the order of timestamps to form a consumption-trajectory spatiotemporal sequence dataset containing multi-scene payment information and continuous location information. Perform spatiotemporal correlation analysis on the consumption-trajectory spatiotemporal sequence dataset to determine whether abnormal behavior has occurred. If abnormal behavior has occurred, generate abnormal warning information containing the type of abnormal behavior and the location of the abnormal behavior.

[0005] Another embodiment of this application provides a secure payment system, the system comprising: The identification module is used to identify the consumption scenario based on the real-time location data of the electronic student ID and generate a corresponding payment account activation instruction. The transaction module is used to load the matching payment account according to the payment account activation instruction and complete the transaction. After the transaction is completed, the real-time location coordinates of the electronic student ID are obtained, and the consumption amount, transaction time and location coordinates are packaged to generate a consumption-location associated data package with scene tags. The integration module is used to synchronously retrieve the student's historical consumption records and historical trajectory data based on consumption-location associated data packets with scene labels, and integrate them in the order of timestamps to form a consumption-trajectory spatiotemporal sequence dataset containing multi-scene payment information and continuous location information; The early warning module is used to perform spatiotemporal correlation analysis on the consumption-trajectory spatiotemporal sequence dataset to determine whether abnormal behavior has occurred. If abnormal behavior occurs, it generates abnormal early warning information containing the type and location of the abnormal behavior.

[0006] Another embodiment of this application provides a storage medium storing a computer program, wherein the computer program is configured to execute the method described in any of the preceding claims when running.

[0007] Another embodiment of this application provides an electronic device including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the method described in any of the preceding claims.

[0008] Compared with existing technologies, the secure payment method provided by this invention can realize multi-dimensional perception and real-time risk assessment of students' payment behavior, thereby improving the security and controllability of campus payments. Attached Figure Description

[0009] Figure 1 A hardware structure block diagram of a computer terminal for a secure payment method provided in an embodiment of the present invention; Figure 2 A flowchart illustrating a secure payment method provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of a secure payment system provided in an embodiment of the present invention. Detailed Implementation

[0010] The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.

[0011] This invention first provides a secure payment method that can be applied to electronic devices, such as computer terminals, specifically ordinary computers.

[0012] The following detailed explanation uses a computer terminal as an example. Figure 1This is a hardware structure block diagram of a computer terminal for a secure payment method provided in an embodiment of the present invention. (See diagram below.) Figure 1 As shown, the computer device includes a processor, memory, and network interface connected via a system bus, wherein the memory may include non-volatile storage media and internal memory.

[0013] See Figure 2 The present invention provides a secure payment method, which may include the following steps: S201: Identify the consumption scenario based on the real-time location data of the electronic student ID and generate a payment account activation instruction corresponding to the consumption scenario; Specifically, it can acquire multi-source positioning data from electronic student ID cards, collect real-time location information through the terminal's built-in positioning module, and filter out positioning drift data to obtain pre-processed real-time positioning coordinates. I. Multi-source positioning module and data acquisition The electronic student ID card has a built-in BeiDou / GPS / LBS tri-mode positioning module. The core parameters and data acquisition logic of the module are as follows: Positioning accuracy: In open outdoor environments (such as playgrounds), BeiDou + GPS dual-mode positioning accuracy is 1-3 meters; in indoor / obstructed environments (such as teaching building corridors), LBS base station positioning accuracy is 10-50 meters (meeting the accuracy requirements for scene recognition; centimeter-level accuracy is not required for scene recognition on campus); or, indoor positioning can also be achieved through WiFi and Bluetooth solutions. Data collection frequency: Default continuous collection every 30 seconds. When an NFC wake-up signal is detected (such as when the device is near the cafeteria POS machine), real-time data collection is triggered (the collection interval is shortened to 1 second to ensure that the location data is up-to-date during the transaction). Data format: The collected raw location information includes "latitude and longitude (WGS84 coordinate system), positioning timestamp, positioning type (BeiDou / GPS / LBS), signal strength (number of satellites / base station signal dBm)". For example, a piece of raw data is "30°15′25.3″N, 120°05′18.6″E, 2025-09-01 12:25:30, positioning type: BeiDou (8 satellites), signal strength: -85dBm".

[0014] II. Positioning Drift Data Filtering Method Location drift refers to the abnormal location output by the positioning module due to signal interference (such as WiFi signals on campus or obstruction by metal buildings) (e.g., jumping instantly from the cafeteria to a street 1 kilometer away). It is addressed using a Kalman filter algorithm combined with continuous frame consistency verification. The specific implementation is as follows: Kalman filter preprocessing: The original data is corrected through the "prediction-update" loop of Kalman filtering—first, the theoretical position of the current frame is predicted based on the position of the previous frame, and then the optimal estimate is updated by combining the original position of the current frame. For example, if the position of the previous frame is (30°15′25.3″, 120°05′18.6″), the predicted position of the current frame is (30°15′25.4″, 120°05′18.7″), the original position of the current frame is (30°15′25.5″, 120°05′18.8″), and the optimal position after updating is (30°15′25.45″, 120°05′18.75″), thus reducing the influence of instantaneous noise. Consecutive Frame Consistency Check: A "drift judgment threshold" is set—if the Euclidean distance deviation between five consecutive frame positions exceeds 10 meters (the maximum single scene span within a campus is typically ≤500 meters, and a 10-meter threshold can effectively identify drift), the data is judged as drifted. For example, in a certain five-frame position, if the third frame suddenly jumps to (30°16′00.0″, 120°06′00.0″), the distance from the second frame is approximately 1200 meters, far exceeding the 10-meter threshold, and is judged as drifted. Drift data replacement: For frames identified as drifting, replace them with the average position values ​​of the previous 3 frames and the last 2 frames. For example, the drift data of the 3rd frame is calculated using the average latitude and longitude values ​​of the 1st-2nd and 4th-5th frames to ensure continuous and smooth position data.

[0015] III. Real-time positioning coordinate output after preprocessing The filtered positioning coordinates must meet the requirements of "accuracy identifier + data integrity". For example, the output should be "30°15′25.45″N (±2 meters), 120°05′18.75″E (±2 meters), positioning type: Beidou + GPS, signal strength: -82dBm, data status: valid". Here, "±2 meters" is the accuracy range, and "valid" means that it has passed the drift filter and can be used for subsequent scene recognition.

[0016] Construct a scene electronic fence system, and preset the geographical boundaries of three types of consumption scenes in the system: campus scene, public transportation scene, and off-campus scene, and obtain scene fence parameters; I. Construction of Electronic Fences on Campus The campus scene covers "areas where students make daily purchases," including the cafeteria, convenience store, and access control for teaching buildings. It uses rectangular fences (the regular shape that fits the campus wall), and the parameters are based on the actual latitude and longitude of the campus (the precise boundaries are obtained through drone mapping). Fence type: Rectangular (longitude range + latitude range); Coordinate range: 30°15′20.0″-30°15′40.0″ North latitude (latitude span 20 seconds, approximately 550 meters), 120°05′10.0″-120°05′30.0″ East longitude (longitude span 20 seconds, approximately 500 meters); Related consumption scenarios: cafeteria (located within the fence at 30°15′28.0″N, 120°05′18.0″E), convenience store (30°15′32.0″N, 120°05′22.0″E), and access control for the teaching building (30°15′25.0″N, 120°05′15.0″E). Scene fence parameters: Fence ID=S001, Type=Rectangle, Latitude_min=30°15′20.0″, Latitude_max=30°15′40.0″, Longitude_min=120°05′10.0″, Longitude_max=120°05′30.0″, Trigger priority=1 (higher than off-campus scenes, to avoid misjudgment of campus edge locations).

[0017] II. Construction of Electronic Fences for Public Transportation Scenarios The public transportation scenario covers the area surrounding bus stops where students go to and from school, using a circular fence (centered on the bus stop, covering the area where students swipe their cards and wait for the bus). The parameters are based on the latitude and longitude data of the city's public transportation system (obtained from the local transportation department's API). Fence type: Circular (center latitude and longitude + radius); Coordinate range: Centered on the bus stop at the school gate, with coordinates of the center (30°15′18.0″N, 120°05′08.0″E), radius = 50 meters (covering the bus stop and surrounding waiting area, students do not need to stand precisely in the center of the bus stop to be identified); Related consumption scenarios: City bus routes 1 and 5 (bus routes that stop at this station, whose bus terminal NFC signals are bound to this fence); Scene fence parameters: Fence ID=B001, Type=Circular, Center_lat=30°15′18.0″, Center_lng=120°05′08.0″, Radius=50 meters, Trigger condition=NFC signal detection (must satisfy both location and signal to avoid misjudgment in non-public transportation scenarios).

[0018] III. Construction of Electronic Fences in Off-Campus Scenarios The off-campus scene refers to the area outside the campus and the bus scene. It uses an exclusionary fence (i.e., all areas not belonging to the campus S001 or bus B001 fences). No separate coordinate range needs to be set; only the "default scene" parameter needs to be defined. Fence type: Virtual exclusion type (no physical coordinate range, determined by whether it is outside the S001 or B001 fence); Related consumption scenarios: off-campus convenience stores, bookstores, stationery stores (off-campus locations where students may make purchases, requiring parental authorization for transactions); Scene fence parameters: Fence ID=O001, Type=Exclusion type, Associated exclusion fence=S001+B001, Trigger condition=Location is not within S001 / B001 and there is no bus NFC signal.

[0019] IV. Scene Fence Parameter Storage and Update All scene fence parameters are stored on the local security chip of the electronic student ID (such as NXP SE050), and simultaneously synchronized to the cloud management platform. Schools / parents can update the parameters according to the actual situation (such as adjusting the S001 fence range after campus expansion). Updates must be transmitted through an encrypted channel (RSA-2048 encryption) to prevent parameters from being tampered with.

[0020] The system assists in detecting signals from surrounding devices. The electronic student ID card scans devices that contain at least RFID and / or NFC. If a unique NFC signal specific to the bus terminal is detected, it is marked as a bus scenario candidate. If no signal is detected, the system combines real-time positioning coordinates to match the scene fence and obtain the scene candidate result. I. Electronic Student ID NFC Module and Signal Scanning The electronic student ID card has a built-in NFC module (supporting ISO14443A / B protocols and compatible with the Type A protocol commonly used in public transport cards). The core parameters and scanning logic of the module are as follows: Operating frequency: 13.56MHz (the standard operating frequency of NFC for public transport terminals, to avoid interference with other wireless signals); Scanning range: 0-10 cm (when students swipe their cards, the distance between the electronic student ID and the bus terminal is usually ≤5 cm. This range ensures that only the signal of the transaction terminal at close range is detected). Scanning frequency: When the location coordinates of the electronic student ID are within 100 meters of the bus fence B001, the NFC module is triggered to scan at a high frequency (10 times / second); if in other areas, the scanning frequency is reduced to 1 time / second (to reduce power consumption). Signal strength is measured in dBm (decibels and milliwatts). The smaller the value, the weaker the signal. For example, the NFC signal strength of a bus terminal is about -40dBm at a distance of 5 cm and about -60dBm at a distance of 10 cm.

[0021] II. NFC signal recognition unique to bus terminals The NFC signal of public transport terminals (such as onboard POS machines on city buses) has a "specific manufacturer ID + protocol field". Electronic student ID cards distinguish public transport from other NFC devices (such as cafeteria POS machines and convenience store card readers) by recognizing these features. Specifically, this is implemented as follows: Signal feature extraction: After the electronic student ID card scans the NFC signal, it parses the "manufacturer code" (the manufacturer code for public transport terminals is usually 0x0001, and the code for cafeteria POS machines is 0x0002) and the "application ID" (the application ID for public transport is 0xA0000000031010, and the application ID for campus is 0xA0000000081010). Bus signal determination: If the manufacturer code is 0x0001 and the application ID is 0xA0000000031010, and the NFC signal strength is ≥-50dBm (ensuring it is a near-field bus terminal, not a distant signal interference), then it is determined to be a "bus terminal-specific NFC signal". Candidate marker: For example, if an electronic student ID card is scanned near a bus stop at the school gate and an NFC signal strength of -45dBm is detected, with manufacturer code 0x0001 and application ID 0xA0000000031010, it is immediately marked as a "bus scenario candidate" and the signal detection timestamp (2025-09-01 17:30:45) is recorded.

[0022] III. Candidate Matching for Scenarios When There is No NFC Signal for Public Transportation If the electronic student ID does not detect a bus-specific NFC signal (or the signal strength is <-50dBm), candidate results are generated based on the "containment relationship between real-time positioning coordinates and scene fences". The specific judgment logic is as follows: Campus scene candidate determination: Substitute the preprocessed real-time positioning coordinates (e.g., 30°15′25.45″, 120°05′18.75″) into the parameters of the campus fence S001, and determine whether it satisfies "latitude_min≤lat≤latitude_max and longitude_min≤lng≤longitude_max" - the latitude 30°15′25.45″ is within 30°15′20.0″-30°15′40.0″, and the longitude 120°05′18.75″ is within 120°05′10.0″-120°05′30.0″, and is determined as "campus scene candidate"; Off-campus scene candidate determination: If the location coordinates are not within the campus fence S001 and not within the B001 bus fence (e.g., coordinates 30°15′10.0″, 120°05′05.0″, 100 meters from the edge of one fence S001 and 80 meters from the edge of another fence B001), then it is determined as an "off-campus scene candidate"; Candidate Result Output: Each candidate result must include "Scenario Type, Judgment Criteria, and Confidence Level", for example, "Candidate for On-Campus Scene, Judgment Criteria: Location within S001 fence, Confidence Level 98%", "Candidate for Off-Campus Scene, Judgment Criteria: Location outside S001 / B001 and no public transport NFC signal, Confidence Level 95%".

[0023] The system determines the consumption scenario and generates instructions, comparing the scenario candidate results with the scenario fence parameters: if the location coordinates are within the campus fence, it is determined to be an on-campus scenario, triggering the campus payment account activation instruction; if a bus NFC signal is detected, it is determined to be a bus scenario, triggering the bus payment account activation instruction; otherwise, it is determined to be an off-campus scenario, triggering the social payment account activation instruction, thus obtaining the payment account activation instruction for the corresponding consumption scenario.

[0024] I. Priority Rules for Scene Determination Because the public transportation scenario requires dual verification of "location + signal" (a single location may cover both the bus and the edge of the campus), a priority is set as "bus NFC signal > campus fence location > off-campus default" to avoid conflicts between multiple scenarios: Highest priority: Bus NFC signal: If step three marks it as "Bus scenario candidate" (bus-specific NFC signal detected), regardless of whether the location is within the bus fence, it is directly determined as "bus scenario" (for example, if a student swipes their card 10 meters outside the bus fence in advance, it still needs to be identified as a bus scenario). Second highest priority: Campus fence location: If no bus NFC signal is detected, but the location is within the campus fence S001, it is determined to be "campus scene"; Default priority: Off-campus scenario: If there is no NFC signal for public transportation and the location is not within the campus fence, it is determined to be an "off-campus scenario".

[0025] II. Account Activation Command Generation for Different Scenarios Each scenario corresponds to a unique payment account (campus account, public transport account, social account, stored in different partitions of the electronic student ID's security chip). The activation command must include "scenario identifier, account ID, activation timestamp, and encrypted verification code" to ensure that the command is unique and cannot be tampered with. Campus scene activation command: Scene identifier = "SCHOOL" (2 bytes); Account ID = "SCH2025001" (Unique identifier for student campus account, linked to the school's financial system); Activation timestamp = "20250901122530" (year, month, day, hour, minute, second, 14 bytes); Encryption verification code = "A3F2D1E4" (generated using AES-128 encryption based on the instruction content, 4 bytes); A complete instruction example: "SCHOOL|SCH2025001|20250901122530|A3F2D1E4". The instruction is transmitted to the payment module via the internal bus of the electronic student ID card, triggering the decryption and loading of the campus account.

[0026] Bus Scene Activation Command: Scene identifier = "bus" (2 bytes); Account ID = "bus2025001" (Unique identifier for student bus account, linked to the local transportation card system); Activation timestamp = "20250901173045"; Encryption verification code = "B7C8E9F0"; A complete instruction example: “bus|bus2025001|20250901173045|B7C8E9F0”. After receiving this instruction, the payment module immediately closes the campus account channel and only retains the NFC communication permission of the bus account.

[0027] Off-campus scene activation command: Scene identifier = "OUTSIDE" (2 bytes); Account ID = "OUT2025001" (Unique identifier for student's social payment account, requires parental authorization); Activation timestamp = "20250901180520"; Encryption verification code = "C1D2E3F4"; A complete example of the command is: "OUTSIDE|OUT2025001|20250901180520|C1D2E3F4". This command will also trigger an authorization request in the parent's app (the account can only be officially activated after the parent scans the code to confirm).

[0028] III. Command Verification and Error Handling After receiving the activation instruction, the payment module of the electronic student ID card must first verify the "encrypted verification code" (decrypt the verification code using the locally stored key and compare it with the instruction content). If the verification fails (e.g., the instruction has been tampered with), the account activation will be refused and an error log will be recorded. If the verification is successful, the corresponding account will be loaded according to the instruction, and an "activation successful" receipt will be returned (e.g., "bus account activation successful, time 20250901173046"), completing the closed loop of scenario determination and instruction execution.

[0029] S202, Load the matching payment account according to the payment account activation instruction and complete the transaction. After the transaction is completed, obtain the real-time location coordinates of the electronic student ID card, and package the consumption amount, transaction time and location coordinates to generate a consumption-location associated data package with scene tags. Specifically, it can parse the payment account activation instruction, extract the scenario type and target account identifier from the instruction, decrypt the target account's storage key, and obtain the account decryption key; I. Structured Format and Parsing Logic of Payment Account Activation Instructions The payment account activation instruction uses a structured format of "field separator + verification code," which is parsed by the main controller of the electronic student ID (such as the STM32H743 microprocessor, which supports high-security data processing). The format definition and parsing process are as follows: Command format: The command consists of four parts: "Scenario type | Target account identifier | Activation timestamp | Encryption verification code". Each field is separated by "|". The total length is fixed at 48 bytes (to ensure transmission and parsing efficiency). For example, the activation command for the bus scenario is "bus|bus2025001|20250901173045|B7C8E9F0". Scene type (2 bytes): Identifies the consumption scene. "bus" indicates a public transportation scene, "school" indicates a school scene, and "outside" indicates a school scene. It uses ASCII encoding for easy and quick identification. Target account identifier (10 bytes): Uniquely identifies the payment account. For example, in "bus2025001", "bus" represents the account type, and "2025001" is the student's unique ID (bound to the electronic student ID terminal ID). Activation timestamp (14 bytes): The format is "YYYYMMDDHHMMSS", such as "20250901173045", which represents 17:30:45 on September 1, 2025. It is used to prevent command replay attacks (the command will become invalid if it is not executed within 5 minutes). Encryption verification code (4 bytes): A verification value generated using the AES-128 algorithm based on the first three fields, used to verify the integrity of the instruction, such as "B7C8E9F0".

[0030] Parsing process: After receiving the instruction, the main controller first separates the fields by "|" and verifies whether the length of each field meets the requirements (2 bytes for scene type, 10 bytes for account identifier, etc.). If the field length does not match, it is determined to be an invalid instruction; if it matches, the scene type and target account identifier are extracted. For example, the scene type "bus" and the target account identifier "bus2025001" are extracted from the above instruction and temporarily stored in the temporary buffer area of ​​the main controller (easily lost when power is off, to avoid information residue).

[0031] II. Location of the target account's stored key and decryption algorithm The target account's storage key (used to unlock account transaction permissions) is encrypted and stored in the NXP SE050 security chip of the electronic student ID (compliant with GlobalPlatform security standards and supporting hardware-level key protection), rather than in the main controller's ordinary storage area, ensuring that the key cannot be illegally read. The decryption process uses a "hardware encryption + key indexing" mechanism, specifically implemented as follows: Key storage location: The security chip has an independent secure storage area (address range 0x0000-0x1FFF). Each payment account has a unique key index (e.g., public transport account key index 0x0001, campus account index 0x0002). The key is stored in encrypted form (encrypted with the security chip's root key, which is fused in the chip hardware and cannot be exported). Key decryption trigger: The main controller sends the extracted target account identifier "bus2025001" to the security chip. The chip parses out the key index 0x0001 corresponding to the account type "bus" and triggers decryption through the internal hardware encryption engine. Decryption Algorithm and Parameters: The AES-128 symmetric encryption algorithm (NIST standard encryption algorithm, high security and efficiency adapted to terminal hardware) is used. The decryption process requires input of "key index + instruction checksum fragment" (the first 2 bytes of the checksum are used as the initialization vector IV), for example: Key index: 0x0001; Initialization vector IV: "B7C8" (extract the first 2 bytes from the checksum "B7C8E9F0"); Decrypted output: 128-bit account decryption key (e.g., "3A7F2D4E8C1B690E5F3A8D2C7E1F4B6D", 16 bytes); Decryption result verification: The security chip returns the decrypted key to the main controller through the encryption channel (SPI bus, data transmission is encrypted with a temporary session key). The main controller verifies the key length (16 bytes) and format (compliant with AES-128 key requirements). If the verification is successful, a valid account decryption key is obtained; otherwise, "decryption failed" is returned, and account loading is terminated.

[0032] Load the matching payment account, unlock the corresponding payment account's transaction permissions using the account decryption key, load the account information into the terminal's NFC module, and simultaneously close payment account channels in other scenarios to obtain the loaded target payment account; I. Composition of Payment Account Information and Unlocking Logic Payment account information is stored in the account partition of the security chip (independent of the key partition, providing dual protection). It includes "essential transaction fields + security verification fields" and can only be read after being unlocked with the account decryption key. The specific structure and unlocking process are as follows: Account information structure (32 bytes): Account card number (16 bytes): e.g., public transport account card number "6222081234567890" (bank card number format conforming to ISO7816 standard); Account balance (4 bytes): stored in cents, such as "000500" representing 5.00 yuan (to avoid floating-point calculation errors); Validity period (4 bytes): Format "YYYYMM", such as "202712" indicating that it expires in December 2027; Security check value (8 bytes): A hash value generated using the SHA-256 algorithm based on the card number and balance, used to verify account integrity during transactions; Unlocking logic: The main controller sends the account decryption key to the security chip. After the chip verifies the validity of the key, it unlocks the account partition through internal hardware circuitry, reads the account information and returns it in encrypted form (using a temporary session key, a new session key is generated each time the account is unlocked). For example, after unlocking the bus account, the encrypted account information "6222081234567890000500202712A1B2C3D4E5F6A7B8" (encrypted format) is returned. The main controller decrypts the information to obtain the plaintext account information.

[0033] II. Account information is loaded into the terminal NFC module The terminal NFC module uses the NXP PN532 (supporting the ISO14443A / B protocol, compatible with common protocols for public transport cards and campus cards). Account information is loaded into the module's temporary transaction buffer (non-volatile storage to prevent data loss in case of power failure) via the I2C communication bus. The loading process is as follows: NFC module initialization: The main controller sends an initialization command (0x000x000x000x010x00) to the PN532, and the module returns a "Ready" response (0x000x010x000x00), setting the module's working mode to "Active Card Reading Mode" (waiting for the consumer terminal to read account information); Account information transmission: The main controller encapsulates the plaintext account information according to the ISO14443A protocol format and transmits it to the buffer of PN532 (address 0x00-0x1F) via the I2C bus. Loading verification: The PN532 verifies the account information format (whether the start and end characters are correct, and whether the field lengths match). If the verification is successful, it returns a "Loading successful" response (0x000x020x000x00), at which point the NFC module is ready to communicate with the consumer terminal. If the verification fails (e.g., a field is missing), it returns an error code (0x000x030x010x00, representing a format error), and reloading is required.

[0034] III. Methods for Closing Payment Account Channels in Other Scenarios To prevent multiple accounts from being accessed simultaneously during transactions (such as confusion between on-campus accounts and public transport accounts), it is necessary to disable account channels for non-target scenarios. This can be achieved through a dual mechanism of "hardware chip selection disabling + software permission locking". Hardware chip select disable: Different accounts within the security chip correspond to independent chip select signals (e.g., the internal account corresponds to the CS1 pin, and the bus account corresponds to the CS2 pin). After the main controller loads the target account (e.g., the bus account), it outputs a low level to disable the chip select signal of the non-target account (CS1 pin is set low), cutting off the communication link between the non-target account and the main controller. Even if the non-target account key is cracked, the account information cannot be read. Software permission locking: At the operating system level (such as FreeRTOS task permission management), the main controller locks the access permissions of non-target accounts. For example, it prohibits the scheduling of "internal account read task" and only allows "public transport account transaction task" to run. At the same time, it clears the residual data of non-target accounts in the main controller cache (overwritten with 0x00). Verification shutdown: The main controller attempts to read information from non-target accounts (such as internal campus accounts). If it returns a "permission denied" response (security chip output 0x000x040x020x00), the channel is considered successfully shut down. If it can still read the information, a hardware reset is triggered, and the shutdown process is re-executed.

[0035] Finally, the target payment account that has been loaded is obtained (such as a public transport account, card number 6222081234567890, balance 5.00 yuan). The NFC module only responds to the read request of this account to prepare for subsequent transactions.

[0036] The electronic student ID establishes an encrypted communication link with the consumer terminal to execute the transaction process, transmits account information and transaction amount, and receives a transaction success receipt from the terminal after the deduction is completed, thus obtaining a transaction success certificate. I. Establishment of an encrypted communication link (based on the TLS 1.3 protocol) The electronic student ID card and the payment terminal (such as a bus POS machine that supports TLS 1.3 encryption) establish a near-field communication link via an NFC module. The link establishment process requires "identity authentication + key exchange" to ensure that both communicating parties are legitimate devices. Device discovery and handshake initialization: When the electronic student ID is brought close to the consumer terminal (distance ≤ 5 cm), the NFC module detects the terminal's NFC wake-up signal (13.56MHz) and sends a "terminal detection" interrupt request to the main controller. The main controller triggers the TLS handshake process and sends a "client Hello" message to the terminal (containing the electronic student ID "STU2025001" and the supported encryption suite "TLS_AES_128_GCM_SHA256"). Server authentication and key exchange: The consumer terminal returns a "Hello" message to the server (confirming the encryption suite and generating a server random number), and at the same time sends the terminal certificate (issued by the city transportation department's CA and containing the terminal's public key). The electronic student ID verifies the certificate's validity (verifying the CA signature and certificate validity period). If the verification is successful, a client random number and a pre-master key (encrypted with the terminal's public key) are generated and sent to the terminal. Session key generation: Both parties generate a session key (AES-128-GCM key) based on the client's random number, the server's random number, and the pre-master key through HKDF (key derivation function), which is used for subsequent transaction data encryption. Once the link is established, the communication latency is ≤100ms (meeting the requirements of real-time transactions).

[0037] II. Encrypted transmission of account information and transaction amounts Transaction data (account information, transaction amount) is transmitted through an established encrypted link, using "symmetric encryption + message authentication code (MAC)" to ensure integrity and confidentiality. Transaction data encapsulation: The main controller encapsulates the account information (card number 6222081234567890) and the transaction amount (e.g., bus fare deduction of 2.00 yuan, format "000200") according to "transaction type + data length + data content", for example, "0x010x146222081234567890000200" (0x01 is the consumption transaction type, 0x14 is the data length of 20 bytes). Data encryption and MAC generation: The encapsulated data is encrypted using AES-128-GCM with a session key, generating ciphertext and a 12-byte GCM authentication tag (used to verify data integrity). For example, the encrypted ciphertext is “3F7A2D4E8C1B690E5F3A8D2C7E1F4B6D”, and the authentication tag is “8A7B6C5D4E3F2A1B0C9D8E7F”. Data transmission and reception confirmation: Encrypted data is transmitted to the consumer terminal via the NFC module. After receiving the data, the terminal decrypts it with the session key and verifies the authentication tag. If the verification is successful, it returns a "data received successfully" confirmation (0x000x050x000x00); if the verification fails (e.g., the data has been tampered with), it returns "data invalid" (0x000x050x010x00), and the electronic student ID needs to be retransmitted.

[0038] III. Fee Deduction Execution and Transaction Success Receipt Verification After the payment terminal completes the deduction, it sends a transaction success receipt to the electronic student ID. The electronic student ID verifies the validity of the receipt to ensure the transaction is genuinely completed. Deduction execution: The consumer terminal reads the decrypted account information, communicates with the charging system (such as the public transportation charging system) in the terminal, deducts the account balance (5.00 yuan → 3.00 yuan), and generates a unique transaction ID (such as "TXN20250901173050001"). Receipt Format and Transmission: A successful transaction receipt includes "Transaction ID (16 bytes) + Deduction Amount (4 bytes) + Transaction Timestamp (14 bytes) + Terminal Signature (8 bytes)," for example, "TXN20250901173050001|000200|20250901173050|A1B2C3D4E5F6A7B8." The receipt is encrypted with the session key and transmitted to the electronic student ID. Receipt Verification: After the electronic student ID card decrypts the receipt, three items are verified: ① Transaction ID format (whether it contains the "TXN" prefix and is 16 bytes long); ② Whether the deducted amount matches the requested amount (000200 corresponds to 2.00 yuan); ③ Terminal signature (verify the validity of the signature using the terminal's public key). If all three items pass, a transaction success certificate (containing all fields of the receipt) is obtained; if any verification fails, the transaction is deemed abnormal, and the "transaction retry" process is triggered (maximum of 3 retries).

[0039] Generate a consumption-location associated data packet. Immediately after a successful transaction, the location module is triggered to obtain the current precise location coordinates. The consumption amount, transaction time, and location coordinates are packaged according to a preset format and encrypted using MQTT or TCP protocol to generate a consumption-location associated data packet with a scene tag.

[0040] I. Real-time triggering and precise coordinate acquisition of the positioning module After a successful transaction, the main controller immediately triggers the built-in Beidou / GPS / LBS tri-mode positioning module (Zhongke Micro AT6558) via GPIO pins to obtain the current precise location coordinates, avoiding location delays that could cause a disconnect between location and consumption behavior. Location trigger timing: Within 100ms after receiving the successful transaction receipt, the main controller outputs a high-level signal to the trigger pin (TRIG pin) of the positioning module, and the module switches from low-power mode (current ≤10mA) to working mode (current ≤50mA) to start positioning; Positioning mode selection: The module automatically selects the positioning mode according to the current environment - in open outdoor environments (such as bus stops), it uses Beidou + GPS dual-mode positioning (positioning accuracy 1-3 meters), and in indoor / obstructed environments (such as canteens), it uses LBS base station positioning (positioning accuracy 10-50 meters), with a positioning time of ≤2 seconds (meeting real-time requirements). Coordinate Format and Precision Marker: The coordinates returned by the positioning module use the WGS84 coordinate system (globally universal and easy for parents to display on the map), and the format is "Latitude (degrees, minutes, and seconds) | Longitude (degrees, minutes, and seconds) | Positioning Type | Precision". For example, the positioning result for a bus scenario is "30°15′18.2″N|120°05′08.5″E|BeiDou + GPS|±2m", where "±2m" is the positioning precision, which is used to determine the reliability of the location during subsequent anomaly analysis.

[0041] II. Preset Format and Packaging of Consumption-Location Associated Data Packets The data package uses JSON format (for easy parsing and cross-platform transmission) and includes "scene tags + consumption data + location data + security verification," ensuring that the fields are complete and the structure is clear. The packaging process is as follows: Field definition and population: Scene tag: String type, corresponding to the consumption scene, such as "bus" (public transportation scene); Payment data: an object type containing transaction ID (txn_id), payment amount (amount, in yuan), and transaction time (txn_time). Location data: an object type that includes latitude (lat), longitude (lng), and location accuracy. Terminal identifier (device_id): String type, unique ID of electronic student ID, such as "STU2025001"; Security checksum: a string type, a hash value generated using the SHA-256 algorithm based on the first four fields; JSON Packaging: The main controller combines the above fields in JSON format to generate a complete data packet.

[0042] III. Encryption Processing and Data Packet Transmission of the MQTT Protocol The MQTT protocol (a lightweight IoT communication protocol suitable for resource-constrained terminal devices) is used to encrypt and transmit data packets to the cloud monitoring platform. The transmission process requires "SSL / TLS encryption + authentication" to ensure that the data is not eavesdropped on or tampered with. MQTT Client Configuration: The MQTT client for electronic student ID cards (developed based on the paho-mqtt open-source library) is configured as follows: broker address: school cloud monitoring platform address (e.g., "mqtt.school-safety.com"), port 1883 (MQTT standard port); Client ID: Consistent with device_id ("STU2025001"), to avoid client conflicts; Connection parameters: QoS level 1 (ensure messages are delivered at least once), clean session (clean_session=true, to avoid historical message residue); SSL / TLS encryption configuration: The client enables TLS 1.3 encryption, loads the platform CA certificate (pre-stored in the security chip, used to verify the broker's identity), and uses the client certificate (issued by the school's CA) for authentication to prevent unauthorized devices from accessing the site; Topic Subscription and Message Publishing: The client subscribes to the topic "student / safety / pay / STU2025001" (used to receive platform feedback), publishes data packets to the topic "student / safety / upload / STU2025001" (used by the platform to receive data), and waits for the platform to return a "receive confirmation" (a PUBACK message of QoS1). If no confirmation is received within 5 seconds, the client republishes (maximum of 2 retries). Encrypted data packet generation: The MQTT message payload is an AES-128-GCM encrypted result of a JSON data packet (encrypted with the MQTT session key), ensuring that even if the data packet is intercepted during transmission, the content cannot be parsed.

[0043] Finally, a consumption-location associated data package with scene tags (after encryption) was generated and successfully transmitted to the cloud monitoring platform, completing the linkage data recording of "transaction-location" and providing real-time data input for the subsequent construction of consumption-trajectory spatiotemporal sequence datasets.

[0044] S203, based on the consumption-location associated data package with scene labels, synchronously retrieve the student's historical consumption records and historical trajectory data, and integrate them in the order of timestamps to form a consumption-trajectory spatiotemporal sequence dataset containing multi-scene payment information and continuous location information; Specifically, key information of the current data packet can be extracted, and core fields such as scene tag, transaction timestamp, consumption amount, location coordinates, and terminal ID can be parsed from the consumption-location associated data packet with scene tag. The data is then categorized and organized according to field type to obtain structured current data. I. Parsing Logic of Consumption-Location Associated Data Packets The current data packets are transmitted using JSON format encryption. Parsing requires first decryption using the electronic student ID card main controller (such as STM32H743) using AES-128-GCM, and then extracting the core information according to the JSON field hierarchy. The parsing process must avoid the risks of format errors and missing fields. Decryption preprocessing: The main controller calls the MQTT session key stored in the security chip to decrypt the received encrypted data packets and obtain plaintext JSON data packets; Field validity verification: Before parsing, verify the integrity of the JSON format (whether it contains "{}" and whether the field separator "," is correct) and checksum verification (recalculate the data packet hash value using the SHA-256 algorithm and compare it with the checksum field; if they match, it is considered valid). If the verification fails, re-request the data packet to avoid parsing invalid data. The core fields are extracted in the following order: "Scene Tag → Transaction Timestamp → Consumption Amount → Location Coordinates → Terminal ID" to ensure that key identifiers (such as Terminal ID) and time bases (transaction timestamps) associated with historical data are obtained first.

[0045] II. Definition, Format, and Examples of Core Fields Each core field has a clear physical meaning and a fixed format. During parsing, strict matching of the format requirements is necessary to avoid data confusion. Scene tags: Definition: Identifies the current consumption scenario, used for subsequent classification of payment information across multiple scenarios; Format: Lowercase string, with values ​​in the range of "school" (on-campus scenario), "bus" (public transportation scenario), and "outside" (off-campus scenario); Example: Extract the scene tag "bus" from the above data packet to indicate that the current scenario is public transportation consumption.

[0046] Transaction timestamp (txn_time): Definition: Records the precise time a transaction is completed, serving as a benchmark for data time alignment; Format: "YYYY-MM-DDHH:MM:SS" (year-month-day hour:minute:second), time zone is UTC+8 (consistent with domestic campus schedules); Example: Extracting the transaction timestamp as "2025-09-01 17:30:50" indicates that the transaction was completed at 17:30:50 on September 1, 2025.

[0047] Amount of consumption: Definition: The amount deducted in the current transaction, accurate to two decimal places, with no negative numbers (only for consumption transactions, no refund scenarios); Format: Numeric type (floating-point type), unit is "yuan"; Example: The amount withdrawn is 2.00 yuan, which corresponds to the cost of a single bus ride.

[0048] Location coordinates: Definition: The real-time location of the electronic student ID card after the transaction is completed, including latitude (lat), longitude (lng) and positioning accuracy, for subsequent trajectory integration; Format: Latitude is in "degrees, minutes, seconds + N / S" (WGS84 coordinate system, N is uniformly used in the Northern Hemisphere), longitude is in "degrees, minutes, seconds + E / W" (E is uniformly used in the Eastern Hemisphere), and accuracy is "±Xm" (X is the positioning error range). Example: The extracted location coordinates are "lat:30°15′18.2″N, lng:120°05′08.5″E, accuracy:±2m", which means the location is at 30°15′18.2″N and 120°05′8.5″E, with a positioning error of no more than 2 meters.

[0049] Terminal ID (device_id): Definition: The unique identifier of the electronic student ID card, used to link the student's historical data (one person, one terminal, ID is bound to student's academic record information); Format: String, consisting of "prefix + year + serial number", where the prefix is ​​fixed as "STU" (student terminal identifier), the year is 4 digits, and the serial number is 3 digits; Example: Extract the terminal ID as "STU2025001", where "STU" is the prefix, "2025" is the year the terminal was issued, and "001" is the serial number of the first terminal in that year.

[0050] III. Categorize and Structure Current Data by Field Type The extracted core fields are categorized by "data type + business meaning" to form structured data (not in tabular form, but organized by logical hierarchy) to facilitate subsequent alignment with historical data. Identification data: Terminal ID (STU2025001), scene tag (bus), used for data association and scene classification; Time-related data: Transaction timestamp (2025-09-01 17:30:50), serving as the benchmark for time alignment; Numerical data: Purchase amount (2.00 yuan), used for subsequent consumption behavior analysis; Geographic data: Location coordinates (30°15′18.2″N, 120°05′08.5″E, ±2m), used for trajectory integration; The final structured representation of the current data is "Terminal ID-STU2025001|Scene Tag-bus|Transaction Timestamp-2025-09-01 17:30:50|Consumption Amount-2.00 Yuan|Location Coordinates-30°15′18.2″N,120°05′08.5″E(±2m)". Each field is associated with a "field name-value" format to ensure that the required information can be quickly located in subsequent calls.

[0051] Retrieve historical data, associate the student's historical database with the terminal ID, retrieve the historical consumption records and historical trajectory data of the past 30 days respectively, filter out invalid data, and obtain the historical consumption dataset and historical trajectory dataset; I. Storage Location and Structure of Historical Database Historical data is stored in the school's cloud-based MySQL database (using a master-slave architecture, with the master database used for writing and the slave database used for reading, ensuring data security and read efficiency). The database is divided into tables according to "business modules," and the core tables related to students include the "Consumption Record Table (payment_history)" and the "Location Data Table (location_history)." The table structure is designed as follows (not in tabular form, but described by field logic): Payment history table: Primary key field: id (auto-incrementing integer, uniquely identifying each consumption record); Associated field: device_id (same as the electronic student ID terminal ID, used to associate students); Business fields: scene (scene tag), txn_id (transaction ID), amount (consumption amount), txn_time (transaction timestamp), txn_status (transaction status, "success" for success, "fail" for failure); Index design: Use device_id+txn_time as a composite index to accelerate queries by terminal ID and time range.

[0052] Trajectory data table (location_history): Primary key field: id (auto-incrementing integer); Related field: device_id (terminal ID); Business fields: lat (latitude), lng (longitude), accuracy (location accuracy), location_time (location timestamp), location_type (location type, "beidou+gps" or "lbs"); Index design: The system uses a composite index of device_id and location_time to support trajectory queries by terminal ID and time range.

[0053] II. Logic for Historical Data Association and Retrieval Based on Terminal ID Using the terminal ID "STU2025001" from the current data as the association key, retrieve historical data for the past 30 days from the cloud database using an SQL query. The retrieval process must ensure accurate time range and data integrity. Association logic: The terminal ID is the unique link between students and historical data. Each terminal ID corresponds to a unique student's student status information in the database (stored in the "student information table (student_info)"). When retrieving data, the student's identity is first confirmed through the device_id (to avoid retrieving data from different students), and then the student's consumption and trajectory data are queried. The 30-day time range is defined as follows: Based on the current transaction timestamp "2025-09-01 17:30:50", the time range is from "2025-08-02 00:00:00" to "2025-09-01 17:30:50", ensuring that the entire 30-day period is covered.

[0054] III. Criteria and Filtering Methods for Invalid Data Invalid data will cause deviations in subsequent integration results and must be filtered according to three categories of rules: "incorrect format," "abnormal status," and "time limit exceeded." The filtering process is jointly completed by cloud database query statements and local data verification. Incorrect format data: Judgment criteria: Field format does not meet the preset requirements, such as negative consumption amount, missing "degrees, minutes and seconds" symbols for location coordinates, and timestamp format is "2025 / 09 / 01" (should be "2025-09-01"). Filtering method: Exclude data by SQL conditions during query (e.g., "amount>0"). Validate the format after receiving the data locally. For example, if the lat value of a certain trajectory data is "301518.2N" (missing "°′"), it is determined to be invalid data and removed.

[0055] Abnormal status data: Judgment criteria: The transaction record's txn_status is "fail" (transaction failed), and the trajectory data's location_type is "invalid" (location invalid, such as due to signal loss); Filtering method: When querying consumption records, only data with txn_status='success' is retained. For trajectory data, only data with location_type of "beidou+gps" or "lbs" is retained. For example, if the txn_status of a consumption record is "fail", it is directly excluded from the historical consumption dataset.

[0056] Time limit exceeded data: Judgment criteria: Data timestamps exceeding the "last 30 days" range, or earlier than the student terminal's activation time (e.g., if the terminal was activated on 2025-08-10, the trajectory data on August 2 is invalid). Filtering method: When querying, the time range is limited by the BETWEEN condition, and the terminal activation time is compared locally (stored in the student_info table). For example, if the terminal activation time is 2025-08-10, the trajectory data from August 2 to August 9 is determined to be invalid and removed.

[0057] IV. Output of Historical Consumption Dataset and Historical Trajectory Dataset After filtering, two types of structured historical datasets are obtained, with the data format consistent with the current data, facilitating subsequent integration: Historical spending dataset: Contains 15 successful spending records of this student within the last 30 days; Historical trajectory dataset: Contains 1200 valid location records of the student within the last 30 days.

[0058] Data timestamp alignment is performed by sorting historical consumption datasets, historical trajectory datasets, and current structured data in chronological order based on transaction timestamps. Missing time points in the trajectory data are supplemented by linear interpolation to obtain a time-aligned integrated dataset. I. Selection and Sorting Logic of Timestamp Base The core reason for using "transaction timestamps" instead of "location timestamps" is that consumption data consists of discrete events (e.g., 3-5 purchases per day), while trajectory data is continuously sampled (e.g., every 30 seconds). Transaction timestamps can serve as "key time nodes," allowing for the segmentation of continuous trajectory data to correlate consumption behaviors. The sorting logic is as follows: Data merging: Merge the current structured data, historical consumption dataset, and historical trajectory dataset into a "hybrid dataset" that includes the timestamp field of all consumption and trajectory data (txn_time for consumption data and location_time for trajectory data). Unified naming of timestamps: To facilitate sorting, the txn_time of consumption data and the location_time of trajectory data will be uniformly named "time_stamp" while retaining the original meaning of the fields (e.g., the time_stamp of consumption data is actually the transaction time, and the time_stamp of trajectory data is actually the location time). Time sequence sorting: Sort in ascending order (from earliest to latest) according to the time_stamp format "YYYY-MM-DDHH:MM:SS". Data type (consumption or trajectory) is ignored during sorting, and the timestamp is the only criterion.

[0059] II. Determination of Missing Time Point Trajectory Data and Principle of Linear Interpolation Track data may be missing due to signal obstruction (such as inside a teaching building) (e.g., no location data within a 5-minute period). It is necessary to first determine the missing range and then supplement it using linear interpolation to ensure the continuity of the track data. Missing data determination criteria: The "maximum interval threshold for trajectory data" is set to 60 seconds (trajectory data sampling frequency is 30 seconds / sample, with a maximum interval not exceeding 2 sampling periods). If the time_stamp interval between two adjacent trajectory data sets exceeds 60 seconds, it is determined to be a "missing time point." For example: Track data 1: 2025-08-20 17:20:00; Track data 2: 2025-08-20 17:26:00; If the interval of 6 minutes (360 seconds) is greater than 60 seconds, the time point between 17:20:00 and 17:26:00 is determined to be missing, and trajectory data for the two time points of 17:22:00 and 17:24:00 need to be supplemented.

[0060] Linear interpolation principle: Assuming that the students' movement during the missing time period is uniform linear motion (the students' movement speed within the campus is relatively stable, this assumption holds), then latitude (lat) and longitude (lng) change linearly with time. The interpolation formula is: Missing point timestamp: (k=1,2,...,n-1, (where Δt is the previous valid time, n is the interpolation time interval, and n is the number of missing points). Missing point latitude: ; Longitude of missing point: ; in, For the next valid time, , for Corresponding position coordinates , for The corresponding position coordinates.

[0061] III. Specific Application Examples of Linear Interpolation Taking the missing time point (17:20:00 to 17:26:00) as an example, the trajectory data for 17:22:00 and 17:24:00 are supplemented. The specific calculation process is as follows: Given conditions: t1=17:20:00, lat1=30°15′18.0″N, lng1=120°05′08.0″E; t2=17:26:00, lat2=30°15′24.0″N, lng2=120°05′14.0″E; The number of missing points is n=2, Δt=2 minutes (120 seconds), t1=17:22:00, t2=17:24:00.

[0062] Calculate the missing point at 17:22:00 (t k =17:22:00): Time difference ratio: (t) k -t1) / (t2-t1)=(2×60) / (6×60)=1 / 3; Latitude increment: lat2 - lat1 = 30°15′24.0″N - 30°15′18.0″N = 6.0″; Interpolation latitude: lat k =18.0″+6.0″×(1 / 3)=20.0″, that is, 30°15′20.0″N; Longitude increment: lng2 - lng1 = 120°05′14.0″E - 120°05′08.0″E = 6.0″; Interpolated longitude: lng k =8.0″+6.0″×(1 / 3)=10.0″, that is, 120°05′10.0″E; Positioning accuracy: Take the average accuracy of lat1 and lat2, which is ±2m (both accuracy is ±2m).

[0063] Calculate the missing point at 17:24:00 (t k =17:24:00): Time difference ratio: (4×60) / (6×60)=2 / 3; Interpolated latitude: 18.0″ + 6.0″ × (2 / 3) = 22.0″, which is 30°15′22.0″N; Interpolated longitude: 8.0″ + 6.0″ × (2 / 3) = 12.0″, i.e., 120°05′12.0″E; Positioning accuracy: ±2m.

[0064] IV. Output of Time-Aligned Integrated Dataset After supplementing the missing trajectory data, the integrated dataset is arranged logically as "time_stamp-data type-scene label (consumption data only)-consumption amount (consumption data only)-location coordinates-terminal ID", with continuous time sequence and no missing data.

[0065] This dataset achieves time alignment between consumption data and trajectory data, providing continuous and complete foundational data for the subsequent construction of spatiotemporal sequence datasets.

[0066] A consumption-trajectory spatiotemporal sequence dataset is constructed. The time-aligned integrated data is reorganized according to the dimensions of timestamp-scene-consumption amount-location coordinates, and multi-scene payment switching nodes are marked to form a consumption-trajectory spatiotemporal sequence dataset containing multi-scene payment information and continuous location information.

[0067] I. Logical Order and Basis of Dimensional Reorganization The dimensional reorganization proceeds in the order of "timestamp-scene-consumption amount-location coordinates." This order is designed based on the principle of "time as the axis, scene and consumption as behavioral features, and location as spatial features," which aligns with the core logic of "spatiotemporal sequence" (time + space + behavior). The following points should be noted during reorganization: Timestamp (time_stamp): As the first dimension, it ensures that the dataset is continuous in chronological order, and each timestamp corresponds to a unique record (trajectory or consumption). Scene: As the second dimension, only consumed data has scene labels. The scene label of trajectory data inherits the scene of the previous consumption (e.g., trajectory data at 17:20:00, the previous consumption was the school scene at 17:00:00, then the scene is labeled as school). Trajectory data without historical consumption (e.g., the first time the terminal is used) is labeled as "unknown". Consumption amount: As a third dimension, only consumption data has an amount, and trajectory data is marked as "0.00 yuan" (indicating no consumption); Location coordinates: As the fourth dimension, all data (trajectory and consumption) includes location coordinates. The location coordinates of consumption data are the positioning results after the transaction, while the location coordinates of trajectory data are the coordinates after sampling or interpolation.

[0068] II. Criteria and Marking Methods for Determining Payment Switching Nodes in Multiple Scenarios Scene switching nodes refer to the time points when "scene labels change from one type to another," used for subsequent analysis of students' movement behavior between different scenes. The determination and labeling methods are as follows: Judgment criteria: Compare the scene labels of two adjacent consumption data. If the labels are different, the timestamp of the latter consumption data is the "scene switching node". If there is trajectory data between adjacent consumption data, the scene label of the trajectory data follows the former consumption data, and the switching node is only marked at the consumption data. Labeling method: Add the "[Switch]" label after the "Scene" dimension of the scene switching node, and indicate "Switch from XX scene to XX scene" to facilitate quick identification later.

[0069] III. Structural Example of a Consumption-Trajectory Spatiotemporal Sequence Dataset Based on the above reorganization logic and annotation method, the final dataset contains nearly 30 days of continuous spatiotemporal information. This dataset fully contains four-dimensional information of "time (time_stamp) - scene (scene) - consumption (amount) - location (location)", and annotates scene switching nodes. It not only reflects the switching process of multi-scene payment, but also contains continuous location trajectories, which can be directly used for spatiotemporal correlation analysis to determine whether there is a risk of fraudulent transactions or abnormal behavior such as trajectory deviation.

[0070] S204 performs spatiotemporal correlation analysis on the consumption-trajectory spatiotemporal sequence dataset to determine if any abnormal behavior has occurred. If abnormal behavior occurs, it generates an anomaly warning message containing the type and location of the abnormal behavior. Furthermore, for abnormal consumption transaction behavior, the transaction can be blocked if necessary.

[0071] Specifically, spatiotemporal correlation features can be extracted. Two types of core features can be extracted from the consumption-trajectory spatiotemporal sequence dataset: consumption correlation features and trajectory correlation features. The features are then standardized to obtain a standardized spatiotemporal feature set. I. Extraction of Consumption-Related Features (Reflecting Abnormal Tendencies in Consumption Behavior) The consumption correlation features focus on the "patterns of change in consumption time, location, and amount." Three core features are extracted from the consumption-trajectory spatiotemporal sequence dataset. The calculation process for each feature needs to be explained with a real-world data example. Adjacent consumption time interval (Δt) Definition: The difference in timestamps between two consecutive successful transactions in the dataset, expressed in minutes, is used to determine whether the transaction frequency is abnormal (e.g., frequent transactions within a short period of time may indicate fraudulent activity). Extraction method: Traverse the consumption data in ascending order of timestamps, calculate the difference between the time of the last consumption (t2) and the time of the previous consumption (t1), and use the formula Δt=(t2-t1) / 60 (convert seconds to minutes); Example: Two adjacent consumption records in the dataset are "2025-09-01 17:30:50 (bus scenario, 2.00 yuan)" and "2025-09-01 17:38:20 (off-campus convenience store scenario, 3.50 yuan)", t2-t1=7 minutes 30 seconds=450 seconds, Δt=450 / 60=7.5 minutes.

[0072] "Frequent spending within a short period" refers to spending behavior that occurs three or more times within 10 minutes, spanning different spending scenarios (such as on-campus → off-campus → public transportation) or where the amount of a single spending transaction exceeds the student's usual single spending limit (preset by parents, such as ≤20 yuan for primary school students and ≤50 yuan for middle school students). Not all frequent spending within a short period is considered abnormal. Explanation of reasonableness: Students' daily short-term consumption is context-dependent: such as continuous consumption in the school cafeteria → convenience store (within 2 times) is a normal scenario, but if there are 3 consumptions in the school, convenience store, and bus within 10 minutes, it exceeds the student's movement and consumption logic (such as primary school students cannot spare the time to cross 3 scenarios within 10 minutes).

[0073] Based on account security logic: the typical characteristics of fraudulent transactions are "short time, multiple scenarios, small amount and high frequency" (to circumvent payment limits), while normal student spending is mostly "single scenario, one or two transactions" (such as lunch + stationery purchase), so the two can be clearly distinguished.

[0074] Flexible configuration space is reserved: Parents can adjust the "short-term consumption frequency threshold" through the mini-program (such as allowing middle school students to make two off-campus purchases within 10 minutes) to suit the consumption habits of students of different age groups.

[0075] Straight-line distance between adjacent consumption locations (Δd) Definition: The straight-line distance on the ground between the location coordinates corresponding to two consecutive transactions, in kilometers, is used to determine whether the transaction location is different (transactions in different locations may be fraudulent). Extraction method: The straight-line distance between two points (WGS84 coordinate system) is calculated using the Haversine formula.

[0076] Consumption fluctuation coefficient (CV_amount) Definition: The ratio of the standard deviation to the mean of the three most recent transactions. It is dimensionless and used to determine whether there are abnormal fluctuations in transaction amounts (e.g., a sudden increase in the amount may indicate fraudulent transactions). Extraction method: Take the amount of the current consumption and the previous two consumptions (a1, a2, a3), first calculate the mean μ, then calculate the standard deviation σ, and finally CV_amount=σ / μ; When the volatility coefficient (CV_amount) of spending amount is ≥ 0.5, it is considered an abnormal fluctuation in spending amount. That is, if the standard deviation of the spending amount in the last three transactions reaches 50% or more of the mean, it is considered abnormal. The threshold setting is based on: Based on statistics of student consumption patterns: Through sampling analysis of 30 days of consumption data of 1,000 primary and secondary school students, the average CV_amount of normal consumption is 0.23, and 95% of students have CV_amount ≤ 0.45. Setting 0.5 as the threshold can effectively filter out normal fluctuations (such as 5 yuan lunch on Monday, 8 yuan lunch on Tuesday, and 6 yuan lunch on Wednesday, CV_amount≈0.22), and only capture abnormal situations (such as 5 yuan on Monday, 30 yuan on Tuesday, and 8 yuan on Wednesday, CV_amount≈0.89).

[0077] Adapted to different age groups and consumption scenarios: Primary school students' daily single spending is concentrated between 5-20 yuan, and CV_amount≥0.5 means that the amount fluctuates by more than 10 yuan (e.g., 5 yuan→15 yuan→8 yuan); middle school students' spending is concentrated between 10-50 yuan, and the fluctuation exceeds 25 yuan (e.g., 10 yuan→40 yuan→15 yuan), both of which exceed the normal consumption fluctuation range and require parents' attention.

[0078] II. Extraction of trajectory association features (reflecting the safety tendency of trajectory movement) The trajectory correlation features focus on "deviation from the trajectory and the usual route, movement speed, and dwell time," extracting three core features from the dataset and combining them with students' daily behavioral patterns (such as fixed routes home from school) to identify anomalies. The average deviation (D_dev) between the real-time trajectory and the commonly used route. Definition: The average of the shortest distance between the location coordinates on the real-time trajectory every minute within a certain period (such as the school dismissal period from 17:00 to 18:00), and the preset "frequently used route", in "kilometers", used to determine whether the route has deviated from the safe route; Extraction method: First, preset frequently used routes in the system (e.g., parents set the latitude and longitude sequence of "school → bus stop → home" via a mini-program), then calculate the shortest distance d_i from each sampling point (t_i) on the real-time trajectory to the frequently used route. Finally, D_dev = (d1 + d2 + ... + d n ) / n (where n is the number of sampling points); Example: The shortest distances from the real-time locations of 5 sampling points to the commonly used routes during the school dismissal period are "0.3 km, 0.5 km, 1.2 km, 1.1 km, 1.3 km", D_dev=(0.3+0.5+1.2+1.1+1.3) / 5=4.4 / 5=0.88 km.

[0079] Movement speed per unit time (v_move) Definition: The ratio of the distance between two adjacent sampling points on a real-time trajectory to the time difference, expressed in kilometers per hour, used to determine whether the movement speed is abnormal (e.g., excessive speed may indicate abnormal movement). Extraction method: Calculate the distance (d_move, kilometers, using the Haversine formula) and time difference (Δt_move, hours) between adjacent sampling points, with the formula v_move=d_move / Δt_move; Example: Adjacent sampling points are "17:20:00 (lat=30°15′18.2″N, lng=120°05′08.5″E)" and "17:25:00 (lat=30°16′00.0″N, lng=120°06′00.0″E)", d_move≈1.5 km, Δt_move=5 minutes=5 / 60≈0.083 hours, v_move=1.5 / 0.083≈18 km / h (consistent with the normal walking + bus speed of students, no abnormalities).

[0080] Duration of a single stay (t_stay) Definition: The continuous time a location (a circular area with a radius of 50 meters) stays on a real-time trajectory, measured in minutes, is used to determine whether a person has stayed in an abnormal location for an extended period of time (e.g., staying in an unfamiliar area for too long may pose a safety risk). Extraction method: Traverse the trajectory data. If the positions of consecutive sampling points are all within a 50-meter radius, accumulate the time difference until the position exceeds the range. The accumulated value is t_stay. Example: Sampling points “17:10:00, 17:12:00, 17:15:00” are all within 50 meters of “30°15′00″N, 120°05′00″E”, t_stay=17:15:00-17:10:00=5 minutes (normal stay, possibly waiting for the bus).

[0081] If a single stay lasts for ≥20 minutes and the location is not a "preset safe area", it is considered an abnormal stay.

[0082] Preset safe zones: Parents can set up these zones via a mini-program. These zones include school, home, after-school care facilities, and frequently visited bookstores / stationery stores, forming a circular area with a radius of 50 meters centered on the latitude and longitude.

[0083] Dwell time calculation: The cumulative time during which consecutive sampling points (30 seconds / sample) in the trajectory data all reside within the same non-preset safety zone. Reasoning explanation: To avoid misjudging normal behavior: Students staying in pre-designated safe areas (such as during school lunch break or shopping at a convenience store near home) will not be considered abnormal, regardless of the duration; staying in non-pre-designated areas (such as unfamiliar streets or remote parks) for ≤15 minutes (such as asking for directions or taking shelter from the rain) is normal, while staying for ≥20 minutes may pose safety risks such as getting lost or being stranded.

[0084] To meet the needs of campus safety management: Primary and secondary school students have weak safety awareness and need timely warnings when staying in unfamiliar areas for a long time. The 20-minute threshold can provide a reasonable buffer time and avoid delayed warnings.

[0085] III. Feature Standardization Process (Z-score Standardization) Differences in the dimensions of different features can lead to biases in subsequent rule comparisons (e.g., Δt "7.5 minutes" and Δd "6.2 kilometers" cannot be directly compared). Z-score standardization is used to map all features to the same dimension with a mean of 0 and a standard deviation of 1.

[0086] Perform spatiotemporal correlation analysis and compare the standardized spatiotemporal feature set with the anomaly judgment rule set: if the same student makes two or more out-of-town transactions within 10 minutes and the distance between the two locations exceeds 5 kilometers, a fraud risk judgment is triggered; if the trajectory during the school dismissal period deviates from the usual school dismissal route by more than 1 kilometer, a trajectory deviation judgment is triggered; if none of the rules are met, it is judged as normal behavior, and an anomaly judgment result is obtained. The commonly used school dismissal route refers to a fixed route that is "preset by parents and verified by the system". Specifically, parents enter the latitude and longitude sequence of the starting point (school gate latitude and longitude), the ending point (home / after-school care institution latitude and longitude), and key nodes (such as bus stops and intersections) through the school-home safety mini-program. The system automatically matches the student's valid trajectory data for the past 14 days (excluding location drift data). If the average deviation distance between the trajectory and the preset route is ≤0.3 kilometers, it is confirmed as the commonly used school dismissal route and is dynamically updated.

[0087] Route adjustment mechanism: Parents can manually modify the route. The system will also prompt parents to confirm whether to update the frequently used route if the student takes the new route for 3 consecutive days without any abnormal warning.

[0088] The criteria are consistent with student movement range: Primary and secondary school students' routes home from school are relatively fixed. The maximum deviation distance for normal detours (such as buying stationery or picking up classmates) is usually ≤0.5 kilometers. The 1-kilometer threshold far exceeds the normal detour range, effectively distinguishing between "normal detours" and "trajectory deviations." Reasonableness explanation: Filtering out the impact of positioning drift: The positioning accuracy of the electronic student ID is ±2-50 meters (indoor / obstructed environment). The 1-kilometer threshold is much greater than the positioning error, avoiding misjudgment caused by positioning drift.

[0089] To meet safety warning needs: a deviation of 1 kilometer from the trajectory means that the student may have deviated from the safe route to an unfamiliar area (such as going to other streets instead of home). Combined with the safety sensitivity during the school dismissal period, this threshold can trigger an early warning in a timely manner to ensure student safety.

[0090] I. Detailed Definition of Anomaly Detection Rule Set The rule set is based on the Ministry of Education's requirements for closed-loop safety management and is formulated in combination with students' daily behavioral characteristics. Each rule includes "trigger conditions, threshold standards, and physical meaning": Credit Card Risk Rules Triggering conditions: The consumption behavior of the same student meets the criteria of "closed time + different location"; Threshold standards: ① Time interval Δt ≤ 10 minutes (short period of time); ② Number of transactions N ≥ 2 times (frequent transactions); ③ Δd of any two transactions > 5 kilometers (different locations, exceeding the student's short-term mobility, such as the maximum distance traveled in 10 minutes of walking is about 1 kilometer, and by bus it is about 3 kilometers). Physical meaning: If a student cannot move from point A to point B, which is 5 kilometers away, within 10 minutes to make a purchase, it may be because the card has been stolen.

[0091] Trajectory Deviation Rules Triggering condition: During school dismissal time, the student's trajectory deviates from the usual route beyond the safe range; Threshold standards: ① Time period determination: within the preset school dismissal time (e.g., 17:00-18:00, which can be customized by parents in the mini-program and adjusted according to the season, such as 16:30-17:30 in winter); ② Deviation distance: D_dev>1 km (exceeding the normal route fluctuation range, such as taking a detour to buy things, the deviation is usually ≤0.5 km); ③ Duration: the deviation state lasts for ≥5 minutes (excluding misjudgments caused by instantaneous positioning drift); Physical significance: During school dismissal time, students usually follow a fixed route home. If they deviate from the route by more than 1 kilometer for an extended period, it may indicate that they are lost, stranded, or have other safety issues.

[0092] Normal Behavior Rules Judgment criteria: It does not meet any of the above anomaly rules, and the absolute value of all standardized spatiotemporal feature values ​​is ≤2 (within the 95% confidence interval and without extreme features). Example: A student consumes food at the school cafeteria at 17:30 (Δt = 20 minutes ago, Δd = 0.3 km, D_dev = 0.2 km), which is normal behavior.

[0093] II. Comparison Process of Standardization Features and Rules The comparison is performed in the following priority order: "theft risk → deviation from the tracking → normal behavior" (theft risk has a higher priority and should be handled first). The process is as follows: Risk comparison of fraudulent transactions: Step 1: Filter the consumption records of the same student within the last 10 minutes and count the number of times N; Step 2: If N≥2, calculate Δd for any two consumptions and determine if there is Δd>5 kilometers; Step 3: If both N≥2 and Δd>5 kilometers are satisfied, trigger the fraud risk assessment; otherwise, proceed to trajectory deviation comparison. Example: Student STU2025001 made 2 transactions within the last 10 minutes (N=2), Δt=7.5 minutes ≤ 10 minutes, Δd=6.2 km > 5 km, triggering the risk of fraudulent transactions.

[0094] Trajectory deviation comparison: Step 1: Determine if the current time is within the school dismissal period (e.g., 17:20 is within 17:00-18:00). Step 2: Calculate D_dev for this time period and determine whether D_dev > 1 km; Step 3: Check the duration of the deviation and determine if it is ≥5 minutes; Step 4: If the time period, D_dev, and duration conditions are met simultaneously, trigger the trajectory deviation judgment; otherwise, it is judged as normal behavior. Example: Students are in the dismissal period from 17:20 to 17:25. D_dev = 0.88 km ≤ 1 km, so no trajectory deviation is triggered. If D_dev = 1.2 km > 1 km and continues for 6 minutes, trajectory deviation is triggered.

[0095] Determination of normal behavior: If neither of the above two rules is met, and the absolute values ​​of the standardized feature values ​​(such as Δt_norm=-0.9375, Δd_norm=1.233) are both ≤2, it is judged as normal behavior; Example: A student makes a purchase on campus at 17:30 and then makes a purchase at a bus stop 1.5 kilometers away at 17:50 (Δt = 20 minutes > 10 minutes, Δd = 1.5 kilometers < 5 kilometers, D_dev = 0.3 kilometers < 1 kilometer), which is considered normal.

[0096] III. Output Format of Anomaly Detection Results The judgment result must include "judgment type, triggering rule, and key feature value" to facilitate the subsequent generation of warning information. Example: Fraudulent transaction risk result: "Type of judgment: Fraudulent transaction risk; Triggering rule: Two out-of-town transactions within 10 minutes (Δt=7.5 minutes, N=2, Δd=6.2 km>5 km); Key features: Δt_norm=-0.9375, Δd_norm=1.233; Terminal ID: STU2025001"; Track deviation result: "Judgment type: Track deviation; Triggering rule: During the school dismissal period (17:00-18:00), D_dev=1.2 km>1 km, lasting for 6 minutes; Key features: D_dev_norm=1.4, duration=6 minutes; Terminal ID: STU2025001"; Normal behavior result: "Judgment type: normal behavior; no abnormal rules were triggered; key features: Δt_norm=0.625, Δd_norm=0.33, D_dev_norm=0.2; terminal ID: STU2025001."

[0097] Generate abnormal warning information. If the abnormality judgment result is the risk of fraudulent use, then mark the abnormal behavior type as the risk of fraudulent use and associate the location coordinates of the abnormal behavior; if it is a trajectory deviation, then mark the type as trajectory deviation and attach a comparison map of the deviation route; integrate the abnormality type, abnormal location and timestamp in a fixed format and push them to the parent terminal and the school management platform to generate abnormal warning information containing the abnormal behavior type and abnormal location.

[0098] I. Generation of Credit Card Fraud Risk Warning Information Warning messages should highlight the "time, location, and amount of abnormal spending," and include location coordinates for easy verification by parents. The format should be concise and clear, containing six core information categories: Warning header: Indicates the warning type and urgency level (the risk of fraudulent charges is "medium-urgent" and needs to be verified within 10 minutes); Student identification: Terminal ID and student name (linked to student registration information to avoid misidentification); Abnormal spending details: List all abnormal spending in chronological order, including timestamp, amount, scene tag, and location coordinates (including location accuracy); Reasons for the anomaly: Identify the key thresholds that trigger the rules (e.g., "two out-of-town transactions within 10 minutes, with a distance of 6.2 km between the two locations > 5 km"). Action recommendations: Guide parents on how to proceed (e.g., "Please contact the student immediately to confirm whether the purchase was made by the student; if it is fraudulent, the account can be frozen via the mini-program"). Warning time: The precise time (accurate to the second) at which the warning is generated.

[0099] II. Generation of Track Deviation Warning Information Warning messages should highlight the "specific location and distance of deviation from the route," accompanied by a comparative map for visual display. The format should include six core information categories (a new "Route Comparison" module has been added): Warning header: Indicates the warning type (trajectory deviation is "general emergency", verification is required within 15 minutes); Student identification: Same risk of credit card fraud; Time and route information: school dismissal time, starting and ending points of commonly used routes, and deviations from the actual route during certain times; Deviation details: average deviation distance, coordinates of the maximum deviation point, duration; Route Comparison: Describes how to view the comparison map (e.g., in the mini-program, "blue represents commonly used routes, red represents the actual trajectory, and red dots represent the points of maximum deviation"). Action Recommendation: Guide parents to contact students to confirm their safety.

[0100] III. Early Warning Information Dissemination Channels and Format Adaptation The warning information needs to be pushed to both the "Parent Terminal (WeChat Mini Program)" and the "School Management Platform (Web)" simultaneously, adapting to the format requirements of different platforms: Parental control panel (WeChat mini-program): Push method: We use a dual channel of "WeChat service notification + pop-up in mini program" to ensure that parents see it in time (clicking the service notification will directly jump to the mini program warning details page); Format adaptation: The pop-up content is simplified (retaining the warning type, student name, and key action suggestions), and the details page displays complete information and a map; Example pop-up message: "[Urgent] Your child Zhang San (STU2025001) is at risk of deviating from his travel itinerary. Click to view details and contact your child."

[0101] School Management Platform (Web Version): Push method: "Platform pop-up + SMS notification to administrator" will be used, and the SMS will be sent to the mobile phones of the class teacher and the safety director; Format adaptation: The web-based details page includes a "warning information table + trajectory map + historical warning records", and supports exporting warning reports (PDF format); Example SMS: "[School Safety Warning] Student Zhang San (STU2025001) triggered a trajectory deviation warning at 17:26. For details, please log in to the campus safety management platform. Contact number: XXX-XXXXXXX."

[0102] IV. Security and Traceability of Early Warning Information To prevent early warning information from being tampered with or leaked, security mechanisms must be added: Information encryption: The push process uses AES-128 encryption (both the parent's mini-program and the school's platform store the decryption key); Operation log: Record the "generation time, push time, parent viewing time, and feedback result" of the warning information. The log is kept for 3 months (for subsequent traceability). False alarm handling: If parents report a false alarm (such as location drift causing Δd calculation deviation), they can mark it as a "false alarm" in the mini-program. The system will add the case to the historical database and optimize subsequent rules (such as adjusting the Δd threshold to 5.5 kilometers).

[0103] The final generated anomaly warning information includes not only accurate anomaly characteristics and location information, but also actionable suggestions. At the same time, it is pushed through multiple channels to ensure timely response, forming a safety closed loop of "anomaly judgment - warning push - parent verification - school follow-up".

[0104] Another embodiment of the present invention provides a secure payment system, see [link to relevant documentation]. Figure 3 The system may include: The identification module 301 is used to identify the consumption scenario based on the real-time location data of the electronic student ID card and generate a payment account activation instruction corresponding to the consumption scenario. Transaction module 302 is used to load the matching payment account according to the payment account activation instruction and complete the transaction. After the transaction is completed, it obtains the real-time location coordinates of the electronic student ID card and packages the consumption amount, transaction time and location coordinates to generate a consumption-location associated data package with scene tags. The integration module 303 is used to synchronously retrieve the student's historical consumption records and historical trajectory data based on the consumption-location association data package with scene labels, and integrate them in the order of timestamps to form a consumption-trajectory spatiotemporal sequence dataset containing multi-scene payment information and continuous location information; The early warning module 304 is used to perform spatiotemporal correlation analysis on the consumption-trajectory spatiotemporal sequence dataset to determine whether abnormal behavior has occurred. If abnormal behavior occurs, it generates abnormal early warning information containing the type and location of the abnormal behavior.

[0105] This invention also provides a storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above method embodiments when running.

[0106] This invention also provides an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0107] Specifically, the aforementioned electronic device may further include a transmission device and an input receiving device, wherein the transmission device is connected to the aforementioned processor, and the input receiving device is connected to the aforementioned processor.

[0108] The above description, based on the embodiments shown in the figures, details the structure, features, and effects of the present invention. The above description is only a preferred embodiment of the present invention, but the present invention is not limited to the scope of implementation shown in the figures. Any changes made in accordance with the concept of the present invention, or equivalent embodiments modified to have equivalent changes, that do not exceed the spirit covered by the specification and figures, should be within the protection scope of the present invention.

Claims

1. A secure payment method, characterized in that, The method includes: The system identifies the consumption scenario based on the real-time location data of the electronic student ID and generates a corresponding payment account activation instruction. The matching payment account is loaded according to the payment account activation instruction and the transaction is completed. After the transaction is completed, the real-time location coordinates of the electronic student ID are obtained, and the consumption amount, transaction time and location coordinates are packaged to generate a consumption-location associated data package with scene tags. Based on consumption-location associated data packets with scene labels, the student's historical consumption records and historical trajectory data are retrieved synchronously and integrated in the order of timestamps to form a consumption-trajectory spatiotemporal sequence dataset containing multi-scene payment information and continuous location information. Perform spatiotemporal correlation analysis on the consumption-trajectory spatiotemporal sequence dataset to determine whether abnormal behavior has occurred. If abnormal behavior has occurred, generate abnormal warning information containing the type of abnormal behavior and the location of the abnormal behavior.

2. The method according to claim 1, characterized in that, The step of identifying the consumption scenario based on the real-time location data of the electronic student ID and generating a corresponding payment account activation instruction includes: The system acquires multi-source positioning data from electronic student ID cards, collects real-time location information through the terminal's built-in positioning module, and filters out positioning drift data to obtain pre-processed real-time positioning coordinates. Construct a scene electronic fence system, and preset the geographical boundaries of three types of consumption scenes in the system: campus scene, public transportation scene, and off-campus scene, and obtain scene fence parameters; The system assists in detecting signals from surrounding devices. The electronic student ID card scans the surrounding area and includes at least RFID and / or NFC signal strength. If a unique NFC signal specific to the bus terminal is detected, it is marked as a bus scene candidate. If no signal is detected, the scene fence is matched with the real-time positioning coordinates to obtain the scene candidate result. The system determines the consumption scenario and generates instructions, comparing the scenario candidate results with the scenario fence parameters: if the location coordinates are within the campus fence, it is determined to be an on-campus scenario, triggering the campus payment account activation instruction; if a bus NFC signal is detected, it is determined to be a bus scenario, triggering the bus payment account activation instruction; otherwise, it is determined to be an off-campus scenario, triggering the social payment account activation instruction, thus obtaining the payment account activation instruction for the corresponding consumption scenario.

3. The method according to claim 2, characterized in that, The process involves loading a matching payment account according to the payment account activation instruction and completing the transaction. After the transaction is completed, the real-time location coordinates of the electronic student ID are obtained. The consumption amount, transaction time, and location coordinates are packaged to generate a consumption-location associated data package with scene tags, including: Parse the payment account activation instruction, extract the scenario type and target account identifier from the instruction, decrypt the target account's storage key, and obtain the account decryption key; Load the matching payment account, unlock the corresponding payment account's transaction permissions using the account decryption key, load the account information into the terminal's NFC module, and simultaneously close payment account channels in other scenarios to obtain the loaded target payment account; The electronic student ID establishes an encrypted communication link with the consumer terminal to execute the transaction process, transmits account information and transaction amount, and receives a transaction success receipt from the terminal after the deduction is completed, thus obtaining a transaction success certificate. Generate a consumption-location associated data packet. Immediately after a successful transaction, the location module is triggered to obtain the current precise location coordinates. The consumption amount, transaction time, and location coordinates are packaged according to a preset format and encrypted using MQTT or TCP protocol to generate a consumption-location associated data packet with a scene tag.

4. The method according to claim 3, characterized in that, The consumption-location associated data package with scene labels synchronously retrieves the student's historical consumption records and historical trajectory data, and integrates them in timestamp order to form a consumption-trajectory spatiotemporal sequence dataset containing multi-scene payment information and continuous location information, including: Extract key information from the current data packet. Parse the core fields from the consumption-location associated data packet with scene tags: scene tag, transaction timestamp, consumption amount, location coordinates, and terminal ID. Categorize and organize the data according to field type to obtain structured current data. Retrieve historical data, associate the student's historical database with the terminal ID, retrieve the historical consumption records and historical trajectory data of the past 30 days respectively, filter out invalid data, and obtain the historical consumption dataset and historical trajectory dataset; Data timestamp alignment is performed by sorting historical consumption datasets, historical trajectory datasets, and current structured data in chronological order based on transaction timestamps. Missing time points in the trajectory data are supplemented by linear interpolation to obtain a time-aligned integrated dataset. A consumption-trajectory spatiotemporal sequence dataset is constructed. The time-aligned integrated data is reorganized according to the dimensions of timestamp-scene-consumption amount-location coordinates, and multi-scene payment switching nodes are marked to form a consumption-trajectory spatiotemporal sequence dataset containing multi-scene payment information and continuous location information.

5. The method according to claim 4, characterized in that, The process involves performing spatiotemporal correlation analysis on the consumption-trajectory spatiotemporal sequence dataset to determine whether abnormal behavior has occurred. If abnormal behavior occurs, an anomaly warning message is generated, containing the type and location of the abnormal behavior, including: Spatiotemporal correlation features are extracted from the consumption-trajectory spatiotemporal sequence dataset. Two types of core features are extracted: consumption correlation features and trajectory correlation features. The features are then standardized to obtain a standardized spatiotemporal feature set. Perform spatiotemporal correlation analysis and compare the standardized spatiotemporal feature set with the anomaly judgment rule set: if the same student makes two or more out-of-town transactions within 10 minutes and the distance between the two locations exceeds 5 kilometers, a fraud risk judgment is triggered; if the trajectory during the school dismissal period deviates from the usual school dismissal route by more than 1 kilometer, a trajectory deviation judgment is triggered; if none of the rules are met, it is judged as normal behavior, and an anomaly judgment result is obtained. Generate abnormal warning information. If the abnormality judgment result is the risk of fraudulent use, then mark the abnormal behavior type as the risk of fraudulent use and associate the location coordinates of the abnormal behavior; if it is a trajectory deviation, then mark the type as trajectory deviation and attach a comparison map of the deviation route; integrate the abnormality type, abnormal location and timestamp in a fixed format and push them to the parent terminal and the school management platform to generate abnormal warning information containing the abnormal behavior type and abnormal location.

6. A secure payment system, characterized in that, The system includes: The identification module is used to identify the consumption scenario based on the real-time location data of the electronic student ID and generate a corresponding payment account activation instruction. The transaction module is used to load the matching payment account according to the payment account activation instruction and complete the transaction. After the transaction is completed, the real-time location coordinates of the electronic student ID are obtained, and the consumption amount, transaction time and location coordinates are packaged to generate a consumption-location associated data package with scene tags. The integration module is used to synchronously retrieve the student's historical consumption records and historical trajectory data based on consumption-location associated data packets with scene labels, and integrate them in the order of timestamps to form a consumption-trajectory spatiotemporal sequence dataset containing multi-scene payment information and continuous location information; The early warning module is used to perform spatiotemporal correlation analysis on the consumption-trajectory spatiotemporal sequence dataset to determine whether abnormal behavior has occurred. If abnormal behavior occurs, it generates abnormal early warning information containing the type and location of the abnormal behavior.

7. The system according to claim 6, characterized in that, The identification module is specifically used for: The system acquires multi-source positioning data from electronic student ID cards, collects real-time location information through the terminal's built-in positioning module, and filters out positioning drift data to obtain pre-processed real-time positioning coordinates. Construct a scene electronic fence system, and preset the geographical boundaries of three types of consumption scenes in the system: campus scene, public transportation scene, and off-campus scene, and obtain scene fence parameters; The system assists in detecting signals from surrounding devices. The electronic student ID card scans devices that contain at least RFID and / or NFC. If a unique NFC signal specific to the bus terminal is detected, it is marked as a bus scenario candidate. If no signal is detected, the system combines real-time positioning coordinates to match the scene fence and obtain the scene candidate result. The system determines the consumption scenario and generates instructions, comparing the scenario candidate results with the scenario fence parameters: if the location coordinates are within the campus fence, it is determined to be an on-campus scenario, triggering the campus payment account activation instruction; if a bus NFC signal is detected, it is determined to be a bus scenario, triggering the bus payment account activation instruction; otherwise, it is determined to be an off-campus scenario, triggering the social payment account activation instruction, thus obtaining the payment account activation instruction for the corresponding consumption scenario.

8. The system according to claim 7, characterized in that, The transaction module is specifically used for: Parse the payment account activation instruction, extract the scenario type and target account identifier from the instruction, decrypt the target account's storage key, and obtain the account decryption key; Load the matching payment account, unlock the corresponding payment account's transaction permissions using the account decryption key, load the account information into the terminal's NFC module, and simultaneously close payment account channels in other scenarios to obtain the loaded target payment account; The electronic student ID establishes an encrypted communication link with the consumer terminal to execute the transaction process, transmits account information and transaction amount, and receives a transaction success receipt from the terminal after the deduction is completed, thus obtaining a transaction success certificate. Generate a consumption-location associated data packet. Immediately after a successful transaction, the location module is triggered to obtain the current precise location coordinates. The consumption amount, transaction time, and location coordinates are packaged according to a preset format and encrypted using MQTT or TCP protocol to generate a consumption-location associated data packet with a scene tag.

9. A storage medium, characterized in that, The storage medium stores a computer program, wherein the computer program is configured to execute the method of any one of claims 1-5 when it is run.

10. An electronic device comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to run the computer program to perform the method of any one of claims 1-5.

Images