Message display method, transmission method, device, electronic equipment and storage medium

Abstract

The application discloses a message display method, a transmission method, a device, electronic equipment and a storage medium, and belongs to the technical field of networks. According to the application, after a calling interface is popped up on a terminal, in the case that a user does not access a network conference in time due to some reason, a calling notification message is displayed to prompt a missed calling request, and based on the calling notification message, an entrance for quickly joining a target network conference is provided, so that when the user has a demand to enter the network conference with delay, the operation complexity of the user for entering the network conference is reduced, and the human-computer interaction efficiency is greatly improved.

Description

Technical Field

[0001] This application relates to the field of network technology, and in particular to a message display method, transmission method, device, electronic device, and storage medium. Background Technology

[0002] With the increasing prevalence of digital and networked office work, more and more companies are using web conferencing to support users in remote work. In remote work scenarios, the meeting host may initiate a web conference at any time and invite participants to join. However, it often happens that participants are already in another web conference, or that they are unable to join the current web conference for various reasons (such as being on a call, not having their device with them, etc.).

[0003] If a participant misses the invitation to a web conference, they usually need to find the conference identifier in the message history and switch to the web conference client to join the conference. Therefore, when users need to join a web conference late, the process is cumbersome and the human-computer interaction is inefficient. Summary of the Invention

[0004] This application provides a message display method, transmission method, apparatus, electronic device, and storage medium, which can reduce the complexity of entering a web conference and improve the efficiency of human-computer interaction. The technical solution is as follows:

[0005] On the one hand, a message display method is provided, executed by a terminal, the method comprising:

[0006] In response to a call request from a target network conference, the call interface of the target network conference is displayed, wherein the call request is used to invite the account logged into the terminal to join the target network conference;

[0007] If the account does not join the target network conference through the call interface, display the call notification message of the target network conference;

[0008] Based on the call notification message, an entry point for joining the target web conference is displayed.

[0009] On the one hand, a message transmission method is provided, executed by a server, the method comprising:

[0010] Send a call request to the account to be invited associated with the target web conference, the call request being used to invite the account to join the target web conference;

[0011] Set the account's status parameter for the target network conference to "sent" status, whereby the status parameter indicates whether the account has joined the target network conference.

[0012] If the account meets the message push conditions based on the status parameters, a call notification message for the target network conference is sent to the account. The call notification message is used to provide an entry point to join the target network conference.

[0013] On one hand, a message display device is provided, the device comprising:

[0014] The first display module is used to respond to a call request from the target network conference and display the call interface of the target network conference, wherein the call request is used to invite the account logged into the device to join the target network conference;

[0015] The second display module is used to display the call notification message of the target network conference when the account has not joined the target network conference based on the call interface;

[0016] The third display module is used to display an entry point for joining the target web conference based on the call notification message.

[0017] In one possible implementation, the second display module is used for:

[0018] In response to a rejection operation triggered by the call interface, the call notification message is displayed, the rejection operation being used to refuse immediate access to the target web conference.

[0019] In one possible implementation, the device further includes:

[0020] The sending module is used to respond to the rejection operation by sending a status report information carrying the rejected status to the server. The status report information is used to request that the status parameter of the account for the target network conference be set to the rejected status.

[0021] In one possible implementation, the second display module is used for:

[0022] If no answer or reject operation is detected based on the call interface after the target time period, the call notification message is displayed. The answer operation is used to trigger the account to immediately join the target network conference, and the reject operation is used to refuse to immediately join the target network conference.

[0023] In one possible implementation, the second display module includes:

[0024] The display unit is configured to display the call notification message in an application that displays the call interface; or, to display the call notification message in the message push bar of the device, wherein the message push bar is configured to display notification messages of various applications that are active on the device.

[0025] In one possible implementation, the display unit is further configured to:

[0026] The call notification message is displayed in the session interface between the account and the target account that created the target web conference; or,

[0027] The call notification message is displayed in the message list of the account. The message list is used to display session messages or notification messages for the account.

[0028] In one possible implementation, the third display module is used for:

[0029] The call notification message displays the call notification text, the identification information of the target web conference, and an entry point for joining the target web conference. The call notification text is used to provide the account with the historical call records of the target web conference.

[0030] In one possible implementation, the third display module is used for:

[0031] The call notification message displays a call notification text, which is used to provide the account with the historical call records of the target web conference;

[0032] In response to the triggering operation of the call notification message, the identification information of the target web conference and the entry point for joining the target web conference are displayed.

[0033] In one possible implementation, the first display module is further configured to:

[0034] In response to an answering operation triggered by the call interface or a triggering operation on the entry point, the meeting interface of the target network conference is displayed, wherein the answering operation is used to trigger the account to immediately join the target network conference.

[0035] In one possible implementation, the device further includes:

[0036] The sending module is used to respond to the answering operation by sending a status report information carrying the answering status to the server. The status report information is used to request that the status parameter of the account for the target network conference be set to the answering status.

[0037] In one possible implementation, the device further includes:

[0038] The cancel display module is used to cancel the display of the call interface in response to an interface close message sent by the server. The interface close message is used to instruct the call interface to be closed when any terminal logged in to the account responds to the call request.

[0039] In one possible implementation, the first display module is used to:

[0040] In response to the call request, the call interface is displayed if the target web conference has not ended and the account has not joined any web conference.

[0041] In one possible implementation, the second display module is further configured to:

[0042] If another terminal logged into the account responds to the call request, a call response message associated with the response is displayed;

[0043] Specifically, when the response is an answer operation, the call response message is used to prompt the account to join the target network conference on the other terminal; when the response is a reject operation, the call response message is used to prompt the account to refuse to join the target network conference on the other terminal.

[0044] In one possible implementation, the third display module is further configured to:

[0045] Based on the call interface or the call notification message, a transfer entry to the target web conference is displayed, which is used to instruct users to join the target web conference on other terminals logged in with the account.

[0046] In one possible implementation, the third display module is further configured to:

[0047] Display a message reply entry based on the call interface or the call notification message;

[0048] In response to a trigger operation on the message reply entry, at least one preset reply message is displayed;

[0049] The device further includes:

[0050] The sending module is used to send the reply message to the target account that created the target network conference or to each account that joined the target network conference in response to a selection operation on any reply message or an input operation on the reply message.

[0051] On one hand, a message transmission device is provided, the device comprising:

[0052] The sending module is used to send a call request to the account to be invited associated with the target web conference, the call request being used to invite the account to join the target web conference;

[0053] The settings module is used to set the status parameter of the account to the target network conference to the "sent" status, and the status parameter is used to indicate whether the account has joined the target network conference;

[0054] The sending module is further configured to send a call notification message for the target network conference to the account when the account meets the message push conditions based on the status parameters. The call notification message is used to provide an entry point to join the target network conference.

[0055] In one possible implementation, the message push condition includes at least one of the following: within a target duration after sending the call request, the status parameter is set to a rejected state; or, when the target duration is reached after sending the call request, the status parameter is still in the sent state.

[0056] In one possible implementation, the setting module is further configured to: in response to the status reporting information sent by the account, set the status parameter of the account to the answered status or rejected status carried in the status reporting information.

[0057] The sending module is further configured to: send an interface close message to the account, the interface close message being used to instruct each terminal logged in by the account to close the call interface displayed based on the call request.

[0058] In one possible implementation, the sending module is further configured to:

[0059] In response to the status reporting information, a status change instruction is sent to the target account that created the target network conference. The status change instruction is used to instruct the target account to update the status parameters of the account in the conference member list based on the status reporting information.

[0060] In one possible implementation, the meeting member list includes a first member list and a second member list, wherein the first member list is used to display each account that has joined the target network meeting, and the second member list is used to display each account that has been invited but has not yet joined the target network meeting;

[0061] When the status report information carries a "call answered" status, the status change indication information is used to indicate that the account be transferred from the second member list to the first member list;

[0062] If the status report information carries a rejected status, the status change indication information is used to indicate that the calling option of the account is displayed in the second member list, and the calling option is used to trigger the resending of the calling request to the account.

[0063] On one hand, an electronic device is provided, comprising one or more processors and one or more memories, wherein at least one computer program is stored in the one or more memories, and the at least one computer program is loaded and executed by the one or more processors to implement a message display method or a message transmission method as described in any of the above possible implementations.

[0064] On the one hand, a storage medium is provided that stores at least one computer program, which is loaded and executed by a processor to implement a message display method or a message transmission method as described in any of the possible implementations above.

[0065] On one hand, a computer program product or computer program is provided, the computer program product or computer program comprising one or more lines of program code, the one or more lines of program code being stored in a computer-readable storage medium. One or more processors of an electronic device are capable of reading the one or more lines of program code from the computer-readable storage medium, the one or more processors executing the one or more lines of program code, enabling the electronic device to execute the message display method or message transmission method of any of the above possible embodiments.

[0066] The beneficial effects of the technical solutions provided in this application include at least the following:

[0067] After the call interface pops up on the terminal, if a user misses a call request for some reason, a call notification message is displayed to remind them of the missed call request. Based on this call notification message, a quick entry point to join the target online meeting is provided. This reduces the cumbersome operation for users to join the online meeting when they need to join the meeting later, and greatly improves the efficiency of human-computer interaction. Attached Figure Description

[0068] 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.

[0069] Figure 1 This is a schematic diagram illustrating the implementation environment of a message display method provided in an embodiment of this application;

[0070] Figure 2 This is an interactive flowchart of the call request triggering logic provided in an embodiment of this application;

[0071] Figure 3 This is a schematic diagram of a meeting creation interface provided in an embodiment of this application;

[0072] Figure 4 This is a schematic diagram of an account configuration interface provided in an embodiment of this application;

[0073] Figure 5 This is a schematic diagram of a call interface provided in an embodiment of this application;

[0074] Figure 6 This is a schematic flowchart illustrating the triggering process of a call request provided in an embodiment of this application;

[0075] Figure 7 This is an interactive flowchart of the call request triggering logic provided in an embodiment of this application;

[0076] Figure 8 This is a schematic diagram of a member configuration interface provided in an embodiment of this application;

[0077] Figure 9 This is a schematic flowchart illustrating the triggering process of a call request provided in an embodiment of this application;

[0078] Figure 10 This is a flowchart of a message display method provided in an embodiment of this application;

[0079] Figure 11 This is a schematic diagram of a member configuration interface provided in an embodiment of this application;

[0080] Figure 12 This is a schematic diagram of a member configuration interface provided in an embodiment of this application;

[0081] Figure 13 This is a flowchart of a message display method provided in an embodiment of this application;

[0082] Figure 14 This is a schematic diagram of a meeting card message push process provided in an embodiment of this application;

[0083] Figure 15 This is a schematic diagram of the structure of a message display device provided in an embodiment of this application;

[0084] Figure 16 This is a schematic diagram of the structure of a message transmission device provided in an embodiment of this application;

[0085] Figure 17This is a schematic diagram of the structure of a terminal provided in an embodiment of this application;

[0086] Figure 18 This is a schematic diagram of the structure of a server provided in an embodiment of this application. Detailed Implementation

[0087] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0088] In this application, the terms "first," "second," etc., are used to distinguish identical or similar items with essentially the same function. It should be understood that there is no logical or temporal dependency between "first," "second," and "n," nor are they limited in quantity or execution order.

[0089] In this application, the term "at least one" means one or more, and "multiple" means two or more, for example, multiple first positions means two or more first positions.

[0090] The term "including at least one of A or B" in this application refers to the following situations: including only A, including only B, and including both A and B.

[0091] The user-related information (including but not limited to user device information, personal information, behavioral information, etc.), data (including but not limited to data used for analysis, stored data, displayed data, etc.) and signals involved in this application, when applied to specific products or technologies using the methods of the embodiments of this application, are all obtained with the user's permission, consent, authorization, or full authorization from all parties. Furthermore, the collection, use, and processing of related information, data, and signals must comply with the relevant laws, regulations, and standards of the relevant countries and regions. For example, the voice or video data collected when users speak during online meetings involved in this application are obtained with full authorization from all parties.

[0092] The following is a description of the terminology used in the embodiments of this application:

[0093] Cloud computing is a computing model that distributes computing tasks across a resource pool consisting of a large number of computers, enabling various application systems to access computing power, storage space, and information services as needed. The network providing these resources is called the "cloud." From the user's perspective, the resources in the "cloud" are infinitely scalable, readily available, on-demand, and expandable, with payment based on usage.

[0094] As a provider of fundamental cloud computing capabilities, a cloud resource pool platform, often referred to as a cloud platform or IaaS (Infrastructure as a Service), is established. This platform deploys various types of virtual resources within the resource pool for external customers to choose from. The cloud resource pool primarily includes: computing devices (virtualized machines containing operating systems), storage devices, and network devices.

[0095] Based on logical function, a PaaS (Platform as a Service) layer can be deployed on top of the IaaS layer, and a SaaS (Software as a Service) layer can be deployed on top of the PaaS layer. Alternatively, SaaS can be deployed directly on top of IaaS. PaaS is a platform for running software, such as databases and web containers. SaaS refers to various types of business software, such as web portals and bulk SMS senders. Generally speaking, SaaS and PaaS are upper layers compared to IaaS.

[0096] Cloud conferencing is an efficient, convenient, and low-cost form of conferencing based on cloud computing technology. Users only need a cloud conferencing application or an application that supports remote conferencing to quickly and efficiently share voice, data files, and video with teams and clients around the world. The complex technologies involved in data transmission and processing during the meeting are handled by the cloud conferencing service provider. Currently, cloud conferencing mainly focuses on SaaS-based services, including telephone, internet, and video services. Video conferencing based on cloud computing is called cloud conferencing.

[0097] In the era of cloud conferencing, data transmission, processing, and storage are all handled by the computer resources of the video conferencing vendor. Users no longer need to purchase expensive hardware or install cumbersome software. They can simply open the support and log in to the corresponding interface to conduct efficient remote meetings.

[0098] Cloud conferencing systems support dynamic multi-server cluster deployment and provide multiple high-performance servers, significantly improving meeting stability, security, and availability. In recent years, web conferencing has gained popularity due to its ability to greatly improve communication efficiency, continuously reduce communication costs, and upgrade internal management, and is widely used in various fields such as government, transportation, logistics, finance, telecommunications, education, enterprises, and connected vehicles. Undoubtedly, with the application of cloud computing, web conferencing is even more attractive in terms of convenience, speed, and ease of use, and will surely stimulate a new wave of related conferencing applications.

[0099] Web conferencing refers to a multimedia conferencing platform using the internet as a medium. Users can overcome time and geographical limitations to achieve face-to-face communication effects via the internet. Web conferencing is also known as remote collaborative work, utilizing the internet to enable data sharing among multiple users in different locations. Typically, web conferencing systems employ advanced audio and video encoding and decoding technologies to ensure clear voice and video quality. Powerful data sharing capabilities provide users with a wealth of meeting support functions such as electronic whiteboards, web page synchronization, program sharing, synchronized presentation slides, virtual printing, and file transfer. It can comprehensively meet various needs such as remote video conferencing, data sharing, collaborative work, remote business, remote training, and even remote stock trading, thus providing users with an efficient and convenient new communication channel, effectively reducing enterprise operating costs and improving operational efficiency.

[0100] With the increasing prevalence of digital and networked office work, more and more companies are using web conferencing (also known as online meetings, remote meetings, cloud meetings, etc.) to support users working remotely. In remote work scenarios, the meeting host may initiate a web meeting at any time and invite participants to join. However, it often happens that participants are already in another web meeting, or they are unable to join the new meeting for some reason (such as being on a call), or they miss the invitation because their device is not nearby.

[0101] If a participant misses the invitation to a web conference, they usually need to find the conference identifier in the message history and switch to the web conference client to join the conference. Therefore, when users need to join a web conference late, the process is cumbersome and the human-computer interaction is inefficient.

[0102] In view of this, embodiments of this application provide a message display method and a transmission method that, for situations where users are unable to join a web conference or miss a web conference call invitation, display a web conference call notification message on the terminal side and provide users with a quick entry point to join the web conference through the call notification message. This provides a solution to meet the user's need to join a web conference late, allowing users to quickly and conveniently join the web conference through the call notification message, thereby simplifying the process of joining a web conference and improving human-computer interaction efficiency.

[0103] The system architecture involved in the embodiments of this application will be described below.

[0104] Figure 1 This is a schematic diagram illustrating the implementation environment of a message display method provided in an embodiment of this application. See also... Figure 1 The implementation environment includes a first terminal 120, a server 140, and a second terminal 160.

[0105] The first terminal 120 has an application that supports web conferencing installed and running. Optionally, this application may include, but is not limited to, social applications, instant messaging applications, enterprise applications, office applications, browser applications, and remote conferencing applications. This application embodiment does not specifically limit the type of application. The first terminal 120 refers to the terminal used by the first user, who is a user with configuration permissions for the participants in the web conference. For example, the first user may refer to the web conference host, the conference initiator, or the conference creator.

[0106] To illustrate, taking a remote work scenario as an example, an enterprise application is installed on the first terminal 120. The first user (i.e., the meeting host) starts the enterprise application on the first terminal 120 and selects to create a new web conference (e.g., a remote conference to be started at a specified future time) in the enterprise application. Then, the start time and participants are configured for the web conference. For example, the first user selects multiple accounts corresponding to multiple second users from the enterprise address book as the accounts to be invited to the web conference.

[0107] The first terminal 120 and the second terminal 160 communicate directly or indirectly with the server 140 via wired or wireless communication.

[0108] Server 140 includes at least one of a single server, multiple servers, a cloud computing platform, or a virtualization center. Server 140 provides background services for applications supporting web conferencing. Optionally, server 140 undertakes the primary computing task, while the first terminal 120 and the second terminal 160 undertake secondary computing tasks; or, server 140 undertakes secondary computing tasks, while the first terminal 120 and the second terminal 160 undertake the primary computing tasks; or, server 140, the first terminal 120, and the second terminal 160 collaborate on computing using a distributed computing architecture.

[0109] Optionally, server 140 may be an independent physical server, a server cluster or distributed system consisting of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDN), and big data and artificial intelligence platforms.

