Information processing method and device, electronic equipment and computer readable storage medium

Abstract

The information processing method, device, electronic equipment and computer readable storage medium, one embodiment of the present application provides an information processing method, comprising: obtaining a plurality of login accounts in a first application respectively generated business event message; in response to a preset trigger operation for the first application or detecting that the business event message meets the preset reminding condition, displaying an aggregation panel, and respectively displaying the business event message from the plurality of login accounts in the aggregation panel; in response to a trigger operation for a target business event message in the aggregation panel, triggering the first application to switch to a target account corresponding to the target business event message, and opening a function module interface corresponding to the type of the target business event message.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to information processing methods, apparatus, electronic devices, and computer-readable storage media. Background Technology

[0002] In client-side applications of related technologies, to facilitate user management of multiple registered identities, it is typically supported to log in to multiple accounts concurrently within the same application instance. When the application is running in the background or obscured by other interfaces, the system generally outputs status prompts through a single entry point in the operating system notification area. Users need to manually launch the application interface and switch to the corresponding account tab within it to view the specific message content.

[0003] However, in client applications that support concurrent login of multiple accounts, the above notification methods cannot effectively distinguish the message sources of different accounts. Users still need to manually perform window restoration, account tab switching, and function module navigation operations one by one, resulting in a long interaction chain. During this process, frequent changes in application interface state and redrawing operations increase the computing load on the terminal processor, and the large number of human-computer interaction commands generated by multi-step operations can also easily cause additional consumption of client memory and rendering resources, resulting in limited information processing efficiency. Summary of the Invention

[0004] This application provides an information processing method, apparatus, electronic device, and computer-readable storage medium to at least partially solve the aforementioned problems existing in the related art.

[0005] According to one aspect of this application, an information processing method is provided, the method comprising: acquiring business event messages generated by multiple login accounts in a first application; in response to a preset trigger operation for the first application or detection that a business event message meets a preset reminder condition, displaying an aggregation panel and displaying business event messages from multiple login accounts in the aggregation panel respectively; in response to a trigger operation for a target business event message in the aggregation panel, triggering the first application to switch to the target account corresponding to the target business event message, and opening the functional module interface corresponding to the type of the target business event message.

[0006] According to one aspect of this application, an information processing apparatus is provided, comprising: an acquisition module for acquiring business event messages generated by multiple login accounts in a first application; a display module for displaying an aggregation panel in response to a preset trigger operation for the first application or when a business event message meets a preset reminder condition, and displaying business event messages from multiple login accounts in the aggregation panel; and a processing module for triggering the first application to switch to the target account corresponding to the target business event message in response to a trigger operation for a target business event message in the aggregation panel, and opening a function module interface corresponding to the type of the target business event message.

[0007] According to one aspect of this application, an electronic device is provided, comprising: a memory storing computer-executable instructions executable by a processor; and a processor for executing the computer-executable instructions to implement any of the above methods.

[0008] According to one aspect of this application, a computer-readable storage medium is provided, which stores a computer program that, when executed by a processor, implements any of the above methods.

[0009] By aggregating and displaying messages from multiple accounts and enabling one-click switching between accounts and opening corresponding function interfaces, the interaction path is shortened, and message processing efficiency is improved. At the same time, it reduces redundant interface rendering and switching commands caused by users frequently restoring windows and manually switching accounts, helping to reduce terminal resource consumption. Attached Figure Description

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

[0011] Figure 1 This application illustrates a schematic diagram of a system architecture according to one exemplary embodiment. Figure 2 This invention provides a flowchart illustrating an information processing method in one exemplary embodiment of the present application. Figure 3 A schematic diagram showing a configuration interface in one exemplary embodiment of this application is provided. Figure 4 A schematic diagram showing a configuration interface in one exemplary embodiment of this application is provided. Figure 5 A schematic diagram of a display aggregation panel is shown in one exemplary embodiment of this application; Figure 6A schematic diagram showing a shortcut configuration interface in one exemplary embodiment of this application is provided. Figure 7 This diagram illustrates the reminder settings for time-sensitive services in one exemplary embodiment of this application. Figure 8 This illustration shows a graphical user interface diagram of setting an object of interest in one exemplary embodiment of this application; Figure 9 A graphical user interface diagram illustrating the setting of parameters of interest in one exemplary embodiment of this application is shown. Figure 10 A graphical user interface diagram illustrating setting an alarm clock is shown in one exemplary embodiment of this application. Figure 11 A schematic diagram of the interface of the direct positioning function module in one exemplary embodiment of this application is shown; Figure 12 A schematic diagram of the structure of an information processing apparatus according to one exemplary embodiment of the present disclosure is shown. Figure 13 This illustration shows a schematic diagram of the structure of an electronic device according to one exemplary embodiment of the present application. Detailed Implementation

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

[0013] It should be noted that the terms "first," "second," etc., in the specification, claims, 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.

[0014] The accompanying drawings are schematic illustrations of this application and are not necessarily drawn to scale. Some block diagrams shown in the drawings may be functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities may be implemented in software, in hardware modules or integrated circuits, or in networks, processors, or microcontrollers. Implementations can be carried out in various forms and should not be construed as limited to the examples set forth herein. The features, structures, or characteristics described in this application can be combined in any suitable manner in one or more implementations. In the following description, numerous specific details are provided to give a thorough description of the embodiments of this application. However, those skilled in the art will recognize that one or more specific details may be omitted when implementing the technical solutions of this application, or other methods, components, apparatuses, steps, etc., may be used to replace one or more specific details.

[0015] Figure 1 A system architecture diagram of the operating environment of this exemplary embodiment is shown. This system architecture may include a terminal device 110 and a server 120. The terminal device 110 may be a mobile phone, tablet computer, personal computer, smart wearable device, game console, etc., and has a display function capable of displaying a graphical user interface, which may include the operating system interface or the application interface. An application, such as a game program, is installed on the terminal device 110. The server 120 generally refers to the backend system providing application services in this exemplary embodiment; it may be a single server or a cluster of multiple servers. For example, a game server program is deployed on the server 120 to perform server-side game data processing. The terminal device 110 and the server 120 can be connected via a wired or wireless communication link for data transmission. The method in one exemplary embodiment of this application can be executed by any one or more of the terminal device 110 and the server 120.

[0016] In one implementation, the above method can be implemented and executed based on a cloud interaction system. The cloud interaction system can be the system architecture described above. Various cloud applications, such as cloud gaming, can run under the cloud interaction system. Taking cloud gaming as an example, cloud gaming can be a game mode based on cloud computing. In the cloud gaming operation mode, the game program's execution entity and the game screen presentation entity are separated. The storage and execution of the game's control and interaction methods are completed on the cloud gaming server (such as the aforementioned server 120). The cloud gaming client (such as the aforementioned terminal device 110) is responsible for receiving and sending data and presenting the game screen. For example, the cloud gaming client can be a display device with data transmission capabilities located close to the user, such as a mobile terminal, television, computer, or PDA; while the cloud gaming server in the cloud performs information processing. When playing the game, the user operates the cloud gaming client to send operation commands to the cloud gaming server. The cloud gaming server runs the game according to the operation commands, encodes and compresses the game screen and other data, returns it to the cloud gaming client via the network, and finally, the cloud gaming client decodes and outputs the game screen.

[0017] In one implementation, the method described above can be implemented by the terminal device 110 alone. For example, without deploying the server 120, the terminal device 110 can run the application in a standalone environment to implement the game function and execute the method described above.

[0018] According to one embodiment of the information processing method of this application, such as Figure 2 As shown, the method may include: Step S210: Obtain business event messages generated by multiple login accounts in the first application; Step S220: In response to a preset trigger operation for the first application or the detection that a business event message meets the preset reminder conditions, an aggregation panel is displayed, and business event messages from multiple logged-in accounts are displayed in the aggregation panel respectively. Step S230: In response to the trigger operation for the target business event message in the aggregation panel, the first application is triggered to switch to the target account corresponding to the target business event message, and the function module interface corresponding to the type of the target business event message is opened.

[0019] In one specific application of this embodiment, the game client supports a multi-account mode with multiple tabs in a single window. Users can log in to multiple game character accounts in the same window using multiple tabs, with each tab corresponding to an independent game account. When multiple game accounts generate business event messages, such as account A receiving a chat message from a friend, account B being matched for a team dungeon, or account C's limited-time daily activity about to begin, the game client receives these business event messages from different game accounts. The types of business event messages include limited-time task reminders, account status changes (such as stamina fully restored), social interaction messages (such as friend chats or guild invitations), collaborative matching results (such as successful team matching), and automatic matching results (such as automatic arena matching completed). When the user minimizes the game client window to handle other tasks, the game client icon remains displayed in the operating system's notification area. When a user hovers their mouse cursor over the notification area icon, the game client responds to the preset trigger, displaying an aggregation panel. This panel shows business event messages from multiple game accounts, including Account A, Account B, and Account C. Each message is labeled with its respective game account name and message type, allowing users to preview message content from each account without opening the game window. When a user clicks on a friend's chat message for Account A in the aggregation panel, the game client automatically restores the game window from its minimized state to the foreground, switches the display to the tab corresponding to Account A, opens the friend system function module, and locates the friend's chat dialog box, allowing the user to directly reply to messages without manually switching tabs or searching for the friend system entry. Similarly, when a user clicks on a successful team match message for Account B, the game client automatically restores the window, switches to the Account B tab, and opens the team dungeon interface, allowing the user to immediately enter the dungeon.

[0020] In another specific application of this embodiment, the client application of the multi-store e-commerce operation management platform supports simultaneous login to multiple store accounts in a multi-tab format. Operators can manage orders, inventory, customer service, marketing, and other business operations for multiple stores within a single window. The client application used by operators runs in a multi-tab mode, with each tab corresponding to a store account. When multiple store accounts generate business event messages—for example, store A receives a new order pending shipment, store B's inventory of a certain product falls below a safety threshold, and store C receives a customer refund request—the client application retrieves these business event messages from different store accounts. When an operator hovers the cursor over the message display entry of the client application in the operating system notification area, the client application responds to this preset trigger operation, displays an aggregation panel, and shows business event messages from multiple store accounts such as store A, store B, and store C. Each message is labeled with its respective store account name and message type. When an operations staff member clicks on the inventory alert message for store B in the aggregation panel, the client application responds to the triggered operation by automatically switching the display interface to the tab corresponding to store B and opening the inventory management function module interface, allowing the operations staff member to directly view and edit the product information of insufficient inventory in store B.

