JP7495073B1 - SERVER AND METHOD - Google Patents

Abstract

[Problem] To provide a mechanism for providing live streaming that can reflect the actions of the streamer.
[Solution] The server includes a starting means for starting the priority provision period of a live distribution when a priority provision period start request is received via a network from a terminal of a distributor who is currently live distributing, a management means for managing the timing at which the next priority provision period of the live distribution can start, and a processing means for performing a process to provide information of the live distribution during the priority provision period to a user in priority over information of the live distribution outside the priority provision period.
[Selected Figure] Figure 1

Description

The present disclosure relates to a server and a method.

As IT technology develops, the way information is exchanged has also changed. In the Showa era, one-way information transmission, such as through newspapers and television, was the norm. In the Heisei era, mobile phones and personal computers became widespread and Internet communication speeds improved significantly, leading to the rise of instant two-way communication services such as chat services, and on-demand video distribution services became more popular as storage costs decreased. Now, in the Reiwa era, with the increasing functionality of smartphones and further improvements in network speeds such as 5G, services that enable real-time communication through video, especially live streaming services, are rapidly gaining recognition. The number of users of live streaming services, especially among young people, is increasing as a service that allows everyone to share the same fun time even when they are far apart.

Although some users access the live streaming platform by specifying a specific live stream, in most cases the live streaming platform provides the accessing user with information about live streams currently in progress, such as a list of available live streams and the profile of the streamer. The user selects the live stream they wish to watch from the provided information and watches it. The live streaming platform can determine the priority of live streams to provide to the user and the live streams to recommend to the user depending on the degree of matching between the user and the streamer or live stream (see, for example, Patent Document 1). This provides the user with information about live streams that are more likely to interest the user, allowing the user to enjoy live streams more.

JP 2023-122470 A JP 2020-521207 A JP 2019-164617 A

In the live streaming recommendation mechanism described in Patent Document 1, the system decides which live streaming programs to recommend to a user based on a matching score between the user and the live streaming program. In general, the operations or intentions of the broadcaster are not directly taken into account in the process of deciding which live streaming programs to recommend.

One of the characteristics of live streaming is that it does not proceed according to a fixed script, but rather progresses freely depending on the on-the-spot interactions between the streamer and the viewer. As a result, the excitement and highlights of a live stream go up and down, and it is difficult for a system to accurately predict when such an ups and downs will occur.

A streamer can accurately judge whether the excitement is coming soon, whether the excitement is currently building, whether they are taking a break, or whether the highlight is coming soon. However, with the current live streaming system, the streamer's actions are not directly reflected in the selection of content to be streamed, so the streamer's judgment cannot be utilized.

This disclosure has been made in consideration of these issues, and its purpose is to provide a system for providing live streaming that can reflect the actions of the streamer.

One aspect of the present invention relates to a server. The server includes a start means for starting a priority provision period of a live stream when a priority provision period start request is received via a network from a terminal of a streamer who is currently live streaming, a management means for managing the timing at which the next priority provision period of the live stream can start, and a processing means for performing a process to provide information about a live stream that is within the priority provision period to a user in priority over information about a live stream that is not within the priority provision period.

Another aspect of the present invention is a computer program. This computer program causes a terminal of a live stream distributor to have the following functions: receive a priority provision period start instruction from the distributor during live stream; transmit a priority provision period start request to a server via a network upon receiving the priority provision period start instruction; and begin accepting the next priority provision period start instruction upon the arrival of the timing at which the next priority provision period can be started.

In addition, any combination of the above components, or mutual substitution of the components or expressions of the present invention between devices, methods, systems, computer programs, and recording media storing computer programs, are also valid aspects of the present invention.

The present invention provides a system for providing live streaming that can reflect the actions of the streamer.

FIG. 2 is a schematic diagram showing an aspect of live streaming provided in a live streaming system according to an embodiment. FIG. 1 is a schematic diagram showing a configuration of a live distribution system according to an embodiment. FIG. 3 is a block diagram showing the functions and configuration of the user terminal of FIG. 2. FIG. 3 is a block diagram showing the functions and configuration of the server in FIG. 2 . 5 is a data structure diagram showing an example of a stream DB in FIG. 4. 5 is a data structure diagram showing an example of a user DB in FIG. 4. FIG. 5 is a data structure diagram showing an example of a gift DB in FIG. 4. 5 is a data structure diagram showing an example of a core time distribution list of FIG. 4. 5 is a data structure diagram showing an example of a recommendation list DB in FIG. 4. 11 is a flowchart showing the flow of a series of processes on a user terminal of a distributor during live distribution. FIG. 13 is a representative screen diagram of a live streaming room screen displayed on the display of a user terminal of a broadcaster. FIG. 13 is a representative screen diagram of a live streaming room screen displayed on the display of a user terminal of a broadcaster. 13 is a flowchart showing the flow of a series of processes for updating the core time distribution list in the server. 1 is a flowchart showing a series of processing steps in a live distribution system when providing live distribution to a viewer's user terminal. FIG. 13 is a representative screen diagram of a live streaming room screen displayed on the display of the user terminal of the target user. FIG. 13 is a representative screen diagram of a live streaming selection screen displayed on the display of the user terminal of the target user. 1 is a block diagram showing an example of a hardware configuration of an information processing device according to an embodiment of the present invention;

In the following, identical or equivalent components, parts, processes, and signals shown in each drawing will be given the same reference numerals, and duplicate explanations will be omitted where appropriate. In addition, some parts that are not important for the explanation will be omitted in each drawing.

In a live streaming system according to an embodiment, when a broadcaster who is broadcasting a live stream presses a "core time button," the core time of that live stream begins. The live streaming system provides the user with a live stream selected from a list of live streams during the core time. By swiping or sliding up or down on the user's user terminal, a UI is realized in which only the live streams of the broadcaster who pressed the "core time button" are streamed one after another. The core time lasts for a relatively short, predetermined period of time. The "core time button" is configured so that once it is pressed, a predetermined waiting period must be waited before it can be pressed again. For example, the "core time button" can only be pressed once per hour, and each core time lasts for three minutes.

In an embodiment, live streaming information during a priority provision period is provided to users in priority over live streaming information outside the priority provision period. In this specification, this priority provision period is referred to as core time.

FIG. 1 is a schematic diagram showing the manner of providing live streams in a live streaming system according to an embodiment. At a certain time t=T, four ongoing live streams, namely a first live stream 800, a second live stream 802, a third live stream 804, and a fourth live stream 806, are in core time. At time t=T, a user can switch to the second live stream 802 by swiping up on the first live stream 800, and can switch back to the first live stream 800 by swiping down on the second live stream 802. The same applies between the second live stream 802 and the third live stream 804, and between the third live stream 804 and the fourth live stream 806. The four live streams may be ordered by a matching score with the user. At time t=T, the remaining core time of the first live stream 800 is 20 seconds, the remaining core time of the second live stream 802 is 2 minutes, the remaining core time of the third live stream 804 is 2 minutes, and the remaining core time of the fourth live stream 806 is 1 minute 30 seconds. In addition to these four live streams, at least one other live stream that is not in the core time (outside the core time) is in progress in the live streaming system, but these four live streams that are in the core time are provided to users with priority. For example, the system may be configured so that users have to make more effort (tapping, searching, etc.) to watch live streams that are outside the core time.

At time t=T+1 minutes, one minute after time t=T, five ongoing live streams, namely, the second live stream 802, the third live stream 804, the fifth live stream 808, the fourth live stream 806, and the sixth live stream 810, are in core time. At time t=T+1 minutes, the core time for the first live stream 800 has ended, so the first live stream 800 is removed from the list of live streams to be provided. At time t=T+1 minutes, the user can switch to the third live stream 804 by swiping up on the second live stream 802, and can switch back to the second live stream 802 by swiping down on the third live stream 804. The same applies between the third live stream 804 and the fifth live stream 808, between the fifth live stream 808 and the fourth live stream 806, and between the fourth live stream 806 and the sixth live stream 810. The five live streams may be ordered by matching scores with the user. In the case of FIG. 1, within the one minute that has passed, the fifth live stream 808 and the sixth live stream 810 enter the core time, and as a result of matching with users, the fifth live stream 808 is ranked above the fourth live stream 806, and the sixth live stream 810 is ranked below the fourth live stream 806.

