Terminal, method, and computer program

Abstract

To provide a terminal, a method, and a computer program that reduce a server load, improve the responsiveness of user terminals, minimize user misunderstandings, and improve the user experience by dynamically determining a cache strategy for data processing from a network or cache.SOLUTION: A terminal for processing data on a live streaming platform includes one or more processors. The one or more processors execute machine-readable instructions to execute steps for requesting data from the live streaming platform and determining a cache strategy on the basis of the timing of the data. The cache strategy may be determined dynamically before, during, or after an event.SELECTED DRAWING: Figure 16

Description

Technical Field

[0001] The present disclosure relates to information and communication technologies, and more particularly to terminals, methods, and computer programs in live streaming.

Background Art

[0002] Some applications and platforms provide live streaming services that allow live streamers and viewers to communicate with each other. A live streamer may perform a performance to cheer up the viewers, or a viewer may donate or send a gift to support the live streamer. In addition, various campaigns and events are held to encourage more live streamers and viewers to participate in live streaming.

[0003] Since the communication between the live streamer and the viewer is real-time, the calculation and update of data such as the leaderboard are required to be fast and accurate. Patent Document 1 discloses a method of displaying the cache of the leaderboard to reduce the server load and improve the timeliness of information.

[0004] However, due to the network conditions of the user terminal, there are variations in the display of data. In addition, if a blank screen is displayed while the data is being requested, it may cause dissatisfaction among users and reduce the user experience. Therefore, how to process data from the network and cache is a very important issue.

Prior Art Documents

Patent Documents

[0005]

Patent Document 1

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, and the one or more processors execute machine-readable instructions to perform steps of requesting data from the live streaming platform and determining a caching strategy based on the timing of the data.

[0007] A method for processing data in a live streaming platform according to another embodiment of the present disclosure includes steps of requesting data from the live streaming platform and determining a caching strategy based on the timing of the data.

[0008] A computer program for processing data in a live streaming platform according to another embodiment of the present disclosure causes a terminal to perform functions of requesting data from the live streaming platform and determining a caching strategy based on the timing of the data.

[0009] According to the above embodiments, the caching strategy may be dynamically determined before an event, during an event, and after an event. There is a possibility that the server load is reduced and the responsiveness of the user terminal is improved. Also, automatic switching of the caching strategy may minimize user misunderstandings. Therefore, there is a possibility that the user experience is improved.

Brief Description of the Drawings

[0010]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16

Figure 17

MODE FOR CARRYING OUT THE INVENTION

[0011] Hereinafter, the same or similar components, members, procedures, or signals shown in each drawing are denoted by the same reference numerals in all the drawings, and redundant descriptions are accordingly omitted as appropriate. Also, some members that are not important in the description of each drawing are omitted.

[0012] The live streaming system 1 according to some embodiments of the present disclosure provides enhanced functions for facilitating communication and interaction among users. More specifically, it is a system that enables viewers and live streamers to enjoy themselves in a technical way.

[0013] FIG. 1 shows a schematic diagram showing the 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 real-time interaction between a live streamer (also referred to as a liver, streamer, or distributor) LV and viewers (also referred to as an audience) AU (AU1, AU2,...). As shown in FIG. 1, the live streaming system 1 can include a server 10, a user terminal 20, and user terminals 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 referred to as users. The server 10 can 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 machines, wearable terminals, or stationary computers such as desktop PCs. The server 10, the user terminal 20, and the user terminal 30 may be communicably connected by any type of wired or wireless network NW.

[0014] The live streaming system 1 involves an app provider (not shown) that provides the live streamer LV, the viewer AU, and the server 10. The live streamer LV can record content such as their own songs, talks, performances, game streaming, etc. on their user terminal 20 and upload it to the server 10, and can become a person who distributes the content in real time. In some embodiments, the live streamer LV can communicate with the viewer AU via the live streaming.

[0015] The app provider can provide a platform for the content to be live streamed on the server 10. In some embodiments, the app provider may be a media or manager that manages the real-time communication between the live streamer LV and the viewer AU. The viewer AU can access the platform through the user terminal 30 and select and view the content they want to watch. The viewer AU can perform operations for communicating with the live streamer, such as commenting on or cheering for the live streamer, through the user terminal 30. The live streamer who provides the content can respond to the comments and cheers. The response of the live streamer can be sent to the viewer AU by video and / or audio, etc. Therefore, the mutual communication between the live streamer and the viewer can be achieved.