[0021] According to the embodiments of this disclosure, by aggregating and displaying messages from multiple accounts and enabling one-click switching between accounts and opening corresponding function interfaces, the interaction path is shortened and message processing efficiency is improved. At the same time, it reduces redundant interface rendering and switching commands caused by users frequently restoring windows and manually switching accounts, helping to reduce terminal resource consumption.

[0022] The embodiments of this application will be further described below.

[0023] In step S210, business event messages generated by multiple login accounts in the first application are obtained.

[0024] Optionally, the first application is a client program that supports simultaneous login of multiple accounts and generates business events. The first application can be a game client program running on a desktop operating system, or other instant messaging tools, client applications of multi-store e-commerce operation management platforms, or office software that support parallel operation of multiple accounts. This embodiment does not limit the type of the first application. The first application is not limited to personal computers and can also be extended to mobile terminal devices; its specific form can be adaptively adjusted according to the actual operating environment.

[0025] Optionally, multiple login accounts can be a collection of independent accounts logged in concurrently within the same application window using multiple tabs, or accounts corresponding to different application instances running on the same terminal using a multi-instance approach. In one implementation, multiple login accounts share the same client process, with different account interfaces presented through tab switching. In another implementation, multiple login accounts can be user-logged-in characters A, B, and C within the same game client, with each character independently running its own game session and generating corresponding business event messages. In yet another implementation, multiple login accounts can be multiple store accounts logged in simultaneously on a multi-store e-commerce operation management platform. It should be noted that the above examples of account operation methods are not intended to limit the specific operational architecture of accounts. In actual implementation, multiple login accounts can also be distributed across different virtual desktops or different display devices, as long as the messages generated by these accounts can be obtained by a unified message processing module, thereby meeting the multi-account management needs under different hardware environments.

[0026] Optionally, business event messages are notification data representing changes in account status within the application or the triggering of preset logic. Business event messages can take the form of time-sensitive task reminders, account status change notifications, social interaction messages, collaborative matching results, and automatic matching results. It should be noted that, in addition to basic text content, business event messages may also include extended information such as event type identifiers, source account information, and importance parameters. This extended information can further assist in subsequent intelligent sorting and categorized display. In actual implementation, the types of messages to be acquired can be determined based on experience or specific application conditions; this application does not aim to exhaustively limit this.

[0027] Optionally, the acquisition process of business event messages can be implemented through an inter-process communication framework. In one implementation, when a specific action occurs within the game process, the generated message string is proactively sent to the process where the message bar resides for caching. To avoid message loss due to network fluctuations or process lag, the above method can resend the message according to a preset retry mechanism when a message sending failure is detected. If an abnormal event occurs outside of normal circumstances, it can be further verified using local log records; this application embodiment does not limit this. It should be understood that different types of business event messages generally have different generation frequencies and timeliness requirements. The system can adopt different acquisition strategies based on these characteristics. For example, real-time push can be used for highly time-sensitive matching results, while timed polling can be used for less time-sensitive status changes, thereby reducing system resource consumption while ensuring information timeliness.

[0028] In an optional implementation, acquiring business event messages generated by multiple login accounts in the first application includes: receiving configuration operations for reminder conditions for each login account through a configuration interface, where the reminder conditions include the type of business event message and / or reminder parameters; acquiring business event messages from multiple login accounts that meet the reminder conditions based on the reminder conditions configured for each login account; wherein the type of business event message includes at least one of time-sensitive tasks, account status changes, social interactions, collaborative matching results, and automatic matching results. In this way, by configuring reminder conditions independently for each login account, different accounts can accurately acquire corresponding business event messages according to their own needs, effectively avoiding the uniform disturbance of unimportant information in multi-account scenarios, and improving the personalization and filtering efficiency of message acquisition.

[0029] For example, in a game application, such as Figure 3 and Figure 4 As shown, users can enable message notifications for the account "Le Da Chui" through the configuration interface. They can select the message type via checkboxes, including friend chat messages, item release notifications, and game events, and set reminder conditions for events (5 minutes in advance). Additionally, users can configure reminder conditions for other accounts logged in simultaneously via the account switch button.

[0030] For example, in an e-commerce management platform, the operator sets the following reminder conditions for store A in the configuration interface: "Order overdue for shipment" (time-sensitive task type) and "Store rating change" (account status change type), with an advance reminder parameter of 15 minutes. For store B, the reminder conditions include "Customer inquiry message" (social interaction type) and "Refund application" (collaboration matching result type), with an advance reminder parameter of immediate reminder. Based on the reminder conditions configured for each store, the system only retrieves event messages that meet the conditions. Store A will not receive reminders for customer inquiry messages, and store B will not receive reminders for order overdue orders.

[0031] Optionally, the configuration interface receives reminder condition configuration operations performed by the user for each logged-in account to support differentiated reminder rule settings. Optionally, the configuration interface can be a global settings panel embedded in the application client or an independent floating window invoked via a system tray icon; its presentation can be adaptively adjusted according to the client's operating environment and screen resolution. In this interface, users can browse a list of all currently logged-in account identifiers and expand the reminder rule editing area for each account. The interface can present a separate message type checklist and reminder parameter setting controls for each account, allowing reminder rules for account A and account B to be configured completely independently without affecting each other. Furthermore, the configuration interface can also provide reset and copy controls next to the configuration area for each account. Users can trigger the reset control to restore the reminder conditions of the current account to the system default value, or trigger the copy control to synchronize the currently edited reminder rule to other specified accounts, thereby improving the efficiency of multi-account configuration. It should be noted that the layout of the configuration interface can be a sidebar navigation style, a tabbed layout, or a collapsible panel style; this application does not intend to limit its specific interaction form.

[0032] Optionally, the alert conditions include the type of business event message and / or alert parameters, and are configured and effective independently for each logged-in account. Optionally, the alert conditions serve as a preliminary judgment rule for whether business event messages can enter the aggregation panel. Their core function is to filter out the parts that users are truly concerned about from the massive number of business events generated by the first application. Among them, message type filtering is used to define which business events can generate alert messages, such as limiting the reception to only time-sensitive tasks or social interaction events; alert parameters are used to perform more granular time or frequency control on similar events, such as setting advance reminder minutes for limited-time events, or setting notifications for only specific sessions of events that are open multiple times a day.

[0033] Optionally, the business event message type is a general overview of various alertable events within the application. Its subordinate concepts can be flexibly expanded according to the functional modules of the application system, including but not limited to time-sensitive tasks, account status changes, social interactions, collaborative matchmaking results, and automatic matchmaking results. For example, in a game application, time-sensitive tasks may include daily limited-time dungeon challenges or periodically refreshed world events; account status changes may include a character's stamina being fully restored, equipment durability falling below a threshold, or accumulated online time reaching a specific value; social interactions may include private messages sent by friends, mentions of a user's nickname in the guild channel, or recruitment requests from the mentor-apprentice system; collaborative matchmaking results may include notifications that a five-person team has been formed or that a team dungeon application has been approved; automatic matchmaking results may include notifications of successful automatic matchmaking in the arena or a countdown to the start of a cross-server battlefield. It should be noted that the above classifications are not exhaustive, and other custom event types can be included in practical applications. Optionally, reminder parameters are used to fine-tune the triggering timing and threshold of business event messages, and different parameter dimensions correspond to different types of business event messages. Optionally, the specific content and value selection method of reminder parameters are closely related to the type of business event message configured, with different types corresponding to different parameter dimensions. Taking time-sensitive tasks as an example, reminder parameters may include the advance reminder time interval and the desired activity session. The time interval allows users to set a specified number of minutes before the activity starts, and the activity session allows users to select the specific session they wish to be reminded of from multiple activities on a single day. Taking price fluctuation reminders as an example, reminder parameters may include a attention threshold and a price change threshold. A reminder is triggered when the attention of the monitored object reaches the set threshold or the price decrease exceeds a set percentage. Taking alarm clock reminders as an example, reminder parameters may include the specific reminder time and a description of the associated reminder event. It should be noted that the above descriptions of reminder parameters are merely illustrative, and this application does not intend to exhaustively limit the specific dimensions of reminder parameters. In actual implementation, new parameter dimensions can be added according to the expansion of business event message types to adapt to the differentiated needs of users for reminder accuracy and flexibility in different scenarios.

[0034] In an optional implementation, the method further includes: displaying a batch application entry in the configuration interface; receiving a confirmation command for the batch application entry; and applying the reminder conditions of the currently logged-in account to all logged-in accounts in the first application. This avoids the tedious process of configuring reminder conditions one by one in multi-account scenarios, significantly improving the configuration efficiency for multi-account users and reducing operational costs through one-click batch application.

[0035] In one implementation, the user sets the reminder condition for account A to only receive timed tasks and social notifications in the configuration interface, and clicks the "Batch Application" button at the bottom of the interface. The system then pops up a secondary confirmation box. After the user clicks "Confirm", the system automatically synchronizes the configuration of account A to all accounts currently logged in on the client.

[0036] Optionally, the batch application entry is used to receive trigger operations to synchronize the configuration parameters of the current account to other accounts. Its presentation can be a button, icon, or text link. Optionally, the batch application entry can be displayed in the bottom area of ​​the configuration interface, the sidebar, or other locations that do not affect the viewing of the main information. The presentation of this entry can be varied, such as a rectangular button with the words "Batch Application," an icon with a specific style, or a clickable text link. Considering that multi-account users often need to repeatedly set the same parameters for each account when configuring reminder conditions, to reduce the interaction cost caused by this repetitive operation, the aforementioned batch application entry can trigger a configuration synchronization mechanism after receiving a trigger operation. It should be noted that the above description of the location and form of the batch application entry is only one example, and this application is not intended to limit it. In actual implementation, it can be flexibly adjusted according to the overall layout of the interface and interaction habits.

