Information pushing method and apparatus, system, storage medium, and program product

Abstract

An information pushing method and apparatus, a system, a storage medium, and a program product, relating to the technical field of terminals, and used for improving the accuracy of livestreaming message pushing. The method comprises: in response to an operation of pulling down a notification bar on a terminal device by a user, the terminal device sends a livestreaming request message to a server, receives a livestreaming response message from the server, and displays, in the notification bar, first livestreaming information comprised in the livestreaming response message, the first livestreaming information comprising first livestreaming content of a first streamer related to the user. When the user pulls down the notification bar, currently livestreamed content in a live stream is acquired in real time and pushed to the user, so that the user can acquire the most real-time and accurate livestreaming content. Hence, if interested in the current livestreaming content, the user can enter the live stream to watch the live stream, and even perform livestreaming interaction, thus reducing the probability of the user erroneously entering the live stream, and improving the live stream watching experience and livestreaming interaction experience of the user.

Description

An information push method, device, system, storage medium, and program product.

[0001] Cross-references to related applications

[0002] This application claims priority to Chinese Patent Application No. 202510136861.0, filed on February 7, 2025, entitled "An Information Push Method, Apparatus, System, Storage Medium and Program Product", the entire contents of which are incorporated herein by reference. Technical Field

[0003] This application relates to the field of terminal technology, and in particular to an information push method, device, system, storage medium and program product. Background Technology

[0004] With the popularization and development of internet technology, live streaming has gradually penetrated into all walks of life and is showing an increasingly popular trend. Both live streaming platforms and live streamers hope to present good live streaming content to users, and users also hope to obtain the live streaming content they expect.

[0005] However, current mainstream live streaming push notifications require users to actively open the live streaming app on their devices and subscribe to messages from streamers they are interested in. Only when the streamer the user subscribed to starts broadcasting does the device display a pre-set live stream message in the notification bar, informing the user that the live stream has started. If the user is interested, they can click on the message to enter the live stream room and watch. However, this push notification method is inaccurate and may mislead users, affecting their live streaming experience. For example, if a user subscribes to AAA's live stream, the device will push a pre-set message like "AAA is live!" or similar content to the user when AAA starts broadcasting. However, most users cannot check the push notification in time; they only check it after the live stream has expired or ended, and then they cannot watch the live stream content from the streamer they are interested in. It's also possible that a user is only interested in certain parts of AAA's live stream and not the rest. In this case, the user only realizes their lack of interest after entering the live stream room and then exits, resulting in a degraded live streaming experience.

[0006] In conclusion, improving the timeliness and accuracy of live streaming message delivery is a pressing technical issue that needs to be addressed in the field of online live streaming. Summary of the Invention

[0007] This application provides an information push method, apparatus, system, storage medium, and program product to improve the timeliness and accuracy of live message push.

[0008] Firstly, this application provides an information push method, which is applied to a terminal device, and can be executed by the terminal device or a module (such as a processor, chip, or chip system) within the terminal device. Taking execution by a terminal device as an example, the method includes the following steps: In response to a user's action of pulling down the terminal device's notification bar, the terminal device sends a live streaming request message to a server and receives a live streaming response message from the server, and displays the first live streaming information included in the live streaming response message in the notification bar, wherein the first live streaming information includes the first live streaming content of a first broadcaster related to the user.

[0009] It should be noted that "user-related broadcasters" can be understood as broadcasters who have an association with the user. These broadcasters might be those the user is interested in, such as those the user has followed, favorited, or interacted with. They could also be broadcasters the server deems appropriate to push to the user, such as broadcasters the user hasn't followed but are of the same type as those the user does follow, broadcasts from areas the user has never followed, or broadcasts from the broadcasters with the highest current traffic on the platform, etc. In some examples, the specific broadcaster(s) referred to as "user-related broadcasters" can be determined by the server's push strategy; this application does not impose specific limitations on this.

[0010] Based on the above methods, by obtaining the content currently being broadcast in the live room in real time when the user pulls down the notification bar and pushing it to the user, the user can obtain the most real-time and accurate live broadcast content. In this way, if the user is interested in the current live broadcast content, they can enter the live room to watch the live broadcast and even interact with the live broadcast, reducing the probability of users accidentally entering the live room and improving the user's live broadcast viewing experience and live broadcast interaction experience.

[0011] It's important to note that the notification bar doesn't display live stream information until the user pulls it down. Even if the server pushes live stream information to the device, the device won't display it in the notification bar; instead, it will cache it locally. When the user habitually pulls down the notification bar to check for live stream information, the device then requests the live stream content from the server and displays it in the notification bar. This way, the user sees the currently streaming live content in the notification bar, allowing them to accurately match their interests and enter the live stream only when they are interested. This not only reduces the probability of users accidentally entering the live stream and improves the user experience, but also increases the interaction rate and product purchase rate of the live stream because only users interested in the live stream content enter.

[0012] In one possible design, before responding to the user's action of pulling down the notification bar on the terminal device, the terminal device also receives a first live push message from the server. The first live push message includes a setting flag, which is a flag that instructs the terminal device to send a live request message to the server when the user pulls down the notification bar.

[0013] Based on the above design, after receiving a live push message with a set tag, the terminal device can monitor the user's action of pulling down the notification bar and send a live request message to the server to request real-time live content. This is equivalent to providing a trigger condition for the terminal device to start real-time live push. The terminal device only needs to start real-time live push according to the instruction message sent by the server side, without having to decide when to start it, which can reduce the design difficulty of adding real-time live push function to the terminal device.

[0014] In one example of the above design, the first live stream push message also includes second live stream information, which is a preset live stream information generated by the server. After the terminal device sends a live stream request message to the server, if it does not receive a live stream response message within a first set time period, it will display the second live stream information in the notification bar.

[0015] Based on the above design, if the terminal device receives the live streaming content from the server before the request times out, it will push the live streaming content to the user. If the terminal device does not receive the live streaming content after the request times out, it will display the preset live streaming content to the user. In this way, it can provide users with live streaming content as much as possible while avoiding situations where users do not receive push messages for a long time, ensuring that users receive timely live streaming push experiences.

[0016] In one possible design, the terminal device can also receive a second live broadcast push message from the server. If the second live broadcast push message includes second live broadcast information but does not include a setting flag, the second live broadcast information will be displayed in the notification bar. The second live broadcast information is the preset live broadcast information generated by the server.

[0017] Based on the above design, after receiving a live broadcast push message without a set tag, the terminal device will display the preset second live broadcast information to the user. In other words, it will follow the original live broadcast push logic. This can avoid the impact of adding a real-time live broadcast push function to the terminal device on the original live broadcast push logic of the terminal device.

[0018] In one example of the above design, the first live push message and / or the second live push message can be sent to the terminal device through a long push connection between the server and the terminal device.

[0019] Based on the above example, by establishing a long connection between the server and the terminal device, the server can quickly and directly transmit live push messages to the terminal device through this long connection, avoiding the operational complexity and transmission latency issues caused by repeatedly establishing short connections.

[0020] In one possible design, before responding to the user's action of pulling down the notification bar of the terminal device, the terminal device can also receive a notification message from the server, which includes the identifier of the first application (APP) to instruct the first APP to enable the real-time live streaming push function; the terminal device sends a live streaming request message to the server, specifically: the terminal device sends a live streaming request message carrying the identifier of the first APP to the server, which is used to request the live streaming content of the host broadcasting on the first APP.

[0021] Based on the above design, by notifying the terminal device of the APP that supports the real-time live streaming push function, the terminal device can push real-time live streaming content to these APPs in a more targeted manner, so as to meet the different needs of different APPs regarding whether to enable the real-time live streaming push function.

[0022] In one example of the above design, after receiving a live response message from the server, the terminal device can also store the first live information in the live response message into a set queue. If there are other live information of the first APP in the set queue, the other live information and the first live information are deduplicated. After deduplication, the first APP has only one live information in the set queue.

[0023] Based on the above examples, it can be ensured that there is only one live stream message to be pushed to the same app in the queue at the same time, avoiding the situation of pushing multiple live stream messages from the same live streaming app to the user at the same time, thus improving the user's live stream push experience.

[0024] In one example of the above design, the notification message also includes a first address, which is the storage address of the image content in the live stream content of each streamer broadcasting on the first app; the first live stream content includes the text description content in the live stream content of the first streamer, and the live stream response message also includes a location identifier, which is used to indicate the storage location of the image content in the live stream content of the first streamer in the first address. Based on this, the terminal device displays the first live stream information in the notification bar, specifically: the terminal device obtains the image content in the live stream content of the first streamer according to the first address and the location identifier, and displays the image content together with the text description content in the first live stream content in the notification bar.

[0025] Based on the above examples, the terminal device can combine a pre-configured address and the location identifier in the live broadcast response message to obtain the image content currently being broadcast by the anchor relevant to the user. This allows the terminal device to push the anchor's image content along with text descriptions to the user, improving the user's viewing experience. Furthermore, by returning the storage address of the image content to the terminal device, instead of the actual image content, the device can still obtain the image content while reducing the amount of data carried in the returned information. This reduces communication losses, improves transmission efficiency, and ultimately enhances the efficiency of pushing real-time live broadcast messages.

[0026] In one possible design, the first live stream content includes the text description of the first streamer's live stream content. The live stream response message also includes a second address, which is the storage address of the image content in the first streamer's live stream content. Based on this, the terminal device displays the first live stream information in the notification bar. Specifically, the terminal device retrieves the image content from the first streamer's live stream content from the second address and displays the image content along with the text description of the first live stream content in the notification bar.

[0027] Based on the above design, the terminal device can directly obtain the storage address of the image content currently being streamed by the host by parsing the live broadcast response message. The terminal device can then access this storage address to retrieve the image content without needing to configure the address in advance. This design achieves the same technical effect as the previous example while reducing operational complexity.

[0028] In one example of the above design, the first live stream content also includes the main visual image of the first anchor's live stream content.

[0029] Based on the above examples, the real-time push notifications that users view not only include text content, but also the main visual image of the streamer currently broadcasting, thereby improving the visual experience of users watching real-time live push notifications.

[0030] In one example of the above design, the image content includes video clips, animated images, and still images. The terminal device displays the image content and text description together in the notification bar. Specifically, the terminal device may display one of the video clips, animated images, and still images together with the text description in the notification bar.

[0031] Based on the above example, the terminal device will only display one of the multiple image contents. In this way, it can ensure that users can see the live image content, and will not repeatedly display different types of image content that are essentially the same, thus saving display resources.

[0032] In a further example, the terminal device displays one of the following in the notification bar: a video clip, an animated image, or a static image, along with a text description. Specifically, the terminal device determines its push notification capability based on one or more of the following: battery level, power consumption, network connectivity, display capabilities, and operating system. If the push notification capability supports playing video clips, then the video clip and text description are displayed in the notification bar. If the push notification capability does not support playing video clips but supports playing animated images, then the animated image and text description are displayed in the notification bar. If the push notification capability only supports displaying static images, then the static image and text description are displayed in the notification bar.

[0033] Based on the above examples, terminal devices can push the best-looking video clips, dynamic images, and static images according to their own push capabilities, thereby improving the user's visual experience of watching live push messages as much as possible without exceeding their own push capabilities.

[0034] In one possible design, the terminal device displays the image content in the notification bar. Specifically, if the terminal device's display capability supports online display, the image content is displayed in real time in the notification bar; if the terminal device's display capability does not support online display, the image content is downloaded to the local device and then displayed in the notification bar.

[0035] Based on the above design, the terminal device will play image content online when it has online display capability, and download it to the local device before displaying it when it does not have online display capability. In this way, it can play image content for users while minimizing the occupation of the terminal device's storage resources.

[0036] In one example of the above design, after the terminal device displays the image content in the notification bar, if the image content is clicked, or if it is not clicked after a second set period of time, the image content stored locally is deleted.

[0037] Based on the above design, local image content can be cleared in a timely manner, freeing up storage space as soon as possible.

[0038] In one example of the above design, after the terminal device displays the image content and text description together in the notification bar, it displays the text description and collapses the image content in response to the user pulling down the notification bar again.

[0039] Based on the above example, when the user pulls down the notification bar again, only the text content can be displayed instead of the image content, so that the user's focus is more on the text content and the image content from the previous pull-down of the notification bar does not interfere with the user.

[0040] In a further example, the terminal device responds to the user's click of the collapse button by displaying image content to the user, or by sending a live stream request message to the server again.

[0041] Based on the above examples, when a user pulls down the collapsed icon of the image content, the real-time image content obtained when the notification bar was pulled down last time can be displayed directly, or the real-time image content at the current moment can be re-obtained to meet the different needs of different users.

[0042] Secondly, this application provides an information push method, which is applied to a server or a module in a server (e.g., a circuit, chip, or chip system), or a logical node, logical module, or software capable of implementing all or part of the server's functions. The method includes the following steps: the server receives a live streaming request message from a terminal device and sends a live streaming response message to the terminal device. The live streaming request message is sent to the server by the terminal device in response to a user pulling down the terminal device's notification bar. The live streaming response message includes first live streaming information, which includes first live streaming content from a first broadcaster related to the user.

[0043] In one possible design, before the server receives the live streaming request message from the terminal device, it can also send a first live streaming push message to the terminal device. The first live streaming push message includes a setting flag, which is a flag that instructs the terminal device to send a live streaming request message to the server when the user pulls down the notification bar.

[0044] In one example of the above design, the first live stream push message also includes second live stream information, which is a preset live stream information generated by the server.

[0045] In one possible design, the server can also send a second live stream push message to the terminal device. The second live stream push message includes second live stream information, which is preset live stream information generated by the server.

[0046] In one example of the above design, the server sends a first live push message or a second live push message to the terminal device. Specifically, the server sends the first live push message or the second live push message to the terminal device through a long push connection between the server and the terminal device.