[0110] Schematic example, taking a remote work scenario, after a first user creates a web conference using a first terminal 120, the server 140 stores the start time of the web conference and a list of accounts to be invited. When the start time of the web conference arrives, or at a preset time (e.g., 5 minutes before the start time), the server 140 automatically triggers a call request to each of the invited accounts. The preset time is any value greater than 0. In some embodiments, after the web conference has started, some second users may not join the target web conference on time. If the first user, while the web conference is in progress, triggers a re-invitation for late second users, or if the first user can select the account of a new user they want to invite from the company address book as an invited account, the server immediately sends a call request to the newly added invited account. The processing logic for the call request will be described in detail in subsequent embodiments and will not be repeated here.

[0111] The second terminal 160 has an application that supports web conferencing installed and running. Optionally, this application may include, but is not limited to, social applications, instant messaging applications, enterprise applications, office applications, browser applications, and remote conferencing applications. This embodiment does not specifically limit the type of application. The second terminal 160 refers to the terminal used by the second user. The second user refers to a user who has the right to participate in the web conference and is different from the first user. For example, the second user refers to any participant in the web conference other than the conference host.

[0112] Schematic example, taking a remote work scenario, the second user launches the web conferencing application on the second terminal 160. After receiving a call request for the web conferencing from the server 140 through this application, the call interface of the web conferencing is displayed on the second terminal 160. This call interface displays answer and reject options, allowing the second user to immediately join the web conferencing by answering or temporarily refuse to join by rejecting. Optionally, after the second user clicks the answer option, if the application itself has built-in web conferencing function modules (such as audio and video calls, screen sharing, file transfer, sending chat messages, etc.), the web conferencing interface is directly displayed in the application. Alternatively, if the second terminal 160 also has a dedicated conferencing application installed, it is also permissible to use this application to launch a third-party conferencing application in the background after full authorization from all parties, thereby switching to the conferencing application to participate in the web conferencing. This embodiment does not specifically limit the participating application.

[0113] Optionally, the applications installed on the first terminal 120 and the second terminal 160 are the same, or the applications installed on the two terminals are the same type of application on different operating system platforms, or the applications installed on the two terminals are different versions of the same type of application developed for different models of terminals. For example, if the first terminal 120 is a desktop computer, then a PC (Personal Computer) application is installed, and if the second terminal 160 is a smartphone, then a mobile application is installed.

[0114] The first terminal 120 or the second terminal 160 generally refers to one of a plurality of terminals. This application embodiment uses only the first terminal 120 and the second terminal 160 as examples. The device types of the first terminal 120 and the second terminal 160 may be the same or different. These device types include, but are not limited to, smartphones, tablets, laptops, desktop computers, smart speakers, smartwatches, in-vehicle terminals, smart home appliances, and smart voice interaction devices. The following embodiments use smartphones as an example.

[0115] The message display method described in this application can be applied to various scenarios, including but not limited to: cloud computing, artificial intelligence, smart transportation, and assisted driving.

[0116] Those skilled in the art will understand that the number of terminals described above can be more or less. For example, there may be only one terminal, or there may be dozens or hundreds of terminals, or even more. This application does not limit the number of terminals or the type of device.

[0117] Based on the above system architecture, this application embodiment relates to a scheme for pushing call notification messages to accounts that have not joined a network conference when the user has not joined the conference (e.g., the user rejects the conference call request, or the request times out because the user did not answer / reject the call request). This is achieved by maintaining status parameters on the server side and using a mechanism based on the terminal reporting status and the background periodically triggering status query tasks. For example, the call notification message can be a conference card message. Since the conference card message does not require the user to provide immediate feedback online like a call request, it is also called an offline conference card. Of course, the call notification message can also be a chat notification message in the application, a service notification message in the message push bar, etc. This application embodiment does not specifically limit the message type of the call notification message.

[0118] In the above-mentioned call notification message push scheme, since the push logic for the call notification message is triggered only when the user receives the call request on the terminal side but does not join the network conference, the following embodiments will first introduce the call request triggering logic before introducing the message display method of this application embodiment. Simply put, after the first user creates the target network conference, the account corresponding to the second user is set as the account to be invited in the target network conference. When the target network conference is about to start, the server will push a call request to the terminal logged in by the second user's account. This call request is used to invite the second user's account to join the target network conference. The call request is also called the conference ringing.

[0119] In this embodiment, the scenario is that after a first user pre-creates a target network conference and configures accounts to be invited, the server creates a scheduled task to trigger a push call request to the accounts to be invited. In other embodiments, since the first user may still have the need to invite new users to join the conference after the target network conference has started, or may have the need to re-invite users who have already been invited but have not yet joined the target network conference, the server will push a call request to the corresponding newly added account or the account to be invited during the conference (without generating a scheduled task). This will be described in detail in the next embodiment.

[0120] Figure 2 This is an interactive flowchart of the call request triggering logic provided in an embodiment of this application, such as... Figure 2 As shown, the call request triggering logic involves the interaction of four parties: the first terminal, the second terminal, the message server, and the conference server. Specifically, in the system architecture of the above embodiment, server 140 is a server cluster integrating the message server and the conference server. The message server provides message push and message processing services, while the conference server provides various services for web conferencing. The call request triggering process includes the following steps:

[0121] 201. The first terminal sends a conference ticket request to the message server, which carries one or more invitation accounts specified for the target web conference.

[0122] The first terminal refers to the terminal used by the first user. The first user refers to a user who has configuration permissions for the participants in the online meeting. For example, the first user refers to the host, initiator, or creator of the online meeting.

[0123] The first terminal has an application that supports web conferencing installed and running. For example, the application may include, but is not limited to, social applications, instant messaging applications, enterprise applications, office applications, browser applications, remote conferencing applications, etc. The embodiments of this application do not specifically limit the type of application.

[0124] In some embodiments, a first user launches the web conferencing-enabled application on a first terminal, logs in to the target account within the application, and then enters the meeting creation interface. This interface provides configuration options for participants. The first user executes a trigger operation on these configuration options to configure the various invited accounts allowed to participate in the target web conferencing. For example, after selecting one or more invited accounts, the first user performs a batch confirmation operation on those accounts, triggering the first terminal to send a meeting ticket request to the message server. Typically, the meeting ticket request carries at least the account identifiers of the selected one or more invited accounts. Optionally, the meeting ticket request also carries the account identifier of the target account corresponding to the first user. Here, the target web conferencing refers to the web conferencing to be created.

[0125] To illustrate, in a remote work scenario, taking this application as an enterprise application as an example, the meeting host, i.e. the first user, starts the enterprise application and switches to the meeting creation interface through the meeting creation function. In the meeting creation interface, it supports the configuration of the start time of the target network meeting, the meeting duration, the meeting type (including audio conference and audio-visual conference), the accounts to be invited, and other meeting information.

[0126] Figure 3 This is a schematic diagram of a meeting creation interface provided in an embodiment of this application, such as... Figure 3As shown, the meeting creation interface 300 includes a meeting name editing field 301, a configuration option for invited accounts 302, a start time setting field 303, a meeting duration setting field 304, a meeting type switch option 305, meeting settings options 306, a meeting room configuration option 307, a calendar expansion option 308, an information expansion option 309, and a create option 310. The meeting name editing field 301 is used to edit the meeting name; the configuration option for invited accounts 302 is used to configure the accounts to be invited to the meeting; the start time setting field 303 is used to set the start time of the meeting (e.g., "Today, December 31st, 21:30"); and the meeting duration setting field 304 is used to set the meeting duration (e.g., 1 hour). To illustrate, since all-day meetings occur frequently, an all-day meeting switch option 3041 is also provided. When the all-day meeting switch option 3041 is enabled, it is not necessary to set the meeting duration through the meeting duration setting field 304, which is convenient for the first user. The system allows for quick configuration of the meeting duration for all-day meetings. Additionally, the meeting type switch option 305 configures whether the web conference is an audio or video conference (e.g., when enabled, it's a video conference; when disabled, it's an audio conference). The meeting settings option 306 sets other relevant configuration information for the web conference. The meeting room configuration option 307 configures which meeting room the web conference is associated with. The calendar expansion option 308 allows users to view the meeting schedule calendar, enabling them to see available times and avoid scheduling conflicts. The more information expansion option 309 allows users to view more meeting information (e.g., uploaded meeting materials, meeting images, or other data files). Furthermore, the meeting creation interface 300 includes a creation option 310. This creation option 310 triggers the first terminal to send a meeting creation request to the meeting server after the first user has configured all the information for the target web conference (see step 203 for detailed creation instructions).

[0127] In some embodiments, the meeting creation interface includes configuration options for the accounts to be invited. The first user triggers this configuration option to enter the account configuration interface. This interface allows selection of various accounts associated with the target account. For example, it supports selecting accounts within the same group chat (i.e., account group) as the target account, accounts of colleagues or clients in the company's address book, accounts on the target account's social relationship chain within the application and other related social applications, and accounts of the target account's most recent contacts within the application. This embodiment does not specifically limit the source of the invited accounts. For instance, the account configuration interface includes a confirmation option. After configuring each invited account in the account configuration interface, the first user triggers this confirmation option, which is equivalent to confirming the selected invited accounts. This triggers the first terminal to send the meeting ticket request to the message server.

[0128] Figure 4 This is a schematic diagram of an account configuration interface provided in an embodiment of this application, such as... Figure 4 As shown, the account configuration interface 400 includes a contact search bar 401, a group chat selection option 402, a customer selection option 403, a corporate address book selection option 404, a related corporate address book selection option 405, a recent contacts display bar 406, and a confirmation option 407. The contact search bar 401 is used to search for the contact account to be invited. The group chat selection option 402 triggers the selection of the invited account from the group chat where the target account is located. The customer selection option 403 triggers the selection of the invited account from the customer contacts. The corporate address book selection option 404 triggers the selection of the invited account from the address book of the target account's own company. The related corporate selection option 405 triggers the selection of the invited account from the authorized contact person accounts of other companies related to the target account. The recent contacts display bar 406 displays the target account's recent contacts and provides selection controls. The confirmation option 407 triggers a confirmation operation after the first user has configured each invited account, thus facilitating a return to the meeting creation interface to continue configuring other meeting-related information.

[0129] In some embodiments, the first terminal encapsulates the request identifier of the conference ticket request in the header field of the message. Then, it generates a list of invited accounts containing the account identifiers of each invited account, and then encapsulates the list of invited accounts in the data field of the message. When the conference ticket request also carries the account identifier of the target account, the account identifier of the target account also needs to be encapsulated in the data field. Then, the message is encapsulated using a preset protocol, the encapsulated message is compressed, the compressed message is encrypted, and finally the encrypted message (i.e., the conference ticket request) is sent to the server.

[0130] Optionally, the preset protocol used to encapsulate the message includes TCP (Transmission Control Protocol), UDP (User Datagram Protocol), IP (Internet Protocol), or other network data transmission protocols. This application embodiment does not specifically limit the protocol type of the preset protocol.

[0131] Optionally, the compression algorithm used to compress the message includes LZ77, LZ78, LZSS, Base64, etc. This application embodiment does not specifically limit which compression algorithm is used.

[0132] Optionally, the encryption algorithm used in the encrypted message includes symmetric encryption algorithms or asymmetric encryption algorithms. For example, symmetric encryption algorithms include DES (Data Encryption Standard), TDEA (Triple Data Encryption Algorithm), IDEA (International Data Encryption Algorithm), Blowfish algorithm, RC5 block cipher algorithm, etc. Asymmetric encryption algorithms include RSA encryption algorithm, Elgamal encryption algorithm, knapsack algorithm, Rabin encryption algorithm, ECC (Elliptic Curve Cryptography), etc. This application embodiment does not specifically limit which encryption algorithm is used.

[0133] It should be noted that the above compression or encryption process is optional. That is, the first terminal may not compress the encapsulated message, may not encrypt the encapsulated message, or may neither compress nor encrypt the encapsulated message, thereby simplifying the transmission process of the conference ticket request. This application embodiment does not specifically limit whether the message is compressed or encrypted.

[0134] 202. In response to the meeting ticket request, the message server returns a meeting ticket generated for the one or more invited accounts to the first terminal. The meeting ticket is used to verify the account's participation permission for the target network meeting.

[0135] In some embodiments, when the message server receives any request, if the received request is decrypted, it uses the decryption algorithm corresponding to the encryption algorithm to decrypt the request; if the received request is compressed, it uses the decompression algorithm corresponding to the compression algorithm to decompress the request, finally obtaining a message encapsulated using a preset protocol. Then, the header field of the message is parsed. If the header field carries a request identifier for a meeting ticket request, it is determined that the request is a meeting ticket request. Then, the data field of the message is parsed to obtain a list of accounts to be invited.

[0136] In some embodiments, the message server generates a key-value data structure based on the list of accounts to be invited. The key is a string generated for the target web conference, and the value is the list of accounts to be invited. The message server then stores this key-value data structure and uses the key as the conference ticket for the target web conference. Since the key allows retrieval of the corresponding list of accounts to be invited within the key-value data structure, the system can verify whether the recipient's account has the necessary permissions to participate in the target web conference by comparing the account identifier received with the list of accounts retrieved based on the conference ticket.

[0137] In some embodiments, after generating a conference ticket in the manner described above, the message server encapsulates the conference ticket in a response message to the conference ticket request, encapsulates the response message using a preset protocol, and after compression and encryption, returns a compressed and encrypted response message to the first terminal. The encapsulation, compression, and encryption process is similar to that described in step 201 above, and will not be repeated here.

[0138] In some embodiments, since the same account to be invited may have different account identifiers in the message server and the conference server, or for data privacy and security reasons, the message server may not want to expose the account identifier internally to the external conference server. In addition to generating conference tickets, the message server can also map the account identifier of each account in the invitation list to another external identifier based on a preset mapping algorithm. For example, the account identifier of each account to be invited internally in the message server is denoted as VID, and the external identifier exposed to the external conference server is denoted as OpenID. Then, based on the VID of each account to be invited, a unique external identifier OpenID can be obtained by mapping through the preset mapping algorithm. The data type of the account identifier includes Uint64 (unsigned 64-bit integer, occupying 8 bytes), Int64 (signed 64-bit integer, occupying 8 bytes), String, or other data types. For example, the data type of VID is Uint64, and the data type of OpenID is String. This application embodiment does not specifically limit the data type of the account identifier.

[0139] In some embodiments, after the message server maps each VID in the list of invited accounts to an OpenID, it is equivalent to converting the list of invited accounts from a list of VIDs into a list of OpenIDs. Optionally, the message server encapsulates the mapped list of OpenIDs and the meeting ticket together into a response message and returns it to the first terminal, which can increase data security and help better protect privacy.

[0140] 203. The first terminal sends a meeting creation request to the meeting server. The meeting creation request is used to create the target network meeting. The meeting creation request carries the meeting ticket and one or more accounts to be invited.

[0141] In some embodiments, after receiving the response message from the message server in response to the conference ticket request, the first terminal parses the response message to obtain the conference ticket for the target network conference. Optionally, if the response message also carries an OpenID list, parsing the response message can obtain both the conference ticket and the OpenID list. The message parsing process is similar to the process described in step 202 above, and will not be repeated here.

[0142] In some embodiments, since the meeting ticket is requested by the first user after configuring all the invited accounts for the target network conference, the first terminal returns to the meeting creation interface from the account configuration interface. The first user can continue to configure the meeting name, start time, meeting duration, meeting type (including audio and video conferencing), and other meeting information of the target network conference in the meeting creation interface. Alternatively, the first user can also re-edit the configured invited accounts (e.g., add new accounts, delete existing accounts, etc.). Each re-editing requires sending a meeting ticket request to the message server again to apply for the meeting ticket, which is similar to the process of applying for the meeting ticket for the first time, and will not be described in detail here. After the first user has set all the meeting information of the target network conference, the first user can perform a trigger operation on the create option (or save option) in the meeting creation interface, thereby triggering the first terminal to send a meeting creation request to the meeting server. The meeting creation request includes at least a meeting ticket and a list of accounts to be invited. Optionally, the meeting creation request also includes meeting description information set by the first user. The meeting description information includes, but is not limited to: meeting name, start time, meeting duration, meeting type (including audio conference and audio-visual conference) and other meeting information (such as uploaded meeting files). This application embodiment does not specifically limit which data is included in the meeting description information.

[0143] In some embodiments, if the response message does not carry an OpenID list, the first terminal directly encapsulates the conference ticket, the original VID list, and the conference description information into a conference creation request and sends the conference creation request to the conference server, thereby eliminating the need for the message server to generate an OpenID list and saving the message server's processing resources.

[0144] In some embodiments, if the response message carries an OpenID list, the first terminal can encapsulate the parsed meeting ticket, the OpenID list, and the meeting description information into a meeting creation request and send the meeting creation request to the meeting server. This avoids the message server exposing the original VID list to external meeting servers, thereby improving data security and privacy. This application embodiment does not specifically limit whether the list of accounts to be invited in the meeting creation request is a VID list or an OpenID list. The process of sending the meeting creation request is similar to the process of sending the meeting ticket request in step 201 above, and will not be described in detail here.

[0145] It should be noted that since the first user may edit the list of accounts to be invited multiple times, and each time a new account is added, the first terminal will apply for a new meeting ticket, when the first terminal applies for multiple meeting tickets for the target network meeting, the first terminal needs to encapsulate all of the multiple meeting tickets in the meeting creation request. At the same time, the encapsulated list of accounts to be invited is also the union of the full list of multiple accounts to be invited, so as to avoid missing any newly added accounts to be invited.

[0146] 204. In response to the conference creation request, the conference server creates the target network conference and returns the identification information assigned to the target network conference to the first terminal.

[0147] In some embodiments, the conference server receives the conference creation request, parses the request to obtain a conference ticket, a list of invited accounts (which may be a list of VIDs or OpenIDs), and conference description information. Then, based on the parsed conference ticket, the server authenticates each invited account in the received list, discarding those that fail authentication. Combining the remaining authenticated invited accounts with the conference description information, the server creates the target network conference and assigns a unique identifier (e.g., a conference identifier, i.e., a conference ID) to it. The conference server returns this identifier to the first terminal. The message parsing process is similar to step 202, and the message encapsulation process is similar to step 201; therefore, they will not be described in detail here.