[0037] Optionally, the confirmation command is used to grant secondary authorization for the execution of batch applications. It can be generated by clicking a preset control or inputting a specific gesture. To avoid accidentally overwriting the personalized configurations of all accounts due to accidental activation of the batch application entry, the above method can first display a secondary confirmation interface after receiving a trigger operation for the batch application entry, requiring the user to input a confirmation command. If the user does not input a confirmation command within a preset time, it can be considered as abandoning this batch application operation; only if the user inputs a correct confirmation command will the system execute the subsequent configuration synchronization logic. It should be understood that, in addition to generating confirmation commands by clicking controls, voice commands or biometric recognition information input by the user can also be received as confirmation criteria, and this application is not limited to this.

[0038] Optionally, all login accounts may include all active accounts in the current client instance, or multiple accounts bound to the current device and online within the same local area network. It should be noted that the above description of the scope of all login accounts is just one example, and those skilled in the art can determine the appropriate scope based on specific application scenarios.

[0039] In step S220, in response to a preset trigger operation for the first application or the detection that a business event message meets a preset reminder condition, an aggregation panel is displayed, and business event messages from multiple logged-in accounts are displayed in the aggregation panel.

[0040] Optionally, a preset trigger operation is used to receive the user's active interaction intent to invoke the aggregation panel for message display. Optionally, the preset trigger operation can be a hover operation, a click operation, or a right-click menu selection operation on a system notification area icon. Considering that users may frequently switch windows when multitasking, to reduce the invocation cost, the aforementioned hover operation can be set to trigger after the cursor has been hovering for a preset duration, to avoid frequent pop-ups caused by accidental cursor movement. It should be noted that the preset trigger operation is not limited to mouse interaction; it can also be a keyboard shortcut combination or voice command. This application does not aim to exhaustively limit the triggering methods. In actual implementation, it can be flexibly configured according to the operating system's interaction specifications or the user's custom habits to meet the fast invocation needs in different scenarios.

[0041] Optionally, the preset reminder conditions aim to automatically determine whether to activate the aggregation panel based on the message type and configuration parameters. These preset reminder conditions can be set by default by the system based on the attributes of the business event message, or users can customize the selection and parameter adjustments for different types of business events in the configuration interface; this application is not limited to this. In addition to message type matching rules, the preset reminder conditions can also include additional judgment dimensions such as timeliness thresholds and quantity limits, thereby achieving accurate filtering of important messages in multi-account parallel scenarios. As one possible implementation, when the system detects that the type of a business event message belongs to a time-limited task category selected by the user, and its generation time is within the set valid reminder period, it determines that the preset reminder conditions are met, thereby triggering the display logic of the aggregation panel to prevent users from missing key activities. Similarly, when the system detects that the cumulative number of unread messages of the same type exceeds a preset threshold, it can also determine that the preset reminder conditions are met and trigger the display of the aggregation panel. For example, when the system detects that at least one of the multiple logged-in accounts has generated a business event message marked as having the highest importance level, and the aggregation panel is not currently displayed, it is also determined that the preset reminder conditions are met and the aggregation panel is actively triggered to ensure that high-priority events are delivered in a timely manner.

[0042] Optionally, the aggregation panel is used to display and visualize business event messages from multiple logged-in accounts. Its presentation can be a floating window or a standalone panel. For example, the aggregation panel can be a floating list that pops up along the edge of the system notification area icon, or a semi-transparent overlay window generated at a specified location on the desktop. This aggregation panel is displayed when a preset trigger operation is received or preset reminder conditions are met. Its internal area can be vertically divided according to account, with each section displaying multiple business event messages under that account. It should be noted that the aggregation panel's display hierarchy is above the operating system desktop and can be set to always be on top or automatically hide when focus is lost.

[0043] In an optional implementation, the method further includes: providing a message display entry point for the first application in the operating system's notification interface; and a preset trigger operation for the first application including a trigger operation for the message display entry point. Thus, by placing the message display entry point for the first application in the operating system's notification interface, users can quickly bring up the aggregation panel without having to search for the application window in the desktop environment, significantly improving the convenience and response efficiency of information access in multi-account scenarios.

[0044] In one implementation, taking a multiplayer online game on a personal computer as an example, such as... Figure 5 As shown, when a user is simultaneously handling other tasks and idling in the game, the game client window is minimized. At this time, the game's message display entry (i.e., the application icon) is displayed in the notification area in the lower right corner of the operating system desktop. When any of the multiple game accounts generates a new business event message, the icon will provide a visual cue in a preset manner, such as periodically flashing or displaying a red dot in the upper right corner. When the user moves the mouse cursor over and hovers over the icon, a preset trigger action is triggered for the first application, and the system immediately pops up an aggregation panel near the icon, displaying business event messages from multiple logged-in accounts. In another implementation, if the user does not perform a hovering action, the system can also automatically display the aggregation panel when it detects that a business event message meets preset reminder conditions (such as reaching the highest importance level), ensuring that key information is not missed.

[0045] Optionally, the operating system's notification interface serves as the message display entry point for the first application. It is located in the system-level area of ​​the desktop environment and is presented independently of the application client window. Optionally, the operating system's notification interface can be a graphical area in the desktop operating system used to centrally display system-level status indicators and application entry points; its specific form varies depending on the operating system type. In one implementation, the notification interface is the taskbar notification area in the lower right corner of the personal computer desktop (i.e., the system tray), where the user can keep the icon of the first application permanently displayed. In another implementation, the notification interface can also be a notification center panel provided by the operating system, which aggregates message summaries from various applications and arranges them in chronological order through a system-level interface. It should be noted that the above description of the specific location of the notification interface is merely illustrative and is not intended to limit its location. In actual implementation, the notification interface can also be the status bar pull-down notification page or the lock screen notification area in a mobile terminal system, as long as it provides a system-level message display entry point. By setting the message display entry point in the operating system's notification interface, even if the application client window is minimized or obscured by other windows, users can still quickly perceive the reminder signal at the system level, effectively avoiding the problem of information loss caused by window layer obstruction.

[0046] Optionally, the message display entry is used to receive user trigger operations to directly bring up the aggregation panel. Its presentation form can be one or more of icons, bubbles, or dynamic icons. The message display entry can be an application entry control displayed as an icon in the operating system's notification interface. It not only serves as a trigger point for application launch or focus but also provides a visual cue for message notifications. In one implementation, the message display entry is represented as an application icon residing in the system tray. When there are unread business event messages, a red dot is displayed in the upper right corner of the icon to alert the user that a new message has arrived. In another implementation, the visual cue for the message display entry can be represented by the periodic flashing effect of the icon itself, i.e., the icon repeatedly switches between displayed and hidden states to attract the user's attention. Furthermore, the preset trigger operations supported by the message display entry can include various interaction forms, such as mouse hover operations, mouse click operations, and touch long-press operations. When the user performs a mouse hover operation, the system pops up an aggregation panel near the entry to preview the message content; when the user performs a click operation, the system can directly trigger the application window restoration and deep jump process. It should be noted that the above combinations of visual prompts and triggering actions are merely examples, and this application does not intend to exhaustively limit them. Developers can flexibly configure different prompt styles and triggering gestures according to the operating system's interaction specifications and user habits.

[0047] In an optional implementation, business event messages from multiple logged-in accounts are displayed in the aggregation panel. This includes: determining the importance level of each business event message based on a preset mapping relationship between the message type and its importance level, and / or the received importance level configured for each message type; distinguishing and displaying the business event messages according to their importance level in the aggregation panel, and sorting them according to their importance level; wherein, within the same importance level, the messages are sorted based on their generation time. In this way, message importance is determined through a dual-track approach of system preset mapping and user-defined configuration, combined with visual differentiation and a two-level composite sorting, making the massive amount of multi-account aggregated information clearly hierarchical and prioritized, facilitating users to quickly locate high-priority events and reducing cognitive burden.

[0048] In one implementation, users configure importance levels for different types of messages in the system settings. For example, timed tasks are set to the highest importance, and social notifications are set to medium importance. When multiple accounts generate messages simultaneously, the timed task message with the highest importance is displayed at the top of the aggregation panel with a prominent red background, while social notifications are displayed below with a yellow background. If there are multiple social notifications within the same importance level, they are arranged in chronological order of their generation, with the most recently generated notification appearing first. Optionally, this importance level indicates the urgency or attention value of business event messages; it can be automatically determined based on a preset mapping relationship for message types or dynamically adjusted based on received custom configurations.

[0049] Optionally, the determination of the above importance levels can be implemented in multiple ways to meet the personalized information filtering needs of different users. As one possible implementation, the system internally pre-configures a mapping relationship between the type of business event message and its importance level. This pre-configured mapping relationship is used to establish a benchmark judgment rule between the message type and its importance level, enabling the system to automatically determine its initial importance level based on the message type. This pre-configured mapping relationship can be pre-configured by the system backend based on the inherent attributes of the business events. Taking game applications as an example, types involving time-limited tasks and successful team formation, which are highly time-sensitive or collaborative, can be mapped to the highest importance level; social notifications and product listings can be mapped to a medium importance level; and low-time-sensitive types such as resource refresh prompts and system broadcast announcements can be mapped to the lowest importance level. For e-commerce applications, refund dispute messages and order timeout messages can be mapped to a high importance level; inventory warning messages and customer service transfer messages can be mapped to a medium importance level; and product listing notifications and promotion review notifications can be mapped to a low importance level. The aforementioned preset mapping relationship can be stored in a local configuration file as key-value pairs, where the key is the type identifier of the business event message and the value is the importance level code. It should be noted that this mapping relationship is not static and can be dynamically adjusted by the system based on operational strategies or version content. As a possible implementation, the system can also receive the importance level configured for each business event message type, allowing users to manually adjust the level weight of specific message types in the configuration interface. For example, the system can display all configurable message types in a list format in the configuration interface, providing several importance options for each type for the user to select. After this configuration takes effect, when a business event message of the corresponding type is generated, the system will prioritize the user-defined importance level. This combination of preset and custom approaches provides a default hierarchical strategy that works out of the box while also granting users a high degree of customization, making the display logic of the aggregation panel more aligned with user needs and focus.

[0050] Optionally, the steps described above for distinguishing and displaying business event messages according to their importance level can be implemented using different visual identifiers. For example, message entries with the highest importance level can be rendered with a red highlighted background or an interface control with a flashing edge, medium importance level messages can use a yellow background, and the lowest importance level messages can use a regular gray-white background. Regarding sorting and display, the system prioritizes arranging message entries from top to bottom according to their importance level. Furthermore, for multiple messages that may exist within the same importance level, the system obtains the generation time of these business event messages and performs a secondary sorting according to the chronological order of the timestamps, typically placing the most recently generated message at the top of that level's block. This multi-dimensional sorting and differentiation mechanism not only ensures the priority exposure of high-priority information but also maintains the temporal continuity within information of the same level, avoiding confusion in time logic when users process similar information.

