A hitchhiking matching method and device

Abstract

This application provides a ridesharing matching method and apparatus. The method includes: acquiring historical travel data of a target passenger; determining whether the target passenger is a periodic commuter based on the historical travel data; if the target passenger is determined to be a periodic commuter, extracting the time, location, and frequency patterns of the target passenger's periodic travel from the historical travel data; determining the stability of the target passenger's periodic commuting behavior based on the time, location, and frequency patterns of the target passenger's periodic travel; if the stability exceeds a preset threshold, determining the comprehensive matching degree between the target passenger and the current ridesharing driver through path overlap, time overlap, and frequency matching degree; if the comprehensive matching degree exceeds a preset matching threshold, establishing a long-term matching relationship between the target passenger and the current ridesharing driver. This solution effectively improves the efficiency of ridesharing matching.

Description

Technical Field

[0001] This application belongs to the field of intelligent transportation technology, and in particular relates to a ride-sharing matching method and device. Background Technology

[0002] With the continuous development of the sharing economy, ride-sharing has become a widely used green and economical mode of transportation. Currently, ride-sharing platforms mainly adopt the "single order placement - single matching - single transaction" model, that is, passengers need to place an order before each trip, and the platform will match them in real time based on their current travel needs and the driver's route.

[0003] However, the existing ride-sharing matching model has the following technical problems when facing commuting scenarios: 1) Low matching efficiency: Matching calculations need to be performed again for each trip, which will inevitably waste computing resources and the matching success rate is unstable.

[0004] 2) Poor user experience: Commuters (including passengers and drivers) need to repeat the "place an order - accept an order - match - confirm" process every day, which is cumbersome and time-consuming. Especially during morning and evening rush hours, users often need to place orders well in advance, otherwise it is difficult to match suitable vehicles or passengers.

[0005] There is currently no effective solution to the technical problems of low matching efficiency and poor user experience in the existing ride-sharing matching model. Summary of the Invention

[0006] The purpose of this application is to provide a ride-sharing matching method and device that can improve the matching efficiency of ride-sharing.

[0007] This application provides a ride-sharing matching method and apparatus, which are implemented as follows: A ride-sharing matching method includes: Obtain the target passengers' historical travel data; Based on the historical travel data, determine whether the target passenger is a periodic commuter. If the target passenger is determined to be a periodic commuter, the time pattern, location pattern, and frequency pattern of the target passenger's periodic travel are extracted from the historical travel data; Based on the time, location, and frequency patterns of the target passenger's periodic travel, the stability of the target passenger's periodic commuting behavior is determined; When the stability is greater than the preset threshold, the overall matching degree between the target passenger and the current ridesharing driver is determined by the path overlap, time overlap, and frequency matching degree. If the overall matching degree exceeds the preset matching threshold, a long-term matching relationship is established between the target passenger and the current rideshare driver.

[0008] In one implementation, extracting the time, location, and frequency patterns of the target passenger's periodic travel from the historical travel data includes: From the historical travel data, the fixed travel time windows of the target passengers are identified, and the standard deviation of the travel time is determined to determine the fluctuation coefficient of the target passengers' travel time pattern. From the historical travel data, cluster analysis is performed on the origin and destination coordinates of the target passengers to determine their common origin and destination, and the location deviation range of the origin and destination is calculated to determine the fluctuation coefficient of the target passengers' travel locations. From the historical travel data, the travel frequency of the target passenger is determined in order to identify the fluctuation coefficient of the target passenger's travel frequency; Accordingly, based on the time, location, and frequency patterns of the target passenger's periodic travel, the stability of the target passenger's periodic commuting behavior is determined, including: The stability of the target passenger's periodic commuting behavior is determined by comprehensively considering the fluctuation coefficients of the target passenger's travel time pattern, travel location, and travel frequency.

[0009] In one implementation, the overall matching degree between the target passenger and the current rideshare driver is determined by route overlap, time overlap, and frequency matching degree, including: Obtain path weight, time weight, and frequency weight; The overall matching degree between the target passenger and the current rideshare driver is obtained by weighting and accumulating the path weight, time weight, frequency weight, path overlap, time overlap, and frequency matching degree.

[0010] In one implementation, obtaining the time overlap includes: Based on the historical data of current ridesharing drivers, extract the departure time data of ridesharing drivers; Based on the departure time data of ride-sharing drivers, a discrete probability distribution table of ride-sharing drivers is established, which includes: time point, number of departures, and departure probability. Extract the departure time data of the target passengers based on their historical travel data; Based on the departure time data of the target passengers, establish a discrete probability distribution table for the target passengers; Based on the discrete probability distribution table of ride-sharing drivers and the discrete probability distribution table of target passengers, calculate the overall coverage of ride-sharing drivers' needs for target passengers. Based on the discrete probability distribution table of ride-sharing drivers and the discrete probability distribution table of target passengers, calculate the weighted matching probability that the ride-sharing driver and the target passenger appear at the same matchable time point. The time overlap is calculated based on the overall coverage of the ride-sharing driver's needs for the target passenger and the weighted matching probability of the ride-sharing driver and the target passenger appearing at the same matchable time point.

[0011] In one implementation, the time overlap is calculated based on the overall coverage of the ride-sharing driver's demand for the target passenger and the weighted matching probability that the ride-sharing driver and the target passenger appear at the same matchable time point, including: The time overlap is calculated as follows: T = α × Coverage × 100 + β × P_match × 100; Where T is the time overlap, Coverage is the overall coverage of the ride-sharing driver's needs for the target passenger, P_match is the weighted matching probability that the ride-sharing driver and the target passenger appear at the same matchable time point, and α and β are weight coefficients, α + β = 1.

[0012] In one implementation, based on the discrete probability distribution table of ride-sharing drivers and the discrete probability distribution table of target passengers, the weighted matching probability of the ride-sharing driver and the target passenger appearing simultaneously at a matchable time point is calculated, including: The weighted matching probability of a rideshare driver and a target passenger appearing at the same matchable time point is calculated using the following formula: P_match = ΣΣ[P_arrive(t_a) × P_passenger(t_p) × I(|t_a-t_p| ≤ Δt_tolerance)]; Where P_match represents the weighted matching probability that the rideshare driver and the target passenger appear at the same matchable time point, P_arrive(t_a) represents the probability that the rideshare driver arrives at time point t_a, P_passenger(t_p) represents the probability that the target passenger gets on the ride at time point t_p, Δt_tolerance is the tolerance time difference, and I(condition) is the indicator function.

[0013] In one implementation, based on the discrete probability distribution table of ride-sharing drivers and the discrete probability distribution table of target passengers, the overall coverage of ride-sharing drivers' needs for target passengers is calculated, including: The overall coverage of ride-sharing drivers' needs to the target passengers' demands is calculated using the following formula: Coverage = Σ [P_passenger(t_p) × ΣP_arrive(t_a) × I(|t_a-t_p| ≤Δt_tolerance)]; Where Coverage represents the overall coverage of the ride-sharing driver's needs for the target passenger, P_passenger(t_p) represents the probability that the target passenger gets on the ride at time t_p, P_arrive(t_a) represents the probability that the ride-sharing driver arrives at time t_a, and I(condition) is the indicator function.

[0014] In one implementation, determining whether the target passenger is a periodic commuter based on the historical travel data includes: The time stability score of the target passenger is calculated using the following formula: ; in, The target passenger's time stability score is determined. The standard deviation of travel time within the preset duration. The preset maximum threshold; The location stability score for the target passenger is calculated using the following formula: ; in, Score the location stability of the target passengers. The number of trips within the core cluster. This represents the total number of trips. The frequency stability score of the target passenger is calculated using the following formula: ; in, The target passenger frequency stability score is given. The goodness of fit between the actual frequency and the Poisson distribution. This is the adjustment coefficient; The behavioral consistency score of the target passenger is calculated using the following formula: ; in, Score the consistency of the target passenger's behavior. Let n be the probability of transitioning between the travel status on day i and day i+1, and n be the total number of days. The overall score of the target passenger's periodic commuting behavior is calculated using the following formula: ; in, The score represents the overall score of the target passenger's periodic commuting behavior, with a, b, c, and d being weighting coefficients.

[0015] In one implementation, determining whether the target passenger is a periodic commuter based on the historical travel data includes: Retrieve a pre-established commuting behavior trend prediction model; The historical travel data of the target passenger within a preset time period is used as input data and input into the input layer of the commuting behavior trend prediction model: The commuting behavior trend prediction model outputs the commuting probability of the target passenger in future periods through its output layer. The commuting behavior trend prediction model includes a hidden layer and an attention mechanism layer. The hidden layer consists of a first layer with 64 neurons, a second layer with 32 neurons, and a third layer with 16 neurons, with the activation function being tanh. The attention mechanism layer introduces temporal attention weights. The output layer consists of a fully connected layer and a sigmoid activation function.

[0016] A ride-sharing matching device includes: The acquisition module is used to acquire the historical travel data of the target passenger; The first determining module is used to determine whether the target passenger is a periodic commuter based on the historical travel data; The extraction module is used to extract the time pattern, location pattern, and frequency pattern of the target passenger's periodic travel from the historical travel data when it is determined that the target passenger is a periodic commuter. The second determining module is used to determine the stability of the target passenger's periodic commuting behavior based on the time pattern, location pattern, and frequency pattern of the target passenger's periodic travel. The third determination module is used to determine the overall matching degree between the target passenger and the current ridesharing driver by means of path overlap, time overlap, and frequency matching degree when the stability is greater than a preset threshold. A module is established to create a long-term matching relationship between the target passenger and the current rideshare driver when the overall matching degree exceeds a preset matching threshold.

[0017] A terminal device includes a processor and a memory for storing processor-executable instructions, wherein the processor implements the steps of the method described above when executing the instructions.

[0018] A computer-readable storage medium having a computer program / instructions stored thereon, which, when executed by a processor, implement the steps of the above-described method.

[0019] This application provides a ridesharing matching method that determines whether a target passenger is a periodic commuter based on their historical travel data. If the target passenger is determined to be a periodic commuter, the method extracts the time, location, and frequency patterns of their periodic travel from the historical travel data. Based on these patterns, the method determines the stability of the target passenger's periodic commuting behavior. If the stability exceeds a preset threshold, the method determines the overall matching degree between the target passenger and the current ridesharing driver through path overlap, time overlap, and frequency matching. If the overall matching degree exceeds a preset matching threshold, a long-term matching relationship is established between the target passenger and the current ridesharing driver. In other words, the method proactively identifies the matching degree between the target passenger and the ridesharing driver, and if the matching degree meets the requirements, it proactively establishes a long-term matching relationship between the passenger and the driver. This solves the technical problem of low efficiency in existing ridesharing matching processes and effectively improves the efficiency of ridesharing matching. Attached Figure Description

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

[0021] Figure 1 This is a flowchart of one embodiment of the ride-sharing matching method provided in this application; Figure 2 This is a schematic diagram of the architecture of the ride-sharing fixed-ride matching system based on periodic commuting behavior provided in this application; Figure 3 This is a flowchart illustrating the calculation method for the long-term matching degree between vehicle owners and passengers provided in this application; Figure 4 This is a hardware structure block diagram of an electronic device for a ride-sharing matching method provided in this application; Figure 5 This is a schematic diagram of the module structure of one embodiment of the ride-sharing matching device provided in this application. Detailed Implementation

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

[0023] It should be noted that the information and data related to users involved in the embodiments of this specification are all information and data authorized by the user or fully authorized by the relevant parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of the relevant data all comply with relevant laws, regulations, and standards, and necessary confidentiality measures have been taken. They do not violate public order and good morals, and corresponding operation entry points are provided for users or relevant parties to choose to authorize or refuse.

[0024] It should also be noted that in the embodiments of this specification, certain software, components, models and other existing solutions in the industry may be mentioned. These should be regarded as exemplary and are only intended to illustrate the feasibility of implementing the technical solution of this application. However, it does not mean that the applicant has used or necessarily used the solution.

[0025] Figure 1 This is a flowchart of one embodiment of the ride-sharing matching method provided in this application. Although this application provides method operation steps or device structures as shown in the following embodiments or figures, more or fewer operation steps or module units may be included in the method or device based on conventional or non-inventive effort. In steps or structures where there is no logically necessary causal relationship, the execution order of these steps or the module structure of the device is not limited to the execution order or module structure described in the embodiments and figures of this application. When the method or module structure is applied in actual devices or terminal products, it can be executed sequentially or in parallel according to the method or module structure shown in the embodiments or figures (e.g., in a parallel processor or multi-threaded processing environment, or even a distributed processing environment).