[0016] As used herein, "live streaming" can refer to data transmission that enables an audience AU to substantially play and view content recorded by a live streamer LV via a user terminal 20 through the user terminal 30. In some embodiments, "live streaming" may also refer to the streaming realized by the above-described data transmission. The live streaming can 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), MPEG DASH, etc. The live streaming may further include an embodiment in which the audience AU can play or view the content with a specific delay while the live streamer is recording the content. Regarding the degree of the delay, it is desirable that it be at least small enough for the live streamer LV and the audience 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 the data of the recorded content in a server and providing the data from the server to the user at a random timing in response to the user's request.

[0017] As used herein, "streaming data" can refer to data including image data and audio data. More specifically, the image data (which may also be referred to as video data) may be generated by the image capture functions of the user terminals 20 and 30. The audio data (which may also be referred to as audio data) may be generated by the audio input functions of the user terminals 20 and 30. The streaming data may be played back on the user terminals 20 and 30 so that the user can view content related to the user. In some embodiments, between the generation of the streaming data on the user terminal of the live streamer and the playback on the user terminal of the viewer, processes such as compression, decompression, encoding, decoding, transcoding, etc., for changing the data format and size specifications are assumed. Before and after such processing, the content (video and audio) is not substantially changed. Therefore, in the current embodiments of the present disclosure, it is explained that the streaming data before processing and the streaming data after processing are the same. That is, when the streaming data generated by the user terminal of the live streamer is played back 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 back 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 it to the server 10 via the network NW. At the same time, the user terminal 20 can display the video VD on the display of the user terminal 20 and check the streaming content of the live streamer LV.

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

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

[0021] FIG. 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 herein represent devices such as a computer's CPU, hardware such as mechanical components, and software such as computer programs that represent functional blocks implemented by the cooperation of these elements. Therefore, those skilled in the art will understand that the functional blocks can be implemented in various ways by a combination of hardware and software.

[0022] The live streamer LV and the viewer AU can download and install the live streaming application (live stream app) of the present disclosure from the download site to the user terminals 20 and 30 via the network NW. Alternatively, the live stream app may be pre-installed on the user terminals 20 and 30. By executing live streaming on 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 stream app by the user terminals 20 and 30 (more specifically, a processor such as a CPU) will be described below as the functions of the user terminals 20 and 30. The functions are basically the functions that the live stream app causes the user terminals 20 and 30 to realize. In some embodiments, these functions may be transmitted from the server 10 to the web browsers of the user terminals 20 and 30 via the network NW and realized by being executed by the computer programs of the web browsers. 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 the user's audio and / or video data and generate streaming data to be transmitted to the server 10. The viewing unit 200 is configured to receive and play the streaming data from the server 10. In some embodiments, the user can operate the streaming unit 100 during a broadcast or operate the viewing unit 200 when viewing the stream. In some embodiments, the user terminal that operates the streaming unit 100 can be called a live streamer or the user terminal that generates the streaming data. The user terminal that operates the viewing unit 200 can be called a viewer or the user terminal that plays the streaming data.

[0024] The streaming unit 100 can 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] When the distribution unit 106 receives streaming data including video data from the video control unit 102 and audio data from the audio control unit 104, it transmits the data to the server 10 via the network NW. In some embodiments, the distribution unit 106 transmits the streaming data in real time. That is, the generation of the streaming data from the video control unit 102 and the audio control unit 104 and the distribution by the distribution unit 106 are executed 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 is configured to generate the streaming data for the partner to whom the distribution unit 106 transmits and plays the streaming data for display on the display. The UI control unit 108 is configured to display an object to be operated or an object to receive an instruction on the display and 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 transmission unit 206, a cache unit 208, a queue unit 210, a processing unit 212, a cache DB 250, a data queue DB 252, and a cache method lookup table 254. The viewing unit 200 is configured to receive streaming data from the server 10 via the 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 is configured to play the streaming data to display an image on the display and output sound from the speaker. In some embodiments, outputting an image on the display and outputting sound from the speaker may be referred to as "playing the streaming data". The UI control unit 202 is connected to input units such as a touch panel, a keyboard, and a display, and can obtain input from the user.

[0029] The rendering unit 204 may be configured to render the streaming data from the server 10 and the frame image. The frame image may include an input from the user, a comment input by the viewer, and a user interface object for receiving data received from the server 10. The input transmission unit 206 is configured to receive the user input from the UI control unit 202 and transmit it to the server 10 via the network NW.

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