[0148] In some embodiments, during the authentication process, the conference server sends a query request carrying the conference ticket to the message server. The message server responds to the query request. Since the query request may carry one or more conference tickets, for each conference ticket, the conference ticket is used as the key. The corresponding value is queried from a pre-stored key-value data structure to obtain the list of VIDs stored in the value. After traversing all conference tickets in the query request, one or more VID lists can be obtained. The message server integrates all the retrieved VID lists to obtain a union of all VID lists (if there is only one VID list, then obtaining the union is unnecessary). Here, the union of all VID lists... The set is called the target VID list. Optionally, if the message server and the conference server communicate using a VID list, the message server returns the target VID list to the conference server. The conference server receives the target VID list returned by the message server in response to the query request, and then, for each VID in the list of invited accounts (also a VID list) parsed from the conference creation request, it determines whether the VID can be matched with the same VID in the target VID list. If it can be matched, it means that the current VID has passed the authentication verification, and the process continues to traverse the next VID. If it cannot be matched, it means that the current VID has not passed the authentication verification (e.g., the VID's participation permission has expired), and the current VID is discarded, and the process continues to traverse the next VID.

[0149] In some embodiments, during the authentication process, if the message server and the conference server communicate using an OpenID list, the message server, after obtaining the target VID list, maps each VID in the target VID list to its corresponding OpenID, ultimately obtaining a target OpenID list. The message server returns this target OpenID list to the conference server. The conference server receives the target OpenID list returned by the message server in response to the query request, and then, for each OpenID in the list of invited accounts (also an OpenID list) parsed from the conference creation request, determines whether the OpenID can be matched with the same OpenID in the target OpenID list. If a match is found, it means that the current OpenID has passed authentication, and the process continues to iterate over the next OpenID. If a match is not found, it means that the current OpenID has not passed authentication (e.g., the OpenID's participation permission has expired), and the process discards the current OpenID, continuing to iterate over the next OpenID.

[0150] 205. At the ringing time corresponding to the target network conference, the conference server sends a ringing push request to the message server. The ringing push request carries the conference ticket and the one or more accounts to be invited. The ringing push request is used to request the message server to push a call request to the accounts to be invited.

[0151] In some embodiments, after the conference server generates identification information for the target network conference and returns the identification information to the first terminal, if the first user sets a ringing time when creating the target network conference (e.g., equal to the start time of the target network conference, or 5 minutes before the start time), the conference description information in the conference creation request sent by the first terminal will carry the ringing time. If the conference server parses the ringing time set by the first user, then when the ringing time set by the first user is reached, the conference server sends the ringing push request to the message server.

[0152] In some embodiments, if the first user does not set a ringing time when creating the target network conference, the field corresponding to the ringing time in the conference description information of the conference creation request sent by the first terminal will carry a default value or default value. When the ringing time obtained by the conference server is the default value or default value, the conference server uses the start time of the target network conference as the default ringing time, or uses the time indicated by the preset duration before the start time as the default ringing time, so that when the default ringing time is reached, the conference server sends the ringing push request to the message server.

[0153] In some embodiments, for a target network conference, after determining the ringing time or default ringing time set by the first user, the conference server registers a timed task in a timer. The timed task is used to trigger the sending of the ringing push request to the message server at the ringing time set by the first user or the default ringing time.

[0154] In some embodiments, the ringing push request carries at least the full set of conference tickets corresponding to the target network conference and a full list of invited accounts. The full list of invited accounts refers to the list of account identifiers of all invited accounts that have passed authentication verification after the conference server performs authentication verification in step 204. Specifically, when the message server and the conference server communicate using a VID list, the full list of invited accounts is a VID list composed of the VIDs of all invited accounts that have passed authentication verification; when the message server and the conference server communicate using an OpenID list, the full list of invited accounts is an OpenID list composed of the OpenIDs of all invited accounts that have passed authentication verification. This embodiment does not specifically limit the scope of the request. The message encapsulation process of the ringing push request is similar to step 201 and will not be described in detail here.

[0155] 206. In response to the ringing push request, the message server pushes the call request to the second terminal logged in by each account to be invited. The call request is used to invite the corresponding account to join the target network conference.

[0156] In some embodiments, after receiving the ringback push request, the message server can create a message queue (MQ, also known as a message queue) to handle the potentially massive number of ringback push requests from various network conferences simultaneously. This message queue is a container used to store messages during transmission and is used to asynchronously execute the received ringback push requests from each network conference. The message server then adds the received ringback push request to the tail of the message queue. Since the message queue has a first-in, first-out (FIFO) characteristic, it only needs to process each ringback push request stored in the message queue sequentially, thus reducing the possibility of performance degradation when a large number of ringback push requests are received simultaneously.

[0157] In some embodiments, when the ringing push request for the target network conference is at the head of the message queue, the message server parses the ringing push request to obtain the full set of conference tickets and the full list of accounts to be invited corresponding to the target network conference. Then, using the parsed full set of conference tickets, the message server performs authentication verification on the parsed full list of accounts to be invited. The authentication verification process is similar to that described in step 204 above, and will not be repeated here. For each account to be invited that passes the authentication verification, the message server pushes the call request to the second terminal that is logged into the account to be invited.

[0158] To illustrate, the received full list of invited accounts is the target OpenID list. The server uses the full set of conference tickets as the key and queries the VID list stored in the value of the key-value data structure corresponding to each conference ticket. The union of all the retrieved VID lists is taken as the target VID list. Then, each OpenID in the target OpenID list obtained above is reverse mapped to obtain the corresponding VID. Next, it checks whether the reverse mapped VID is in the target VID list. If it is in the target VID list, a call request is sent to the second terminal logged in by the account indicated by the current VID. If it is not in the target VID list, the current VID is discarded or skipped.

[0159] 207. The second terminal responds to the call request and displays the call interface of the target network conference.

[0160] The second terminal refers to the terminal used by the second user. The second user is a user who has the right to participate in the online meeting and is different from the first user. For example, the second user is any participant in the online meeting other than the meeting host.

[0161] The second terminal has an application that supports web conferencing installed and running. For example, the application may include, but is not limited to, social applications, instant messaging applications, enterprise applications, office applications, browser applications, remote conferencing applications, etc. This application embodiment does not specifically limit the type of application.

[0162] In some embodiments, after receiving the call request, the second terminal displays the call interface so that the second user can quickly enter the target network conference through the call interface, or the second user can reject the target network conference, thereby providing a way to quickly enter the target network conference.

[0163] In some embodiments, when the second terminal receives a call request, the second user may be in a meeting, or the target network meeting may have already ended. In such cases, displaying the call interface might negatively impact the user experience. Therefore, in response to the call request, the second terminal does not directly display the call interface. Instead, it sends a meeting status query request to the message server. This request carries at least the identification information of the target network meeting (such as the meeting ID) and the account identifier of the account to be invited that logged into the second terminal. In response to the meeting status query request, the message server uses the identification information of the target network meeting to query the meeting status of the target network meeting from the meeting server, obtaining the meeting status query result. Simultaneously, using the account identifier of the account to be invited, the system queries the meeting server to determine whether the account is currently in any online meeting, obtaining the participation status query result. Then, the message server returns the meeting status query result and the participation status query result to the second terminal. The second terminal only displays the call interface if the meeting status query result indicates that the target online meeting has not ended and the participation status query result indicates that the account to be invited is not currently in any online meeting. In other words, the second terminal will only display the call interface if the target online meeting has not ended and the account logged into the second terminal has not joined any online meeting, thereby optimizing the pop-up logic of the call interface and improving the user experience of the second user.

[0164] In some embodiments, the call interface provides answer and reject options. When the second user performs an operation to answer the call, they can enter the meeting interface of the target web conference with one click and participate in the target web conference. When the second user performs an operation to reject the call, they will not be redirected to the meeting interface of the target web conference, thus avoiding interruption of the second user's running process.

[0165] Figure 5 This is a schematic diagram of a call interface provided in an embodiment of this application, such as... Figure 5 As shown, the call interface 500 includes a meeting information area 501, an answer option 502, and a reject option 503. The meeting information area 501 is used to display the meeting information of the target network meeting, such as: the meeting name of the target network meeting, the account nickname of the meeting host (i.e., the first user), the number of participants, etc. The answer option 502 is used to trigger immediate joining of the target network meeting, and the reject option 503 is used to trigger rejection of immediate joining of the target network meeting.

[0166] All of the above-mentioned optional technical solutions can be combined in any way to form optional embodiments of this disclosure, and will not be described in detail here.

[0167] In this embodiment, a method is provided whereby a first user pre-creates a target network conference on a conference server and configures the accounts to be invited. The conference server, based on a scheduled task, triggers a push call request to each account to be invited via a message server at the ringing time. This allows a second user to be invited to the target network conference in a timely manner via a call request at the ringing time. This eliminates the need for the second user to manually search for the conference ID and enter the conference password in the application to join the conference. Instead, the second user can join the conference with a single click by answering the call through the call interface, greatly improving the efficiency of human-computer interaction.

[0168] Because the message server and the conference server can handle different user loads under this architecture, the computing load of the server is greatly reduced. In some embodiments, the message server and the conference server can also be integrated into the same physical machine to save communication overhead between different servers.

[0169] The following will take the communication between the message server and the conference server using OpenID as an example to introduce a possible implementation of the call request triggering process in the above embodiments. Figure 6 This is a schematic flowchart illustrating the triggering process of a call request provided in an embodiment of this application, such as... Figure 6 As shown, the call request triggering logic involves the interaction of four parties: the first terminal, the second terminal, the message server, and the conference server. The call request triggering process includes the following steps:

[0170] 601. The first terminal sends a conference ticket request to the message server. The conference ticket request carries a list of VIDs consisting of the VIDs of each account to be invited in the target web conference.

[0171] Step 601 above is similar to step 201 above, and will not be described in detail here.

[0172] 602. In response to the conference ticket request, the message server generates a conference ticket and a list of OpenIDs mapped from the VID list, based on the VID list.

[0173] 603. The message server returns the meeting tickets and OpenID list to the first terminal.

[0174] Steps 602-603 above are similar to step 202 above, and will not be repeated here.

[0175] 604. The first terminal sends a meeting creation request to the meeting server, which carries the meeting ticket and OpenID list.

[0176] Step 604 above is similar to step 203 above, and will not be described in detail here.

[0177] 605. In response to the conference creation request, the conference server creates the target network conference and returns the identification information of the target network conference to the first terminal.

[0178] Step 605 above is similar to step 204 above, and will not be described in detail here.

[0179] 606. At the ringing time corresponding to the target network conference, the conference server sends a ringing push request to the message server. The ringing push request carries the full number of conference tickets and the full list of OpenIDs.

[0180] Step 606 above is similar to step 205 above, and will not be described in detail here.

[0181] 607. The message server returns a confirmation message to the conference server regarding the ringing push request.

[0182] For example, the acknowledgment message is an ACK (Acknowledge Character) message.

[0183] 608. The message server adds the ringing push request to the message queue.

[0184] In other words, the message server delivers the asynchronous task of the ringing push request to the message queue (MQ).

[0185] 609. When the message server processes the ringing push request in the message queue, it uses a full meeting ticket query to obtain a full list of VIDs.

[0186] 610. The message server determines the final list of VIDs to be pushed based on the full list of VIDs obtained from the query and the VID list obtained by reverse mapping based on the full list of OpenIDs.

[0187] In other words, for each OpenID in the full list of OpenIDs, the corresponding VID is obtained through inverse mapping. Then, the full list of VIDs obtained in step 609 above is checked to see if there is a matching VID. If there is a matching VID, the current VID is added to the list of VIDs to be pushed. If there is no matching VID, the current VID is skipped and the next VID obtained through inverse mapping is traversed.

[0188] 611. The message server pushes a call request to the second terminal logged in by the account corresponding to each VID in the list of VIDs to be pushed.

[0189] Steps 607-611 above are similar to step 206 above, and will not be described in detail here. This call request is also called a ringing message.

[0190] 612. Message server registration ringing timeout check asynchronous task.

[0191] The asynchronous task for ringing timeout detection checks the account's status parameters after a target duration has been reached following the push of a call request to that account. These status parameters help determine whether the message push conditions for a call notification message are met. The relevant processing logic will be described in detail in subsequent embodiments. The target duration is any value greater than or equal to 0.

[0192] 613. In response to the call request, the second terminal sends a meeting status query request to the message server.

[0193] The meeting status query request should at least carry the identification information of the target web conference (such as the meeting ID) and the VID of the account logged into the second terminal.

[0194] 614. In response to the meeting status query request, the message server queries the meeting status of the target network meeting from the meeting server.

[0195] For example, the message server sends a first query request carrying the conference ID to the conference server.

[0196] 615. The conference server returns the conference status query results to the message server.

[0197] For example, in response to the first query request, the conference server queries the conference status of the target network conference using the conference ID. The conference status is used to indicate whether the target network conference has ended. The server then returns the query result of the conference status to the message server.

[0198] 616. The message server queries the meeting status of the account logged into the second terminal from the meeting server.

[0199] For example, the message server maps the VID of the account logged into the second terminal to obtain the corresponding OpenID, and sends a second query request carrying the OpenID to the conference server.

[0200] 617. The conference server returns the meeting status query results to the message server.

[0201] For example, in response to the second query request, the conference server queries the participation status of the corresponding account through the OpenID. The participation status is used to indicate whether the account is currently in any online conference, and returns the query result of the participation status to the message server.

[0202] 618. The message server returns the meeting status query results and the participation status query results to the second terminal.

[0203] 619. The second terminal displays the call interface if the target network conference has not ended and the corresponding account is not in any network conference.

[0204] The second terminal only displays the call interface if the target online meeting has not ended and the corresponding account is not in any online meeting. Essentially, upon receiving a call request, the message server in the background queries the meeting server, and the returned query structure determines whether a call interface should be displayed. For example, there's no need to display the call interface if the target online meeting has already ended, or if the second user's account has already joined an online meeting.

[0205] In one example, the second user is in another meeting. If a call interface pops up, it would interrupt the second user from listening to the other meeting or from speaking in the other meeting, causing a significant negative impact on the user experience. Therefore, it is not necessary to pop up a call interface in this case.

[0206] In another example, where multiple devices can log in to the same account, the second user may have already joined the target web conference on another device. In this case, since the second user is already in the target web conference, there is no need to pop up a call interface, thus avoiding any harm to the user experience.

[0207] Steps 612-619 above are similar to step 207 above, and will not be repeated here.

[0208] In this embodiment, a method is provided whereby a first user pre-creates a target network conference on a conference server and configures the accounts to be invited. The conference server, based on a scheduled task, triggers a push call request to each account to be invited via a message server at the ringing time. This allows a second user to be invited to the target network conference in a timely manner via a call request at the ringing time. This eliminates the need for the second user to manually search for the conference ID and enter the conference password in the application to join the conference. Instead, the second user can join the conference with a single click by answering the call through the call interface, greatly improving the efficiency of human-computer interaction.

[0209] Furthermore, the message server and conference server communicate using OpenID, and generate conference tickets based on VID and map them to the corresponding OpenID. This message transmission mechanism, which uses conference tickets to authenticate and verify OpenIDs, greatly improves data security and privacy. The message server processes ringing push requests through a message queue, reducing the risk of the message server crashing due to a large influx of ringing push requests. In addition, after receiving a call request, the second terminal only displays the call interface if the target network conference has not ended and the corresponding account is not in any network conference, thus avoiding interrupting the ongoing process of the second terminal at an inappropriate time and optimizing the user experience.

[0210] In the above embodiments, it was introduced that after the first user completes the creation of the target network conference, the conference server, driven by a scheduled task, sends a ringing push request to the message server when the timer indicates the ringing time. However, in other embodiments, since the first user may still have the need to invite new users to join the conference after the target network conference has started, or may have the need to re-invite users who have been invited but have not yet joined the target network conference, the server will push a call request to the corresponding newly added account or the account to be invited during the conference (without generating a scheduled task). The triggering process of the call request in this case will be explained below.

[0211] Figure 7 This is an interactive flowchart of the call request triggering logic provided in an embodiment of this application, such as... Figure 7 As shown, in the system architecture of the above embodiment, server 140 is a server cluster integrating a message server and a conference server. The message server is used to provide message push and message processing services, while the conference server is used to provide various services for web conferencing. This embodiment includes the following steps:

[0212] 701. During the target network conference, the first terminal sends a conference ticket request to the message server, which carries one or more newly added accounts specified for the target network conference.

[0213] The first user represents the target network meeting in progress during the meeting's time period (i.e., after the start time and before the end time). At this time, the first user can still invite newly added accounts to participate in the target network meeting at any time. It should be noted that "newly added accounts" here refers to accounts that were not invited before the meeting started but were invited during the meeting, not newly registered accounts.

[0214] Optionally, when the first terminal reaches the start time of the target network conference, it displays the conference interface of the target network conference. This conference interface includes member configuration options. The first user executes a trigger operation on the member configuration options to enter the member configuration interface, which displays an invitation option. By executing a trigger operation on the invitation option, a newly added account can be invited to participate in the target network conference. The method of selecting a newly added account during the conference is similar to the method of selecting an account to be invited before the start of the conference described in step 201 above, and will not be repeated here.

[0215] Figure 8 This is a schematic diagram of a member configuration interface provided in an embodiment of this application, such as... Figure 8 As shown, during a target network conference, the first user can access the member configuration interface 800 from the conference interface. The member configuration interface 800 displays a member search bar 801, a first member list 802, a second member list 803, a mute option 804, an unmute option 805, and an invite option 806. The member search bar 801 searches for accounts already joined to the target network conference and invited but not yet joined accounts. The first member list 802 displays accounts already joined to the target network conference, and the second member list 803 displays invited but not yet joined accounts. The mute option 804 mutes all accounts except the target account associated with the first user. The unmute option 805 unmutes all accounts except the target account. The invite option 806 invites newly added accounts to the target network conference. The first member list 802 and the second member list 803 are collectively referred to as the conference member list.

[0216] 702. In response to the conference ticket request, the message server returns a conference ticket generated for the one or more newly added accounts to the first terminal. The conference ticket is used to verify the account's participation permission for the target network conference.

[0217] Step 702 is similar to step 202 above, and will not be described in detail here.

[0218] 703. The first terminal sends a new ringback request to the conference server. The new ringback request carries the conference ticket and the one or more newly added accounts.

[0219] Specifically, the newly added ringing request is used to trigger the conference server to enable the ringing push service for the newly added account. That is, the newly added ringing request is used to request the conference server to send a ringing push request to the message server for each newly added account.

[0220] In some embodiments, if the first user wants to re-invite an account that has been previously invited but has not yet joined the target web conference, since a conference ticket was applied for for such an account during the initial invitation, there is no need to execute steps 701-702. The user only needs to add the locally cached conference ticket for the corresponding account and the account to the new ringback request to enable repeated invitations during the conference.

[0221] 704. In response to the new ringing request, the conference server sends a ringing push request to the message server. The ringing push request carries the conference ticket and the one or more newly added accounts. The ringing push request is used to request the message server to push call requests to the newly added accounts.

[0222] Step 704 above is similar to step 205 above, and will not be repeated here. It should be noted that when inviting a newly added account or inviting an account that has been invited before but has not yet joined the target network meeting during the meeting, it is not necessary to create a scheduled task to determine whether the ringing time has been reached. Instead, the meeting server will directly send a ringing push request to the message server under the drive of the new ringing request.

[0223] 705. In response to the ringing push request, the message server pushes the call request to each newly added account's logged-in second terminal. The call request is used to invite the corresponding account to join the target network conference.

[0224] Step 705 is similar to step 206 above, and will not be repeated here.

[0225] 706. The second terminal responds to the call request and displays the call interface of the target network conference.

[0226] Step 706 is similar to step 207 above, and will not be repeated here.

[0227] All of the above-mentioned optional technical solutions can be combined in any way to form optional embodiments of this disclosure, and will not be described in detail here.

[0228] In this embodiment, a method is provided whereby a first user can select new accounts to invite to join a target network conference at any time during the conference, and push call requests to each new account through a message server. This allows a second user to be invited to join the target network conference at any time during the conference. This eliminates the need for the second user to manually search for the conference ID and enter the conference password in the application; instead, they can simply answer the call through the call interface to join with one click, greatly improving the efficiency of human-computer interaction.

[0229] Because the message server and the conference server can handle different user loads under this architecture, the computing load of the server is greatly reduced. In some embodiments, the message server and the conference server can also be integrated into the same physical machine to save communication overhead between different servers.

[0230] The following will take the communication between the message server and the conference server using OpenID as an example to introduce a possible implementation of the triggering process for a call request for a newly added account during the conference in the above embodiments. Figure 9 This is a schematic flowchart illustrating the triggering process of a call request provided in an embodiment of this application, such as... Figure 9 As shown, the call request triggering logic involves the interaction of four parties: the first terminal, the second terminal, the message server, and the conference server. The call request triggering process includes the following steps:

[0231] 901. During the target network conference, the first terminal sends a conference ticket request to the message server. The conference ticket request carries a list of VIDs consisting of the VIDs of each newly added account in the target network conference.

[0232] Step 901 above is similar to step 601 above, and will not be described in detail here.

[0233] 902. In response to the conference ticket request, the message server generates a conference ticket and a list of OpenIDs mapped from the VID list, based on the VID list.

[0234] Step 902 is similar to step 602 above, and will not be described in detail here.

[0235] 903. The message server returns the meeting tickets and OpenID list to the first terminal.

[0236] Step 903 is similar to step 603 above, and will not be repeated here.

[0237] 904. The first terminal sends a new ringing request to the conference server. The new ringing request carries the conference ticket and a list of OpenIDs of the newly added account.

[0238] In some embodiments, if the first user wants to re-invite an account that has been previously invited but has not yet joined the target web conference, since the OpenID of such an account has already been obtained and a conference ticket has been applied for during the initial invitation, there is no need to perform steps 901-903. The user only needs to add the locally cached OpenID of the account that wants to be invited again to the OpenID list to achieve repeated invitations during the conference.

[0239] 905. The conference server returns a confirmation message to the first terminal regarding the newly added ringing request.

[0240] For example, the acknowledgment message is an ACK (Acknowledge Character) message.

[0241] 906. In response to the new ringing request, the conference server sends a ringing push request to the message server, which carries the conference tickets and OpenID list contained in the new ringing request.

[0242] Step 906 above is similar to step 704 above, and will not be repeated here. It should be noted that when inviting a newly added account or inviting an account that has been invited before but has not yet joined the target network meeting during the meeting, it is not necessary to create a scheduled task to determine whether the ringing time has been reached. Instead, the meeting server will directly send a ringing push request to the message server under the drive of the new ringing request.

[0243] 907. The message server returns a confirmation message to the conference server regarding the ringing push request.

[0244] For example, the acknowledgment message is an ACK (Acknowledge Character) message.

[0245] 908. The message server adds the ringing push request to the message queue.

[0246] In other words, the message server delivers the asynchronous task of the ringing push request to the message queue.

[0247] 909. When the message server processes the ringing push request in the message queue, it uses the meeting ticket to query the corresponding VID list.

[0248] 910. The message server determines the final list of VIDs to be pushed based on the VID list obtained from the query and the VID list obtained by reverse mapping from the OpenID list.

[0249] In other words, for each OpenID in the OpenID list received in step 906 above, the corresponding VID is obtained through inverse mapping. Then, the VID list obtained in step 909 above is checked to see if there is a matching VID. If there is a matching VID, the current VID is added to the VID list to be pushed. If there is no matching VID, the current VID is skipped and the next VID obtained through inverse mapping is traversed.

[0250] 911. The message server pushes a call request to the second terminal logged in by the account corresponding to each VID in the list of VIDs to be pushed.

[0251] 912. Message server registration ringing timeout check asynchronous task.

[0252] 913. In response to the call request, the second terminal sends a meeting status query request to the message server.

[0253] 914. In response to the meeting status query request, the message server queries the meeting status of the target network meeting from the meeting server.

[0254] 915. The conference server returns the conference status query results to the message server.

[0255] 916. The message server queries the meeting status of the account logged into the second terminal from the meeting server.

[0256] 917. The conference server returns the meeting status query results to the message server.

[0257] 918. The message server returns the meeting status query results and the participation status query results to the second terminal.

[0258] 919. The second terminal displays the call interface if the target network conference has not ended and the corresponding account is not in any network conference.

[0259] Steps 907-919 above are similar to steps 607-619 above, and will not be repeated here.

[0260] In this embodiment, a method is provided whereby a first user can select new accounts to invite to join a target network conference at any time during the conference, and push call requests to each new account through a message server. This allows a second user to be invited to join the target network conference at any time during the conference. This eliminates the need for the second user to manually search for the conference ID and enter the conference password in the application; instead, they can simply answer the call through the call interface to join with one click, greatly improving the efficiency of human-computer interaction.

[0261] Furthermore, the message server and conference server communicate using OpenID, and generate conference tickets based on VID and map them to the corresponding OpenID. This message transmission mechanism, which uses conference tickets to authenticate and verify OpenIDs, greatly improves data security and privacy. The message server processes ringing push requests through a message queue, reducing the risk of the message server crashing due to a large influx of ringing push requests. In addition, after receiving a call request, the second terminal only displays the call interface if the target network conference has not ended and the corresponding account is not in any network conference, thus avoiding interrupting the ongoing process of the second terminal at an inappropriate time and optimizing the user experience.

[0262] In the above embodiments, the processing logic for accurately pushing call requests to the second terminal through the interaction between the first terminal, the message server, and the conference server before and during the conference is described in detail. In the embodiments of this application, if the second terminal misses the call request, a quick way to enter the target network conference will be provided to the second terminal. The following is an explanation.

[0263] Figure 10 This is a flowchart illustrating a message display method provided in an embodiment of this application. See also... Figure 10 This embodiment is implemented through interaction between a terminal and a server. The terminal refers to the second terminal involved in the above embodiments. Since this embodiment does not involve a first terminal, it is simply referred to as a terminal. The server refers to the server cluster integrated by the message server and the conferencing server involved in the above embodiments, as described below:

[0264] 1001. The server sends a call request to the terminal logged in by the account associated with the target web conference. The call request is used to invite the account to join the target web conference.

[0265] In some embodiments, the call request may be issued at the ringing time of the target network conference, or it may be pushed in real time during the meeting. Optionally, the ringing time may be preset by the meeting host (i.e., the first user) or it may be a default ringing time preset by the server. This application embodiment does not specifically limit this. The processing logic of the server pushing call requests to each terminal has been described in detail in the foregoing embodiments and will not be repeated here. In addition, the "terminal" involved in this application embodiment refers to the second terminal in the foregoing embodiments, and the "server" involved in this application embodiment refers to the server cluster integrated by the message server and the conference server in the foregoing embodiments.

[0266] 1002. The server sets the status parameter of the account for the target network conference to "sent". This status parameter is used to indicate whether the account has joined the target network conference.

[0267] In some embodiments, the server configures a status parameter for each account associated with the target web conference. The status parameter includes three values: sent, answered, and rejected. The sent status indicates that a call request has been sent to the corresponding account, but no answer or rejection feedback has been received. The answered status indicates that the corresponding account has joined the target web conference. The rejected status indicates that the corresponding account rejected the previously sent call request.

[0268] In some embodiments, in addition to the three values ​​mentioned above, the status parameter can also be set to a fourth value, namely the ringing timeout status. The ringing timeout status is used to indicate that no answer or rejection feedback information has been received within the target duration. This application embodiment does not specifically limit this.

[0269] Optionally, this status parameter is an integer. A value of 1 indicates the call has been sent, a value of 2 indicates the call has been answered, and a value of 3 indicates the call has been rejected. It should be noted that if the status parameter supports a ringing timeout status, a value of 4 indicates a ringing timeout.

[0270] Optionally, this status parameter is a string. When the string is "Ringing", it indicates that the call has been sent; when the string is "Pick_Up", it indicates that the call has been answered; and when the string is "Hang_Up", it indicates that the call has been rejected. It should be noted that if the status parameter supports a ringing timeout status, then when the status parameter is "Overtime", it indicates that the ringing timeout status has been reached.

[0271] In some embodiments, the server maintains a status parameter list for each account associated with the target network conference that has received a call request. This list stores the account identifier for each account and its corresponding status parameters. After the call request is successfully sent, the server sets the account's status parameter to "sent" in the status parameter list. Optionally, a key-value data structure is constructed for each account in the status parameter list, where the key is the account identifier and the value is the status parameter.

[0272] 1003. The terminal responds to the call request of the target network conference and displays the call interface of the target network conference. The call request is used to invite the account logged into the terminal to join the target network conference.

[0273] In some embodiments, after receiving the call request, the terminal directly obtains the multimedia resources of the call interface and renders the multimedia resources of the call interface to display the call interface on the screen. Optionally, the multimedia resources of the call interface may be carried in the call request, or the multimedia resources of the call interface may be pre-cached locally by the terminal, or the multimedia resources of the call interface may be loaded from the server by the terminal after receiving the call request. This application embodiment does not specifically limit the source of the multimedia resources of the call interface.

[0274] In some embodiments, when the terminal receives a call request, there may be situations where the user is already in a meeting (e.g., has joined the target network meeting from another device, or the previous meeting has not yet ended), or the target network meeting has already ended (e.g., the meeting host, i.e., the first user, actively canceled, or the meeting was short and has ended). In such cases, popping up the call interface might negatively impact the user experience. Therefore, in response to the call request, the terminal will not directly pop up the call interface, but will instead send a meeting status query request to the server. This meeting status query request will at least carry the identification information of the target network meeting (such as the meeting ID) and the account information of the terminal itself. The server uses an identifier to respond to the meeting status query request. It uses the identifier information of the target network meeting to query its status and obtain the meeting status query result. Then, it uses the account identifier to query whether the account is currently in any network meeting and obtains the participation status query result. The server then returns both the meeting status query result and the participation status query result to the terminal. The terminal only displays the call interface if the meeting status query result indicates that the target network meeting has not ended and the participation status query result indicates that the account is not currently in any network meeting. This optimizes the call interface display logic and thus improves the user experience.

[0275] 1004. In response to the rejection operation triggered by the call interface, the terminal sends a status report information to the server carrying the rejection status.

[0276] In some embodiments, the call interface provides an answer option and a reject option. The answer option is used to trigger an answer operation to the target web conference, which triggers the account to immediately join the target web conference. The reject option is used to trigger a reject operation to the target web conference, which refuses to immediately join the target web conference.

[0277] In some embodiments, a user clicking the answer option triggers an answer operation, and a user clicking the reject option triggers a reject operation. Indicatively, a touch sensor senses the pressure signal applied by the user to the display screen and obtains the screen coordinates of the touch point of the pressure signal. If the screen coordinates are located within the display area of ​​the answer option on the display screen, it indicates that an answer operation triggered by the call interface has been detected; if the screen coordinates are located within the display area of ​​the reject option on the display screen, it indicates that a reject operation triggered by the call interface has been detected.

[0278] In some embodiments, in addition to clicking, answering or rejecting a call can also be triggered by other methods such as swiping in a specified direction, double-clicking, or long-pressing. For example, pressing and holding the answer option and swiping in a specified direction can trigger answering, and long-pressing the reject option can trigger rejecting.

[0279] In some embodiments, users can also trigger answering or rejecting operations via voice commands. For example, if a user says "Join the meeting" into the microphone, the terminal will perform voice recognition on the voice signal collected by the microphone and obtain the recognized text "Join the meeting," confirming that an answering operation has been detected. Alternatively, if a user says "Hang up" into the microphone, the terminal will perform voice recognition on the voice signal collected by the microphone and obtain the recognized text "Hang up," confirming that a rejecting operation has been detected.

[0280] In some embodiments, users can also trigger answering or rejecting operations through gesture commands. This application embodiment does not specifically limit the triggering method of answering or rejecting operations. Of course, the triggering methods of answering or rejecting operations can be the same or different, and this application embodiment does not specifically limit them either.

[0281] In step 1004 above, the terminal detects that the user has rejected the target network conference. For example, the terminal detects that the user has triggered the rejection option. In this case, the terminal will actively report status information to the server, carrying the account identifier and the rejected status. In other words, when the user performs a rejection operation, the status information reported by the terminal is used to request that the status parameter of the account for the target network conference be set to the rejected status. This allows the server to promptly look up the status parameter of the account in the status parameter list, using the account identifier as the index, and then set the status parameter of the account from the issued status to the rejected status. This facilitates timely updating of the account's status parameter and avoids errors when determining whether to push call notification messages based on the status parameter.

[0282] In some embodiments, if the terminal detects that a user has answered a call to the target web conference, for example, if the terminal detects that the user has triggered an action to select the answer option, the terminal will proactively report status information to the server, carrying the account identifier and the answered status. In other words, when the user answers the call, the status information reported by the terminal is used to request that the account's status parameter for the target web conference be set to the answered status. This allows the server to promptly look up the account's status parameter in the status parameter list, using the account identifier as an index, and then set the account's status parameter from the issued status to the answered status. This facilitates timely updates to the account's status parameter and avoids errors when determining whether to push a call notification message based on the status parameter. In addition, after the terminal has finished reporting the answered status, it can directly proceed to step 1007 below to send an interface close message to each terminal logged in with this account. This is for situations where the same account can be logged in on multiple devices at the same time. As long as the user triggers the answer operation on any device, all devices logged in with this account (including this terminal) will cancel the display of the call interface. Then, proceed directly to step 1010 below to join the audio and video call of the target network conference through this terminal and display the conference interface of the target network conference.

[0283] In some embodiments, there is also a situation where, when the display duration of the call interface reaches the target duration, neither answering nor rejecting an operation is detected, which is equivalent to the terminal ringing continuously, but the user does not answer or reject the call. Since neither answering nor rejecting an operation is detected, the terminal will not report any status information. At this time, it will enter step 1304 in the following embodiment, triggering the ringing timeout check asynchronous task. For details, please refer to the description in the next embodiment.

[0284] 1005. In response to the status report information sent by the account, the server sets the status parameter of the account to the rejected status carried in the status report information.

[0285] In some embodiments, the server receives status reporting information sent by the terminal, parses the status reporting information to obtain an account identifier and a latest status information. The account identifier carried here is the account identifier of the logged-in terminal's account, and the latest status information carried is a rejected status. Then, the server queries the corresponding stored status parameter in the status parameter list maintained for the target network conference, using the parsed account identifier as an index, and then sets the retrieved status parameter from the sent status to the answered status. This facilitates timely updates to the status parameters of each account, thereby avoiding errors when determining whether to push call notification messages based on the status parameters later.

[0286] It should be noted that when the same account can be logged in on multiple devices at the same time, each device logged in by the account may send the status report information to the server. In this case, the server can process only the first status report information received and discard the rest, thus simplifying the server's storage resources.

[0287] In some embodiments, in response to the status reporting information sent by the terminal, regardless of whether the status reporting information carries an answered or rejected status, the server sends a status change indication message to the terminal (i.e., the first terminal) logged in by the target account that created the target network conference. This status change indication message instructs the target account to update its status parameters in the conference member list based on the status reporting information. Illustratively, the conference member list displayed on the first terminal includes a first member list and a second member list. The first member list displays accounts that have joined the target network conference, and the second member list displays accounts that have been invited but have not yet joined the target network conference. For example, the first member list is as follows: Figure 8 The first member list 802 in the member configuration interface 800 shown is the second member list 803 in the member configuration interface 800.

[0288] In some embodiments, when the status report information received by the server carries a "listened" status, the status change indication information sent by the server to the first terminal is used to instruct the account to be transferred from the second member list to the first member list.

[0289] In some embodiments, when the status report information received by the server carries a rejected status, the status change indication information sent by the server to the first terminal is used to indicate that the calling option of the account is displayed in the second member list, and the calling option is used to trigger the resending of the call request to the account.

[0290] Figure 11 This is a schematic diagram of a member configuration interface provided in an embodiment of this application, such as... Figure 11As shown, the member configuration interface 800 displays a first member list 802 and a second member list 803. Each account 811 to 815 in the second member list 803 is displayed as "Calling", indicating that the server has pushed a call request to each account 811 to 815, but has not yet received any feedback information from any account to answer or reject the call, and the target duration has not been reached. If, at some point within the target duration, the user performs an answering operation on the second terminal logged in by account 811, and account 811 enters the target network conference, then the server will send a status change instruction message to the first terminal. This status change instruction message is used to instruct account 811 to be transferred from the second member list 803 to the first member list 802.

[0291] Figure 12 This is a schematic diagram of a member configuration interface provided in an embodiment of this application, such as... Figure 12 As shown, the member configuration interface 800 displays a first member list 802 and a second member list 803. The second member list 803 includes five accounts 811 to 815 to be invited. After the server pushes a call request to each account 811 to 815, if at any time within the target duration, a user performs a rejection operation on a second terminal logged in with any of the accounts 811 to 815, or if the user does not perform any answer or rejection operation on the second terminal within the target duration (representing a ringing timeout), the server will send a status change indication message to the first terminal when any of the above conditions are met. This status change indication message is used to indicate that the call option for the corresponding account is displayed in the second member list 803. This call option is used to trigger the resending of the call request to the account. Suppose that all accounts 811 to 815 in the second member list 803 either reject the call or the ringing timeout occurs. In this case, the second member list 803 displays the call options 821 to 825 corresponding to each of accounts 811 to 815. In addition, the second member list 803 also displays the all-call option 830, which is used to make batch calls to all accounts that can be called in the second member list 803.

[0292] 1006. The server sends a call notification message for the target web conference to the terminal logged in with the account. This call notification message is used to provide an entry point to join the target web conference.

[0293] The call notification message serves not only to provide an entry point to join the target web conference, but also to provide the historical call records of that web conference. In other words, the call notification message serves two purposes: firstly, to inform the user that they have missed one (or more) call requests, and secondly, to provide the user with an entry point to join the target web conference with one click.

[0294] In some embodiments, when the server detects that the status parameter of any account in the status parameter list is in a rejected state, it sends the call notification message to each terminal logged into that account. The call notification message carries at least multimedia resources for joining the target web conference. Optionally, the call notification message also carries call notification text and identification information of the target web conference. The call notification text is used to provide historical call records of the target web conference.

[0295] In steps 1005-1006 above, a possible implementation method is provided whereby the server, based on the status parameter, determines that the account meets the message push conditions, and sends a call notification message for the target network conference to the account. Specifically, this embodiment uses the message push condition of the status parameter being set to a rejected state within a target duration after the call request is sent as an example. For cases where the call request exceeds the target duration, please refer to the asynchronous ringing timeout check task in the next embodiment. Here, the target duration is any value greater than 0; that is, the target duration refers to a timeout threshold for continuous ringing on the terminal side. Within the timeout threshold, if the user initiates a rejection operation, the message push conditions are met, and the server sends the call notification message to the terminal. Outside the timeout threshold, if the user neither initiates an answer operation nor a rejection operation, the asynchronous ringing timeout check task described in the next embodiment is triggered.

[0296] 1007. The server sends an interface close message to each terminal logged in with the account. The interface close message is used to instruct each terminal logged in with the account to close the call interface displayed based on the call request.

[0297] In some embodiments, as long as the server receives the status report information sent by the account, it will update the status parameters of the account in the status parameter list based on the latest status parameters carried in the status report information. This application embodiment takes the case of carrying the rejected status as an example. In this case, the server sets the status parameter of the account to the rejected status. However, if the case carries the answered status, the server will set the status parameter of the account to the answered status.

[0298] It should be noted that when the same account is logged in on multiple devices at the same time, each device logged in to that account may send status reporting information to the server. Therefore, when the server receives multiple status reporting information corresponding to the same account, it can process only the first status reporting information that arrives, while rejecting or discarding the rest of the status reporting information, which can save server processing resources.

[0299] Furthermore, as long as the server receives the status report information sent by the account, in addition to executing the update logic for the status parameters, regardless of whether the status report information carries an answered status or a rejected status, the server sends an interface close message to each terminal that needs to be logged in by the account, or sends an interface close message to each terminal that is logged in by the account other than the terminal itself. This application embodiment does not specifically limit whether the server sends an interface close message to the terminal itself.

[0300] In the above process, by turning off messages through the push interface, for situations where the same account can be logged in on multiple devices at the same time, as long as the user triggers an answer or reject operation on any device, the call interface will be canceled on all devices logged in with that account, thus optimizing the user experience.

[0301] For example, if a user logs into the account on both a mobile phone and a computer, and the user joins the target web conference on the mobile phone, the server will send a message to both the computer and the mobile phone to close the interface, triggering both the mobile phone and the computer to cancel the display of the call interface, and then the mobile phone will display the meeting interface of the target web conference.

[0302] For example, if a user logs into the account on both a mobile phone and a computer, and then rejects a call request from the target web conference on the mobile phone, the server will send an interface close message to both the computer and the mobile phone to trigger both the mobile phone and the computer to cancel the display of the call interface. Of course, since the rejection operation will trigger the server to send a call notification message, the call notification message will be displayed on both the mobile phone and the computer.

[0303] It should be noted that step 1007 is optional. For example, assuming the application does not support simultaneous login of the same account on multiple devices, since the account can only log in to one terminal at a time, the terminal only needs to switch to the conference interface when a call is answered and cancel the display of the call interface when a call is rejected or the display duration of the call interface reaches the target duration. The server does not need to send interface close messages to each terminal logged in with the same account. Alternatively, even if the application supports simultaneous login of the same account on multiple devices, the server may not send interface close messages to each terminal logged in with the same account. Therefore, after a user connects or rejects a call on a certain device, the logic of automatic cancellation upon timeout on other devices will not cause too much disturbance, thus saving server computing resources and communication overhead.

[0304] In some embodiments, where simultaneous login of the same account on multiple devices is supported, if a user responds to a call request on another terminal (i.e., a terminal other than the one where the account is logged in) using the same account, the response is either an answer or a rejection operation. Since both answering and rejection operations trigger the other terminal to send a status report to the server, when the server receives the status report from the other terminal, it can generate a call response message corresponding to the status parameters carried in the received status report. Then, the server can send a call response message to each terminal other than the one where the account is logged in. All terminals (including this terminal) push the call response message. Since the status parameters carried in the status reporting information are associated with the user's response on other terminals, such as the status parameter being "answered" when the response is to answer and "rejected" when the response is to reject, it is equivalent to the server pushing a call response message associated with the user's response on other terminals to all terminals logged in by this account, thereby triggering each terminal to display the received call response message. This call response message is used to notify the account of its response to the call request on other terminals.

[0305] To illustrate, when a user answers a call on another terminal, the status report information submitted by that terminal indicates that the call has been answered. The call response message pushed by the server then indicates that the account has joined the target network conference on another terminal. For example, if a user logs into the account on terminals A, B, and C, and answers a call on terminal A, joining the target network conference on terminal A, terminal A submits a status report information indicating that the call has been answered. This triggers the server to send an interface close message and a call response message to terminals B and C. Terminals B and C then respond to the interface close message by canceling the display of the call interface and simultaneously displaying the received call response message, such as "You have joined the conference on terminal A".

[0306] To illustrate, when a user responds with a rejection operation on other terminals, the status report information reported by those other terminals carries the rejected status. The call response message pushed by the server is used to indicate that the account has rejected joining the target network conference on other terminals. For example, if a user logs into the account on terminals A, B, and C, and performs a rejection operation on terminal A, rejecting joining the target network conference on terminal A, terminal A reports a status report information carrying the rejected status. This triggers the server to send an interface close message and a call response message to terminals B and C. Terminals B and C then respond to the interface close message by canceling the display of the call interface and simultaneously displaying the received call response message, for example, "Meeting has been rejected on terminal A".

[0307] 1008. In response to the interface close message sent by the server, the terminal cancels the display of the call interface and displays the received call notification message.

[0308] In some embodiments, after receiving an interface close message, the terminal cancels the display of the call interface. Furthermore, after receiving a call notification message, it displays the call notification message on the screen. Since the system supports simultaneous login on multiple terminals with the same account, a user's response to a call request on any terminal logged in with that account (which may be the same terminal or another terminal) will trigger the corresponding terminal to send a status report to the server. This causes the server, upon receiving a status report from any terminal logged in with the same account, to send an interface close message to all terminals logged in with that account (including or excluding the sender of the status report). Essentially, this interface close message instructs the corresponding call interface to be closed when any terminal logged in with the same account responds to a call request. This avoids the disruption to the user experience caused by other devices continuing to ring while the user responds to a call request on one device.

[0309] In some embodiments, when a terminal displays a call notification message, it displays the call notification message directly within the application displaying the call interface. That is, the call notification message is displayed within the application in various forms such as service notification, unread message, top-level notification, bottom-level notification, sidebar notification, bubble notification, floating window notification, etc. This application embodiment does not specifically limit the display method of the call notification message.

[0310] Optionally, the terminal displays the call notification message in the message list of this account, where the message list is used to display session messages or notification messages for this account. This is equivalent to using a separate list item in the message list of this account to carry the call notification message for the target network conference. For example, when the application is an enterprise application, social application, or instant messaging application, the call notification message is displayed in the message list as a service notification.

[0311] Optionally, the terminal displays the call notification message in the conversation interface between the current account and the target account (referring to the account that created the target web conference). This converts the call notification message for the conference invitation into a special conversation message within the conversation between the current account and the target account for transmission. This allows the user to immediately send a reply message to the target account in the conversation interface after viewing the call notification message, without having to manually switch to the conversation interface with the target account to enter a reply message, thus further improving human-computer interaction efficiency.

[0312] Optionally, the terminal displays the call notification message as a floating layer in the current display interface of the application (referring to the interface displayed after the call interface is canceled), at the top, bottom, or sidebar positions of the display interface (corresponding to top-level notification, bottom-level notification, and sidebar notification, respectively). When the call notification message floats in the display interface for more than a display duration threshold, the terminal cancels the display of the call notification message and then collapses it into the message list, allowing the user to easily review the message in the message list if they miss it. The display duration threshold is any value greater than 0.

[0313] Optionally, in addition to displaying the call notification message as a floating layer, the terminal can also display the call notification message in the application as a floating window, a pop-up notification box, a dialog box, etc. This application embodiment does not specifically limit the display method of the call notification message.

[0314] In other embodiments, when displaying a call notification message, the terminal does not display the message within the application itself, but rather in the terminal's push notification bar. This push notification bar displays notification messages from various active applications on the terminal. In this case, even if the application is running in the background, the terminal can still push the call notification message in the integrated notification bar of various applications, improving the user's efficiency in obtaining information about the call notification message.

[0315] In other embodiments, when displaying call notification messages, the terminal may also display them via SMS, text messages, notification emails, etc., with full authorization from the user and all parties involved. This application does not specifically limit this method.

[0316] In step 1008 above, the terminal responds to the rejection operation triggered by the call interface and displays the call notification message. This application embodiment only describes the case where the call notification message is displayed based on the rejection operation. In the next embodiment, the processing logic for automatically triggering the display of the call notification message when the user has not joined the target network conference after the timeout threshold is also provided, which will not be elaborated here.

[0317] 1009. Based on the call notification message, the terminal displays an entry point for joining the target web conference.

[0318] In some embodiments, the call notification message carries at least multimedia resources for joining the target web conference. Optionally, the call notification message also carries call notification text and identification information of the target web conference. The call notification text is used to provide the account with historical call records of the target web conference. For example, the historical call records carry at least the time the call request was received and the ringing duration. Since users may miss more than one call request from more than one conference, they can view all historical call records of all missed conferences through the call notification text, which can improve the user's information acquisition efficiency.

[0319] Optionally, when displaying the call notification message, the terminal may directly display the call notification text, the identification information of the target network conference, and the entry point for joining the target network conference within the call notification message. For example, the call notification message may be a conference card message, which may display the call notification text, the identification information of the target network conference, and the entry point for the target network conference.

[0320] Optionally, when the terminal displays the call notification message, it only displays the call notification text in the call notification message. This can briefly remind the user of the missed call request. If the user intends to join the target web conference, the user performs a trigger operation on the call notification message, thereby causing the terminal to respond to the trigger operation on the call notification message and display the identification information of the target web conference and the entry point of the target web conference.

[0321] In some embodiments, since a user may receive call requests from different web conferences within the same time period, and each web conference may initiate one or more call requests to the user, in cases where the user misses multiple call requests, the terminal may display the number and details of missed historical call records in the call notification text, such as "You have missed 6 conference calls, of which Conference 1 called 3 times, Conference 2 called 2 times, and Conference 3 called 1 time." After the user performs a trigger operation on the call notification text, the triggering terminal displays the reception time, ringing duration, and conference information for each historical call record. At the same time, each historical call record also provides an entry point to the corresponding web conference, making it easy for the user to select which web conference to enter.

[0322] In some embodiments, when the account is logged in on multiple terminals, a transfer entry for the target web conference is displayed for at least one of the call notification messages provided in step 1009 or the call interface provided in step 1003 above. The transfer entry is used to instruct users to join the target web conference on other terminals where the account is logged in.

[0323] Optionally, when the account is logged in on only two terminals, the user can trigger the transfer entry to join the target web conference on another terminal other than the one logged in. For example, if the user is logged in on both a mobile phone and a computer, the mobile phone or computer provides a transfer entry on the call interface and call notification message. For example, the transfer entry on the mobile phone prompts "Transfer to computer to join the meeting", and the transfer entry on the computer prompts "Transfer to mobile phone to join the meeting".

[0324] Optionally, when the account is logged in on two or more terminals, the user can trigger the transfer entry to display transfer options for all terminals other than the current terminal. In response to the user's trigger action on any transfer option, the user can join the target web conference on the terminal corresponding to the selected transfer option. For example, if the user is logged in on a mobile phone, desktop computer, and laptop computer, and each of these devices provides a transfer entry on the call interface and call notification message, the user can trigger the transfer entry to display the transfer options "Join the meeting on desktop computer" and "Join the meeting on laptop computer" when the call interface pops up on the mobile phone or the call notification message appears after a ringout. This allows the user to select the transfer option corresponding to the terminal they want to join, ultimately controlling the user to join the target web conference on another terminal. This reduces the complexity of controlling which device to join the meeting and further improves human-computer interaction efficiency.

[0325] In some embodiments, for at least one of the call notification messages provided in step 1009 or the call interface provided in step 1003 above, a message reply entry is also displayed. This message reply entry refers to a shortcut entry for one-click message reply to the meeting initiator or current participants. Optionally, in response to the user's triggering operation on the message reply entry, at least one preset reply message is displayed, or a message input box is also displayed. For example, preset reply messages include "On my way, expected to join the meeting in 5 minutes", "I'm not available now, I'll join later", "I'm finishing up my work, I'll be there soon", etc. Displaying preset reply messages makes it easier for users to directly select preset messages, thereby reducing the time spent inputting messages and speeding up message reply. Providing a message input box allows users to customize messages when they are not satisfied with the preset messages, improving the operability of message reply. Optionally, in response to a user's selection of any preset reply message or input of a reply message, the terminal sends the reply message to the target account that created the target network conference or to each account that joined the target network conference. That is, after the user selects a provided preset message or manually inputs a message, they can quickly reply to the conference initiator or current participants. For example, the terminal sends the reply message to the server, the server sends the reply message to the terminal logged in with the target account, or sends the reply message to the terminals logged in with each account that joined the target network conference. The terminal that receives the reply message can display the reply message in the conference interface or in the session interface of the conference group. This application embodiment does not specifically limit this.

[0326] In step 1009 above, a possible implementation is provided whereby the terminal displays a call notification message for the target network conference when the account has not joined the target network conference via the call interface. Specifically, the call notification message is displayed when the account has not joined the target network conference via the call interface because the user has performed a reject operation. In the next embodiment, a processing flow will be described when the account has not joined the target network conference via the call interface because the user has not performed any operation on the call interface for a target duration.

[0327] 1010. In response to the triggering operation of the entry point of the target network conference, the terminal displays the conference interface of the target network conference.

[0328] In some embodiments, after a user performs a trigger operation at the entry point of the target network conference, the terminal will access the audio and video call of the target network conference and switch to the conference interface of the target network conference. The triggering logic of the trigger operation includes, but is not limited to: click operation, long press operation, double click operation, swipe operation in a specified direction, voice command, gesture command, etc. The detection logic is similar to the description in step 1004 above, and will not be repeated here.

[0329] In some embodiments, when the terminal displays the conference interface, it directly displays the conference interface within the application that receives call notification messages and call requests, which simplifies the display logic of the conference interface. In other embodiments, when the terminal displays the conference interface, if a dedicated conference application associated with the application is installed on the terminal, the terminal displays an authorization prompt window to launch the conference application. If the user confirms the authorization, the terminal automatically launches the conference application and displays the conference interface within that application. This application does not specifically limit the display method of the conference interface.

[0330] It should be noted that, in addition to displaying the conference interface in response to a triggering operation at the entry point of the target network conference, the conference interface can also be triggered and displayed in response to an answering operation based on the call interface. This application embodiment does not specifically limit this.

[0331] All of the above-mentioned optional technical solutions can be combined in any way to form optional embodiments of this disclosure, and will not be described in detail here.

[0332] The method provided in this application embodiment, after the terminal pops up the call interface, displays a call notification message to remind the user of the missed call request when the user fails to join the online meeting in time for some reason. Based on the call notification message, a quick entry point to join the target online meeting is provided. This can reduce the cumbersome operation of the user to join the online meeting when the user has a need to join the online meeting later, and greatly improve the efficiency of human-computer interaction.

[0333] The previous embodiment detailed the process of displaying a call notification message on the terminal when a user fails to join the target web conference due to a rejection operation performed on the call interface. In this embodiment, the process of displaying a call notification message on the terminal when a user fails to join the target web conference due to inaction on the call interface for an extended period of time will be described.

[0334] Figure 13 This is a flowchart illustrating a message display method provided in an embodiment of this application. See also... Figure 13This embodiment is implemented through interaction between a terminal and a server. The terminal refers to the second terminal involved in the above embodiments. Since this embodiment does not involve a first terminal, it is simply referred to as a terminal. The server refers to the server cluster integrated by the message server and the conferencing server involved in the above embodiments, as described below:

[0335] 1301. The server sends a call request to the terminal logged in by the account associated with the target web conference. The call request is used to invite the account to join the target web conference.

[0336] Step 1301 above is similar to step 1001 above, and will not be described in detail here.

[0337] 1302. The server sets the status parameter of the account for the target network conference to the "sent" status. This status parameter is used to indicate whether the account has joined the target network conference.

[0338] Step 1302 above is similar to step 1002 above, and will not be described in detail here.

[0339] 1303. The terminal responds to the call request of the target network conference and displays the call interface of the target network conference. The call request is used to invite the account logged into the terminal to join the target network conference.

[0340] Step 1303 above is similar to step 1003 above, and will not be described in detail here.

[0341] 1304. When the server reaches the target duration after sending the call request, it queries the status parameter of the account.

[0342] In some embodiments, the server maintains a status parameter list for each account associated with the target network conference that has received a push call request. The status parameter list stores the account identifier of each account and the status parameters of that account. For each account that has received a push call request, the server queries the status parameter list for that account when the target duration has elapsed since the push call request was sent.

[0343] In some embodiments, after the server sends out call requests in batches to each invited account (or a newly added account during the meeting) associated with the target network conference in a broadcast, multicast, or other manner, it queries the status parameters of each account in the status parameter list when the target duration has elapsed after the batch sending time. Optionally, after the batch sending is completed, the server registers a timeout detection function (i.e., a ringing timeout check asynchronous task, also known as a delayed task). This timeout detection function is used to query the status parameters of each account in the status parameter list when the target duration has elapsed after the batch sending time.

[0344] In some embodiments, since the server may not send call requests to each invited account (or a newly added account during the meeting) in a batch at once, but may send them asynchronously, it is only necessary to register a timeout detection function for each account after each sending is completed. This can accurately create an asynchronous task for ringing timeout checking for each account and improve the detection accuracy of timeout.

[0345] The target duration is any value greater than 0, such as a target duration of 45 seconds. That is, the target duration refers to a timeout threshold for continuous ringing on the terminal side. When the timeout threshold is reached after the timer indicates the time for batch distribution, the status parameters of each account in the status parameter list need to be queried under the action of the timeout detection function.

[0346] 1305. When the status parameter is in the "issued" state, the server sends a call notification message for the target network conference to the terminal logged in by the account. This call notification message is used to provide an entry point to join the target network conference.

[0347] The call notification message not only provides an entry point to join the target web conference, but also provides historical call records for the target web conference.

[0348] In step 1305 above, after the server sends a call request to the terminal and the target duration is reached, the server will query the status parameters of the account in the status parameter list. If the status parameter is "issued," it means that the terminal has not actively reported any status parameters within the target duration after the call request was issued, which means that the user has not performed an answer or reject operation. At this time, the server can send the call notification message to the terminal. The sending logic of the call notification message is described in step 1006 of the previous embodiment, and will not be repeated here.

[0349] In some embodiments, if the status parameter supports a ringing timeout state, then after the server sends a call request to the terminal and the target duration has elapsed, if the status parameter of the account is still in the "sent" state when the status parameter list is found, in addition to triggering the push of the call notification message, the status parameter of the account can also be set to the ringing timeout state. It should be noted that if the status parameter does not support the ringing timeout state, then the server does not need to update the status parameter.

[0350] In steps 1304-1305 above, it is equivalent to providing a possible implementation method in which the server sends a call notification message for the target network conference to the account when the account meets the message push conditions based on the status parameter. This application embodiment only takes the example that the status parameter is still in the "sent" state when the message push condition is that the target time has elapsed after the call request is sent.

[0351] 1306. The terminal displays the call notification message.

[0352] Step 1306 is similar to step 1008 above, and will not be repeated here.

[0353] In step 1306 above, it is equivalent to the terminal displaying the call notification message if no answer or reject operation based on the call interface is detected within the target time period. The answer operation is used to trigger the account to immediately join the target network conference, and the reject operation is used to refuse to immediately join the target network conference.

[0354] 1307. Based on the call notification message, the terminal displays an entry point for joining the target web conference.

[0355] Step 1307 is similar to step 1009 above, and will not be repeated here.

[0356] In this application embodiment, a possible implementation is shown of how a terminal displays the call notification message of the target network conference when the account fails to join the target network conference based on the call interface because the user has not performed any operation on the call interface for a period of time.

[0357] 1308. In response to the trigger operation on this entry point, the terminal displays the meeting interface of the target network conference.

[0358] Step 1308 above is similar to step 1010 above, and will not be repeated here.

[0359] All of the above-mentioned optional technical solutions can be combined in any way to form optional embodiments of this disclosure, and will not be described in detail here.

[0360] The method provided in this application embodiment, after the terminal pops up the call interface, displays a call notification message to remind the user of the missed call request when the user fails to join the online meeting in time for some reason. Based on the call notification message, a quick entry point to join the target online meeting is provided. This can reduce the cumbersome operation of the user to join the online meeting when the user has a need to join the online meeting later, and greatly improve the efficiency of human-computer interaction.

[0361] In this embodiment, the push process of the server for conference card messages will be described using a call notification message as an example. This push process involves multiple processes or threads on the terminal side, including the conference logic process, conference message queue (MQ), conference server (SVR), conference storage, message docking service, message channel, and ringback invitation service. Optionally, the conference logic process, conference MQ, conference storage, conference SVR, and conference docking service are all integrated in the conference server, while the message docking service, message channel, and ringback invitation service are all integrated in the message server. Optionally, the conference server and the message server are integrated in the same physical machine or server cluster.

[0362] Figure 14 This is a schematic diagram of a meeting card message push process provided in an embodiment of this application, such as... Figure 14 As shown, this meeting card message is an exemplary illustration of a call notification message. The push process for this meeting card message includes:

[0363] 1401. When a user answers or rejects a call request, the application sends the corresponding status report information to the conference logic process.

[0364] The conference logic process is used to handle the processing logic when a user performs an answer or reject operation.

[0365] For example, when a user answers a call request (i.e., a ringing request), a status report indicating that the call has been answered is sent; when a user rejects a call, a status report indicating that the call has been rejected is sent. Since both the answered and rejected statuses are status parameters generated by the user's response to the ringing request, they are collectively referred to as the ringing status or the answering status.

[0366] 1402. The conference logic process sends this status report information to the conference SVR.

[0367] In other words, the meeting logic process reports the ringing status to the meeting SVR. The meeting SVR is used to control changes to the initiation status parameters and to initiate push notifications for closing the interface and meeting card messages.

[0368] 1403. The meeting SVR updates the account status parameters in the meeting storage.

[0369] The meeting storage is used to store the status parameters of each account. For example, the meeting storage maintains a status parameter list for each network meeting, which is used to store the status parameters of each account associated with the corresponding network meeting.

[0370] That is, the meeting SVR updates the ringing status in the meeting storage; correspondingly, after the meeting storage has updated the status parameters of the corresponding account, i.e. the ringing status, it returns an ACK confirmation message to the meeting SVR.

[0371] 1404. The conference SVR sends an interface close message to the messaging channel.

[0372] This interface-closing message, also known as the multi-terminal screen-down control message, is used to store various messages to be sent to the application (such as interface-closing messages, meeting card messages, etc.).

[0373] In other words, the conference SVR pushes a multi-terminal screen-down control message to the message channel; correspondingly, after the message channel sends the interface-off message (i.e., the multi-terminal screen-down control message) to each terminal logged into the account, it returns an ACK confirmation message to the conference SVR.

[0374] 1405. The conference SVR sends this status report information to the message docking service.

[0375] In other words, the status report information sent by the conference SVR to the message docking service synchronization application is equivalent to the conference SVR reporting its listening status to the message docking service. This message docking service provides a communication interface between the message server and the external conference server.

[0376] 1406. The message docking service forwards the status report information to the meeting docking service.

[0377] In other words, the message connection service synchronizing this status report information with the conference connection service is equivalent to the message connection service reporting the answering status to the conference connection service. The conference connection service provides the conference server with a communication interface with the external message server.

[0378] 1407. The meeting coordination service forwards the status report information to the ringing invitation service.

[0379] In other words, the meeting connection service synchronizes this status report information with the ringback invitation service, which is equivalent to the meeting connection service reporting the answering status to the ringback invitation service. The ringback invitation service is used to provide the service of pushing call requests to various accounts.

[0380] Accordingly, after receiving the status report information, the ringing invitation service returns an ACK message to the meeting docking service. Then, the meeting docking service returns an ACK message to the message docking service, and then the message docking service returns an ACK message to the meeting SVR.

[0381] 1408. When the reported information in this state carries the status of rejection, the conference SVR pushes a conference card message to the message channel.

[0382] Correspondingly, after the message channel pushes the conference card message to the application on the terminal logged in by the corresponding account, it returns an ACK message to the conference SVR. Then, the conference SVR returns an ACK message to the conference logic process, and the conference logic process returns an ACK message to the application.

[0383] 1409. The meeting message queue (MQ) triggers a timeout task in the background.

[0384] Among them, the Meeting MQ is used to trigger an asynchronous task for ringing timeout checks, also known as a delayed task or timeout task.

[0385] For example, after the call invitation service pushes a call request to each account, it registers a timeout detection function in the meeting message queue (MQ). When the target duration is reached after recommending the call request, the meeting message queue automatically invokes the timeout detection function. This timeout detection function is used to access the status parameters (i.e., the latest status parameters) of each account in the meeting storage. This process is the meeting message queue performing timeout detection in the ringback tones background.

[0386] 1410. The meeting MQ queries the account status parameters from the meeting storage.

[0387] The meeting message queue (MQ) accesses the status parameters of the corresponding account in the meeting storage; correspondingly, after the meeting storage retrieves the status parameters based on the account identifier, it returns the status parameters of the corresponding account to the meeting message queue.

[0388] Optionally, if the status parameter supports a ringing timeout status, the meeting MQ can update the status parameter when it is found to be in the meeting storage as having been sent. For example, the status parameter can be configured to ringing timeout status, which is equivalent to the meeting MQ updating the ringing status in the meeting storage. Correspondingly, after updating the ringing status in the meeting storage, the meeting MQ returns an ACK message confirming the timeout to the meeting MQ.

[0389] 1411. For each account whose status parameter is still in the "issued" state, the meeting MQ sends a status report to the message docking service. This status report is used to indicate that the status parameter should be set to the "ringing timeout" state.

[0390] In other words, for each account that has not answered the call after the ringing timeout, the meeting MQ reports the answering status to the message connection service.

[0391] 1412. The message docking service forwards a status report message carrying the ringing timeout status to the meeting docking service.

[0392] In other words, the message connection service reports the call status to the meeting connection service.

[0393] 1413. The meeting coordination service forwards a status report information carrying the ringing timeout status to the ringing invitation service.

[0394] In other words, the meeting coordination service reports the call status to the ringing invitation service.

[0395] Accordingly, after receiving the status report information, the ringing invitation service returns an ACK message to the meeting docking service. Then, the meeting docking service returns an ACK message to the message docking service, and then the message docking service returns an ACK message to the meeting MQ.

[0396] 1414. The meeting message queue (MQ) pushes meeting card messages to the meeting service controller (SVR).

[0397] 1415. The conference SVR forwards the conference card message to the message channel.

[0398] Correspondingly, after the message channel pushes the conference card message to the application on the terminal logged in by the corresponding account, it returns an ACK message to the conference SVR, and then the conference SVR returns an ACK message to the conference MQ.

[0399] In this embodiment, a push notification scheme is provided that automatically triggers the distribution of meeting card messages based on the user's active rejection of the meeting call or the call timeout. This provides a delayed access path for users who are unable to answer the meeting. Furthermore, by carrying call notification text in the meeting card message, users can quickly and accurately know when / who invited them to the online meeting by checking the distribution time and number of meeting card messages. They can also directly join the online meeting with one click through the entry provided by the meeting card message, greatly improving the efficiency of human-computer interaction.

[0400] Figure 15 This is a schematic diagram of the structure of a message display device provided in an embodiment of this application, as shown below. Figure 15 As shown, the device includes:

[0401] The first display module 1501 is used to respond to a call request from a target network conference and display the call interface of the target network conference, wherein the call request is used to invite the account logged into the device to join the target network conference;

[0402] The second display module 1502 is used to display the call notification message of the target network conference when the account has not joined the target network conference based on the call interface;

[0403] The third display module 1503 is used to display an entry point for joining the target web conference based on the call notification message.

[0404] The device provided in this application embodiment, after the terminal pops up the call interface, displays a call notification message to remind the user of the missed call request if the user did not join the online meeting in time for some reason. Based on the call notification message, it provides an entry point for quickly joining the target online meeting. This can reduce the cumbersome operation for users to join the online meeting when they have a need to delay joining the online meeting, and greatly improve the efficiency of human-computer interaction.

[0405] In one possible implementation, the second display module 1502 is used for:

[0406] In response to a rejection action triggered by the call interface, a call notification message is displayed, the rejection action being used to refuse immediate access to the target web conference.

[0407] In one possible implementation, based on Figure 15 The device comprises:

[0408] The sending module is used to respond to the rejection operation by sending a status report message carrying the rejected status to the server. The status report message is used to request that the status parameter of the account for the target network conference be set to the rejected status.

[0409] In one possible implementation, the second display module 1502 is used for:

[0410] If no answer or reject operation is detected based on the call interface after the target time, the call notification message is displayed. The answer operation is used to trigger the account to immediately join the target network conference, and the reject operation is used to refuse to immediately join the target network conference.

[0411] In one possible implementation, based on Figure 15 The device comprises, wherein the second display module 1502 includes:

[0412] The display unit is used to display the call notification message in the application that displays the call interface; or, to display the call notification message in the message push bar of the device, wherein the message push bar is used to display notification messages of various applications that are active on the device.

[0413] In one possible implementation, the display unit is further configured to:

[0414] The call notification message is displayed in the session interface between the account and the target account that created the target web conference; or,

[0415] The call notification message is displayed in the message list for this account. This message list is used to display session messages or notification messages for this account.

[0416] In one possible implementation, the third display module 1503 is used for:

[0417] The call notification message displays the call notification text, the identification information of the target web conference, and an entry point for joining the target web conference. The call notification text is used to provide the account with the historical call records of the target web conference.

[0418] In one possible implementation, the third display module 1503 is used for:

[0419] The call notification message displays the call notification text, which is used to provide the account with the historical call records of the target web conference;

[0420] In response to the triggering action of the call notification message, display the identification information of the target web conference and the entry point for joining the target web conference.

[0421] In one possible implementation, the first display module 1501 is further configured to:

[0422] In response to an answering action triggered by the call interface or an action triggered by the entry point, the meeting interface of the target web conference is displayed. The answering action is used to trigger the account to immediately join the target web conference.

[0423] In one possible implementation, based on Figure 15 The device comprises:

[0424] The sending module is used to respond to the answering operation by sending a status report message carrying the answering status to the server. The status report message is used to request that the status parameter of the account for the target network conference be set to the answering status.

[0425] In one possible implementation, based on Figure 15 The device comprises:

[0426] The Cancel Display module is used to cancel the display of the call interface in response to an interface close message sent by the server. The interface close message is used to instruct the call interface to be closed if any terminal logged in to the account responds to the call request.

[0427] In one possible implementation, the first display module 1501 is used for:

[0428] In response to the call request, the call interface is displayed if the target web conference has not ended and the account has not joined any web conference.

[0429] In one possible implementation, the second display module 1502 is further configured to:

[0430] If another terminal logged into the same account responds to the call request, the call response message associated with that response will be displayed;

[0431] Specifically, when the response is an answer operation, the call response message is used to prompt the account to join the target network conference on the other terminal; when the response is a reject operation, the call response message is used to prompt the account to refuse to join the target network conference on the other terminal.

[0432] In one possible implementation, the third display module 1503 is further configured to:

[0433] Based on the call interface or the call notification message, a transfer entry for the target web conference is displayed, which is used to instruct other terminals logged in with the account to join the target web conference.

[0434] In one possible implementation, the third display module 1503 is further configured to: display a message reply entry based on the call interface or the call notification message; and display at least one preset reply message in response to a triggering operation on the message reply entry.

[0435] based on Figure 15 The device comprises: a sending module, configured to send the reply message to the target account that created the target web conference or to each account that joined the target web conference in response to a selection operation on any reply message or an input operation on the reply message.

[0436] All of the above-mentioned optional technical solutions can be combined in any way to form optional embodiments of this disclosure, and will not be described in detail here.

[0437] It should be noted that the message display device provided in the above embodiments is only illustrated by the division of the above functional modules when displaying messages. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the electronic device can be divided into different functional modules to complete all or part of the functions described above. In addition, the message display device and message display method embodiments provided in the above embodiments belong to the same concept, and the specific implementation process can be found in the message display method embodiments, which will not be repeated here.

[0438] Figure 16 This is a schematic diagram of the structure of a message transmission device provided in an embodiment of this application, as shown below. Figure 16 As shown, the device includes:

[0439] The sending module 1601 is used to send a call request to the account to be invited associated with the target web conference, and the call request is used to invite the account to join the target web conference;

[0440] The setting module 1602 is used to set the status parameter of the account for the target network conference to the "sent" status, which is used to indicate whether the account has joined the target network conference.

[0441] The sending module 1601 is also used to send a call notification message for the target network conference to the account when the account meets the message push conditions based on the status parameter. The call notification message is used to provide an entry point to join the target network conference.

[0442] The device provided in this application maintains a status parameter for each account invited to participate in the target network conference. Based on the status parameter, it can determine in a timely manner whether a call notification message needs to be pushed to the corresponding account. In this way, the call notification message provides users with a quick entry point to join the target network conference. When users have a need to delay joining the network conference, it can reduce the cumbersome operation of users joining the network conference and greatly improve the efficiency of human-computer interaction.

[0443] In one possible implementation, the message push condition includes at least one of the following: within a target duration after the call request is sent, the status parameter is set to the rejected state; or, when the target duration is reached after the call request is sent, the status parameter is still in the sent state.

[0444] In one possible implementation, the setting module 1602 is further configured to: in response to the status reporting information sent by the account, set the status parameter of the account to the answered status or rejected status carried in the status reporting information.

[0445] The sending module 1601 is also used to: send an interface close message to the account, the interface close message being used to instruct each terminal logged in by the account to close the call interface displayed based on the call request.

[0446] In one possible implementation, the sending module 1601 is further configured to:

[0447] In response to the status report, a status change instruction is sent to the target account that created the target network conference. The status change instruction is used to instruct the target account to update the account's status parameters in the conference member list based on the status report.

[0448] In one possible implementation, the meeting member list includes a first member list and a second member list. The first member list is used to display each account that has joined the target online meeting, and the second member list is used to display each account that has been invited but has not yet joined the target online meeting.

[0449] When the status report carries the message that the call has been answered, the status change indication message is used to indicate that the account should be moved from the second member list to the first member list.

[0450] When the status report carries a rejected status, the status change indication information is used to indicate that the calling option for the account is displayed in the second member list, and the calling option is used to trigger the resending of the call request to the account.

[0451] All of the above-mentioned optional technical solutions can be combined in any way to form optional embodiments of this disclosure, and will not be described in detail here.

[0452] It should be noted that the message transmission device provided in the above embodiments is only illustrated by the division of the above functional modules when transmitting messages. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the electronic device can be divided into different functional modules to complete all or part of the functions described above. In addition, the message transmission device and the message display method embodiments provided in the above embodiments belong to the same concept, and their specific implementation process can be found in the message display method embodiments, which will not be repeated here.

[0453] Figure 17 This is a schematic diagram of the structure of a terminal provided in an embodiment of this application, such as... Figure 17 As shown, terminal 1700 is an exemplary illustration of an electronic device. Optionally, the device type of terminal 1700 includes: a smartphone, tablet computer, MP3 player (Moving Picture Experts Group Audio Layer III), MP4 player (Moving Picture Experts Group Audio Layer IV), laptop computer, or desktop computer. Terminal 1700 may also be referred to as user equipment, portable terminal, laptop terminal, desktop terminal, or other names.

[0454] Typically, terminal 1700 includes a processor 1701 and a memory 1702.

[0455] Optionally, the processor 1701 includes one or more processing cores, such as a quad-core processor, an octa-core processor, etc. Optionally, the processor 1701 is implemented using at least one hardware form selected from DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), and PLA (Programmable Logic Array). In some embodiments, the processor 1701 includes a main processor and a coprocessor. The main processor, also known as a CPU (Central Processing Unit), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, the processor 1701 integrates a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content required to be displayed on the screen. In some embodiments, the processor 1701 also includes an AI (Artificial Intelligence) processor, which is used to handle computational operations related to machine learning.

[0456] In some embodiments, memory 1702 includes one or more computer-readable storage media, optionally non-transitory. Optionally, memory 1702 also includes high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In some embodiments, the non-transitory computer-readable storage media in memory 1702 is used to store at least one program code, which is executed by processor 1701 to implement the message display methods provided in the various embodiments of this application.

[0457] In some embodiments, the terminal 1700 may also optionally include a peripheral device interface 1703 and at least one peripheral device. The processor 1701, memory 1702, and peripheral device interface 1703 can be connected via a bus or signal line. Each peripheral device can be connected to the peripheral device interface 1703 via a bus, signal line, or circuit board. Specifically, the peripheral device includes at least one of the following: a radio frequency circuit 1704, a display screen 1705, a camera assembly 1706, an audio circuit 1707, and a power supply 1708.

[0458] Peripheral interface 1703 can be used to connect at least one I / O (Input / Output) related peripheral device to processor 1701 and memory 1702. In some embodiments, processor 1701, memory 1702 and peripheral interface 1703 are integrated on the same chip or circuit board; in some other embodiments, any one or two of processor 1701, memory 1702 and peripheral interface 1703 are implemented on separate chips or circuit boards, which is not limited in this embodiment.

[0459] The radio frequency (RF) circuit 1704 is used to receive and transmit RF (Radio Frequency) signals, also known as electromagnetic signals. The RF circuit 1704 communicates with communication networks and other communication devices via electromagnetic signals. The RF circuit 1704 converts electrical signals into electromagnetic signals for transmission, or converts received electromagnetic signals back into electrical signals. Optionally, the RF circuit 1704 includes: an antenna system, an RF transceiver, one or more amplifiers, a tuner, an oscillator, a digital signal processor, a codec chipset, a user identity module card, etc. Optionally, the RF circuit 1704 communicates with other terminals via at least one wireless communication protocol. This wireless communication protocol includes, but is not limited to: metropolitan area networks (MANs), various generations of mobile communication networks (2G, 3G, 4G, and 5G), wireless local area networks (WLANs), and / or WiFi (Wireless Fidelity) networks. In some embodiments, the RF circuit 1704 also includes circuitry related to NFC (Near Field Communication), which is not limited in this application.

[0460] Display screen 1705 is used to display a UI (User Interface). Optionally, the UI includes graphics, text, icons, videos, and any combination thereof. When display screen 1705 is a touch display screen, display screen 1705 also has the ability to collect touch signals on or above the surface of display screen 1705. The touch signals can be input to processor 1701 for processing as control signals. Optionally, display screen 1705 is also used to provide virtual buttons and / or virtual keyboards, also known as soft buttons and / or soft keyboards. In some embodiments, there is one display screen 1705, which is set on the front panel of terminal 1700; in other embodiments, there are at least two display screens 1705, which are respectively set on different surfaces of terminal 1700 or are folded; in still other embodiments, display screen 1705 is a flexible display screen, which is set on the curved surface or folded surface of terminal 1700. Furthermore, optionally, display screen 1705 is set as a non-rectangular irregular shape, that is, an irregularly shaped screen. Alternatively, the display screen 1705 may be made of materials such as LCD (Liquid Crystal Display) or OLED (Organic Light-Emitting Diode).

[0461] The camera assembly 1706 is used to acquire images or videos. Optionally, the camera assembly 1706 includes a front-facing camera and a rear-facing camera. Typically, the front-facing camera is located on the front panel of the terminal, and the rear-facing camera is located on the back of the terminal. In some embodiments, there are at least two rear-facing cameras, which are any one of a main camera, a depth-sensing camera, a wide-angle camera, and a telephoto camera, to achieve background blurring by fusion of the main camera and the depth-sensing camera, panoramic shooting by fusion of the main camera and the wide-angle camera, VR (Virtual Reality) shooting, or other fusion shooting functions. In some embodiments, the camera assembly 1706 also includes a flash. Optionally, the flash is a single-color temperature flash or a dual-color temperature flash. A dual-color temperature flash refers to a combination of a warm-light flash and a cool-light flash, used for light compensation at different color temperatures.

[0462] In some embodiments, the audio circuit 1707 includes a microphone and a speaker. The microphone is used to collect sound waves from the user and the environment, and convert the sound waves into electrical signals that are input to the processor 1701 for processing, or input to the radio frequency circuit 1704 to realize voice communication. For stereo acquisition or noise reduction purposes, multiple microphones are used, each located at a different part of the terminal 1700. Optionally, the microphone is an array microphone or an omnidirectional acquisition microphone. The speaker is used to convert the electrical signals from the processor 1701 or the radio frequency circuit 1704 into sound waves. Optionally, the speaker is a conventional film speaker or a piezoelectric ceramic speaker. When the speaker is a piezoelectric ceramic speaker, it can convert electrical signals not only into sound waves that humans can hear, but also into sound waves that humans cannot hear for purposes such as distance measurement. In some embodiments, the audio circuit 1707 also includes a headphone jack.

[0463] Power supply 1708 is used to power the various components in terminal 1700. Optionally, power supply 1708 is AC power, DC power, a disposable battery, or a rechargeable battery. When power supply 1708 includes a rechargeable battery, the rechargeable battery supports wired or wireless charging. The rechargeable battery also supports fast charging technology.

[0464] In some embodiments, the terminal 1700 further includes one or more sensors 1710. The one or more sensors 1710 include, but are not limited to: an acceleration sensor 1711, a gyroscope sensor 1712, a pressure sensor 1713, an optical sensor 1714, and a proximity sensor 1715.

[0465] In some embodiments, the accelerometer 1711 detects the magnitude of acceleration along the three coordinate axes of a coordinate system established with the terminal 1700. For example, the accelerometer 1711 is used to detect the components of gravitational acceleration along the three coordinate axes. Optionally, the processor 1701 controls the display screen 1705 to display the user interface in either a landscape or portrait view based on the gravitational acceleration signal acquired by the accelerometer 1711. The accelerometer 1711 is also used for acquiring motion data from games or the user.

[0466] In some embodiments, the gyroscope sensor 1712 detects the orientation and rotation angle of the terminal 1700. The gyroscope sensor 1712 and the accelerometer sensor 1711 work together to acquire the user's 3D movements on the terminal 1700. Based on the data acquired by the gyroscope sensor 1712, the processor 1701 implements the following functions: motion sensing (e.g., changing the UI based on the user's tilt operation), image stabilization during shooting, game control, and inertial navigation.