[0026] Specifically, such as Figure 1 As shown, the above-mentioned ride-sharing matching method may include the following steps: Step 101: Obtain the target passenger's historical travel data; Step 102: Determine whether the target passenger is a periodic commuter based on the historical travel data; Step 103: If the target passenger is determined to be a periodic commuter, extract the time pattern, location pattern, and frequency pattern of the target passenger's periodic travel from the historical travel data; Step 104: Determine the stability of the target passenger's periodic commuting behavior based on the time, location, and frequency patterns of the target passenger's periodic travel. Specifically, extracting the time, location, and frequency patterns of the target passenger's periodic travel from the historical travel data may include: S1: Identify the fixed travel time window of the target passenger from the historical travel data, and determine the standard deviation of the travel time to determine the fluctuation coefficient of the target passenger's travel time pattern; S2: From the historical travel data, perform cluster analysis on the origin and destination coordinates of the target passenger to determine the target passenger's frequently used origin and destination, and calculate the location deviation range of the origin and destination to determine the fluctuation coefficient of the target passenger's travel location; S3: Determine the travel frequency of the target passenger from the historical travel data to identify the fluctuation coefficient of the target passenger's travel frequency; Accordingly, determining the stability of the target passenger's periodic commuting behavior based on the time, location, and frequency patterns of the target passenger's periodic travel can include: comprehensively determining the stability of the target passenger's periodic commuting behavior based on the fluctuation coefficients of the target passenger's travel time patterns, travel location fluctuation coefficients, and travel frequency fluctuation coefficients.

[0027] Step 105: When the stability is greater than the preset threshold, determine the comprehensive matching degree between the target passenger and the current ridesharing driver by using path overlap, time overlap, and frequency matching degree. In implementation, path weight, time weight, and frequency weight can be obtained; by weighting and accumulating the path weight, time weight, frequency weight, path overlap, time overlap, and frequency matching degree, the overall matching degree between the target passenger and the current ridesharing driver can be obtained.

[0028] Step 106: If the overall matching degree exceeds the preset matching threshold, establish a long-term matching relationship between the target passenger and the current rideshare driver.

[0029] Specifically, the aforementioned time overlap can be obtained as follows: S1: Extract the departure time data of current ridesharing drivers based on their historical data; S2: Based on the departure time data of ride-sharing drivers, establish a discrete probability distribution table for ride-sharing drivers, which includes: time point, number of departures, and departure probability. S3: Extract the departure time data of the target passengers based on their historical travel data; S4: Based on the departure time data of the target passengers, establish a discrete probability distribution table of the target passengers; S5: Based on the discrete probability distribution table of ride-sharing drivers and the discrete probability distribution table of target passengers, calculate the overall coverage of ride-sharing drivers' needs for target passengers. S6: Based on the discrete probability distribution table of the ride-sharing driver and the discrete probability distribution table of the target passenger, calculate the weighted matching probability that the ride-sharing driver and the target passenger appear at the same matching time point. S7: The time overlap is calculated based on the overall coverage of the ride-sharing driver's needs for the target passenger and the weighted matching probability of the ride-sharing driver and the target passenger appearing at the same matchable time point.

[0030] Specifically, the time overlap can be calculated as follows: T = α × Coverage × 100 + β × P_match × 100; Where T is the time overlap, Coverage is the overall coverage of the ride-sharing driver's needs for the target passenger, P_match is the weighted matching probability that the ride-sharing driver and the target passenger appear at the same matchable time point, and α and β are weight coefficients, α + β = 1.

[0031] The weighted matching probability of a rideshare driver and a target passenger appearing at the same matchable time point can be calculated using the following formula: P_match = ΣΣ[P_arrive(t_a) × P_passenger(t_p) × I(|t_a-t_p| ≤ Δt_tolerance)]; Where P_match represents the weighted matching probability that the rideshare driver and the target passenger appear at the same matchable time point, P_arrive(t_a) represents the probability that the rideshare driver arrives at time point t_a, P_passenger(t_p) represents the probability that the target passenger gets on the ride at time point t_p, Δt_tolerance is the tolerance time difference, and I(condition) is the indicator function.

[0032] The overall coverage of ridesharing drivers' needs to the target passengers can be calculated using the following formula: Coverage = Σ [P_passenger(t_p) × ΣP_arrive(t_a) × I(|t_a-t_p| ≤Δt_tolerance)]; Where Coverage represents the overall coverage of the ride-sharing driver's needs for the target passenger, P_passenger(t_p) represents the probability that the target passenger gets on the ride at time t_p, P_arrive(t_a) represents the probability that the ride-sharing driver arrives at time t_a, and I(condition) is the indicator function.

[0033] In implementation, determining whether the target passenger is a periodic commuter based on the historical travel data may include: S1: Calculate the target passenger's time stability score using the following formula: ; in, The target passenger's time stability score is determined. The standard deviation of travel time within the preset duration. The preset maximum threshold; S2: Calculate the target passenger's location stability score using the following formula: ; in, Score the location stability of the target passengers. The number of trips within the core cluster. This represents the total number of trips. S3: Calculate the frequency stability score of the target passenger using the following formula: ; in, The target passenger frequency stability score is given. The goodness of fit between the actual frequency and the Poisson distribution. This is the adjustment coefficient; S4: Calculate the target passenger's behavioral consistency score using the following formula: ; in, Score the consistency of the target passenger's behavior. Let n be the probability of transitioning between the travel status on day i and day i+1, and n be the total number of days. S5: Calculate the overall score of the target passenger's periodic commuting behavior according to the following formula: ; in, The score represents the overall score of the target passenger's periodic commuting behavior, with a, b, c, and d being weighting coefficients.

[0034] That is, a weighted scoring model is constructed by combining four dimensions: time stability, location stability, frequency stability, and behavioral consistency, to replace the single percentage rule.

[0035] To determine whether the target passenger is a periodic commuter based on historical travel data, a commuting behavior trend prediction model is provided in this example. Specifically, a pre-established commuting behavior trend prediction model is retrieved; historical travel data of the target passenger within a preset time period is used as input data and input to the input layer of the commuting behavior trend prediction model; the output layer of the commuting behavior trend prediction model outputs the commuting probability of the target passenger in future periods. The commuting behavior trend prediction model includes a hidden layer and an attention mechanism layer. The hidden layer includes a first layer with 64 neurons, a second layer with 32 neurons, and a third layer with 16 neurons, using the tanh activation function. The attention mechanism layer introduces temporal attention weights. The output layer includes a fully connected layer and a sigmoid activation function.

[0036] The above method will be described below with reference to a specific embodiment. However, it should be noted that this specific embodiment is only for better illustration of this application and does not constitute an improper limitation of this application.

[0037] Considering the highly periodic and regular travel needs of daily commuters (fixed times, fixed origins and destinations, fixed frequency), identifying and utilizing these periodic patterns can effectively improve the matching success rate. Specifically, by deeply mining users' historical travel data, automatically identifying their periodic commuting behavior patterns, establishing long-term, fixed ride services for users with a high degree of compatibility, and providing a comprehensive fulfillment guarantee mechanism, matching efficiency can be improved, user experience optimized, and platform operating costs reduced.

[0038] Based on this, this example provides a ride-sharing system based on periodic commuting behavior, which can be used as follows: Figure 2 As shown, it includes the following modules: user periodic demand collection module, behavior recognition module, and matching calculation module. The following sections provide a detailed explanation of each model: A. User Periodic Request Collection Module: This module supports a data collection method that combines active input with intelligent recognition: Manual entry function: Users can actively enter periodic travel plans, including: fixed travel time (such as "7:30 every Monday to Friday", "9:00 on the 1st and 15th of every month"), fixed origin and destination (such as "from city A to city B", "from city C to city D"), and travel cycle type (weekday commute, specific dates every week, fixed dates every month, etc.). Automatic recognition function: The system automatically collects and analyzes users' historical travel data, including: travel time (year, month, day, hour, minute, second), origin coordinates (latitude and longitude), destination coordinates (latitude and longitude), travel frequency, and order completion status; Intelligent tagging mechanism: For example, when a user's travel history over the past 30 days shows that repeated routes (origin-end deviation ≤ 500 meters) account for ≥ 70%, the system automatically tags the user as a "periodic commuter" and pushes a "establish a fixed ride relationship" prompt to reduce manual data entry costs.

[0039] B. Behavior Recognition Module: This module is used to identify users' periodic commuting behavior patterns from historical travel data, including: Time pattern extraction: Analyze the distribution of users' travel time on weekdays / weekends / holidays; for example: use clustering algorithms to identify fixed travel time windows (e.g., 7:30-8:00 AM and 6:00-6:30 PM, Monday to Friday); calculate the standard deviation of travel time to assess the stability of time patterns.

[0040] Location pattern extraction: DBSCAN cluster analysis is performed on the origin and destination coordinates to identify the user's frequently used origin and destination; frequently occurring locations are marked (e.g., home address, company address); the location deviation range is calculated to assess location stability.

[0041] Frequency pattern extraction: Statistical analysis of user travel frequency (e.g., 5 times per week, 20 times per month); determination of whether a user is a high-frequency commuter (e.g., frequency ≥ 3 times per week); identification of travel cycle patterns (e.g., only weekdays, including weekends, specific dates, etc.).

[0042] Regularity stability assessment: Calculate the fluctuation coefficients of the above time, location, and frequency; comprehensively evaluate the stability score of commuting behavior (0-100 points); for example, users with a stability score ≥70 points are given priority in establishing long-term matching relationships.

[0043] C. Long-term matching engine (matching calculation module): Used to calculate the long-term match between car owners and passengers, for example, it can be like... Figure 3 As shown, the following indicators are used for evaluation: path overlap, time fit, and frequency matching.

[0044] Route overlap: Calculates the degree of overlap between the driver's frequently used driving routes and the passenger's origin and destination, including: origin and destination distance deviation (the deviation distance between the passenger's pick-up and drop-off points and the driver's route), and route overlap rate; Matching threshold: If the route overlap is ≥80%, it is considered a high match.

[0045] Time fit: Compare the travel time windows of car owners and passengers, and calculate the time overlap and time deviation; Matching threshold: If the time deviation is ≤20 minutes, it is considered a high match.

[0046] Specifically, calculating the time overlap between the driver's arrival time and the passenger's boarding time based on the probability distribution of users' historical travel data can include the following steps: Step 1: Extract the vehicle owner's departure time window and probability distribution: Historical data collection allows you to gather a vehicle owner's travel records for the past 30 working days (or calendar days, depending on the period type) and extract departure time data. Data example: {Date: 2024-01-08, Departure Time: 7:28} {Date: 2024-01-09, Departure Time: 7:32} {Date: 2024-01-10, Departure Time: 7:25} ... There are a total of N records (N≥20).

[0047] Data cleaning can remove abnormal data such as holidays and days off, classify data by weekdays / weekends, and retain data during stable commuting periods.

[0048] Step 2: Extract the adaptive time window: A two-stage algorithm can be used to extract the car owner's frequently used departure time windows: 1) The coarse positioning stage may include: Divide the 24-hour period into fixed windows (window length 10 minutes, step size 10 minutes), count the travel frequency within each window, and identify the continuous interval with the highest travel frequency as candidate regions.

[0049] Specifically, this may include: S1: Define a fixed set of time windows: W_i = [t_0+i×10 minutes, t_0+(i+1)×10 minutes], where i=0,1,2,...,143 (a total of 144 windows covering 24 hours); S2: For each window W_i, count the number of historical departure times that fall into that window (Count(W_i)); S3: Calculate the frequency of each window: Freq(W_i) = Count(W_i) / N; S4: Identify high-frequency regions: Find a continuous window where Freq(W_i) ≥ the threshold (10% recommended); S5: Merge consecutive high-frequency windows to obtain candidate regions.

[0050] Example:

[0051] Candidate region: [7:10, 7:50] (merging consecutive high-frequency windows).

[0052] 2) Fine positioning stage: Within the candidate area, a sliding window technique (window length L = 15-20 minutes, step size S = 1-5 minutes) is used for fine scanning to find the optimal window that covers the most travel records and has a cumulative probability of 80%-90%.

[0053] Specifically, this may include: Within the candidate region [T_candidate_start, T_candidate_end], define a sliding window: SW_j = [T_candidate_start + j × S, T_candidate_start + j × S + L]; For each sliding window SW_j: count the number of historical records falling into that window: Count(SW_j), and calculate the cumulative probability: P_cumulative(SW_j) = Count(SW_j) / N The window that meets the following conditions is selected as the optimal window: P_cumulative(SW_j) ≥ 80% (sufficient coverage), Count(SW_j) is the largest (covers the most records), and the window length is as short as possible (to improve accuracy).

[0054] Example: Candidate region: [7:10, 7:50] Sliding window length: L = 16 minutes Step length: S = 2 minutes.

[0055] Scan results:

[0056] 3) Output results: Vehicle owner's departure time window: [T_d_start, T_d_end] Example: [7:22, 7:38], window length 16 minutes.

[0057] Step 3: Establish the probability distribution of departure time: Within a defined time window, a discrete probability distribution is established.

