Message pushing method and device, storage medium and electronic equipment

Abstract

The invention discloses a message pushing method and device, a storage medium and electronic equipment, and relates to the technical field of recommendation systems. The method comprises the following steps: determining road condition information of a first route; under the condition of determining that the first route is abnormal based on the road condition information of the first route, planning at least two candidate routes, and determining a time difference of arrival between the at least two candidate routes; and under the condition that the time difference of arrival satisfies a message pushing condition, taking the candidate route with the shortest arrival time between the at least two candidate routes as a second route, and pushing a necessary message containing related information of the second route to the terminal. According to the method, the candidate routes can be triggered to be planned under the condition that the condition that the road condition of the first route is abnormal is determined, and then the related information of the second route selected from the candidate routes is actively pushed in the form of the necessary message, so that a user is reminded to avoid a congested road section, and the travel experience of the user is effectively improved.

Description

Technical Field

[0001] This application relates to the field of recommendation system technology, and in particular to a message push method, apparatus, storage medium and electronic device. Background Technology

[0002] With urbanization and the increase in the number of motor vehicles, road congestion has become a core issue affecting travel efficiency. Although electronic maps are now widespread and can provide congestion avoidance navigation services through route planning and real-time traffic conditions, the current service model of electronic maps has significant limitations. In scenarios where users drive familiar routes, it is difficult to meet the needs of efficient congestion avoidance.

[0003] In high-frequency scenarios such as daily commutes, users are highly familiar with some frequently used routes (such as "home to work" or "school to home") and usually do not actively turn on electronic map navigation when traveling. However, when such routes become congested due to sudden accidents, temporary repairs, traffic control, or extreme weather, electronic maps cannot push abnormal traffic information in real time because navigation is not activated. Users only realize the traffic congestion when they reach the beginning of the congestion. At this time, if there is a side road nearby, they can temporarily detour, wasting only a small amount of time. But if they are on elevated roads, expressways, or main roads without side roads, users have no room to adjust and can only get stuck in congestion, which not only delays their journey but may also cause driving anxiety and increase the risk of secondary accidents.

[0004] Furthermore, most existing traffic alert mechanisms rely on users actively opening the app or subscribing to services, and lack adaptation for scenarios where users are familiar with the route but do not actively open electronic map navigation. For example, the "traffic alert" function of some maps requires the app to be opened and a navigation route to take effect. General push notifications such as broadcasts and city traffic app announcements are less targeted, making it difficult for users to quickly obtain congestion information related to their own routes, and failing to solve the core pain point of "sudden congestion avoidance when familiar with the route but without navigation".

[0005] In summary, in scenarios where users drive familiar routes, there are problems such as untimely delivery of abnormal road condition information and a lack of decision-making windows for avoiding congestion. There is an urgent need for technical solutions that can proactively identify travel habits, accurately predict familiar routes, and push effective congestion avoidance information at key nodes to fill the gaps and improve travel efficiency and experience. Summary of the Invention

[0006] In view of this, this application provides a message push method, apparatus, storage medium, and electronic device. This application can trigger the planning of candidate routes when it is determined that there are abnormal traffic conditions on a first route, and then proactively push relevant information about a second route selected from the candidate routes in the form of a guaranteed message, thereby reminding users to avoid congested sections and effectively improving the user's travel experience.

[0007] Firstly, this application provides a message push method applied to a cloud server, including: The road condition information for the first route is determined; the first route is predicted based on historical driving data uploaded by the terminal.

[0008] If it is determined that there is an anomaly in the first route based on the road condition information of the first route, at least two candidate routes are planned, and the arrival time difference between the at least two candidate routes is determined.

[0009] If the arrival time difference meets the message push conditions, the candidate route with the shortest arrival time between at least two candidate routes will be selected as the second route, and a guaranteed message containing information about the second route will be pushed to the terminal.

[0010] Secondly, this application provides a message push method, applied to a terminal, including: Receive a guaranteed delivery message containing information about the second route sent by the cloud server; the second route is determined based on the candidate route with the shortest arrival time among at least two candidate routes, provided that the arrival time difference between at least two candidate routes meets the message push conditions, and the at least two candidate routes are planned based on the road condition information of the first route, which indicates that the first route is abnormal.

[0011] Based on the guaranteed delivery message containing information about the second route, display the guaranteed delivery message pop-up.

[0012] Thirdly, this application provides a message push device applied to a cloud server, comprising: The determination module is configured to determine the road condition information of the first route; the first route is predicted based on historical driving data uploaded by the terminal.

[0013] The planning module is configured to plan at least two candidate routes and determine the arrival time difference between at least two candidate routes if the traffic information of the first route indicates that there is an anomaly in the first route.

[0014] The push module is configured to, when the arrival time difference meets the message push conditions, select the candidate route with the shortest arrival time between at least two candidate routes as the second route, and push a guaranteed message containing information about the second route to the terminal.

[0015] Fourthly, this application provides a message push device applied to a terminal, comprising: The receiving module is configured to receive a guaranteed message containing information about the second route sent by the cloud server. The second route is determined based on the candidate route with the shortest arrival time among at least two candidate routes, provided that the arrival time difference between at least two candidate routes meets the message push conditions. The at least two candidate routes are planned when it is determined that there is an anomaly in the first route based on the traffic information of the first route.

[0016] The display module is configured to display a guaranteed delivery message pop-up based on a guaranteed delivery message containing information related to the second route.

[0017] Fifthly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method of the first or second aspect.

[0018] In a sixth aspect, this application provides an electronic device, including a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, wherein the processor executes the computer program to implement the method of the first aspect or the second aspect.

[0019] In view of the above embodiments, this application provides a message push method, apparatus, storage medium, and electronic device. This application can proactively determine the traffic information of a user's frequently used route (first route) via a cloud server. When an anomaly is detected on the first route, it plans at least two candidate routes to avoid the abnormal road segment and calculates the arrival time difference. Only when the arrival time difference meets the message push condition is the relevant information of the optimal route (second route) pushed to the terminal as a guaranteed message. This solution overcomes the limitation of existing electronic maps that rely on users actively activating navigation to provide congestion avoidance services. Even if the user does not activate navigation, they can promptly obtain abnormal traffic conditions and optimal detour plans for frequently used routes, effectively avoiding travel delays caused by not promptly detecting congestion or missing congestion avoidance road segment nodes (such as elevated roads without intersections), significantly improving travel efficiency and user experience.

[0020] It should be noted that the above content is only a general overview of the technical solution of this application. In order to enable those skilled in the art to clearly understand the core technical means of this application and to accurately implement this solution based on the content disclosed in the specification, the technical details of this application will be described in detail below in conjunction with specific embodiments. Attached Figure Description

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

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

[0023] Figure 1 The illustration shows an example scenario applicable to a message push method provided in this application embodiment; Figure 2 This paper illustrates a system architecture diagram applicable to a message push method provided in an embodiment of this application; Figure 3 An example terminal diagram is shown, to which a message push method provided in this application is applicable; Figure 4 This illustration shows a flowchart of a message push method provided in an embodiment of this application; Figure 5 This illustration shows a flowchart of a message push method provided in an embodiment of this application; Figure 6 This illustration shows a flowchart of a message push method provided in an embodiment of this application; Figure 7 This paper shows a schematic diagram of the structure of a message push device provided in an embodiment of this application; Figure 8 A schematic diagram of the structure of a message push device provided in an embodiment of this application is shown. Detailed Implementation

[0024] All user driving data involved in this application strictly comply with relevant laws and regulations on data security and privacy protection. During the data collection phase, valid authorization from users has been clearly obtained, and users have full knowledge and the right to choose regarding the scope of data collection, usage scenarios, and duration. During the data processing phase, de-identification and anonymization techniques are used to process the data, removing information that can be directly or indirectly linked to a specific user's identity, ensuring that the data cannot be linked to any specific individual during use. Furthermore, security measures such as encrypted storage and transmission are employed to prevent data leakage, misuse, or tampering, comprehensively protecting users' data rights.