[0031] The cache unit 208 may be configured to process cache data. For example, the cache unit 208 may store the network data from the server 10 as cache data in the cache DB 250. The cache unit 208 may obtain 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 by the user terminal. In some embodiments, the cache unit 208 may display the cache data when 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 the download of network data from the server 10. In some embodiments, the queue unit 210 may control the queue 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 the data queue of the download data in the data queue DB 252 and control the download of the data.

[0033] The user may request data from the server 10 using the user terminal. For example, when the user terminal is a smartphone, the user may request live streaming data via an app or the like. When 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 a plurality of data from the live streaming platform. For example, the user may request live streaming data in the streaming room or leaderboard data of an event. In some embodiments, the requested data may be any possible data from the live streaming service.

[0034] When the user accesses a page such as a leaderboard page, the queue unit 210 may start a data request to the server 10. The leaderboard may include a plurality of data such as event descriptions, rules, and leaderboards. The leaderboard may further include the user's ranking, the current score obtained, and the like. In some embodiments, the current score may include a sub-page indicating the composition of the score, the bonus obtained from the previous round, and the like.

[0035] The processing unit 212 may be configured to determine a cache strategy for the data requested from the server 10. Here, the cache strategy may refer to the setting of rules for determining how data is acquired, stored, updated, and the like. The cache strategy may include, for example, "cache only", "network after cache", "network priority", "network only", and the like. The processing unit 212 may flexibly determine the cache strategy for the requested data based on various elements.

[0036] Here, the "cache only" cache strategy may mean that the requested data is retrieved only from the cache and there is no fallback network. The "cache only" strategy ensures that the response is retrieved from the cache. This "cache only" strategy is used, for example, for data that never changes once it is first cached. For example, leaderboard data within an event never changes before the start of the event or after the end of the event, so it may be cached once and provided only from the cache.

[0037] Here, the "network only" cache strategy may mean that the requested data is retrieved only from the network and there is no fallback cache. This "network only" strategy is used when the request needs to be satisfied from the network. Unlike the "cache only" strategy, this strategy is used for data that changes frequently. For example, leaderboard data for an event changes frequently just before the end of the event, so only the network may be applied to display the latest data to the user.

[0038] Here, the "network first", or "network that falls back to cache" cache strategy may mean that the requested data is retrieved from the latest response via the network. In the "network first" strategy, by default, an attempt is made to retrieve the latest response from the network. If the request is successful, the requested data is also placed in the cache. If the network does not return a response, the cached response is used. This "network first" strategy is an ideal solution for data that is updated frequently. For example, leaderboard data in an event changes frequently during the event, so it may be requested using the "network first" strategy.

[0039] Here, the caching strategy of "network after cache" may refer to that the requested data is first obtained from the local cache, and when the cache is unavailable, the network is requested for the data. More specifically, when the data has already been stored in the local cache and is still valid (i.e., the expiration date has not passed), the user terminal can obtain the data from the local cache. When the data is not in the local cache or has expired, the user terminal may initiate a network request such as obtaining the latest data from server 10.

[0040] The strategy of "network after cache" has the advantage of significantly shortening the waiting time of the user waiting for the completion of the network request because it first attempts to use the local cache. For example, since the leaderboard data does not change frequently at the start of an event, it may first be requested from the local cache and then from the network if necessary. According to these embodiments, the responsiveness of the user terminal can be improved and the load on the server can be reduced. Therefore, the performance of the application and the user experience may be improved.

[0041] FIG. 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.

[0042] When the streaming information unit 302 receives a live streaming request 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 the stream ID of the live streaming and / or the live streamer ID of the live streamer corresponding to the live streaming.

[0043] When the streaming information unit 302 receives 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 streamings. 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.

[0044] When the input transmission unit 206 of the user terminal 30 receives the selection of a 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 transmits 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.

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

[0046] The processing unit 306 is configured to process requests according to operations from the user's user terminal. 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 refers to the data DB 324 to obtain the event list, and the processing unit 306 and the relay unit 304 may further transmit the event list to the user's user terminal.

[0047] FIG. 4 is a table showing an exemplary data structure of the stream DB320 in FIG. 3. The stream DB320 holds information regarding the currently ongoing live stream. The stream DB320 stores, in association with each other, a stream ID for identifying a live stream on the live streaming platform provided by the live streaming system 1, a live streamer ID for identifying a live streamer who provides the live stream, and a viewer ID for identifying a viewer of the live stream.