[0047] In one possible design, before receiving a live streaming request message from a terminal device, if the server determines that the first application (APP) has enabled the real-time live streaming push function, it sends a notification message to the terminal device, which includes the identifier of the first APP. Correspondingly, the server sends a live streaming response message to the terminal device. Specifically, the server determines the first broadcaster related to the user among the various broadcasters broadcasting on the first APP, and sends a live streaming response message to the terminal device based on the live streaming content of the first broadcaster.

[0048] In one example of the above design, the first anchor meets one or more of the following conditions: an anchor followed by the user, an anchor with the longest user browsing time, an anchor with the most user views, an anchor the user has interacted with, an anchor of the same type as the anchor followed by the user, and an anchor primarily promoted by the app. Alternatively, other conditions may also be met, such as anchors from fields the user has never followed before; there are no restrictions.

[0049] Based on the above design, live content from streamers that are highly relevant to users or promoted by the live streaming platform can be returned to the terminal device. This live content is from streamers that users are most likely to be interested in, and is most likely to drive users into the live stream room, thus increasing the success rate of push notifications.

[0050] In one example of the above design, the notification message also includes a first address, which is the storage address of the image content in the live broadcast content of each anchor on the first APP; the server sends a live response message to the terminal device, specifically: the server stores the image content in the live broadcast content of the first anchor in the first location of the first address, and generates a live response message based on the text description content in the live broadcast content of the first anchor and the location identifier of the first location, and sends the live response message to the terminal device.

[0051] In one possible design, the server sends a live response message to the terminal device. Specifically, the server stores the image content from the first broadcaster's live stream at a second address, generates a live response message based on the text description content from the first broadcaster's live stream and the second address, and sends the live response message to the terminal device.

[0052] In one example of the above design, the live stream response message also includes the main visual image of the first broadcaster's live stream content.

[0053] In one example of the design above, the image content includes one or more of the following: video clips, animated images, and still images.

[0054] Thirdly, this application provides an information push device that has the function of implementing the method of the first aspect or any of the designs in the first aspect. For example, the information push device includes modules, units or means for performing the operations involved in the method of the first aspect or any of the designs in the first aspect. These modules, units or means can be implemented by software, by hardware, or by a combination of software and hardware.

[0055] Fourthly, this application provides an information push device, which includes an interface circuit and one or more processors. The one or more processors are coupled to a memory. The memory stores part or all of the necessary computer programs or instructions for implementing the functions involved in the methods of implementing the first aspect or any of the designs in the first aspect. The one or more processors can execute the computer programs or instructions, and when the computer programs or instructions are executed, the information push device implements the methods of the first aspect or any of the designs or examples in the first aspect. The interface circuit is used to implement communication functions within the information push device and / or communication functions between the information push device and other devices or components.

[0056] The information push device in the third or fourth aspect mentioned above can be a terminal device, a module in the terminal device (such as a circuit, chip or chip system), or a logic node, logic module or software that can realize all or part of the functions of the terminal device.

[0057] Fifthly, this application provides an information push device that has the function of implementing the method of the second aspect or any of the designs in the second aspect. For example, the information push device includes modules, units or means for performing the operations involved in the method of the second aspect or any of the designs in the second aspect. The modules, units or means can be implemented by software, or by hardware, or by a combination of software and hardware.

[0058] Sixthly, this application provides an information push device, which includes an interface circuit and one or more processors. The one or more processors are coupled to a memory. The memory stores part or all of the necessary computer programs or instructions for implementing the functions involved in the methods of the second aspect or any of the designs in the second aspect. The one or more processors can execute the computer programs or instructions, and when the computer programs or instructions are executed, cause the information push device to implement the methods of the second aspect or any of the designs or examples in the second aspect. The interface circuit is used to implement communication functions within the information push device and / or communication functions between the information push device and other devices or components.

[0059] The information push device in the fifth or sixth aspect mentioned above can be a server, a module in the server (e.g., a circuit, a chip, or a chip system), or a logical node, logical module, or software that can realize all or part of the server's functions.

[0060] In a seventh aspect, this application provides an information push system, comprising: a terminal device and a server, wherein the terminal device is used to execute the method in the first aspect or any possible design in the first aspect; and the server is used to execute the method in the second aspect or any possible design in the second aspect.

[0061] Eighthly, this application provides a computer-readable storage medium storing computer-readable instructions that, when read and executed by a computer, cause the computer to perform a method as described in the first aspect or any of the designs or examples in the first aspect, or to perform a method as described in the second aspect or any of the designs or examples in the second aspect.

[0062] Ninthly, this application provides a computer program product that, when read and executed by a computer, causes the computer to perform a method as described in the first aspect or any of the designs or examples in the first aspect, or to perform a method as described in the second aspect or any of the designs or examples in the second aspect.

[0063] In a tenth aspect, this application provides a chip for reading a computer program stored in a memory and executing the method described in the first aspect or any of the designs or examples in the first aspect, or executing the method described in the second aspect or any of the designs or examples in the second aspect. Optionally, the chip may include a processor coupled to the memory for reading the computer program stored in the memory and implementing the method described in the first aspect or any of the designs or examples in the first aspect, or implementing the method described in the second aspect or any of the designs or examples in the second aspect. Optionally, the chip may also include components such as a memory, a communication interface, and a power supply module. The memory is used to store the computer program; the communication interface is used to receive and send data; and the power supply module is used to supply power to the processor.

[0064] Eleventhly, this application provides a chip system including a processor for supporting a computer in implementing the methods described in the first aspect or any of the designs or examples in the first aspect, or in implementing the methods described in the second aspect or any of the designs or examples in the second aspect. In one possible design, the chip system further includes a memory for storing programs and data necessary for the computer. The chip system may be composed of chips or may include chips and other discrete devices.

[0065] The technical effects that can be achieved in the second to eleventh aspects mentioned above can be referred to the description of the beneficial effects in the first aspect mentioned above, and will not be repeated here. Attached Figure Description

[0066] Figure 1 illustrates an exemplary architecture diagram of an information push system applicable to this application;

[0067] Figure 2 illustrates an interactive flow diagram of an information push method provided in this application;

[0068] Figure 3 is an exemplary schematic diagram of a terminal interface when a user pulls down the notification bar according to this application;

[0069] Figure 4a illustrates an exemplary schematic diagram of a notification bar display interface provided in this application;

[0070] Figure 4b illustrates an exemplary schematic diagram of another notification bar display interface provided in this application;

[0071] Figure 4c illustrates a schematic diagram of another notification bar display interface provided in this application;

[0072] Figure 4d exemplarily illustrates a display interface diagram of another notification bar provided in this application;

[0073] Figure 5a is an exemplary schematic diagram of the display interface when a user pulls down the notification bar again, as provided in this application.

[0074] Figure 5b is an exemplary schematic diagram of the display interface after a user clicks the collapse icon according to this application;

[0075] Figure 5c exemplarily illustrates another display interface provided in this application after a user clicks the collapse icon;

[0076] Figure 6 illustrates an interactive flow diagram of another information push method provided in this application;

[0077] Figure 7 illustrates an exemplary architectural diagram of another information push system provided in this application;

[0078] Figure 8 illustrates an interactive flow diagram of another information push method provided in this application;

[0079] Figure 9 illustrates a schematic diagram of the software architecture of an information push system provided in this application;

[0080] Figure 10a illustrates an example of the interaction between a vendor server and a terminal device provided in this application.

[0081] Figure 10b illustrates an example of the interaction between a developer server and a vendor server provided in this application.

[0082] Figure 10c illustrates an exemplary diagram of the interaction between another vendor's server and a terminal device provided in this application;

[0083] Figure 10d illustrates an example of the interaction between a terminal device and a manufacturer's server provided in this application.

[0084] Figure 10e illustrates an example of the interaction between a developer server and other servers provided in this application;

[0085] Figure 10f illustrates an example of the interaction between various servers and terminal devices provided in this application;

[0086] Figure 10g exemplarily illustrates the interaction diagram between various modules in a terminal device provided in this application;

[0087] Figure 11a illustrates an example of an interface diagram for displaying preset live messages on a notification bar, as provided in this application.

[0088] Figure 11b is an exemplary schematic diagram of an interface for displaying video slices on a notification bar provided in this application;

[0089] Figure 11c exemplarily illustrates a schematic diagram of an interface for displaying GIF animations on a notification bar, as provided in this application;

[0090] Figure 11d exemplarily illustrates a schematic diagram of an interface for displaying static images on a notification bar, as provided in this application;

[0091] Figure 12 illustrates a schematic diagram of the structure of an information push device provided in this application;

[0092] Figure 13 illustrates a schematic diagram of another information push device provided in this application;

[0093] Figure 14 illustrates a schematic diagram of another information push device provided in this application. Detailed Implementation

[0094] The information push scheme provided in this application will now be described in detail with reference to the accompanying drawings and embodiments.

[0095] Please refer to Figure 1, which exemplarily illustrates the architecture of an information push system to which this application applies. The system includes a server and at least one terminal device; the figure shows an example with two terminal devices. Communication between the server and each terminal device, or between different terminal devices, can be achieved through mobile communication networks (e.g., 5G or future communication networks), wireless local area networks (WLANs), or short-range communication technologies. Here, short-range communication technology refers to technologies that transmit information via radio waves over a short distance (e.g., within 100 meters), including but not limited to: Bluetooth, Wi-Fi, Near Field Communication (NFC), Wi-Fi Aware, general short-range communication technologies, and short-range communication technologies specified by the Starlight Alliance.

[0096] The server mentioned above can be a single server or a server cluster composed of multiple servers. For example, it can be a server cluster deployed with multiple servers using a distributed architecture, where the servers in the cluster coordinate with each other to jointly complete functions such as computing, data storage, communication, and live streaming. For ease of description, this application collectively refers to a single server, a distributed server, and a server cluster as a server. The server can be a physical device or a virtual machine or container deployed in the cloud. The server can respond to live streaming request messages sent by terminal devices and can also provide live streaming viewing services to terminal devices.

[0097] The terminal devices described above are devices that can provide users with various services such as voice, video, photography, and data connectivity by installing application software. Terminal devices can also be called user equipment (UE), mobile station (MS), mobile terminal (MT), etc. Examples of terminal devices include, but are not limited to: mobile phones, portable Android devices (PADs), laptops, PDAs, smart TVs, printers, smart cars in the Internet of Vehicles (IoV), on-board units (OBUs), roadside units (RSUs), roadside equipment (RSEs), set-top boxes, mobile internet devices (MIDs), point-of-sale (POS) terminals, wearable devices, virtual reality (VR) devices, augmented reality (AR) devices, smart terminals in industrial control, smart terminals in self-driving, smart terminals in remote medical surgery, smart terminals in smart grids, smart terminals in transportation safety, smart terminals in smart cities, smart terminals in smart homes, and various smart meters (smart water meters, smart electricity meters, smart gas meters), etc.

[0098] It should be noted that the form and quantity of the servers and terminal devices shown in Figure 1 above are for illustrative purposes only and do not constitute a limitation on this application. Furthermore, the servers and terminal devices described above can be hardware, software categorized by function, or a combination of both; this application does not impose specific limitations in this regard.

[0099] As described in the background technology description, existing live streaming push methods suffer from inaccurate live streaming information delivery. This is mainly because the live streaming information pushed by current terminal devices is pre-set by the server, meaning the terminal devices can only push pre-set live streaming information to users and cannot obtain the content currently being streamed in the live room in real time. The pre-set live streaming information may not be the content that users are actually interested in, easily misleading users into entering the live room and then leaving, thus degrading the user's live streaming experience.

[0100] Furthermore, even if a user enters a live stream and finds the content interesting, the long broadcast time makes it difficult for them to stay in the room for an extended period. There might be a segment of content they dislike before returning to something more interesting. In this scenario, existing devices can only push pre-set live stream information and cannot obtain real-time updates on the content being broadcast. Therefore, users cannot know the current progress of the live stream unless they are watching it. This leads to either wasting time and data by staying in the live stream, frequently checking the progress, or even seeing a notification and then re-entering the stream only to find it has already ended, resulting in a poor viewing experience.

[0101] In view of this, this application provides an information push method. When a user performs a certain set operation on a terminal device, the terminal device can request the content currently being streamed in a live room from the server and push it to the user. The user can quickly preview the push information to determine whether the current live content is of interest to them. If so, they can click to enter the live room to watch. Based on this, users do not need to stay in the live room for a long time or frequently enter the live room to obtain a real-time preview of the live content, which can avoid the probability of users accidentally entering the live room.

[0102] It's important to clarify that when a user performs a certain setting action on their terminal device, it can be understood as the user making an action to view live stream notifications. For example, for a specific model of terminal device, if the user is required to pull down the notification bar to view live stream notifications, then when the terminal device detects the user pulling down the notification bar, it can assume that the user has made an action to view live stream notifications. Therefore, the terminal device requests the real-time live stream content from the server and displays the requested live stream content in the notification bar.

[0103] To facilitate understanding of the solution, the following explanation uses the setting operation as an example of pulling down the notification bar to illustrate the specific information push method. However, it should be understood that different terminal devices may have different forms of viewing operations. Therefore, the setting operation may also be other operations, such as clicking a setting icon, issuing a voice command, or making a setting gesture, etc. Any solution that can push real-time live content to users based on their behavior is within the scope of protection of this application.

[0104] Based on the above, Figure 2 exemplarily illustrates an interactive flow diagram of an information push method provided in this application. This method can be executed by a terminal device and a server, such as the terminal device and server in Figure 1 above. As shown in Figure 2, the method includes the following steps:

[0105] Step 201: In response to the user's action of pulling down the notification bar of the terminal device, the terminal device sends a live broadcast request message to the server.