[0051] In an optional implementation, the method further includes: receiving a quick filtering command while the aggregation panel is displayed; filtering a subset of messages that meet the filtering conditions from the currently displayed business event messages according to the filtering dimensions and filtering values ​​corresponding to the quick filtering command, and displaying the message subset in the aggregation panel; wherein the filtering dimensions include at least one of account dimension and importance dimension. In this way, by using quick filtering commands to filter message subsets of specific dimensions in real time in the aggregation panel, the difficulty of searching caused by information overload in multi-account scenarios is avoided, enabling users to quickly locate key messages of target account or target importance, effectively improving information acquisition efficiency.

[0052] In one implementation, when a user hovers the mouse cursor over the message display entry point of the first application in the operating system's notification area, an aggregation panel pops up displaying business event messages from multiple logged-in accounts. The user can then trigger filtering by pressing a keyboard shortcut combination without moving the mouse away from the panel area. For example, pressing Ctrl+1 will only display business event messages for account 1 in the aggregation panel, temporarily hiding messages from other accounts; similarly, pressing Alt+2 will only display business event messages with a medium importance level from all accounts. After filtering, pressing the same shortcut again or a preset restore key will restore the full message display in the aggregation panel. It should be noted that the mapping between shortcuts and filtering dimensions is configured by default by the system, but users can also manually adjust it in the settings interface.

[0053] Optionally, quick filter commands are used to trigger message filtering while the aggregation panel is displayed, extracting target messages that meet certain criteria from the currently displayed full range of business event messages. Quick filter commands can be keyboard shortcuts received while the mouse cursor is hovering over the aggregation panel, or touch clicks or voice commands on preset filter controls within the aggregation panel. As one possible implementation, the quick filter command is triggered when the aggregation panel is displayed and the mouse cursor is not leaving the panel area. This design aims to prevent users from accidentally pressing shortcuts in non-preview scenarios, thus avoiding unnecessary filtering actions. In practice, quick filter commands can be implemented using key combinations, such as... Figure 13 As shown, users can pre-set different shortcut commands through the configuration interface, such as the Alt key combined with the letters A, W, and P, where the letter keys are mapped to message types or importance levels. It should be noted that the above key combination is only one example; in actual implementation, other forms such as function keys F1 to F12, number keys, or arrow keys can also be used. This application does not intend to limit the specific input method of shortcut filtering commands. Furthermore, when a user presses multiple shortcut filtering commands consecutively in a floating state, the system can execute according to the logic of the later command overriding the previous command, or according to the logic of multiple conditions superimposed, thereby meeting different filtering needs. In addition, for mobile terminals, shortcut filtering commands can be implemented through voice commands or swipe trajectories. For example, short voice keywords such as "only view account one" can be input through the microphone to activate message filtering for the corresponding dimension, or a mapping relationship between a preset swipe trajectory and account number or importance level number can be used.

[0054] Optionally, the filtering dimension defines the filtering direction of the quick filtering command, and it includes at least one of the following: account dimension and importance dimension. The account dimension filters according to the login account to which the business event message belongs, while the importance dimension filters according to the importance level of the business event message. In specific applications, the filtering value under the account dimension can correspond to the tab number of the login account in the client; for example, a filtering value of 1 displays only messages from account 1, and a filtering value of 2 displays only messages from account 2. The filtering value under the importance dimension can correspond to the importance level; for example, a filtering value of 1 displays only messages of the highest importance, and a filtering value of 3 displays only messages of the lowest importance. To avoid the filtering dimension being too singular and causing users to be unable to accurately locate information, as an extended implementation method, the filtering dimension can further include a message type dimension, such as time-limited tasks, social notifications, price changes, etc. Users can use corresponding shortcut keys to display only one type of business event message. It should be noted that the above description of the types of filtering dimensions and the mapping relationship of filtering values ​​is only one example. In actual implementation, it can be expanded or adjusted according to specific application scenarios. This application does not intend to limit the specific composition of the filtering dimensions. Similarly, different filtering dimensions can be used independently or in combination to meet the needs of multi-dimensional cross-filtering.

[0055] In an optional implementation, the method further includes: when at least two accounts among multiple logged-in accounts are detected to generate the same type of business event message, downgrading the importance level of the business event messages corresponding to each of the at least two accounts; and independently displaying the downgraded business event messages of the at least two accounts in the aggregation panel. In this way, when different accounts generate the same type of message, automatic downgrading and independent display effectively reduce the visual interference of repeated reminders on the user, reducing information overload while retaining necessary information.

[0056] In one implementation, a user's first and second accounts simultaneously receive notifications for the same time-limited event. The system detects that the business event messages from both accounts belong to the time-sensitive task type, and automatically downgrades the importance level of each message from high to medium. Subsequently, the notification content for both accounts is still displayed as separate items in the aggregation panel, but the order in the aggregation panel is adjusted accordingly, allowing the user to be aware of the pending tasks for each account without being overwhelmed by multiple highlighted high-priority messages.

[0057] Optionally, "same type of business event messages" refers to messages belonging to the same business category generated by multiple logged-in accounts within a similar time or the same time period, used to trigger a downgrade judgment mechanism. Specifically, "same type of business event messages" can cover message categories under various business scenarios. For example, both Account A and Account B received a reminder at 10:55 AM about the start of the "11:00 AM to 12:00 PM Guild Competition" activity; these two messages belong to the same time-sensitive task type. Another example is that Account A received a private message from Friend X, and Account B received a private message from Friend Y; although the senders are different, the message type belongs to the social interaction category. Yet another example is that multiple accounts' market-followed products simultaneously triggered price change alerts; for instance, both "Enhancement Stones" followed by Account A and Account B experienced price drops, generating the same type of price increase / decrease alerts. It should be noted that the above-mentioned judgment regarding the same type can be based on matching message category tags or on matching the business event identifier associated with the message; this application does not intend to limit this. When the system detects that at least two accounts have generated the same type of business event message, it can trigger the subsequent degradation process, thereby reducing the visual impact of duplicate information on users.

[0058] Optionally, degradation processing is used to reduce the importance level of business event messages by at least one level to reduce the visual weight of duplicate messages of the same type in the aggregation panel. The specific implementation of degradation processing can be flexibly adjusted according to the granularity of importance level division. As one possible implementation, the system presets three importance levels: "highest," "medium," and "lowest." When at least two accounts are detected to generate the same type of business event message, the importance level of the messages corresponding to these at least two accounts is reduced by one level, for example, from "highest" to "medium" or from "medium" to "lowest." As another implementation, the magnitude of degradation processing can also be dynamically determined according to the number of accounts generating the same type of message. For example, it can be reduced by one level when two accounts generate the same type of message, and by two levels when three or more accounts generate the same type of message, thereby further compressing the display weight of large-scale duplicate information. It should be noted that degradation processing mainly affects the message's sorting position and visual identification (such as color, icon, etc.) in the aggregation panel, and does not affect the message's delivery or clickable navigation function. By downgrading the process, the system ensures that messages from all accounts are fully preserved and displayed. On the other hand, by reducing the sorting priority of duplicate information, it allows non-duplicate and differentiated information to receive higher display positions, thereby achieving a more reasonable allocation of attention in information aggregation scenarios.

[0059] Optionally, independent display is used to present the downgraded business event messages of each account as independent entries in the aggregation panel, rather than merging them into a single entry. Independent display means that each business event message occupies its own display entry in the aggregation panel, carrying the identification information of its respective account. Users can execute trigger operations on each message individually to achieve navigation. Specifically, in the aggregation panel, each independently displayed message entry can include elements such as an account name or avatar thumbnail, a message type icon, a message summary text, and color indicators corresponding to the importance level. The entries are visually distinguished by separators or spacing. For example, although the same limited-time event messages from Account A and Account B have been downgraded, they are still displayed as two independent entries in the panel: "Account A - Guild Competition is about to begin" and "Account B - Guild Competition is about to begin." Users can click on either one to jump to the corresponding function interface of the corresponding account. By maintaining the integrity of the message entries for each account through independent display, users can intuitively perceive the message status of each account and accurately operate on messages of a specific account.

[0060] In an optional implementation, the method further includes: obtaining status data of the business events corresponding to the business event messages displayed in the aggregation panel; removing the target business event message from the aggregation panel when the status data indicates that the business event corresponding to the target business event message has expired, or when the status data indicates that the business event corresponding to the target business event message has been processed in the first application; wherein, expired includes at least one of the following situations: the time-sensitive business event has expired, the object associated with the business event is offline, or the resource associated with the business event is unavailable. In this way, by detecting the validity of business events in real time through status data and automatically removing the corresponding messages when they expire or have been processed, not only can visual redundancy caused by invalid reminders occupying the aggregation panel for a long time be avoided, but the manual cleanup cost for users can also be significantly reduced and information overload can be alleviated.

[0061] For example, in a game application, the system reminds the user to participate in a limited-time event from 11:00 to 12:00 at 10:55. If the user ignores the reminder, when the system time reaches 12:00, it detects that the event has expired and automatically cancels the reminder. As another example, if a user receives a reminder that flowers can be picked in their homestead but does not click on the message in the aggregation panel, instead switching to the corresponding account tab to complete the picking, the system detects that the event has been processed and removes the message from the aggregation panel. For duplicate reminders, such as those 5 minutes before the event starts, the system will use later-generated messages to overwrite reminders from the previous 15 minutes, achieving dynamic cleanup.

[0062] For example, in an e-commerce application, an aggregation panel displays a limited-time promotion registration message for store A, with a registration deadline of 12:00 PM on the same day. When the system time reaches 12:01 PM, the system detects based on status data that the business event has expired and is therefore invalid, automatically removing the message from the aggregation panel. As another example, the aggregation panel displays a customer service transfer message for store C; the associated customer service representative is offline on the platform. The system detects this offline status and determines the message as invalid, removing it. Yet another example is a product listing reminder for store B; the associated product resource has been removed from the platform and is therefore unavailable. Furthermore, if an operations staff member has already processed the shipping operation corresponding to an order timeout message in the first application, the system detects that the business event has been processed and removes the corresponding message from the aggregation panel.

