Terminal, method, and computer program

Abstract

To provide a terminal, a method, and a computer program that smoothly display requested data such as leader-board data on a user terminal regardless of the network status, rather than display a blank screen, so as to improve the user experience.SOLUTION: A terminal for processing data on a live streaming platform includes one or more processors of which the one or more processors execute the functions for executing machine-readable instructions to send a request for a portion of the data, receiving a response to the request, setting the number of retries in response to the response failing and the portion of the data not being the first portion, determining a retry time on the basis of the set number of retries, and sending the next request for the portion of the data after the retry time.SELECTED DRAWING: Figure 14

Description

[Technical field]

[0001] The present disclosure relates to information and communication technology, and in particular to a terminal, a method, and a computer program for live streaming. [Background technology]

[0002] Some apps and platforms provide live streaming services where live streamers and viewers can interact with each other. Live streamers may perform performances to support their viewers, and viewers may donate or send gifts to support live streamers. They also hold various campaigns and events to attract more live streamers and viewers to participate in live streaming.

[0003] Since interactions between live streamers and viewers are real-time, calculation and updating of data such as leaderboards must be fast and accurate. Patent Document 1 discloses a method for displaying a cache of a leaderboard, reducing server load, and improving the timeliness of information.

[0004] However, depending on the network conditions of the user terminal, the display of data may vary. Also, if a blank screen is displayed while requesting data, it may cause user dissatisfaction and reduce the user experience. Therefore, how to handle data from the network and cache is a very important issue. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] Chinese Patent No. 107249140 Summary of the Invention

[0006] A terminal for processing data in a live streaming platform according to an embodiment of the present disclosure includes one or more processors, wherein the one or more processors execute machine-readable instructions to perform functions of sending a request for a portion of data, receiving a response to the request, setting a retry count in response to the response being a failure and the portion of data not being a first portion, determining a retry time based on the set retry count, and sending a next request for the portion of data after the retry time.

[0007] A method for processing data in a live streaming platform according to another embodiment of the present disclosure includes sending a request for a portion of data, receiving a response to the request, setting a retry count in response to the response being a failure and the portion of data not being a first portion, determining a retry time based on the set retry count, and sending a next request for the portion of data after the retry time.

[0008] A computer program according to another embodiment of the present disclosure enables a terminal to perform the following functions: sending a request for a portion of data; receiving a response to the request; setting a retry count in response to the response being unsuccessful and the portion of data not being a first portion; determining a retry time based on the set retry count; and sending a next request for the portion of data after the retry time.

[0009] According to the present disclosure, instead of displaying a blank screen, requested data, such as leaderboard data, can be smoothly displayed on a user terminal regardless of network conditions, potentially improving user experience. [Brief description of the drawings]

[0010] [Figure 1]1 is a schematic diagram showing a configuration of a live streaming system 1 based on some embodiments of the present disclosure. [Diagram 2] FIG. 2 is a block diagram of a user terminal 20 according to some embodiments of the present disclosure. [Diagram 3] FIG. 1 is a block diagram of a server 10 according to some embodiments of the present disclosure. [Figure 4] 4 is a table showing an example data structure of the stream DB 320 of FIG. 3. [Diagram 5] 4 is a table showing an example data structure of the user DB 322 of FIG. 3. [Figure 6] 4 is a table showing an example data structure of the data DB 324 of FIG. 3. [Figure 7] 3 is a table showing an example data structure of the cache DB 250 of FIG. 2. [Figure 8] 4 is a table showing an example data structure of the data queue DB 252 of FIG. 2. [Figure 9] 13 is an exemplary screen image of a live streaming room screen 660 displayed on the display of a live streamer's user terminal 20 or a viewer's user terminal 30. [Figure 10] 13 is an exemplary screen image of a live streaming room screen 660 displayed on the display of a live streamer's user terminal 20 or a viewer's user terminal 30. [Figure 11] 13 is an exemplary screen image of a live streaming room screen 660 displayed on the display of a live streamer's user terminal 20 or a viewer's user terminal 30. [Figure 12] 13 is a flowchart showing the steps of an application startup process in the user terminal 20, 30. [Figure 13] 13 is a flowchart showing the steps of an application startup process in the user terminal 20, 30. [Figure 14] 13 is a flowchart showing the steps of an application startup process in the user terminal 20, 30. [Figure 15]13 is a flowchart showing the steps of an application startup process in the user terminal 20, 30. [Figure 16] 13 is a flowchart showing a process for determining a retry time. [Figure 17] 3 is a table illustrating an example data structure for the retry time lookup table 254 of FIG. 2. [Figure 18] 13 is a flowchart showing a process for determining a refresh time. [Figure 19] 3 is a table illustrating an example data structure of the refresh time lookup table 256 of FIG. 2. [Figure 20] 1 illustrates an exemplary hardware configuration of an information processing device based on some embodiments of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0011] Hereinafter, the same or similar components, parts, steps, or signals shown in each drawing will be denoted by the same reference numerals in all drawings, and duplicated explanations will be omitted as appropriate. In addition, some parts that are not important in the explanation of each drawing will be omitted.

[0012] The live streaming system 1 according to some embodiments of the present disclosure provides enhanced functionality to facilitate communication and interaction between users, and more specifically, to entertain viewers and live streamers in a technological manner.

[0013] FIG. 1 shows a schematic diagram illustrating a configuration of a live streaming system 1 according to some embodiments of the present disclosure. The live streaming system 1 provides a live streaming service for a live streamer (also called a liver, streamer, or distributor) LV and a viewer (also called an audience) AU (AU1, AU2, ...) of streaming to interact with each other in real time. As shown in FIG. 1, the live streaming system 1 may include a server 10, a user terminal 20, and a user terminal 30 (30a, 30b, ...). The user terminal 20 may be a live streamer, and the user terminal 30 may be a viewer. In some embodiments, the live streamer and the viewer may be called users. The server 10 may include one or more information processing devices connected via a network NW. The user terminals 20 and 30 may be, for example, mobile terminals such as smartphones, tablets, notebook PCs, recorders, portable game consoles, and wearable terminals, or stationary computers such as desktop PCs. The server 10, the user terminal 20, and the user terminal 30 may be communicatively connected by any type of wired or wireless network NW.

[0014] The live streaming system 1 involves the live streamer LV, the viewer AU, and an app provider (not shown) that provides the server 10. The live streamer LV can record content such as his / her own singing, talking, performance, game streaming, etc. on his / her user terminal 20 and upload it to the server 10, thereby distributing the content in real time. In some embodiments, the live streamer LV can interact with the viewer AU through the live streaming.