[0106] Correspondingly, the server receives live streaming request messages from the terminal devices.

[0107] For example, as shown in Figure 3, when a user taps the top area of ​​the terminal device's screen with their finger and swipes down, the terminal device detects the user's action of pulling down the terminal device's notification bar and sends a live broadcast request message to the server.

[0108] Optionally, the live stream push notification is not displayed in the notification bar before the user pulls it down. In other words, the user doesn't pull down the notification bar based on a displayed live stream push notification, but rather habitually pulls it down at a certain time to check for live stream push notifications. The terminal device detects this pull-down action and sends a live stream request message to the server.

[0109] Step 202: The server sends a live response message to the terminal device. The live response message includes first live information, which includes the first live content of the first broadcaster related to the user.

[0110] Correspondingly, the terminal device receives a live broadcast response message from the server.

[0111] Optionally, the live streaming request message sent by the terminal device carries the terminal device's identifier (ID). The server queries the correspondence between the device ID and the user ID based on the terminal device's ID to determine the user ID of the user using the terminal device. Then, based on the user ID, it queries the first broadcaster related to the user among the currently live streaming broadcasters.

[0112] For example, the server can query all currently live-streaming broadcasters according to a set priority order, and designate the first live-streaming broadcaster found as the first broadcaster associated with the user. The set priority order can be determined by the server itself, and may include, but is not limited to, the following priorities and order: Priority Level 1: Broadcasters followed by the user; Priority Level 2: Broadcasters with the longest viewing time; Priority Level 3: Broadcasters with the most views; Priority Level 4: Broadcasters the user has interacted with, such as those who have purchased goods, given tips, or paid for services; Priority Level 5: Broadcasters of the same type as those followed by the user; Priority Level 6: Broadcasters promoted by the live-streaming platform, such as the broadcaster with the highest traffic, the broadcaster's own brand, the highest-earning broadcaster, or the broadcaster with the most followers; ...

[0113] Based on the priority order given above, the server can first check if the broadcaster followed by the user is currently live, according to Level 1. If so, this broadcaster is designated as the first broadcaster relevant to the user, and the query stops. If not, it then checks if the broadcaster with the longest viewing time is currently live, according to Level 2. If so, this broadcaster is designated as the first broadcaster relevant to the user, and the query stops. If not, it then checks if the broadcaster most frequently viewed by the user is currently live, according to Level 3, and so on, until a broadcaster is found that is currently live, which is then designated as the first broadcaster relevant to the user. This method only requires checking one broadcaster that is currently live, saving query workload and improving query efficiency.

[0114] Alternatively, other query methods can be used. For example, another query method could disregard priority order and instead retrieve all broadcasters associated with the user ID, then randomly or according to some rule select one as the first broadcaster associated with that user. Or, there might be other query methods, which are not specifically limited here.

[0115] Optionally, after retrieving the first streamer associated with the user, the server can generate text descriptions and images of the streamer's current live stream based on the streamer's current content. Optionally, a main visual image can also be generated. The image content can include one or more of video clips, animated images, and static images. Animated images can be, for example, Graphics Interchange Format (GIF) images. Video clips, animated images, and static images all have a certain amount of data. Text descriptions, on the other hand, have a smaller data size. While the main visual image is also an image, its size is very small (approximately 800×800 pixels, mainly used as an avatar in live stream notifications to improve readability), and its data size is relatively small, allowing it to be processed in the same way as the text descriptions.

[0116] For example, taking the generation of text descriptions, main visual images, and image content for the first broadcaster as an example, in one instance, the server can encapsulate all the content of the generated first broadcaster in the first live broadcast information and return it to the terminal device through a live broadcast response message. That is, the first live broadcast content in the first live broadcast information includes not only text descriptions and main visual images, but also image content, such as video clips, animated images, and still images. In this case, the terminal device can directly obtain the text descriptions, main visual images, and image content by parsing the first live broadcast information in the live broadcast response message. The terminal device can then display one or more of these elements based on the actual situation on the device side, making the operation relatively simple.

[0117] Alternatively, in another example, considering the large data volume of image content, directly returning it to the terminal device might cause significant communication overhead and push latency. Therefore, the server could encapsulate only the text description and main visual image as the first live stream content within the first live stream information, while storing the image content at a specific address. Then, the server returns the information from that address along with the first live stream information to the terminal device via a live stream response message. In this case, the first live stream information only includes the text description and main visual image, while the live stream response message includes the storage address of the image content, which we'll call the second address. The terminal device parses the live stream response message and obtains the text description, the main visual image, and the second address.

[0118] Optionally, the server can also set a time limit for the image information stored in the second address. After the storage time limit is exceeded, the image information in the second address will be automatically deleted, and the storage space corresponding to the second address will be released. In some scenarios, considering that the image information in the second address will be pushed to different terminal devices at different time points, the time limit here can be set to a longer period, such as 15 days. This can avoid the server repeatedly generating video slices, dynamic images, and static images, reducing the complexity of pushing real-time live information.

[0119] Step 203: The terminal device displays the first live broadcast information in the notification bar.

[0120] Optionally, after receiving the live broadcast response message, the terminal device parses the message to obtain the first live broadcast information, and may also obtain a second address. If only the first live broadcast information is obtained, and this information includes text descriptions, a main visual image, and image content, the terminal device can directly display one or more of these elements based on the actual situation on the device side. If the second address is obtained along with the first live broadcast information, the terminal device first needs to retrieve the image content from the second address, and then display the image content, along with one or more of the text descriptions and main visual images from the first live broadcast information, based on the actual situation on the device side.

[0121] The actual situation on the device side can be determined based on one or more of the following: battery level, power consumption, network connectivity, display capabilities, and operating system. For example, the push notification capability of the terminal device can be determined based on one or more of these factors. If the push notification capability is insufficient, only the text description and main visual image will be displayed in the notification bar. If the push notification capability is sufficient, the text description, main visual image, and image content will all be displayed in the notification bar.

[0122] Optionally, when push capabilities are sufficient, if the image content includes at least two of the following: video clips, animated images, and static images, the terminal device can display one of these—video clips, animated images, and static images—along with the text description and the main visual image in the notification bar to avoid duplicate display. For example, if the push capability supports playing video clips, the video clips are displayed in the notification bar along with the text description and the main visual image; if the push capability does not support playing video clips but supports playing animated images, the animated images are displayed in the notification bar along with the text description and the main visual image; and if the push capability only supports displaying static images, the static images are displayed in the notification bar along with the text description and the main visual image.

[0123] Optionally, when displaying image content, the image content can be played online or locally depending on the display capabilities of the terminal device. For example, if the terminal device's display supports online display, the image content is played in real time on the notification bar; if the terminal device's display does not support online display, the image content is downloaded locally and then played on the notification bar. In this way, the method of pushing image content can be matched to the actual display capabilities of the terminal device.

[0124] To make it easier to understand, here's a specific example illustrating how the notification bar is displayed on a terminal device:

[0125] Assuming the terminal device parses the first live stream information and obtains the text description, main visual image, and second address, and the second address stores three parts: video clips, animated images, and static images, then the terminal device can obtain the current remaining battery power, its network status, determine the playback formats supported by the user interface system, and determine whether its display capabilities support online or offline display. Based on this information:

[0126] Scenario 1: If the remaining battery power is less than the minimum battery power threshold, such as less than 20%, or the network status is poor, such as the current network is 2G or 3G, or although it is 4G or 5G network but the network speed is lower than the minimum network speed threshold, it means that the current push capability is insufficient. The terminal device will only display the text description content and the main visual image in the notification bar. Optionally, the icon of the current live streaming platform can also be displayed, as shown in Figure 4a.

[0127] Conversely, if the remaining battery power is greater than or equal to the minimum battery power threshold, or if the network condition is good, it indicates that the current push notification capability is sufficient. Based on this:

[0128] In scenario two, the terminal device determines whether it supports playing video slice format files and whether the power consumption of playing video slices does not exceed the maximum power consumption threshold. If both are true, and its display capabilities support online display, the video slice from the second address is displayed in real-time in the notification bar, along with the text description and main visual image. If both are true, but its display capabilities do not support online display and only support offline display, the video slice file from the second address is first downloaded to the local device, and then the locally stored video slice file is displayed in real-time in the notification bar, along with the text description and main visual image. Optionally, the icon of the live streaming platform can also be displayed, as shown in Figure 4b.

[0129] Scenario 3: If at least one of the two conditions in Scenario 2 is negative, or both are positive, but online playback of the video slice fails, or downloading the video slice fails or times out (e.g., exceeding 10ms), or offline playback of the locally stored video slice fails, then the terminal device can further determine whether it supports playing dynamic image formats (e.g., GIF format) and whether the power consumption for playing dynamic images does not exceed the maximum power consumption threshold. If both are positive, and its display capabilities support online display, then the dynamic image from the second address is displayed in real-time in the notification bar, along with the text description and main visual image. If both are positive, but its display capabilities do not support online display and only support offline display, then the dynamic image from the second address is first downloaded to the local device, and then the locally stored dynamic image is displayed in real-time in the notification bar, along with the text description and main visual image. Optionally, the icon of the live streaming platform can also be displayed, as shown in Figure 4c.

[0130] Scenario 4: If at least one of the two conditions in Scenario 3 is negative, or both are positive, but online playback of animated images fails, or downloading animated images fails or times out (e.g., exceeding 10ms), or offline playback of locally stored animated images fails, then the terminal device can further determine whether it supports playing static image files and whether the power consumption for playing static images does not exceed the maximum power consumption threshold. If both are positive, and its display capabilities support online display, then the static image from the second address will be displayed in real-time in the notification bar, along with the text description and main visual image. If both are positive, but its display capabilities do not support online display and only support offline display, then the static image from the second address will first be downloaded locally, and then the locally stored static image will be displayed in real-time in the notification bar, along with the text description and main visual image. Optionally, the live streaming platform icon can also be displayed, as shown in Figure 4d.

[0131] Scenario 5: If at least one of the two conditions in Scenario 4 is negative, or both are positive, but online playback of static images fails, or downloading static images fails or times out (e.g., exceeds 10ms), or offline playback of locally stored static images fails, then the terminal device will only display the text description and main visual image in the notification bar. Optionally, the live streaming platform icon can also be displayed, as shown in Figure 4a above.

[0132] Based on the above methods, when the push capabilities of the terminal device are sufficient, the optimal video or image supported by the terminal device can be displayed in the notification bar to maximize the user's visual experience when viewing live stream push messages. Furthermore, even when the push capabilities of the terminal device are insufficient, the text description of the broadcast currently taking place on the server (or including the main visual image) can still be displayed in the notification bar to push real-time live stream content and meet the user's need for quick previewing of live stream content.

[0133] Optionally, the terminal device can also set a time limit (i.e., a second set duration) for push notifications displayed in the notification bar, such as 3 hours. Within 3 hours, if the push notification is clicked, the terminal device will redirect to the corresponding live stream room and automatically clear the push notification from the notification bar. Optionally, if the push notification includes image content, and the image content is downloaded locally before playback, the terminal device can also clear the locally stored image content, such as locally downloaded video clips, GIF images, and static images. Conversely, if the push notification is not clicked within 3 hours, the push notification is likely no longer real-time compliant. In this case, the terminal device can also clear the push notification from the notification bar, as well as locally downloaded video clips, GIF images, and static images.

[0134] Optionally, the user may pull down the notification bar more than once within 3 hours. Upon the first pull down, the terminal device requests a real-time push notification from the server and displays it in the notification bar. If the user releases the notification bar without clicking the push notification, and then pulls down the notification bar again within 3 hours, the terminal device can display only the text description and main visual image from the previous push notification, while collapsing the image content, as shown in Figure 5a. If the user wants to view the image content again, they can click the collapse button. In this case, the terminal device can display the previously collapsed image content again in the notification bar, as shown in Figure 5b. Alternatively, to ensure the real-time nature of the image content, a live stream request message can be sent to the server again, and the collapsed image content can be updated based on the live stream response message returned by the server, as shown in Figure 5c.

[0135] Based on the above, by retrieving the currently streaming content from the notification bar in real time and pushing it to the user, users can access the most up-to-date and accurate live stream information. If users are interested in the current live stream content, they can enter the live stream to watch and even interact with the stream. This reduces the probability of users accidentally entering the live stream and improves the user experience. Furthermore, since those entering the live stream are users interested in the live content, it also increases the interaction rate and product purchase rate of the live stream.

[0136] The solution described in Figure 2 above can be understood as the message push process for a live streaming app that supports real-time live streaming push functionality. To further illustrate the solution, Figure 6 below explains the message push process for multiple live streaming apps. Any one of these apps may or may not support real-time live streaming push functionality; there are no restrictions.

[0137] Please refer to Figure 6, which shows a flowchart of another information push method provided in this application. The method includes the following steps:

[0138] Step 601: When each live streaming app enables the real-time live streaming push function, the server sends a notification message to the terminal device.

[0139] Correspondingly, the terminal device receives notification messages from the server.

[0140] The notification message includes the identifier of the live streaming app that has enabled the real-time live streaming push function. This notification message is used to inform the terminal device which live streaming app has enabled the real-time live streaming push function, so that the terminal device can push real-time live streaming messages to that live streaming app instead of pushing preset live streaming messages.

[0141] Optionally, the notification message may also include a first address, which is a dedicated address opened by the server for the live streaming app that has enabled the real-time live streaming push function. This address is specifically used to store image content from the live streaming content of various streamers broadcasting on the live streaming app, such as video clips, GIF images, and still images from the live streaming content of various streamers broadcasting on the live streaming app. Optionally, it may also store text descriptions of the streamer's current live stream.