[0048] FIG. 5 is a table showing an exemplary data structure of the user DB322 in FIG. 3. The user DB322 holds information regarding a user. The user DB322 stores, in association with each other, a user ID for identifying the user, a point for specifying the points accumulated by the user, a level for identifying the level of the user, and a status for identifying the status of the user. The point is an electronic value that circulates 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.

[0049] FIG. 6 is a table showing an exemplary data structure of the data DB324 in FIG. 3. The data DB324 holds data information regarding a live stream in the live streaming platform. In some embodiments, the data within the server 10 may be any data possible in the live streaming platform. Here, the leaderboard data in an event will be taken as an example for explanation. The data DB324 stores by associating with each other 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. Further, the data DB324 stores by associating with each other a user ID, a rank, and a score for identifying users participating in the leaderboard, the ranks and scores corresponding to those users.

[0050] In some embodiments, the queue unit 210 may download all the data from the server 10 at once or in several portions. For example, if there are 3,000 data entries in the server 10, the queue unit 210 may download 100 pieces at a time in several portions. In some embodiments, the queue unit 210 may determine the order of data download. When the queue unit 210 obtains access to the leaderboard page, it may request the leaderboard data. For example, the queue unit 210 may download the data of the top 10 users of the leaderboard and display the information of the leaderboard on the viewer's terminal.

[0051] FIG. 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, in association with each other, 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 some embodiments, the cache DB 250 may include other detailed information for each data entry.

[0052] FIG. 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 regarding a queue of data downloaded by the user terminal of the user. The data queue DB 252 stores, in association with each other, a queue ID for identifying the queue, progress status, and response of the download from the server 10, the progress status, and the response. The data queue DB 252 also stores, in association with each other, the number of retries for specifying the number of requests for the corresponding data, and the previous response time for specifying the time at the previous time until the server 10 responds to a request from the user terminal of the user. In some embodiments, the response time may be measured based on the elapsed time from when the request is made until the server sends back a response to the user terminal of the user.

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

[0054] In some embodiments, the response may be "success" or "failure". A "success" response may mean that the requested data is normally obtained and processed without errors or problems and returned to the user terminal. On the other hand, a "failure" response may mean that due to an error or problem, the requested data is not normally obtained and processed and not returned to the user terminal. In some embodiments, the reason or error code for the "failure" response may also be included in the response.

[0055] The reason for the "failure" response may be that the server is unavailable, server load, network problems, etc. For example, if the server cannot provide a response within a reasonable or expected time, the response is "failure", and the reason may be "no response", etc. In some embodiments, the reasonable or expected time frame for the response to the request may be a maximum of 3 seconds, 5 seconds, or determined flexibly according to actual needs. In some embodiments, the response may be displayed as "pending" indicating that the request is in the processing stage and waiting for a response.

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

[0057] Figure 9 shows an exemplary event page 334. The viewer or the live streamer may click a button on the screen to request an event list. When an event is selected, the corresponding event page 334 may be displayed on the user terminal. As shown in Figure 9, the event page 334 may include a title 336, a banner 338, an explanation 340, and a ranking 342. In some embodiments, the event page 334 may include a tab 344 indicating the current stage of the event, such as Round 1, Round 2, and the final round.

[0058] The user may click on the ranking 342 to check the current or past leaderboard of the event. Figures 10 and 11 show exemplary leaderboard pages of the ranking 342. In some embodiments, the leaderboard page 346 may display the user's ranking and the corresponding score S. In some embodiments, detailed information DI of the score S showing the score information in detail may be displayed below each user. For example, the detailed information DI may include score bonuses, score combinations, and other related information.

[0059] In some embodiments, the live streamer and viewers may access the leaderboard page 346 to check the current leaderboard. When multiple users access the leaderboard page 346 and request data from the server 10, the load on the server becomes very high. If the user fails to receive data from the server 10, the leaderboard page 346 may become blank, which may lead to a degradation of the user experience. Therefore, the user terminal first checks whether the requested data is available in the cache data DB 250. Regardless of whether cached data is displayed, the terminal may further request network data from the server 10.

[0060] For some events, the competition is very intense. In particular, the last certain period before the end of the event is always considered to be the most thrilling time in the event. The viewers always gather with the live streamer and support the live streamer for the event. The viewers donate gifts for the event to the live streamer and wait until the end of the event to try to make their favorite live streamer win the event or reach the reward threshold. Therefore, the information on the leaderboard page 346 is very important and needs to be obtained and refreshed dynamically in real time.