[0467] Optionally, the pressure sensor 1713 is disposed on the side bezel of the terminal 1700 and / or on the lower layer of the display screen 1705. When the pressure sensor 1713 is disposed on the side bezel of the terminal 1700, it can detect the user's grip signal on the terminal 1700, and the processor 1701 performs left / right hand recognition or quick operation based on the grip signal collected by the pressure sensor 1713. When the pressure sensor 1713 is disposed on the lower layer of the display screen 1705, the processor 1701 controls the operable controls on the UI interface based on the user's pressure operation on the display screen 1705. The operable controls include at least one of button controls, scroll bar controls, icon controls, and menu controls.

[0468] Optical sensor 1714 is used to collect ambient light intensity. In one embodiment, processor 1701 controls the display brightness of display screen 1705 based on the ambient light intensity collected by optical sensor 1714. Specifically, when the ambient light intensity is high, the display brightness of display screen 1705 is increased; when the ambient light intensity is low, the display brightness of display screen 1705 is decreased. In another embodiment, processor 1701 also dynamically adjusts the shooting parameters of camera assembly 1706 based on the ambient light intensity collected by optical sensor 1714.

[0469] The proximity sensor 1715, also known as a distance sensor, is typically located on the front panel of the terminal 1700. The proximity sensor 1715 is used to detect the distance between the user and the front of the terminal 1700. In one embodiment, when the proximity sensor 1715 detects that the distance between the user and the front of the terminal 1700 is gradually decreasing, the processor 1701 controls the display screen 1705 to switch from a screen-on state to a screen-off state; when the proximity sensor 1715 detects that the distance between the user and the front of the terminal 1700 is gradually increasing, the processor 1701 controls the display screen 1705 to switch from a screen-off state to a screen-on state.