[0058] Input data: Vehicle owner's travel history: N records (after cleaning, N≥20); Confirmed departure time window: [T_d_start, T_d_end]; The probability distribution of departure time can be established by following these steps: 1) Time point division: Divide the time window into discrete time points with a fixed granularity: Time granularity: Δt = 5 minutes (can be adjusted to 3-10 minutes depending on the actual scenario); Number of time points: m = (T_d_end - T_d_start) / Δt + 1 The set of time points is: {t_1, t_2, ..., t_m}, where t_i = T_d_start + (i-1)×Δt; Example: Window [7:22, 7:38], granularity 5 minutes.

[0059] For ease of calculation, round down to 7:20 and round up to 7:45.

[0060] Set of time points: {7:20, 7:25, 7:30, 7:35, 7:40, 7:45}, Number of time points: m=6.

[0061] 2) Mapping historical records to specific points in time: Map the actual departure time of each historical travel record to the most recent point in time: For the departure time t_actual in the historical records; The mapping rule is: t_mapped = argmin_{t_i∈{t_1,...,t_m}} |t_actual - t_i|.

[0062] That is, select the time point with the smallest difference from the actual time.

[0063] Example:

[0064] 3) Count the number of trips at each time point: Create a counting table to count the number of historical records mapped to each time point: Count(t_i) = |{t_actual | t_mapped = t_i}|.

[0065] Example (assuming 30 historical records):

[0066] Total number of records within the window: N_window = 1 + 3 + 9 + 8 + 4 + 2 = 27 records. (The other 3 records fall outside the window and are not counted.)

[0067] 4) Calculate the discrete probability distribution: For each time point t_i within the window, calculate its travel probability: The probability of travel can be calculated using the following formula: P_d(t_i) = Count(t_i) / N_window.

[0068] Where P_d(t_i) is the probability that the car owner departs at time point t_i, Count(t_i) is the number of historical records mapped to time point t_i, and N_window is the total number of valid records within the window.

[0069] Example calculation: N_window = 27 entries

[0070] 5) Normalization verification: Verify the validity of the probability distribution: The constraint is that the sum of the probabilities of departure at each time point is 1. If the sum is approximately equal to 1, then the condition is considered valid.

[0071] Example verification: 3.7% + 11.1% + 33.3% + 29.6% + 14.8% + 7.4% = 99.9% ≈ 100%, the verification is valid. Due to rounding, there may be an error of ±0.1%, which is acceptable.

[0072] 6) Output results: The discrete probability distribution table is shown in Table 1 below: Table 1

[0073] Passenger boarding time window and probability distribution: Based on historical passenger data or user settings, establish the boarding time window and probability distribution. Method 1: Based on historical data (users with existing travel records), extract the window and probability distribution using the same method as for car owners: Collect passenger historical departure time data (N≥20 records); An adaptive time window extraction algorithm is used to obtain the passenger's commonly used boarding time window [T_p_start, T_p_end]; Establish a discrete probability distribution P_p(t_i).

[0074] Method 2: Based on user settings (new users or no historical data), for new users without historical travel records, a uniform distribution model is established based on their set time window.

[0075] Input data: User-defined desired boarding time window: [T_p_start, T_p_end]; Calculation process: Time point division: Divide the time window into discrete time points with a fixed granularity. Time granularity Δt = 5 minutes (consistent with the car owner); Number of time points: n = (T_p_end - T_p_start) / Δt + 1; The set of time points is: {t_1, t_2, ..., t_n}, where t_i = T_p_start + (i-1)×Δt; Example: User settings window: [7:30, 7:50], window length: 20 minutes, time granularity: 5 minutes; Number of time points: n = 20 / 5 + 1 = 5, Time point set: {7:30, 7:35, 7:40, 7:45, 7:50}.

[0076] 2) Uniform distribution assumption: Assume that users have an equal probability of boarding the bus at every point in the time window (no preference): formula: P_p(t_i) = 1 / n, for all i = 1,2,...,n; Where P_p(t_i) is the probability that a passenger boards the bus at time point t_i, and n is the number of time points within the time window.

[0077] Example calculation: Number of time points: n = 5, probability of each time point: P_p(t_i) = 1 / 5 = 0.2 = 20%.

[0078] 3) Generate the probability distribution table shown in Table 2 below: Table 2

[0079] 4) Normalization verification: The constraint is that the sum of the probabilities of boarding the bus is 1.

[0080] Example verification: 20% × 5 = 100%, verification passed.

[0081] 5) Handling special cases: Case A: The window length is not an integer multiple of the time granularity.

[0082] Example: Window [7:30, 7:48], length 18 minutes, granularity 5 minutes; Solution: Round up to the nearest whole number and adjust the endpoint to 7:50; Time points: {7:30, 7:35, 7:40, 7:45, 7:50}; The probability at each time point is 1 / 5 = 20%.

[0083] Scenario B: The window is very narrow (< 5 minutes).

[0084] Example: Window [7:30, 7:33], length 3 minutes; Solution: Dynamically adjust the time granularity to Δt = 1 minute; Time points: {7:30, 7:31, 7:32, 7:33}; The probability at each time point is 1 / 4 = 25%.

[0085] Scenario C: The window is very wide (> 60 minutes).

[0086] Example: Window [7:00, 9:00], length 120 minutes.

[0087] Processing method: Keep the time granularity Δt = 5 minutes, number of time points: n = 120 / 5 + 1 = 25, probability of each time point = 1 / 25 = 4%.

[0088] 6) Output results: The discrete probability distribution table (standard case) can be shown in Table 3 below: Table 3

[0089] Driver arrival time distribution calculation: Convert the driver departure time distribution into the arrival time distribution of passengers at the pick-up point.

[0090] Step 1: Estimate travel time: The travel time T_drive is estimated based on the distance between the origin and destination and real-time traffic conditions.

[0091] Calculate using the following formula: T_drive = (Distance / V_avg) × k_traffic

[0092] Where Distance is the distance (in kilometers) from the driver's starting point to the passenger's pick-up point, V_avg is the average vehicle speed (in kilometers per hour), with a recommended speed of 30-60 km / h, and k_traffic is the traffic condition time factor (dimensionless).

[0093] The road condition coefficient can be defined as follows: Considering the impact of road conditions at different times: Morning rush hour (7:00-9:00): k_traffic = 1.67 (speed drops to 60%, 1 / 0.6≈1.67); Off-peak hours (9:00-17:00): k_traffic = 1.0 (normal speed); Evening rush hour (17:00-19:00): k_traffic = 1.43 (speed drops to 70%, 1 / 0.7≈1.43); Nighttime (19:00-7:00): k_traffic = 0.8 (speed increased by 25%, 1 / 1.25 = 0.8); The road condition coefficient can be dynamically adjusted based on real-time road condition data, weather, holidays, and other factors.

[0094] Example: Distance from the starting point to the boarding point: Distance = 5 kilometers.

[0095] During the morning rush hour, the average vehicle speed is V_avg = 30 km / h; Traffic condition coefficient: k_traffic = 1.67.

[0096] Estimated travel time: T_drive = (5 / 30) × 1.67 hours = 0.167 × 1.67 hours = 0.278 hours = 16.7 minutes ≈ 17 minutes (rounded up to the integer multiple of the time granularity). For ease of calculation, it can be adjusted to T_drive = 10 minutes.

[0097] Step 2: Calculate the arrival time distribution. For each time point t_d in the driver's departure time distribution, calculate the corresponding arrival time and its probability: Conversion rules: t_arrive = t_d + T_drive, P_arrive(t_arrive) = P_d(t_d).

[0098] That is: arrival time = departure time + travel time, arrival probability = departure probability (probability conservation).

[0099] Calculation process: Iterate through all time points in the distribution of car owner departure times: For each time point (t_d, P_d(t_d)), calculate the corresponding arrival time point and probability (t_arrive, P_arrive(t_arrive)).

[0100] Generate a table summarizing the arrival time distribution.

[0101] For example: Input: Driver departure time distribution; Driving time: T_drive = 10 minutes.

[0102] The conversion process is shown in Table 4 below: Table 4

[0103] The output is shown in Table 5 below, which illustrates the probability distribution of arrival times: Table 5

[0104] Furthermore, in actual implementation, if multiple departure times map to the same arrival time, the probabilities need to be accumulated. For example, if t_d1=7:28 and t_d2=7:32 both map to t_arrive=7:40, then P_arrive(7:40) = P_d(7:28) + P_d(7:32).

[0105] Time matching degree calculation can be based on probability distribution, calculating the time fit from the perspective of passenger demand satisfaction. It may include the following steps: S1: Define matching rules: For the vehicle owner's arrival time t_arrive and the passenger's boarding time t_passenger, the following matching rules are defined: Matching condition: |t_arrive - t_passenger| ≤ Δt_tolerance.

[0106] Δt_tolerance is the tolerable time difference (minutes), representing the acceptable range of time deviation. The recommended value is Δt_tolerance = 5 minutes. The specific value can be adjusted according to the actual scenario, such as 3-5 minutes for commuting and 5-10 minutes for long-distance travel.