[0142] For example, suppose a server manages push notifications for three live streaming apps: APP1, APP2, and APP3. Initially, none of these apps have enabled real-time live streaming clipping. However, at some point, APP1 decides to enable real-time live streaming push notifications. APP1 can then send an activation request to the server. Based on this request, the server determines that APP1 can push real-time live stream messages to end devices. Therefore, the server allocates storage space specifically for APP1 to store its real-time live stream content. Then, based on the storage space's address and APP1's identifier, the server generates a notification message and sends it to the end device. Specifically, it can send the message to the end device that has APP1 installed. This informs the end device which live streaming app has enabled real-time live streaming and also provides the end device with the storage address of the corresponding real-time live stream content. This allows the device to retrieve the corresponding real-time live stream content from that storage address, which could include video clips, GIFs, still images, or even text descriptions.

[0143] Optionally, when the first address is first created, it is empty as it contains no content. In subsequent applications, the server can automatically slice the live stream content from various broadcasters on the live streaming app, generate relevant image content, and store it in the first address. Alternatively, it can store image content only when a terminal device accesses the app. For example, after receiving a live stream request message from a terminal device, the server can slice the live stream content from the broadcasters on the live streaming app and store the generated image content in the first address. Using the latter method essentially generates and stores content based on the real-time live stream access needs of the terminal device. This satisfies the user's real-time live stream access requirements while avoiding additional workload and storing unnecessary image resources, thus saving storage and processing resources. Therefore, the following section will use the latter method as an example.

[0144] Step 602: The server sends a live streaming push message from the First Live APP to the terminal device.

[0145] Correspondingly, the terminal device receives live stream push messages from the server.

[0146] The live stream push message includes second live stream information, which can be understood as preset live stream information for the first live stream app, or preset live stream information generated by the server specifically for the first live stream app. This preset live stream information may include a preset live stream title and preset introductory text, and optionally, a preset image. For example, taking the first live stream app as APP1, the preset live stream title could be "APP1 Live Stream," the preset introductory text could be "Welcome to my live stream room," and the preset image could be the APP1 icon (such as the "APP1" icon), a mainstream image, or a main visual image.

[0147] Optionally, the sending time of live stream push messages can be determined by the server. For example, the server can collect statistics on the time users have spent watching the FirstLive app in the past to determine their habitual viewing time, and then send live stream push messages to the user's terminal device within the habitual viewing time or a relatively recent period. For instance, by studying historical user habits, if a user habitually opens the FirstLive app at 12 noon, then a live stream push message can be sent to the user's primary terminal device between 11:30 and 12:00. If another user habitually opens the FirstLive app at 8 pm, then a live stream push message can be sent to the user's secondary terminal device between 7:30 and 8:00 pm. Since different users watch the same live stream app at different times, pushing live stream push messages to each user's corresponding terminal device based on their viewing time can avoid live stream push messages occupying the notification bar or the terminal device's cache for a long time, thus saving storage resources.

[0148] Step 603: The terminal device determines whether the live push message includes a set flag. If not, proceed to step 604; if yes, proceed to step 605.

[0149] Optionally, in addition to the second live broadcast information, the live broadcast push message may also include other content, such as setting tags. Setting tags, also known as real-time live broadcast push tags or video slice tags, are used to indicate that a live broadcast push message is a real-time live broadcast push message, or in other words, to indicate that a live broadcast push message is a push message from a live broadcast app that supports real-time live broadcast push functionality.

[0150] Based on this, depending on whether the FirstLive APP supports real-time live streaming push functionality, there are two possible scenarios for live streaming push messages:

[0151] Scenario 1: The First Live APP supports real-time live streaming push function, and the live streaming push message includes the Second Live Stream information and the set tag;

[0152] Scenario 2: The First Live APP does not support real-time live streaming push function. The live streaming push message includes information about the Second Live Stream, but does not include the set tag.

[0153] Based on these two possible scenarios, the terminal device will push live stream messages to the user in different ways. In scenario one, a real-time live stream push method can be used, i.e., steps 605 to 610. In scenario two, the existing live stream push method is used, i.e., step 604. In other words, by including or omitting a set flag in the live stream push message, real-time and non-real-time live stream push messages can be distinguished. This allows the terminal device to accurately determine whether to use the real-time live stream push method or the original non-real-time live stream push method, thus adding real-time live stream push functionality without affecting the terminal device's original non-real-time live stream push functionality.

[0154] Step 604: The terminal device displays the second live broadcast information in the notification bar.

[0155] Optionally, if the terminal device fails to obtain the set flag when parsing the live stream push message, it indicates that the live stream push message is sent by a live stream app that does not support real-time live stream push functionality (referred to as a second live stream push message), and it needs to be pushed to the user according to the original push process. For example, the second live stream information in the live stream push message can be directly displayed in the notification bar. After seeing the second live stream information in the notification bar, the user can click on the second live stream information if interested, and the terminal device will detect the user's action of pulling down the notification bar and clicking on the second live stream information, and then jump to the corresponding live stream room.

[0156] Step 605: The terminal device caches the second live broadcast information locally.

[0157] Optionally, when the terminal device parses the live push message and obtains the set flag, it indicates that the live push message is a message sent by a live streaming APP that supports real-time live push function (referred to as the first live push message). The set flag is used to instruct the terminal device to request real-time live content from the server when the user pulls down the notification bar.

[0158] Optionally, if the set flag is obtained after parsing the live stream push message, the terminal device does not display the second live stream information in the notification bar, but only caches it locally. The purpose of caching is to provide the user with a preset live stream information if the real-time first live stream information cannot be successfully obtained later, thus avoiding long waiting times that could affect the live stream experience.

[0159] Step 606: In response to the user's pull-down notification bar action, the terminal device sends a live streaming request message to the server.

[0160] Correspondingly, the server receives the live streaming request message sent by the terminal device.

[0161] The live streaming request message includes the identifier of the FirstLive APP, and is used to request the live streaming content of the host who is currently streaming on the FirstLive APP.

[0162] Step 607: The server identifies the first streamer related to the user from among the streamers currently broadcasting on the First Live APP, and generates first live information based on the first streamer's live content.

[0163] Optionally, in addition to the identifier of the First Live APP, the live streaming request message may also include the identifier of the terminal device. The server can first query the preset mapping relationship between terminal device identifiers and user identifiers to determine the user identifier corresponding to the terminal device identifier carried in the live streaming request message. Then, based on the user identifier, it obtains the corresponding priority push strategy and searches among the various broadcasters on the First Live APP according to the priority order in the priority push strategy. The broadcaster with the highest priority found is selected as the first broadcaster related to the user.

[0164] Furthermore, the server can perform image processing on the content currently being streamed by the first broadcaster, generating video clips of a certain duration. These video clips can then be further processed to generate a GIF image of a certain duration and a static image. Optionally, the server can also generate text descriptions and a main visual image of the content currently being streamed by the first broadcaster. The text descriptions may include descriptions of the video being streamed and related text about the first broadcaster. The server can use all or part of the generated information as the first live stream information.

[0165] Step 608: The server sends a live broadcast response message to the terminal device, which includes the first live broadcast information.

[0166] In one example, the server can use all the information generated above as the first live stream information and return it to the terminal device in the live stream response message. That is, the first live stream information includes video clips, GIF images, still images, text descriptions, and the main visual image of the first broadcaster's live stream content. The terminal device can then parse the live stream response message to obtain all the content corresponding to the first broadcaster.

[0167] Alternatively, in another example, considering the large data volume of video clips, GIF images, and still images, directly returning them to the terminal device would result in significant network overhead and transmission latency. Therefore, to reduce network overhead and transmission latency, the server could use only the text description and main visual image as the first live broadcast information. Simultaneously, the video clips, GIF images, and still images would be stored in the first address configured for the first live broadcast app in step 601 above. Then, the location identifiers of these information in the first address, along with the first live broadcast information, would be included in the live broadcast response message and returned to the terminal device. Alternatively, the first address, location identifier, and first live broadcast information could be included in the live broadcast response message and returned to the terminal device. In the former case, the location identifier in the live broadcast response message and the first address carried in the notification message are needed to obtain the image content. In the latter case, the live broadcast response message directly carries the first address and location identifier, allowing the terminal device to obtain the image content based on the live broadcast response message. The first address and location identifier are combined to form the second address described in the text description section of Figure 2 above.

[0168] Understandably, since there are many live streamers on the First Live APP, and the live streamers associated with different terminal devices may also be different, there will be a lot of image content corresponding to different live streamers stored in the first address. The aforementioned location identifier is used to indicate the storage location of the image content related to the current terminal device in the first address. This location identifier makes it easier for the terminal device to obtain the image content of the live streamer related to itself, and not to obtain the image content of the live streamer related to other terminal devices, thereby improving the accuracy of live information push.

[0169] As an example, the image content corresponding to different broadcasters can be stored in different folders of the first address. Therefore, the address identifier can specifically be the directory and filename of the folder. By combining this address identifier with the first address, it is possible to determine which folder under which directory of the first address contains the image content corresponding to a broadcaster, and thus obtain the image content corresponding to that broadcaster.

[0170] Optionally, in addition to the initial live broadcast information and the location identifier of the image content, the live broadcast response message may also include other information, such as descriptive information about the image content. This descriptive information may include, but is not limited to, the image content format, the image content duration, and the image content size. Including descriptive information about the image content in the live broadcast response message allows the terminal device to first determine which image content it can support, and then retrieve the required image content from the corresponding location, without having to retrieve all image content. This way, the terminal device can push only one type of image content based on its capabilities, avoiding duplicate pushes and reducing the workload of the terminal device.

[0171] Step 609: Does the terminal device receive a live response message within the first set time period? If yes, proceed to step 610; otherwise, proceed to step 611.

[0172] Optionally, the terminal device maintains a first timer, the duration of which is a first preset duration. After sending the live broadcast request message in step 606 above, the terminal device can start the first timer. If a live broadcast response message is received from the server before the first timer expires, it indicates that the current network condition is good and can support real-time live broadcast push. Therefore, the terminal device can push the real-time live broadcast message to the user, i.e., execute step 610 below. Conversely, if no live broadcast response message is received from the server after the first timer expires, it indicates that the current network condition is poor, or other reasons prevent real-time live broadcast push. In this case, the terminal device can push a preset live broadcast message to the user, i.e., execute step 611 below.

[0173] Here, the first set duration can be set to a duration greater than the information transmission time but less than the user's visual perception time difference. For example, under normal circumstances, a live broadcast response message will return in 10ms, but to accommodate some abnormal situations, the first set duration can be configured to be slightly longer, such as 100ms. If the user sees the push message within 100ms after pulling down the notification bar, it is still equivalent to seeing the push message in real time for the user, resulting in a better live broadcast push experience.

[0174] Step 610: The terminal device displays the first live broadcast information in the notification bar.

[0175] Here, if a live response message is received from the server within a first set time period, the terminal device can parse the live response message to obtain its content. There are several possible parsing results, such as: Parsing result one: obtaining first live information, which includes all content related to the user's first broadcaster, including live video clips, GIF images, still images, text descriptions, and main visual images; Parsing result two: obtaining the first live information and a location identifier, where the location identifier indicates the storage location of the image content corresponding to the user's first broadcaster in a first address, which is notified to the terminal device in the notification message of step 601 above; Parsing result three: obtaining the first live information, a first address, and a location identifier, where the first address and location identifier are combined as a second address, used to indicate the storage location of the image content corresponding to the user's first broadcaster.

[0176] Optionally, the parsing results may also include descriptive information about the image content, such as the type, duration, and size of video clips, the type, duration, and size of GIF images, and the type and size of static images. The terminal device can also use this descriptive information, combined with its own edge capabilities, to determine the image content with the best display effect that it can support, and then display the first live broadcast information and the image content together in the notification bar.

[0177] For example, if the parsing result is as described above, and the terminal device's edge capabilities support playing video clips of the specified format, duration, and size, then the terminal device can display the parsed first live stream information and the video clip together in the notification bar. In other words, the notification bar will simultaneously display the video clip, text description, and main visual image of the first streamer currently broadcasting, all relevant to the user.

[0178] If the parsing result is two, and the terminal device's edge capabilities do not support playing video slice format, duration, and size files, but support playing GIF image format, duration, and size files, then the terminal device can retrieve the GIF image from the first address corresponding to the First Live APP based on the location identifier of the GIF image carried in the live response message. Then, it will display the GIF image and First Live information together in the notification bar. In other words, the notification bar will simultaneously display the GIF image, text description, and main visual image of the First Live streamer currently broadcasting, all relevant to the user.

[0179] If the parsing result is three, and the terminal device's edge capabilities do not support playing video clips and GIF image files in terms of format, duration, and size, but do support playing static image files in terms of format and size, then the terminal device can obtain the static image based on the location identifier and first address corresponding to the static image carried in the live broadcast response message. Then, it will display the static image and the first live broadcast information together in the notification bar. In other words, the notification bar will simultaneously display the static image, text description, and main visual image of the first broadcaster currently livestreaming, all relevant to the user.

[0180] Assuming the first live stream information and image content to be displayed is called the first push notification, in one example, before displaying the first push notification, the terminal device can first determine whether there are other push notifications waiting to be displayed. If there are no other push notifications, the first push notification can be directly displayed in the notification bar. If there are other push notifications, the first push notification is stored in a designated queue. This designated queue is set up for each live streaming app that has enabled real-time live stream push functionality, specifically to store the push notifications for these apps. The push notifications in the designated queue are displayed sequentially according to the time they were entered, or each push notification can have its own push time, and each push notification is displayed according to its own push time.

[0181] Optionally, after storing the first message to be pushed to the set queue, in order to avoid duplicate pushes, it is also possible to check whether there are other messages to be pushed by the First Live APP in the set queue. If so, the first message to be pushed and other messages to be pushed are deduplicated to ensure that the First Live APP has only one message to be pushed in the set queue after deduplication.