In this way, in the live streaming system according to this embodiment, a live stream that is currently being streamed and is in core time is provided to users in priority over a live stream that is currently being streamed but outside of core time. When the core time for a live stream ends over time, that live stream is no longer a target for priority provision. This allows the streamer to specify the timing of entering core time, so the streamer can enter core time when they want to promote their live stream, such as when their live stream is about to get popular, when it is getting popular, or when the highlight is approaching. As a result, a live stream that is relatively interesting is provided to users in priority, so users can watch a more interesting live stream, and the streamer can increase viewer retention of their live stream.

In conventional live streaming systems, the system automatically selects which live streams will be given priority at any given time, so it is possible that, for example, a live stream may be given priority when it happens to be quiet, causing viewers to lose interest, or conversely, it may not be selected as a priority stream when it is very exciting, resulting in a missed opportunity to attract viewers. In the live streaming system of this embodiment, streamers can choose the timing when their live streams will be given priority, which can reduce or eliminate the above-mentioned mismatches that can occur in conventional technology.

In addition, introducing a waiting period can prevent or eliminate abuse of the core time button. The rarity of core time encourages streamers to carefully press the core time button. As a result, the quality and excitement of live streams during core time can be improved.

FIG. 2 is a schematic diagram showing the configuration of a live distribution system 1 according to an embodiment of the present disclosure. The live distribution system 1 provides an interactive live distribution service in which a distributor (also called a live streamer) LV and a viewer (also called an audience) AU (AU1, AU2, ...) can communicate in real time. As shown in FIG. 2, the live distribution system 1 includes a server 10, a user terminal 20 on the distributor side, and a user terminal 30 (30a, 30b, ...) on the viewer side. In addition to distributors who distribute live distribution and viewers who watch live distribution, there are also users who log in to the live distribution platform but do not distribute or watch. Such users are called active users. Distributors, viewers, and active users may be collectively referred to as users. The server 10 may be composed of one or more information processing devices connected to the network NW. The user terminals 20 and 30 may be, for example, mobile terminals such as smartphones, tablet terminals, laptop PCs, recorders, portable game consoles, and wearable devices, or may be stationary devices such as desktop PCs. The server 10, the user terminal 20, and the user terminal 30 are connected to each other so that they can communicate with each other via various wired or wireless networks NW.

The live distribution system 1 involves a distributor LV, a viewer AU, and an administrator (not shown) who manages the server 10. The distributor LV is a person who transmits content in real time by recording and filming his/her own songs, talks, performances, fortune telling, game commentary, etc. on his/her own user terminal 20 and uploading the content to the server 10 as is. The administrator provides a platform for live distribution of content on the server 10, and also mediates or manages real-time exchanges between the distributor LV and the viewer AU. The viewer AU accesses the platform with the user terminal 30, selects the desired content, and views it. During the live distribution of this content, the viewer AU performs operations to make comments, support, or request a fortune through the user terminal 30, and the distributor LV who provides the content responds to such comments, support, or requests, and the reaction is transmitted to the viewer AU through video and/or audio, thereby establishing two-way communication.

In this specification, "live streaming" may mean a data transmission mode that realizes a state in which content recorded on the user terminal 20 of the distributor LV is played back and made viewable on the user terminal 30 of the viewer AU in substantially real time, or may mean the distribution itself realized by such a transmission mode. Live streaming may be realized using existing live streaming technologies such as HTTP Live Streaming, Common Media Application Format, Web Real-Time Communications, Real-Time Messaging Protocol, and MPEG DASH. Live streaming includes a transmission mode in which the viewer AU can view the content with a certain delay while the distributor LV is recording the content. The delay is at least large enough to allow communication between the distributor LV and the viewer AU. However, live streaming is distinguished from so-called on-demand distribution in which the entire recorded data of the content is temporarily stored on a server, and then the data is provided to the user from the server at any time upon request from the user.

In this specification, "video data" refers to data including image data (also called video data) generated by the imaging function of the user terminals 20 and 30, and audio data (also called audio data) generated by the audio input function of the user terminals 20 and 30. The video data is played back on the user terminals 20 and 30, allowing the user to view the content. In this embodiment, it is assumed that processing such as compression, decompression, encoding, decoding, and transcoding is performed to change the format, size, and specifications of the data between when the video data is generated on the distributor's user terminal and when it is played back on the viewer's user terminal. Since the content (e.g., moving images and audio) represented by the video data before and after such processing is substantially unchanged, in this embodiment, the video data after such processing is described as being the same as the video data before such processing. In other words, when video data is generated on the distributor's user terminal and then played back on the viewer's user terminal via the server 10, the video data generated on the distributor's user terminal, the video data passing through the server 10, and the video data received and played on the viewer's user terminal are all the same video data.

In the example of FIG. 2, a broadcaster LV is live streaming a talk. The broadcaster LV's user terminal 20 records and records the image and audio of the broadcaster LV while he or she is talking, generating video data, which is then transmitted to the server 10 via the network NW. The user terminal 20 also displays the recorded video image VD of the broadcaster LV on the display of the user terminal 20, allowing the broadcast content by the broadcaster LV to be confirmed.

The user terminals 30a, 30b of viewers AU1, AU2 who have requested the platform to watch the live broadcast of the broadcaster LV each receive video data related to the live broadcast via the network NW, and play the received video data to display the videos VD1, VD2 on the display and output audio from the speaker. The videos VD1, VD2 displayed on each user terminal 30a, 30b are substantially identical to the video VD captured by the user terminal 20 of the broadcaster LV, and the audio output from each user terminal 30a, 30b is also substantially identical to the audio recorded by the user terminal 20 of the broadcaster LV.

The recording and recording on the user terminal 20 of the distributor LV and the playback of the video data on the user terminals 30a and 30b of the viewers AU1 and AU2 are performed substantially simultaneously. When one viewer AU1 inputs a comment on the content of the talk of the distributor LV to the user terminal 30a, the server 10 displays the comment in real time on the user terminal 20 of the distributor LV and also on the user terminals 30a and 30b of each viewer AU1 and AU2. When the distributor LV reads the comment and starts a talk that overlays the content, the video and audio of the talk are output on the user terminals 30a and 30b of each viewer AU1 and AU2, and it is recognized that a conversation between the distributor LV and viewer AU1 has been established. In this way, the live distribution system 1 realizes live distribution that enables two-way communication rather than one-way communication.

Figure 3 is a block diagram showing the functions and configuration of user terminal 20 in Figure 2. User terminal 30 has the same functions and configuration as user terminal 20. Each block shown in Figure 2 and the following block diagrams can be realized in hardware terms by elements and mechanical devices such as a computer CPU, and in software terms by computer programs, etc., but here we depict functional blocks realized by the cooperation of these. Therefore, those skilled in the art who have read this specification will understand that these functional blocks can be realized in various ways by combining hardware and software.

A user downloads and installs a live distribution application program (hereinafter referred to as a live distribution app) according to this embodiment from a download site to the user terminal 20, 30 via the network NW. Alternatively, the live distribution app may be pre-installed in the user terminal 20, 30. When the live distribution app is executed by the user terminal 20, 30, the user terminal 20, 30 communicates with the server 10 via the network NW and realizes various functions. Hereinafter, functions realized by the user terminal 20, 30 (its processor such as a CPU) executing the live distribution app will be described as functions of the user terminal 20, 30. These functions are actually functions that the live distribution app makes the user terminal 20, 30 realize. Note that in other embodiments, these functions may be realized by a computer program written in a programming language such as HTML (HyperText Markup Language), which is transmitted from the server 10 to the web browser of the user terminal 20, 30 via the network NW and executed by the web browser.

The user terminal 20 comprises a distribution unit 100 that generates video data recording the user's image and voice and provides it to the server 10, a viewing unit 200 that acquires the video data from the server 10 and plays it, and a non-distribution processing unit 400 that processes requests from active users. The user activates the distribution unit 100 when distributing, the viewing unit 200 when viewing, and the non-distribution processing unit 400 when searching for a live broadcast they want to watch, viewing a distributor's profile, or viewing an archive. The user terminal on which the distribution unit 100 is active is the user terminal on the distributor side, that is, the user terminal that generates the video data, the user terminal on which the viewing unit 200 is active is the user terminal on the viewer side, that is, the user terminal that plays the video data, and the user terminal on which the non-distribution processing unit 400 is active is the user terminal of an active user.

The distribution unit 100 includes an imaging control unit 102, an audio control unit 104, a video transmission unit 106, a distribution side UI control unit 108, and a distribution side communication unit 110. The imaging control unit 102 is connected to a camera (not shown in FIG. 2) and controls imaging by the camera. The imaging control unit 102 acquires image data from the camera. The audio control unit 104 is connected to a microphone (not shown in FIG. 2) and controls audio input by the microphone. The audio control unit 104 acquires audio data from the microphone. The video transmission unit 106 transmits video data including image data acquired by the imaging control unit 102 and audio data acquired by the audio control unit 104 to the server 10 via the network NW. The video transmission unit 106 transmits the video data in real time. That is, the generation of video data by the imaging control unit 102 and the audio control unit 104 and the transmission of the generated video data by the video transmission unit 106 are substantially simultaneous.