[0015] The app provider may provide a platform for content to be live streamed on the server 10. In some embodiments, the app provider may be a media or manager that manages real-time communication between the live streamer LV and the viewer AU. The viewer AU may access the platform through the user terminal 30 and select and view the content that the viewer AU wants to view. The viewer AU may perform operations to interact with the live streamer, such as commenting on the live streamer or cheering on the live streamer, through the user terminal 30. The live streamer providing the content may respond to the comments or cheers. The live streamer's response may be transmitted to the viewer AU by video and / or audio. Thus, mutual communication between the live streamer and the viewer may be achieved.

[0016] The term "live streaming" as used herein may refer to data transmission that allows the viewer AU to substantially play and view the content recorded by the live streamer LV via the user terminal 20 via the user terminal 30. In some embodiments, "live streaming" may refer to streaming realized by the above-mentioned data transmission. The live streaming may be realized by known technologies such as HTTP live streaming, CMAF (Common Media Application Format), WebRTC (Web Real-Time Communications), RTMP (Real-Time Messaging Protocol), and MPEG DASH. The live streaming may further include an embodiment in which the viewer AU can play or view the content with a certain delay while the live streamer is recording the content. It is desirable that the degree of the delay is small enough to at least allow the live streamer LV and the viewer AU to communicate with each other. However, live streaming is different from so-called on-demand distribution. More specifically, the on-demand distribution may refer to storing all data of the recorded content in a server and providing the data to the user from the server at random times in response to a user's request.

[0017] In this specification, "streaming data" may refer to data including image data and audio data. More specifically, the image data (which may be referred to as video data) may be generated by an image capture function of the user terminals 20 and 30. The audio data (which may be referred to as audio data) may be generated by an audio input function of the user terminals 20 and 30. The streaming data may be played on the user terminals 20 and 30 to enable viewing of content related to the user. In some embodiments, a process of changing the format and size standard of data, such as compression, expansion, encoding, decoding, transcoding, etc., is assumed between the time when the streaming data is generated on the user terminal of the live streamer and the time when it is played on the user terminal of the viewer. Before and after such processing, the content (video and audio) is not substantially changed, and therefore, in the current embodiment of the present disclosure, the streaming data before processing and the streaming data after processing are described as being the same. In other words, when the streaming data generated by the user terminal of the live streamer is played on the user terminal of the viewer via the server 10, the streaming data generated by the user terminal of the live streamer, the streaming data that has passed through the server 10, and the streaming data received and played by the user terminal of the viewer are all the same streaming data.

[0018] As shown in Fig. 1, the live streamer LV provides live streaming. The user terminal 20 of the live streamer generates streaming data by recording the video and / or audio of the streamer, and transmits the streaming data to the server 10 via the network NW. At the same time, the user terminal 20 displays the video VD on the display of the user terminal 20, so that the user can check the streaming content of the live streamer LV.

[0019] The viewers AU1, AU2 of the user terminals 30a, 30b that request the platform to provide live streaming of the live streamer can receive streaming data corresponding to the live streaming via the network NW, play the received streaming data to display the videos VD1, VD2 on a display, and output the audio from a speaker, etc. The videos VD1, VD2 displayed on the user terminals 30a, 30b, respectively, are substantially the same as the videos recorded by the user terminals of the live streamer LV, and the audio output from the user terminals 30a, 30b is substantially the same as the audio recorded by the user terminals of the live streamer LV.

[0020] The recording of the live streamer on the user terminal 20 may be simultaneous with the playback of the streaming data on the user terminals 30a, 30b of the viewers AU1, AU2. When the viewer AU1 inputs a comment on the content of the live streamer LV to the user terminal 30a, the server 10 displays the comment on the user terminal 20 of the live streamer in real time, and also on the user terminals 30a, 30b of the viewers AU1, AU2. When the live streamer LV responds to the comment, the response is output as text, image, video, or audio from the user terminals 30a, 30b of the viewers AU1, AU2, thereby realizing communication between the live streamer LV and the viewers AU1, AU2. Thus, the live streaming system can realize two-way live streaming.

[0021] 2 is a block diagram showing the functions and configuration of the user terminal 20 shown in FIG. 1 according to an embodiment of the present disclosure. The user terminal 30 has the same functions and configuration as the user terminal 20. The blocks depicted in the block diagrams in this specification are implemented by hardware such as a device or mechanical part, such as a computer CPU, and software such as a computer program that represents functional blocks implemented by the cooperation of these elements. Therefore, it will be understood by those skilled in the art that the functional blocks can be implemented in various ways by combining hardware and software.

[0022] The live streamer LV and the viewer AU can download and install the live streaming application (live streaming app) of the present disclosure from a download site to the user terminals 20 and 30 via the network NW. Alternatively, the live streaming app may be pre-installed in the user terminals 20 and 30. By executing live streaming by the user terminals 20 and 30, the user terminals 20 and 30 can communicate with the server 10 via the network NW and realize a plurality of functions. The functions realized by executing the live streaming app by the user terminals 20 and 30 (more specifically, a processor such as a CPU) are described below as functions of the user terminals 20 and 30. The functions are basically functions that the live streaming app causes the user terminals 20 and 30 to realize. In some embodiments, these functions may be realized by transmitting them from the server 10 to the web browsers of the user terminals 20 and 30 via the network NW and executing them by a computer program of the web browser. The computer program may be written in a programming language such as HTML (Hyper Text Markup Language).

[0023] The user terminal 20 includes a streaming unit 100 and a viewing unit 200. In some embodiments, the streaming unit 100 is configured to record a user's audio and / or video data and generate streaming data to send to the server 10. The viewing unit 200 is configured to receive and play streaming data from the server 10. In some embodiments, a user can activate the streaming unit 100 at the time of broadcasting or activate the viewing unit 200 when viewing a stream. In some embodiments, the user terminal that activates the streaming unit 100 can be referred to as a live streamer or the user terminal that generates streaming data. The user terminal that activates the viewing unit 200 can be referred to as a viewer or the user terminal that plays the streaming data.

[0024] The streaming unit 100 may include a video control unit 102, an audio control unit 104, a distribution unit 106, and a UI control unit 108. The video control unit 102 may be connected to a camera (not shown), and the video is controlled by the camera. The video control unit 102 can obtain the video data from the camera. The audio control unit 104 may be connected to a microphone (not shown), and the audio is controlled by the microphone. The audio control unit 104 can obtain the audio data from the microphone.

[0025] The delivery unit 106 receives streaming data including video data from the video control unit 102 and audio data from the audio control unit 104 and transmits the streaming data to the server 10 via the network NW. In some embodiments, the delivery unit 106 transmits the streaming data in real time, i.e., the generation of the streaming data from the video control unit 102 and the audio control unit 104 and the delivery by the delivery unit 106 are performed simultaneously.