[0470] Those skilled in the art will understand that Figure 17 The structure shown does not constitute a limitation on terminal 1700, which may include more or fewer components than shown, or combine certain components, or use different component arrangements.

[0471] Figure 18 This is a schematic diagram of the structure of a server provided in an embodiment of this application, such as... Figure 18As shown, server 1800 is an exemplary illustration of an electronic device. Server 1800 can vary significantly due to differences in configuration or performance. Server 1800 includes one or more Central Processing Units (CPUs) 1801 and one or more memories 1802. The memories 1802 store at least one computer program, which is loaded and executed by the one or more processors 1801 to implement the message display method or message transmission method provided in the various embodiments described above. Optionally, server 1800 also includes wired or wireless network interfaces, a keyboard, and input / output interfaces for input / output. Server 1800 also includes other components for implementing device functions, which will not be elaborated here.

[0472] In an exemplary embodiment, a computer-readable storage medium is also provided, such as a memory including at least one computer program, which can be executed by a processor in a terminal to perform the message display method or message transmission method in the various embodiments described above. For example, the computer-readable storage medium includes ROM (Read-Only Memory), RAM (Random-Access Memory), CD-ROM (CompactDisc Read-Only Memory), magnetic tape, floppy disk, and optical data storage devices, etc.

[0473] In an exemplary embodiment, a computer program product or computer program is also provided, including one or more lines of program code stored in a computer-readable storage medium. One or more processors of an electronic device are capable of reading the one or more lines of program code from the computer-readable storage medium, and the one or more processors execute the one or more lines of program code, enabling the electronic device to perform the message display method or message transmission method described in the above embodiments.