The distribution side UI control unit 108 controls the UI for the distributor. The distribution side UI control unit 108 is connected to a display not shown in FIG. 2, and displays a moving image on the display by playing back the moving image data to be transmitted by the moving image transmission unit 106. The distribution side UI control unit 108 is connected to input means such as a touch panel, keyboard, and display not shown in FIG. 2, and acquires input from the distributor via these input means. The distribution side UI control unit 108 superimposes a predetermined frame image on the moving image. The frame image includes various user interface objects (hereinafter simply referred to as objects) for receiving input from the distributor, comments entered by the viewer, and information acquired from the server 10. The distribution side UI control unit 108 accepts, for example, tap input on an object by the distributor. The object includes a core time button.

The distribution side communication unit 110 controls communication with the server 10 during live distribution. The distribution side communication unit 110 transmits the contents of the input by the distributor acquired by the distribution side UI control unit 108 to the server 10 via the network NW. The distribution side communication unit 110 receives various information associated with the live distribution from the server 10 via the network NW.

The viewing unit 200 includes a viewing side UI control unit 202 and a viewing side communication unit 204. The viewing side communication unit 204 controls communication with the server 10 during live streaming. The viewing side communication unit 204 receives video data related to the live streaming in which the distributor and viewers participate from the server 10 via the network NW.

The viewing side UI control unit 202 controls the UI for the viewer. The viewing side UI control unit 202 is connected to a display and a speaker (not shown in FIG. 2), and plays the received video data to display a video image on the display and output audio from the speaker. The output of an image on the display and audio from the speaker can be collectively referred to as "video data being played". The viewing side UI control unit 202 is connected to input means such as a touch panel, keyboard, and display (not shown in FIG. 2), and acquires input from the viewer through these input means. The viewing side UI control unit 202 superimposes a predetermined frame image on the image of the video data acquired from the server 10. The frame image includes various objects for receiving input from the viewer, comments input by the viewer, and information acquired from the server 10. The viewing side communication unit 204 transmits the contents of the viewer's input acquired by the viewing side UI control unit 202 to the server 10 via the network NW.

The non-broadcast processing unit 400 includes a non-broadcast UI control unit 402 and a non-broadcast communication unit 404. The non-broadcast UI control unit 402 controls the UI for active users. For example, the non-broadcast UI control unit 402 generates a live broadcast selection screen that displays a list of live broadcasts that can currently be joined and accepts the selection of a live broadcast by the active user, and displays it on the display. The non-broadcast UI control unit 402 generates a profile screen of any user and displays it on the display. The non-broadcast UI control unit 402 plays back archives that were generated by recording and filming past live broadcasts.

The non-broadcast communication unit 404 controls communication with the server 10 outside of live broadcasting. The non-broadcast communication unit 404 receives information for generating a live broadcast selection screen, information for generating a profile screen, and archive data from the server 10 via the network NW. The non-broadcast communication unit 404 transmits the contents of input by active users to the server 10 via the network NW.

Figure 4 is a block diagram showing the functions and configuration of the server 10 in Figure 2. The server 10 includes a distribution information providing unit 302, a relay unit 304, a gift processing unit 308, a payment processing unit 310, a core time processing unit 330, a waiting period management unit 332, a matching unit 334, a recommendation processing unit 336, a stream DB 314, a user DB 318, a gift DB 320, a core time distribution list 338, and a recommendation list DB 340.

Figure 5 is a data structure diagram showing an example of the stream DB 314 in Figure 4. The stream DB 314 holds information on live streaming currently being performed. The stream DB 314 holds, in association with each other, a stream ID that identifies a live streaming on the live streaming platform provided by the live streaming system 1, a broadcaster ID that is a user ID that identifies the broadcaster of the live streaming, a viewer ID that is a user ID that identifies the viewer of the live streaming, and a content tag that represents the content of the live streaming.

In the live streaming platform provided by the live streaming system 1 according to this embodiment, when a user performs live streaming, that user becomes a streamer, and when the same user watches a live stream broadcast by another user, that user becomes a viewer. Therefore, the distinction between streamer and viewer is not fixed, and a user ID that is registered as a streamer ID at one time may be registered as a viewer ID at another time.

The content tags for live streaming may be tags specified by the streamer when they start the live stream, or they may be tags obtained by a model generated by machine learning that analyzes the live stream in real time.

Figure 6 is a data structure diagram showing an example of the user DB 318 of Figure 4. The user DB 318 holds information about users. The user DB 318 holds a user ID that identifies a user, points owned by the user, rewards granted to the user, the remaining waiting period of the user, the level of the user, and attributes of the user, in association with each other. The user attributes include the age range of the user, the gender of the user, and the hair color of the user.

Points are electronic value circulated within the live streaming platform. Users purchase points by credit card or other payment methods. Rewards are electronic value defined within the live streaming platform, and are an indicator used to determine the amount of money that a broadcaster receives from the administrator of the live streaming platform. On the live streaming platform, when a viewer gives a gift to a broadcaster during or outside of a live stream, the viewer's points are consumed and the broadcaster's reward increases accordingly.

The level is an index indicating the performance of the user as a broadcaster on the live streaming platform. In other embodiments, the level may be an index indicating the performance of the user as a viewer on the live streaming platform, or may be an index indicating the performance of the user as both a broadcaster and a viewer. The level may increase or decrease depending on the number of live streams, the broadcast time of the live stream, the total viewed time of the live stream, the total viewed time as a viewer of the live stream, the number and/or amount of gifts given, the number and/or amount of gifts received, the number of comments, etc. Alternatively, the level may be evaluated and determined by an administrator based on reviews of the broadcaster, user satisfaction, and comments in the stream. Alternatively, the level may be automatically determined by a predetermined rule or a machine learning model.

Fig. 7 is a data structure diagram showing an example of the gift DB 320 in Fig. 4. The gift DB 320 holds information about gifts that can be used by viewers in live distribution. A gift is electronic data having the following characteristics.
・Can be purchased with points or money, or given free of charge.
- Something that viewers can give to the streamer. Giving a gift to a streamer is also called "using a gift" or "throwing a gift."
In some cases, the purchase and use of the gift occur simultaneously as a set, while in other cases the viewer can use the gift at any time after purchase.
・When a viewer gives a gift to a streamer, the streamer will receive an appropriate reward.
When a gift is used, an effect associated with the gift may occur. For example, an effect corresponding to the gift may appear on the live streaming room screen.

The gift DB 320 stores a gift ID that identifies a gift, a given reward that is given to a broadcaster when the gift is given to the broadcaster, and a value point that is a value to be paid when using the gift, in association with each other. A viewer can give a gift to a broadcaster by paying the value points of the desired gift while watching a live broadcast. The value points may be paid by an appropriate electronic payment method, for example, by the viewer paying the value points to the administrator. Alternatively, payment may be made by bank transfer or credit card. The relationship between the given reward and the value points can be set arbitrarily by the administrator. For example, the given reward may be set to the value points. Alternatively, the value points may be set to points obtained by multiplying the given reward by a predetermined coefficient such as 1.2, or the value points may be set to points obtained by adding a predetermined fee point to the given reward.

In this embodiment, a waiting period shortening gift is set. For example, the gift "SH1" in FIG. 7 is set as a waiting period shortening gift. When a viewer uses the waiting period shortening gift during a live broadcast, the waiting period of the live broadcast is shortened. The waiting period may be shortened by decreasing the remaining time of the current waiting period by a specified amount, or by increasing the speed of the countdown of the waiting period. For example, when the gift "SH1" in FIG. 7 is used during a live broadcast, the remaining time of the waiting period of the live broadcast at that time is decreased by 30 seconds. In other words, if the remaining time is 2 minutes 15 seconds, the remaining time becomes 1 minute 45 seconds by using the gift "SH1".

Figure 8 is a data structure diagram showing an example of the core time distribution list 338 of Figure 4. The core time distribution list 338 is a list of live distributions within the core time (within the priority provision period). Core time may be a period during which the target live distribution is in a priority provision state. The core time distribution list 338 may include information on only live distributions within the core time. The length of the core time may be fixed or variable. The core time distribution list 338 holds, in association with each other, the distributor ID of the distributor of the live distribution within the core time, the stream ID of the live distribution, and the time when the core time of the live distribution started for that live distribution.