[0026] The UI control unit 108 controls the UI of the live streamer. The UI control unit 108 is connected to a display (not shown) and configured to generate the streaming data for the distribution unit 106 to transmit, play and display on the display. The UI control unit 108 is configured to display an object to be operated or an object to be instructed on the display and to receive a tap input from the live streamer.

[0027] The viewing unit 200 may include a UI control unit 202, a rendering unit 204, an input sending unit 206, a cache unit 208, a queue unit 210, a cache DB 250, a data queue DB 252, a retry time lookup table 254, and a refresh time lookup table 256. The viewing unit 200 is configured to receive streaming data from the server 10 via a network NW.

[0028] The UI control unit 202 controls the UI of the viewer. The UI control unit 202 is connected to a display (not shown) and / or a speaker (not shown) and configured to display video on the display and output audio from the speaker by playing the streaming data. In some embodiments, outputting video on the display and outputting audio from the speaker may be referred to as "playing streaming data". The UI control unit 202 is connected to an input unit such as a touch panel, a keyboard, a display, etc., and can obtain input from a user.

[0029] The rendering unit 204 may be configured to render streaming data from the server 10 and frame images. The frame images may include user interface objects for accepting input from a user, comments entered by a viewer, and data received from the server 10. The input sending unit 206 is configured to receive the user input from the UI control unit 202 and send it to the server 10 via the network NW.

[0030] In some embodiments, the user input may be clicking an object on the screen of the user terminal, such as selecting a live stream, entering a comment, sending a gift, following or unfollowing a user, voting in an event, playing a game, etc. For example, the input sending unit 206 may generate gift information and send it to the server 10 via the Internet NW when the user terminal of a viewer clicks a gift object on the screen to send a gift to the live streamer.

[0031] The cache unit 208 may be configured to process cache data. For example, the cache unit 208 may store network data from the server 10 as cache data in the cache DB 250. The cache unit 208 may retrieve the cache data from the cache DB 250 for display on the user terminal of the user. In some embodiments, the cache unit 208 may first display available cache data when the user requests data via the user terminal. In some embodiments, the cache unit 208 may display the cache data if the network data from the server 10 is not available. In some embodiments, the cache unit 208 may update, delete, modify, etc. the cache data.

[0032] The queue unit 210 may be configured to process downloads of network data from the server 10. In some embodiments, the queue unit 210 may control queuing of download data in the data queue DB 252. More specifically, when the user requests data from the server 10, the queue unit 210 may store a data queue of download data in the data queue DB 252 and control the download of the data.

[0033] The user may use the user terminal to request data from the server 10. For example, if the user terminal is a smartphone, the user may request live streaming data via an app or the like. If the user terminal is a desktop PC, the user may request live streaming data via a browser or the like. In some embodiments, the user may request multiple data from a live streaming platform. For example, the user may request live streaming data in a streaming room and leaderboard data for an event. In some embodiments, the requested data may be any available data from a live streaming service.

[0034] When the user accesses a page, such as a leaderboard page, the queue unit 210 may initiate a request for data from the server 10. The leaderboard may include a number of pieces of data, such as a description of the event, rules, a leaderboard, etc. The leaderboard may further include the user's ranking, a current score achieved, etc. In some embodiments, the current score may include sub-pages showing the composition of the score, bonuses obtained from previous rounds, etc.

[0035] 3 is a block diagram of the server 10 according to some embodiments of the present disclosure. The server 10 may include a streaming information unit 302, a relay unit 304, a processing unit 306, a stream DB 320, a user DB 322, and a data DB 324.

[0036] The streaming information unit 302 receives a request for live streaming from the user terminal 20 of the live streamer via the network NW. Upon receiving the request, the streaming information unit 302 registers the information of the live streaming in the stream DB 320. In some embodiments, the information of the live streaming may be a stream ID of the live streaming and / or a live streamer ID of the live streamer corresponding to the live streaming.

[0037] When receiving a request for providing the information of the live streaming from the viewing unit 200 of the user terminal 30 via the network NW from the viewer, the streaming information unit 302 refers to the stream DB 320 and generates a list of available live streaming. Then, the streaming information unit 302 transmits the list to the user terminal 30 via the network NW. The UI control unit 202 of the user terminal 30 generates a live streaming selection screen based on the list and displays the list on the display of the user terminal 30.

[0038] When the input sending unit 206 of the user terminal 30 receives the selection of live streaming by the viewer on the live streaming selection screen, it generates a delivery request including the stream ID of the selected live streaming, and sends it to the server 10 via the network. The streaming information unit 302 can start providing the live streaming specified by the stream ID in the delivery request to the user terminal 30. The streaming information unit 302 can update the stream DB 320 and add the viewer ID of the viewer of the user terminal 30 to the live streamer ID of the stream ID.

[0039] The relay unit 304 can relay the transmission of live streaming from the user terminal 20 of the live streamer to the user terminal 30 of the viewer in the live streaming started by the streaming information unit 302. The relay unit 304 can receive a signal indicating a user input from the viewer from the input transmission unit 206 during playback of streaming data. The signal indicating the user input may be an object designation signal indicating designation of an object to be displayed on the display of the user terminal 30. The object designation signal may include a viewer ID of the viewer, a live streamer ID of a live streamer who delivers the live streaming being viewed by the viewer, and an object ID designated by the object. If the object is a gift or the like, the object ID may be a gift ID or the like. Similarly, the relay unit 304 can receive a signal indicating a user input of the live streamer, such as the object designation signal, from the streaming unit 100 of the user terminal 20 during playback of streaming data.

[0040] The processing unit 306 is configured to process the request according to an operation from the user terminal of the user. For example, the user may click an event list button to make a request on the event list. When the relay unit 304 receives the request, the processing unit 306 may refer to the data DB 324 to obtain the event list, and the processing unit 306 and the relay unit 304 may further send the event list to the user terminal of the user.

[0041] Fig. 4 is a table showing an example data structure of the stream DB 320 in Fig. 3. The stream DB 320 holds information about currently running live streams. The stream DB 320 stores a stream ID for identifying a live stream on a live streaming platform provided by the live streaming system 1, a live streamer ID for identifying a live streamer providing the live stream, and a viewer ID for identifying a viewer of the live stream, in association with each other.

[0042] 5 is a table showing an example data structure of the user DB 322 of FIG. 3. The user DB 322 holds information about users. The user DB 322 stores a user ID for identifying a user, a point for identifying points accumulated by the user, a level for identifying the level of the user, and a status for identifying the status of the user, in association with each other. The point is an electronic value circulating within the live streaming platform. The level may be an indicator of the amount of activity or engagement of the user on the live streaming platform. The status may be the identity or membership status of the user on the live streaming platform.