[0474] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. Optionally, the program is stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0475] The above description is merely an optional embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A message display method, characterized in that, The method includes: The first terminal provides participant configuration options in the meeting creation interface; in response to the confirmation operation of at least one invited account selected based on the participant configuration options, it sends a meeting ticket request carrying the account identifier of the at least one invited account to the message server; The message server parses the conference ticket request to obtain a list of accounts to be invited; based on the list of accounts to be invited, it generates and stores a key-value pair data structure, where the key is a string generated for the target network conference and the key is the list of accounts to be invited; the key is returned to the first terminal as a conference ticket for the target network conference. After receiving the meeting ticket, the first terminal receives other meeting information entered in the meeting creation interface. When the other meeting information is information obtained by re-editing the various invited accounts that have already been configured, the terminal re-sends a meeting ticket request to the message server to apply for a meeting ticket. In response to triggering the creation option in the meeting creation interface, the first terminal sends a meeting creation request to the meeting server, which carries at least a meeting ticket, a list of accounts to be invited, and meeting description information. The meeting description information carries the ringing time corresponding to the target network meeting, and the ringing time is located before the start time of the target network meeting. The meeting server parses the meeting creation request to obtain the meeting ticket, the list of accounts to be invited, and the meeting description information. Based on the parsed meeting ticket, it executes a verification process, authenticates each account to be invited in the received list of accounts to be invited, discards accounts that fail verification, and combines the remaining verified accounts with the meeting description information to create the target network meeting and assign a unique identifier to the target network meeting. The identifier information is then returned to the first terminal. The verification process is as follows: The meeting server sends a query request carrying at least one meeting ticket to the message server; the message server responds to the query request by querying the key value corresponding to the key name in a pre-stored key-value pair data structure for each meeting ticket, using the meeting ticket as the key name, to obtain the list of invited accounts stored in the key value. After traversing all meeting tickets in the query request, one or more lists of invited accounts can be obtained; the message server returns the union of all the queried lists of invited accounts to the meeting server; the meeting server receives the union and, for each invited account in the list of invited accounts parsed from the meeting creation request, determines whether the invited account can be matched with the same invited account in the union. If it can be matched, the current invited account passes the authentication verification; if it cannot be matched, the current invited account fails the authentication verification and is discarded; the process continues to traverse the next invited account for authentication verification. At the ringing time, the conference server sends a ringing push request to the message server. The ringing push request carries at least the full conference tickets corresponding to the target network conference, as well as a full list of invited accounts consisting of the account identifiers of all invited accounts that have passed the authentication verification after the conference server performs the authentication verification. The ringing push request is used to request the message server to push call requests to the invited accounts. The message server parses the ringing push request to obtain the full conference ticket and the full list of accounts to be invited; it uses the full conference ticket to authenticate and verify the parsed full list of accounts to be invited; for each account to be invited that passes the authentication and verification, the message server pushes the call request to the second terminal logged into each account to invite the corresponding account to join the target network conference. In response to the call request, the second terminal sends a meeting status query request to the message server, carrying at least the identification information and the account identifier of the account to be invited logged into the second terminal. In response to the meeting status query request, the message server uses the identification information to query the meeting status of the target network meeting from the meeting server, obtaining a meeting status query result. Simultaneously, using the account identifier of the account to be invited, the message server queries whether the account to be invited is currently in any network meeting, obtaining a participation status query result. The message server returns the meeting status query result and the participation status query result to the second terminal. If the target network meeting has not ended and the account logged into the second terminal has not joined any network meeting, the second terminal displays the call interface of the target network meeting. If the account logged into the second terminal has not joined the target network conference through the call interface, the second terminal displays a call notification message for the target network conference; based on the call notification message, an entry point for joining the target network conference is displayed.