Figure 9 is a data structure diagram showing an example of the recommendation list DB 340 of Figure 4. The recommendation list DB 340 holds a recommendation list for each user, which is a list of live broadcasts (hereinafter referred to as recommended broadcasts) during core time that are recommended to that user. The recommendation list DB 340 holds a user's user ID in association with a recommendation list for that user. The recommendation list for a user holds a stream ID of a recommended broadcast for that user in association with a matching score value between that recommended broadcast and that user. In the recommendation list, the recommended broadcasts are ordered in descending order of matching score.

Returning to FIG. 4, the core time processing unit 330 controls the core time of a live broadcast currently in progress. When the core time processing unit 330 receives a core time start request via the network NW from the user terminal 20 of a broadcaster currently broadcasting live, it starts the core time of the live broadcast.

The core time processing unit 330 manages the timing at which the next core time for a live stream can start. The core time processing unit 330 allows the next core time to start when a waiting period longer than the core time has elapsed since the start of the core time for a live stream. The length of the core time may be set to 1 minute, 3 minutes, 5 minutes, 10 minutes, etc., and the length of the waiting period may be set to 30 minutes, 1 hour, 3 hours, etc., which is longer than the length of the core time.

In this embodiment, the length of the core time is fixed as a system parameter, but in other embodiments, the length of the core time may be dynamically adjusted. For example, the core time processing unit 330 may adjust the length of the core time according to changes in parameters during live streaming. The core time processing unit 330 may measure the degree of excitement of the live streaming during the core time, and if the degree meets a predetermined extension condition, perform processing to extend the core time of the live streaming by a predetermined amount. The degree of excitement may be calculated by a formula that inputs the number of comments, the number and amount of gifts, the number of cheers, etc. The extension condition may be met when the degree of excitement exceeds a threshold value or when that state continues for a predetermined period of time. Alternatively, when a core time extension gift is used by a viewer during live streaming, the core time processing unit 330 may perform processing to extend the core time of the live streaming. Alternatively, when a payment is made by a distributor of a live streaming during the core time, the core time processing unit 330 may perform processing to extend the core time of the live streaming. If the length of the core time is adjusted dynamically and/or according to the user, the user DB 318 may store the length of the core time for each user.

The core time processing unit 330 manages or updates the core time distribution list 338. The core time processing unit 330 registers a live distribution for which a new core time has started in the core time distribution list 338, and removes a live distribution for which a previously started core time has expired from the core time distribution list 338. The core time processing unit 330 updates the core time distribution list 338 every time a core time start request is received. The core time processing unit 330 updates the core time distribution list 338 when a predetermined master update period has elapsed even if a core time start request is not received. The length of the master update period may be set according to the length of the core time, or may be set to be smaller than the length of the core time. For example, the length of the master update period may be set to one-tenth or one-fifth of the length of the core time. Alternatively, the length of the master update period may be set to a fixed value that is sufficiently smaller than the length of the core time. By setting the length of the master update period to be smaller than the length of the core time, the number of live distributions that remain in the core time distribution list 338 even if the core time has expired can be suppressed.

The waiting period management unit 332 shortens the waiting period on the condition that a distributor who is live streaming or a viewer who is watching the live streaming pays a fee. The waiting period management unit 332 adjusts the length of the waiting period according to a change in a parameter during the live streaming. The waiting period management unit 332 may measure the degree of excitement of the live streaming outside the core time, and if the degree satisfies a predetermined shortening condition, perform processing to shorten the waiting period of the live streaming by a predetermined amount. The shortening condition may be satisfied if the degree of excitement exceeds a threshold value, or if that state continues for a predetermined period. Conversely, the waiting period management unit 332 may perform processing to extend the waiting period of the live streaming by a predetermined amount if the degree of excitement of the live streaming outside the core time satisfies a predetermined waiting extension condition. The waiting extension condition may be satisfied if the degree of excitement falls below a threshold value, or if that state continues for a predetermined period, or if it is determined that the live streaming is in an idle state. Alternatively, when a viewer uses a waiting period shortening gift during a live stream, the waiting period management unit 332 may perform processing to shorten the waiting period of the live stream. Alternatively, when a distributor of a live stream outside of the core time pays a fee, the waiting period management unit 332 may perform processing to shorten the waiting period of the live stream.

The waiting period management unit 332 adjusts the waiting period by increasing or decreasing the remaining waiting time registered in the user DB 318 for each user. For example, if the waiting period of user "LR1" should be shortened by 30 minutes, the waiting period management unit 332 updates the user DB 318 so that 30 minutes is subtracted from the current remaining waiting time of user "LR1". In the example of FIG. 6, the waiting period management unit 332 changes the remaining waiting time of user "LR1" from "58 minutes 40 seconds" to "28 minutes 40 seconds".

The matching unit 334 calculates a matching score between a user logged in to the live streaming platform and each live streaming within the core time. The matching unit 334 acquires attributes of the live streaming within the core time. More specifically, the matching unit 334 refers to the stream DB 314 and identifies the broadcaster ID and content tag of the live streaming within the core time. The matching unit 334 refers to the user DB 318 and acquires the attributes and level of the broadcaster corresponding to the identified broadcaster ID. The attributes of the live streaming within the core time include the attributes and level of the broadcaster of the live streaming, and the content tag. The matching unit 334 refers to the user DB 318 and acquires the attributes of the user logged in to the live streaming platform. The matching unit 334 calculates a matching score between the attributes of the live streaming within the core time and the attributes and viewing history of the identified user. The viewing history is acquired from a viewing history DB (not shown). Calculation of such a matching score between a live stream and a user may be achieved using known matching techniques, such as those described in Patent Document 2 and Patent Document 3.

The recommendation processing unit 336 manages or updates the recommendation list DB 340. When a user newly logs in to the live streaming platform, the recommendation processing unit 336 calculates a matching score between the user and each live streaming within the core time. The recommendation processing unit 336 generates a recommendation list for the user in descending order of the calculated matching scores, and registers the recommendation list in the recommendation list DB 340. Specifically, the recommendation processing unit 336 generates a recommendation list for the user by rearranging the stream IDs of live streaming within the core time so that the higher the matching score, the higher the ranking. The recommendation processing unit 336 registers the generated recommendation list in the recommendation list DB 340 in association with the user ID of the user.

The recommendation processing unit 336 updates the recommendation list of a user each time the recommendation update period of the user elapses. The length of the recommendation update period may be set according to the length of the core time, or may be set to be shorter than the length of the core time. For example, the length of the recommendation update period may be set to one-fifth or one-half the length of the core time. Alternatively, the length of the recommendation update period may be set to a fixed value that is sufficiently smaller than the length of the core time. By setting the length of the recommendation update period to be shorter than the length of the core time, the results of updating the core time distribution list 338 can be reflected in the recommended distributions in real time. For example, a distributor will be able to feel the effect of increased exposure opportunities by entering the core time more quickly.

When the distribution information providing unit 302 receives a notification from the distributor's user terminal 20 via the network NW that a live distribution is to commence, the distribution information providing unit 302 registers in the stream DB 314 a stream ID that identifies the live distribution and the distributor ID of the distributor of the live distribution.

The distribution information providing unit 302 performs processing to provide information about live streaming during the core time to the user in priority over information about live streaming outside the core time. The distribution information providing unit 302 performs processing to provide information only about live streaming during the core time to the user. More specifically, the distribution information providing unit 302 selects a live streaming to be provided to the user from among the recommended streamings registered in a recommendation list for each user.

In the examples of Figures 5 and 8, live streams "ST1" and "ST3" are examples of live streams within core time, and live stream "ST2" is an example of live stream outside core time. Live streams "ST1" and "ST3" are provided to the user in priority over live stream "ST2". In this embodiment, as shown in Figure 1, a live stream selected by default from a list of recommended streams (consisting of live streams within core time) is provided to the user, and live streams outside core time are configured to be viewable without going to great lengths, such as entering a different mode, entering a different tab, or searching.

When a user newly logs in to the live streaming platform, the streaming information providing unit 302 transmits information about the live streaming that is registered at the top of the list of recommended streamings for the user, generated by the recommendation processing unit 336, to the user terminal of the user. The streaming information providing unit 302 starts providing video data of the live streaming that is registered at the top to the user terminal of the user. The streaming information providing unit 302 updates the stream DB 314 so that the viewer ID of the stream ID of the live streaming that has started to be provided includes the user ID of the user. This makes the user a viewer of the live streaming.