[0063] Optionally, the status data is used to characterize the real-time operation of business events in the first application. It can be a data set generated in real-time during the operation of the first application, reflecting the current lifecycle stage of the business event. The acquisition method can include timed polling detection or event-driven real-time notification. Considering the high frequency of message status changes in a multi-account environment, as a possible implementation, the aforementioned status data can be acquired by receiving status change notifications from the application process in real-time through an inter-process communication framework (Remote Procedure Call, RPC), or by the process containing the aggregation panel sending query requests to the application process at preset time intervals. In addition to the basic flag indicating whether the business event has ended, the status data can also contain other dimensions of information, such as the online status identifier of the business event's associated objects and the inventory quantity of resources and items. It should be noted that the above description of the status data acquisition method is only one example, and this application does not intend to limit the acquisition mechanism. In actual implementation, the strategy of actively pulling or passively receiving can be flexibly selected according to the system load or specific application scenario to ensure a balance between the timeliness of the status data and system performance.

[0064] Optionally, "expired" indicates that a business event message has lost its processing value or processing conditions in the current environment, including at least situations such as time expiration, object offline, and resource unavailability.

[0065] Optionally, invalidation can specifically manifest as a time-sensitive business event having expired, meaning the corresponding activity window has been closed. For example, if the system reminds a user to participate in a limited-time activity from 11:00 to 12:00 at 10:55, and the user ignores the reminder, the activity will expire when the system time reaches 12:00. To avoid invalid information occupying panel space and interfering with user decision-making, the system determines that the business event has expired based on the acquired status data and automatically removes the corresponding reminder message from the aggregation panel. Furthermore, for multiple reminders generated by the same business event, such as a pre-reminder 15 minutes before the event starts and a final reminder 5 minutes before the event starts, the system can use an overwrite mechanism to update the previous message with the later-generated business event message, thereby reducing the amount of duplicate information displayed and increasing information density to some extent.

[0066] Optionally, invalidation scenarios may also include situations where the object associated with the business event is offline or the resource associated with the business event is unavailable. For example, in social notifications, if a notification message inviting a friend to join a team is displayed on the aggregation panel, but the friend subsequently exits the game or changes their network status, resulting in offline status, the team invitation is meaningless. Once the system detects the offline status data of the associated object, it will automatically remove the message. Similarly, for price fluctuation notifications in an economic system, if the product a user is interested in has already been purchased by another user before the user clicks to process it, meaning the resource associated with the business event is unavailable, the system will also determine that the message is invalid and remove it. It should be understood that the above-listed invalidation scenarios are only some examples. In practical applications, other types of invalidation conditions can be defined according to the application's business scenario, such as the business event's associated activity ending, the associated coupon expiring, or the associated logistics order being signed for. This application embodiment does not limit these scenarios.

[0067] Optionally, the message has been processed to indicate that the user has performed the corresponding response action in the first application for the business event message, thus achieving the purpose of the reminder. This mechanism aims to identify when a user manually handles the reminded event directly within the application without navigating through the aggregation panel. For example, in a game application, after receiving a reminder that flowers in the homestead can be harvested, the user does not click on the message in the aggregation panel but instead switches to the corresponding account tab and completes the harvesting action. At this time, the game process generates status data indicating that the business event has been completed and synchronizes it to the process where the aggregation panel is located through an inter-process communication framework. After receiving this status data, the system determines that the business event corresponding to the target business event message has been processed in the first application and removes it from the aggregation panel to avoid redundant display. This mechanism not only ensures the real-time accuracy of the panel information but also avoids the annoyance of repeated user operations and improves the smoothness of interaction in multi-tasking scenarios.

[0068] In an optional implementation, the method further includes: when multiple business event messages are detected for the same business event, updating the previously displayed business event message in the aggregation panel using the later-generated business event message. This avoids redundant information accumulation in the aggregation panel by identifying duplicate messages for the same business event and performing overwrite updates, ensuring that messages are always up-to-date and valid, thereby improving the accuracy of information previews and the utilization rate of panel space.

[0069] For example, in a game application, a user sees a rare piece of equipment in the game store but feels the current price is too high. They then add the equipment to their watchlist and configure the watchlist parameters to trigger an alert when the price drops by 20%. When the system detects that the market price of the equipment has dropped from 1000 gold coins to 800 gold coins, meeting the price change condition, it automatically generates a price drop alert message and displays it in the aggregated panel. Users don't need to constantly monitor the store interface to be informed of price changes while handling other tasks.

[0070] For example, in an e-commerce application, the inventory of a certain product in store A continuously decreased, triggering three inventory warning messages. The first message read "Product X: 50 units remaining," the second "Product X: 20 units remaining," and the third "Product X: 5 units remaining." The system detected that these three messages corresponded to the same product inventory warning event, and updated the displayed content in the aggregation panel using the last generated message, "Product X: 5 units remaining," replacing the first two messages. The aggregation panel now retains only one message entry reflecting the latest inventory status.

[0071] Optionally, the aforementioned duplicate message detection is used to identify business event messages triggered multiple times from the same event source. This can be determined based on at least one of the following: the business event identifier, the triggering source object identifier, and the event type code carried in the message. For example, when a reminder mechanism for a time-limited activity generates reminder messages about the same activity twice, the system compares the activity number, target account, and event classification code associated in the two messages to confirm that both point to the same business event, thereby triggering the subsequent overwrite update process. It should be noted that the business event identifier can be an independent primary key at the database level or a time-sensitive serial number assigned by the business logic layer; its specific form and naming rules are not limited in this application and can be adapted according to the data storage structure or message queue protocol in actual implementation. To avoid misjudging messages as different business events due to clock deviations or network delays in different subsystems, the system can also introduce a time window constraint in the above comparison process. Only messages received within a preset time threshold and whose business identifiers match are considered duplicate messages generated by the same business event, thereby improving the accuracy and reliability of duplicate detection.

[0072] Optionally, the newly generated business event message is used to overwrite the previous message of the same event in the aggregation panel to ensure that only the latest reminder content is displayed for the same business event. In practice, this can be achieved through full content replacement or incremental field updates. In the full replacement implementation, the newly generated message completely replaces the previous message's display position, visual style, and sorting weight in the aggregation panel, allowing users to view the latest reminders directly without manually clearing old messages. In the incremental update implementation, the system only replaces the fields in the message content that have changed (such as the countdown value of the reminder time or the activity status change marker), retaining the original message's position and importance level in the panel to reduce visual abruptness caused by interface refresh. Furthermore, considering that the message body structure of different business events may differ, the above update mechanism can also automatically select a replacement strategy based on the message type. For example, a full replacement is performed for plain text reminders, while a partial incremental update is used for card-style reminders containing complex interactive controls. In addition, after the update is completed, the system can re-evaluate the message's sorting position in the aggregation panel to ensure that the panel always displays the currently valid message set according to importance level and time order.

[0073] In an optional implementation, the method further includes: detecting the target business behavior executed in the first application, determining the time-sensitive target business state corresponding to the target business behavior, and calculating the expected occurrence time of the target business state; displaying a prompt message containing the expected occurrence time information and a reminder creation option; recording the expected occurrence time in response to a confirmation operation of the reminder creation option or the fulfillment of automatic creation conditions; and generating a business event message corresponding to the target business state when the expected occurrence time arrives, and displaying it in the aggregation panel. In this way, by automatically detecting business behaviors within the application and generating time-sensitive reminders, users can receive accurate reminders at the expected time without manually memorizing or repeatedly checking, effectively reducing the probability of users missing important business events in multi-tasking scenarios and improving the timeliness and scenario adaptability of reminder triggering.

[0074] For example, in a game application, such as Figure 7 As shown, when a user controls a character to plant flowers in the home scene, the system recognizes that this flower-planting behavior is a target business activity with time-sensitive benefits and calculates the estimated harvest time as 2 hours later based on the growth cycle of the flower crop. At this time, a prompt bubble pops up above the character's head or at the edge of the interface, displaying the expected occurrence time information and a reminder creation option. After the user clicks to confirm, the system records the expected occurrence time and generates a reminder message on the aggregation panel when the countdown ends.

[0075] For example, in an e-commerce application, an operations staff member creates a limited-time discount event in store A, setting the start time to 10:00 AM the following day. After detecting the event creation, the system determines the corresponding time-sensitive target business status as "Limited-time discount event started" and calculates the expected occurrence time as 10:00 AM the following day. The system displays a pop-up notification message on the interface, showing "This limited-time discount event will start tomorrow at 10:00 AM. Create a reminder? [Yes] [No]". After the operations staff member clicks [Yes], the system records the expected occurrence time. When 10:00 AM arrives the following day, the system generates a business event message "Store A's limited-time discount event has started," which is displayed in the aggregation panel.

[0076] Optionally, the target business behavior can be a user-initiated action within the application, where the business status changes at an expected time, requiring the user to pay attention. In game applications, this type of behavior can be production operations, resource collection operations, or scene construction operations, or it can be a time-limited interactive event that enters a cooldown or loading state after being triggered by the user. For example, a user sowing flower seeds in the homestead system, casting a fishing rod in the fishing grounds, or starting equipment crafting in the workshop—these actions may all result in a time-sensitive state where the output can only be collected after a certain period of time. The detection logic for the above-mentioned target business behavior can be captured in real time by the application client's behavior tracking module or scene state monitoring module. When a specific interactive action is detected, the corresponding backend configuration table is automatically queried to determine whether there is a subsequent state change node that needs to be waited for.

[0077] Optionally, the target business state reflects a time-sensitive node that occurs after the execution of the target business action and is about to change over time. Taking the aforementioned game application as an example, the target business state may include, but is not limited to, the state where crops are ripe and ready to be harvested, the state where fish have gathered and can be caught, the state where items have been crafted and can be claimed, the state where stamina is full and can continue the challenge, and the state where a limited-time dungeon entrance is open and can be entered. The above description of the types of target business states is only one example, and this application is not intended to limit the specific types of target business states. In actual implementation, the system can flexibly define the triggering time and duration of the target business state according to different business rules.