[0061] In some embodiments, as shown in FIG. 10, the cached data of the leaderboard page 346 may be displayed on the user terminal. In some embodiments, as shown in FIG. 11, the network data from the server 10 may be displayed and refreshed in real time. According to this embodiment, the user may track the current ranking of the leaderboard page 346 and contribute to the victory of the favorite live streamer. The method of displaying cached data, the method of displaying network data, and the method of refreshing the data will be described later.

[0062] In some embodiments, the processing unit 212 may be configured to determine a caching strategy for the requested data. In some embodiments, the caching strategy may be determined based on a predetermined look-up table. In some embodiments, the caching strategy may be determined based on various parameters. In some embodiments, the caching strategy may be determined by a machine learning model or the like. In some embodiments, the caching strategy may be flexibly determined according to actual needs.

[0063] In some embodiments, the requested data may be any possible data within the live streaming platform. In some embodiments, the caching strategy may be applied to data such as having a start time, having an end time, being in progress, etc. In some embodiments, the requested data may be, for example, gift data or the like. In some embodiments, the requested data may be other data similar to event data such as having a start time, having an end time, being in progress, etc. In some embodiments, the requested data may be flexibly determined according to actual needs.

[0064] FIG. 12 is a flowchart showing the steps of the application startup process in the user terminals 20, 30. The user may request data from the server 10 via the user terminal. For example, the live streamer or viewer may open the event page 334 or the leaderboard page 346, check the description of the event and the leaderboard, and the user terminal may collect a list of requests for the data request to the server 10.

[0065] When data is requested, the processing unit 212 may obtain a cache strategy for the requested data (S502). The cache strategy may be determined flexibly. When the cache strategy is determined, the processing unit 212 may apply the cache strategy to the requested data. For example, when the cache strategy is the "network first" strategy (yes in S504), the processing unit 212 may handle the data according to the "network first" strategy (S506).

[0066] In some embodiments, when the cache strategy is the "network after cache" strategy (yes in S508), the processing unit 212 may handle the data according to the "network after cache" strategy (S510). In some embodiments, when the cache strategy is the "cache only" strategy (yes in S512), the processing unit 212 may handle the data according to the "cache only" strategy (S514). In some embodiments, when the cache strategy is not any of the above (no in S504, S508, S512), the processing unit 212 may handle the data according to the "network only" strategy (S516).

[0067] In some embodiments, as shown in FIG. 12, the cache strategy may be determined in an order such as the order of "network first", "network after cache", "cache only", "network only", etc. In some embodiments, the cache strategy may be determined simultaneously. In some embodiments, when the cache strategy is determined, the processing unit 212 may directly apply the cache strategy to the requested data. In some embodiments, the method for determining the cache strategy may be determined flexibly according to actual needs.

[0068] In some embodiments, the step S502 of obtaining the cache strategy may be implemented via a predetermined rule such as a lookup table. FIG. 13 is a flowchart showing the process of determining the cache strategy, and FIG. 14 is a table showing an exemplary data structure of the cache method lookup table 254 in FIG. 2. As shown in FIG. 13, when data is requested, the processing unit 212 may refer to the cache method lookup table 254 (S602).

[0069] The cache method lookup table 254 may be configured to store the relationship between the requested data (such as an API) and the cache strategy. As illustrated in FIG. 14, the cache method lookup table 254 may include an API ID and the corresponding cache strategy. The cache method lookup table 254 stores the API ID that identifies the requested data and the cache strategy that identifies the cache strategy for the requested data in association with each other.

[0070] In some embodiments, the API may correspond to a specific portion of the data. Also, in some embodiments, all data may be requested via the same API or different APIs, which depends on the parameters in the API. The processing unit 212 may refer to the cache method lookup table 254 and determine the cache strategy based on the API ID and the like. Also, in some embodiments, the cache method lookup table 254 may include other parameters such as the timing of the requested data.

[0071] In some embodiments, the cache strategy for data reception (such as leaderboard data) may refer to a whitelist such as the cache method lookup table 254. The cache strategy is always hard-coded in the whitelist or code. In some embodiments, the "network after cache" may be applied as the default cache strategy, that is, the cache may be displayed first. In some embodiments, when the user manually triggers an update, it may indicate that the user wants to see the latest leaderboard data. However, using the "network after cache" strategy by default may result in displaying old data for a short time, which may cause misunderstandings for the user.

[0072] In some embodiments, the step S502 of obtaining the cache strategy may be dynamically determined. The processing unit 212 may determine the cache strategy based on various parameters. The parameters may be, for example, the occurrence timing of events, the presence or absence of cache, cache history, network connection, user operations, automatic updates, etc. Automatically switching the cache strategy may minimize misunderstandings for the user when viewing leaderboard data.