[0107] If the matching criteria are met, then the time point is considered matchable (the driver can meet the passenger's needs); if the matching criteria are not met, then the time point is considered unmatchable.

[0108] For example, if Δt_tolerance = 5 minutes, the driver arrives at 7:35, and the passenger wants to board at 7:30: |7:35 - 7:30| = 5 minutes ≤ 5 minutes, so a match is possible.

[0109] The driver arrives at 7:35, and the passenger wants to board at 7:42: |7:35 - 7:42| = 7 minutes > 5 minutes, therefore a match cannot be made.

[0110] S2: Calculate passenger demand coverage: From the perspective of passenger needs, calculate the extent to which the car owner can meet the passengers' boarding needs.

[0111] Definition: Passenger coverage intensity at a certain time point. For each time point t_p within the passenger boarding window, calculate the coverage intensity of the vehicle owner at that time point (i.e., the total probability that the vehicle owner can arrive near that time). This can be calculated using the following formula: CoverageIntensity(t_p) = Σ P_arrive(t_a) The condition is met: |t_a - t_p| ≤ Δt_tolerance.

[0112] Where CoverageIntensity(t_p) is the coverage intensity at passenger time point t_p, P_arrive(t_a) is the probability of the car owner arriving at time point t_a, and the summation range is all car owner arrival times whose time difference with t_p does not exceed Δt_tolerance.

[0113] CoverageIntensity(t_p) = 100% means that the driver will definitely arrive within the tolerance range at that time point; CoverageIntensity(t_p) = 50% means that the driver has a 50% probability of arriving within the tolerance range at that time point; and CoverageIntensity(t_p) = 0% means that the driver will not be able to arrive within the tolerance range at that time point.

[0114] Passenger demand coverage is calculated by comprehensively considering all possible boarding times of passengers, and can be used to determine the overall extent to which the vehicle owner covers passenger demand. The calculation can be performed using the following formula: Coverage = Σ [P_passenger(t_p) × CoverageIntensity(t_p)]; For all passenger boarding times t_p, expand as follows: Coverage = Σ [P_passenger(t_p) × Σ P_arrive(t_a) × I(|t_a-t_p| ≤Δt_tolerance)]; Where Coverage is the passenger demand coverage (a value between 0 and 1, or 0-100%), P_passenger(t_p) is the probability that a passenger will board the bus at time point t_p, and I(condition) is an indicator function, which is 1 if the condition is met and 0 otherwise.

[0115] Where Coverage = 100% means that the driver can fully meet all the passengers' boarding time requirements, Coverage = 50% means that the driver can meet about half of the passengers' boarding time requirements (weighted average), and Coverage = 0% means that the driver cannot meet the passengers' boarding time requirements at all.

[0116] S3: Calculate the weighted matching probability: From the perspective of two-way matching, the probability of the car owner and passenger appearing at the same matchable time point is calculated.

[0117] For example, it can be calculated using the following formula: P_match = ΣΣ[P_arrive(t_a) × P_passenger(t_p) × I(|t_a-t_p| ≤ Δt_tolerance)]; Where P_match represents the weighted matching probability (a value between 0 and 1, or 0-100%), P_arrive(t_a) represents the probability that the driver arrives at time t_a, P_passenger(t_p) represents the probability that the passenger boards the vehicle at time t_p, I(condition) is an indicator function, which is 1 if the condition is met and 0 otherwise. The double summation is to iterate through all possible combinations of driver arrival time and passenger boarding time. P_match represents the probability that the driver and passenger can match their times in a randomly selected trip, that is, the joint probability considering the time distribution of both parties.

[0118] Overall score for time fit: The final time fit score is calculated by combining two indicators: passenger demand coverage and weighted matching probability. For example, the final time fit score can be calculated using the following formula: T = α × Coverage × 100 + β × P_match × 100; Where T is the time fit score (0-100 points), Coverage is the passenger demand coverage (0-1), P_match is the weighted matching probability (0-1), and α and β are weight coefficients, satisfying α + β = 1. For example, the weights α = 0.7 (passenger demand coverage weight, the dominant indicator) and β = 0.3 (weighted matching probability weight, the auxiliary indicator).

[0119] In other words, a larger α indicates an emphasis on evaluating the matching degree from the perspective of passenger needs, prioritizing passenger experience, while a smaller β indicates that the joint matching probability of both parties is considered as a supplementary factor. In actual selection, the weights can be adjusted according to the business scenario (for example, β can be increased when supply-side priority is given).

[0120] For example, a score of 90-100 indicates a high match, with a strong recommendation to establish a long-term relationship; a score of 70-89 indicates a good match, with a recommendation to establish a long-term relationship; a score of 50-69 indicates a moderate match, with the possibility of establishing a long-term relationship but adjustments needed; and a score of <50 indicates a low match, with no recommendation to establish a long-term relationship.

[0121] Calculation example: Typical scenarios where car owners can effectively meet passenger needs.

[0122] The input data is the probability distribution of car owner departure times as shown in Table 6: Table 6

[0123] Travel time: T_drive = 10 minutes

[0124] The probability distribution of the vehicle owner's arrival time is shown in Table 7 below: Table 7

[0125] Passenger boarding windows: [7:30, 7:50], with a uniform distribution as shown in Table 8 below: Table 8

[0126] Tolerance time difference: Δt_tolerance = 5 minutes.

[0127] Specifically, the calculation can be performed as follows: S1: Calculate the coverage intensity for passengers at each time point: Passengers board at 7:30 (±5 minute tolerance range: [7:25, 7:35]): Matching car owners' arrival times: 7:30, 7:35; CoverageIntensity(7:30) =P_arrive(7:30) + P_arrive(7:35)= 5%+10%=15%.

[0128] Passengers board at 7:35 (±5 minute tolerance range: [7:30, 7:40]): Matching car owners' arrival times: 7:30, 7:35, 7:40; CoverageIntensity(7:35) = P_arrive(7:30) + P_arrive(7:35) + P_arrive(7:40) = 5% + 10% + 30%= 45%.

[0129] Passengers board at 7:40 (±5 minute tolerance range: [7:35, 7:45]): Matching car owners' arrival times: 7:35, 7:40, 7:45; CoverageIntensity(7:40) = P_arrive(7:35) + P_arrive(7:40) + P_arrive(7:45) = 10% + 30% + 25% = 65%.

[0130] Passengers board at 7:45 (±5 minute tolerance range: [7:40, 7:50]): Matching car owner arrival times: 7:40, 7:45, 7:50; CoverageIntensity(7:45) = P_arrive(7:40) + P_arrive(7:45) + P_arrive(7:50) = 30% + 25% + 15%= 70%.

[0131] Passengers board at 7:50 (±5 minute tolerance range: [7:45, 7:55]): Matching car owners' arrival times: 7:45, 7:50, 7:55; CoverageIntensity(7:50) = P_arrive(7:45) + P_arrive(7:50) + P_arrive(7:55) = 25% + 15% + 10%= 50%.

[0132] The summary table is shown in Table 9 below: Table 9

[0133] S2: Calculate passenger demand coverage: Coverage = Σ [P_passenger(t_p) × CoverageIntensity(t_p)] = P_p(7:30)×CI(7:30) + P_p(7:35)×CI(7:35) + P_p(7:40)×CI(7:40) + P_p(7:45)×CI(7:45) + P_p(7:50)×CI(7:50) = 20%×15% + 20%×45% + 20%×65% + 20%×70% + 20%×50% = 3% + 9% + 13% + 14% + 10% = 49% Therefore, it can be determined that car owners can cover 49% of passengers' boarding needs (weighted average).

[0134] S3: Calculate the weighted matching probability: Table 10 below lists all matching (arrival time, boarding time) combinations and their joint probabilities: Table 10

[0135] P_match = 1% + 2% + 1% + 2% + 6% + 2% + 6% + 5% + 6% + 5% + 3% + 5% +3% + 2% = 49%.

[0136] S4: Overall Score: T = α × Coverage × 100 + β × P_match × 100 = 0.7 × 49 + 0.3 × 49 = 34.3 + 14.7 = 49 points; Therefore, the time fit can be determined as 49 points.

[0137] This is mainly because the peak arrival times for drivers (7:40-7:45) partially overlap with passenger boarding times (7:30-7:50), but drivers generally arrive later, resulting in insufficient coverage of passengers' earlier arrival time (7:30-7:35). Drivers can cover approximately 49% of passenger boarding needs, indicating a below-average match. Therefore, to improve the time fit to above 70 points (good match), the following methods can be adopted: Option A: Drivers adjust their departure time (optimization from the supply side): It is recommended that drivers depart 5-10 minutes earlier. If drivers depart 10 minutes earlier, the overall arrival time distribution will shift forward to [7:20-7:50], and the time matching rate is expected to improve to 75-80 points.

[0138] Option B: Adjust boarding window for passengers (optimization from the demand side): It is recommended that passengers adjust the boarding window to [7:35, 7:55], aligning with the peak arrival time of drivers (7:40-7:45), which is expected to improve the time matching rate to 70-75 minutes.

[0139] Option C: Negotiated adjustment by both parties (two-way optimization): Drivers arrive 5 minutes earlier and passengers depart 5 minutes later from the boarding window, achieving the optimal time match for both parties. It is estimated that the time compatibility can be improved to over 85 points.

[0140] Frequency matching calculation: Compare the travel frequency and cycle patterns of car owners and passengers; assess the degree of matching between their needs (e.g., both commuting "Monday to Friday"); matching threshold: travel cycle consistency ≥ 80% is considered a high match. Specifically, the long-term supply and demand matching degree can be assessed from the perspective of passenger demand satisfaction by analyzing users' travel frequency, cycle patterns, and daily travel frequency.

[0141] The implementation may include the following steps: S1: Vectorization of travel cycle patterns: Represent a user's travel patterns for 7 days a week as a binary vector: The vehicle owner's travel pattern vector D_d = [d1, d2, d3, d4, d5, d6, d7]; Passenger demand pattern vector D_p = [p1, p2, p3, p4, p5, p6, p7].

[0142] Where di = 1 indicates that the driver travels on day i, di = 0 indicates that the driver does not travel, pi = 1 indicates that the passenger needs to take a ride on day i, pi = 0 indicates that the passenger does not need to take a ride, i = 1 represents Monday, i = 2 represents Tuesday, ..., i = 7 represents Sunday.

[0143] For example: the car owner travels "Monday to Friday": D_d = [1, 1, 1, 1, 1, 0, 0], and the passenger needs "Monday, Wednesday, and Friday": D_p = [1, 0, 1, 0, 1, 0, 0].

[0144] S2: Calculate the day matching degree from the perspective of demand satisfaction, that is, calculate the degree to which the car owner can meet the needs of passengers: Calculate the number of overlapping days in a cycle: N_overlap = Σ(di × pi), where i ranges from 1 to 7, and only the number of days when the car owner travels and the passengers need to travel is included in the overlap; Calculate the number of days passengers need to travel and the number of days the driver travels: N_p = Σpi (number of days passengers need to travel per week), N_d = Σdi (number of days the driver travels per week); Calculate the demand satisfaction degree: R = N_overlap / N_p.

[0145] Calculate the daily matching degree score: If R = 1.0 (the car owner fully meets the passenger's needs): D_score = 100 points; if R < 1.0 (the car owner partially meets the passenger's needs): D_score = R × 100 points.

[0146] For example: Car owner: Monday to Friday (5 days), D_d = [1,1,1,1,1,0,0]; Passenger: Monday, Wednesday, Friday (3 days), D_p = [1,0,1,0,1,0,0]; N_overlap = 1+0+1+0+1+0+0 = 3 days; N_p = 3 days; R = 3 / 3 = 1.0; D_score = 100 points (the car owner fully meets the passenger's needs).

[0147] S3: Calculate the daily travel frequency matching degree: Considering that the user may travel multiple times a day (such as commuting in the morning and evening), therefore, the matching degree in terms of frequency can be calculated: Extract the daily travel frequency: For each overlapping day i (di = 1 and pi = 1): the travel frequency of the car owner on that day N_d_i (e.g., 2 times, in the morning and evening), and the required frequency of the passenger on that day N_p_i (e.g., 1 time, only in the morning).

[0148] Calculate the daily frequency satisfaction degree: The daily frequency satisfaction degree = min(N_d_i, N_p_i) / N_p_i.

[0149] If N_d_i ≥ N_p_i, then determine the frequency satisfaction degree = 1.0 (the car owner fully meets the passenger); if N_d_i < N_p_i, then determine the frequency satisfaction degree = N_d_i / N_p_i (the car owner partially meets).

[0150] Calculate the frequency matching degree score: C_score = [Σ(daily frequency satisfaction degree) / N_overlap] × 100.

[0151] For example: Overlapping for 3 days (Monday, Wednesday, Friday): Monday: The car owner travels 2 times, the passenger travels 1 time, satisfaction degree = 1.0; Wednesday: The car owner travels 2 times, the passenger travels 1 time, satisfaction degree = 1.0; Friday: The car owner travels 2 times, the passenger travels 1 time, satisfaction degree = 1.0; C_score = (1.0 + 1.0 + 1.0) / 3 × 100 = 100 points.

[0152] S4: Determine the supply and demand surplus reward: When a car owner's supply capacity exceeds passenger demand, additional bonus points are awarded: Triggering conditions: N_d > N_p and R ≥ 0.8 (the car owner has a high number of days and a high satisfaction rate).

[0153] The surplus bonus can be calculated using the following formula: Bonus = min(10, (N_d - N_p) / N_p ×20).

[0154] The more days a car owner has registered, the higher the reward, with a maximum reward of 10 points. These reward points reflect the greater likelihood that a car owner can cope with temporary adjustments.

[0155] For example: the car owner has 5 days, the passenger has 3 days, R=1.0, Bonus = min(10, (5-3) / 3 × 20) = min(10,13.3) = 10 minutes.

[0156] S5: Determine the overall score for frequency matching: Calculate the frequency matching degree using the following formula: F = w1 × D_score + w2 × C_score + Bonus; Where w1 = 0.6 (days matching weight, the primary indicator), w2 = 0.4 (number of times matching weight, the secondary indicator).

[0157] The frequency matching degree F can range from 0 to 110 points (including a maximum of 10 points of surplus reward), and is standardized as follows: F_final = min(100, F).

[0158] For example: The car owner fully accommodates the passengers (including any surplus): The input data is: Car owner: Monday to Friday, twice a day (morning + evening), D_d = [1, 1, 1, 1, 1, 0, 0]; Passengers: Monday to Friday, once a day (morning), D_p = [1, 1, 1, 1, 1, 0, 0].

[0159] Calculate the day matching degree: N_overlap (number of overlapping days) = 5 days; N_p (number of days required by passengers) = 5 days; N_d (number of days the car owner travels) = 5 days.

[0160] The requirement satisfaction R = N_overlap / N_p = 5 / 5 = 1.0, therefore, the day matching score D_score = 100 points.

[0161] Calculate the matching degree of the number of times: Overlapping for 5 days (Monday to Friday), daily analysis: Monday: Driver 2 times ≥ Passenger 1 time, Satisfaction = 1.0; Tuesday: Drivers 2 times or more, passengers 1 time or more, satisfaction rate = 1.0; Wednesday: Drivers 2 times or more, passengers 1 time or more, satisfaction rate = 1.0; Thursday: Drivers 2 times or more, passengers 1 time or more, satisfaction rate = 1.0; Friday: Drivers 2 times or more, passengers 1 time, satisfaction rate = 1.0.

[0162] Therefore, the frequency matching score C_score = (1.0×5) / 5 × 100 = 100 points.

[0163] Calculate surplus reward: Trigger condition check: N_d = N_p (5 = 5): N_d > N_p is not satisfied, there are no days left, and the bonus for surplus is 0 points.

[0164] Finally, the frequency matching degree F = w1 × D_score + w2 × C_score + Bonus = 0.6 × 100 + 0.4 × 100 + 0 = 60 + 40 + 0 = 100 points, that is, the final score is 100 points.

[0165] For example: The car owner fully meets the requirements and has extra days available: The input data is: Car owner: Monday to Friday, once a day, D_d = [1, 1, 1, 1, 1, 0, 0]; Passengers: Monday, Wednesday, and Friday, once a day, D_p = [1, 0, 1, 0, 1, 0, 0].

[0166] Calculate the day matching degree: N_overlap (number of overlapping days) = 1 + 0 + 1 + 0 + 1 + 0 + 0 = 3 days; N_p (number of days passengers need) = 1 + 0 + 1 + 0 + 1 + 0 + 0 = 3 days; N_d (number of days the car owner travels) = 1 + 1 + 1 + 1 + 1 + 0 + 0 = 5 days; The requirement satisfaction R = N_overlap / N_p = 3 / 3 = 1.0, therefore, the day matching score D_score = 100 points.

[0167] Calculate the matching degree of the number of times: Overlapping for 3 days (Monday, Wednesday, and Friday), analysis each day: Monday: 1 time for the car owner = 1 time for the passenger, satisfaction rate = 1.0; Wednesday: 1 time for the car owner = 1 time for the passenger, satisfaction rate = 1.0; Friday: 1 time for car owner = 1 time for passenger, satisfaction rate = 1.0.

[0168] Therefore, the frequency matching score C_score = (1.0×3) / 3 × 100 = 100 points.

[0169] Calculate surplus reward: Trigger conditions are checked: N_d > N_p: 5 > 3, satisfied; R ≥ 0.8: 1.0 ≥ 0.8, satisfied.

[0170] Calculate the reward: Bonus=min(10, (N_d-N_p) / N_p×20)=min(10, (5-3) / 3×20)=min(10, 2 / 3×20) = min(10, 13.3)= 10 points.

[0171] Finally, the frequency matching degree F = w1 × D_score + w2 × C_score + Bonus = 0.6×100 +0.4 × 100 + 10 = 60 + 40 + 10 = 110 points. After standardization: F_final = min(100, 110) = 100 points, that is, the final score is 100 points.

[0172] For example: The car owner partially satisfies the passengers' needs: Input data: Car owner: Once a day, Monday, Wednesday, and Friday; D_d = [1, 0, 1, 0, 1, 0, 0]; Passengers: Monday to Friday, twice a day (morning + evening), D_p = [1, 1, 1, 1, 1, 0, 0].

[0173] Calculate the day matching degree: N_overlap (number of overlapping days) = 1+0+1+0+1+0+0 = 3 days (Monday, Wednesday, Friday); N_p (number of days passengers need) = 1 + 1 + 1 + 1 + 1 + 0 + 0 = 5 days; N_d (number of days the car owner travels) = 1+0+1+0+1+0+0 = 3 days.

[0174] Demand satisfaction: R = N_overlap / N_p = 3 / 5 = 0.6; The day matching score D_score = R × 100 = 0.6 × 100 = 60 points.

[0175] Calculate the matching degree of the number of times: Overlapping for 3 days (Monday, Wednesday, and Friday), analysis each day: Monday: Driver 1 time < Passenger 2 times, satisfaction = min(1,2) / 2 = 1 / 2 = 0.5; Wednesday: Driver 1 time < Passenger 2 times, satisfaction = min(1,2) / 2 = 1 / 2 = 0.5; Friday: 1 time for the driver < 2 times for the passenger, satisfaction = min(1,2) / 2 = 1 / 2 = 0.5.

[0176] The score for matching frequency is C_score = (0.5×3) / 3 × 100 = 0.5 × 100 = 50 points.

[0177] Calculate the surplus reward: Check the trigger condition: N_d < N_p: 3 < 5, which is not met, there is no surplus, therefore, the surplus reward Bonus = 0 points.

[0178] Finally, the frequency matching degree F = w1 × D_score + w2 × C_score + Bonus = 0.6 × 60 + 0.4 × 50 + 0 = 36 + 20 + 0 = 56 points, that is, the final score is 56 points.

[0179] For example: period mismatch: Input data: Car owner: Tuesday to Saturday, once a day, D_d = [0, 1, 1, 1, 1, 1, 0]; Passengers: Monday to Friday, once a day, D_p = [1, 1, 1, 1, 1, 0, 0].

[0180] Calculate the day matching degree: Comparative analysis yielded the following results:

[0181] Therefore, N_overlap (number of overlapping days) = 0 + 1 + 1 + 1 + 1 + 0 + 0 = 4 days (Tuesday to Friday). N_p (number of days passengers need) = 1 + 1 + 1 + 1 + 1 + 0 + 0 = 5 days; N_d (number of days the car owner travels) = 0 + 1 + 1 + 1 + 1 + 0 = 5 days.

[0182] Demand satisfaction R = N_overlap / N_p = 4 / 5 = 0.8; The day matching score D_score = R × 100 = 0.8 × 100 = 80 points.

[0183] Based on this, it can be determined that although both the car owner and the passenger have a 5-day travel period, their travel periods are misaligned. The passenger needs to travel on Monday, but the car owner does not travel (missing 1 day).

[0184] Calculate the matching degree of the number of times: Overlapping for 4 days (Tuesday to Friday), daily analysis: Tuesday: 1 time for the car owner = 1 time for the passenger, satisfaction rate = 1.0; Wednesday: 1 time for the car owner = 1 time for the passenger, satisfaction rate = 1.0; Thursday: 1 time for the car owner = 1 time for the passenger, satisfaction rate = 1.0; Friday: 1 time for car owner = 1 time for passenger, satisfaction rate = 1.0.

[0185] Therefore, the frequency matching score C_score = (1.0×4) / 4 × 100 = 100 points.

[0186] Calculate surplus reward: Trigger condition check: N_d = N_p: 5 = 5, N_d > N_p is not satisfied, that is, although the number of days is the same, R < 1.0 (the cycle is not perfectly matched), therefore, there is no surplus, and the surplus bonus is 0 points.

[0187] Finally, the frequency matching degree F = w1 × D_score + w2 × C_score + Bonus = 0.6 × 80 + 0.4 × 100 + 0 = 48 + 40 + 0 = 88 points, and the final score is 88 points.

[0188] In other words, although the number of days is the same (both are 5 days), the matching score is reduced to 88 points due to the misalignment of the cycles (Monday is missing).

[0189] When calculating the overall matching score, you can use the following formula: M = w1 × path overlap + w2 × time fit + w3 × frequency fit; Default weights: w1=0.4, w2=0.35, w3=0.25.

[0190] For matches with an overall score of ≥85, the system will automatically generate a long-term matching plan, such as a fixed match for the next 30 days.

[0191] D. Fixed Ride Management Module (Subscription Management Module): This module is used to establish and manage long-term, fixed-ride services for successfully matched users.

[0192] Specifically, subscription plans can be generated based on the matching results, including the subscription period (e.g., one month, one quarter), fixed travel time, fixed travel location, single trip cost, and total cost; specifying the service content and expected number of trips.

[0193] The process involves two parties confirming the matching plan and subscription invitation to the car owner and passenger. After confirmation by both parties, a subscription relationship is established and the subscription agreement is recorded.

[0194] Automatic order generation: During the subscription period, the system automatically generates orders at the agreed-upon time, eliminating the need for users to manually place orders. This method reduces the number of user actions to 0 (only the first confirmation of a match).

[0195] Trip reminder mechanism: One hour before each trip, an automatic reminder notification will be sent to both parties (e.g., "Depart at point A at 7:30 today"); the reminder content includes the time, location, and the other party's contact information.

[0196] Automatic settlement function: After the trip ends, the single-trip fee settlement is automatically triggered (calculated according to the preset unit price); real-time settlement or periodic batch settlement is supported.

[0197] In other words, the above scheme can identify users' periodic commuting behavior, automatically match highly compatible drivers and passengers (e.g., route overlap ≥80%, time deviation ≤20 minutes, period consistency ≥80%), establish long-term fixed riding relationships, reduce users' repeated operations to 0 (only initial confirmation is required), and improve matching efficiency.

[0198] Furthermore, in this example, enhanced matching can be performed based on multi-dimensional behavioral features. That is, the behavior recognition module and matching calculation module mentioned above can be optimized to improve matching accuracy. 1) Behavioral feature extension: In addition to basic features such as time, location, and frequency, this example further extracts the user's deep behavioral features.

[0199] For example: behavioral stability indicators: Calculate the user's historical cancellation rate, lateness rate (lateness > 10 minutes), and on-time arrival rate; Assess the user's performance reliability and generate a performance reliability score (0-100 points). Reliability scores are incorporated into the matching calculation, prioritizing the matching of users with high reliability.

[0200] Personalized preference characteristics: Extract users' historical reviews, car model preferences, gender preferences, and whether they accept carpooling, etc.; Build user preference profiles to improve the personalization of matching.

[0201] Seasonal behavioral characteristics: Identify seasonal changes in user behavior (e.g., travel time may be delayed in winter and advanced in summer). Adjust the matching threshold of the time window according to the current season.

[0202] 2) Dynamic adjustment of intelligent weights: The weight coefficients w1, w2, and w3 in the matching calculation module are not fixed and can be dynamically adjusted according to user type and scenario: For example, user types can be identified: Time-sensitive users (strict attendance record, historical on-time rate >95%): increase the weight of w2 (time fit) to 0.5; Price-sensitive users (historical frequency of choosing the lowest price order >80%): increase the weight of w1 (path overlap) to 0.5, and prioritize the match with the least detour; Flexible users (high tolerance for time and path): balance the weights of the three.