[0078] Optionally, the expected occurrence time is calculated based on the timeliness parameters of the target business status, and is used to mark the precise time anchor point for triggering the reminder. Optionally, the expected occurrence time can be calculated by directly adding the current server time to the standard waiting time of the target business status, or by first reading the client's local time at the time the behavior is triggered, then adding it to the base period issued by the backend after network latency correction to obtain the final absolute time point. For example, if a user performs a homestead planting activity at 10:00 AM that is expected to take 120 minutes to grow, the system records the expected occurrence time as 12:00:02 PM after verifying that the network latency is two seconds; or if a user starts an equipment forging activity at 3:00 PM that is expected to be completed in 45 minutes, the expected occurrence time is 3:45 PM. It should be understood that the expected occurrence time can be stored in the form of an absolute timestamp or a relative countdown, and this application is not limited to this. Furthermore, to reduce the time management costs for users in a multi-account environment, the aforementioned expected occurrence time can be accompanied by associated business behavior identifiers and user role identifiers after being recorded. This allows the system to accurately dispatch arriving reminders to the corresponding account tabs in a multi-tab environment on the same client, avoiding reminder mismatches or message interference.

[0079] Optionally, the reminder creation option is designed to receive user confirmation, recording the expected occurrence time as a reminder and adding it to the subsequent trigger queue. Its specific implementation can take the form of a confirmation control to trigger reminder creation and a cancellation control to abandon the reminder. This confirmation control can be displayed directly within the prompt bubble in the graphical user interface, or it can be generated in the settlement pop-up window after the user completes the target business action. For example, when a user plants a crop in the home system that takes two hours to mature, the system's pop-up prompt bubble can display the estimated harvest time, and place a highlighted "Yes" button and a grayed-out "No" button side-by-side in the lower right corner of the bubble as reminder creation options; or, in another way, the prompt bubble only displays a clock-shaped floating button with a checkmark icon, and the user clicking this floating button is considered to trigger a confirmation operation. The above description of the number and layout of reminder creation options is only one example; in actual implementation, it can be adaptively adjusted according to screen resolution or aspect ratio. In addition to recording the expected occurrence time by having the user manually click the confirmation control in the reminder creation option, confirmation can also be triggered after the user performs a specific gesture operation on the prompt message, such as long-pressing the bubble area for more than a preset time, double-clicking the bubble, or dragging the bubble to a specified collection area.

[0080] Optionally, automatic creation conditions are used to eliminate the manual confirmation step when preset rules are met, allowing the system to directly record the expected occurrence time and generate a reminder event. Automatic creation conditions may include at least one of the following: the proportion of times a user continuously selects to create a reminder for the historical processing results of the target business activity exceeds a preset threshold; the quality or profit level of the item associated with the target business activity reaches the rare or legendary level; or the automatic recording switch for this type of business activity is enabled in the current account's reminder settings panel. As one possible implementation, if a user has manually clicked the confirmation control in the reminder creation option four times in the past five plantings of the same advanced crop, the system can determine that the user has a strong need for this type of time-sensitive event, and directly meet the automatic creation conditions and skip the bubble confirmation step on the sixth planting. It should be noted that the above list of automatic creation conditions is not intended to be exhaustive; in actual implementation, it can also be dynamically judged based on the user's current combat or social status. Furthermore, if a user manually enters the target business scenario and actively collects output within a certain period after an automatically created reminder, the system can automatically clear the created reminder records to avoid redundant accumulation of expired reminders in the aggregation panel. One objective of this embodiment is that, through a hierarchical automation strategy, it can significantly reduce the disturbance to users caused by high-frequency repetitive operations, while ensuring that high-value gains remain within the system's monitoring and protection scope even when users are not paying attention.

[0081] In an optional implementation, the method further includes: acquiring the attention parameter settings for the target object of interest in the first application, the attention parameters including attention volume conditions and price change conditions; when it is detected that the attention volume of the target object of interest meets the attention volume conditions and / or the price meets the price change conditions, generating a corresponding business event message and displaying it in the aggregation panel. In this way, by setting multi-dimensional attention parameters for the target object of interest, reminders can be automatically generated when market conditions meet preset conditions, allowing users to keep abreast of transaction dynamics without frequent checks, effectively protecting users' important transaction profits and improving the timeliness of information acquisition.

[0082] For example, in a game application, such as Figure 8 and Figure 9 As shown, users can set their favorite items as targets for attention in the game store and configure the following parameters: a 20% price reduction and more than 100 followers. When the system backend monitors and finds that the market price and number of followers of the item meet the preset conditions, the system automatically generates a business event message containing the specific price or number of followers and pushes it to the desktop aggregation panel for display. Users can learn about this market change without entering the game.

[0083] For example, in an e-commerce management platform, an operator sets up follow parameters for a best-selling product in store B. The follower count condition is "more than 5000 followers," and the price change condition is "price reduction exceeding 10%." When the system detects that the follower count for this product increases from 3000 to 5200, the follower count condition is met, and a business event message "Product X's follower count has reached 5200" is generated and displayed in the aggregation panel. When the wholesale price of this product decreases from 100 yuan to 85 yuan, the price change condition is met, and a business event message "Product X's wholesale price has decreased by 15%" is generated and displayed in the aggregation panel. Based on this, the operator can decide whether to increase inventory or adjust the selling price.

[0084] Optionally, the target attention object is used to represent the virtual entity tracked and monitored by the user in the first application, and it is dynamically determined based on the user's selection operation. For game applications, the target attention object can be various virtual items listed in the game store, such as rare equipment, enhancement materials, pet skill books, etc., or resources consigned by other users in the trading house. As one possible implementation, the system allows users to set an item as a target attention object by clicking interactive controls such as "Add to Favorites" when browsing the item details interface. It should be noted that the above description of the target attention object type is only one example and is not intended to limit it. In actual implementation, the target attention object can also be extended to specific virtual store items or auction house bidding items. The system will assign a unique identifier to each marked target attention object in order to continuously obtain its status data.