2. The method according to claim 1, characterized in that, When the account logged into the second terminal has not joined the target network conference through the call interface, the call notification message for the target network conference displayed on the second terminal includes: The second terminal responds to the call rejection operation triggered by the call interface by displaying the call notification message, the call rejection operation being used to refuse to immediately join the target network conference.

3. The method according to claim 2, characterized in that, The method further includes: In response to the rejection operation, the second terminal sends a status report message to the server carrying the status of rejection. The status report message is used to request that the status parameter of the account for the target network conference be set to the rejected status.

4. The method according to claim 1, characterized in that, When the account logged into the second terminal has not joined the target network conference through the call interface, the call notification message for the target network conference displayed on the second terminal includes: If the second terminal does not detect an answer or reject operation based on the call interface for a period of time exceeding the target duration, it displays the call notification message. The answer operation is used to trigger the account to immediately join the target network conference, and the reject operation is used to refuse to immediately join the target network conference.

5. The method according to claim 1, characterized in that, The call notification message displaying the target network conference includes: In the application displaying the call interface, the call notification message is displayed; or, The call notification message is displayed in the message push bar of the terminal, wherein the message push bar is used to display notification messages of various applications that are active on the terminal.

6. The method according to claim 5, characterized in that, The process of displaying the call notification message in the application that displays the call interface includes: The call notification message is displayed in the session interface between the account and the target account that created the target web conference; or, The call notification message is displayed in the message list of the account. The message list is used to display session messages or notification messages for the account.

7. The method according to claim 1, characterized in that, The method of displaying an entry point for joining the target web conference based on the call notification message includes: The call notification message displays the call notification text, the identification information of the target web conference, and an entry point for joining the target web conference. The call notification text is used to provide the account with the historical call records of the target web conference.

8. The method according to claim 1, characterized in that, The method of displaying an entry point for joining the target web conference based on the call notification message includes: The call notification message displays a call notification text, which is used to provide the account with the historical call records of the target web conference; In response to the triggering operation of the call notification message, the identification information of the target web conference and the entry point for joining the target web conference are displayed.

9. The method according to claim 1, characterized in that, The method further includes: The second terminal responds to an answer operation triggered by the call interface or an entry point trigger operation by displaying the meeting interface of the target network conference. The answer operation is used to trigger the account to immediately join the target network conference.

10. The method according to claim 9, characterized in that, The method further includes: In response to the answering operation, the second terminal sends a status report message carrying the status of being answered to the server. The status report message is used to request that the status parameter of the account for the target network conference be set to the status of being answered.

11. The method according to claim 1, characterized in that, The method further includes: The second terminal responds to the interface shutdown message sent by the server and cancels the display of the call interface. The interface shutdown message is used to instruct the call interface to be closed when any terminal logged in by the account responds to the call request.

12. The method according to claim 1, characterized in that, The method further includes: When another terminal logged into the account responds to the call request, the second terminal displays a call response message associated with the response; Specifically, when the response is an answer operation, the call response message is used to prompt the account to join the target network conference on the other terminal; when the response is a reject operation, the call response message is used to prompt the account to refuse to join the target network conference on the other terminal.