[0043] FIG. 6 is a table showing an exemplary data structure of the data DB 324 of FIG. 3. The data DB 324 holds data information related to live streams on the live streaming platform. In some embodiments, the data in the server 10 may be any data available on the live streaming platform. Here, an example of leaderboard data for an event will be described. The data DB 324 stores a data ID for identifying data on the live streaming platform provided by the live streaming system 1 and a leaderboard ID for identifying the leaderboard of the data, in association with each other. The data DB 324 also stores user IDs, ranks, and scores for identifying users participating in the leaderboard, and ranks and scores corresponding to the users, in association with each other.

[0044] In some embodiments, the queue unit 210 may download data from the server 10 all at once or in batches. For example, if the server 10 has 3,000 data entries, the queue unit 210 may download them in batches of 100 at a time. In some embodiments, the queue unit 210 may determine the order of data download. When the queue unit 210 gains access to a leaderboard page, it may request the leaderboard data. For example, the queue unit 210 may download data for the top 10 users on the leaderboard and display the leaderboard information on the viewer's device.

[0045] 7 is a table showing an exemplary data structure of the cache DB 250 of FIG 2. The cache DB 250 holds cache data of data from the server 10. The cache DB 250 stores a cache ID and a data ID for identifying the cache data and the corresponding data from the server 10, a time tag for identifying time information of the cache data, and a URL for identifying the location of the cache data, in association with each other. In some embodiments, the cache DB 250 may include other detailed information of each data entry.

[0046] 8 is a table showing an exemplary data structure of the data queue DB 252 of FIG. 2. The data queue DB 252 holds information about a queue of data downloaded by the user terminal of the user. The data queue DB 252 stores a queue ID for identifying the queue, progress, and response of the download from the server 10, the progress, and the response, in association with each other. The data queue DB 252 also stores a retry count that specifies the number of requests for the corresponding data, and a previous response time that specifies the time it took the server 10 to respond to a request from the user terminal of the user, in association with each other. In some embodiments, the response time may be measured based on the elapsed time from when a request is made until the server sends a response back to the user terminal of the user.

[0047] In some embodiments, the progress may be a ratio of current data entries to total data entries, indicating the current progress of the download. In some embodiments, the progress may include progress for each entry of data or each batch of data (e.g., progress for data entries 1-100, 101-200, etc.). In some embodiments, the last response time may be saved when the request is successful. In some embodiments, the last response time may be saved for reference when the request fails. In some embodiments, for a "failed" response due to "no response", a threshold for determining "no response" or the like may be used as the last response time.

[0048] In some embodiments, the response may be "success" or "failure." A "success" response may indicate that the requested data was successfully retrieved, processed, and returned to the user terminal without any errors or problems. Meanwhile, a "failure" response may indicate that the requested data was not successfully retrieved, processed, and returned to the user terminal due to an error or problem. In some embodiments, the reason for the "failure" response or an error code may also be included in the response.

[0049] The reason for the response of "failure" may be server unavailability, server load, network issues, etc. For example, if the server fails to provide a response within a reasonable or expected time, the response may be "failure" and the reason may be "non-response", etc. In some embodiments, the reasonable or expected time frame for a response to the request may be up to 3 seconds, 5 seconds, or flexibly determined according to actual needs. In some embodiments, the response may be indicated as "waiting", indicating that the request is in a processing stage, awaiting a response, etc.

[0050] 9 to 11 are exemplary screen images of a live streaming room screen 600 displayed on the display of the live streamer's user terminal 20 or the viewer's user terminal 30. FIG.

[0051] An exemplary event page 334 is shown in FIG. 9. The viewer or live streamer may click an on-screen button to request an event listing. Once an event is selected, a corresponding event page 334 may be displayed on the user terminal. As shown in FIG. 9, the event page 334 may include a title 336, a banner 338, a description 340, and a ranking 342. In some embodiments, the event page 334 may include tabs 344 indicating the current stage of the event, such as round 1, round 2, finals, etc.

[0052] The user may click on rankings 342 to check current or past leaderboards for the event. An exemplary leaderboard page for rankings 342 is shown in FIGS. 10 and 11. In some embodiments, the leaderboard page 346 may display the user's ranking and corresponding score S. In some embodiments, detailed information DI for the score S may be displayed under each user, detailing information about the score S. For example, the detailed information DI may include score bonuses, score combinations, and other related information.

[0053] In some embodiments, the live streamer and viewers may access the leaderboard page 346 to check the current leaderboard. If multiple users access the leaderboard page 346 and request data from the server 10, the server may be overloaded. If the user fails to receive data from the server 10, the leaderboard page 346 may be blank, which may result in poor user experience. Therefore, the user terminal first checks whether the requested data is available in the cached data DB 250. Regardless of whether the cached data is displayed, the terminal may further request network data from the server 10.

[0054] Some events are very competitive. In particular, the last certain time before the end of the event is always considered to be the most thrilling time of the event. The viewers always gather with the livestreamer and support the livestreamer for the event. The viewers donate event gifts to the livestreamer and wait until the end of the event to make their favorite livestreamer win the event or achieve the reward threshold. Therefore, the information on the leaderboard page 346 is very important and needs to be dynamically retrieved and refreshed in real time.

[0055] In some embodiments, cached data of the leaderboard page 346 may be displayed on the user terminal, as shown in Figure 10. In some embodiments, network data from the server 10 may be displayed and refreshed in real time, as shown in Figure 11. According to this embodiment, the user may track the current rankings of the leaderboard page 346 and contribute to the victory of their favorite live streamer. Methods of displaying cached data, displaying network data, and refreshing the data are described below.

[0056] Figures 12 to 15 are flowcharts showing steps of an application startup process in the user terminals 20 and 30. More specifically, Figures 12 and 13 show one embodiment of the live streaming system 1, and Figures 14 and 15 show another embodiment of the live streaming system 1. The embodiments of Figures 12 and 13 may be compared with the embodiments of Figures 14 and 15 and referred to as related art.

[0057] 12, 13, 14, and 15, the live streamer may open the event page 334 or the leaderboard page 346 to check the description of the event or the leaderboard, and the user terminal may collect a request list for data requests to the server 10 (S502). After collecting the request list, the queue unit 210 refers to the cache DB 250 to check whether there is a latest cache for the data in the request list (S504).

[0058] If there is a latest cache for the data in the request list ("Yes (True)" in S504), the cache unit 208 may process the cache data (S508). For example, the cache unit 208 may obtain the latest cache data from the cache DB 250. In some embodiments, the rendering unit 204 may further process the leaderboard data (S510). For example, the rendering unit 204 may render the latest cache data on a frame image and display it on the user terminal of the user. According to this embodiment, the user can see the cache data instead of a blank page, which may improve the user experience.