[0203] Optimization can also be achieved through machine learning: collect historical matching success rates and user satisfaction feedback data; continuously optimize weight parameters using gradient descent or Bayesian optimization algorithms; and update the weight model regularly (weekly).

[0204] 3) Credit scoring mechanism: Introducing a user credit scoring system to improve matching quality: Credit score calculation: The credit score is calculated by taking into account the user's historical performance (40% weight), rating score (30% weight), platform usage time (20% weight), and complaint record (10% weight). The credit score ranges from 0 to 100, with an initial score of 80.

[0205] Credit and matching linkage: When calculating the matching results, users with high credit scores are given priority. The matching score formula is adjusted to: M' = M × (1 + α×S / 100), where α is the credit weight coefficient, and a value of 0.2 is recommended; Users with a credit score of 90 or higher can receive priority for highly matched order pushes.

[0206] In the example above, by extracting multi-dimensional behavioral features and adjusting intelligent weights, the matching accuracy can be improved by more than 25%; by using a credit scoring mechanism, the risk of default during the subscription period can be reduced, the order completion rate can be increased from 85% in the basic plan to more than 92%, and user satisfaction can be improved by 30%.

[0207] Furthermore, in this example, a performance monitoring and contract protection mechanism can be established: Specifically, modules for performance monitoring, anomaly handling, and contract constraints will be added to address issues related to rights protection and service stability. 1) Electronic Contract Generation Module: After both parties confirm the match, the system automatically generates a standardized electronic contract, clearly defining the rights and obligations of both parties: Subscription information: matching period (e.g., monthly / quarterly), fixed ride time and location, single ride cost, total cost; Performance Rules: If the driver fails to show up (does not arrive on time and does not notify in advance), he / she shall compensate the passenger for 50% of the day's fare; if the passenger is more than 15 minutes late, the driver may cancel the trip without being liable; if the passenger does not show up on time and does not notify in advance, he / she shall pay 30% of the day's fare as compensation for the wasted trip.

[0208] If you give the other party 3 days' notice, you can terminate the contract without penalty, and the fees already paid will be settled according to the actual number of times the service is completed. A penalty of 20% of the remaining subscription fee will be charged for temporary cancellation (within 3 days). If a user defaults three times consecutively, the subscription relationship will be automatically terminated by the system.

[0209] Both parties exchange electronic signatures via mobile phone verification code or facial recognition; The contract content is uploaded to a blockchain or third-party evidence storage platform to ensure it cannot be tampered with, and serves as the basis for subsequent dispute mediation.

[0210] 2) Performance monitoring submodule: During the subscription period, monitor the user's fulfillment of the subscription in real time: Pre-trip monitoring: Reminder notifications are sent to the driver and passengers twice, one hour and 30 minutes before the agreed departure time; the notifications include the time, location, weather conditions, and road condition warnings.

[0211] During the trip: Track the vehicle's real-time location via GPS, updating every 30 seconds; monitor whether the vehicle is traveling on the agreed route (a warning is triggered if the deviation is greater than 20%); monitor whether the vehicle arrives on time (a record is triggered if the actual arrival time deviates from the agreed time by more than 15 minutes).

[0212] Anomaly Detection: Automatically identifies abnormal situations such as failure to arrive on time (failure to board within 15 minutes of the agreed time), temporary cancellation (cancellation within 2 hours of departure), route deviation (deviation from the agreed route > 3 kilometers), and time delay (delay > 20 minutes). Abnormal situations are automatically recorded and trigger the processing flow.

[0213] 3) Exception handling submodule: When an anomaly is detected, the emergency response procedure is triggered: Handling of last-minute cancellations: If one party cancels more than 2 hours in advance, it will not be considered a breach of contract, only the number of cancellations will be recorded (2 cancellations without penalty are allowed per month). If one party cancels at the last minute (within 2 hours), the system will automatically recommend alternative options to the other party: Option A: Find other users from the subscription pool who have the same route and time period for temporary replacement (match rate ≥ 70%). Option B: Convert the order into a regular ridesharing order and use the real-time matching engine for matching; Option C: Provide the affected party with platform coupons or an immediate refund.