13. The method according to claim 1, characterized in that, The method further includes: The second terminal displays a transfer entry to the target web conference based on the call interface or the call notification message. The transfer entry is used to instruct other terminals logged in with the account to join the target web conference.

14. The method according to claim 1, characterized in that, The method further includes: The second terminal displays a message reply entry based on the call interface or the call notification message; In response to the triggering operation of the message reply entry, the second terminal displays at least one preset reply message; In response to a selection operation on any reply message or an input operation on a reply message, the second terminal sends the reply message to the target account that created the target network conference or to each account that joined the target network conference.

15. A message transmission method, characterized in that, The method, executed by the server, includes: Send a call request to a second terminal associated with the account to be invited to the target web conference, the call request being used to invite the account to join the target web conference; Set the account's status parameter for the target network conference to "sent" status, whereby the status parameter indicates whether the account has joined the target network conference. If the account meets the message push conditions based on the status parameters, a call notification message for the target network conference is sent to the account. The call notification message is used to provide an entry point to join the target network conference. The target web conference was created by the first terminal in the following manner: The meeting creation interface provides participant configuration options; in response to a confirmation operation on at least one invited account selected based on the participant configuration options, a meeting ticket request carrying the account identifier of the at least one invited account is sent to the message server. The message server is configured to: parse the meeting ticket request to obtain a list of accounts to be invited; based on the list of accounts to be invited, generate and store a key-value pair data structure, where the key is a string generated for the target network meeting and the key is the list of accounts to be invited; and return the key as a meeting ticket for the target network meeting to the first terminal. After receiving the meeting ticket, the system receives other meeting information entered in the meeting creation interface. When the other meeting information is information that has been edited from the already configured information of each invited account, the system resends a meeting ticket request to the message server to apply for a meeting ticket. In response to triggering the creation option in the meeting creation interface, a meeting creation request is sent to the meeting server, carrying at least a meeting ticket, a list of accounts to be invited, and meeting description information. The meeting description information carries the ringing time corresponding to the target network meeting, and the ringing time is located before the start time of the target network meeting. The meeting server is configured to: parse the meeting creation request to obtain the meeting ticket, the list of accounts to be invited, and the meeting description information; based on the parsed meeting ticket, execute a verification process to authenticate each account to be invited in the received list of accounts to be invited, discard accounts that fail verification, and combine the remaining verified accounts to be invited with the meeting description information to create the target network meeting and assign a unique identifier to the target network meeting; and return the identifier to the first terminal. The verification process is as follows: The meeting server sends a query request carrying at least one meeting ticket to the message server; the message server responds to the query request by querying the key value corresponding to the key name in a pre-stored key-value pair data structure for each meeting ticket, using the meeting ticket as the key name, to obtain the list of invited accounts stored in the key value. After traversing all meeting tickets in the query request, one or more lists of invited accounts can be obtained; the message server returns the union of all the queried lists of invited accounts to the meeting server; the meeting server receives the union and, for each invited account in the list of invited accounts parsed from the meeting creation request, determines whether the invited account can be matched with the same invited account in the union. If it can be matched, the current invited account passes the authentication verification; if it cannot be matched, the current invited account fails the authentication verification and is discarded; the process continues to traverse the next invited account for authentication verification. The conference server is further configured to: send a ringing push request to the message server at the ringing time. The ringing push request carries at least the full conference ticket corresponding to the target network conference, and a full list of invited accounts consisting of the account identifiers of all invited accounts that have passed the authentication verification after the conference server performs the authentication verification. The ringing push request is used to request the message server to push a call request to the invited accounts. The message server is also used to: parse the ringing push request to obtain the full conference ticket and the full list of accounts to be invited; use the full conference ticket to authenticate and verify the parsed full list of accounts to be invited; for each account to be invited that has passed the authentication and verification, the message server pushes the call request to the second terminal that has logged into each account to invite the corresponding account to join the target network conference; The second terminal is configured to: in response to the call request, send a meeting status query request to the message server, carrying at least the identification information and the account identifier of the invited account logged into the second terminal; if the target network meeting has not ended and the account logged into the second terminal has not joined any network meeting, display the call interface of the target network meeting; if the account logged into the second terminal has not joined the target network meeting based on the call interface, display the call notification message of the target network meeting; and display an entry point for joining the target network meeting based on the call notification message. The message server is further configured to: respond to the meeting status query request, use the identification information to query the meeting status of the target network meeting from the meeting server to obtain the meeting status query result, and use the account identifier of the account to be invited to query from the meeting server whether the account to be invited is currently in any network meeting to obtain the participation status query result; and return the meeting status query result and the participation status query result to the second terminal.

16. The method according to claim 15, characterized in that, The message push conditions include at least one of the following: within a target duration after sending the call request, the status parameter is set to the rejected state; or, when the target duration is reached after sending the call request, the status parameter is still in the sent state.

17. The method according to claim 16, characterized in that, The method further includes: In response to the status reporting information sent by the account, the status parameter of the account is set to the answered or rejected status carried in the status reporting information. Send an interface close message to the account, the interface close message being used to instruct each terminal logged in by the account to close the call interface displayed based on the call request.

18. The method according to claim 17, characterized in that, The method further includes: In response to the status reporting information, a status change instruction is sent to the target account that created the target network conference. The status change instruction is used to instruct the target account to update the status parameters of the account in the conference member list based on the status reporting information.

19. The method according to claim 18, characterized in that, The meeting member list includes a first member list and a second member list. The first member list is used to display each account that has joined the target online meeting, and the second member list is used to display each account that has been invited but has not yet joined the target online meeting. When the status report information carries a "call answered" status, the status change indication information is used to indicate that the account be transferred from the second member list to the first member list; If the status report information carries a rejected status, the status change indication information is used to indicate that the calling option of the account is displayed in the second member list, and the calling option is used to trigger the resending of the calling request to the account.

20. A message display device, characterized in that, The device includes: The first display module is used to respond to a call request from a target network conference. If the target network conference has not ended and the account logged into the device has not joined any network conference, the call request is used to invite the account to join the target network conference. The second display module is used to display the call notification message of the target network conference when the account has not joined the target network conference based on the call interface; The third display module is used to display an entry point for joining the target web conference based on the call notification message; The target web conference is created based on the following interaction flow: The first terminal provides participant configuration options in the meeting creation interface; in response to the confirmation operation of at least one invited account selected based on the participant configuration options, it sends a meeting ticket request carrying the account identifier of the at least one invited account to the message server; The message server parses the conference ticket request to obtain a list of accounts to be invited; based on the list of accounts to be invited, it generates and stores a key-value pair data structure, where the key is a string generated for the target network conference and the key is the list of accounts to be invited; the key is returned to the first terminal as a conference ticket for the target network conference. After receiving the meeting ticket, the first terminal receives other meeting information entered in the meeting creation interface. When the other meeting information is information obtained by re-editing the various invited accounts that have already been configured, the terminal re-sends a meeting ticket request to the message server to apply for a meeting ticket. In response to triggering the creation option in the meeting creation interface, the first terminal sends a meeting creation request to the meeting server, which carries at least a meeting ticket, a list of accounts to be invited, and meeting description information. The meeting description information carries the ringing time corresponding to the target network meeting, and the ringing time is located before the start time of the target network meeting. The meeting server parses the meeting creation request to obtain the meeting ticket, the list of accounts to be invited, and the meeting description information. Based on the parsed meeting ticket, it executes a verification process, authenticates each account to be invited in the received list of accounts to be invited, discards accounts that fail verification, and combines the remaining verified accounts with the meeting description information to create the target network meeting and assign a unique identifier to the target network meeting. The identifier information is then returned to the first terminal. The verification process is as follows: The meeting server sends a query request carrying at least one meeting ticket to the message server; the message server responds to the query request by querying the key value corresponding to the key name in a pre-stored key-value pair data structure for each meeting ticket, using the meeting ticket as the key name, to obtain the list of invited accounts stored in the key value. After traversing all meeting tickets in the query request, one or more lists of invited accounts can be obtained; the message server returns the union of all the queried lists of invited accounts to the meeting server; the meeting server receives the union and, for each invited account in the list of invited accounts parsed from the meeting creation request, determines whether the invited account can be matched with the same invited account in the union. If it can be matched, the current invited account passes the authentication verification; if it cannot be matched, the current invited account fails the authentication verification and is discarded; the process continues to traverse the next invited account for authentication verification. The device receiving the call request determines this based on the following message interaction process: At the ringing time, the conference server sends a ringing push request to the message server. The ringing push request carries at least the full conference tickets corresponding to the target network conference, as well as a full list of invited accounts consisting of the account identifiers of all invited accounts that have passed the authentication verification after the conference server performs the authentication verification. The ringing push request is used to request the message server to push call requests to the invited accounts. The message server parses the ringing push request to obtain the full conference ticket and the full list of accounts to be invited; it uses the full conference ticket to authenticate and verify the parsed full list of accounts to be invited; for each account to be invited that passes the authentication and verification, the message server pushes a call request to the device that is logged into each account to be invited.

21. The apparatus according to claim 20, characterized in that, The second display module is used for: In response to a rejection operation triggered by the call interface, the call notification message is displayed, the rejection operation being used to refuse immediate access to the target web conference.

22. The apparatus according to claim 21, characterized in that, The device further includes: The sending module is used to respond to the rejection operation by sending a status report information carrying the rejected status to the server. The status report information is used to request that the status parameter of the account for the target network conference be set to the rejected status.

23. The apparatus according to claim 20, characterized in that, The second display module is used for: If no answer or reject operation is detected based on the call interface after the target time period, the call notification message is displayed. The answer operation is used to trigger the account to immediately join the target network conference, and the reject operation is used to refuse to immediately join the target network conference.

24. The apparatus according to claim 20, characterized in that, The second display module includes: The display unit is configured to display the call notification message in an application that displays the call interface; or, to display the call notification message in the message push bar of the device, wherein the message push bar is configured to display notification messages of various applications that are active on the device.

25. The apparatus according to claim 24, characterized in that, The display unit is also used for: The call notification message is displayed in the session interface between the account and the target account that created the target web conference; or, The call notification message is displayed in the message list of the account. The message list is used to display session messages or notification messages for the account.

26. The apparatus according to claim 20, characterized in that, The third display module is used for: The call notification message displays the call notification text, the identification information of the target web conference, and an entry point for joining the target web conference. The call notification text is used to provide the account with the historical call records of the target web conference.

27. The apparatus according to claim 20, characterized in that, The third display module is used for: The call notification message displays a call notification text, which is used to provide the account with the historical call records of the target web conference; In response to the triggering operation of the call notification message, the identification information of the target web conference and the entry point for joining the target web conference are displayed.

28. The apparatus according to claim 20, characterized in that, The first display module is also used for: In response to an answering operation triggered by the call interface or a triggering operation on the entry point, the meeting interface of the target network conference is displayed, wherein the answering operation is used to trigger the account to immediately join the target network conference.

29. The apparatus according to claim 28, characterized in that, The device further includes: The sending module is used to respond to the answering operation by sending a status report information carrying the answering status to the server. The status report information is used to request that the status parameter of the account for the target network conference be set to the answering status.

30. The apparatus according to claim 20, characterized in that, The device further includes: The cancellation module is used to cancel the display of the call interface in response to an interface close message sent by the server. The interface close message is used to instruct the call interface to be closed when any device logged in to the account responds to the call request.

31. The apparatus according to claim 20, characterized in that, The second display module is also used for: If another device logged into the account responds to the call request, a call response message associated with the response is displayed; Specifically, when the response is an answer operation, the call response message is used to prompt the account to join the target network conference on the other device; when the response is a reject operation, the call response message is used to prompt the account to refuse to join the target network conference on the other device.

32. The apparatus according to claim 20, characterized in that, The third display module is also used for: Based on the call interface or the call notification message, a transfer entry to the target web conference is displayed, which is used to instruct users to join the target web conference on other devices logged into the account.

33. The apparatus according to claim 20, characterized in that, The third display module is also used to display a message reply entry based on the call interface or the call notification message; and to display at least one preset reply message in response to a trigger operation on the message reply entry. The sending module is used to send the reply message to the target account that created the target network conference or to each account that joined the target network conference in response to a selection operation on any reply message or an input operation on the reply message.

34. A message transmission device, characterized in that, The device includes: The sending module is used to send a call request to a device associated with an account to be invited to the target web conference, the call request being used to invite the account to join the target web conference; The settings module is used to set the status parameter of the account to the target network conference to the "sent" status, and the status parameter is used to indicate whether the account has joined the target network conference; The sending module is further configured to send a call notification message for the target network conference to the account when the account meets the message push conditions based on the status parameters. The call notification message is used to provide an entry point to join the target network conference. The target web conference is created by the first terminal in the following manner: The meeting creation interface provides participant configuration options; in response to a confirmation operation on at least one invited account selected based on the participant configuration options, a meeting ticket request carrying the account identifier of the at least one invited account is sent to the message server. The message server is configured to: parse the meeting ticket request to obtain a list of accounts to be invited; based on the list of accounts to be invited, generate and store a key-value pair data structure, where the key is a string generated for the target network meeting and the key is the list of accounts to be invited; and return the key as a meeting ticket for the target network meeting to the first terminal. After receiving the meeting ticket, the system receives other meeting information entered in the meeting creation interface. When the other meeting information is information that has been edited from the already configured information of each invited account, the system resends a meeting ticket request to the message server to apply for a meeting ticket. In response to triggering the creation option in the meeting creation interface, a meeting creation request is sent to the meeting server, carrying at least a meeting ticket, a list of accounts to be invited, and meeting description information. The meeting description information carries the ringing time corresponding to the target network meeting, and the ringing time is located before the start time of the target network meeting. The meeting server is configured to: parse the meeting creation request to obtain the meeting ticket, the list of accounts to be invited, and the meeting description information; based on the parsed meeting ticket, execute a verification process to authenticate each account to be invited in the received list of accounts to be invited, discard accounts that fail verification, and combine the remaining verified accounts to be invited with the meeting description information to create the target network meeting and assign a unique identifier to the target network meeting; and return the identifier to the first terminal. The verification process is as follows: The meeting server sends a query request carrying at least one meeting ticket to the message server; the message server responds to the query request by querying the key value corresponding to the key name in a pre-stored key-value pair data structure for each meeting ticket, using the meeting ticket as the key name, to obtain the list of invited accounts stored in the key value. After traversing all meeting tickets in the query request, one or more lists of invited accounts can be obtained; the message server returns the union of all the queried lists of invited accounts to the meeting server; the meeting server receives the union and, for each invited account in the list of invited accounts parsed from the meeting creation request, determines whether the invited account can be matched with the same invited account in the union. If it can be matched, the current invited account passes the authentication verification; if it cannot be matched, the current invited account fails the authentication verification and is discarded; the process continues to traverse the next invited account for authentication verification. The conference server is further configured to: send a ringing push request to the message server at the ringing time. The ringing push request carries at least the full conference ticket corresponding to the target network conference, and a full list of invited accounts consisting of the account identifiers of all invited accounts that have passed the authentication verification after the conference server performs the authentication verification. The ringing push request is used to request the message server to push a call request to the invited accounts. The message server is also used to: parse the ringing push request to obtain the full conference ticket and the full list of accounts to be invited; use the full conference ticket to authenticate and verify the parsed full list of accounts to be invited; for each account to be invited that has passed the authentication and verification, the message server pushes the call request to the device that has logged into each account to invite the corresponding account to join the target network conference; The device for logging into the invited account is configured to: in response to the call request, send a meeting status query request to the message server, carrying at least the identification information and the account identifier of the invited account logged into the device; if the target network meeting has not ended and the account logged into the device has not joined any network meeting, display the call interface of the target network meeting; if the account logged into the device has not joined the target network meeting based on the call interface, display the call notification message of the target network meeting; and display an entry point for joining the target network meeting based on the call notification message. The message server is further configured to: respond to the meeting status query request, use the identification information to query the meeting status of the target network meeting from the meeting server to obtain the meeting status query result, and simultaneously use the account identifier of the account to be invited to query from the meeting server whether the account to be invited is currently in any network meeting to obtain the participation status query result; and return the meeting status query result and the participation status query result to the device that logs in to the account to be invited.

35. The apparatus according to claim 34, characterized in that, The message push conditions include at least one of the following: within a target duration after sending the call request, the status parameter is set to the rejected state; or, when the target duration is reached after sending the call request, the status parameter is still in the sent state.

36. The apparatus according to claim 35, characterized in that, The setting module is also used for: In response to the status reporting information sent by the account, the status parameter of the account is set to the answered or rejected status carried in the status reporting information. The sending module is further configured to: send an interface close message to the account, the interface close message being used to instruct each device logged in by the account to close the call interface displayed based on the call request.

37. The apparatus according to claim 36, characterized in that, The sending module is also used for: In response to the status reporting information, a status change instruction is sent to the target account that created the target network conference. The status change instruction is used to instruct the target account to update the status parameters of the account in the conference member list based on the status reporting information.

38. The apparatus according to claim 37, characterized in that, The meeting member list includes a first member list and a second member list. The first member list is used to display each account that has joined the target online meeting, and the second member list is used to display each account that has been invited but has not yet joined the target online meeting. When the status report information carries a "call answered" status, the status change indication information is used to indicate that the account be transferred from the second member list to the first member list; If the status report information carries a rejected status, the status change indication information is used to indicate that the calling option of the account is displayed in the second member list, and the calling option is used to trigger the resending of the calling request to the account.

39. An electronic device, characterized in that, The electronic device includes one or more processors and one or more memories, wherein the one or more memories store at least one computer program, which is loaded and executed by the one or more processors to implement the message display method as described in any one of claims 1 to 14; or, the message transmission method as described in any one of claims 15 to 19.

40. A storage medium, characterized in that, The storage medium stores at least one computer program, which is loaded and executed by a processor to implement the message display method as described in any one of claims 1 to 14; or the message transmission method as described in any one of claims 15 to 19.

41. A computer program product, characterized in that, The computer program product includes at least one computer program, which is loaded and executed by a processor to implement the message display method as described in any one of claims 1 to 14; or the message transmission method as described in any one of claims 15 to 19.

Images