[0059] More specifically, if there is available cache data, the corresponding cache data may be retrieved immediately. At this point, the screen displays the cache data of the previous request. For example, if 100 records were retrieved in the first request of the previous session, and 100 records are also requested in the current session, the screen first displays cache data of records 1 to 100 from the data of the previous session. In some embodiments, the remaining records of the cache data may be reserved, and a decision as to whether to display the remaining records of the cache data is made in a subsequent process. If there is no available cache data, the requested data is displayed when it is received from server 10.

[0060] After the leaderboard data is processed, the queue unit 210 requests network data from the server 10 based on the request list (S512). In some embodiments, if the request list does not have a current cache of the data ("No" in S506), the queue unit 210 may directly request data from the server 10 based on the request list (S512). In some embodiments, the cached data may be data from the cache DB 250. The network data may be data from the server 10. The leaderboard data is data displayed on the user terminal, and may be data from the cached data or network data.

[0061] For example, if the server 10 has 3,000 data entries, the queue unit 210 may download the data in several downloads, 100 entries at a time. The queue unit 210 may first request data for the 1st to 100th entries. Before the queue unit 210 requests data from the server 10, the cache unit 208 may check whether or not there is cache data for the 1st to 100th entries corresponding to the cache DB 250. If there is, the cache unit 208 may obtain the cache data, and the rendering unit 204 may display the cache of the 1st to 100th data on the user terminal. If there is not, the queue unit 210 may request data for the 1st to 100th entries from the server 10.

[0062] If the requests for all data are not successful ("No" in S514), that is, if the requests for the 1st to 100th data items are not successful, the queue unit 210 may determine whether the status of the request is "first read" (S518). The status of "first read" may refer to a state in which the request is disconnected at the beginning of the request. For example, if the requests for the 1st to 100th data items are not normally requested, this may be called "first read". This may refer to a state in which an error or problem occurs in the user terminal of the user.

[0063] If the request is "first read" ("Yes" in S518), the caching unit 208 may obtain the latest cache of the requested data (S520). For example, the caching unit 208 may obtain the latest cache data of the 1st to 100th data from the cache DB 250. The caching unit 208 may further process the remaining cache data and set the parameter of "first read" to "No" (S522). For example, the caching unit 208 may further obtain the cache data of the 101st to 3,000th data from the cache DB 250. The rendering unit 204 may further process all the leaderboard data, for example by displaying all the cached data on the user terminal (S524).

[0064] If the request is not "first read" ("No" in S518), the queue unit 210 may wait for a retry time (S526) and may request data from the server 10 again based on the request list (S512). Here, the retry time may refer to the time until the queue unit 210 makes a next network data request to the server 10. In some embodiments, as shown in FIG. 12, the retry time may be a fixed time such as 1 second. In some embodiments, as shown in FIG. 14, FIG. 16, and FIG. 17, the retry time may not be a fixed time. In some embodiments, the retry time may be flexibly determined according to actual needs.

[0065] FIG. 16 is a flowchart showing a process of determining a retry time, and FIG. 17 is a table showing an example data structure of the retry time lookup table 254 of FIG. 2. In some embodiments, if the request is not a "first read" ("No" in S518), the determination of the retry time may be initiated. As shown in FIG. 16, a parameter of "retry count" may be incremented by 1 (S602). Here, the "retry count" may refer to the number of retries that the queue unit 210 requests data from the server 10. The queue unit 210 may further obtain the retry time based on the number of retries (S604). After that, the queue unit 210 may wait for the retry time (S606) and further request data from the server 10.

[0066] The retry time lookup table 254 may be configured to store a relationship between the retry count and the retry time. As shown in the example of FIG. 17, the retry time lookup table 254 may include retry counts and corresponding retry times in association with each other. In some embodiments, a range or value of the retry count may correspond to a value of the retry time. For example, retry counts "1-10", "11-20", "21-30" may correspond to retry times "1", "5", "9" seconds, etc. In some embodiments, the retry count may be determined based on a response from the server 10. For example, if the response from the server 10 is not "success" or is "failure" (meaning that the terminal has a problem obtaining data), the retry count may be incremented by one.

[0067] In some embodiments, the retry time is a fixed value or increases with an increase in the number of retry attempts. In some embodiments, the retry time increases based on the number of times data is requested from the server 10. In some embodiments, the retry time may be proportional to the number of retry attempts. In some embodiments, the retry time may follow an arithmetic progression, a geometric progression, a Fibonacci sequence, etc., depending on the number of retry attempts. In some embodiments, the relationship between the number of retry attempts and the retry time may be flexibly determined according to actual needs.

[0068] According to this embodiment, the retry time to wait before initiating the next retry for the request is determined based on the accumulated retry count. As the retry count increases (indicating multiple failed attempts with the backend), the retry time becomes a larger value, thereby extending the retry interval, thus helping to reduce the load on the backend.

[0069] More specifically, there are three scenarios: First, if the data request is successful, the network of the user terminal may be referred to as an ideal connection or a weak connection state. In this situation, the cached data of the first part of the data from 1 to 100 may be displayed immediately at the start. The user terminal may then process the network data by updating the leaderboard, synchronizing the cached data, updating the screen every 100 data entries, etc. The user terminal may further add the returned data to the leaderboard and continue to display subsequent data until the cursor is no longer on the response.

[0070] In some embodiments, the user terminal may be able to retrieve the data even when the network is in an ideal or weak connection state, but the data may be retrieved more slowly when the network is in a weak connection state. The data retrieved from the first to the 100th items may be slower when the network is in a weak connection state, but the data may still be retrieved by the user terminal, and the user may not have scrolled down to see the subsequent data yet, so this is not a problem.

[0071] Secondly, if the data request fails at the beginning of the data request, the network of the user terminal may be referred to as a "start-time network disconnected" state. In this situation, all of the cached data of the first part of the data from 1 to 100 and another part of the data from 101 to 3,000 may be displayed first and immediately. In some embodiments, the request is sent again to simulate a data retrieval operation. In most cases, the API request fails. Even if the request is successful, the cached data is used.

[0072] Third, if the data request fails during data acquisition, the network of the user terminal may be referred to as a "network disconnected during data acquisition" state. For example, if the user terminal requests data from 101 to 200 and the request fails, it is not a "first read". After the data request fails, a new request is sent after a retry time until it is successful. If it is successful, the cache is updated and synchronized. For example, if the request for data from 501 to 600 fails, the screen displays records up to 500. Meanwhile, the request for data from 501 to 600 continues to be retried until it is successful. Upon receiving a successful response, the screen continues to process data from 501 to 600, and subsequent records may also be requested until there is no cursor in the response.