[0073] FIG. 15 is an exemplary functional configuration diagram of events in a live streaming platform. As shown in FIG. 15, multiple events may occur simultaneously in the live streaming platform. The events may be related to various topics such as singing, new talents, Christmas, etc. Each event may have a start time and an end time, such as events E1, E2, and E3 in FIG. 15. In some embodiments, as shown in FIG. 15, the event may be divided into multiple rounds, and each round may have a start time and an end time.

[0074] In some embodiments, the user may request data related to the event via the user terminal. For example, the live streamer and the viewer may request leaderboard data and check past rankings, current rankings, etc. Further, the live streamer and the viewer may request event data and check the description and rules of the event. In some embodiments, the cache strategy may be flexibly determined based on the above parameters and the like.

[0075] Also, in some embodiments, the step S502 of obtaining the cache strategy may be dynamically realized. FIG. 16 is a flowchart showing the steps of the application startup process in the user terminals 20 and 30. As shown in FIG. 16, the processing unit 212 may check the timing of the event (S522, S530, S532). If the event has not started yet, that is, if it is before the start time of the event (S522), the processing unit 212 may determine whether there is a cache corresponding to the requested data (S524).

[0076] If there is a cache corresponding to the requested data (yes in S524), the processing unit 212 may apply the cache strategy of "cache only" as a response (S526). If there is no cache corresponding to the requested data (no in S524), the processing unit 212 may apply the cache strategy of "network after cache" as a response (S528).

[0077] In some embodiments, if the event has already ended, i.e., it is after the event end time (Yes in S530), the processing unit 212 may also determine whether there is a cache corresponding to the requested data (S524). If there is a cache corresponding to the requested data (Yes in S524), the processing unit 212 may apply the cache strategy of "cache only" in the response (S526). Or, if there is no cache corresponding to the requested data (No in S524), the processing unit 212 may apply the cache strategy of "network after cache" in the response (S528).

[0078] In some embodiments, if the event is neither before the start nor after the end (No in S522 and S530), and the event is in progress (S532), the cache strategy during event progress may be applied. In some embodiments, the processing unit 212 may determine whether the requested data is the first read (S534).

[0079] In some embodiments, the status of the "first read" may refer to the state where the request is interrupted at the start of the request. For example, if there are 3,000 data entries in the server 10, the queue unit 210 may download them in several times, 100 at a time. If the data from the 1st to the 100th is not requested normally, it may be called the "first read". This may refer to a situation where an error occurs in the user terminal of the user, or a problem occurs while requesting the first part of the data.

[0080] In some embodiments, if the requested data is the first read (Yes in S534), the processing unit 212 may determine the quality of the network connection. The quality of the network connection may be determined by parameters such as the speed of the network connection. The processing unit 212 may detect the speed of the network connection at the user terminal. The speed of the network connection may be classified based on network statuses such as, for example, no connection, low 2G, 2G, 3G, 4G, 5G, or higher.

[0081] In some embodiments, if the network status is 3G or lower, it may be called a poor connection. In some embodiments, if the network status is 4G or higher, it may be called a good connection. In some embodiments, the definition of good or poor connection may be flexibly determined according to actual needs.

[0082] In some embodiments, if the quality of the network connection is poor (Poor in S536), the processing unit 212 may apply the cache strategy of "network after cache" as a response (S528). In some embodiments, if the quality of the network connection is good (Good in S536), the processing unit 212 may apply the cache strategy of "network priority" as a response (S538).

[0083] In some embodiments, the poor quality may be called a poor network connection. In some embodiments, the good or poor quality may be further divided into different levels respectively. For example, the poor quality may be further divided into worse and worst. In a network connection, the worse quality may correspond to the network statuses of 3G and 2G, and the worst quality may correspond to the network statuses of low 2G and no network connection.

[0084] In some embodiments, when the quality of the network connection is poor, the cache strategy of "network after cache" may be applied. When the quality of the network connection is the worst, the cache strategy of "cache only" may be applied, and so on. In some embodiments, the cache strategy corresponding to the level of the network quality may be flexibly determined according to the actual necessity.

[0085] When the required data is not the first read (No in S534), the processing unit 212 may determine whether there is a user operation from the user of the user terminal (S540). In some embodiments, the user operation may be an operation triggered by the user, etc., and the purpose of the operation may be data update, etc. For example, the user may update the leaderboard data on the screen by clicking a button or swiping down on the screen of the user terminal.