[0214] If you temporarily cancel more than the monthly exemption limit, your credit score will be deducted (10 points for each cancellation).

[0215] Delay handling: When a vehicle is delayed due to traffic congestion or other reasons: a real-time push notification will be sent to the passenger, displaying the estimated arrival time (calculated based on real-time traffic conditions); for delays of 10-20 minutes: the driver can apologize; for delays of 20-30 minutes: 10% of the fare will be automatically reduced; for delays greater than 30 minutes: 30% of the fare will be automatically reduced and recorded as a performance defect; the time estimate for subsequent trips will be updated to avoid cascading delays.

[0216] Route adjustment processing: When a temporary route adjustment is required (such as road closures, traffic accidents, or passengers changing their destination temporarily): the system recalculates the optimal route and estimated time; automatically sends a route adjustment request to the other party, and no response within 15 minutes is considered as acceptance; the cost is automatically adjusted according to the change in distance (the increased mileage is charged at the real-time unit price, and the reduced mileage is automatically refunded).

[0217] 4) Alternate Resource Pool Management: The system maintains a dynamic alternative resource pool to improve emergency response capabilities in case of abnormal situations. Resource pool composition: includes other subscribed users on the same route (path overlap ≥70%) and in the same time period (time deviation ≤30 minutes); includes non-subscribed users on the same route (active users who are willing to accept temporary orders); and prioritized according to historical response speed and reliability.

[0218] Dynamic update mechanism: The pool of alternative resources is automatically updated every day at midnight; the pool is updated in real time when a user cancels their subscription or modifies their schedule; users with a credit score of ≥85 and a response time of <5 minutes are given priority in inclusion.

[0219] Fast call strategy: When an anomaly occurs, the system completes the matching and push of alternative resources within 3 minutes; alternative solutions are pushed to 3-5 candidate users at the same time, with priority given to the first to confirm; the matching success rate is over 90%.

[0220] In the example above, by clarifying the rights and responsibilities of both parties through electronic contracts, performance disputes are reduced by more than 80%. Through a sound performance monitoring and anomaly handling mechanism, the reliability and stability of long-term fixed ride services can be improved. Even if anomalies occur, 90% of orders can be completed through alternative solutions. User trust in the subscription service increases by 60%, and user churn rate caused by anomalies decreases by 50%.

[0221] Furthermore, a prepaid and intelligent pricing incentive system can be established, namely, by adding a pricing calculation module and a fee management module to optimize cost structure and flexibility: 1) Base pricing calculation: The base price for a long-term subscription is calculated based on the following factors: Basic pricing formula: Distance: distance D (kilometers) between origin and destination; Subscription period: subscription duration T (in days); Trip frequency: estimated number of trips N (times); Basic unit price: basic unit distance price P0 (yuan / kilometer) set by the platform; Basic subscription price = P0 × D × N.

[0222] For example: the distance is 15 kilometers, and there are 2 round trips per day (once in the morning and once in the evening), with 22 working days in a month; the basic unit price is 6 yuan / kilometer; then, the basic subscription price = 6 × 15 × (2 × 22) = 3,960 yuan.

[0223] 2) Prepaid and tiered pricing mechanism, allowing users to prepay the total fee for the subscription period and enjoy tiered discounts: Prepaid Management: Users prepay the total fee in one lump sum according to the matching cycle (monthly / quarterly / yearly); the fee is temporarily stored in the platform account as a guarantee deposit; after each trip, the platform automatically deducts the daily fee from the prepaid fee and transfers it to the driver's account; when the subscription expires or is terminated early, the remaining fee will be refunded after settlement based on the actual number of completed trips.

[0224] Tiered discount strategy: Monthly payment discount: Subscribe for 1 month and enjoy an 8-10% discount; Example: 100 yuan per use, 20 uses per month, original price 2,000 yuan, actual payment 1,800 yuan (10% discount); Quarterly payment discount: Subscribe for 3 months and enjoy a 12-15% discount; Annual payment discount: Subscribe for 12 months and enjoy an 18-20% discount.

[0225] Matching score discount: Matching score M≥90: enjoy an additional 5% discount; Matching score 85≤M<90: enjoy an additional 3% discount; Matching score <85: no additional discount.

[0226] Credit Discount: Users with a credit score S≥95: enjoy an additional 5% discount; users with a credit score 90≤S<95: enjoy an additional 3% discount; users with a credit score 85≤S<90: enjoy an additional 2% discount; users with a credit score <85: no credit discount.

[0227] 3) Dynamic adjustment and flexibility optimization: In the prepaid model, a flexible adjustment mechanism is added to solve the problems of fixed matching and rigidity. Temporary change mechanism: Allows users to temporarily change their itinerary (such as the driver needing to work overtime and needing to delay departure by 1 hour, the passenger requesting leave and canceling the day's trip, or temporarily changing the pick-up and drop-off locations); after the change is initiated, the system will push it to the other party in real time. If the change is confirmed within 15 minutes, the itinerary for the day will be updated. If there is no response, the original plan will be executed. Free quota: 3 free temporary changes are allowed per month; Excess charges: After exceeding the free attempts, an adjustment fee of 10% of the cost per attempt will be charged (deducted from the prepayment). Note: Temporary changes will not result in a deduction in credit score, but frequent changes (>5 times / month) will lower the priority of subsequent matching.

[0228] Subscription plan adjustment: Allows users to adjust their travel frequency midway through the subscription period (e.g., from 5 times per week to 3 times per week); after the adjustment, the cost for the remaining period will be recalculated, with refunds or additional charges as needed; one adjustment is allowed per subscription period.

[0229] 4) Dynamic supply and demand adjustment and renewal incentives: Pricing and incentives are dynamically adjusted based on market supply and demand and user performance. Supply and demand adjustment coefficient: For routes where supply exceeds demand (more drivers than passengers): offer passengers an additional 5-10% discount to attract them to subscribe; For routes where supply is less than demand (more passengers than drivers): offer drivers an additional 10-15% subsidy to incentivize them to provide service; For routes where supply and demand are balanced: no additional adjustments are made.

[0230] Performance Incentive Mechanism: Credit Linkage: Linking user performance with credit score and price discounts: Drivers with a performance compliance rate ≥ 95% (on-time rate, cancellation rate, etc.) and passengers with a 100% on-time payment rate and a performance compliance rate ≥ 95% will receive a credit score increase of 5 points per month (maximum 100 points); upgraded discounts upon renewal (e.g., monthly discount increased from 10% to 15%); priority access to high-matching orders. One breach of contract (temporary cancellation without prior notice, unexcused lateness > 15 minutes, etc.): 10 credit points will be deducted; eligibility for discount upgrades for the current month will be cancelled. Credit score below 60 points: Restricted from participating in long-term matching; only able to use the regular order mode.

[0231] Renewal Offer: 7 days before the subscription expires, the system will analyze the performance and send a renewal invitation; if the performance rate of the previous period is ≥95%: enjoy an additional 5% discount on renewal; if the performance rate of the previous period is 90-95%: enjoy an additional 3% discount on renewal; if the performance rate of the previous period is <90%: no additional discount.

[0232] Referral incentives: When a user refers a new user to join the long-term matching program, both users will receive either a free trip or a 50 RMB coupon.

[0233] 5) Final Price Calculation Formula: Taking into account the above factors, the final subscription price calculation formula is as follows: Final subscription price = Base subscription price × (1 - Subscription duration discount%) × (1 - Matching degree discount%) × (1 - Credit discount%) × Supply and demand adjustment coefficient For example, the base price is 3,960 yuan, the monthly payment discount is 10%, the matching score discount (M=92 points) is 5%, the credit discount (S=96 points) is 5%, the supply and demand adjustment coefficient is 0.95 (supply exceeds demand, so passengers get a discount), and the final price is 3,960 × 0.9 × 0.95 × 0.95 × 0.95 = 3,060 yuan (22.7% lower than the base price).

[0234] Through the aforementioned prepayment and tiered pricing, users' long-term travel costs can be reduced by 15-25%, and subscription willingness can be increased by 50%. The platform locks in cash flow in advance through the prepayment model, reducing user churn rate by 30%. The temporary change mechanism can solve the problems of fixed rides and rigidity, adapting to temporary changes in commuting (such as overtime or leave), and user satisfaction can be increased by 40%. Through credit linkage and performance incentives, user performance rate can be increased to over 98%, forming a positive cycle in which high-quality users enjoy more benefits.

[0235] Furthermore, behavior prediction and proactive service optimization can be established, that is, by adding a behavior prediction module and a proactive service optimization mechanism: 1) Travel demand forecasting: Based on users' historical data and external factors, machine learning algorithms are used to predict changes in users' future travel demand. Prediction model construction: Input features include users' historical travel time, frequency, season, weather, holidays, weekdays / weekends, user occupation information, etc.; Algorithm selection is LSTM time series prediction or XGBoost classification model; Output result is the probability of travel each day in the next 7-30 days (a value between 0 and 1).

[0236] Demand Change Identification: Identify trends in user behavior patterns, such as: gradually delayed or earlier travel times (possibly due to job changes or adjustments to work schedules); decreased travel frequency (possibly due to job changes or increased remote work); changes in origin and destination (possibly due to moving or changing jobs); when a significant trend is detected (a deviation of >30% for two consecutive weeks), the system proactively pushes a reminder: "Your commuting pattern seems to have changed; do you need to adjust your subscription plan?"

[0237] Renewal Intention Prediction: Based on user performance, satisfaction ratings, price sensitivity, competitor usage, etc., predict the probability of users renewing their subscriptions when they expire; for users with a renewal probability of less than 50%, push retention incentives and improvement plans in advance.

[0238] 2) Proactive matching optimization: Based on the prediction results, proactively optimize the matching scheme and service content. Advance Recommendation: 10 days before the user's subscription expires, based on the predicted changes in renewal intention and demand: High renewal intention (>70%): Push renewal invitations and renewal offers; Medium renewal intention (40-70%): Push optimization solutions (such as adjusting the time, changing the matching target, additional discounts); Low renewal intention (<40%): Push retention solutions (such as large coupons, VIP services, personalized adjustments).

[0239] Dynamically adjust the matching pool: Based on the predicted travel probability, dynamically adjust the composition of the alternative resource pool; prioritize the inclusion of users with high travel probability (>80%), high credit score (>90), and fast response time (<5 minutes); update the matching pool priority ranking once a week.

[0240] Personalized recommendations: Based on user preference predictions and behavioral changes, recommend subscription plans that better suit their needs; for example, if it detects that a user's travel time is 30 minutes earlier in summer, it automatically recommends a plan to adjust the subscription time; for example, if it detects that a user prefers highly rated drivers, it prioritizes recommending drivers with a rating of ≥4.8.

[0241] 3) Intelligent renewal and optimization suggestions: When the subscription is about to expire, the system automatically analyzes and generates optimization suggestions: Performance analysis: Statistics include the number of actual trips, attendance rate, average delay time, and user reviews during the subscription period; Generate a performance report, such as "20 trips completed this month, with a 95% on-time rate and an average on-time arrival rate. Both parties rated it 4.9 points."

[0242] Cost reasonableness analysis: Compare the subscription price with the average price of a regular order on the same route; calculate the actual savings: such as "This month, a total of 420 yuan (21%) was saved through subscription".

[0243] Optimization suggestions generated: Time optimization: such as "You often arrive 10 minutes early, it is recommended to move the departure time to 7:40, which can improve the matching accuracy to 95%"; Target optimization: such as "A new driver on the same route has been found with a higher matching accuracy (96 points vs. the current 92 points), should you consider changing?"; Price optimization: such as "Renewing the quarterly payment can save an additional 180 yuan, it is recommended to upgrade to the quarterly payment plan."

[0244] Proactive renewal push: Personalized renewal invitations are generated by combining performance analysis, optimization suggestions, and renewal offers; Push timing: The first push is sent 7 days before the expiration date, the second push is sent 3 days before the expiration date, and the final push is sent 1 day before the expiration date; Simplified renewal process: Users can complete the renewal with one click without having to fill in information again.

[0245] In the example above, through behavioral prediction and proactive optimization, the user renewal rate increased by 35%, from the current 65% to 88%; the user churn rate was reduced, and the platform's user stickiness was enhanced; through advance prediction and preparation, the response speed in abnormal situations was improved by 60%, and the success rate of matching alternative solutions could reach 95%; personalized optimization suggestions could improve user satisfaction by 25%, and users felt the platform's intelligence and thoughtful service.