[0073] As shown again in FIG. 12, FIG. 13, FIG. 14, and FIG. 15, when the request for network data from the server 10 is "successful" ("Yes" in S528), the cache unit 208 may set the cache in the cache DB 250 (S530). In some embodiments, when all requests for data from the server 10 are successful ("Yes" in S514), that is, when the requests for data 1 to 100 are successful, the queue unit 210 may process all the network data and set the "First Read" parameter to "No" (False) (S516). Here, the process of processing the network data or the process of processing the cache data may refer to temporarily storing the data without setting or updating the leaderboard on the user terminal. Meanwhile, processing the leaderboard data may refer to setting or updating the leaderboard on the user terminal. In some embodiments, as shown in FIG. 15, the queue unit 210 may set the number of retries to 0 and store the response time (S531). In some embodiments, the response time may be used to determine the refresh time of the data, as described in more detail below.

[0074] After all the network data is processed, the queue unit 210 may further determine whether to refresh the data (S532). In some embodiments, the determining factor for whether to refresh the data may be based on the timeliness of the leaderboard data. For example, the leaderboard for an offline event may be refreshed frequently to reflect the latest rankings of users. Meanwhile, the past leaderboard may not need to be refreshed at all because the score and ranking calculations have already been completed. In some embodiments, the leaderboard for an online event does not need to be refreshed frequently during the event, but may need to be refreshed frequently, such as one hour before the end of the event. In some embodiments, the refreshing of the data may be determined according to actual needs.

[0075] If the data does not need to be refreshed (S532: No), the rendering unit 204 may further process all the leaderboard data, for example by displaying all the network data on the user terminal (S534). When the network data or cache data becomes available, the leaderboard data may be displayed sequentially on the user terminal. In some embodiments, the queue unit 210 may further determine whether the API request includes a cursor (S536). Here, the cursor functions as a special marker or pointer that indicates the position or identifier of the data to be retrieved next. If a subsequent portion of data is available, the cursor may be included in the response from the server 10. For example, if the data requests from 1 to 100 are successful, the queue unit 210 may receive a cursor indicating that there is subsequent data from 101 to 200, etc. Also, if the data requests from 2901 to 3000 are successful, the cursor may not be returned to the queue unit 210.

[0076] In some embodiments, if the API request includes a cursor (YES in S536), the flow may return to the beginning of Figure 12 or 14, and the user terminal may collect a request list for data requests to the server 10 (S502). If the API request does not include a cursor (NO in S536), the flow may end.

[0077] If the data needs to be refreshed ("Yes" in S532), the queue unit 210 may further determine whether or not the parameter "total data acquisition count" is 0 (S538). Here, the parameter "total data acquisition count" may refer to the number of times all data has been acquired. For example, if there are 3,000 entry data in the server 10 and all 3,000 have been requested once, the parameter "total data acquisition count" may be incremented by 1. On the other hand, if all 3,000 entry data have not been requested at least once, the parameter "total data acquisition count" may be 0.

[0078] In some embodiments, if the parameter "total data acquisition count" is 0 (S538: Yes), the rendering unit 204 may further process all the leaderboard data (S540), for example, by displaying all the network data on the user terminal. The parameter "total data acquisition count" being 0 may indicate that all the data has not yet been fully requested. As the network data or cache data becomes available, the leaderboard data may be sequentially displayed on the user terminal. For example, the queue unit 201 and the rendering unit 204 may sequentially request and display data 1 to 100, data 101 to 200, and so on.

[0079] In some embodiments, the queue unit 210 may further determine whether the API request includes a cursor (S542). In some embodiments, if the API request includes a cursor (YES in S542), the flow may return to the beginning of FIG. 12 or FIG. 14, and the user terminal may collect a request list for data requests to the server 10 (S502). If the API request does not include a cursor (NO in S542), the parameter of "total data acquisition count" may be increased by 1 (S544), which means that all data has been acquired at least once.

[0080] In some embodiments, if the parameter of "total data acquisition count" is not 0 ("No" in S538), the queue unit 210 may further determine whether the API request includes a cursor (S546). In some embodiments, if the API request includes a cursor ("Yes" in S546), the flow may return to the beginning of FIG. 12 or FIG. 14, and the user terminal may collect a request list for data requests to the server 10 (S502).

[0081] In some embodiments, if the API request does not include a cursor (NO in S546), the rendering unit 204 may further process all the leaderboard data, for example, by displaying all the network data on the user terminal (S548). Furthermore, the parameter "total data acquisition count" may be incremented by 1 (S544). The parameter "total data acquisition count" not being 0 may indicate that all the data has been completely requested, or may indicate that the previous complete data has been displayed on the leaderboard. In this case, new leaderboard data may be displayed on the user terminal once all the data has been completely requested.

[0082] More specifically, if all data has not been obtained at least once, the rendering unit 204 may display the data in batches. For example, the rendering unit 204 may sequentially display data 1 to 100, data 101 to 200, and so on, on the user terminal. On the other hand, if all data has been obtained at least once, the rendering unit 204 may display the data until the API request does not include a cursor. For example, the rendering unit 204 may display all data 1 to 3000 at once if all data has been obtained at least once and the response from the server 10 does not include a cursor.

[0083] In some embodiments, the queue unit 210 may further refresh the data. In some embodiments, the queue unit 210 may clear the temporarily stored network data and cache data in preparation for data refresh, for example, by setting the network data and cache data to empty and resetting a "first read" parameter to "yes" (True) (S550). In some embodiments, the flow may return to the beginning of FIG. 12 or FIG. 14, and a request list may be collected to refresh data from the server 10 (S502).

[0084] In some embodiments, the queue unit 210 may wait a refresh time before starting to refresh the data, as shown in FIG. 15 (S551). Here, the refresh time may be referred to as an interval or frequency at which data is updated or refreshed. It represents the time between successive updates or refreshes to ensure the accuracy and validity of data. In some embodiments, the refresh time may be a fixed or non-fixed time interval. In some embodiments, the refresh time is a fixed value or increases with the increase of the previous response time. In some embodiments, the refresh time may be flexibly determined according to actual needs.

[0085] Fig. 18 is a flow chart showing a process of determining a refresh time, and Fig. 19 is a table showing an example data structure of the refresh time lookup table 256 of Fig. 2. As shown in Fig. 18, the queue unit 210 may obtain the refresh time based on the previous response time from the server 10 (S612). Here, the previous response time may refer to the response time stored in step S531 of Fig. 15. Thereafter, the queue unit 210 may wait for the refresh time (S614) and further request data for refresh from the server 10.

[0086] The refresh time lookup table 256 may be configured to store the relationship between the response time and the refresh time. In some embodiments, the refresh time lookup table 256 may include the response time and its corresponding refresh time in association with each other. When the request for the data from the server 10 is successful, the queue unit 210 may store the response time from the server 10, for example in the data queue DB 252. In some embodiments, the response time may refer to the time from sending a request from the user terminal to receiving a response from the server 10.