[0085] Optionally, the attention parameter settings define specific threshold conditions for triggering the generation of business event messages, which at least include attention volume conditions and price change conditions. The price change conditions in the attention parameter settings can include multiple dimensions such as absolute price thresholds (e.g., below 1000 gold coins) and relative price fluctuation thresholds (e.g., a 5% drop from the previous day's closing price). To avoid information overload for users due to frequent message triggers caused by instantaneous market fluctuations, the above method can calculate the average price based on a preset time window or use a sliding smoothing algorithm to determine whether the price meets the conditions. The attention volume condition can be set to the absolute value of the number of followers (e.g., the number of followers exceeds 500) or the increase in new followers per unit time. Based on this, the system will only generate the corresponding business event message when the real-time data of the target object simultaneously meets or any of the above-configured attention parameters. It should be understood that users can flexibly combine these parameters according to their own trading strategies to achieve personalized market dynamic early warnings.

[0086] In an optional implementation, the method further includes: providing an alarm clock configuration interface, obtaining the alarm clock creation operation performed in the alarm clock configuration interface, the alarm clock creation operation including setting the reminder time and reminder event; recording the reminder time and reminder event; and when the reminder time arrives, generating a business event message corresponding to the reminder event and displaying it in the aggregation panel. In this way, by providing an independent alarm clock configuration interface, users can freely set personalized reminder times and reminder events, overcoming the limitations of the system's preset activity reminders, meeting users' flexible reminder needs in customized scenarios, and improving information delivery efficiency in multi-tasking scenarios.

[0087] For example, in a game application, a user can select to enter the alarm clock configuration interface from the pop-up basic settings menu, such as... Figure 10 As shown in the image, this interface allows users to create multiple alarms according to their needs, including reminder time, reminder event, and reminder method. This way, even if the game system lacks preset events or activities, users can freely set the reminders they require.

[0088] For example, in an e-commerce management platform, an operations staff member opens the alarm clock configuration interface, creates an alarm reminder, sets the reminder time to 9:00 AM every Monday, and the reminder event to "Weekly Store Operation Data Review". The system records the reminder time and reminder event. When 9:00 AM arrives every Monday, the system generates a "Weekly Store Operation Data Review" business event message, which is displayed in the aggregation panel. After the operations staff member clicks on the message, the system switches to the corresponding store account and opens the data analysis function module interface.

[0089] Optionally, the alarm clock configuration interface can be a desktop-level configuration window independent of the application's main interface, or it can be a sub-interface embedded in the application client's settings panel. Its entry point can be located in the right-click menu of the notification area icon, or in the quick operation area of ​​the aggregation panel. The interface can specifically include a time selection control, an event description input box, and a confirmation button. It should be noted that the specific presentation of the alarm clock configuration interface is not limited to the above example. In actual implementation, it can be adapted and adjusted according to the operating system's interface specifications or the client's UI design style. This application does not intend to limit it in this way. The interface can also provide an alarm clock list area, displaying created alarm clock entries in a list or card format. Each entry displays the reminder time, a summary of the reminder event, and entry points for editing and deleting, facilitating centralized management of existing alarms.

[0090] Optionally, the alarm creation process includes setting the reminder time and setting the reminder event to generate a custom reminder task independent of the system's preset activities. For example, users can set specific hours and minutes using the time selector in the alarm configuration interface and manually type a description of the reminder event in the text input box. The alarm creation process can also support voice input or quick template selection. For example, the system has preset templates for commonly used events such as "Fixed Team Gathering," "Guild Tasks," and "Listing on the Trading Post." Users only need to select a template and adjust the time to quickly complete the creation.

[0091] Optionally, the reminder time is used to trigger the generation of business event messages. It can be accurate to the minute and can also support periodic repetition. Specifically, the reminder time can be set in two ways: absolute time and relative time. In absolute time settings, the user directly specifies a specific date and time, such as 12:15 PM on the current day. The system will trigger a reminder when that time is reached. In relative time settings, the user can specify a trigger time after a certain period from the current time, such as "2 hours later." The system will automatically calculate the target trigger time based on the current time. It should be noted that the reminder time can also support single-trigger and recurring trigger modes. In single-trigger mode, the alarm record is automatically destroyed after the reminder time arrives and a business event message is generated. In recurring trigger mode, reminders are repeatedly generated at fixed times according to daily, weekly, or other cycles. The above description of reminder time setting methods is only one example. This application does not intend to limit the specific configuration form of reminder time; in actual implementation, it can be flexibly combined according to user habits and scenario requirements.

[0092] Optionally, a reminder event describes the specific content of the alarm reminder, which may include text descriptions, associated application identifiers, and custom notes. The content of a reminder event can cover multiple dimensions, not limited to built-in application activity types. For example, in a game application, a reminder event can be custom content related to game social interaction, such as "fixed team gathering for a dungeon run" or "guild pre-battle rally." These events are set by the user according to social conventions and have a high degree of freedom. Reminder events can also be content related to game economic activities, such as "monitored items expected to drop in price" or "street vending time about to expire," helping users seize economic opportunities while multitasking. The above description of reminder event types is merely illustrative, and this application does not intend to limit the specific content scope of reminder events. Any user-defined event information that needs to be prompted at a specified time should be included. One objective of this embodiment is to enable users to supplement reminder settings for custom scenarios without preset reminder mechanisms within the application through flexible alarm creation operations. This increases the freedom of the reminder system and reduces the probability of users missing important custom events.

[0093] In an optional implementation, the method further includes: displaying multiple business event messages under the same login account as summary entries in the aggregation panel; receiving an expand operation on the summary entries to display all business event messages under that login account; and when the total number of business event messages from multiple login accounts exceeds a preset limit, retaining and displaying a preset number of business event messages sorted by importance level and generation time in the aggregation panel. In this way, by collapsing the summary entries and dynamically controlling the quantity limit, the interface congestion problem caused by message overload from multiple accounts is effectively avoided, while ensuring the priority exposure of high-importance messages, thus improving the cleanliness of information browsing and processing efficiency.

[0094] In one implementation, when the same account receives multiple business event messages within a short period, the system aggregates these messages into a single summary entry, such as "Account A has 3 new notifications." Users can tap or long-press the summary entry to expand it, displaying a list of all specific messages for that account. Furthermore, when the total number of messages from multiple accounts surges and exceeds a preset limit, the system automatically truncates and retains only the top N messages sorted by importance level and generation time, displaying a message at the bottom of the panel: "More messages have been collapsed."

[0095] Optionally, summary entries are used to aggregate and display multiple business event messages under the same logged-in account to reduce redundancy in interface elements. These summary entries can be in the form of abbreviated text, overlaid icons, or progress bars. Considering that a large number of messages in a multi-account environment may lead to interface congestion, as a possible implementation, the above-mentioned summary entries can be displayed in the respective account group areas of the aggregation panel. Their display content includes not only message count statistics but also the type icon and brief text of the latest message. It should be noted that the specific presentation of the summary entries can be dynamically adjusted according to the interface layout space. For example, when the panel width is limited, only numerical badges can be displayed; when the panel width is sufficient, a card containing an avatar and a preview of the latest message can be displayed, thus achieving a balance between information density and visual clarity.

[0096] Optionally, the expand operation is used to trigger a state switch for the summary item to display all business event messages under the logged-in account. The expand operation can be a click, hover, or swipe operation on the summary item. To avoid frequent panel jumps caused by accidental touches, the expand operation can be set to an interaction method with a confirmation intent, such as double-clicking or long-pressing. In one specific approach, when an expand operation on a summary item is detected, the system can dynamically generate a sub-list area below the item with a smooth animation transition effect to display all business event messages. It should be understood that the expand operation is not limited to a downward-expanding list; it can also be a pop-up overlay or a side drawer. This application is not limited to these, as long as it can achieve a switch from a collapsed state to a detailed display state.

[0097] Optionally, a preset limit is used to restrict the maximum number of business event messages displayed simultaneously in the aggregation panel. This preset limit can be a system default value or a user-defined value based on their screen resolution and reading habits. Considering the differences in display capabilities across different devices and varying user tolerance for information overload, the above method, when detecting that the total number of messages exceeds the preset limit, will sort them based on importance and generation time and truncate them accordingly. It should be noted that truncated messages are not directly deleted but can be stored in a background cache. When the user finishes processing the currently displayed messages or actively requests to view more, they are dynamically loaded and replaced, ensuring that critical information is not lost and the interface remains clean.

[0098] In step S230, in response to the triggering operation of the target business event message in the aggregation panel, the first application is triggered to switch to the target account corresponding to the target business event message, and the function module interface corresponding to the type of the target business event message is opened.

[0099] In one implementation, such as Figure 11As shown, users can see a friend message notification for the account "Mou Da Xian" on the aggregation panel in the system tray. After clicking the notification, the system will automatically restore the minimized or obscured application client window, seamlessly switch the display interface to the tab corresponding to the account "Mou Da Xian", and automatically open the chat box with the friend. Users do not need to manually switch accounts or find the system entry.

[0100] In another implementation, after a user clicks on the "Account A - Limited-Time Event Coming Soon" reminder in the aggregation panel, the system automatically restores the application client window and switches the display interface to the target account tab of Account A. Then, the event participation interface in that tab is automatically opened, and the user can directly register or participate without having to manually search for the event entry.

[0101] In another implementation, after the operator clicks on the inventory warning message for store B in the aggregation panel, the client application responds to the triggered operation by automatically switching the display interface to the tab corresponding to store B and opening the inventory management function module interface, allowing the operator to directly view and edit the product information of insufficient inventory in store B.

[0102] Optionally, this triggering operation aims to receive a user's selection command for a single message and initiate an automatic cross-account redirection process. The triggering operation for a target business event message in the aggregation panel can be a confirmation command triggered by the user left-clicking a message item, a redirection command selected after bringing up a shortcut menu with the right mouse button, or a single press or double-click gesture in a touch scenario. The specific form of the triggering operation can be adaptively adjusted according to the hardware environment or user habits; this application is not limited to a specific input method.

[0103] Optionally, the target account is used to indicate the specific account tab that the first application needs to respond to or switch to in a multi-account parallel login environment. The process of triggering the first application to switch to the target account can be implemented through an inter-process communication framework (Remote Procedure Call, RPC). Specifically, the process where the aggregation panel resides will send a preset message string to notify the application process through the inter-process communication framework, thereby executing the account tab switching logic. Optionally, if the tab corresponding to the target account has been manually closed by the user, or if the target account is currently unavailable due to permission restrictions or unmet attribute conditions, the system will not push new business event messages to that account to avoid invalid redirection.

[0104] Optionally, the functional module interface is used to present the specific business system or interactive window corresponding to the target business event message. In game applications, the functional module interface can be an instant messaging chat window, a limited-time event registration panel, a character status details page, a virtual trading market inquiry interface, or a harvesting interface corresponding to the maturity prompt of homestead planting, etc., matching the type of the target business event message. In e-commerce management platforms, the functional module interface can be an order management interface, an inventory management interface, a customer service management interface, a marketing data statistics interface, etc. The specific type of functional module interface is determined by the type of the target business event message. If an exception occurs where the target functional module interface fails to open successfully, the system will pop up a redirection failure message to inform the user that the redirection was unsuccessful, and will automatically remove the target business event message from the aggregation panel.

[0105] In an optional implementation, after triggering the first application to switch to the target account corresponding to the target business event message, the method further includes: switching the display interface of the first application to the target account tab corresponding to the target business event message, and opening the functional module interface corresponding to the type of the target business event message in the target account tab. In this way, by automatically switching the display interface to the target account tab and opening the corresponding functional module therein, a seamless jump from desktop notifications to a specified account and system is achieved, significantly reducing the operational burden of manual account switching and navigation for multiple users.

[0106] In one implementation, after a user clicks on the notification item "Account A - Friend XX sent 1 message" in the system tray's aggregated panel, the system automatically restores the minimized or obscured game client window, switches the display interface to the target account tab corresponding to account A, and directly opens the friend system interface and the corresponding friend's chat box on that tab. The user does not need to manually search for account A across multiple tabs or navigate through the game's hierarchical menus; the entire redirection process is automatically completed by the system in the background.

[0107] In another implementation, after the operator clicks on the refund application message for store C in the aggregation panel, the system first restores the client application window from the minimized state to the foreground display, and then switches the display interface to the tab corresponding to store C. In this tab, the refund management function module interface is directly opened and the details page of the refund application is located. The operator does not need to manually switch between store tabs and search for the refund management entry.

[0108] Optionally, the target account tab is used in the single-window multi-account mode of the first application to isolate and display the application interface of different logged-in accounts in tab form, and to serve as a positioning anchor point for deep jumps. The target account tab can be an account isolation unit presented in the same client window of the first application in the form of tabs arranged side by side, with each tab corresponding to an independent logged-in account and its running status. In the "one window, multiple tab accounts" mode, multiple account tabs can be arranged horizontally along the top or side of the window, and users can switch between the screens of different accounts by clicking different tabs. It should be noted that the switching of the target account tab can be automatically executed by the system after receiving the deep jump instruction, without manual intervention from the user. Specifically, the process where the aggregation panel is located sends a preset message string containing the target account identifier and the target functional module identifier to the application process. After the application process parses the string, it switches the currently active tab to the target account tab and loads the corresponding functional module in the interface of that tab. Optionally, if the target account tab has been manually closed by the user, the system will not generate a new reminder message for that account, thereby avoiding invalid jumps.

[0109] In an optional implementation, the method further includes: when the first application fails to open the target function module interface after executing the jump instruction, displaying a jump failure message on the interface of the first application and removing the target business event message from the aggregation panel. This ensures timely feedback to the user on the failure status and automatic cleanup of invalid messages when jump execution fails, preventing users from repeatedly clicking on failure reminders and avoiding wasted time, while also maintaining the validity of the information on the aggregation panel.

[0110] In one implementation, after a user clicks the "Friends Chat" notification message corresponding to account A in the aggregation panel, the system sends a jump command to the application client via inter-process communication, attempting to restore the window and locate the chat interface of account A. If the tab for account A has been manually closed by the user or a network error causes a communication timeout, and the application client fails to successfully open the chat interface, a text message "Jump failed" will pop up on the desktop, and the notification message in the aggregation panel will automatically disappear.

[0111] Optionally, the jump instruction can be a message string generated and sent by the process containing the aggregation panel, transmitted to the application client process via an inter-process communication framework to trigger the logic of account tab switching and opening the functional module interface. It should be noted that the generation and transmission methods of the jump instruction are not limited to the aforementioned inter-process communication methods; cross-process instruction transmission can also be achieved using the operating system's native window message mechanism, shared memory writing, or local sockets, etc. This application does not impose any limitations on this. Furthermore, in addition to containing the target account identifier and the target functional module identifier, the jump instruction can also include extended parameters such as jump priority and timeout threshold, so that the client can determine the execution order and fault tolerance strategy of the jump based on these parameters after receiving the instruction. When multiple notification messages are triggered simultaneously, the jump instruction can also carry a queue identifier, allowing the client to execute multiple jump tasks sequentially in a preset order, avoiding interface conflicts or resource contention issues caused by concurrent jumps.

[0112] Optionally, a redirection failure message is used to provide feedback to the user on the abnormal status when the redirection fails. The message can be presented as a text pop-up, a graphic icon, or a voice broadcast.

[0113] Optionally, the redirection failure message can be presented in various visual forms on the desktop or on the main interface of the currently active account in the first application. These could include a message box with the text "Redirection Failed," a lightweight notification bar with a warning icon at the edge of the interface, or a brief flashing of the screen border. In addition to the failure status indicator, the redirection failure message can also include a description of the reason for the failure, such as "Target account is offline," "Function module not unlocked," or "Communication timeout," helping users quickly determine whether manual intervention is necessary. Simultaneously, while displaying the redirection failure message, the system automatically removes the corresponding target business event message from the aggregation panel, preventing users from repeatedly triggering the failed redirection process by clicking the same failure reminder again, thereby reducing the consumption of system resources by invalid operations.

[0114] Corresponding to the above method embodiments, this invention provides an information processing apparatus. According to one embodiment of this application, the information processing apparatus, such as... Figure 12 As shown, the device may include: The acquisition module is used to acquire business event messages generated by multiple login accounts in the first application. The display module is used to respond to a preset trigger operation for the first application or to detect that a business event message meets the preset reminder conditions, display an aggregation panel, and display business event messages from multiple logged-in accounts in the aggregation panel respectively; The processing module is used to respond to the trigger operation of the target business event message in the aggregation panel, trigger the first application to switch to the target account corresponding to the target business event message, and open the function module interface corresponding to the type of the target business event message.

[0115] This approach, by aggregating and displaying messages from multiple accounts and enabling one-click switching between accounts and accessing corresponding function interfaces, shortens the interaction path and improves message processing efficiency. Simultaneously, it reduces redundant interface rendering and switching commands caused by users frequently restoring windows and manually switching accounts, thus helping to lower terminal resource consumption.

[0116] The specific details of each part of the above-mentioned device have been described in detail in the method section of the implementation plan. For any undisclosed details, please refer to the implementation plan of the method section, and therefore will not be repeated here.

[0117] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to the exemplary embodiments of this application, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0118] Figure 13 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0119] The following is a detailed reference. Figure 13 The diagram illustrates a structural schematic suitable for implementing the electronic device described in the embodiments of this application. The electronic device may include a processor (e.g., a central processing unit, graphics processor, etc.) 1201, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 1202 or a program loaded from memory 1208 into random access memory (RAM) 1203. The RAM 1203 also stores various programs and data required for the operation of the electronic device. The processor 1201, ROM 1202, and RAM 1203 are interconnected via a bus 1204. An input / output (I / O) interface 1205 is also connected to the bus 1204.