The relay unit 304 relays the transmission of video data from the user terminal 20 of the broadcaster of the live broadcast started by the broadcast information providing unit 302 to the user terminal 30 of the viewer. The relay unit 304 receives a signal indicating a user input by the viewer during live broadcast, i.e., during playback of the video data, from the viewing side communication unit 204. The signal indicating the user input includes a swipe signal indicating a swipe or slide input having any of the directions of up, down, left, and right, and an object designation signal indicating the designation of an object displayed on the display of the user terminal 30. The object designation signal includes the viewer ID of the viewer, the broadcaster ID of the broadcaster performing the live broadcast that the viewer is watching, and an object ID that identifies the object. If the object is a gift icon, the object ID is a gift ID. In that case, the object designation signal is a gift use signal indicating the use of a gift by the viewer for the broadcaster. Similarly, the relay unit 304 receives a signal indicating a user input by the broadcaster during playback of the video data, for example, an object designation signal, from the broadcasting side communication unit 110 of the broadcasting unit 100 of the user terminal 20.

When the relay unit 304 receives a request to change the live stream from the user terminal 20 of a viewer of the live stream via the network NW, it selects a new live stream that is different from the current live stream from a list of recommended streams for that viewer. The stream change request may be a swipe signal indicating an up swipe or a down swipe. The relay unit 304 starts relaying the transmission of video data related to the selected live stream from the user terminal of the stream distributor of the selected live stream to the user terminal of the viewer who requested the stream change request.

The gift processing unit 308 updates the user DB 318 to increase the distributor's reward according to the reward for the gift specified by the gift ID included in the gift usage signal. The gift processing unit 308 refers to the gift DB 320 and specifies the reward for the gift ID included in the received gift usage signal. The gift processing unit 308 updates the user DB 318 to add the specified reward for the reward corresponding to the distributor ID included in the gift usage signal.

The payment processing unit 310 processes the payment of the gift by the viewer in response to receiving the gift use signal. The payment processing unit 310 refers to the gift DB 320 and identifies the value points of the gift identified by the gift ID included in the gift use signal. The payment processing unit 310 updates the user DB 318 to deduct the identified value points from the points of the viewer identified by the viewer ID included in the gift use signal.

The operation of the live distribution system 1 configured as above will now be described.
FIG. 10 is a flowchart showing a series of processing steps in the user terminal 20 of a distributor during live distribution. The distribution side UI control unit 108 of the user terminal 20 displays a live distribution room screen including a moving image of the distributor generated by the distribution side control unit 108 on the display during live distribution. The distributor can check comments, check how his/her live distribution looks, give instructions to end distribution, give instructions to start core time, and the like on the live distribution room screen. The distribution side UI control unit 108 enables a core time button on the live distribution room screen displayed on the display (S202). The core time button is an object for receiving an instruction to start core time from the distributor during live distribution. The enabling of such an object and the later-described disabling include activating and deactivating the object. For example, the enabling of the core time button may be to start displaying the core time button, to start accepting taps or designations on the core time button, or to transition the core time button to a state in which it can be pressed or designated. Disabling the core time button may be performed by ceasing the display of the core time button, by ceasing the acceptance of taps or designations on the core time button, or by transitioning the core time button to a state in which it cannot be pressed or designated. The display mode of the core time button may differ when the core time button is valid and when it is invalid. In this case, a valid core time button may be displayed more emphasized than an invalid core time button. The emphasis or non-emphasis of the button may be expressed using color, darkness, or size.

The distribution-side UI control unit 108 waits for a tap on the core time button (S204). The distribution-side UI control unit 108 determines whether or not a tap on the core time button has been detected, and if not (N in S204), repeats the process of S204. If the distribution-side UI control unit 108 detects a tap on the core time button (Y in S204), the distribution-side communication unit 110 generates a core time start request including the stream ID of the live stream related to the live stream room screen on which the tapped core time button is displayed, and transmits the request to the server 10 via the network NW (S206).

When a tap on the core time button is detected, the delivery side UI control unit 108 disables the core time button on the live delivery room screen displayed on the display (S208). When the timing arrives when the next core time can be started, the user terminal 20 starts accepting an instruction to start the next core time. The delivery side UI control unit 108 judges whether or not the waiting period has elapsed since the core time button was disabled in step S208 (S210). This judgment may be realized, for example, by the delivery side UI control unit 108 counting using a timing means such as a timer, or may be realized by the delivery side communication unit 110 inquiring of the server 10. In the former case, if there is a change or increase/decrease in the remaining time of the waiting period other than the normal countdown (for example, the use of a period-shortening gift), the waiting period management unit 332 of the server 10 notifies the user terminal 20 of the remaining time after the change or increase/decrease via the network NW, and the delivery side UI control unit 108 of the user terminal 20 updates the count of the waiting period with the notified remaining time. In the latter case, the delivery side communication unit 110 periodically inquires of the server 10 via the network NW as to whether the waiting period has expired, and the waiting period management unit 332 determines whether the waiting period has expired by referring to the user DB 318. The waiting period management unit 332 returns the result of the determination to the delivery side communication unit 110. In this way, the length of the waiting period determines the timing at which the next core time can start after the core time has started.

If the waiting period has elapsed (Y in S210), the distribution side UI control unit 108 returns the process to step S202 and re-enables the disabled core time button. This starts accepting instructions to start the next core time.

11 is a representative screen diagram of a live streaming room screen 630 displayed on the display of the user terminal 20 of the distributor. The live streaming room screen 630 in FIG. 11 corresponds to a state in which the tap of the core time button is awaited in step S204 in FIG. 10. The live streaming room screen 630 displays a video generated by the user terminal 20 of the distributor in real time. The live streaming room screen 630 has a video 632 of the distributor obtained by playing the video data to be transmitted by the video transmission unit 106, a comment display area 634, an end streaming button 636, and a core time button 638. The distribution side UI control unit 108 generates the live streaming room screen 630 by superimposing other objects, i.e., the end streaming button 636, the comment display area 634, and the core time button 638, on the video 632 obtained by playing the video data.

The comment display area 634 may include comments entered by viewers and notifications from the system. The notifications from the system may include information indicating who gave which gift to the broadcaster, information indicating that the broadcaster's core time for live streaming has started, and information indicating that the broadcaster's core time for live streaming has ended. The broadcasting side UI control unit 108 generates a comment display area 634 including the viewer's comments received from the server 10 and notifications from the system, and includes the generated comment display area 634 in the live streaming room screen 630.

The end broadcast button 636 is an object for accepting an instruction from the broadcaster to stop providing live broadcast.

When the delivery side communication unit 110 of the user terminal 20 detects a tap on the core time button 638, it generates a core time start request and transmits it to the server 10 via the network NW. When the core time start request is transmitted, the delivery side UI control unit 108 of the user terminal 20 disables the core time button 638.

12 is a representative screen diagram of the live streaming room screen 630 displayed on the display of the user terminal 20 of the distributor. The live streaming room screen 630 in FIG. 12 corresponds to the state immediately after the core time button is disabled in step S208 in FIG. 10. When the core time button 638 is tapped on the live streaming room screen 630 in FIG. 11, the display transitions to the live streaming room screen 630 in FIG. 12. In FIG. 12, the core time button 640 is grayed out or transparent. The distribution side UI control unit 108 is configured not to accept a tap on the core time button 640 in this state. Even if the core time button 640 in this state is tapped, the distribution side UI control unit 108 ignores it. The live streaming room screen 630 includes an indicator 642 associated with the core time button 640. The indicator 642 indicates the remaining time of the waiting period for the live streaming related to the live streaming room screen 630. The delivery side UI control unit 108 updates the display of the indicator 642 according to the count number of the waiting period or the remaining time acquired from the server 10. When the live streaming is within the core time, the live streaming room screen 630 includes a core time object 644. The presence of the core time object 644 allows the broadcaster to know that he or she is within the core time. When the live streaming is registered in the core time streaming list 338 in the server 10 in response to a core time start request transmitted by tapping the core time button 638 in FIG. 11, the server 10 generates a start message 646 notifying the start of the core time and transmits it to the user terminal 20 of the broadcaster of the live streaming and the user terminal 30 of the viewer. The delivery side UI control unit 108 of the user terminal 20 includes the received start message 646 in the comment display area 634.

When time has passed from the state of the live streaming room screen 630 in FIG. 12 and the core time has expired, the streaming communication unit 110 receives an end message from the server 10 notifying the end of the core time, and the streaming UI control unit 108 includes the end message in the comment display area 634. The streaming UI control unit 108 stops displaying the core time object 644. After that, when the waiting period has elapsed, the core time button is activated, and the display becomes similar to that of the live streaming room screen 630 shown in FIG. 11.