[0087] In some embodiments, the response time and the refresh time may be determined by a lookup table, such as the refresh time lookup table 256. As shown in FIG. 19, a range of response times may correspond to refresh time values. For example, the response time ranges "0-1", "1-5", "5-9" may correspond to refresh time values ​​of "5" seconds, "9" seconds, "17" seconds, etc. In some embodiments, the refresh time may increase based on an increase in the previous response time when requesting data from the server 10. In some embodiments, the refresh time may be proportional to the response time. In some embodiments, the refresh time may follow an arithmetic progression, a geometric progression, a Fibonacci progression, etc., depending on the response time. In some embodiments, the relationship between the response time and the refresh time may be flexibly determined according to actual needs.

[0088] According to this embodiment, the refresh time to wait before refreshing the data is determined based on the previous response time. As the response time increases (indicating a slower backend), the refresh time obtained as a function of the refresh time becomes larger. Therefore, by using this refresh time, the interval between refreshes can be increased and the load on the backend can be reduced.

[0089] In some embodiments, after all cached data is displayed on the user terminal in S524, the queue unit 210 may further determine whether to refresh the data (S552). If the data does not need to be refreshed (S552: No), the flow may be terminated. If the data needs to be refreshed (S532: Yes), the queue unit 210 may erase the temporarily stored network data and cache data (S554), for example, by setting the network data and cache data to empty and resetting the parameter of "first read" to "Yes" (True), in preparation for data refresh. In some embodiments, the refresh time may be a fixed or non-fixed time interval. In some embodiments, the flow may return to the beginning of FIG. 12 or FIG. 14, and a request list may be collected to refresh data from the server 10 (S502). In some embodiments, the queue unit 210 may also wait a refresh time (S551) before starting to refresh the data, as shown in FIG. 15.

[0090] In some embodiments, multiple leaderboard data may be requested from the user terminal at the same time. When the flow returns to step S502, there are two scenarios in which the request list is collected. First, it is the first data request, including requests after the "first read" parameter is reset. Second, the data request is not fully completed and there is a returned cursor. Otherwise, there is no need to collect the request list, which returns null and is finally filtered.

[0091] According to the above embodiment, the retry time and the refresh time may be determined by the terminal side, not by the server side. The terminal may determine the retry time and the refresh time according to the response from the server 10 and the response time. That is, all the decisions are made by the terminal side, not by the server side. Therefore, the timing of requesting and displaying data can be optimized, and the load on the server can be reduced.

[0092] According to this embodiment, the timing of requesting data from the server 10 can be optimized. For example, when a backend problem is encountered and data cannot be acquired, a retry time can be set, and the terminal can wait for the retry time before attempting to acquire data the next time. Furthermore, when a backend problem is encountered, it always indicates that there is a problem with normal data acquisition. Repeated queries to the backend may further accumulate the burden on the backend. Therefore, the burden on the backend can be reduced by setting the retry time according to the number of retries.

[0093] According to this embodiment, the timing of refreshing data from the server 10 can also be optimized. For example, the refresh time may be set based on the previous response time from the backend, and the terminal may wait for the refresh time before attempting the next data refresh. Furthermore, repeated data refresh from the backend without considering the previous response time may further accumulate the burden on the backend. Therefore, setting the refresh time based on the previous response time can also reduce the burden on the backend.

[0094] According to the present disclosure, instead of displaying a blank screen, requested data, such as leaderboard data, can be smoothly displayed on a user terminal regardless of network conditions, potentially improving user experience.

[0095] Fig. 20 is a schematic block diagram of a system configuration and computer hardware for executing processing according to some embodiments of the present disclosure. The information processing device 900 in Fig. 20 is configured to realize, for example, the server 10 and the user terminals 20 and 30 according to some embodiments of the present disclosure.

[0096] The information processing device 900 includes a CPU 901, a read-only memory (ROM) 903, and a random access memory (RAM) 905. Furthermore, the information processing device 900 may include a host bus 907, a bridge 909, an external bus 911, an interface 913, an input unit 915, an output unit 917, a storage unit 919, a drive 921, a connection port 925, and a communication unit 929. The information processing device 900 may include an imaging device (not shown) such as a camera. The information processing device 900 may include a processing circuit such as a digital signal processor (DSP) or an application specific integrated circuit (ASIC) instead of or in addition to the CPU 901.

[0097] The CPU 901 functions as an arithmetic processing device and a control device, and controls the overall operation of the information processing device 900 or a part of the operation according to various programs recorded in the ROM 903, the RAM 905, the storage unit 919, or the removable recording medium 923. For example, the CPU 901 controls the overall operation of each functional unit included in the server 10 and the user terminals 20 and 30 of the above-mentioned embodiment. The ROM 903 stores programs and operation parameters used by the CPU 901. The RAM 905 transiently stores programs used when the CPU 901 executes programs and parameters that change appropriately when the programs are executed. The CPU 901, the ROM 903, and the RAM 905 are connected to each other via a host bus 907 consisting of an internal bus such as a CPU bus. The host bus 907 is connected to an external bus 911 such as a peripheral component interconnect / interface (PCI) bus via the bridge 909.

[0098] The input unit 915 is a device operated by a user, such as a mouse, a keyboard, a touch panel, a button, a switch, or a lever. The input unit 915 may be a device that converts a physical quantity into an electric signal, such as an audio sensor (such as a microphone), an acceleration sensor, a tilt sensor, an infrared sensor, a depth sensor, a temperature sensor, or a humidity sensor. The input unit 915 may be, for example, a remote control device that uses infrared rays or another type of radio wave. Alternatively, the input unit 915 may be an external connection terminal 927 such as a mobile phone that supports the operation of the information processing device 900. The input unit 915 includes an input control circuit that generates an input signal based on information input by a user and outputs the generated input signal to the CPU 901. The user operates the input unit 915 to input various data and instruct the information processing device 900 to perform a processing operation.

[0099] The output unit 917 includes a device that can visually or audibly notify the user of the acquired information. The output unit 917 may be, for example, a display device such as an LCD, a PDP, or an OLED, an audio output device such as a speaker or a headphone, a printer, etc. The output unit 917 outputs the results obtained by the processing executed by the information processing device 900 in the form of text, video such as an image, or sound such as voice.

[0100] The storage unit 919 is a data storage device and is an example of a storage unit of the information processing device 900. The storage unit 919 includes, for example, a magnetic storage device such as a hard disk drive (HDD), a semiconductor storage device, an optical storage device, a magneto-optical storage device, etc. The storage unit 919 stores programs and various data executed by the CPU 901, and various data acquired from the outside.

[0101] The drive 921 is a reader / writer of a removable recording medium 923 such as a magnetic disk, an optical disk, a magneto-optical disk, or a semiconductor memory, and is built into or externally attached to the information processing device 900. The drive 921 reads out information recorded on the attached removable recording medium 923, and outputs it to the RAM 905. The drive 921 writes information to the attached removable recording medium 923.