[0182] For example, assuming each message to be pushed has its own push time, the terminal device can check if there are other messages to be pushed by the same live streaming app in the designated queue with the same push time as the first message. If so, it means that these two messages are from the same live streaming app and are intended to be pushed to the user at the same time. This push method will interfere with the user, and one of the messages to be pushed needs to be removed from the designated queue. There are many options for which message to remove, such as randomly removing one, removing the older message and keeping only the newest one, or querying the server to determine which message to remove, etc. Based on this cleanup operation, it can be ensured that there is only one message to be pushed by a live streaming app on a single terminal device at the same time. This ensures that the user only sees one push notification for a live streaming app at a time, improving the user's live streaming push experience.

[0183] Step 611: The terminal device displays the second live broadcast information in the notification bar.

[0184] Here, if no live stream response message is received from the server within the first set time period, the terminal device can display the previously cached second live stream information in the notification bar. In other words, the preset second live stream information is pushed to the user. Based on this, even if the terminal device is unable to push real-time live stream information due to poor network conditions or other reasons, the preset live stream information can still be pushed to the user, avoiding situations where the user waits for a long time without receiving live stream push messages and maintaining a good live stream push experience.

[0185] Based on the message push method shown in Figure 6 above, the real-time live push operation provided in this application can be integrated with the original live push operation, so that the terminal device can support both the original live push operation and the real-time live push. While adding the real-time live push function, it does not affect the logic implementation of the original non-real-time live push operation, and at the same time, it can make the most of the existing system without having to develop a completely new push system, which can reduce the difficulty of development and design.

[0186] The above content describes the information interaction process between the terminal device and the server. The server can be a single server or a server cluster. When it is a server cluster, please refer to Figure 7, which shows a schematic diagram of another push system architecture provided in this application. In this architecture, the server cluster can include a live streaming server, a developer server, a configuration server, a policy server, and a vendor server. The developer server is connected to the live streaming server, configuration server, policy server, and vendor server, respectively. The vendor server is also connected to the terminal device.

[0187] Optionally, the vendor's server and the terminal device can connect via a push persistent connection. On this push persistent connection, the vendor's server and the terminal device can continuously send multiple data packets. If no data packets are sent, both parties need to send link detection packets. Push persistent connections can avoid the communication latency caused by repeatedly establishing connections, and are particularly suitable for frequent, point-to-point communication scenarios.

[0188] In the architecture shown in Figure 7, the servers in the server cluster collaborate to complete the live streaming push function. For example, the live streaming server can receive real-time video and audio streams from the broadcaster, encode them to generate live streaming information, and send it to the developer server. The developer server, also known as the content distribution server, is mainly responsible for deciding which terminal devices to push the live streaming information to. The decision-making process requires first calling the push policy stored in the policy server to query the target user information interested in the live streaming information, and then calling the mapping relationship between user information and terminal devices stored in the configuration server to determine the information of the terminal devices to be pushed to the target user information. Finally, the live streaming information and the information of the terminal devices to be pushed to are sent together to the manufacturer server. The manufacturer server can be understood as the server of the terminal device manufacturer, such as the server of a mobile phone manufacturer or the server of a vehicle manufacturer. As an intermediate node between the terminal device and the developer server, the manufacturer server is mainly responsible for sending the live streaming information sent by the developer server to the corresponding terminal device, so that it can be pushed to the user using the terminal device.

[0189] Since the functions of the live streaming server, developer server, configuration server, and policy server are all related to the live streaming service, these four servers can also be categorized as servers on the live streaming service side, such as a live streaming app server. Vendor servers, on the other hand, are categorized as servers on the terminal manufacturer side. For example, when the terminal device is a mobile phone, the vendor server is also the mobile phone manufacturer's server. The mobile phone needs to establish a connection with the live streaming app server through the vendor server to indirectly send request messages to the live streaming app and indirectly obtain live streaming information sent by the live streaming app server, which is then pushed to the user.

[0190] Based on the system architecture shown in Figure 7, Figure 8 illustrates a flowchart of another information push method provided in this application. This method is applicable to the live streaming server, developer server, vendor server, and terminal device shown in Figure 7, and mainly includes the following steps:

[0191] Step 801: The developer server sends a push message to the vendor server.

[0192] Correspondingly, the vendor's server receives push messages sent by the developer's server.

[0193] Here, the push message refers to the aforementioned live stream push message. The push message carries preset live stream information, also known as the second type of live stream information. This preset live stream information includes preset live stream introduction text and / or image information. The live stream introduction text can include a title and content; the title could be, for example, the name of the live stream platform, the content could be, for example, "Welcome to my live stream room," and the image can be a mainstream image from the live stream platform. For example, if the push message is from the FirstLive app, the preset live stream information could include the name of the FirstLive app, the text "Welcome to my live stream room," and the FirstLive app icon.

[0194] Optionally, the push message can also carry a flag indicating that the user should request a video segment from the live streaming server when pulling down the notification bar. This flag is called the "live stream flag," which is the same as the previously mentioned setting flag. If the live streaming platform supports video slicing, the push message mainly carries the preset live stream information and the "live stream flag." If the live streaming platform does not support video slicing, the push message may only carry the preset live stream information without the "live stream flag." The "live stream flag" is essentially an instruction that tells the terminal device to request a video segment when the user pulls down the notification bar.

[0195] Step 802: The vendor's server sends a push message to the terminal device.

[0196] Optionally, the vendor's server can send push messages to the terminal device via a long-lived push connection. This push message primarily carries the following: a pre-set live stream introduction text and / or image information; or, a pre-set live stream introduction text and / or image information, and a "live stream tag". If the push message does not carry a "live stream tag", the process proceeds to step 803a. If the push message carries a "live stream tag", the process proceeds to steps 803b through 815.

[0197] Step 803a: The terminal device displays the push message.

[0198] Here, when the push message does not carry a "live broadcast tag", it means that there is no need to push real-time live broadcast content. Therefore, the terminal device follows the original push logic, that is, it displays the preset live broadcast information in the push message on the notification bar, and the user can directly enter the live broadcast room after clicking.

[0199] Step 803b: The terminal device caches the push message.

[0200] Here, when the push message carries a "live broadcast tag", it means that real-time live broadcast content needs to be pushed. The mobile terminal can cache the above push message, but only cache it and do not display it. The real-time live broadcast content will be displayed when the user pulls down the notification bar. See steps 804 to 815.

[0201] Step 804: The user pulls down the notification bar on their terminal device to read the push notification.

[0202] Step 805: The terminal device requests a video slice from the manufacturer's server.

[0203] Here, after detecting the user's pull-down notification bar action, the terminal device requests a video slice from the manufacturer's server. For example, it sends a live streaming request message to the manufacturer's server carrying the terminal device's ID. This live streaming request message requests an X-second live video slice. The value of X can be set by those skilled in the art; for example, it could be 10 seconds or other durations.

[0204] Optionally, the terminal device can also be configured with a set request time, which is the first set duration mentioned earlier. This first set duration can be, for example, Y1 milliseconds. The value of Y1 can be set to a larger value. For example, if it can return in 10 milliseconds under normal network conditions, then to accommodate network issues, it can be configured to 100 milliseconds or a larger value. 100 milliseconds is also very small relative to the user's visual time difference and will not affect the user's experience of reading push messages.

[0205] Step 806: The vendor server requests video slices from the developer server.

[0206] Here, the vendor's server forwards a live stream request message to the developer's server, requesting a live video slice of X seconds.

[0207] Optionally, the vendor server can also be configured with a set request time, which can be, for example, Y2 milliseconds. The value of Y2 can be the same as or less than Y1. For example, if Y1 is 100 milliseconds, Y2 can be 100 milliseconds, 95 milliseconds, 90 milliseconds, 89 milliseconds, 85 milliseconds, etc., without limitation.

[0208] Step 807: The developer server matches the user's relevant streamer information and modifies the preset live streaming information to the matched streamer information.

[0209] Optionally, the developer server can access the mapping relationship between terminal device IDs and user IDs stored in the configuration server based on the terminal device ID, query the corresponding user ID, and then access the priority push policy corresponding to that user stored in the policy server based on the user ID. According to the priority push policy, it can match the information of broadcasters on the live streaming platform that are relevant to the user and currently live. For example, it can match information based on the user's following status, number of views, and the live streaming platform's main recommendations, and take the first live streamer information found as the broadcaster information relevant to the user.

[0210] Furthermore, the developer server uses the matched streamer information to modify the preset live stream information. For example, the preset live stream text can be changed to streamer-related text, and the preset live stream image can be changed to a streamer-related image, such as the streamer's main visual image. For instance, assuming the preset live stream information includes the name of the FirstLive app, the text "Welcome to my live stream room," and the FirstLive app icon, if the matched streamer is Streamer 1, then the text "Welcome to my live stream room" can be changed to "Welcome to Streamer 1's live stream room," and the FirstLive app icon can be changed to an image of Streamer 1. The name of the FirstLive app can remain unchanged. The modified live stream information is the same as the previously mentioned FirstLive information.

[0211] Step 808: The developer server requests a video slice from the live streaming server.

[0212] Here, the developer server can send the matched streamer information to the live streaming server to request the corresponding streamer's X-second live video slice.

[0213] Optionally, the developer server can also be configured with a set request time, which can be, for example, Y3 milliseconds. The value of Y3 can be the same as or less than Y2. For example, if Y2 is 100 milliseconds, Y3 can be 100 milliseconds, 99 milliseconds, 97 milliseconds, 93 milliseconds, 85 milliseconds, etc., without limitation.

[0214] Step 809: The live streaming server returns the video slice and slice description to the developer server.

[0215] Here, the live streaming server can extract an X-second segment of real-time live video from the corresponding live stream room on the live streaming platform based on the streamer information sent by the developer's server, and can generate a description of this real-time live video segment. The description can include, for example, promotional text for the product currently being introduced in the live stream, or other relevant content, without limitation.

[0216] Step 810: The developer server returns the modified live stream information, video slices, and slice descriptions to the vendor server.

[0217] In other words, the developer's server can return an X-second live video clip, the clip description, and text and / or images related to the streamer to the vendor's server.

[0218] Step 811: The vendor's server generates the corresponding GIF image based on the video slices.

[0219] For example, a vendor's server can extract images from a video slice of X seconds at a set frame rate to obtain a GIF image.

[0220] Step 812: The vendor's server returns the modified live broadcast information, video slices, GIF format images, and slice descriptions to the terminal device.

[0221] For example, the vendor's server can send a live response message to the terminal device. The live response message includes one or more of the following: an X-second live video clip, a clip description, a GIF image, and text and / or images related to the streamer.

[0222] Optionally, the vendor server can present all information together as the first live stream information and return it to the terminal device via a live stream response message. Alternatively, it can present only the segment descriptions and broadcaster-related text and / or images as the first live stream information, store the X-second live stream video segment and GIF image at a designated address, and then return the first live stream information and the information at the designated address to the terminal device via a live stream response message. In the former case, the terminal device can obtain all content by directly parsing the live stream response message returned by the vendor server. However, in the latter case, the terminal device also needs to obtain the X-second live stream video segment and GIF image based on the information at the designated address. For details, please refer to the aforementioned description; it will not be repeated here.

[0223] Step 813: The terminal device displays the push message.

[0224] Optionally, before the timeout configured in step 805 above, if a live stream response message is returned and the terminal device supports video playback, the video slice is displayed in the notification bar; if a live stream response message is returned but the terminal device does not support video playback, a GIF image is displayed in the notification bar. Furthermore, if the returned live stream response message contains descriptive content, such as slice descriptions and text and / or images related to the broadcaster, the slice descriptions and broadcaster-related text and / or images can also be displayed in the notification bar.

[0225] Optionally, if the live response message fails to return before the set request timeout configured in step 805 above, that is, if the live response message is not received before the set request timeout, the terminal device can display the preset live information. That is, the preset live information in the push message cached in step 803b is displayed in the notification bar. The preset live information includes the preset live text and preset live image.

[0226] Step 814: The user clicks on the push notification.

[0227] Step 815: The terminal device launches the APP and redirects to the landing page of the designated live stream room.

[0228] Here, when the terminal device detects that the user clicks on the real-time push message displayed in the notification bar, it jumps to the corresponding live room on the live streaming platform and plays the live content to the user.

[0229] Using the push notification scheme shown in Figure 8, the terminal device can retrieve live video clips, GIF images, live clip descriptions, and relevant text and / or images from the live stream based on the user's action of pulling down the notification bar, and return them to the user. This way, users can see real-time live messages when viewing notifications, instead of pre-set ones. Furthermore, the live messages users see include not only images and text, but also video clips and GIFs, resulting in a better live stream push experience.

[0230] From a software architecture perspective, the system architecture shown in Figure 7 corresponds to the software architecture shown in Figure 9.

[0231] As shown in Figure 9, in the software architecture, the live streaming server can be equipped with an ⑧X-second video slice generation module; the developer server has a ⑦ developer slice request interface and a ① push request interface; the vendor server has a ⑥ vendor slice request interface, a ⑨ push configuration platform, and a push interface management module; and the terminal device has a preprocessing module, a push message processing module, a ④ notification management module, and a user interface system. The preprocessing module includes a common capability module, primarily responsible for maintaining the long push connection between the terminal device and the vendor server, such as sending a heartbeat packet periodically during the connection maintenance, and other common operations. The preprocessing module also includes a long connection module, a message classification module, a regular message preprocessing module, and a ② video slice message preprocessing module. The push message processing module includes a regular message management module and a ③ video slice message management module. The user interface system includes a ⑤ multimedia display module, primarily responsible for playing slices, displaying GIF images, images, and text. The user interface system also includes a notification bar display module and a user notification bar behavior monitoring module. The connection relationships between the various modules are shown in Figure 9 and will not be described in detail further.