[0120] Typically, the following devices can be connected to I / O interface 1205: input devices 1206 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 1207 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; memory devices 1208 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1209. Communication device 1209 allows electronic devices to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 13 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown, and more or fewer devices may be implemented or have instead.

[0121] In particular, according to one embodiment of this application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, one embodiment of this application includes a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via communication device 1209, or installed from memory 1208, or installed from ROM 1202. When the computer program is executed by processor 1201, it performs the functions defined in the methods described above in various embodiments of this application.

[0122] Figure 13 The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0123] This application also provides a computer-readable storage medium. The methods described in this application can be implemented in hardware or firmware, or implemented as recordable on a storage medium, or implemented as computer code downloaded over a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and subsequently stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium may also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code. When the software or computer code is accessed and executed by the computer, processor, or hardware, the methods shown in the above embodiments are implemented.

[0124] A portion of this application can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can invoke or provide the methods and / or technical solutions according to this application through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, installation package files, etc. Correspondingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions, or the computer compiling the instructions and then executing the corresponding compiled program, or the computer reading and executing the instructions, or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.

[0125] Although embodiments of this application have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of this application, and all such modifications and variations fall within the scope defined by the appended claims.

Claims

1. An information processing method, characterized in that, The method includes: Retrieve business event messages generated by multiple login accounts in the first application; In response to a preset trigger operation for the first application or when the business event message is detected to meet a preset reminder condition, an aggregation panel is displayed, and business event messages from the multiple login accounts are displayed in the aggregation panel respectively; In response to a trigger operation on a target business event message in the aggregation panel, the first application is triggered to switch to the target account corresponding to the target business event message and open the functional module interface corresponding to the type of the target business event message.

2. The method according to claim 1, characterized in that, The method further includes: Provide a message display entry point for the first application in the operating system's notification interface; The preset triggering operation for the first application includes the triggering operation for the message display entry.

3. The method according to claim 1, characterized in that, The process of displaying business event messages from the multiple logged-in accounts in the aggregation panel includes: The importance level of the business event message is determined based on the preset mapping relationship between the type and importance level of each business event message, and / or the received importance level configured for the type of each business event message; In the aggregation panel, the business event messages are displayed separately according to their importance level, and then sorted according to their importance level. Within the same importance level, the business event messages are sorted and displayed based on their generation time.

4. The method according to claim 1, characterized in that, The method further includes: In the display state of the aggregation panel, receive quick filtering commands; Based on the filtering dimensions and filtering values ​​corresponding to the quick filtering command, a subset of messages that meet the filtering conditions is filtered from the currently displayed business event messages, and the subset of messages is displayed in the aggregation panel. The filtering dimensions include at least one of the account dimension and the importance dimension.

5. The method according to claim 3, characterized in that, The method further includes: When it is detected that at least two of the multiple login accounts generate the same type of business event message, the importance level of the business event message corresponding to each of the at least two accounts is downgraded. The downgraded business event messages of the at least two accounts are displayed independently in the aggregated panel.

6. The method according to claim 1, characterized in that, The method further includes: Obtain the status data of the business events corresponding to the business event messages displayed in the aggregation panel; When the status data indicates that the business event corresponding to the target business event message has expired, or when the status data indicates that the business event corresponding to the target business event message has been processed in the first application, the target business event message is removed from the aggregation panel. The term "invalid" includes at least one of the following situations: the time-sensitive business event has expired, the object associated with the business event is offline, or the resource associated with the business event is no longer available.

7. The method according to claim 1, characterized in that, The method further includes: When multiple business event messages are detected for the same business event, the previously displayed business event message in the aggregation panel is updated using the later-generated business event message.

8. The method according to claim 1, characterized in that, The method further includes: Detect the target business behavior executed in the first application, determine the time-sensitive target business state corresponding to the target business behavior, and calculate the expected occurrence time of the target business state; Display a prompt message, which includes the expected occurrence time information and reminder creation options; In response to the confirmation of the reminder creation option or the fulfillment of the automatic creation conditions, the expected occurrence time is recorded; When the expected occurrence time arrives, a business event message corresponding to the target business state is generated and displayed in the aggregation panel.

9. The method according to claim 1, characterized in that, After triggering the first application to switch to the target account corresponding to the target business event message, the method further includes: Switch the first application display interface to the target account tab corresponding to the target business event message, and open the function module interface corresponding to the type of the target business event message in the target account tab.

10. The method according to claim 1, characterized in that, The method further includes: Obtain the attention parameter settings for the target object of attention in the first application, wherein the attention parameters include attention quantity conditions and price change conditions; When it is detected that the number of followers of the target object meets the number of followers condition and / or the price meets the price change condition, a corresponding business event message is generated and displayed in the aggregation panel.

11. The method according to claim 1, characterized in that, The step of obtaining business event messages generated by multiple login accounts in the first application includes: The configuration interface receives configuration operations for reminder conditions for each logged-in account, the reminder conditions including the type of business event message and / or reminder parameters; Based on the reminder conditions configured for each login account, obtain business event messages from the plurality of login accounts that meet the reminder conditions; wherein, the type of the business event message includes at least one of time-sensitive tasks, account status changes, social interactions, collaborative matching results, and automatic matching results.

12. The method according to claim 11, characterized in that, The method further includes: The batch application entry is displayed in the configuration interface; Upon receiving a confirmation instruction for the batch application entry, the reminder conditions of the currently logged-in account are applied to all logged-in accounts in the first application.

13. The method according to claim 1, characterized in that, The method further includes: Provide an alarm clock configuration interface, and obtain the alarm clock creation operation performed in the alarm clock configuration interface, the alarm clock creation operation including setting reminder time and reminder event; Record the reminder time and the reminder event; When the reminder time arrives, a business event message corresponding to the reminder event is generated and displayed in the aggregation panel.

14. The method according to claim 1, characterized in that, The method further includes: When the first application fails to open the target function module interface after executing the jump instruction, a jump failure prompt message is displayed in the interface of the first application, and the target business event message is removed from the aggregation panel.

15. The method according to claim 3, characterized in that, The method further includes: In the aggregation panel, multiple business event messages under the same login account are displayed in the form of summary entries; Receive an expand operation for the summary entry and display all business event messages under the logged-in account; When the total number of business event messages from the multiple logged-in accounts exceeds a preset limit, a preset number of business event messages, sorted by importance level and generation time, will be displayed in the aggregation panel.

16. An information processing device, characterized in that, The device includes: The acquisition module is used to acquire business event messages generated by multiple login accounts in the first application. The display module is used to respond to a preset trigger operation for the first application or to detect that the business event message meets the preset reminder conditions, display an aggregation panel, and display business event messages from the multiple login accounts in the aggregation panel respectively; The processing module is used to respond to the trigger operation of the target business event message in the aggregation panel, trigger the first application to switch to the target account corresponding to the target business event message, and open the function module interface corresponding to the type of the target business event message.

17. An electronic device, characterized in that, include: Memory stores computer-executable instructions that can be executed by a processor; A processor for executing the computer-executable instructions to implement the method as claimed in any one of claims 1-15.

18. A computer-readable storage medium, characterized in that, The device contains a computer program that, when executed by a processor, implements the method as described in any one of claims 1-15.

Images