[0025] To facilitate the explanation of the embodiments of this application, some technical terms and technical means related to the embodiments of this application, as well as the application scenarios of the embodiments of this application, will be introduced first below.

[0026] Bida Messaging is a messaging format based on 5G messaging technology, characterized by high real-time performance, strong reach, and rich content. Unlike traditional SMS or app notifications, Bida Messaging displays directly as a pop-up on the user interface without requiring the user to actively open the application. It supports embedding text, route guidance, interactive buttons (options), and other multi-dimensional information, ensuring that users can quickly obtain key information in scenarios such as driving and commuting. Furthermore, the message delivery rate is close to 100%, preventing missed opportunities to avoid congested areas due to message delays or omissions.

[0027] Third-party data sources provide external data support for road condition information, including real-time traffic control data released by traffic management departments, traffic flow data collected by road monitoring systems, meteorological data such as rainfall / snowfall that affect traffic released by meteorological departments, standardized road condition data provided by electronic map open platforms, and traffic accident data synchronized by accident alarm platforms, ensuring the accuracy and timeliness of road condition information.

[0028] Route prediction technology, based on historical driving data uploaded by the terminal, analyzes user travel patterns through machine learning algorithms (such as path preference models), automatically identifies and predicts the user's first route, and achieves "non-interactive" route monitoring without requiring the user to manually input the starting point and destination.

[0029] Dynamic traffic update technology combines real-time data from third-party data sources with current driving data uploaded by the terminal (including real-time location, driving speed, remaining mileage, etc.) to periodically update the traffic information of the first route, which can accurately identify abnormal situations such as sudden congestion and temporary traffic control.

[0030] When an anomaly occurs on the primary route, the route planning technology plans at least two candidate routes to avoid the abnormal route based on traffic data provided by a third-party data source. By integrating multiple parameters such as route mileage, real-time traffic flow, and number of traffic lights into a predictive model, the arrival time of each candidate route is calculated, thereby determining the arrival time difference between at least two candidate routes. This provides a basis for decision-making regarding "whether to push a message" and "which route to push".

[0031] In users' daily commutes, current electronic map applications have many shortcomings, making it difficult to help users effectively avoid congested sections of road. On the one hand, electronic maps heavily rely on users actively activating navigation and setting routes. If a user doesn't activate navigation, even if their usual route is congested, the system cannot detect and push abnormal information, causing users to only discover the problem at the starting point of the congestion, missing the opportunity to detour. For example, a user might only discover congestion at the entrance to an elevated highway but be unable to change their route in time. On the other hand, existing general traffic information push methods, such as traffic radio and city traffic app announcements, while informing users of congestion in a certain area, cannot accurately correspond to the user's specific route. For example, regarding congestion on a specific elevated highway section during a user's daily commute, the broadcast might only mention congestion in the area, making it difficult for users to quickly filter out key information relevant to themselves. During busy commuting hours, it's even more difficult to balance driving and information filtering.

[0032] This application provides a message push method that can accurately plan the optimal detour route (second route) when it is determined that the user's frequently used route (first route) has abnormal traffic conditions, and actively push a guaranteed message containing information about the second route to the terminal. This effectively solves the problem that it is difficult for users to obtain abnormal traffic information in real time and avoid congested road sections in a timely manner when navigation is not enabled, thereby improving the user's travel efficiency and travel experience.

[0033] The message push method provided in this application can be applied to users' daily commuting scenarios, especially focusing on high-frequency fixed-route travel scenarios such as commuting to and from get off work. It covers sub-scenarios such as weekday morning peak (7:00-9:00), evening peak (17:00-19:00) and weekend fixed destination travel (such as "home to supermarket" and "home to parents' residence"). The compatible terminal devices include smartphones, in-vehicle smart terminals, smartwatches and other devices that can receive 5G messages.

[0034] like Figure 1 The scenario shown depicts a user starting from their residence (starting point) at 8:00 AM daily, traveling along a fixed route from "XX Road to XX Elevated Road to XX Avenue" (Route 1) to their company (ending point). During the morning rush hour (e.g., 7:50 AM), just before the user enters the XX Elevated Road, a multi-vehicle collision occurs on the "XX Elevated Road K120 section" of Route 1, causing traffic to stop and become congested on that section. Based on this... Figure 2 The system architecture diagram shown below illustrates the execution flow of the method in this application: First, the cloud server automatically identifies the first route to be taken by using the historical driving data uploaded by the user's terminal (including the departure time and driving trajectory of "home to company" in the past 30 days).

[0035] Next, the cloud server sends a data request to a third-party data source to obtain real-time traffic data on the "Traffic Accident on the K120 Section of the XX Elevated Road". Combined with the initial traffic information of the first route, it is determined that there is abnormal congestion on the route.

[0036] Subsequently, based on real-time traffic conditions (such as traffic flow and speed on various road segments) provided by third-party data sources, the cloud server plans two candidate routes to avoid abnormal road segments, such as "XX Road to XX Expressway to XX Avenue" (candidate route 1) and "XX Road to XX Auxiliary Road to XX Avenue" (candidate route 2). Then, through a prediction model that integrates multiple parameters such as road segment mileage, number of traffic lights, and real-time traffic flow, the arrival time of the two candidate routes is calculated. It is found that candidate route 1 is expected to save 20 minutes compared to candidate route 2, and meets the conditions for message push.

[0037] Finally, the cloud server selected candidate route 1 as the second route and pushed a 5G guaranteed message to the user's smartphone. The message content accurately included key information such as "Abnormal road section: XX Elevated Road K120 section", "Cause of abnormality: Traffic accident and congestion", "Route guidance: Turn left from XX Road into XX Expressway, go straight to XX Avenue and turn right" (candidate route 1) and "Estimated time saved: 20 minutes", helping users quickly understand the cause of the abnormality and the solution to avoid congestion.

[0038] like Figure 3 The example terminal device shown demonstrates that users can access the 5G guaranteed delivery message pop-up at the top of their smartphone screen without opening a navigation app. The pop-up displays the aforementioned key information and includes two interactive buttons: "Route Confirm" and "Route Ignore." A countdown timer is placed at the "Route Ignore" button. Users can assess the value of a detour based on their commute time (e.g., starting at 8:30 AM, currently at 7:50 AM). Clicking "Route Confirm" will redirect the phone to the route details page. If "Route Ignore" is selected, or the countdown timer reaches zero, the pop-up automatically collapses without interfering with driving, effectively balancing information delivery efficiency and driving safety. This prevents users from being unable to adjust their route after entering an elevated road due to unnoticed congestion.

[0039] The embodiments of this application will now be described in more detail with reference to the accompanying drawings. It should be noted that, unless otherwise specified, the embodiments and features described herein can be combined with each other.

[0040] This embodiment provides a message push method applied to a cloud server. Relying on the hardware and technological foundation of the cloud server (high-concurrency cluster, real-time API interface, machine learning model, 5G communication module), even when the user has not enabled navigation, it can proactively identify abnormal traffic conditions on frequently used routes (first route) and accurately plan the optimal detour (second route), thereby pushing a guaranteed message reminder to the user containing information related to the second route.

[0041] The following is combined with Figure 4 The flowchart shown illustrates the execution process of the message push method. This message push method includes the following steps S101~S103: S101. Determine the road condition information for the first route.

[0042] The first route is a fixed route that the cloud server identifies by analyzing historical driving data uploaded by the terminal, which is the user's frequently used travel route.