[0246] Furthermore, a security system linking social trust and insurance can be established, namely, by adding a social trust assessment module and an insurance linkage module to enhance security. 1) Social relationship identification: Analyze users' social relationships to reduce psychological barriers to sharing rides with strangers. Multi-dimensional social relationship recognition: Colleague relationships are identified through work location coordinates (deviation <1 km), company email verification, job information, and company social security information. Neighbor relations: Identified through residential address, community information, property certification, etc. Friend relationships: Identified through user-authorized social media account associations (such as WeChat friends, Alipay friends, and contacts in the address book); Historical ride-sharing relationships: Statistics on the number of rides shared between users, rating scores, and whether there are any complaint records.

[0247] Social relationship verification: After the system identifies potential social relationships, it pushes a verification request to the user: "You and user XXX may be colleagues / neighbors, do you want to confirm?" After both parties confirm, a social relationship tag is established to increase the matching priority.

[0248] 2) Trust score and priority matching: Trust scores between users are calculated based on social relationships and applied to the matching algorithm. Trust score calculation: Colleague relationship: base trust score +30 points; Neighbor relationship: base trust score +25 points; Friend relationship (mutual friends on social media accounts): base trust score +40 points; Historical ride-sharing relationship (rating ≥4.5 points): +5 points per ride-sharing, maximum +30 points; Number of mutual friends: +2 points per mutual friend, maximum +20 points; Trust score T ranges from 0 to 100 points.

[0249] Trust-based priority matching: Trust is used as an additional scoring dimension in matching calculations. The matching score M'' = M' + β×T (where β is the trust weight coefficient, recommended to be 0.15). For example, if the original matching score is 88 and the trust score is 50, the final matching score = 88 + 0.15 × 50 = 95.5. Priority is given to establishing long-term subscription relationships with users who have existing social connections or a good history of ride-sharing.

[0250] Social trust indicators are displayed: Social relationship tags are shown on the matching recommendation interface: "You and this driver are colleagues" and "You have 5 mutual friends"; historical ride-sharing records are displayed: "You have shared a ride with this driver 3 times, and all of them have been rated 5 stars", to enhance users' sense of security and trust.

[0251] 3) Insurance linkage module: This module automatically purchases travel accident insurance for long-term matched users to provide comprehensive risk protection. Automatic Insurance Mechanism: After users confirm their subscription, the system automatically purchases "Travel Accident Insurance" for both parties. The insurance premium can be included in the prepaid / single-trip fee (approximately 2-3% of the total cost), and users do not need to pay separately. Insurance Types: Personal Injury Insurance (maximum compensation of 500,000 RMB), Property Damage Insurance (maximum compensation of 50,000 RMB), and Third-Party Liability Insurance. Insurance Coverage: Time Range: The entire journey from passenger boarding to disembarking; Spatial Range: The agreed route and reasonable deviation (deviation < 5 km); Risk Types: Personal injury, medical expenses, property damage (such as personal belongings like mobile phones and computers), and vehicle damage caused by traffic accidents.

[0252] Trip data is linked to insurance: insurance claims are automatically linked to trip records (GPS location trajectory, timestamps, and confirmation records from both parties); in the event of an accident, the system automatically extracts trip data as the basis for claims, eliminating the need for users to provide additional evidence, thus automatically triggering the claims process upon an accident: if a trip interruption is detected (vehicle stopped for more than 30 minutes) or a deviation from the route is detected for more than 5 kilometers, the system automatically pushes: "An abnormal trip has been detected. Do you need assistance?"; after the user confirms the accident, the system automatically generates a claim application, including trip data, GPS trajectory, time records, etc.; after receiving the application, the insurance company will contact the user within 2 hours, complete the preliminary review within 24 hours, and complete the payment within 3 business days.

[0253] The above solution can improve claims efficiency. The existing claims process takes 5-10 business days, while this solution can shorten it to 3 business days. Small claims (<1000 yuan) can be processed instantly: after the system automatically approves the claim, the money will arrive within 1 hour, which can improve claims efficiency by more than 60%.

[0254] 4) Enhanced security monitoring: By combining social trust and insurance linkages, security monitoring capabilities are strengthened. Risk User Identification: Users with a trust score <30, a credit score <70, or more than 2 historical complaints are marked as "risk users"; when risk users participate in long-term matching, an additional review process is added (such as facial recognition verification and emergency contact registration).

[0255] Trip safety monitoring: For long-term matching between strangers (trust level <30 points), enhanced safety monitoring is enabled, and the entire trip is recorded (accessible only in case of disputes with authorization from both parties); the trip trajectory is shared with the user's emergency contacts in real time; a "one-click alarm" function is set up, which can trigger platform intervention and alarm in case of emergency.

[0256] Rapid dispute resolution: When a dispute occurs, the system automatically retrieves trip data, GPS track, and audio recordings (if authorized) as evidence; platform customer service responds within 2 hours and provides preliminary handling opinions within 24 hours; for disputes covered by insurance, the claims process is initiated directly.

[0257] Specifically, by leveraging a social trust mechanism, users with existing social relationships are prioritized for matching, reducing psychological barriers to long-term carpooling between strangers. This can increase subscription conversion rates by 40% and user sense of security by 55%. The insurance linkage module addresses user concerns about the safety of long-term travel, increasing platform trust by 50% and attracting 60% more new users willing to try long-term matching. Automatic linking of insurance claims with trip data improves claims efficiency by 60% and user satisfaction by 30%. The comprehensive safety guarantee system reduces the accident rate by 40% and shortens dispute resolution time by 70%.

[0258] In this example, an LSTM-based commuting behavior trend prediction model is also established, which includes: Input layer: Historical travel data for 30 days (timestamp t, origin coordinates (x1, y1), destination coordinates (x2, y2), trip completion status s) Hidden layers: 3-layer LSTM network (64 neurons in the first layer, 32 neurons in the second layer, and 16 neurons in the third layer), with tanh as the activation function; Attention mechanism layer: Introduce temporal attention weights; Output layer: Fully connected layer, sigmoid activation, outputs the commuting probability for the next 7 days; Application of prediction results: When the predicted commuting probability is ≥0.85 for 3 consecutive days, the user is marked as a potential commuter in advance and a subscription invitation is proactively pushed to them, which can be done 5-7 days earlier than the existing "post-event identification".

[0259] In implementation, dynamic scene factors can be divided into six categories based on origin-destination distance D, travel time H, weather conditions W, and holiday factors Hd, as shown in Table 11 below: Table 11

[0260] Wherein, Wrain is the rainfall factor (rain = 1, no rain = 0), and Hd is the holiday factor (holiday = 1, non-holiday = 0).

[0261] This example also provides a performance risk prediction model based on XGBoost, including: 1) Feature engineering: User-side features: historical cancellation rate Cu, late arrival rate Lu, credit score Su, subscription duration Tsub; Trip-side features: Road congestion index (Croad), Weather risk (Wrisk), Time matching deviation (Tdiff); Interaction features: Cu×Croad (interaction between user cancellation rate and road congestion), Lu×Tdiff (interaction between lateness rate and time deviation).

[0262] 2) Model structure: Input layer: 12-dimensional feature vectors (normalized); Booster layer: 10 decision trees, each with a depth of 6 and a learning rate of 0.1; Output layer: Performance risk probability Prisk(0-1), Prisk≥0.3 is marked as high risk trip.

[0263] 3) Application of prediction results: High-risk trips (Prisk≥0.3): Warnings are sent 2 hours in advance, and the alternative resource pool is automatically activated; Medium-risk trips (0.1≤Prisk<0.3): A notification will be sent 1 hour in advance, and alternative resources will be matched simultaneously; Low-risk trips (Prisk<0.1): Standard reminder process.

[0264] In this example, a multi-objective pricing optimization function is also established: The objective function is expressed as: minCost=ω1Costuser+ω2Costplatform+ω3Costsupply; maxExperience=μ1Satuser+μ2Satdriver; maxBalance=ν1Ratiosupply+ν2Ratiodemand.

[0265] The constraints are: Pricemin≤Price≤Pricemax (Price upper and lower limits); Discount ≤ Discountmax (maximum discount rate); Subsidy≤Subsidymax (maximum subsidy amount); The weighting coefficients are ω1=0.5, ω2=0.2, ω3=0.3; μ1=0.6, μ2=0.4; ν1=0.5, ν2=0.5.

[0266] In the example above, a complete ride-sharing system based on periodic commuting behavior was built. By identifying users' periodic commuting behavior and establishing long-term matching relationships, the system avoids recalculating matching for each trip, reducing computational resource consumption and improving matching success rates. Calculations show that matching efficiency can be improved by over 60% compared to the traditional single-trip matching model. Users no longer need to repeatedly place and accept orders daily; the system automatically generates orders at the agreed time, reducing operational steps by over 80%, lowering user time costs and operational burdens, and improving user satisfaction. By establishing long-term subscription relationships, the stability of supply and demand for drivers and passengers is guaranteed, reducing order cancellations due to the inability to find suitable matches. Test data shows that the order completion rate under the subscription model is over 40% higher than the ordinary model. Long-term fixed ride relationships reduce the platform's matching calculation frequency, customer service workload, and marketing costs, resulting in an overall operating cost reduction of over 30%. Through a robust fulfillment monitoring and anomaly handling mechanism, even if one party has an emergency or encounters unforeseen circumstances, alternative solutions can be quickly provided, ensuring service continuity and reliability, and reducing user complaint rates by over 50%. Through an intelligent dynamic pricing model, differentiated pricing and subsidies are implemented based on the supply and demand relationship of different routes, guiding supply and demand balance and increasing the platform's overall order volume and transaction value. The long-term subscription model enhances user dependence and stickiness to the platform, significantly improving user retention and renewal rates, and providing a more stable source of revenue. Credit scoring and social trust mechanisms prioritize establishing long-term ride-sharing relationships with users who have good credit and existing social connections, reducing the probability of safety accidents and disputes. By improving ride-sharing matching efficiency and order completion rates, more available vehicle seats are utilized, reducing the total number of vehicles on the road, which is beneficial for energy conservation, emission reduction, and alleviating traffic congestion. Through modular design, each optimization scheme can be implemented independently or in combination, facilitating flexible configuration and expansion according to actual business needs.

[0267] Specifically, this invention provides a ride-sharing fixed-ride matching system and method based on periodic commuting behavior. It automatically identifies periodic commuting behavior patterns from users' historical travel data and assesses the long-term matching degree between users, rather than just matching routes for a single trip. Furthermore, it establishes a long-term fixed-ride service mechanism for highly matched users, reducing repetitive operations for periodic commuters and achieving long-term automatic matching between drivers and passengers, thus improving travel efficiency. It also establishes a platform-based fixed-ride contract mechanism, clarifying the rights and obligations of both parties, which can prevent contract disputes in advance and protect rights. Finally, by designing a pricing and incentive model adapted to long-term travel, it reduces user costs and increases platform user stickiness.

[0268] The methods and embodiments provided in the above-described embodiments of this application can be executed in a mobile terminal, computer terminal, or similar computing device. Taking operation on an electronic device as an example... Figure 4 This is a hardware structure block diagram of an electronic device for a ride-sharing matching method provided in this application. (For example...) Figure 4 As shown, the electronic device 10 may include one or more (only one is shown in the figure) processors 02 (processors 02 may include, but are not limited to, processing devices such as microprocessors (MCUs) or programmable logic devices (FPGAs), a memory 04 for storing data, and a transmission module 06 for communication functions. Those skilled in the art will understand that... Figure 4 The structure shown is for illustrative purposes only and does not limit the structure of the electronic device described above. For example, electronic device 10 may also include... Figure 4 The more or fewer components shown, or having the same Figure 4 The different configurations shown.

[0269] The memory 04 can be used to store software programs and modules of application software, such as the program instructions / modules corresponding to the ride-sharing matching method in this embodiment. The processor 02 executes various functional applications and data processing by running the software programs and modules stored in the memory 04, thereby realizing the ride-sharing matching method of the aforementioned application. The memory 04 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 04 may further include memory remotely located relative to the processor 02, and these remote memories can be connected to the electronic device 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0270] The transmission module 06 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the electronic device 10. In one example, the transmission module 06 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission module 06 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0271] At the software level, the aforementioned ride-sharing matching device can, for example... Figure 5 As shown, it includes: Module 501 is used to acquire the historical travel data of the target passenger; The first determining module 502 is used to determine whether the target passenger is a periodic commuter based on the historical travel data. The extraction module 503 is used to extract the time pattern, location pattern and frequency pattern of the periodic travel of the target passenger from the historical travel data when it is determined that the target passenger is a periodic commuter user; The second determining module 504 is used to determine the stability of the periodic commuting behavior of the target passenger based on the time pattern, location pattern and frequency pattern of the target passenger's periodic travel. The third determination module 505 is used to determine the comprehensive matching degree between the target passenger and the current ridesharing driver by means of path overlap, time overlap and frequency matching degree when the stability is greater than the preset threshold. Module 506 is used to establish a long-term matching relationship between the target passenger and the current rideshare driver when the overall matching degree exceeds a preset matching threshold.

