Multi-platform message management system, method and device
By using a multi-platform message management system and leveraging the unified configuration of the microservice cluster module and message management module, the differences in message push formats and mechanisms across different mobile platforms and vendor systems have been resolved, resulting in cost reduction and efficiency improvement.
Patent Information
- Application Number
- CN202511734729.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-11-24
- Publication Date
- 2026-02-24
AI Technical Summary
Due to the diverse development of different mobile platforms and systems from different manufacturers, the formats, permissions, and mechanisms of message pushes vary, increasing development costs.
A multi-platform message management system is adopted, including a microservice cluster module, a message management module, and a backend operation and maintenance module. The backend operation and maintenance module uniformly configures message sending rules to adapt to different mobile platforms and vendor systems, while the message management module performs unified processing according to the rules.
It reduced development costs and improved the efficiency of push message processing.
Smart Images
Figure CN121567672A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of message management technology, and in particular to a multi-platform message management system, method and apparatus. Background Technology
[0002] In related technologies, with the development of mobile Internet technology, application message push and SMS notification have become important means for service providers to communicate with users. In TSP (Telematics Service Provider) systems, there are also scenarios where users are notified of vehicle-related information through application messages or SMS, such as electronic fence triggering or scheduled charging reminders.
[0003] On the other hand, mobile terminals have different requirements for message push formats, permissions, or mechanisms due to the diverse development of different mobile platforms and different manufacturers' systems, resulting in high development costs.
[0004] In summary, the technical problems existing in the relevant technologies need to be improved. Summary of the Invention
[0005] The main objective of this application is to propose a multi-platform message management system, method, and apparatus, which aims to reduce development costs and improve the processing efficiency of push messages.
[0006] To achieve the above objectives, one aspect of this application proposes a multi-platform message management system, the system comprising: a microservice cluster module, a message management module, and a backend operation and maintenance module; The microservice cluster module is configured with a variety of microservices and message triggering conditions for the microservices; the microservice cluster module is used to obtain vehicle status data uploaded by the vehicle TBOX, determine whether to trigger the microservice based on the vehicle status data and the message triggering conditions, and send a message request to the message management module when the microservice is triggered. The message management module is configured with message sending rules; the message management module is used to receive the message request, generate a push message according to the message request, and send the push message to the corresponding receiving end; in the process of generating the push message, it is also used to perform unified processing on the push message according to the message sending rules; The background operation and maintenance module is used to configure and manage the message triggering conditions and the message sending rules.
[0007] In some embodiments, the message management module is further configured to record the user's login status; when sending the push message, the module determines the target receiving end of the corresponding user based on the user's login status and sends the push message to the target receiving end.
[0008] In some embodiments, the message sending rules include a message reporting protocol, and the message management module is used to uniformly encapsulate and forward the push message generated corresponding to the message request according to the message reporting protocol.
[0009] In some embodiments, the message sending rules include a message delivery protocol, and the message management module is used to perform adaptation processing on the push message according to the message delivery protocol. The adaptation processing includes adapting to different mobile platforms and different mobile terminal manufacturer systems.
[0010] In some embodiments, the receiving end includes at least a mobile terminal application, an SMS server, and an in-vehicle terminal application.
[0011] To achieve the above objectives, another aspect of this application proposes a multi-platform message management method, the method comprising: The message triggering conditions for microservices are pre-configured in the microservice cluster module through the backend operation and maintenance module, and the message sending rules are pre-configured in the message management module. The microservice cluster module obtains vehicle status data, determines whether to trigger a microservice based on the vehicle status data and the message triggering conditions, and sends a message request to the message management module when the microservice is triggered. The message management module receives the message request, generates a push message based on the message request, and sends the push message to the corresponding receiving end. During the generation of the push message, the push message is also processed uniformly according to the message sending rules.
[0012] In some embodiments, before obtaining vehicle status data and determining whether to trigger the microservice based on the vehicle status data and the message triggering condition, the method further includes: The message management module receives user login requests; upon successful login, it records the corresponding user's login status, which is associated with a login expiration date; upon the expiration date, it cancels the user's login status.
[0013] In some embodiments, sending the push message to the corresponding receiving end includes: In response to the fact that the login validity period has not expired at the current time, the mobile terminal application is determined as the target receiving end, and the push message is sent to the target receiving end.
[0014] In some embodiments, sending the push message to the corresponding receiving end includes: In response to the current login expiration, the SMS server is identified as the target receiver, and the push message is sent to the target receiver.
[0015] To achieve the above objectives, another aspect of the present application provides a computer device, the device including a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the method described above.
[0016] The embodiments of this application include at least the following beneficial effects: This application provides a multi-platform message management system, method, and apparatus. The multi-platform message management system includes a microservice cluster module, a message management module, and a backend operation and maintenance module. The microservice cluster module is configured with various microservices and message triggering conditions for each microservice. It is used to determine whether to trigger a microservice based on vehicle status data uploaded by the vehicle's TBOX and the message triggering conditions, and to control the sending of message requests to the message management module when triggered. The message management module is configured with message sending rules, used to generate push messages based on the message request. During the generation process, it performs unified processing according to the message sending rules, and then sends the processed push message to the corresponding receiving end. The backend operation and maintenance module is used to configure and manage the message triggering conditions and message sending rules on the other two modules. Compared with the need to develop separate message push solutions adapted to different mobile platforms and different vendor systems, the method of this application uniformly configures message sending rules that can adapt to different mobile platforms and different vendor systems through the backend operation and maintenance module. Based on this, the message management module can uniformly process push messages that need to be sent to different mobile platforms and different vendor systems according to the message sending rules in the same process, reducing development costs and improving the processing efficiency of push messages. Attached Figure Description
[0017] Figure 1 This is a structural diagram of a multi-platform message management system provided in an embodiment of this application; Figure 2 This is a flowchart of a multi-platform message management method provided in an embodiment of this application; Figure 3 This is a flowchart of another embodiment of a multi-platform message management method provided in this application; Figure 4 This is a schematic diagram of the hardware structure of the computer device provided in the embodiments of this application. Detailed Implementation
[0018] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit it. In the following description, when referring to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with those of this application; they are merely examples of apparatuses and methods consistent with some aspects of the embodiments of this application as detailed in the appended claims.
[0019] It is understood that the terms “first,” “second,” etc., used in this application may be used herein to describe various concepts, but unless otherwise stated, these concepts are not limited by these terms. These terms are only used to distinguish one concept from another. For example, without departing from the scope of the embodiments of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the words “if,” “when,” or “in response to a determination” as used herein may be interpreted as “when…” or “when…” or “in response to a determination.”
[0020] As used in this application, the terms "at least one", "multiple", "each", "any", etc., "at least one" includes one, two or more, "multiple" includes two or more, "each" refers to each of the corresponding multiples, and "any" refers to any one of the multiples.
[0021] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.
[0022] In related technologies, with the development of mobile Internet technology, application message push and SMS notification have become important means for service providers to communicate with users. In TSP (Telematics Service Provider) systems, there are also scenarios where users are notified of vehicle-related information through application messages or SMS, such as electronic fence triggering or scheduled charging reminders.
[0023] On the other hand, mobile terminals have different requirements for message push formats, permissions, or mechanisms due to the diverse development of different mobile platforms and different manufacturers' systems, resulting in high development costs.
[0024] In view of this, this application provides a multi-platform message management system, method, and apparatus. The multi-platform message management system includes a microservice cluster module 100, a message management module 200, and a backend operation and maintenance module 300. The microservice cluster module 100 is configured with various microservices and message triggering conditions for each microservice. It is used to determine whether to trigger a microservice based on vehicle status data uploaded from the vehicle's TBOX and the message triggering conditions, and to control the sending of message requests to the message management module 200 when triggered. The message management module 200 is configured with message sending rules, used to generate push messages based on the message request. During the generation process, the push messages are uniformly processed according to the message sending rules, and then sent to the corresponding receiving end. The backend operation and maintenance module 300 is used to configure and manage the message triggering conditions and message sending rules on the other two modules. Compared to the need to develop separate message push solutions for different mobile platforms and different vendor systems, the method in this application uses the backend operation and maintenance module 300 to uniformly configure message sending rules that can adapt to different mobile platforms and different vendor systems. Based on this, the message management module 200 can uniformly process push messages that need to be sent to different mobile platforms and different vendor systems according to the message sending rules in the same process, reducing development costs and improving the processing efficiency of push messages.
[0025] The multi-platform message management system, method, and apparatus provided in this application relate to the field of message management technology. The multi-platform message management method provided in this application can be applied to a terminal, a server, or software running on a terminal or server. In some embodiments, the terminal can be a smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, or in-vehicle terminal, but is not limited to these. The server can be configured as an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The server can also be a node server in a blockchain network. The software can be an application implementing the multi-platform message management method, but is not limited to the above forms.
[0026] This application can be used in a wide variety of general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices. This application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. This application 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.
[0027] Figure 1 This is an optional structural diagram of the multi-platform message management system provided in the embodiments of this application. Figure 1 The system may include, but is not limited to: microservice cluster module 100, message management module 200, and backend operation and maintenance module 300; The microservice cluster module 100 is configured with a variety of microservices and message triggering conditions for microservices; the microservice cluster module 100 is used to obtain vehicle status data uploaded by the vehicle TBOX, determine whether to trigger a microservice based on the vehicle status data and message triggering conditions, and send a message request to the message management module 200 when a microservice is triggered. The message management module 200 is configured with message sending rules; the message management module 200 is used to receive message requests, generate push messages according to the message requests, and send the push messages to the corresponding receiving end; in the process of generating push messages, it is also used to uniformly process push messages according to message sending rules; The backend operation and maintenance module 300 is used to configure and manage message triggering conditions and message sending rules.
[0028] To accommodate the requirements of different receivers, this embodiment manages the microservice cluster module 100 and the message management module 200 through a backend operation and maintenance module 300. The module configures the message triggering conditions for microservices on the microservice cluster module 100 and the message sending rules on the message management module 200. The message sending rules include processing rules for encapsulation, forwarding, and distribution channels to adapt to the requirements of different receivers. When a push message is sent based on a message request, the system can intelligently determine the target sending channel and select the appropriate message sending rules based on the target channel, thereby unifying the processing flow for push messages from different types of receivers.
[0029] On the other hand, the microservices on the microservice cluster module 100 include services such as E-CALL, maintenance configuration, electronic fence, alarm service, and remote service. These microservices share the common feature of needing to notify users based on service progress or results. Therefore, when a microservice is triggered, a corresponding message request is generated to request the sending of a push message to the user's receiving end, achieving the purpose of notifying the user. The determination of whether a microservice is triggered is achieved by obtaining vehicle status data uploaded from the vehicle's TBOX and comparing this data with the message triggering conditions. This vehicle status data includes data that meets the judgment requirements of various microservices; in this embodiment, the specific data type is not limited.
[0030] Regarding the message management module 200, it includes a message assembly unit, a Kafka unit, and a message delivery unit. The message assembly unit is used to assemble and generate preliminary push messages based on message requests. The Kafka unit is used to support the message management module 200 in performing distributed stream processing, enabling the message management module 200 to handle multiple message push services simultaneously. The message delivery unit is used to specifically control the sending operation of push messages.
[0031] In this embodiment, the backend operation and maintenance module 300 is configured to uniformly adapt to message sending rules of different mobile platforms and different manufacturers' systems. Based on this, the message management module 200 can uniformly process push messages that need to be sent to different mobile platforms and different manufacturers' systems according to the message sending rules in the same process, reducing development costs and improving the processing efficiency of push messages.
[0032] For ease of understanding, this application provides embodiments that combine system and method examples. Based on the above embodiments, this invention also provides a multi-platform message management method. Figure 2 This is an optional flowchart for a multi-platform message management method. Figure 2 The method may include, but is not limited to, steps S101 to S103.
[0033] Step S101: The backend operation and maintenance module 300 pre-configures the message triggering conditions of the microservice in the microservice cluster module 100 and pre-configures the message sending rules in the message management module 200. Step S102: Obtain vehicle status data through microservice cluster module 100, determine whether to trigger microservice based on vehicle status data and message triggering conditions, and send a message request to message management module 200 when microservice is triggered. Step S103: Message requests are received through the message management module 200, push messages are generated based on the message requests, and the push messages are sent to the corresponding receiving end. During the generation of push messages, the push messages are also processed uniformly according to the message sending rules.
[0034] In terms of the processing flow, before implementing the message push service, the backend operation and maintenance module 300 pre-configures message triggering conditions in the microservice cluster module 100 and message sending rules in the message management module 200; the specific content of the message triggering conditions and message sending rules are all pre-set by the staff. Then, after the message push service is put into use, the microservice cluster module 100 first determines whether to trigger the microservice and whether a message request needs to be sent based on the vehicle status data and message triggering conditions; the message management module 200 is triggered by the received message request, generates and processes the push message, and finally sends the push message processed according to the message sending rules to the corresponding receiving end, completing the message push service.
[0035] It is understood that the content of this method embodiment is applied to the above system embodiment, and the specific functions implemented by this method embodiment are the same as those of the above system embodiment, and the beneficial effects achieved are also the same as those achieved by the above system embodiment.
[0036] In some embodiments, the receiving end includes at least a mobile terminal application, an SMS server, and an in-vehicle terminal application.
[0037] Regarding the receiving end, it includes at least mobile terminal applications, SMS servers, and in-vehicle applications, representing three different channels through which users may receive push messages; determining the corresponding receiving end in step S103 is actually determining the sending channel. In other embodiments, other types of channels, i.e., receiving ends, may also be included. For example, in a scenario where the user is in their own home, the receiving end may also be a smart home terminal within that home environment.
[0038] Furthermore, the mobile terminal application aspect also includes the adaptation issues of different mobile platforms and different manufacturer systems mentioned above. Mobile platforms include Android and iOS systems, while manufacturer systems include various systems developed by different mobile terminal manufacturers based on Android. When it is determined that a message will be sent to a mobile terminal application, the mobile platform and manufacturer system of the user's mobile terminal are also determined simultaneously, and adaptation processing is performed according to the message sending rules. This ensures that even if the mobile platform and manufacturer system of the user's mobile terminal are different, the push message can still be accurately sent to the mobile terminal application.
[0039] In some embodiments, the message management module 200 is also used to record the user's login status; when sending a push message, it determines the target receiving end of the corresponding user based on the user's login status and sends the push message to the target receiving end.
[0040] To improve the reach of push messages to users, user login status can be utilized. Specifically, when users use various microservices or the push message service of this embodiment, they may have performed a user login operation in the corresponding terminal application. If they successfully register and log in, the user's account and login status will be synchronized to the message management module 200 for registration and recorded as the user login status. The user login status represents the user's usage habits for the corresponding channel, and therefore can be used to determine the actual target receiving end, defined as the target receiving end, and the push message will be sent to the target receiving end.
[0041] In some embodiments, prior to step S102, the method further includes: The message management module 200 receives user login requests; upon successful login, it records the corresponding user's login status, which is associated with a login expiration time; upon the expiration of the login expiration time, it logs out the user's login status.
[0042] Regarding user login status, when the message management module 200 receives a user login request, it verifies the user's login operation. If the verification is successful, the user login request is approved, the user is confirmed to be logged in, and the user's login status is recorded. Simultaneously, a login expiration period is set for the user's login status, which can be set to, for example, 7 days or 15 days. Within the login expiration period, the user does not need to request login again each time they use the relevant service; instead, the user's login status is temporarily saved, and this login expiration period is refreshed each time the user uses the relevant service (equivalent to a login action). When the login expiration period expires, i.e., after the set time of 7 days or 15 days, the user's login status is cancelled to prevent the module's cache resources from being occupied.
[0043] In step S103 of some embodiments, sending the push message to the corresponding receiving end includes: If the login validity period has not expired at the current time, and the mobile terminal application is identified as the target receiving end, the push message will be sent to the target receiving end.
[0044] Optionally, for both mobile terminal applications and SMS servers, sending push messages via SMS incurs higher message transmission costs. Therefore, when both channels are optional, it is preferable to send push messages to the mobile terminal application first.
[0045] When the push notification service is triggered, if the user's login validity period has not expired, it means that the user is currently or recently using a mobile terminal application. Therefore, the mobile terminal application is selected as the target receiving end, and the push message is sent to the mobile terminal application to save message transmission costs.
[0046] In step S103 of some embodiments, sending the push message to the corresponding receiving end includes: In response to the current login expiration, the SMS server is identified as the target recipient, and a push message is sent to the target recipient.
[0047] Optionally, if a user's login validity period has expired, meaning the user has not used the mobile terminal application for a period of time, then the SMS server is selected as the target receiving end, and the push message is sent to the SMS server to improve the user reach rate of the push message.
[0048] In some embodiments, the message sending rules include a message reporting protocol, and the message management module 200 is used to uniformly encapsulate and forward the push messages generated corresponding to the message requests according to the message reporting protocol.
[0049] Specifically, in the processing of push messages, both message encapsulation and forwarding are handled according to the message reporting protocol. The message reporting protocol does not concern itself with the target recipient of the push message; regardless of the recipient, in this embodiment, the message is encapsulated in a uniform format and the same forwarding steps are performed. This is achieved through the defined message reporting protocol, thereby standardizing the push message processing flow for various microservices and channels.
[0050] In some embodiments, the message sending rules include a message delivery protocol, and the message management module 200 is used to perform adaptation processing on the push message according to the message delivery protocol. The adaptation processing includes adapting to different mobile platforms and different mobile terminal manufacturer systems.
[0051] On the other hand, in addition to the aforementioned message reporting protocol, a message delivery protocol is also established. This protocol adapts to various potential recipients of push messages, including mobile terminal applications, SMS servers, in-vehicle applications, and different mobile platforms and systems from different mobile terminal manufacturers. By combining the adaptation processing of the message delivery protocol, the processing flow specified by the aforementioned message reporting protocol can be truly applied to various differentiated recipients, saving development costs for push message services.
[0052] The following is a detailed description and explanation of the solutions in the embodiments of the present invention, using specific application examples: This application provides a multi-platform message management system, method, and apparatus, which are applied to the message management and push service of a TSP system. The multi-platform message management system includes a microservice cluster module 100, a message management module 200, and a backend operation and maintenance module 300.
[0053] refer to Figure 3 , Figure 3 This is a flowchart of another embodiment of the multi-platform message management method.
[0054] First, the message triggering conditions for the microservices are pre-configured in the microservice cluster module 100 through the backend operation and maintenance module 300, and the message sending rules are pre-configured in the message management module 200.
[0055] When the multi-platform message management system puts the message push service into operation, it receives user login requests through the message management module 200. When a user login request is approved, the system records the corresponding user's login status and determines its associated login expiration time. When the login expiration time expires, the user's login status is cancelled.
[0056] The microservice cluster module 100 obtains vehicle status data, determines whether to trigger a microservice based on the vehicle status data and message triggering conditions, and sends a message request to the message management module 200 when the microservice is triggered.
[0057] The message management module 200 receives message requests and generates push messages based on these requests. During message generation, the message is uniformly encapsulated and forwarded according to the message reporting protocol in the message sending rules. Simultaneously, the login validity period of the user is confirmed. If the current login validity period is still valid, the mobile terminal application is identified as the target receiving end; if the current login validity period has expired, the SMS server is identified as the target receiving end. Based on the identified target receiving end, adaptation processing is performed according to the message delivery protocol in the message sending rules. This adaptation processing includes adapting to different receiving ends of the mobile terminal application, SMS server, and vehicle-mounted application, as well as different mobile platforms and different mobile terminal manufacturer systems. After the above processing, the push message can be sent to the target receiving end.
[0058] In this embodiment, the backend operation and maintenance module 300 is configured to uniformly adapt to message sending rules of different mobile platforms and different manufacturers' systems. Based on this, the message management module 200 can uniformly process push messages that need to be sent to different mobile platforms and different manufacturers' systems according to the message sending rules in the same process, reducing development costs and improving the processing efficiency of push messages.
[0059] Reference Figure 4The present invention also provides a computer device, including a memory, a processor, and a program stored in the memory and executable on the processor, wherein the program, when executed by the processor, implements the methods described in the above embodiments.
[0060] Taking the example of a processor and memory in a computer device being connected via a bus, memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the control processor, and these remote memories can be connected to the control device via a network.
[0061] The non-transient software program and instructions required to implement the control method of the above embodiments are stored in memory. When executed by a processor, the control method of the above embodiments is executed. For example, executing... Figure 2 The method steps S100 to S103 are described above. It is understood that the content of the above method embodiments is applicable to this device, and the specific functions implemented in this device embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.
[0062] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.
[0063] This application provides a multi-platform message management system, method, and apparatus. The multi-platform message management system includes a microservice cluster module, a message management module, and a backend operation and maintenance module. The microservice cluster module is configured with various microservices and message triggering conditions for each microservice. It determines whether to trigger a microservice based on vehicle status data uploaded from the vehicle's TBOX and the message triggering conditions, and controls the sending of message requests to the message management module upon triggering. The message management module is configured with message sending rules to generate push messages based on the message request. During the generation process, it performs unified processing according to the message sending rules and then sends the processed push message to the corresponding receiving end. The backend operation and maintenance module configures and manages the message triggering conditions and message sending rules on the other two modules. Compared to developing separate message push solutions adapted to different mobile platforms and different vendor systems, this application's method uses a backend operation and maintenance module to uniformly configure message sending rules adaptable to different mobile platforms and different vendor systems. Based on this, the message management module can uniformly process push messages sent to different mobile platforms and different vendor systems according to the message sending rules using the same process, reducing development costs and improving the processing efficiency of push messages.
[0064] The embodiments described in this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.
[0065] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this application, and may include more or fewer steps than shown, or combine certain steps, or different steps.
[0066] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.
[0067] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.
[0068] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.
[0069] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.
[0070] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of the units described above is only a logical functional division, and 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; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.
[0071] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0072] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.
[0073] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes multiple instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0074] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.
Claims
1. A multi-platform message management system, characterized in that, The system includes: a microservice cluster module, a message management module, and a backend operation and maintenance module; The microservice cluster module is configured with a variety of microservices and message triggering conditions for the microservices; the microservice cluster module is used to obtain vehicle status data uploaded by the vehicle TBOX, determine whether to trigger the microservice based on the vehicle status data and the message triggering conditions, and send a message request to the message management module when the microservice is triggered. The message management module is configured with message sending rules; the message management module is used to receive the message request, generate a push message according to the message request, and send the push message to the corresponding receiving end; in the process of generating the push message, it is also used to perform unified processing on the push message according to the message sending rules; The background operation and maintenance module is used to configure and manage the message triggering conditions and the message sending rules.
2. The system according to claim 1, characterized in that, The message management module is also used to record the user's login status; when sending the push message, it determines the target receiving end of the corresponding user based on the user's login status and sends the push message to the target receiving end.
3. The system according to claim 1, characterized in that, The message sending rules include a message reporting protocol, and the message management module is used to uniformly encapsulate and forward the push messages generated corresponding to the message requests according to the message reporting protocol.
4. The system according to claim 1, characterized in that, The message sending rules include a message delivery protocol. The message management module is used to adapt the push message according to the message delivery protocol. The adaptation process includes adapting to different mobile platforms and different mobile terminal manufacturer systems.
5. The system according to claim 1, characterized in that, The receiving end includes at least a mobile terminal application, an SMS server, and an in-vehicle terminal application.
6. A multi-platform message management method, applied to the multi-platform message management system according to any one of claims 1 to 5, characterized in that, The method includes: The message triggering conditions for microservices are pre-configured in the microservice cluster module through the backend operation and maintenance module, and the message sending rules are pre-configured in the message management module. The microservice cluster module obtains vehicle status data, determines whether to trigger a microservice based on the vehicle status data and the message triggering conditions, and sends a message request to the message management module when the microservice is triggered. The message management module receives the message request, generates a push message based on the message request, and sends the push message to the corresponding receiving end. During the generation of the push message, the push message is also processed uniformly according to the message sending rules.
7. The method according to claim 6, characterized in that, Before obtaining vehicle status data and determining whether to trigger the microservice based on the vehicle status data and the message triggering condition, the process further includes: The message management module receives user login requests; upon successful login, it records the corresponding user's login status, which is associated with a login expiration date; upon the expiration date, it cancels the user's login status.
8. The method according to claim 7, characterized in that, Sending the push message to the corresponding receiving end includes: In response to the fact that the login validity period has not expired at the current time, the mobile terminal application is determined as the target receiving end, and the push message is sent to the target receiving end.
9. The method according to claim 7, characterized in that, Sending the push message to the corresponding receiving end includes: In response to the current login expiration, the SMS server is identified as the target receiver, and the push message is sent to the target receiver.
10. A computer device, characterized in that, The computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the method of any one of claims 6 to 9.