[0232] In the software modules shown in Figure 9, the push interface management module in the vendor server, and the ordinary message management module, long connection module, message classification module, ordinary message preprocessing module, and common capability module in the terminal device are all modules that were originally present in the existing push logic and will continue to follow the existing push logic without modification. The push request interface in the developer server and the notification management module in the terminal device, although also modules that were originally present in the existing push logic, have been functionally improved and are considered modified modules. The vendor slice request interface in the vendor server, the push configuration platform in the vendor server, the developer slice request interface in the developer server, the X-second video slice generation module in the live streaming server, and the video slice message management module, video slice message preprocessing module, and multimedia display module in the terminal device are all modules that were not present in the existing push logic and are considered new modules.

[0233] First, let's briefly explain the functions of each modified module and each newly added module involved in Figure 9.

[0234] ⑨ The push configuration platform is a new module, primarily responsible for notifying terminal devices which live streaming platforms have enabled video slicing functionality. ① The push request interface is a modified module. For live streaming platforms that have enabled video slicing, the push message from the developer server to the vendor server needs to include a video slice identifier, also known as a "live stream marker," to inform the vendor server that the message is a live video slice message. ② The video slice message preprocessing module is a new module, primarily responsible for preprocessing push messages for live video slicing functionality, such as differentiating processing units and message sorting from ordinary push messages. ③ The video slice message management module is a new module, mainly used to distinguish whether the real-time live message to be pushed is a text message, an image message, or a video message, and to interact with the vendor server's ⑥ vendor slice request interface and the terminal device's ④ notification management module. ④ The notification management module is a modified module, responsible for monitoring user behavior in the phone's notification bar. If a user pulls down the notification bar, it triggers a request for live video slices from the vendor server. ⑥ The vendor slice request interface is mainly responsible for forwarding the terminal device's live video slice request to the developer server. ⑦ The developer slice request interface is responsible for forwarding requests for live video slices from the vendor server to the live streaming server. ⑧ The X-second video slice generation module is a new module primarily used to generate X-second video slices of the current live video based on the request requirements, and convert them into GIF format images, static images, and text descriptions of the current video slices. After generation, these are packaged and returned to the vendor server. ⑥ The vendor slice request interface is also responsible for forwarding live video slices queried from the developer server to the terminal device. ③ The video slice message management module is also responsible for displaying the corresponding content, such as GIF format images, video slices, static images, and text descriptions, in the ⑤ multimedia display module after receiving the queried live video slice, based on the current state of the user interface system. The ⑤ multimedia display module is mainly used to display multimedia content according to the requirements of the ⑤ notification management module.

[0235] The detailed process of the information push method provided in this application will be further explained below based on the software architecture shown in Figure 9. In the following process, the "real-time live push" mentioned above will be referred to as "live video slice message". That is to say, the "live video slice message" in the following content can also be replaced with "real-time live push", which will not be repeated in this application.

[0236] As shown in Figure 9, the process mainly includes the following steps one through eight:

[0237] Step 1: Activate the "Live Video Slice Message" function in the live streaming app.

[0238] This step primarily involves the manufacturer's server sending a notification message to the terminal device informing them that the live streaming app has enabled live video segmentation. Specifically, this message can be sent from the push configuration platform (⑨) on the manufacturer's server to the video segment message management module (③) on the terminal device, as shown in Figure 10a. This sending operation is mainly used to inform the terminal device which live streaming app has enabled the "live video segment message" function, which is essentially a real-time live streaming push function. Simultaneously, it can also inform the terminal device of the addresses of the video segments, GIF images, static images, and text description files in the live video segment message on the live streaming server, which is the first address mentioned earlier.

[0239] ⑨ The message sent from the push configuration platform to the ③ video slice message management module is the notification message mentioned above, also known as the configuration file. The configuration file must include at least the field content and the identifier of the live streaming app. For example, assuming that APP1, APP2, and APP3 have all enabled the "live video slice message" function, as an example, the content of the configuration file can be seen in Table 1 below:

[0240] Table 1

[0241] In the example in Table 1, both the APP name and the package name are used to identify the live streaming APP, representing two different names for the APP. The APP name is the name known to the user, while the package name is the name internal to the machine, that is, the name that the machine can recognize. It should be noted that Table 1 lists both names for the convenience of those skilled in the art in notifying the content contained in the message; however, in the actual configuration file, only the package name may be included, omitting the APP name.

[0242] Furthermore, the video slice addresses, GIF image addresses, and static image addresses shown in Table 1 are all represented by the directory addresses of the corresponding image resources on the server. In other words, terminal devices can access these directory addresses on the server to find the required image resources in the corresponding folders. However, this is just an example; other examples can use non-directory addresses, such as network addresses or physical addresses, etc., without specific limitations.

[0243] Step two: The developer's server sends a live video slice message to the vendor's server.

[0244] This step primarily involves the developer's server sending live video slice messages from the live streaming app to the vendor's server. For example, the developer's server can determine the live streaming push time for each terminal device based on each user's historical live streaming viewing data, and at the live streaming push time, call the message sending interface in ① the push request interface to send the live video slice message to the push interface management module in the vendor's server to which each terminal device belongs, as shown in Figure 10b. The live video slice message is sent through the PUSH interface, therefore, it is also called a PUSH message.

[0245] As an example, the API name is "send", and the API parameters must include at least the parameters shown in Table 2 below:

[0246] Table 2

[0247] In the example in Table 2, the message body of the live video slice message contains the following four items: the flag "isLiveVideoCutMsg:true" for "The developer server sends a live video slice message", the ID of the terminal device to be pushed (here, the push identifier Token is used as an example), and the title and body of the push message.

[0248] It should be noted that the flag isLiveVideoCutMsg:true is optional. If it is a live video slice message, this flag is included to inform subsequent modules to follow the live video slice process. If it is a regular push message, this flag is not included to inform subsequent modules to follow the original live push process.

[0249] Step 3: The vendor's server sends the live video slice message to the terminal device side, as shown in Figure 10c, which mainly includes the following five steps.

[0250] The first step is to establish a push long connection between the manufacturer's server and the terminal device. When the manufacturer's server has a push message to be sent, the push message can be sent directly and quickly to the terminal device through the push long connection.

[0251] The second step involves the message classification module determining whether the push message is a regular push message or a live video slice message after it arrives at the terminal device. If the message carries the flag `isLiveVideoCutMsg:true`, it indicates a live video slice message, and the message classification module forwards the message body (containing the aforementioned Title and Body fields) to the ② video slice message preprocessing module for processing. If the message does not carry the flag `isLiveVideoCutMsg:true`, it indicates a regular push message, and the message body (containing the aforementioned Title and Body fields, referred to as the message to be pushed) is forwarded to the regular message preprocessing module.

[0252] Third, the video slice message preprocessing module ② records whether there are other pending push messages to be displayed. If there are other pending push messages, the video slice message preprocessing module ② will put the newly received pending push message into the pending display message queue. In the pending display message queue, the system will determine whether there are any pending push messages from the same live streaming app in the current queue. If so, deduplication will be performed to ensure that only one pending push message is generated for a single live streaming app on a single terminal device at any given time. If the pending display message queue is empty, the newly received pending push message will be transferred to the video slice management module ③.

[0253] It should be noted that the preprocessing process for regular push messages is similar to that for live video slice messages. The regular message preprocessing module places the message body of the regular push message into the corresponding message queue to be displayed, performs deduplication, and then forwards it to the regular message management module for display in the notification bar. This part is the same as the existing push logic and will not be described in detail further.

[0254] Fourth, when the message to be pushed enters the ③ video slice management module, the ③ video slice management module forwards the content carried by the push message, that is, the fields including the preset Title and the preset Body, to the ④ notification management module, and informs the ④ notification management module that it needs to monitor whether the user interface system in the notification bar has performed a pull-down action of the notification bar.

[0255] Fifth, the notification management module ④ caches the message to be pushed, including the preset title and body fields, locally within the notification management module ④. For example, the notification management module ④ can directly cache the message to be pushed locally, or it can monitor whether the user interface system performs a pull-down notification bar action; if so, it will cache the message to be pushed locally, without limitation.

[0256] Step four: The user's action of pulling down the notification bar triggers the terminal device to request a video slice from the manufacturer's server.

[0257] For example, as shown in Figure 10d, assuming that within a set time, such as 3 hours, a user unlocks their phone and pulls down the notification bar to read notification messages, the user's action of pulling down the notification bar will trigger the user interface system to send a broadcast indicating that "the user has pulled down the notification bar." This broadcast is used to inform other modules in the terminal device that the user has performed this action. ④ The notification management module detects the broadcast indicating "the user has pulled down the notification bar" and requests a video slice from ③ the video slice management module. ③ After receiving the video slice request, the video slice management module will carry the terminal device's ID (here referring to the ID used to point to the device push from the live streaming platform, such as the Token in Table 2 above) to ⑥ the vendor slice request interface in the vendor's server to request video slice information, and simultaneously set a timer, such as 500ms. This time is just an example and can be configured to other times without limitation.

[0258] Step 5: The vendor's server requests video slices and other information from the live streaming server, as shown in Figure 10e. This mainly includes the following eight steps.

[0259] The first step involves the vendor's server using the vendor slice request interface (⑥) to request video slices and other information from the developer's server using the terminal device's ID (⑦).

[0260] The second step involves the developer's server sending a query request to the configuration server, carrying the terminal device's ID, to retrieve the user ID corresponding to that terminal device.

[0261] The configuration server stores the mapping relationship between Device ID, Token, and User ID. Device ID is an ID that the machine can recognize; Token is an ID from the live streaming platform used to push notifications to the device; and User ID is the ID of the user using the terminal device. In the live streaming push process, the IDs used for interaction between the servers and the terminal devices are primarily Tokens. The configuration server retrieves the corresponding Device ID based on the Token sent by the developer server, then retrieves the corresponding User ID based on the Device ID, and returns it to the developer server.

[0262] The third step is that after the developer server receives the user ID returned by the configuration server, it will query the policy server for the push priority and push policy corresponding to the user ID to obtain the push policy list.

[0263] Optionally, the push priority and push strategy can be defined by the strategy server itself. For example, in one example, the order could be as follows: Priority Level 1, returning information about the streamers the user follows; Priority Level 2, returning information about the streamers the user has viewed for the longest time; Priority Level 3, returning information about the streamers the user has viewed the most times; Priority Level 4, returning information about the streamers the user has previously spent money on (such as purchasing or tipping); Priority Level 5, returning information about live streams of the same type that the user follows; Priority Level 6, returning information about the streamers promoted by the live streaming platform with the largest number of followers; Priority Level 7, returning information about the consumer-oriented streamers promoted by the live streaming platform; and other strategy-related information.

[0264] Based on the above sorting, the policy server queries the user ID sent by the developer server to obtain the following streamers, the streamers with the longest viewing time, the streamers with the most views, the streamers who have previously made purchases, the streamers of the same type as the followed streamers, and the streamers promoted by the live streaming platform, etc. Then, it creates a push policy list based on the information of these streamers (such as streamer ID) and returns it to the developer server.

[0265] Fourth, after receiving the list of push strategies containing broadcaster information (such as broadcaster ID), the developer server calls the developer slice request interface (⑦) to send the list of push strategies containing broadcaster information (such as broadcaster ID) to the live streaming server.

[0266] Fifth, after receiving the push strategy list containing the broadcaster's information (such as the broadcaster's ID), the live streaming server checks whether the corresponding broadcaster is currently live according to the priority order in the push strategy list. After finding the first broadcaster who is currently live, it calls the 8X-second video slice generation module to generate video slices, GIF images, static images, text descriptions of the video slices, and main visual images of the broadcaster's live content.

[0267] Step 6: The 8X-second video slice generation module saves the generated video slices, GIF images, and static images to the server address indicated in the configuration file that enabled this feature in Step 1.

[0268] Optionally, to ensure the standardization of image content stored in the server address for different broadcasters, certain constraints can be set on the image content to be stored, as shown in Table 3 below:

[0269] Table 3

[0270] In the example in Table 3, constraints are imposed on the file type, file format, file duration, and file size of video clips, GIF images, and still images in the server address, along with the address information for each type of image content. None of these three types of image content are mandatory, but if present, video clips are constrained to be 10 seconds long and no larger than 5MB in mp4, avi, flv, or other video formats; GIF images are constrained to be 5 seconds long and 50KB in size in gif format; and still images are constrained to be 50KB in size in png, jpeg, jpg, or other image formats.

[0271] It should be noted that the file types, file formats, file durations, and file sizes shown in Table 3 above are only examples. In actual storage scenarios, there may be other file types, file formats, file durations, and file sizes, etc., and this application does not make any specific limitations on them.

[0272] Step 7: In order to save network loss and improve transmission efficiency, the addresses and filenames of the generated video slices, GIF images, static images, text descriptions of the video slices, and main visual images are used as video slice information.

[0273] As an example, the video slice information should at least include the content shown in Table 4 below:

[0274] Table 4

[0275] In the examples in Table 4, the terminal device identifier, the title and content of the text description, and the main visual image are all required, while the description information for video slices, GIF images, and still images is optional. Furthermore, for any image content among video slices, GIF images, and still images, the description information may include the type, size, address, and name (i.e., address identifiers, such as directory and filename) of the image content. The relevant information for video slices and GIF images may also include the duration.

[0276] Step 8: The live streaming server returns the video slice information to the terminal device via the original path.

[0277] For example, as shown in Figure 10f, the ⑧X-second video slice generation module in the live streaming server returns the video slice information to the ⑦ developer slice request interface in the developer server. The ⑦ developer slice request interface then forwards the information to the ⑥ manufacturer slice request interface in the manufacturer server, and finally to the ③ video slice message management module in the terminal device.