[0102] The connection port 925 is a port used for directly connecting a device to the information processing device 900. The connection port 925 may be, for example, a USB (Universal Serial Bus) port, an IEEE1394 port, or a SCSI (Small Computer System Interface) port. The connection port 925 may be an RS-232C port, an optical audio terminal, an HDMI (High Definition Multimedia Interface (registered trademark)) port, or the like. By connecting an external connection terminal 927 to the connection port 925, various data can be exchanged between the information processing device 900 and the external connection terminal 927.

[0103] The communication unit 929 is, for example, a communication interface including a communication device for connecting to a communication network NW. The communication unit 929 may be, for example, a communication card for a wired or wireless local area network (LAN), Bluetooth (registered trademark), or Wireless USB (WUSB).

[0104] The communication unit 929 may be, for example, a router for optical communication, a router for ADSL (asymmetric digital subscriber line), or a modem for various types of communication. For example, the communication unit 929 transmits and receives signals on the Internet and transmits and receives signals with other communication devices using a predetermined protocol such as TCP / IP. The communication network NW to which the communication unit 929 is connected is a network established by a wired connection or a wireless connection. The communication network NW is, for example, the Internet, a home LAN, infrared communication, radio wave communication, or satellite communication.

[0105] The imaging device (not shown) is a device that captures real space and generates a captured image using an imaging element such as a CCD (charge-coupled device) or a CMOS (complementary metal-oxide semiconductor) and various members such as a lens for controlling the formation of a subject image on the imaging element. The imaging device may capture still images or moving images.

[0106] The live streaming system 1 of the present disclosure has been described above with reference to the embodiments. The above-mentioned embodiments are described merely for the purpose of explanation. Rather, those skilled in the art can easily conceive of various combinations of the above-mentioned components and processes of the embodiments and various modifications, which are also included in the technical scope of the present disclosure.

[0107] The steps described in this specification, particularly the steps described using flow charts or flow charts, may include some of the steps constituting the steps, may include steps not explicitly included in the steps constituting the steps, and / or may rearrange the order of the steps. Such omissions, additions, and rearrangements of steps are also included in the scope of the present disclosure as long as they do not deviate from the gist of the present disclosure.

[0108] In some embodiments, at least a part of the functions performed by the server 10 may be performed by a device other than the server 10, for example, the user terminal 20 or 30. In some embodiments, at least a part of the functions performed by the user terminal 20 or 30 may be performed by a device other than the user terminal 20 or 30, for example, the server 10. In some embodiments, rendering of frame images may be performed by the user terminal of a viewer, a server, a live streamer, or the like.

[0109] Furthermore, the system or method described in the above embodiments may be provided in a non-transitory computer-readable storage device such as a solid-state storage device, an optical disk storage device, a magnetic disk storage device, or a computer program product. Alternatively, the program may be downloaded from a server via the Internet.

[0110] Although the technical contents and features of the present disclosure have been described above, those skilled in the art can still make many variations and modifications without departing from the teachings and disclosure of the present disclosure. Therefore, the scope of the present disclosure is not limited to the embodiments already disclosed, but is within the scope of the following claims, including other variations and modifications that do not depart from the present disclosure. [Explanation of symbols]

[0111] 1. Live Streaming System 10 Server 20 User terminal 100 Streaming Units 102 Video control unit 104 Audio control unit 106 Delivery Unit 108 UI control unit 200 viewing units 202 UI control unit 204 Rendering Units 206 Input Transmission Unit 208 Cache Unit 210 Queue Unit 250 Cache DB 252 Data Queue DB 254 Retry Time Lookup Table 256 refresh time lookup table 30, 30a, 30b User terminal 302 Streaming Information Unit 304 Relay unit 306 Processing Unit 320 Stream DB 322 User DB 324 Data DB 334 Event Page 336 Titles 338 Banner 340 Explanation 342 Ranking 344 tabs 346 Leaderboard Page 900 Information processing device 901 CPU 903 ROM 905 RAM 907 Host Bus 909 Bridge 911 External Bus 913 Interface 915 Input Unit 917 Output Unit 919 Storage Unit 921 Drive 923 Removable Recording Media 925 Connection Port 927 External connection terminal 929 Communication Unit LS Live Streaming LV Live Streamer NW Network SP Specific part AU1, AU2 viewers S502, S504, S506, S508, S510,... Process S602, S604, S606, S612, S614,... Process VD, VD1, VD2 Video

Claims

1. 1. A terminal for processing data in a live streaming platform, comprising: one or more processors, the one or more processors executing machine-readable instructions to: The ability to send requests for pieces of data; receiving a response to said request; setting a retry count in response to the response being a failure and the portion of the data not being a first portion; determining a retry time based on the set number of retry attempts; sending a next request for said portion of data after said retry period; A terminal characterized by executing

2. The terminal of claim 1 , further characterized in that the retry time is a fixed value or increases with an increase in the number of retry attempts.

3. In response to the request being unsuccessful and the portion of the data being the first portion, obtaining cache data of the portion of the data and the remaining portion of the data; displaying the cache data on the terminal; The terminal of claim 1 further characterized in that:

4. storing a time of a previous response from the server in response to the response being successful; determining a refresh time based on the previous response time; refreshing a portion of the data after the refresh time; The terminal of claim 1 further characterized in that:

5. The terminal according to claim 4, characterized in that the refresh time is a fixed value or increases with an increase in the previous response time.

6. determining whether to refresh the portion of the data in response to the response being successful; displaying the portion of the data in response to not refreshing the portion of the data; sending a request for a next portion of data in response to the cursor being in the response; The terminal of claim 1 further characterized in that:

7. determining whether to refresh the portion of the data in response to the response being successful; determining whether the entire portion of the data has been retrieved in response to refreshing the portion of the data; displaying a portion of the data in response to the entire portion of the data not being acquired; sending a request for a next portion of data in response to the cursor being in the response; The terminal of claim 1 further characterized in that:

8. determining whether to refresh the portion of the data in response to the response being successful; determining whether the entire portion of the data has been retrieved in response to refreshing the portion of the data; displaying the entire portion of the data in response to the entire portion of the data having been obtained and the response being responsive to the absence of a cursor; The terminal of claim 1 further characterized in that:

9. 1. A method for processing data in a live streaming platform, comprising: sending a request for a portion of the data; receiving a response to said request; setting a retry count in response to the response being a failure and the portion of the data not being a first portion; determining a retry time based on the set number of retry attempts; sending a next request for the portion of data after the retry period.

10. A computer program, comprising: The ability to send requests for pieces of data; receiving a response to said request; setting a retry count in response to the response being a failure and the portion of the data not being a first portion; determining a retry time based on the set number of retry attempts; sending a next request for said portion of data after said retry period; A computer program product characterized by:

Images