Figure 13 is a flowchart showing a series of processing steps for updating the core time distribution list 338 on the server 10. The core time processing unit 330 waits for a core time start request from the user terminal 20 of the distributor of the currently ongoing live distribution (S220). If the core time processing unit 330 does not receive a core time start request (N in S220), it determines whether or not the master update period has elapsed since the previous update of the core time distribution list 338 (S222). If the master update period has elapsed (Y in S222), the process proceeds to the core time distribution list update process of step S224 described below. If the master update period has not elapsed (N in S222), the process returns to step S220. As a result, the update interval of the core time distribution list 338 becomes the same as or shorter than the master update period.

When a core time start request is received (Y in S220), the core time processing unit 330 executes the following process to update the core time distribution list 338. After updating, the process returns to step S220.
The core time processing unit 330 registers information about the live distribution of the requester (or sender) of the core time start request received in step S220 at the top of the core time distribution list 338. The core time processing unit 330 registers, at the top of the core time distribution list 338, an association between the stream ID included in the core time start request, the distributor ID of the live distribution specified by the stream ID, and the time when the core time start request was received. The time when the core time start request was received is registered as the start time of the core time. Note that if step S224 is reached from N in step S222, this registration process does not occur.
The core time processing unit 330 deletes information about live streaming whose core time has expired from the core time distribution list 338. The core time processing unit 330 calculates the difference between the current time and the start time of the core time of each live streaming registered in the core time distribution list 338. The core time processing unit 330 deletes from the core time distribution list 338 any live streaming whose calculated difference exceeds the length of the core time.

Figure 14 is a flowchart showing a series of processing steps in the live streaming system 1 when providing a live stream to a viewer's user terminal 30. The streaming information providing unit 302 detects the launch of a live streaming app on the user's user terminal (S240). When a user taps the app icon of the live streaming app displayed on the display of the user terminal, the live streaming app launches on the user terminal. Once the launch is complete, the live streaming app generates a launch signal including the user ID of the user of the user terminal and transmits it to the server 10 via the network NW. When the server 10 receives the launch signal, it detects the launch of the live streaming app on the user terminal that sent it.

The matching unit 334 acquires the attributes and viewing history of the user (hereinafter referred to as the target user) of the user terminal on which the launch of the live streaming app was detected in step S240 (S242). The matching unit 334 acquires the attributes and level corresponding to the user ID included in the received launch signal from the user DB 318. The matching unit 334 acquires the viewing history corresponding to the user ID from a history storage unit (not shown). Based on the acquired information, the matching unit 334 calculates a matching score between the target user and each live stream registered in the core time streaming list 338 (S244).

The recommendation processing unit 336 generates a recommendation list for or for the target user by sorting the live streams registered in the core time stream list 338 in descending order of matching score, and registers the list in the recommendation list DB 340 (S246). The stream information providing unit 302 transmits information on the live stream registered at the top of the recommendation list for the target user to the user terminal of the target user via the network NW (S248). In this embodiment, the user terminal displays a live stream room screen related to the recommended stream as soon as the live stream app is launched, and in order to achieve this, the stream information providing unit 302 starts relaying the video data of the top live stream.

The recommendation processing unit 336 determines whether the recommendation update period has elapsed since the last update of the recommendation list for the target user (S250). If the recommendation update period has elapsed (Y in S250), processing proceeds to the recommendation list update processing of steps S252, S254, and S256 described below. If the recommendation update period has not elapsed (N in S250), processing proceeds to step S258. This makes the update interval of the recommendation list equal or equivalent to the recommendation update period.

If the recommendation update period has elapsed (Y in S250), the matching unit 334 acquires the attributes and viewing history of the target user (S252). The matching unit 334 acquires the attributes and level corresponding to the user ID of the target user from the user DB 318. The matching unit 334 acquires the viewing history corresponding to the user ID from a history storage unit (not shown). Based on the acquired information, the matching unit 334 calculates a matching score between the target user and each live broadcast registered in the core time broadcast list 338 at that time (S254).

The recommendation processing unit 336 updates the recommendation list for the target user by executing the following process.
The recommendation processing unit 336 generates a new recommendation list for the target user by sorting the live broadcasts registered in the core time broadcast list 338 in descending order of matching score.
The recommendation processor 336 replaces the current recommendation list for the target user with the new recommendation list generated above, and updates the recommendation list DB 340 so that such a replacement is realized.
Processing then returns to step S248.

If the recommendation update period has not elapsed (N in S250), the distribution information providing unit 302 determines whether or not a distribution change request has been received from the user terminal of the target user (S258). If a distribution change request has not been received (N in S258), the process returns to step S250. If a distribution change request has been received (Y in S258), the distribution information providing unit 302 determines whether the received distribution change request is a request for the next live distribution or a request for the previous live distribution (S260). In this embodiment, if the distribution change request is a swipe signal indicating an up swipe, it is determined to be a distribution change request requesting the next live distribution, and if the distribution change request is a swipe signal indicating a down swipe, it is determined to be a distribution change request requesting the previous live distribution.

If the distribution change request is a request for the next live distribution ("next live distribution" in S260), the relay unit 304 transmits information on a live distribution that is one rank lower than the live distribution currently being viewed by the target user in the recommendation list for the target user to the user terminal of the target user via the network NW (S262). When the relay unit 304 receives a swipe signal indicating an up swipe from the user terminal of the target user, it refers to the stream DB 314 and identifies a stream ID that includes the user ID of the target user included in the swipe signal as a viewer ID. The live distribution identified by the identified stream ID is the live distribution currently being viewed by the target user. The relay unit 304 refers to the recommendation list DB 340 and acquires the stream ID that is one rank lower than the identified stream ID in the recommendation list for the target user. The relay unit 304 starts providing the video data of the live distribution identified by the acquired stream ID to the user terminal of the target user. The relay unit 304 updates the stream DB 314 so that the viewer ID of the stream ID of the live distribution that has started to be provided includes the user ID of the target user. After that, the process returns to step S250.

If the distribution change request is for a previous live distribution ("Previous live distribution" in S260), the relay unit 304 transmits information on a live distribution that is one rank higher than the live distribution currently being viewed by the target user in the recommendation list for the target user to the user terminal of the target user via the network NW (S264). When the relay unit 304 receives a swipe signal indicating a down swipe from the user terminal of the target user, it refers to the stream DB 314 and identifies a stream ID that includes the user ID of the target user included in the swipe signal as a viewer ID. The live distribution identified by the identified stream ID is the live distribution currently being viewed by the target user. The relay unit 304 refers to the recommendation list DB 340 and acquires a stream ID that is one rank higher than the identified stream ID in the recommendation list for the target user. The relay unit 304 starts providing video data of the live distribution identified by the acquired stream ID to the user terminal of the target user. The relay unit 304 updates the stream DB 314 so that the viewer ID of the stream ID of the live distribution that has started to be provided includes the user ID of the target user. After that, the process returns to step S250.

Explaining with reference to the examples of FIG. 5 and FIG. 9, the target user "VR1" is currently watching the live stream "ST1" as shown in FIG. 5. When the target user "VR1" swipes up, the relay unit 304 refers to the recommendation list DB 340 in FIG. 9 and identifies the live stream "ST4" that is one rank below the live stream "ST1" in the recommendation list of the target user "VR1". The relay unit 304 ends the relay of the live stream "ST1" to the user terminal of the target user "VR1" and subsequently starts relaying the live stream "ST4". Next, when the target user "VR1" swipes down, the relay unit 304 refers to the recommendation list DB 340 in FIG. 9 and identifies the live stream "ST1" that is one rank above the live stream "ST4" in the recommendation list of the target user "VR1". The relay unit 304 ends the relay of the live stream "ST4" to the user terminal of the target user "VR1" and subsequently starts relaying the live stream "ST1".

Figure 15 is a representative screen diagram of a live streaming room screen 608 displayed on the display of the user terminal of the target user. When the live streaming application is launched on the user terminal of the target user and the user terminal receives video data related to the live streaming at the top of the recommendation list from the server 10, the viewing side UI control unit 202 of the user terminal generates the live streaming room screen 608 of Figure 15 and displays it on the display. The live streaming room screen 608 displays the video generated by the user terminal 20 of the broadcaster in real time. The live streaming room screen 608 has a video image 610 of the broadcaster obtained by playing the video data received from the server 10, a gift object 612, a comment input area 616, a comment display area 618, and a viewing end button 620. The viewing side UI control unit 202 generates the live streaming room screen 608 by superimposing other objects, namely the gift object 612, the comment input area 616, the comment display area 618, and the viewing end button 620, on the video image 610 obtained by playing the video data.