[0278] Step six, the processing of video slice information returned by the live streaming server by the terminal device, as shown in Figure 10g, includes the following two branches.

[0279] Branch 1: If the video slice management module ③ in the terminal device has not received the video slice information returned by the live server by the timer set in step 4 above, then the video slice management module ③ notifies the management module ④ to call the multimedia display module ⑤ in the user interface system to display the preset information of the live video slice message, which is the preset information pushed in step 2 above.

[0280] As an example, the content of the preset information can be seen in Table 5 below, and the display interface in the notification bar is shown in Figure 11a:

[0281] Table 5

[0282] Branch 2: If the video slice management module ③ in the terminal device receives the video slice information returned by the live streaming server before the timer set in step 4 expires, then the process is as follows:

[0283] The first step is to parse the video slice information using the video slice management module ③, and obtain the content shown in Table 6 below:

[0284] Table 6

[0285] The second step, by default, displays the text description information in the live video slice message, including the content shown in Table 7 below:

[0286] Table 7

[0287] In other words, of all the parsed content, the content shown in Table 7 above will definitely be displayed in the notification bar, while the other content will depend on the actual situation of the terminal device to determine whether it should be displayed. Please refer to steps three to six below for details.

[0288] The third step involves determining whether the terminal device can display video format based on its network conditions and operating system (such as the user interface system). If online display is possible, the notification management module (④) is notified to play the video format video clip online using the parsed VideoURLName and the default configuration address from step one. If online display is not possible, the video format video clip is downloaded from the corresponding folder using the VideoURLName and the default configuration address from step one, and then the notification management module (④) is notified to call the multimedia display module (⑤) in the user interface system to play the downloaded video clip. For example, in a Wi-Fi connected state, the terminal device can display video clips online or in real-time on the notification bar, as shown in Figure 11b.

[0289] Fourth, based on the network conditions and operating system of the terminal device at the time, if the terminal device does not support displaying video format, or online playback fails, or downloading video segment files fails, or downloading video segment files times out (e.g., 10ms), or playing downloaded video segment files fails, then it is determined whether the terminal device itself supports displaying GIF format. If online display is possible, then based on GifURLName and the default configuration address in step one above, the notification management module (④) is notified to play the GIF format animated image online. If online display is not possible, then based on GifURLName and the default configuration address in step one above, the GIF format animated image is downloaded from the corresponding folder, and then the notification management module (④) is notified to call the multimedia display module (⑤) in the user interface system to play the downloaded animated image. For example, in 4G or 5G network conditions, the terminal device can display GIF animations online or in real time on the notification bar, as shown in Figure 11c.

[0290] Fifth, based on the network conditions and operating system of the terminal device at the time, if the terminal device does not support displaying GIF format, or online playback fails, or downloading the GIF format animated image fails, or downloading the GIF format animated image times out (e.g., 10ms), or playing the downloaded animated image fails, then it is determined whether the terminal device itself supports static image format. If online display is possible, then based on ImageURLName and the default configuration address in step one above, the notification management module (④) is notified to display the static image in Image format online. If online display is not possible, then based on ImageURLName and the default configuration address in step one above, the static image in Image format is downloaded from the corresponding folder, and then the notification management module (④) is notified to call the multimedia display module (⑤) in the user interface system to display the static image in Image format. For example, in 3G network mode, the terminal device can display static animated images online or in real time on the notification bar, as shown in Figure 11d.

[0291] Step 6: Depending on the network conditions and the operating system of the terminal device at that time, if the terminal device does not support displaying the image format, or fails to display online, or fails to download the static image in the image format, or times out when downloading the static image in the image format (e.g., 10ms), or fails to play the downloaded static image, then no other information will be displayed, only the preset information in step 2 will be displayed. The display interface of the notification bar is shown in Figure 11a.

[0292] Step 8: Processing the message after it is displayed on the terminal device.

[0293] If, within a set timeframe, such as three hours (this is an example, but other durations can be configured), a user clicks on a push notification in the notification bar, the terminal device will redirect to the corresponding live streaming app's live room. Simultaneously, push notifications in the notification bar will be automatically cleared, along with previously downloaded video clips, GIFs, and still images.

[0294] Conversely, if the user does not click on the push notification within the set time, such as after three hours, the push notification will be automatically cleared from the notification bar, along with previously downloaded video clips, GIF files, image files, etc.

[0295] Based on the above, it is equivalent to adding some software modules to the original push logic, while improving some existing modules. This allows for the addition of real-time live message push functionality while making the most of the existing modules in the terminal device, without affecting the original live message push operation.

[0296] Based on the information push method described above, this application can also provide an information push device, which can be used to execute the above information push method. The relevant features can be found in the above method embodiments, and will not be repeated here.

[0297] In one possible implementation, Figure 12 shows a possible structural schematic diagram of an information push device provided in this application. The information push device 1200 may be a terminal device or a module (e.g., circuit, chip, or chip system) in the terminal device described in the above embodiments, or it may be a logical node, logical module, or software applied to or used in conjunction with a terminal device or its module, capable of realizing all or part of the functions of the terminal device.

[0298] The information push device 1200 may include modules or units for implementing the methods corresponding to the terminal device side in the above method embodiments. For example, in one possible design, the information push device 1200 may include a transceiver unit 1210 and a display unit 1220. The transceiver unit 1210 may also be called a communication unit, transceiver, transceiver device, or transceiver unit, etc., and the display unit 1220 may also be called a display, display chip, display board, or display device, etc. The display unit 1220 is used to perform the display operation in the above information push method, and the transceiver unit 1210 can be used to perform the sending and receiving operations in the above information push method. The device in the transceiver unit 1210 that implements the receiving function can be regarded as a receiving unit, and the device in the transceiver unit 1210 that implements the sending function can be regarded as a sending unit. That is, the transceiver unit 1210 includes a receiving unit and a sending unit.

[0299] For example, in one embodiment, the transceiver unit 1210 is used to respond to the user's operation of pulling down the notification bar of the terminal device, send a live broadcast request message to the server, and receive a live broadcast response message from the server. The live broadcast response message includes first live broadcast information, which includes first live broadcast content of a first anchor related to the user; the display unit 1220 is used to display the first live broadcast information in the notification bar.

[0300] In one possible design, before the transceiver unit 1210 responds to the user's action of pulling down the notification bar of the terminal device, the transceiver unit 1210 may also receive a first live push message from the server. The first live push message includes a setting flag, which is a flag that instructs the terminal device to send a live request message to the server when the user pulls down the notification bar.

[0301] In a further possible design, the first live broadcast push message also includes second live broadcast information, which is preset live broadcast information generated by the server; after the transceiver unit 1210 sends a live broadcast request message to the server, if no live broadcast response message is received within a first set time period, the display unit 1220 displays the second live broadcast information in the notification bar.

[0302] In one possible design, the transceiver unit 1210 can also receive a second live stream push message from the server, which is second live stream information. The second live stream information is preset live stream information generated by the server, and the display unit 1220 displays the second live stream information in the notification bar.

[0303] In a further possible design, the first live broadcast push message and / or the second live broadcast message mentioned above are sent to the terminal device through a long push connection between the server and the terminal device.

[0304] In one possible design, before the transceiver unit 1210 responds to the user's action of pulling down the notification bar of the terminal device, the transceiver unit 1210 may also receive a notification message from the server, which includes the identifier of the first application (APP) and is used to instruct the first APP to enable the real-time live streaming push function; after the transceiver unit 1210 responds to the user's action of pulling down the notification bar of the terminal device, the transceiver unit 1210 sends a live streaming request message carrying the identifier of the first APP to the server, which is used to request the live streaming content of the host broadcasting on the first APP.

[0305] In a further possible design, as shown in Figure 12, the information push device 1200 may also include a processing unit 1230. After the transceiver unit 1210 receives the live response message from the server, the processing unit 1230 stores the first live information in a set queue. When there are other live information of the first APP in the set queue, the other live information and the first live information are deduplicated. After deduplication, the first APP has only one live information in the set queue.

[0306] In a further possible design, the notification message also includes a first address, which is the storage address of the image content in the live stream content of each streamer broadcasting on the first APP; the first live stream content includes the text description content of the first streamer's live stream content, and the live stream response message also includes a location identifier, which is used to indicate the storage location of the image content in the first streamer's live stream content in the first address. Based on this, the display unit 1220 displays the first live stream information in the notification bar, specifically: the display unit 1220 obtains the image content in the first streamer's live stream content according to the first address and the location identifier, and displays the image content together with the first live stream content in the notification bar.

[0307] In one possible design, the first live broadcast content includes text descriptions of the first broadcaster's live broadcast content and a second address. The second address is the storage address of the image content in the first broadcaster's live broadcast content. Based on this, the display unit 1220 displays the first live broadcast information in the notification bar. Specifically, the display unit 1220 obtains the image content in the first broadcaster's live broadcast content from the second address and displays the image content together with the first live broadcast content in the notification bar.

[0308] In a further possible design, the first live stream content may also include the main visual image of the first anchor's live stream content.

[0309] In a further possible design, the image content includes video clips, animated images, and still images. The display unit 1220 displays the image content and the first live broadcast content together in the notification bar. Specifically, the display unit 1220 may display one of the video clips, animated images, and still images together with the text description in the notification bar.

[0310] In a further possible design, the display unit 1220 displays one of the following in the notification bar: a video clip, an animated image, or a static image, along with a text description. Specifically, the display unit 1220 determines the push capability of the terminal device based on one or more of the terminal device's battery level, power consumption, network connectivity, display capabilities, and operating system. If the push capability supports playing video clips, then the video clip and text description are displayed in the notification bar. If the push capability does not support playing video clips but supports playing animated images, then the animated image and text description are displayed in the notification bar. If the push capability only supports displaying static images, then the static image and text description are displayed in the notification bar.

[0311] In a further possible design, the display unit 1220 displays the image content in the notification bar. Specifically, if the terminal device's display capability supports online display, the display unit 1220 displays the image content in real time on the notification bar. If the terminal device's display capability does not support online display, the display unit 1220 downloads the image content to the local device and then displays the locally stored image content on the notification bar.

[0312] In a further possible design, as shown in Figure 12, the information push device 1200 may also include a processing unit 1230. After the display unit 1220 displays the image content in the notification bar, if the image content is clicked, or if it is not clicked after a second set time period, the processing unit 1230 deletes the locally stored image content.

[0313] In a further possible design, after the display unit 1220 displays the image content and the first live content together in the notification bar, the display unit 1220 can also respond to the user's operation of pulling down the notification bar again, display the first live content, and collapse the image content.

[0314] In a further possible design, after the display unit 1220 collapses the image content, in response to the user clicking the collapse button, the display unit 1220 can also display the image content to the user, or the processing unit 1230 can send a live broadcast request message to the server again.

[0315] In another possible implementation, Figure 13 shows a possible structural schematic diagram of an information push device provided in this application. The information push device 1300 may be a server or a module (e.g., a circuit, chip, or chip system) in the above embodiments, or it may be a logical node, logical module, or software applied to a server or its module, or used in conjunction with a server or its module, capable of realizing all or part of the server functions.

[0316] The information push device 1300 may include modules or units for implementing the corresponding methods on the server side in the above method embodiments. For example, in one possible design, the information push device 1300 may include a processing unit 1310 and a transceiver unit 1320. The processing unit 1310 may also be referred to as a processor, processing chip, processing board, or processing device, etc., and the transceiver unit 1320 may also be referred to as a communication unit, transceiver, transceiver, or transceiver device, etc. The processing unit 1310 is used to perform the processing operations in the above information push method, and the transceiver unit 1320 can be used to perform the sending and receiving operations in the above information push method. The device in the transceiver unit 1320 that implements the receiving function can be regarded as a receiving unit, and the device in the transceiver unit 1320 that implements the sending function can be regarded as a sending unit. That is, the transceiver unit 1320 includes a receiving unit and a sending unit.

[0317] For example, in one embodiment, under the control of the processing unit 1310, the transceiver unit 1320 receives a live broadcast request message from the terminal device and sends a live broadcast response message to the terminal device. The live broadcast request message is sent to the server by the terminal device in response to the user's operation of pulling down the notification bar of the terminal device. The live broadcast response message includes first live broadcast information, which includes first live broadcast content of the first anchor related to the user.

[0318] In one possible design, before the transceiver unit 1320 receives the live broadcast request message from the terminal device, the transceiver unit 1320 may also send a first live broadcast push message to the terminal device. The first live broadcast push message includes a setting flag, which is a flag that instructs the terminal device to send a live broadcast request message to the server when the user pulls down the notification bar.

[0319] In a further possible design, the first live stream push message may also include second live stream information, which is a preset live stream information generated by the server.

[0320] In one possible design, the transceiver unit 1320 can also send a second live push message to the terminal device. The second live push message includes second live information, which is preset live information generated by the server.

[0321] In a further possible design, the transceiver unit 1320 sends a first live push message or a second live push message to the terminal device. Specifically, the transceiver unit 1320 sends the first live push message or the second live push message to the terminal device through a long push connection between the server and the terminal device.

[0322] In one possible design, before the transceiver unit 1320 receives the live streaming request message from the terminal device, the transceiver unit 1320 may also send a notification message to the terminal device after the first application (APP) enables the real-time live streaming push function. The notification message includes the identifier of the first APP. Correspondingly, the transceiver unit 1320 sends a live streaming response message to the terminal device. Specifically, the transceiver unit 1320 determines the first broadcaster related to the user among the various broadcasters broadcasting on the first APP, and sends a live streaming response message to the terminal device based on the live streaming content of the first broadcaster.

[0323] In further possible designs, the first anchor meets one or more of the following conditions: the anchor followed by the user, the anchor with the longest user browsing time, the anchor with the most user views, the anchor that the user has interacted with, the anchor of the same type as the anchor followed by the user, and the anchor that is promoted by the first APP.