[0272] The execution steps of each module in the above-mentioned ride-sharing matching device can be implemented by referring to the steps in the above-mentioned ride-sharing matching method, and will not be repeated here.

[0273] This application also provides a specific implementation of an electronic device capable of implementing all steps of the ride-sharing matching method in the above embodiments. The electronic device specifically includes: a processor, a memory, a communication interface, and a bus; wherein the processor, memory, and communication interface communicate with each other via the bus; the processor is used to call a computer program in the memory, and when the processor executes the computer program, it implements all steps of the ride-sharing matching method in the above embodiments. For example, when the processor executes the computer program, it implements the following steps: Step 1: Obtain the target passenger's historical travel data; Step 2: Determine whether the target passenger is a periodic commuter based on the historical travel data; Step 3: If the target passenger is determined to be a periodic commuter, extract the time pattern, location pattern, and frequency pattern of the target passenger's periodic travel from the historical travel data; Step 4: Determine the stability of the target passenger's periodic commuting behavior based on the time, location, and frequency patterns of the target passenger's periodic travel. Step 5: If the stability is greater than the preset threshold, determine the overall matching degree between the target passenger and the current ridesharing driver by using path overlap, time overlap, and frequency matching degree. Step 6: If the overall matching degree exceeds the preset matching threshold, establish a long-term matching relationship between the target passenger and the current rideshare driver.

[0274] Embodiments of this application also provide a computer-readable storage medium capable of implementing all steps of the ride-sharing matching method in the above embodiments. The computer-readable storage medium stores a computer program that, when executed by a processor, implements all steps of the ride-sharing matching method in the above embodiments. For example, when the processor executes the computer program, it implements the following steps: Step 1: Obtain the target passenger's historical travel data; Step 2: Determine whether the target passenger is a periodic commuter based on the historical travel data; Step 3: If the target passenger is determined to be a periodic commuter, extract the time pattern, location pattern, and frequency pattern of the target passenger's periodic travel from the historical travel data; Step 4: Determine the stability of the target passenger's periodic commuting behavior based on the time, location, and frequency patterns of the target passenger's periodic travel. Step 5: If the stability is greater than the preset threshold, determine the overall matching degree between the target passenger and the current ridesharing driver by using path overlap, time overlap, and frequency matching degree. Step 6: If the overall matching degree exceeds the preset matching threshold, establish a long-term matching relationship between the target passenger and the current rideshare driver.

[0275] As can be seen from the above description, the embodiments of this application actively identify the matching degree between the target passenger and the ride-sharing driver. If the matching degree meets the requirements, a long-term matching relationship between the passenger and the driver is actively established, thereby solving the technical problem of low efficiency in the existing ride-sharing matching process and achieving the technical effect of effectively improving the efficiency of ride-sharing matching.

[0276] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on its differences from other embodiments. In particular, hardware + program embodiments are relatively simple in description because they are fundamentally similar to method embodiments; relevant parts can be referred to the descriptions in the method embodiments.

[0277] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0278] While this application provides the method operation steps as described in the embodiments or flowcharts, more or fewer operation steps may be included based on conventional or non-inventive labor. The order of steps listed in the embodiments is merely one possible execution order among many and does not represent the only execution order. In actual device or client product execution, the methods shown in the embodiments or drawings can be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment).

[0279] While this specification provides method operation steps as described in the embodiments or flowcharts, more or fewer operation steps may be included based on conventional or non-inventive means. The order of steps listed in the embodiments is merely one possible execution order among many and does not represent the only execution order. In actual device or end product execution, the methods shown in the embodiments or drawings may be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even a distributed data processing environment). The terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitations, the presence of other identical or equivalent elements in the process, method, product, or apparatus that includes said elements is not excluded.

[0280] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, in implementing the embodiments of this specification, the functions of each module can be implemented in one or more software and / or hardware components, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, or indirect coupling or communication connection between devices or units, and may be electrical, mechanical, or other forms.

[0281] Those skilled in the art will also know that, besides implementing the controller using purely computer-readable program code, the same functions can be achieved by logically programming the method steps, making the controller function as logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers (PLCs), and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the devices within it used to implement various functions can also be considered structures within that hardware component. Alternatively, the devices used to implement various functions can be considered as both software modules implementing the method and structures within a hardware component.

[0282] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0283] Those skilled in the art will understand that the embodiments of this specification can be provided as methods, systems, or computer program products. Therefore, the embodiments of this specification can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, the embodiments of this specification can take the form of computer program products implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0284] The embodiments described in this specification can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. The embodiments of this specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0285] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, system embodiments are basically similar to method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. In the description of this specification, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of the embodiments in this specification. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described can be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0286] The above description is merely an embodiment of the present specification and is not intended to limit the embodiments of the present specification. For those skilled in the art, various modifications and variations can be made to the embodiments of the present specification. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of the embodiments of the present specification should be included within the scope of the claims of the embodiments of the present specification.

Claims

1. A ride-sharing matching method, characterized in that, The method includes: Obtain the target passengers' historical travel data; Based on the historical travel data, determine whether the target passenger is a periodic commuter. If the target passenger is determined to be a periodic commuter, the time pattern, location pattern, and frequency pattern of the target passenger's periodic travel are extracted from the historical travel data; Based on the time, location, and frequency patterns of the target passenger's periodic travel, the stability of the target passenger's periodic commuting behavior is determined; When the stability is greater than the preset threshold, the overall matching degree between the target passenger and the current ridesharing driver is determined by the path overlap, time overlap, and frequency matching degree. If the overall matching degree exceeds the preset matching threshold, a long-term matching relationship is established between the target passenger and the current rideshare driver.

2. The method according to claim 1, characterized in that, Extracting the time, location, and frequency patterns of the target passenger's periodic travel from the historical travel data, including: From the historical travel data, the fixed travel time windows of the target passengers are identified, and the standard deviation of the travel time is determined to determine the fluctuation coefficient of the target passengers' travel time pattern. From the historical travel data, cluster analysis is performed on the origin and destination coordinates of the target passengers to determine their common origin and destination, and the location deviation range of the origin and destination is calculated to determine the fluctuation coefficient of the target passengers' travel locations. From the historical travel data, the travel frequency of the target passenger is determined in order to identify the fluctuation coefficient of the target passenger's travel frequency; Accordingly, based on the time, location, and frequency patterns of the target passenger's periodic travel, the stability of the target passenger's periodic commuting behavior is determined, including: The stability of the target passenger's periodic commuting behavior is determined by comprehensively considering the fluctuation coefficients of the target passenger's travel time pattern, travel location, and travel frequency.

3. The method according to claim 1, characterized in that, The overall match between the target passenger and the current rideshare driver is determined by route overlap, time overlap, and frequency matching, including: Obtain path weight, time weight, and frequency weight; The overall matching degree between the target passenger and the current rideshare driver is obtained by weighting and accumulating the path weight, time weight, frequency weight, path overlap, time overlap, and frequency matching degree.

4. The method according to claim 1, characterized in that, To obtain time overlap, including: Based on the historical data of current ridesharing drivers, extract the departure time data of ridesharing drivers; Based on the departure time data of ride-sharing drivers, a discrete probability distribution table of ride-sharing drivers is established, which includes: time point, number of departures, and departure probability. Extract the departure time data of the target passengers based on their historical travel data; Based on the departure time data of the target passengers, establish a discrete probability distribution table for the target passengers; Based on the discrete probability distribution table of ride-sharing drivers and the discrete probability distribution table of target passengers, calculate the overall coverage of ride-sharing drivers' needs for target passengers. Based on the discrete probability distribution table of ride-sharing drivers and the discrete probability distribution table of target passengers, calculate the weighted matching probability that the ride-sharing driver and the target passenger appear at the same matchable time point. The time overlap is calculated based on the overall coverage of the ride-sharing driver's needs for the target passenger and the weighted matching probability of the ride-sharing driver and the target passenger appearing at the same matchable time point.

5. The method according to claim 4, characterized in that, The time overlap is calculated based on the overall coverage of ride-sharing drivers' needs for target passengers and the weighted matching probability of ride-sharing drivers and target passengers appearing at the same matchable time point, including: The time overlap is calculated as follows: T = α × Coverage × 100 + β × P_match × 100; Where T is the time overlap, Coverage is the overall coverage of the ride-sharing driver's needs for the target passenger, P_match is the weighted matching probability that the ride-sharing driver and the target passenger appear at the same matchable time point, and α and β are weight coefficients, α + β = 1.

6. The method according to claim 4, characterized in that, Based on the discrete probability distribution tables of ride-sharing drivers and target passengers, calculate the weighted matching probability that the ride-sharing driver and the target passenger simultaneously appear at a matchable time point, including: The weighted matching probability of a rideshare driver and a target passenger appearing at the same matchable time point is calculated using the following formula: P_match = ΣΣ[P_arrive(t_a) × P_passenger(t_p) × I(|t_a-t_p| ≤ Δt_tolerance)]; Where P_match represents the weighted matching probability that the rideshare driver and the target passenger appear at the same matchable time point, P_arrive(t_a) represents the probability that the rideshare driver arrives at time point t_a, P_passenger(t_p) represents the probability that the target passenger gets on the ride at time point t_p, Δt_tolerance is the tolerance time difference, and I(condition) is the indicator function.

7. The method according to claim 4, characterized in that, Based on the discrete probability distribution tables of ride-sharing drivers and target passengers, calculate the overall coverage of ride-sharing drivers' needs for target passengers, including: The overall coverage of ride-sharing drivers' needs to the target passengers' demands is calculated using the following formula: Coverage = Σ [P_passenger(t_p) × ΣP_arrive(t_a) × I(|t_a-t_p| ≤ Δt_tolerance)]; Where Coverage represents the overall coverage of the ride-sharing driver's needs for the target passenger, P_passenger(t_p) represents the probability that the target passenger gets on the ride at time t_p, P_arrive(t_a) represents the probability that the ride-sharing driver arrives at time t_a, and I(condition) is the indicator function.

8. The method according to any one of claims 1 to 7, characterized in that, Determining whether the target passenger is a periodic commuter based on the historical travel data includes: The time stability score of the target passenger is calculated using the following formula: ； in, The target passenger's time stability score is determined. The standard deviation of travel time within the preset duration. The preset maximum threshold; The location stability score for the target passenger is calculated using the following formula: ； in, Score the location stability for the target passengers. The number of trips within the core cluster. This represents the total number of trips. The frequency stability score of the target passenger is calculated using the following formula: ； in, The target passenger frequency stability score is given. The goodness of fit between the actual frequency and the Poisson distribution. This is the adjustment coefficient; The behavioral consistency score of the target passenger is calculated using the following formula: ； in, Score the consistency of the target passenger's behavior. Let n be the probability of transitioning between the travel status on day i and day i+1, and n be the total number of days. The overall score of the target passenger's periodic commuting behavior is calculated using the following formula: ； in, The score represents the overall score of the target passenger's periodic commuting behavior, with a, b, c, and d being weighting coefficients.

9. The method according to any one of claims 1 to 7, characterized in that, Determining whether the target passenger is a periodic commuter based on the historical travel data includes: Retrieve a pre-established commuting behavior trend prediction model; The historical travel data of the target passenger within a preset time period is used as input data and input into the input layer of the commuting behavior trend prediction model: The commuting behavior trend prediction model outputs the commuting probability of the target passenger in future periods through its output layer. The commuting behavior trend prediction model includes a hidden layer and an attention mechanism layer. The hidden layer consists of a first layer with 64 neurons, a second layer with 32 neurons, and a third layer with 16 neurons, with the activation function being tanh. The attention mechanism layer introduces temporal attention weights. The output layer consists of a fully connected layer and a sigmoid activation function.

10. A ride-sharing matching device, characterized in that, include: The acquisition module is used to acquire the historical travel data of the target passenger; The first determining module is used to determine whether the target passenger is a periodic commuter based on the historical travel data; The extraction module is used to extract the time pattern, location pattern, and frequency pattern of the target passenger's periodic travel from the historical travel data when it is determined that the target passenger is a periodic commuter. The second determining module is used to determine the stability of the target passenger's periodic commuting behavior based on the time pattern, location pattern, and frequency pattern of the target passenger's periodic travel. The third determination module is used to determine the overall matching degree between the target passenger and the current ridesharing driver by means of path overlap, time overlap, and frequency matching degree when the stability is greater than a preset threshold. A module is established to create a long-term matching relationship between the target passenger and the current rideshare driver when the overall matching degree exceeds a preset matching threshold.

11. A terminal device, comprising a processor and a memory for storing processor-executable instructions, characterized in that, When the processor executes the instructions, it implements the steps of the method according to any one of claims 1 to 9.

12. A computer-readable storage medium having a computer program / instructions stored thereon, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the method according to any one of claims 1 to 9.

Images