The comment input area 616 accepts comments entered by the viewer. The viewing-side communication unit 204 generates a comment input signal including the comment entered in the comment input area 616, and transmits the signal to the server 10 via the network NW. Additionally, the viewing-side UI control unit 202 updates the comment display area 618 to display the comment entered in the comment input area 616.

The end viewing button 620 is an object for accepting an instruction from the viewer to stop viewing the live broadcast.

When the viewer-side UI control unit 202 detects an upward or downward swipe on the live streaming room screen 608, it generates a swipe signal including the detected swipe direction and the user ID of the target user. The viewer-side communication unit 204 transmits the generated swipe signal to the server 10 via the network NW.

When the viewer UI control unit 202 detects a left or right swipe on the live streaming room screen 608, it stops displaying the live streaming room screen 608 and displays a live streaming selection screen on the display instead. Alternatively, the viewer UI control unit 202 transitions the display from the live streaming room screen 608 to the live streaming selection screen.

FIG. 16 is a representative screen diagram of a live streaming selection screen 600 displayed on the display of the user terminal 30 of the target user. The live streaming selection screen 600 includes thumbnails 602 showing each live streaming in the list of currently viewable live streaming received from the server 10. This list of currently viewable live streaming includes live streaming outside of core time and live streaming within core time. This list may be generated based on the matching score between the target user and the live streaming, without considering whether or not it is within core time. The viewer-side UI control unit 202 generates the live streaming selection screen 600 based on the list of live streaming obtained from the server 10, and displays it on the display. When the viewer taps one of the thumbnails 602, the screen transitions to the live streaming room screen of the corresponding live streaming.

In this embodiment, in order to watch a live stream outside of core time, the user must swipe left or right on the live stream room screen for live streams within core time, which is the first screen displayed after launching the live stream app, to display the live stream selection screen, and then tap on the thumbnail of the live stream outside of core time. In this way, the system is designed to make watching a live stream outside of core time more time-consuming than watching a live stream within core time.

In the above-described embodiment, examples of the database (DB) are a hard disk and a semiconductor memory. Furthermore, based on the description in this specification, it will be understood by those skilled in the art who have read this specification that each unit can be realized by a CPU (not shown), an installed application program module, a system program module, a semiconductor memory that temporarily stores the contents of data read from a hard disk, and the like.

According to the live streaming system 1 of this embodiment, a broadcaster can specify the timing at which their live streaming will appear on the recommendation list of potential viewers by pressing a core time button. This allows the broadcaster to gain exposure to more potential viewers at a time when their live streaming is most attractive, so more viewers will join and stay in the live streaming. As a result, interaction with viewers is stimulated and the broadcaster's satisfaction level increases. Furthermore, viewers can enjoy the live streaming even more, as they can watch more attractive live streaming one after another with simple operations.

In addition, in the live distribution system 1 according to this embodiment, a time limit is set for the core time, and a predetermined interval is set between each core time. This prevents overuse of the core time and allows more broadcasters to enjoy the benefits of the core time.

In addition, in the live streaming system 1 according to this embodiment, the core time is extended and the length of the waiting period is adjusted according to the payment of a fee by the viewer or the broadcaster, or according to the parameters of the live streaming. Therefore, it is possible to provide the viewer and/or the broadcaster with the freedom and incentive to adjust their exposure.

In addition, in the live distribution system 1 according to this embodiment, live distribution during core time is provided to viewers in a so-called reel format, and the press of the core time button by the distributor is reflected in the reel list in real time. Therefore, by reducing the time lag between the instruction to start core time and the increase in exposure, the satisfaction of the distributor can be increased, and viewers can be attracted by being provided with a succession of highly attractive live distributions in reel format.

The hardware configuration of an information processing device according to this embodiment will be described with reference to FIG. 17. FIG. 17 is a block diagram showing an example of the hardware configuration of an information processing device according to this embodiment. The illustrated information processing device 900 can realize, for example, each of the server 10 and the user terminals 20 and 30 according to this embodiment.

The information processing device 900 includes a CPU 901, a ROM (Read Only Memory) 902, and a RAM (Random Access Memory) 903. The information processing device 900 may also include a host bus 907, a bridge 909, an external bus 911, an interface 913, an input device 915, an output device 917, a storage device 919, a drive 921, a connection port 925, and a communication device 929. The information processing device 900 further includes an imaging device (not shown) such as a camera. The CPU 901 is an example of a hardware configuration for realizing the functions realized by the components described in this specification. The functions described in this specification may be realized by a circuit (circuitry) programmed to realize the described functions. The circuit (circuitry) programmed to realize the functions described in this specification includes a CPU (a Central Processing Unit), a DSP (Digital Signal Processor), a general-purpose processor, a specific application processor, an integrated circuit, ASICs (Application Specific Integrated Circuits), and/or a combination thereof. In this specification, a unit that achieves a specific function may be realized as a circuit programmed to achieve that function.

The CPU 901 functions as an arithmetic processing device and a control device, and controls the overall operation or a part of the operation in the information processing device 900 according to various programs recorded in the ROM 902, the RAM 903, the storage device 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 this embodiment. The ROM 902 stores programs and arithmetic parameters used by the CPU 901. The RAM 903 temporarily stores programs used in the execution of the CPU 901 and parameters that change appropriately during the execution. The CPU 901, the ROM 902, and the RAM 903 are connected to each other by a host bus 907 composed of an internal bus such as a CPU bus. Furthermore, the host bus 907 is connected to an external bus 911 such as a PCI (Peripheral Component Interconnect/Interface) bus via a bridge 909.

The input device 915 may be, for example, a device operated by a user, such as a mouse, keyboard, touch panel, button, switch, or lever, or may be a device that converts a physical quantity into an electrical signal, such as a sound 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 device 915 may be, for example, a remote control device that uses infrared or other radio waves, or an external connection device 927 such as a mobile phone that supports the operation of the information processing device 900. The input device 915 includes an input control circuit that generates an input signal based on information input by the user or a sensed physical quantity and outputs it to the CPU 901. The user operates the input device 915 to input various data to the information processing device 900 or to instruct processing operations.

The output device 917 is composed of a device capable of visually or audibly notifying the user of acquired information. The output device 917 can be, for example, a display such as an LCD, PDP, or OELD, an audio output device such as a speaker or headphones, or a printer device. The output device 917 outputs the results obtained by the processing of the information processing device 900 as video such as text or an image, or as sound such as audio.

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

The drive 921 is a reader/writer for 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 the information processing device 900 or is externally attached. The drive 921 reads out information recorded on the attached removable recording medium 923 and outputs it to the RAM 903. The drive 921 also writes information to the attached removable recording medium 923.

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

The communication device 929 is, for example, a communication interface configured with a communication device for connecting to the network NW. The communication device 929 can be, for example, a wired or wireless LAN (Local Area Network), Bluetooth (registered trademark), or a communication card for WUSB (Wireless USB). The communication device 929 may also be a router for optical communication, a router for ADSL (Asymmetric Digital Subscriber Line), or a modem for various communications. The communication device 929 transmits and receives signals, for example, between the Internet and other communication devices using a predetermined protocol such as TCP/IP. The communication network NW connected to the communication device 929 is a network connected by wire or wirelessly, for example, the Internet, a home LAN, infrared communication, radio wave communication, or satellite communication. The communication device 929 realizes the function as a communication unit.

An imaging device (not shown) such as a camera 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 components such as a lens for controlling the formation of a subject image on the imaging element. The imaging device may capture still images or may capture moving images.

The above describes the configuration and operation of the live distribution system 1 according to the embodiment. This embodiment is merely an example, and it will be understood by those skilled in the art that various modifications are possible in the combination of each component and each process, and that such modifications are also within the scope of the present disclosure.

In the embodiment, as an example of providing a user with information about live streams within the core time in priority over information about live streams outside the core time, a case has been described in which a user is made to take more effort to watch a live stream outside the core time than is necessary to watch a live stream within the core time, but this is not limited to this. For example, when calculating a matching score between a user and a live stream that is currently viewable, a calculation formula may be set so that the matching score of a live stream within the core time is higher than the matching score of a live stream that is not within the core time. Alternatively, live streams outside the core time may be removed from the recommendation list presented to the user. Alternatively, a configuration may be used in which live streams within the core time are included as a priority when generating a recommendation list for a user.