[0324] In a further possible design, the notification message also includes a first address, which is the storage address of the image content in the live broadcast content of each anchor on the first APP. Based on this, the transceiver unit 1320 sends a live response message to the terminal device. Specifically, the transceiver unit 1320 stores the image content in the live broadcast content of the first anchor in the first location of the first address, generates a live response message based on the text description content in the live broadcast content of the first anchor and the location identifier of the first location, and then sends the live response message to the terminal device.

[0325] In one possible design, the transceiver unit 1320 sends a live response message to the terminal device. Specifically, the transceiver unit 1320 stores the image content in the live content of the first broadcaster at a second address, generates a live response message based on the text description content in the live content of the first broadcaster and the second address, and then sends the live response message to the terminal device.

[0326] In a further possible design, the first live stream content may also include the main visual image of the first anchor's live stream content.

[0327] In further possible designs, the image content may include one or more of the following: video clips, animated images, and still images.

[0328] It is understood that the division of units in the above-described device is merely a logical functional division. One function can correspond to one functional unit, or two or more functions can be integrated into one functional unit. In actual implementation, all or some units can be integrated onto a single physical entity, or distributed across different physical entities. Furthermore, the aforementioned functional units can be implemented in hardware, software, or a combination of both. Whether a function is executed in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for specific applications, but such implementations should not be considered beyond the scope of this application.

[0329] In one example, the functional unit in any of the above devices may be one or more integrated circuits configured to implement the above methods, such as: one or more application-specific integrated circuits (ASICs), or one or more central processing units (CPUs), one or more microcontroller units (MCUs), one or more digital signal processors (DSPs), or one or more field-programmable gate arrays (FPGAs), or a combination of at least two of these integrated circuit forms.

[0330] In another possible implementation, please refer to Figure 14, which shows another possible structural schematic diagram of the information push device. The information push device 1400 shown in Figure 14 includes at least one processor 1410 and interface circuitry 1420. The at least one processor 1410 is coupled to a memory. Optionally, the memory may be located within the information push device 1400 and integrated with the processor 1410, or it may be located outside the information push device 1400. For example, the information push device 1400 may also include at least one memory 1430. The at least one memory 1430 stores the necessary computer programs (or instructions) and / or data for implementing any of the above embodiments; the at least one processor 1410 can execute the computer programs (or instructions) and / or data stored in the at least one memory 1430 to complete the methods in any of the above embodiments.

[0331] The information push device 1400 can interact with other devices through the interface circuit 1420. For example, the interface circuit 1420 can be a transceiver, circuit, bus, module, pin, or other type of communication interface. When the information push device 1400 is a chip-type device or circuit, the interface circuit 1420 can also be an input / output circuit, capable of inputting information (or receiving information) and outputting information (or sending information). The processor can be an integrated processor, microprocessor, integrated circuit, or logic circuit, and the processor can determine the output information based on the input information.

[0332] The coupling in this embodiment is an indirect coupling or communication connection between devices, units, or modules, which can be electrical, mechanical, or other forms, used for information exchange between devices, units, or modules. The processor 1410 may operate in conjunction with the memory 1430 and the interface circuit 1420. This embodiment does not limit the specific connection medium between the processor 1410, the memory 1430, and the interface circuit 1420.

[0333] Optionally, referring to Figure 14, the processor 1410, the memory 1430, and the interface circuit 1420 are interconnected via a bus. The bus can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used in Figure 14, but this does not indicate that there is only one bus or one type of bus.

[0334] In the embodiments of this application, the processor 1410 may be a general-purpose processor, a digital signal processor, an application-specific integrated circuit, a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly manifested as being executed by a hardware processor, or executed by a combination of hardware and software modules within the processor.

[0335] In this embodiment, the memory 1430 can be a non-volatile memory, such as a hard disk drive (HDD) or a solid-state drive (SSD), or it can be volatile memory, such as random-access memory (RAM). The memory 1430 can be any other medium capable of carrying or storing desired program code in the form of instructions or data structures, and accessible by a computer, but is not limited thereto. The memory 1430 in this embodiment can also be a circuit or any other device capable of implementing storage functions for storing program instructions and / or data.

[0336] When the information push device 1400 is used to implement the above method embodiment, the processor 1410 is used to implement the functions of the display unit 1220 and the processing unit 1230, or to implement the functions of the processing unit 1310. The interface circuit 1420 is used to implement the functions of the transceiver unit 1210, or to implement the functions of the transceiver unit 1320, and will not be described again here.

[0337] Based on the above, this application also provides an information push system, which includes the above-mentioned terminal devices and servers, and can be used to execute the information push method provided in any of the above method embodiments.

[0338] Based on the above, this application also provides a computer-readable storage medium storing instructions that, when executed, cause the method provided in any of the above-described method embodiments to be implemented. The computer-readable storage medium may include various media capable of storing program code, such as a USB flash drive, portable hard drive, read-only memory, random access memory, magnetic disk, or optical disk.

[0339] Based on the above, this application also provides a computer program product, which includes: a computer program (also referred to as code or instructions), which, when run on a computer, causes the computer to perform the method provided in any of the above method embodiments. Optionally, the computer can be a terminal device.

[0340] In all the above implementation schemes, unless otherwise specified or there is a logical conflict, the terminology and / or descriptions of different implementation schemes are consistent and can be referenced by each other. The technical features of different implementation schemes can be combined to form new implementation schemes according to their inherent logical relationships.

[0341] In this application, "at least one" means one or more, and "more than one" means two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. Furthermore, the various numbers involved in the embodiments of this application (such as the numerical numbers "first," "second," "third," etc.) are only for descriptive convenience and are not intended to limit the scope of the embodiments of this application. The order of the sequence numbers of the above processes does not imply the order of execution; the execution order of each process should be determined by its function and internal logic.

[0342] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, compact disc read-only memory (CD-ROM), optical storage, etc.) containing computer-usable program code.

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

[0344] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means that implement the functions specified in one or more flowcharts and / or one or more block diagrams.

[0345] These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable apparatus, provide steps for implementing the functions specified in one or more flowcharts and / or one or more block diagrams.

Claims

1. An information push method, characterized in that, Applied to a terminal device, the method includes: In response to the user pulling down the notification bar of the terminal device, a live streaming request message is sent to the server; Receive a live response message from the server, the live response message including first live information, the first live information including first live content of a first broadcaster related to the user; The first live stream information will be displayed in the notification bar.

2. The method as described in claim 1, characterized in that, Prior to the user's action of pulling down the notification bar of the terminal device, the method further includes: The terminal device receives a first live stream push message from the server. The first live stream push message includes a setting flag, which is a flag that instructs the terminal device to send the live stream request message to the server when the user pulls down the notification bar.

3. The method as described in claim 2, characterized in that, The first live stream push message also includes second live stream information, which is preset live stream information generated by the server; After responding to the user's action of pulling down the notification bar of the terminal device and sending a live broadcast request message to the server, the method further includes: If the live broadcast response message is not received within the first set time period, the second live broadcast information will be displayed in the notification bar.

4. The method according to any one of claims 1 to 3, characterized in that, Before sending a live stream request message to the server in response to the user's action of pulling down the notification bar of the terminal device, the method further includes: Receive a notification message from the server, the notification message including the identifier of the first application (APP), the notification message being used to instruct the first APP to enable the real-time live streaming push function; The step of sending a live streaming request message to the server in response to the user's action of pulling down the notification bar of the terminal device includes: In response to the user's action of pulling down the notification bar, a live streaming request message carrying the identifier of the first APP is sent to the server. The live streaming request message is used to request the live streaming content of the host who is broadcasting on the first APP.

5. The method as described in claim 4, characterized in that, After receiving the live response message from the server, the process further includes: Store the first live stream information into a designated queue; If there are other live stream information of the first APP in the set queue, then the other live stream information and the first live stream information are deduplicated. After deduplication, the first APP has only one live stream information in the set queue.

6. The method as described in claim 4 or 5, characterized in that, The notification message also includes a first address, which is the storage address of the image content in the live broadcast content of each streamer on the first APP; the first live broadcast content includes the text description content in the live broadcast content of the first streamer; the live broadcast response message also includes a location identifier, which is used to indicate the storage location of the image content in the live broadcast content of the first streamer in the first address. Displaying the first live stream information in the notification bar includes: Based on the first address and the location identifier, obtain the image content from the live stream of the first broadcaster, and display the image content and the text description together in the notification bar.

7. The method according to any one of claims 1 to 5, characterized in that, The first live stream content includes the text description content in the live stream content of the first streamer, and the live stream response message also includes a second address, which is the storage address of the image content in the live stream content of the first streamer; Displaying the first live stream information in the notification bar includes: The image content from the live stream of the first broadcaster is obtained from the second address, and the image content and the text description content are displayed together in the notification bar.

8. The method as described in claim 6 or 7, characterized in that, The first live stream content also includes the main visual image of the first streamer's live stream content.

9. The method according to any one of claims 6 to 8, characterized in that, The image content includes video clips, animated images, and still images. Displaying the image content and the text description together in the notification bar includes: Display one of the video clips, the animated images, and the static images along with the text description in the notification bar.

10. The method as described in claim 9, characterized in that, Displaying one of the video slice, the animated image, and the static image along with the text description in the notification bar includes: The push capability of the terminal device is determined based on one or more of the terminal device's battery level, power consumption, network connectivity, display capabilities, and operating system. If the push notification capability supports playing the video clip, then the video clip and the text description content are displayed in the notification bar; if the push notification capability does not support playing the video clip but supports playing the animated image, then the animated image and the text description content are displayed in the notification bar; if the push notification capability only supports displaying the static image, then the static image and the text description content are displayed in the notification bar.

11. The method according to any one of claims 6 to 10, characterized in that, Displaying the image content in the notification bar includes: If the terminal device's display capability supports online display, the image content will be displayed in real time on the notification bar. If the terminal device's display capability does not support online display, the image content will be downloaded to the local device and then displayed on the notification bar.

12. The method as described in claim 11, characterized in that, The step of displaying the image content after the notification bar also includes: If the image content is clicked, or if it is not clicked after a second set time period, the image content stored locally is deleted.

13. The method according to any one of claims 6 to 12, characterized in that, The step of displaying the image content and the text description together after the notification bar also includes: In response to the user pulling down the notification bar again, the text description is displayed and the image content is collapsed; In response to the user clicking the collapse button, the image content is displayed to the user, or the live streaming request message is sent to the server again.

14. An information push method, characterized in that, Applied to a server, the method includes: Receive a live streaming request message from a terminal device, wherein the live streaming request message is sent to the server by the terminal device in response to the user pulling down the notification bar of the terminal device; A live broadcast response message is sent to the terminal device. The live broadcast response message includes first live broadcast information, which includes first live broadcast content of a first broadcaster related to the user.

15. The method as described in claim 14, characterized in that, Before receiving the live broadcast request message from the terminal device, the method further includes: A first live stream push message is sent to the terminal device. The first live stream push message includes a setting flag, which is a flag that instructs the terminal device to send the live stream request message to the server when the user pulls down the notification bar.

16. The method as described in claim 15, characterized in that, The first live stream push message also includes second live stream information, which is preset live stream information generated by the server.

17. The method according to any one of claims 14 to 16, characterized in that, Before receiving the live streaming request message from the terminal device, the method further includes: when the first application APP enables the real-time live streaming push function, sending a notification message to the terminal device, wherein the notification message includes the identifier of the first APP; Sending the live response message to the terminal device includes: obtaining the live content of the first streamer from the live content of each streamer broadcasting on the first APP, and sending the live response message to the terminal device according to the live content of the first streamer.

18. The method as described in claim 17, characterized in that, The first broadcaster meets one or more of the following conditions: The broadcasters followed by the user, the broadcasters with the longest user browsing time, the broadcasters with the most user views, the broadcasters that the user has interacted with, the broadcasters of the same type as the broadcasters followed by the user, and the broadcasters promoted by the first APP.

19. The method as described in claim 17 or 18, characterized in that, The notification message also includes a first address, which is the storage address of image content in the live broadcast content of each anchor on the first APP. Sending the live response message to the terminal device includes: The image content from the first streamer's live stream is stored at a first location of the first address. The live stream response message is generated based on the text description content from the first streamer's live stream and the location identifier of the first location. The live stream response message is then sent to the terminal device.

20. The method according to any one of claims 14 to 18, characterized in that, Sending the live response message to the terminal device includes: The image content from the first broadcaster's live stream is stored at a second address. The live stream response message is generated based on the text description content from the first broadcaster's live stream and the second address, and then the live stream response message is sent to the terminal device.

21. The method as described in claim 19 or 20, characterized in that, The first live stream content also includes the main visual image of the first streamer's live stream content.

22. The method according to any one of claims 19 to 21, characterized in that, The image content includes one or more of the following: video clips, animated images, and still images.

23. An information push device, characterized in that, It includes units and / or modules for implementing the method as described in any one of claims 1 to 13, or units and / or modules for implementing the method as described in any one of claims 14 to 22.

24. An information push device, characterized in that, The device includes a processor coupled to a memory, the processor being configured to execute a computer program or instructions stored in the memory to cause the information push device to perform the method as described in any one of claims 1 to 13, or to perform the method as described in any one of claims 14 to 22.

25. An information push system, characterized in that, It includes a terminal device and a server, the terminal device being used to perform the method as described in any one of claims 1 to 13, and the server being used to perform the method as described in any one of claims 14 to 22.

26. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a program or instructions that, when executed, implement the method as described in any one of claims 1 to 13, or the method as described in any one of claims 14 to 22.

27. A computer program product, characterized in that, The computer program product includes computer program code that, when run on a computer, causes the computer to perform the method as described in any one of claims 1 to 13, or the method as described in any one of claims 14 to 22.

Images