[0086] When an update is triggered (Yes in S540), the processing unit 212 may apply the cache strategy of "network priority" as a response. In some embodiments, when an update is not triggered (No in S540), the cache strategy is not applied, and the process of obtaining the cache strategy may end. For example, the user may do nothing on the leaderboard page and be in an idle state, etc. According to this embodiment, when the user triggers an update of the leaderboard data, the cache strategy of "network priority" may be applied, and the user experience may be improved.

[0087] In some embodiments, an automatic update mechanism may be applied. The automatic update mechanism may refer to, for example, data being automatically updated at specific intervals or the like. In some embodiments, when the update is not triggered (No in S540), the processing unit 212 may further check whether the automatic update is on. In some embodiments, when the automatic update mechanism is on, the processing unit 212 may apply the cache strategy of "network priority" as a response. In some embodiments, when the automatic update mechanism is off, the cache strategy is not applied, and the process of obtaining the cache strategy may end.

[0088] The event may have different periods, such as before the start, during the progress, and after the end of the event. At different time points during the event, the level of data request traffic is different. According to the above embodiments, the cache strategy may be determined automatically or dynamically. For example, the processing unit 212 may check whether there is available cache before the start or after the end of the event, and then determine the cache strategy accordingly.

[0089] Furthermore, the cache strategy may be determined based on the network connection. The processing unit 212 may determine the cache strategy based on the quality of the network connection when the event is in progress. Also, the processing unit 212 may determine the cache strategy based on user operations such as manual updates. Therefore, the user experience may be improved.

[0090] According to the above embodiments, the cache strategy may be dynamically determined before, during, and after the event. There is a possibility that the server load is reduced and the responsiveness of the user terminal is improved. Also, the automatic switching of the cache strategy may minimize user misunderstandings. Therefore, the user experience may be improved.

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

[0092] The information processing apparatus 900 includes a CPU 901, a read only memory (ROM) 903, and a random access memory (RAM) 905. Further, the information processing apparatus 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 apparatus 900 may include an imaging device (not shown) such as a camera. The information processing apparatus 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.

[0093] The CPU 901 functions as an arithmetic processing unit and a control unit, and controls the overall operation or a part of the operation of the information processing apparatus 900 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 in the above-described embodiments. The ROM 903 stores programs, operation parameters, etc. used by the CPU 901. The RAM 905 temporarily stores programs used when the CPU 901 executes and parameters that change as appropriate when executing the programs. The CPU 901, the ROM 903, and the RAM 905 are connected to each other via a host bus 907 composed 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.

[0094] The input unit 915 is a device operated by a user, such as a mouse, keyboard, touch panel, button, switch, lever, etc. The input unit 915 may be a device that converts a physical quantity into an electrical signal, such as an audio sensor (such as a microphone), an acceleration sensor, an inclination sensor, an infrared sensor, a depth sensor, a temperature sensor, a humidity sensor, etc. 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 corresponding to the operation of the information processing device 900. The input unit 915 includes an input control circuit that generates an input signal based on the information input from the user and outputs the generated input signal to the CPU 901. The user operates the input unit 915 to input various data and give an instruction for a processing operation to the information processing device 900.

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

[0096] The storage unit 919 is a device for data storage and is an example of the 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 the programs executed by the CPU 901, various data, and various data acquired from the outside.

[0097] The drive 921 is a reader / writer for a removable recording medium 923 such as a magnetic disk, optical disk, magneto-optical disk, or semiconductor memory, and is built-in or externally attached to the information processing apparatus 900. The drive 921 reads the information recorded on the mounted removable recording medium 923 and outputs it to the RAM 905. The drive 921 writes records to the mounted removable recording medium 923.

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

[0099] 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).

[0100] The communication unit 929 may also 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 uses a predetermined protocol such as TCP / IP to transmit and receive signals on the Internet and to transmit and receive signals to and from other communication devices. The communication network NW to which the communication unit 929 is connected is a network established by a wired or wireless connection. The communication network NW is, for example, the Internet, a home LAN, infrared communication, radio wave communication, or satellite communication.

[0101] The imaging device (not shown) is a device that images the real space using, for example, 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 imaging of the subject image on the imaging element, and generates an imaging image. The imaging device may capture a still image or a moving image.