When the distribution information providing unit 302 according to the modified example receives a request for providing information about live streaming from a user terminal of a user via the network NW, the distribution information providing unit 302 refers to the stream DB 314 and generates a list of live streaming that can currently be viewed. This list may include live streaming within the core time and live streaming outside the core time. The distribution information providing unit 302 adjusts this list so that live streaming within the core time is provided to the user with priority over live streaming outside the core time. For example, the distribution information providing unit 302 removes live streaming outside the core time from the list. Alternatively, the distribution information providing unit 302 sorts the list so that live streaming within the core time is ranked higher than live streaming outside the core time. The distribution information providing unit 302 transmits the adjusted list to the requesting user terminal via the network NW. The requesting user terminal generates a live streaming selection screen based on the received list and displays it on the display of the user terminal.

When the user terminal accepts the user's selection of a live stream on the live stream selection screen, it generates a distribution request including the stream ID of the selected live stream and transmits it to the server 10 via the network NW. The distribution information providing unit 302 starts providing the live stream identified by the stream ID included in the received distribution request to the requesting user terminal.

In the embodiment, a case has been described in which the priority of provision is determined depending on whether the live broadcast is within or outside the core time, but this is not limited thereto. For example, the priority of provision may be determined depending on whether the broadcaster is within or outside the core time.

In the embodiment, a case has been described in which a list of live streams during the core time is provided independently as the core time stream list 338, but this is not limited thereto. For example, the stream DB 314 or the user DB 318 may be configured to further store information indicating whether each live stream or each streamer is in the core time, and the remaining time.

In the embodiment, the previous live stream is identified from the recommendation list, but the present invention is not limited to this. For example, the user's viewing history may be stored, and when a previous live stream is requested, the previous live stream may be identified from the viewing history. In this case, when a user wants to view a live stream that was previously viewed but is now outside of the core time and no longer appears in the updated recommendation list, the user can easily return to that live stream.

In the embodiment, the recommendation list is managed by the server 10, but this is not limiting, and the recommendation list of a user may be configured to be managed by the user terminal of the user. In this case, the user terminal obtains the latest contents of the core time distribution list 338 from the server every time the recommendation list is updated.

In the embodiment, a case where a recommendation list is provided for each user has been described, but this is not limiting. For example, ordering by matching score may not be performed. In this case, when the server detects that an app is launched on a user terminal, it starts relaying the live broadcast registered at the top of the core time broadcast list 338 to the user terminal, and when a broadcast change request is made, it refers to the core time broadcast list 338 to determine the next live broadcast to be provided. Alternatively, when the server detects that an app is launched on a user terminal, it transmits a copy of the core time broadcast list 338 to the user terminal. The user terminal refers to the copy to determine the live broadcast to receive. In this case, the server transmits the updated core time broadcast list 338 to each user terminal every time the core time broadcast list 338 is updated.

In the embodiment, the core time distribution list 338 is updated every time the broadcaster presses the core time button, but this is not limited thereto, and new registrations to the core time distribution list 338 may be performed by batch processing. For example, a temporary list may be provided to accumulate information on live broadcasts for which the core time button has been pressed, and the core time distribution list 338 may be periodically updated with the contents of the temporary list.

In the embodiment, a case has been described in which the live streaming room screen for the live streaming during the core time is switched by swiping up and down, but this is not limited to this. For example, instead of the live streaming room screen, videos and images that have been uploaded to the system in advance by the broadcaster of the live streaming during the core time may be displayed and the display may be switched. These videos and images may include objects for viewing the corresponding live streaming (currently ongoing and within the core time). Alternatively, a clip (short video), archive, or preview generated from the live streaming during the core time may be displayed and the display may be switched.

In the embodiment, a case has been described in which the recommendation list is updated every recommendation update period, but this is not limited thereto, and the recommendation list may be updated, for example, every time the core time distribution list 338 is updated, or every master update period. Alternatively, the recommendation list may be updated when the user has viewed all live distributions in the current recommendation list.

In the embodiment, the display of the core time button is started or resumed after the waiting period has elapsed, but this is not limited to the above. For example, the timing at which the core time can start may be determined by factors such as the specification of absolute time or the conditions of the parameters of the live streaming. For example, a certain streamer may start displaying the core time button at 1:00 PM and 4:00 PM, while another streamer may start displaying the core time button at 2:00 PM and 5:00 PM. Alternatively, when the score of a live streaming outside of the core time exceeds a predetermined threshold value or when a special gift is used, the display of the core time button may be started. Alternatively, the display or non-display of the core time may be controlled according to the streamer's level. Alternatively, a list of streamers that can display the core time button may be prepared, and the core time button may be displayed only in live streaming by streamers included in the list. By setting an upper limit on the number of streamers that can be included in this list, the number of live streaming during the core time can be restricted, and the effect of the core time can be enhanced. The list may be managed by an administrator of the live streaming platform, and, for example, inclusion on the list may be used as a prize for event winners.

In the embodiment, a case has been described in which live streaming within core time is prioritized over live streaming outside core time due to the difference in the effort required for viewing, but this is not limited to the above. For example, different recommendation logic, recommendation methods, recommendation algorithms, etc. may be used for live streaming within core time and live streaming outside core time. Alternatively, live streaming within core time may be provided to users in a different manner than live streaming outside core time. For example, a tab may be provided in a live streaming app that collects only live streaming (thumbnails of live streaming) within core time.

The conversion rates from gift points to rewards in the embodiments are merely examples, and may be set as appropriate by, for example, an administrator of the live streaming system.

The technical ideas of the embodiments may be applied to virtual live streaming, which uses an avatar that moves in sync with the streamer's movements instead of an image of the streamer, or live commerce.

In the processing procedures described in this specification, particularly in processing procedures described using flow diagrams and flowcharts, it is possible to omit some of the processes (steps) that make up the processing procedures, to add processes that are not explicitly stated as processes that make up the processing procedures, and/or to change the order of the steps, and processing procedures in which such omissions, additions, or changes in order have been made are also included within the scope of this disclosure as long as they do not deviate from the spirit of this disclosure.

At least a part of the functions realized by the server 10 may be realized by a device other than the server 10, for example, the user terminals 20 and 30. At least a part of the functions realized by the user terminals 20 and 30 may be realized by a device other than the user terminals 20 and 30, for example, the server 10. For example, the superimposition of a predetermined frame image onto an image of video data performed on a viewer's user terminal may be performed on the server 10 or on the distributor's user terminal.

Claims (10)

a starting means for starting a priority provision period of a live distribution when a request for starting the priority provision period is received via a network from a terminal of a distributor who is currently live distributing the live distribution;
A management means for managing a timing at which the next priority provision period of the live distribution can start;
The server includes a processing means for performing a process for providing information of live distribution within a priority provision period to a user in priority over information of live distribution outside the priority provision period. The server according to claim 1, wherein the management means enables the start of the next priority provision period when a waiting period longer than the priority provision period has elapsed since the start of the priority provision period. The server according to claim 2, wherein the management means shortens the waiting period on condition that a distributor who is live streaming or a viewer who is watching the live streaming pays a fee. The server according to claim 2, wherein the management means adjusts the length of the priority provision period or the length of the standby period, or both, in response to changes in parameters during live distribution. The server according to claim 1, wherein the processing means performs processing to provide the user with information about only live broadcasts that are available during a priority provision period. The server according to claim 1, wherein the processing means selects a live stream to be provided to the user from a list of live streams within a priority provision period. The server according to claim 6 further comprises an update means for registering a live stream whose priority provision period has just started in the list, and removing from the list a live stream whose priority provision period has just started in the past and has now expired. a relay unit configured to relay transmission of video data relating to the first live streaming from a terminal of a broadcaster of the first live streaming registered in the list to a terminal of the user,
When the processing means receives a request to change the live stream from the user's terminal via a network, the processing means selects a second live stream that is different from the first live stream from the list;
The server according to claim 6 , wherein the relay means starts relaying transmission of video data relating to the second live streaming from a terminal of a selected distributor of the second live streaming to a terminal of the user. When a request to start a priority provision period is received via a network from a terminal of a distributor who is live streaming, a priority provision period of the live streaming is started;
Managing the timing when the next priority period of the live streaming can begin;
and performing a process for providing information of live streaming within a priority provision period to a user in priority over information of live streaming outside the priority provision period. On the live broadcaster's device,
A function to accept a priority provision period start instruction from the broadcaster during live broadcast,
a function of transmitting a priority provision period start request to the server according to claim 1 via a network when a priority provision period start instruction is received;
A function of starting to accept an instruction to start the next priority provision period when the timing arrives at which the next priority provision period can start, and a computer program for realizing the function.

Images