[0043] The traffic information for Route 1 is a data set related to Route 1 that reflects the road traffic status. It covers key information such as road speed, whether there is congestion / accident / temporary traffic control, and the impact of weather on traffic, providing a basis for judging whether Route 1 is abnormal.

[0044] For example, the cloud server uses historical driving data uploaded by the terminal as a basis (such as the departure point, destination, departure time, driving trajectory and route preference in the terminal's historical records), and combines it with the user's historical departure time patterns (such as the user often departs at 8 am), and automatically starts route prediction to obtain the traffic information of the first route within the expected user travel period (such as before 7:30 am).

[0045] For example, the cloud server can also continuously obtain road condition information for the first route based on the current driving data uploaded by the terminal (such as the real-time location and driving speed uploaded by the terminal).

[0046] S102. If it is determined that there is an anomaly in the first route based on the road condition information of the first route, plan at least two candidate routes and determine the arrival time difference between at least two candidate routes.

[0047] The first route being abnormal refers to situations where the road conditions are not in line with normal traffic expectations, based on the road condition information of the first route. These situations include, but are not limited to: road congestion (traffic speed is 50% or more lower than the normal speed for the same period), sudden traffic accidents (such as minor collisions or scrapes that cause lane closures), temporary traffic control (such as road closures or traffic restrictions), temporary construction (such as road repairs that occupy lanes), and extreme weather (such as heavy rain or snow that cause road closures or speed limits). All of these situations will significantly increase the time it takes for users to travel on this route.

[0048] The candidate route is an alternative route planned by the cloud server after determining that the first route is abnormal, based on third-party data sources (traffic control, real-time traffic flow, road capacity, etc.) to avoid the abnormal road segment.

[0049] For example, the cloud server first obtains basic attribute data (mileage, number of traffic lights, number of lanes), real-time traffic data (traffic flow, real-time speed, temporary traffic restrictions), and auxiliary impact data (weather conditions in the route area, historical travel time patterns in the same scenario) for each candidate route from a third-party data source via a real-time API interface. Then, it calls a multi-parameter fusion prediction model to calculate the basic travel time for each candidate route as "total mileage ÷ real-time average speed," and then combines this with traffic light waiting time (calculated as the average waiting time per traffic light in historical data × number of traffic lights) and travel time adjustments due to weather / temporary restrictions (e.g., multiplying by the corresponding adjustment coefficient if rainfall reduces traffic speed) to obtain the predicted arrival time for a single candidate route. Finally, it selects the candidate routes to be compared, subtracts the shorter predicted arrival time from the longer predicted arrival time, and obtains the arrival time difference between the two candidate routes.

[0050] S103. If the arrival time difference meets the message push condition, select the candidate route with the shortest arrival time between at least two candidate routes as the second route, and push a guaranteed message containing information about the second route to the terminal.

[0051] For example, message push conditions should be set based on at least two core dimensions: "uninterrupted user experience" and "actual benefits from route switching," to ensure that only high-value information is pushed. For instance, regarding the "actual benefits from route switching" dimension, a time difference threshold can be used to determine whether the arrival time difference between candidate routes is greater than the threshold. This time difference threshold is not fixed and can be dynamically calculated by combining candidate route characteristics (mileage / remaining mileage) with external factors. For example, the basic threshold for routes within 10 kilometers could be set to 5 minutes, and for routes within 20 kilometers, to 8 minutes. During peak hours or accident scenarios, the threshold could be increased by 20% to 30%, ensuring that route switching significantly saves users time and preventing users from frequently switching routes to "save 1 to 2 minutes." In terms of "uninterrupted user experience", the push frequency is controlled to determine whether the same type of must-deliver message has been pushed to the terminal within a preset period (e.g., 1 hour) and the user has not read / responded. The time difference threshold will be automatically increased (e.g., the original threshold of 5 minutes will be adjusted to 8 minutes) to reduce the push frequency and avoid message bombardment to disturb the user (especially in driving scenarios). If the user responds frequently (e.g., click "Route Confirmation" ≥ 3 times within 1 hour), the threshold will be reduced (e.g., 5 minutes will be adjusted to 4 minutes) to prioritize pushing key information.

[0052] For example, when pushing a guaranteed delivery message, the cloud server first compares the predicted arrival times of at least two candidate routes to select the candidate route with the shortest arrival time, which is then designated as the second route (i.e., the optimal detour route). Next, it integrates core information related to the second route, including its core guidance (e.g., "turn left on XX Road, go straight on XX Expressway"), abnormal information about the first route (location / cause of abnormal road sections), and estimated time savings from the detour (e.g., "15 minutes less than the original route"), ensuring the content is concise and valuable for decision-making, avoiding redundant information. Then, it calls a communication module adapted for 5G message push, establishing a communication link with the terminal via the 5G message protocol based on the terminal's activated 5G messaging service, directly triggering the terminal's system-level message receiving channel to push the guaranteed delivery message to the terminal. After the guaranteed delivery message is pushed, it receives real-time feedback from the terminal regarding the message status (read / unread, whether the interaction button was clicked), and records the push timestamp, providing data support for subsequent "dynamic adjustment of push frequency" and "re-pushing after changes in traffic conditions."

[0053] This embodiment provides a message push method applied to a terminal. The terminal is one equipped with 5G messaging service. Leveraging the strong reach of 5G messages, it enables accurate reception and visual display of traffic condition anomalies and optimal route information. Figure 5 As shown, the steps include S201 to S202 as follows: S201. Receive a guaranteed delivery message containing information about the second route sent by the cloud server.

[0054] The second route is determined based on the candidate route with the shortest arrival time among at least two candidate routes, provided that the arrival time difference between at least two candidate routes meets the message push conditions. The at least two candidate routes are planned when it is determined that there is an anomaly in the first route based on the traffic information of the first route.

[0055] For example, the terminal relies on a SIM card that has activated 5G messaging service to automatically receive guaranteed messages pushed by the cloud server through the 5G messaging communication channel.

[0056] S202. Based on the guaranteed delivery message containing information related to the second route, display the guaranteed delivery message pop-up.

[0057] The message pop-up will display at least one of the following: route information for the second route, abnormal road segment information, estimated time saved, route confirmation interaction options, and route ignore interaction options.

[0058] For example, the terminal parses the received guaranteed delivery message, extracts the key information, and generates and displays a standardized guaranteed delivery message pop-up. The pop-up includes the location and cause of the abnormal road segment on the first route (abnormal road segment information), the route information of the second route, and the estimated time saved by the detour. It also provides two interactive options, "Route Confirmation" and "Route Ignore," to help users quickly understand the cause of the abnormality and the solution.

[0059] The message push method provided in the embodiments of this application will now be described in detail from the cloud server side.

[0060] In the actual application scenario of the message push method of this application, the traffic information of the first route can be dynamically divided into two categories according to the user's travel stage, which can be adapted to the "pre-trip prediction" and "in-trip monitoring" scenarios respectively, to ensure the comprehensiveness and timeliness of traffic perception.

[0061] When determining the road condition information of the first route, this application first predicts the first route by analyzing high-frequency travel patterns based on historical driving data uploaded by the terminal, and then obtains the first road condition information corresponding to the "pre-trip prediction" scenario and the second road condition information corresponding to the "in-trip monitoring" scenario.

[0062] In some embodiments, if the difference between the current time and the predicted start time of the first route is less than a preset judgment threshold, traffic information for the first route is extracted based on traffic data provided by a third-party data source and used as the first traffic information. The historical driving data includes the terminal's historical records of origin, destination, departure time, driving trajectory, and route preferences.

[0063] The first traffic information refers to the initial traffic information obtained by the cloud server based on the predicted first route before the user has departed or just departed and has not yet entered the first route driving stage (corresponding to the "pre-trip prediction" scenario). This information is used to predict in advance whether there are any fixed anomalies on the first route. For example, the cloud server first predicts the first route the user will be traveling on based on historical driving data uploaded by the terminal (departure point, destination, departure time, driving trajectory, route preference). Then, it connects to third-party data sources (traffic control announcements, average traffic speed of road sections in the previous hour, weather warnings, etc.) through a real-time API interface to extract traffic data that completely matches the first route. This data is then integrated to form the first traffic information, providing a preliminary basis for subsequent judgment on whether there are any anomalies on the first route.

[0064] In some embodiments, when it is detected that the current location of the terminal is at the starting point of the first route or within a preset range of the starting point, and the direction of the terminal's movement is consistent with the planned direction of the first route, the traffic information of the first route is updated based on real-time traffic update data from a third-party data source and the current driving data, and is used as the second traffic information.

[0065] The current driving data includes the real-time location, speed, acceleration, and remaining mileage uploaded by the terminal. The second traffic information is a dynamic update of the first traffic information by the cloud server when the user has entered the first route and is in the middle of the journey (corresponding to the "in-driving monitoring" scenario). For example, when the cloud server detects that the terminal's real-time location is within the starting point of the first route or a preset range from the starting point (e.g., 500 meters around the starting point), and the terminal's direction of movement is consistent with the planned direction of the first route (excluding cases where the user temporarily deviates from the route), the second traffic information is formed by integrating real-time traffic updates from third-party data sources (such as traffic flow, accident alarms, and dynamic traffic control refreshed every 30 seconds to 1 minute) and the current driving data uploaded by the terminal (such as real-time location, speed, acceleration, and remaining mileage).

[0066] The following sections will introduce the "pre-trip prediction" and "in-trip monitoring" scenarios in the above examples.

[0067] The "pre-trip prediction" scenario focuses on situations where users have not yet departed or have just departed, and have not yet entered the core driving stage of the first route. For example Figure 6 As shown, after the cloud server identifies an anomaly in the first route based on the first traffic information, it plans candidate routes and calculates the arrival time difference through steps S301 to S303, providing a basis for subsequently pushing the optimal detour plan.

[0068] S301. If it is determined that there is an anomaly in the first route based on the first road condition information, a first candidate route is planned from the starting point to the end point of the first route based on the road condition data provided by the third-party data source.

[0069] Among them, the first candidate route and the first route have at least some non-overlapping sections, and the non-overlapping sections do not include abnormal sections where the first route has an anomaly.

[0070] For example, the cloud server first determines that the first route has an anomaly (such as road construction occupying a section of an elevated road) based on the first traffic information (such as construction notices or fixed congestion data during the morning rush hour provided by a third-party data source). Then, it calls the route planning module and, in conjunction with real-time traffic data provided by the third-party data source (including traffic flow, speed, and traffic control status of each road segment), plans a first candidate route from the starting point to the end point of the first route. This first candidate route satisfies the following conditions: it has at least some non-overlapping sections with the first route (for example, if the first route includes "XX elevated road segment", the first candidate route is replaced by a parallel "XX ground expressway segment"); and all non-overlapping sections do not include the abnormal sections of the first route, ensuring that the traffic problems of the first route are completely avoided and preventing users from driving into abnormal sections.

[0071] S302. Based on traffic data provided by a third-party data source, plan a second candidate route from the starting point of the first route to the starting point of the abnormal road section, and from the starting point of the abnormal road section to the end point.

[0072] Among them, at least some sections of the second candidate route overlap with the sections from the starting point of the first route to the starting point of the abnormal section, and the non-overlapping sections do not include the abnormal section.

[0073] For example, the cloud server combines traffic data from a third-party data source to plan a second candidate route. For instance, starting from the beginning of the first route, it first travels along the normal section of the first route to the beginning of the abnormal section (e.g., for the first route "home to XX Road to XX Elevated Road entrance (abnormal section beginning)," the second candidate route overlaps with this section). Then, from the abnormal section beginning, a detour route to the destination is planned, and the detour portion (non-overlapping sections) avoids the abnormal section (e.g., turning from "XX Elevated Road entrance" to "XX Auxiliary Road," then via ground roads to the destination). This ensures that the second candidate route only overlaps with the first route before the abnormal section, and the subsequent detour section is normal, reducing the user's adaptation cost to the new route.

[0074] S303. Determine the time difference between the first and second candidate routes based on their predicted arrival times.

[0075] For example, the cloud server invokes a multi-parameter fusion prediction model, inputting the mileage of each segment of the first and second candidate routes, real-time traffic speed, number of traffic lights, and historical travel time patterns under similar road conditions (such as average traffic light waiting time during morning rush hour). This yields the predicted arrival times for both the first and second candidate routes. The predicted arrival time of the first candidate route is then subtracted from the predicted arrival time of the second candidate route to obtain the arrival time difference between the two candidate routes. For instance, if the first candidate route is predicted to take 22 minutes and the second candidate route is predicted to take 35 minutes, the arrival time difference is 13 minutes.

[0076] After obtaining the arrival time difference between the first candidate route and the second candidate route, this application determines whether the arrival time difference meets the message push condition by using a preset first time difference threshold. If the arrival time difference is greater than the first time difference threshold, the first candidate route is selected as the second route, and a guaranteed delivery message containing route information, abnormal road segment information, and estimated time savings is pushed. The first time difference threshold is a basic threshold determined based on the mileage of the first candidate route and calculated using a first adjustment parameter. For example, it is shown in the following formula: First time difference threshold (T1) = base threshold (H1) × first adjustment parameter (θ1); The base threshold (H1) is determined based on the mileage of the first candidate route; the longer the mileage, the higher the base threshold (H1). For example, when the length of the first candidate route is <10 kilometers, the base threshold is 3 minutes (time savings on short-distance routes are more perceptible to users, so the threshold is set at a lower level); when the length of the first candidate route is 10 kilometers ≤ the length of the first candidate route < 50 kilometers, the base threshold is 5 minutes (medium-distance routes need to balance detour costs and time benefits, so the threshold is set at a medium level); when the length of the first candidate route is ≥ 50 kilometers, the base threshold is 10 minutes (detours on long-distance routes have a greater impact on the overall trip, so the threshold is set at a higher level).

[0077] In the message push method of this application, the first adjustment parameter (θ1) is used to dynamically optimize the first time difference threshold to ensure that the message push not only meets the actual needs of users but also accurately matches traffic conditions. In some embodiments, the first adjustment parameter is determined based on at least one of a first adjustment factor, a second adjustment factor, and a third adjustment factor.

[0078] The value of the first adjustment factor is related to the degree of impact of the time period. For example, the value of the first adjustment factor focuses on the "difference in users' time sensitivity during their commute." The greater the impact of the time period on users' travel, the lower the value of the first adjustment factor. For instance, in a work scenario, being late has a significant impact on users (e.g., attendance, meetings). The threshold can be lowered to ensure users receive timely information on avoiding congested routes, encouraging them to take alternative routes as early as possible to avoid delays. Therefore, for work commuting hours (e.g., 7:00-9:00 AM), the first adjustment factor is set to 0.8. In a home-get off work scenario, arriving home late has a relatively smaller impact on users. The threshold can be increased to reduce unnecessary message interference and balance user experience. Therefore, for home-get off work commuting hours (e.g., 5:00-7:00 PM), the first adjustment factor is set to 1.2.

[0079] The value of the second adjustment factor is related to the severity of the traffic accident. For example, the value of the second adjustment factor focuses on the severity of the traffic accident on the abnormal section of the first route; the more severe the accident (the longer the congestion lasts), the lower the value of the second adjustment factor. For instance, for severe traffic accidents (such as a truck overturning or a multi-vehicle collision, with an estimated lane occupancy time ≥ 30 minutes), since such accidents easily exacerbate congestion, users can significantly reduce time loss by taking an alternative route as early as possible, and therefore, priority should be given to pushing notifications. Therefore, the second adjustment factor is set to 0.8. For ordinary traffic accidents (such as a rear-end collision between two cars, with an estimated lane occupancy time < 10 minutes), since such accidents can be handled quickly, congestion is alleviated rapidly, and the necessity of taking an alternative route is low, the threshold can be increased to reduce the frequency of message pushes; therefore, the second adjustment factor is set to 1.2.

[0080] The value of the third adjustment factor is related to the severity of the weather. For example, the value of the third adjustment factor focuses on the "severity of weather in the area traversed by the first route." The stronger the weather's obstruction to traffic (the higher the risk of congestion), the lower the value of the third adjustment factor. For instance, for severe weather (such as heavy rain, hail, dense fog, visibility <200 meters, or slippery / icy roads), since congestion is easily exacerbated in severe weather, the threshold is lowered to encourage users to take alternative routes as early as possible. Therefore, the third adjustment factor is set to 0.8. For non-severe weather (such as sunny, cloudy, light rain), since the impact on traffic is relatively small, the third adjustment factor is set to 1 (no additional threshold adjustment is needed to maintain the basic judgment standard).

[0081] Compare the arrival time difference between the first and second candidate routes ( ) and the first time difference threshold (T1), if >T1 indicates that the message push condition is met, and the first candidate route is determined as the second route (i.e., the optimal detour route). If If the value is ≤T1, the message push condition is not met, indicating that the benefits of the current detour are insufficient to offset the cost of route switching. No guaranteed delivery message will be pushed; instead, relevant traffic conditions and candidate route information will be stored on the cloud server for users to actively query later.

[0082] Once the second route is determined, the cloud server calls the 5G messaging module to push a guaranteed message containing information about the second route to the terminal. The guaranteed message content includes at least: the starting point of the congestion on the first route, the cause of the congestion (such as an accident or construction), detour suggestions for the second route (route guidance), and the estimated time saved (time difference compared to the original route or other candidate routes), ensuring that users can quickly obtain the information they need for decision-making.

[0083] The "Driving Monitoring" scenario focuses on situations where users have entered the first route and are in the middle of their journey. After the cloud server identifies an anomaly in the first route based on the second road condition information (which integrates third-party real-time road condition update data and the terminal's current driving data), it plans candidate routes and calculates the arrival time difference through steps S401 to S403. Then, it combines the second time difference threshold to determine whether to push a message, adapting to the need for dynamic route adjustment during driving.

[0084] S401. If it is determined that the first route is abnormal based on the second road condition information, a third candidate route is planned from the current location of the terminal to the end of the first route based on the road condition data provided by the third-party data source.

[0085] Among them, the third candidate route and the first route have at least some non-overlapping sections, and the non-overlapping sections do not include the abnormal sections of the first route.

[0086] For example, after determining that the first route is abnormal based on second traffic information (such as sudden accidents or increased congestion near the terminal's current location), the cloud server, in conjunction with real-time traffic data provided by a third-party data source (including real-time traffic flow, speed, and temporary traffic control status for each road segment), plans a third candidate route, starting from the terminal's current location and ending at the first route's endpoint. This third candidate route must have at least some non-overlapping sections with the first route (e.g., if the first route is "from the middle section of the elevated road to the endpoint," the third candidate route could be adjusted to "from the next exit of the elevated road to the ground-level expressway to the endpoint"). Furthermore, all non-overlapping sections must not include any abnormal sections of the first route, ensuring that starting from the current location, users can completely avoid congested, accident-prone, or other abnormal areas, preventing situations where there is no room for adjustment after entering the area.

[0087] S402. Based on traffic data provided by a third-party data source, plan a fourth candidate route from the current location of the terminal to the starting point of the abnormal road segment, and from the starting point of the abnormal road segment to the destination.

[0088] Among them, the fourth candidate route has at least some sections that overlap with the section from the current location of the terminal to the starting point of the abnormal section, and the non-overlapping sections do not include the abnormal section.

[0089] For example, the cloud server plans a fourth candidate route based on traffic data from a third-party data source. For instance, when driving from the terminal's current location to the starting point of an abnormal section on the first route, this section overlaps with the section from the terminal's current location to the starting point of the abnormal section in the first route, reducing the user's unfamiliarity with the new route and minimizing driving distraction. Starting from the starting point of the abnormal section, a detour route to the endpoint of the first route is planned, and the detour portion (non-overlapping sections) avoids the abnormal section (e.g., turning from the elevated entrance onto "XX auxiliary road to the ground main road to the endpoint"), ensuring that it both matches the user's current driving trajectory and effectively avoids congested sections.

[0090] S403. Determine the time difference between the predicted arrival times of the third and fourth candidate routes.

[0091] For example, the cloud server first calls a multi-parameter fusion prediction model, inputting the mileage of each segment of two candidate routes provided by a third-party data source, real-time traffic speed, number of traffic lights, and historical travel time patterns under the same road conditions during the same period (such as average traffic light waiting time on surface roads during evening rush hour). Simultaneously, it combines the terminal's current driving data (real-time location, driving speed, remaining mileage, such as current speed 45km / h, distance from the abnormal road segment starting point 2 kilometers) to derive the predicted arrival times of the third and fourth candidate routes. Then, the predicted arrival time of the third candidate route is subtracted from the arrival time of the fourth candidate route to obtain the arrival time difference between the two candidate routes.

[0092] After obtaining the arrival time difference between the third and fourth candidate routes, this application determines whether the arrival time difference meets the message push condition by using a preset second time difference threshold. If the arrival time difference is greater than the second time difference threshold, the third candidate route is selected as the second route, and a guaranteed delivery message containing route information, abnormal road segment information, and estimated time savings is pushed. The second time difference threshold is calculated based on a base threshold determined by the remaining mileage of the third candidate route and a second adjustment parameter. For example, it is shown in the following formula: Second time difference threshold (T2) = base threshold (H2) × first adjustment parameter (θ2); The basic threshold (H2) is determined based on the remaining mileage of the third candidate route (the distance from the current location of the terminal to the end of the first route). The shorter the remaining mileage, the lower the basic threshold (because quick decisions are required during driving, even a small time difference with a short remaining mileage can help avoid congested sections).

[0093] In the message push method of this application, the second adjustment parameter (θ2) is used to dynamically optimize the second time difference threshold (T2) to ensure that the message push not only meets the actual needs of users, but also accurately matches the traffic conditions.

[0094] In some embodiments, the second adjustment parameter is determined based on at least one of the fourth adjustment factor, the fifth adjustment factor, the sixth adjustment factor, and the seventh adjustment factor.

[0095] The value of the fourth adjustment factor is related to the degree of influence of the time period. For example, the fourth adjustment factor corresponds to the first adjustment factor in the "pre-trip prediction" scenario, focusing on the differences in the impact on users at different times during the journey. For instance, during the morning commute (e.g., 7:00-9:00 AM), being late has a greater impact, so the value is 0.8; during the evening commute (e.g., 5:00-7:00 PM), arriving home late has a smaller impact, so the value is 1.2. For example, the value of the fourth adjustment factor can be the same as the first adjustment factor if the degree of influence of the time period is the same. For example, during the same morning commute, the value of the fourth adjustment factor and the first adjustment factor are both 0.8. In another example, the value of the fourth adjustment factor can also differ from the first adjustment factor, depending on the actual needs of the journey, even if the degree of influence of the time period is the same. For example, during the same morning commute, the value of the fourth adjustment factor is 0.6, and the value of the first adjustment factor is 0.8.

[0096] The value of the fifth adjustment factor is related to the severity level of the traffic accident. For example, the fifth adjustment factor corresponds to the second adjustment factor in the "pre-trip prediction" scenario, focusing on the severity of accidents on abnormal road sections during driving. For instance, in a severe traffic accident (such as a large truck overturning, expected to occupy the road for ≥30 minutes), the congestion lasts longer, so the value is 0.8. In a normal traffic accident (such as a car rear-end collision, expected to occupy the road for <10 minutes), the congestion eases quickly, so the value is 1.2. For example, the value of the fifth adjustment factor can be the same as the value of the second adjustment factor when the traffic accident severity level is the same. For example, when the traffic accident level is "severe," both the fifth and second adjustment factors are 0.8. In another example, the value of the fifth adjustment factor can also differ from the value of the second adjustment factor when the traffic accident severity level is the same, depending on the actual needs of the driving scenario. For example, when the traffic accident level is "severe," the fifth adjustment factor is 0.6, and the second adjustment factor is 0.8.

[0097] The value of the sixth adjustment factor is related to the severity of the weather. For example, the sixth adjustment factor corresponds to the third adjustment factor in the "pre-trip prediction" scenario, focusing on the weather impact on the areas traversed during the journey. For instance, severe weather (heavy rain, dense fog, visibility <200 meters) exacerbates congestion, so a value of 0.8 is used. Non-severe weather (sunny, light rain) has little impact on traffic, so a value of 1 is used. For example, the value of the sixth adjustment factor can be the same as the value of the third adjustment factor when the weather severity is the same. For example, when the weather severity is "severe," both the sixth and third adjustment factors are 0.8. In another example, the value of the sixth adjustment factor can also differ from the third adjustment factor when the weather severity is the same, depending on the actual needs of the driving scenario. For example, when the weather severity is "severe," the sixth adjustment factor is 0.6, and the third adjustment factor is 0.8.

[0098] The value of the seventh adjustment factor is related to driving speed. For example, based on driving safety requirements, the higher the driving speed, the greater the interference from frequent push notifications, and the higher the factor value. For instance, a value of 1 is used for driving speeds < 40 km / h (low speed driving, less distraction); a value of 1.2 is used for speeds 40 km / h ≤ driving speed < 80 km / h (medium speed driving); and a value of 1.4 is used for speeds 80 km / h ≤ driving speed (high speed driving, need to reduce push notification interference).

[0099] Compare the arrival time differences between the third and fourth candidate routes ( ) and the second time difference threshold (T2), if >T2, it is determined that the message push condition is met. At this time, the third candidate route (shortest arrival time) is the optimal detour plan, and it is determined as the second route. If If the time limit is ≤T2, the message push conditions are not met, the benefits of detour are insufficient to offset the cost of route switching during driving, no guaranteed message will be pushed, and only the road conditions and candidate route information will be stored in the cloud for users to actively query later.

[0100] After determining the second route, the cloud server calls the 5G messaging module to push a guaranteed message to the terminal. The guaranteed message includes, for example, the location of the abnormal road section of the first route (e.g., "XX Elevated Road K150 section"), the cause of the abnormality (e.g., "multi-vehicle collision and congestion"), the core guidance of the second route (third candidate route) (e.g., "turn right from the current location onto XX Auxiliary Road, go straight to XX Expressway, turn left to the destination"), the estimated time saved by the detour (e.g., "10 minutes saved compared to the original route"), and the message push timestamp (e.g., "push at 18:15"). The pop-up window only has two interactive buttons, "Route Confirm" and "Route Ignore", and a countdown control is set up. The pop-up window closes when the countdown reaches 0, thereby avoiding interference with driving operations and ensuring driving safety.

[0101] After sending a guaranteed message containing information about the second route, this application continuously adapts to dynamic scenarios through mechanisms such as "re-sending triggered by changes in traffic conditions" and "adjusting the push frequency based on user response," ensuring the timeliness of guaranteed message delivery and user experience.

[0102] In some embodiments, if a predetermined push time interval threshold has elapsed since the last push of a guaranteed message containing information related to the second route, and the change in the arrival time difference between the last push and the current calculated arrival time difference is greater than a predetermined ratio, at least two candidate routes are replanned and the updated arrival time difference is calculated.

[0103] If the updated arrival time difference meets the message push conditions, the candidate route with the shortest arrival time between at least two candidate routes will be selected as the second route, and a guaranteed message containing information about the second route will be pushed.

[0104] For example, candidate route replanning and message updates are triggered by time interval conditions and difference change conditions. Wherein: The time interval condition is that a preset push time interval threshold has elapsed since the last guaranteed message was pushed (the threshold can be dynamically adjusted according to the road segment type, such as 5 minutes for elevated / expressway and other easily congested road segments, and 10 minutes for ordinary ground road segments).

[0105] The difference change condition is that the difference in arrival time that met the push conditions last time (e.g., the original difference of 12 minutes) and the difference in arrival time that was recalculated this time (e.g., the difference after the update of 8 minutes) change by a margin greater than a preset ratio (e.g., set to ±20%, i.e., the change margin is >20% or <-20%).

[0106] When the above judgment conditions are met, the cloud server first reconnects to the third-party data source (to obtain the latest traffic conditions, such as the easing of congestion on the original abnormal road section or sudden accidents on the new road section), and plans at least two new candidate routes (to avoid the latest anomalies). Then, it calculates the arrival time difference of the new candidate routes (i.e., the updated arrival time difference) through a multi-parameter fusion prediction model. If the updated difference meets the message push condition (greater than the time difference threshold of the corresponding scenario), the new candidate route with the shortest arrival time is designated as the second route, and a guaranteed message containing the updated second route information is pushed to the terminal again.

[0107] In some embodiments, if no read or response message related to a guaranteed delivery message containing information about the second route is received within a preset period, the time difference threshold is adjusted to a first value. If a read or response message related to a guaranteed delivery message containing information about the second route is received, and the number of read or response messages is higher than a preset number, the time difference threshold is adjusted to a second value.

[0108] The time difference threshold is used to determine whether the arrival time difference meets the message push conditions. The first value is greater than the original time difference threshold, and the second value is less than the original time difference threshold. For example, the time difference threshold could be the first time difference threshold corresponding to the "pre-trip prediction" scenario, or the second time difference threshold corresponding to the "in-driving monitoring" scenario.

[0109] For example, by analyzing the message reading / response status feedback from the terminal, the time difference threshold can be dynamically adjusted to optimize the push frequency and balance information delivery and user experience. For instance, if a guaranteed message is not read by the user within a preset period (e.g., the pop-up window is not opened) or not responded to (e.g., the "Route Confirmation" is not clicked), the cloud server determines that the current time difference threshold is too low, resulting in frequent pushes or insufficient information value. The message push frequency can be reduced by increasing the time difference threshold (e.g., setting the time difference threshold to the first value).

[0110] For example, if the number of times a guaranteed message is read or responded to within a preset period is higher than the preset number (e.g., 2 or more responses within 1 hour), the cloud server determines that the current time difference threshold is reasonable and that the user has a high demand for push information. It then reduces the time difference threshold (e.g., sets the time difference threshold to the second value) to increase the message push frequency.

[0111] Furthermore, this embodiment provides a message push device applied to a cloud server, such as... Figure 7 As shown, the device includes a determination module 710, a planning module 720, and a pushing module 730. Wherein: The determination module 710 is configured to determine the road condition information of the first route; wherein the first route is predicted based on historical driving data uploaded by the terminal.

[0112] The planning module 720 is configured to plan at least two candidate routes and determine the arrival time difference between at least two candidate routes if it is determined that there is an anomaly in the first route based on the traffic information of the first route.

[0113] The push module 730 is configured to, when the arrival time difference meets the message push conditions, select the candidate route with the shortest arrival time between at least two candidate routes as the second route, and push a guaranteed message containing information related to the second route to the terminal.

[0114] In some embodiments, the determining module 710 is further configured to predict a first route based on historical driving data uploaded by the terminal.

[0115] Traffic information corresponding to the first route is extracted based on traffic data provided by a third-party data source and used as the first traffic information; among which, historical driving data includes the departure point, destination, departure time, driving trajectory and route preference of the terminal's historical records.

[0116] If the terminal is detected to be at the starting point of the first route or within the preset range of the starting point, and the direction of the terminal's movement is consistent with the planned direction of the first route, the traffic information of the first route is updated based on real-time traffic update data from a third-party data source and the current driving data, and is used as the second traffic information; wherein, the current driving data includes the real-time location, driving speed, driving acceleration and remaining mileage uploaded by the terminal.

[0117] In some embodiments, the planning module 720 is further configured to, when it is determined based on first traffic information that a first route is abnormal, plan a first candidate route from the start point to the end point of the first route according to traffic data provided by a third-party data source; the first candidate route and the first route have at least some non-overlapping road segments, and the non-overlapping road segments do not include the abnormal road segments where the first route is abnormal; and, Based on traffic data provided by a third-party data source, a second candidate route is planned from the starting point of the first route to the starting point of the abnormal road segment, and from the starting point of the abnormal road segment to the end point. At least some sections of the second candidate route overlap with the sections corresponding to the starting point of the first route to the starting point of the abnormal road segment, and the non-overlapping sections do not include the abnormal road segment.

[0118] The time difference is determined based on the predicted arrival times of the first and second candidate routes.

[0119] In some embodiments, the planning module 720 is further configured to preset a first time difference threshold. If the arrival time difference is greater than the first time difference threshold, the first candidate route is selected as the second route, and a guaranteed delivery message containing route information of the second route, abnormal road segment information, and estimated time savings is pushed. The first time difference threshold is calculated based on a base threshold determined by the mileage of the first candidate route and a first adjustment parameter.

[0120] In some embodiments, the planning module 720 is further configured to, when it is determined based on the second traffic information that the first route is abnormal, plan a third candidate route from the current location of the terminal to the end point of the first route based on traffic data provided by a third-party data source; the third candidate route and the first route have at least some non-overlapping road segments, and the non-overlapping road segments do not include the abnormal road segments where the first route is abnormal; and, Based on traffic data provided by a third-party data source, a fourth candidate route is planned from the current location of the terminal to the starting point of the abnormal road segment, and from the starting point of the abnormal road segment to the end point. At least some sections of the fourth candidate route overlap with the road segment corresponding to the starting point of the abnormal road segment from the current location of the terminal, and the non-overlapping sections do not include the abnormal road segment.

[0121] The difference in arrival time is determined based on the predicted arrival times of the third and fourth candidate routes.

[0122] In some embodiments, the planning module 720 is further configured to preset a second time difference threshold. If the arrival time difference is greater than the second time difference threshold, the third candidate route is selected as the second route, and a guaranteed delivery message containing route information, abnormal road segment information, and expected time savings of the second route is pushed. The second time difference threshold is calculated based on a basic threshold determined by the remaining mileage of the third candidate route and a second adjustment parameter.

[0123] In some embodiments, the push module 730 is further configured to replan at least two candidate routes and calculate the updated arrival time difference if a preset push time interval threshold has elapsed since the last push of a guaranteed message containing information related to the second route, and the change in the arrival time difference between the last push and the current calculated arrival time difference is greater than a preset ratio.

[0124] If the updated arrival time difference meets the message push conditions, the candidate route with the shortest arrival time between at least two candidate routes will be selected as the second route, and a guaranteed message containing information about the second route will be pushed.

[0125] In some embodiments, the push module 730 is further configured to adjust the time difference threshold to a first value if, within a preset period, no reading or response message related to the guaranteed delivery message containing information about the second route is received; the first value is greater than the time difference threshold before adjustment, and the time difference threshold is the basis for determining whether the arrival time difference meets the message push conditions.

[0126] If a read or response message related to a guaranteed delivery message containing information about the second route is received, and the number of read or response messages is higher than the preset number, the time difference threshold will be adjusted to the second value; the second value will be less than the time difference threshold before adjustment.

[0127] Furthermore, this embodiment provides a message push device applied to a terminal, such as... Figure 8 As shown, the device includes a receiving module 810 and a display module 820. Wherein: The receiving module 810 is configured to receive a guaranteed message containing information related to the second route sent by the cloud server; the second route is determined based on the candidate route with the shortest arrival time among at least two candidate routes, provided that the arrival time difference between at least two candidate routes meets the message push conditions; the at least two candidate routes are planned based on the road condition information of the first route, which indicates that the first route is abnormal.

[0128] Display module 820 is configured to display a guaranteed delivery message pop-up based on a guaranteed delivery message containing information related to the second route.

[0129] It should be noted that other corresponding descriptions of the functional units involved in the message push device provided in this embodiment can be found in the description of the message push method in the above embodiments, and will not be repeated here.

[0130] Based on the message push method shown in the above embodiments, this embodiment also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the method shown in the above embodiments.

[0131] Based on the methods shown in the above embodiments, this embodiment also provides a computer program product on which a computer program is stored, and when the computer program product is executed by a processor, it implements the methods shown in the above embodiments.

[0132] Based on this understanding, the technical solution of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, mobile hard drive, etc.). The storage medium includes several instructions to cause a computer device (such as a personal computer, server, or network device, etc.) to execute the methods of the various embodiments of this application.

[0133] The storage medium may also include an operating system and a network communication module. The operating system is a program that manages the hardware and software resources of the aforementioned physical device, supporting the operation of information processing programs and other software and / or programs. The network communication module is used to enable communication between the various components within the storage medium, as well as communication with other hardware and software in the information processing physical device.

[0134] Based on the method shown in the above embodiments, and Figure 7 , Figure 8 To achieve the above objectives, as illustrated in the virtual device embodiment, this application also provides an electronic device. This electronic device includes a storage medium and a processor; the storage medium stores a computer program; the processor executes the computer program to implement the method shown in the above embodiment.

[0135] Optionally, the aforementioned electronic device may also include a user interface, a network interface, a camera, radio frequency (RF) circuitry, sensors, audio circuitry, a Wi-Fi module, etc. The user interface may include a display screen, input units such as a keyboard, etc., and optionally, a USB interface, a card reader interface, etc. Optionally, the network interface may include standard wired interfaces, wireless interfaces (such as Wi-Fi interfaces), etc.

[0136] Those skilled in the art will understand that the physical device structure provided in this embodiment does not constitute a limitation on the physical device, and may include more or fewer components, or combine certain components, or have different component arrangements.

[0137] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented using software plus necessary general-purpose hardware platforms, or it can be implemented using hardware. Compared with the current related technologies, this application can actively determine the traffic information of the user's frequently used route (first route) through a cloud server. When an anomaly is detected in the first route, at least two candidate routes to avoid the abnormal road segment are planned and the arrival time difference is calculated. Only when the difference meets the push condition is the optimal route (second route) pushed to the terminal with a guaranteed delivery message containing key information. This solution breaks through the limitation of existing electronic maps that rely on users to actively turn on navigation to provide congestion avoidance services. Even if the user does not turn on navigation, it can accurately obtain abnormal traffic conditions and optimal detour solutions for frequently used routes, effectively avoiding travel delays caused by not detecting congestion in time or missing congestion avoidance nodes (such as elevated roads without intersections), and significantly improving travel efficiency and user experience.

[0138] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, 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, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0139] The above description is merely a specific embodiment of this application, enabling those skilled in the art to understand or implement this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments described herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A message push method, characterized in that, Applied to cloud servers, including: Determine the road condition information for the first route; wherein the first route is predicted based on historical driving data uploaded by the terminal; If it is determined that there is an anomaly in the first route based on the road condition information of the first route, at least two candidate routes are planned, and the arrival time difference between the at least two candidate routes is determined. If the arrival time difference meets the message push condition, the candidate route with the shortest arrival time between at least two candidate routes will be selected as the second route, and a guaranteed message containing information related to the second route will be pushed to the terminal.

2. The method according to claim 1, characterized in that, The road condition information for the first route includes the first road condition information determined before traveling the first route; And the second road condition information determined during the journey along the first route; The road condition information for determining the first route includes: If the difference between the current time and the predicted start time of the first route is less than a preset judgment threshold, the traffic information of the first route is extracted based on the traffic data provided by a third-party data source and used as the first traffic information. If the terminal is detected to be at the starting point of the first route or within a preset range of the starting point, and the direction of the terminal's movement is consistent with the planned direction of the first route, the traffic information of the first route is updated based on the real-time traffic update data from the third-party data source and the current driving data, and is used as the second traffic information.

3. The method according to claim 2, characterized in that, The step of planning at least two candidate routes and determining the arrival time difference between at least two candidate routes when it is determined that the first route has an anomaly based on the road condition information of the first route includes: If, based on the first traffic information, it is determined that the first route is abnormal, a first candidate route is planned from the start point to the end point of the first route according to traffic data provided by the third-party data source; the first candidate route and the first route have at least some non-overlapping road segments, and the non-overlapping road segments do not include the abnormal road segments where the first route is abnormal; and, Based on the traffic data provided by the third-party data source, a second candidate route is planned from the starting point of the first route to the starting point of the abnormal road segment, and from the starting point of the abnormal road segment to the end point; at least some sections of the second candidate route overlap with the sections corresponding to the starting point of the first route to the starting point of the abnormal road segment, and the non-overlapping sections do not include the abnormal road segment; The arrival time difference is determined based on the predicted arrival times of the first candidate route and the second candidate route.

4. The method according to claim 3, characterized in that, When the arrival time difference meets the message push condition, the candidate route with the shortest arrival time between at least two candidate routes is selected as the second route, and a guaranteed message containing information related to the second route is pushed, including: A first time difference threshold is preset. If the arrival time difference is greater than the first time difference threshold, the first candidate route is used as the second route, and a guaranteed delivery message containing the route information of the second route, abnormal road segment information, and expected time savings is pushed. The first time difference threshold is calculated based on a basic threshold determined by the mileage of the first candidate route and a first adjustment parameter.

5. The method according to claim 4, characterized in that, The first adjustment parameter is determined based on at least one of a first adjustment factor, a second adjustment factor, and a third adjustment factor; The value of the first adjustment factor is related to the degree of influence over the time period; The value of the second adjustment factor is related to the severity level of the traffic accident; The value of the third adjustment factor is related to the severity of the weather.

6. The method according to claim 2, characterized in that, The step of planning at least two candidate routes and determining the arrival time difference between at least two candidate routes when it is determined that the first route has an anomaly based on the road condition information of the first route includes: If, based on the second traffic information, it is determined that the first route is abnormal, a third candidate route is planned from the terminal's current location to the end of the first route based on traffic data provided by the third-party data source; the third candidate route has at least some non-overlapping sections with the first route, and the non-overlapping sections do not include the abnormal sections where the first route is abnormal; and... Based on the traffic data provided by the third-party data source, a fourth candidate route is planned from the current location of the terminal to the starting point of the abnormal road segment, and from the starting point of the abnormal road segment to the end point; the fourth candidate route has at least some road segments that overlap with the road segments corresponding to the current location of the terminal to the starting point of the abnormal road segment, and the non-overlapping road segments do not include the abnormal road segment; The arrival time difference is determined based on the predicted arrival times of the third candidate route and the fourth candidate route.

7. The method according to claim 6, characterized in that, When the arrival time difference meets the message push condition, the candidate route with the shortest arrival time between at least two candidate routes is selected as the second route, and a guaranteed message containing information related to the second route is pushed, including: A second time difference threshold is preset. If the arrival time difference is greater than the second time difference threshold, the third candidate route is selected as the second route, and a guaranteed delivery message containing the route information of the second route, abnormal road segment information, and expected time savings is pushed. The second time difference threshold is calculated based on the basic threshold determined by the remaining mileage of the third candidate route and the second adjustment parameter.

8. The method according to claim 7, characterized in that, The second adjustment parameter is determined based on at least one of the fourth adjustment factor, the fifth adjustment factor, the sixth adjustment factor, and the seventh adjustment factor; The value of the fourth adjustment factor is related to the degree of influence over the time period; The value of the fifth adjustment factor is related to the severity level of the traffic accident; The value of the sixth adjustment factor is related to the severity of the weather. The value of the seventh adjustment factor is related to the driving speed.

9. The method according to any one of claims 1 to 8, characterized in that, After pushing the guaranteed delivery message containing the second route information to the terminal, the method further includes: If a predetermined push time interval threshold has elapsed since the last push of a guaranteed message containing information related to the second route, and the change in the arrival time difference between the last push and the current calculated arrival time difference is greater than a predetermined ratio, at least two candidate routes will be replanned and the updated arrival time difference will be calculated. If the updated arrival time difference meets the message push conditions, the candidate route with the shortest arrival time between at least two candidate routes will be selected as the second route, and a guaranteed message containing information related to the second route will be pushed.

10. The method according to any one of claims 1 to 8, characterized in that, The method further includes: If no read or response message related to the guaranteed message containing information about the second route is received within a preset period, the time difference threshold is adjusted to a first value; the first value is greater than the time difference threshold before adjustment, and the time difference threshold is the basis for determining whether the arrival time difference meets the message push conditions. If a read or response message related to a guaranteed delivery message containing information about the second route is received, and the number of read or response messages is higher than a preset number, then the time difference threshold is adjusted to a second value; the second value is less than the time difference threshold before adjustment.

11. A message push method, characterized in that, Applied to terminals, including: Receive a guaranteed delivery message containing information about the second route sent by the cloud server; the second route is determined based on the candidate route with the shortest arrival time between at least two candidate routes, provided that the arrival time difference between at least two candidate routes meets the message push conditions, and the at least two candidate routes are planned when it is determined that the first route has an anomaly based on the traffic information of the first route. Based on the guaranteed delivery message containing information related to the second route, a guaranteed delivery message pop-up window is displayed.

12. The method according to claim 11, characterized in that, The content displayed in the guaranteed delivery message pop-up includes at least one of the following: route information of the second route, abnormal road segment information, estimated time saved, route confirmation interaction option, and route ignore interaction option.

13. A message push device, characterized in that, include: The determination module is configured to determine the road condition information of a first route; wherein the first route is predicted based on historical driving data uploaded by the terminal. The planning module is configured to plan at least two candidate routes and determine the arrival time difference between at least two candidate routes if it is determined that there is an anomaly in the first route based on the traffic information of the first route. The push module is configured to, when the arrival time difference meets the message push condition, select the candidate route with the shortest arrival time between at least two candidate routes as the second route, and push a guaranteed message containing information related to the second route to the terminal.

14. A message push device, characterized in that, include: The receiving module is configured to receive a guaranteed message containing information related to the second route sent by the cloud server; The second route is determined based on the candidate route with the shortest arrival time among at least two candidate routes, provided that the arrival time difference between at least two candidate routes meets the message push conditions. The at least two candidate routes are planned when it is determined that the first route has an anomaly based on the traffic information of the first route. The display module is configured to display a guaranteed delivery message pop-up based on the guaranteed delivery message containing information related to the second route.

15. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 10 or the method of any one of claims 11 to 12.

16. An electronic device comprising a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method of any one of claims 1 to 10 or the method of any one of claims 11 to 12.

Images