[0102] As described above, the live streaming system 1 of the present disclosure has been described with reference to the embodiments. The above-described embodiments are merely described for the purpose of explanation. Rather, it is easily conceivable by those skilled in the art that the above-described components and processes of the embodiments can be combined in various ways and various changes can be made, and these are also included in the technical scope of the present disclosure.

[0103] The processes described in this specification, particularly the processes described using flowcharts or flowcharts, can omit a part of the processes constituting the process, add processes not explicitly included in the processes constituting the process, and / or rearrange the order of the processes. Such processes that are the subject of such omission, addition, or rearrangement are also included in the scope of the present disclosure as long as they do not depart from the gist of the present disclosure.

[0104] In some embodiments, at least a part of the functions executed by the server 10 may be executed by something other than the server 10. For example, the user terminal 20 or 30 may execute them. In some embodiments, at least a part of the functions executed by the user terminal 20 or 30 may be executed by something other than the user terminal 20 or 30. For example, the server 10 may execute them. In some embodiments, the rendering of the frame image may be executed by the user terminal such as a viewer, a server, or a live streamer.

[0105] Furthermore, the system or method described in the above embodiment may be provided by a non-transitory computer-readable storage device such as a solid-state memory 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.

[0106] As described above, the technical content and features of the present disclosure have been explained. However, those with ordinary knowledge in the technical field to which the present disclosure pertains can make many more modifications and corrections without departing from the teachings and disclosures of the present disclosure. Therefore, the scope of the present disclosure is not limited to the already disclosed embodiments, but is within the scope included in the appended claims, including other modifications and corrections that do not depart from the present disclosure.

Explanation of Reference Numerals

[0107] 1 Live streaming system 10 Server 20 User terminal 100 Streaming unit 102 Video control unit 104 Audio control unit 106 Distribution unit 108 UI control unit 200 Viewing unit 202 UI control unit 204 Rendering unit 206 Input transmission unit 208 Cache unit 210 Queue unit 212 Processing unit 250 Cache DB 252 Data queue DB 254 Cache method 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 Title 338 Banner 340 Explanation 342 Ranking 344 Tab 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 Medium 925 Connection Port 927 External Connection Terminal 929 Communication Unit LS Live Streaming LV Live Streamer NW Network SP Specific Part AU1, AU2 Viewers VD, VD1, VD2 Video

Claims

1. A terminal for processing data in a live streaming platform, comprising one or more processors, wherein the one or more processors execute machine-readable instructions to request data from the live streaming platform, and determine a caching strategy based on the timing of the data, and execute the same. A terminal characterized by this.

2. In response to the timing not being in progress, a function of determining whether there is a cache corresponding to the data, and in response to there being an available cache corresponding to the data, a function of applying the cache-only caching strategy. The terminal according to claim 1, further comprising this.

3. In response to the timing not being in progress, a function of determining whether there is a cache corresponding to the data, and in response to there being no available cache corresponding to the data, a function of applying the caching strategy of network after cache. The terminal according to claim 1, further comprising this.

4. The data is related to an event within the live streaming platform, and the timing of the data includes before the start time, after the end time, or during progress. The terminal according to claim 1, characterized by this.

5. In response to the timing being in progress, a function of determining whether the request for the data is the first read, and in response to the requested data being the first read, a function of determining the quality of the network connection, and in response to the quality of the connection being good, a function of applying the network-priority caching strategy. The terminal according to claim 1, further comprising this.

6. In response to the timing being in progress, a function of determining whether the request for the data is the first read, and in response to the requested data being the first read, a function of determining the quality of the network connection, and in response to the quality of the connection being poor, a function of applying the caching strategy of network after cache. The terminal according to claim 1, further comprising this.

7. In response to the timing being in progress, a function of determining whether it is the first read of the data; In response to the requested data not being the first read, a function of determining whether there is an update triggered by the user of the user terminal; In response to the update triggered by the user of the user terminal, a function of applying the cache strategy with network priority; The terminal according to claim 1, further comprising the above.

8. In response to the timing being in progress and the requested data not being the first read, a function of determining whether an automatic update mechanism is applied; In response to the automatic update mechanism being applied, a function of applying the cache strategy with network priority; The terminal according to claim 1, further comprising the above.

9. A method for processing data in a live streaming platform, comprising: A step of requesting data from the live streaming platform; A step of determining a cache strategy based on the timing of the data; The method, characterized by including the above.

10. A computer program for processing data in a live streaming platform, causing a terminal to: Have a function of requesting data from the live streaming platform; Have a function of determining a cache strategy based on the timing of the data; The computer program, characterized by realizing the above.

Images