Server and method

Abstract

To provide a livestreaming mechanism that can reflect actions of livestreamers.SOLUTION: A server comprises: starting means for starting a preferential delivery period of a livestream in response to reception of a preferential delivery period start request from a terminal of a livestreamer performing the livestream over a network; managing means for managing timing when a next preferential delivery period can be started for the livestream; and processing means for performing processing to provide information on livestreams that are in the preferential delivery period to a user in priority over information on livestreams outside of the preferential delivery period.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present disclosure relates to a server and a method. [Background technology]

[0002] With the development of IT technology, the way information is exchanged has also changed. During the Showa era, one-way communication, such as through newspapers and television, was the norm. In the Heisei era, the widespread use of mobile phones and personal computers and significant improvements in internet speeds led to the rise of instant, two-way communication services such as chat services. Furthermore, as storage costs decreased, on-demand video streaming services became more popular. Now, in the Reiwa era, with the increasing functionality of smartphones and further improvements in network speeds, such as those exemplified by 5G, services that enable real-time communication through video, particularly live streaming services, are rapidly gaining popularity. Live streaming services are seeing a rapid increase in users, particularly among young people, as they allow everyone to share the same fun time, even when they are far apart.

[0003] While some users access live streaming platforms by specifying a specific live stream, in most cases, live streaming platforms provide users with information about live streams currently in progress, such as a list of available live streams and profiles of streamers. Users select and watch the live streams they want to watch from the provided information. The live streaming platform can determine the priority of live streams to provide to a user and recommend live streams to a user based on the degree of match between the user and the streamer or live stream (see, for example, Patent Document 1). This provides users with information about live streams that are more likely to interest them, allowing them to enjoy live streams more. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Japanese Patent Application Publication No. 2023-122470 [Patent Document 2] Special Publication No. 2020-521207 [Patent Document 3] Japanese Patent Application Publication No. 2019-164617 Summary of the Invention [Problem to be solved by the invention]

[0005] In the live streaming recommendation mechanism described in Patent Document 1, the system determines which live streaming content to recommend to a user based on a matching score between the user and the live streaming content. Basically, the operations or intentions of the streamer are not directly taken into consideration in the process of determining the recommended content.

[0006] One of the characteristics of live streaming is that it does not follow a fixed scenario, but rather progresses freely depending on the interaction between the streamer and the viewers. Therefore, the excitement and highlights of a live stream go up and down, and it is difficult for a system to accurately predict when such a wave will come.

[0007] Streamers can accurately determine whether the excitement is coming soon, whether the excitement is building, whether they are currently taking a break, or whether the highlights are coming soon. However, in conventional live streaming systems, the streamer's actions are not directly reflected in the selection of streams to be streamed, so the streamer's judgment cannot be utilized.

[0008] The present 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 broadcaster. [Means for solving the problem]

[0009] One aspect of the present invention relates to a server that includes: a start unit that starts 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 live streamer; a management unit that manages when the next priority provision period of the live stream can start; and a processing unit that performs processing to provide information about a live stream that is within the priority provision period to users in priority over information about a live stream that is outside the priority provision period.

[0010] Another aspect of the present invention is a computer program that causes a terminal of a live broadcaster to perform the following functions: to accept a priority provision period start instruction from the broadcaster during live broadcasting; to transmit a priority provision period start request to a server via a network upon accepting the priority provision period start instruction; and to start accepting the next priority provision period start instruction upon the arrival of a timing at which the next priority provision period can be started.

[0011] 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, recording media storing computer programs, etc., are also valid aspects of the present invention. [Effects of the Invention]

[0012] According to the present invention, it is possible to provide a live distribution system that can reflect the actions of distributors. [Brief explanation of the drawings]

[0013] [Figure 1] FIG. 1 is a schematic diagram showing how live streaming is provided in a live streaming system according to an embodiment. [Figure 2] 1 is a schematic diagram showing a configuration of a live distribution system according to an embodiment. [Figure 3] FIG. 3 is a block diagram showing the functions and configuration of the user terminal of FIG. 2. [Figure 4] FIG. 3 is a block diagram showing the functions and configuration of the server in FIG. 2. [Figure 5] FIG. 5 is a data structure diagram showing an example of a stream DB in FIG. 4. [Figure 6] FIG. 5 is a data structure diagram showing an example of a user DB in FIG. 4. [Figure 7] FIG. 5 is a data structure diagram showing an example of the gift DB of FIG. 4. [Figure 8] FIG. 5 is a data structure diagram showing an example of a core time distribution list of FIG. 4. [Figure 9] FIG. 5 is a data structure diagram showing an example of a recommendation list DB of FIG. 4. [Figure 10] 10 is a flowchart showing the flow of a series of processes on a user terminal of a broadcaster during live broadcasting. [Figure 11] FIG. 10 is a representative screen diagram of a live streaming room screen displayed on the display of a user terminal of a broadcaster. [Figure 12] FIG. 10 is a representative screen diagram of a live streaming room screen displayed on the display of a user terminal of a broadcaster. [Figure 13] 10 is a flowchart showing the flow of a series of processes for updating the core time distribution list on the server. [Figure 14] 10 is a flowchart showing the flow of a series of processes in a live distribution system when providing live distribution to a viewer's user terminal. [Figure 15] FIG. 10 is a representative screen diagram of a live streaming room screen displayed on the display of the user terminal of the target user. [Figure 16] FIG. 10 is a representative screen diagram of a live streaming selection screen displayed on the display of the user terminal of the target user. [Figure 17] 1 is a block diagram illustrating an example of a hardware configuration of an information processing device according to an embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0014] Hereinafter, the same or equivalent components, parts, processes, and signals shown in each drawing will be denoted by the same reference numerals, and redundant explanations will be omitted where appropriate. In addition, some of the parts that are not important for the explanation will be omitted in each drawing.

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

[0016] In the embodiment, live streaming information within a priority provision period is provided to users with priority over live streaming information outside the priority provision period. In this specification, this priority provision period is referred to as a core time.

[0017] 1 is a schematic diagram showing how live streams are provided in a live streaming system according to an embodiment. At 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, or 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 ranked by their matching scores with the user. At time t=T, the first live stream 800 has 20 seconds remaining in its core time, the second live stream 802 has 2 minutes remaining in its core time, the third live stream 804 has 2 minutes remaining in its core time, and the fourth live stream 806 has 1 minute 30 seconds remaining in its core time. In addition to these four live streams, the live streaming system also has at least one other live stream in progress that is not during the core time (i.e., outside the core time). However, these four live streams that are during the core time are given priority and provided to users. For example, the system may be configured so that users must spend more effort (such as tapping or searching) to watch live streams that are outside the core time.

[0018] At time t=T+1, 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, the core time for the first live stream 800 has ended, so the first live stream 800 is removed from the list of available streams. At time t=T+1, a user can switch to the third live stream 804 by swiping up on the second live stream 802, or 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 their matching scores with the user. In the case of Figure 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 placed above the fourth live stream 806, and the sixth live stream 810 is placed below the fourth live stream 806.

[0019] As described above, in the live streaming system according to this embodiment, live streams that are currently streaming and are in core time are provided to users with priority over live streams that are currently streaming but are outside of core time. As time passes and the core time for a live stream ends, that live stream is no longer available as a priority target. 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 likely to become popular, is in the midst of a high point, or is approaching a highlight. As a result, live streams that are relatively interesting are provided to users with priority, allowing users to watch more interesting live streams and streamers to increase viewer retention of their live streams.

[0020] In conventional live streaming systems, the system arbitrarily selects live streams to be prioritized at any time, which can lead to situations where a live stream is prioritized when it happens to be quiet, causing viewers to lose interest, or conversely, a live stream is not selected as a priority when it is very popular, resulting in a missed opportunity to attract viewers.The live streaming system according to this embodiment allows streamers to choose when their live streams will be prioritized, thereby reducing or eliminating the mismatches that can occur in conventional technology.

[0021] Additionally, introducing a waiting period can prevent or eliminate abuse of the core time button. The scarcity 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.

[0022] FIG. 2 is a schematic diagram illustrating the configuration of a live streaming system 1 according to an embodiment of the present disclosure. The live streaming system 1 provides an interactive live streaming service that allows real-time interaction between broadcasters (also referred to as live streamers) LV and viewers (also referred to as audiences) AU (AU1, AU2, . . .). As shown in FIG. 2, the live streaming system 1 includes a server 10, a broadcaster-side user terminal 20, and a viewer-side user terminal 30 (30a, 30b, . . .). In addition to broadcasters broadcasting live streams and viewers watching live streams, there are also users who log in to the live streaming platform but do not broadcast or watch. These users are called active users. Broadcasters, viewers, and active users may be collectively referred to as users. The server 10 may be configured with one or more information processing devices connected to a network NW. The user terminals 20 and 30 may be mobile devices such as smartphones, tablet devices, laptop PCs, recorders, portable game consoles, or 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 via various wired or wireless networks NW so that they can communicate with each other.

[0023] The live streaming system 1 involves a broadcaster LV, a viewer AU, and an administrator (not shown) who manages the server 10. The broadcaster LV records and films content such as his or her own singing, talking, performance, fortune telling, and game commentary on his or her own user terminal 20 and uploads it directly to the server 10, thereby transmitting the content in real time. The administrator provides a platform for the live streaming of content on the server 10 and also mediates or manages real-time interactions between the broadcaster LV and the viewer AU. The viewer AU accesses the platform with a user terminal 30, selects desired content, and views it. During the live streaming of this content, the viewer AU performs operations via the user terminal 30 to comment, cheer, or request a fortune telling. The broadcaster LV, who provides the content, responds to such comments, cheers, or requests, and these responses are transmitted to the viewer AU via video and / or audio, thereby establishing two-way communication.

[0024] As used herein, "live streaming" may refer to a data transmission method that enables content recorded on a user terminal 20 of a distributor LV to be played back and viewed on a user terminal 30 of a viewer AU in substantially real time, or may refer to the distribution itself achieved by such a transmission method. Live streaming may be achieved 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 method in which a viewer AU can view content with a predetermined delay while the distributor LV is recording the content. The delay is at least long enough to enable communication between the distributor LV and the viewer AU. However, live streaming is distinct from on-demand distribution, in which the entire recorded content is temporarily stored on a server and then provided to users from the server at any time upon request.

[0025] In this specification, "video data" refers to data including image data (also referred to as video data) generated by the imaging function of the user terminals 20 and 30 and audio data (also referred to as 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 users to view 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 remains substantially unchanged, this embodiment describes the video data after such processing 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 back on the viewer's user terminal are all the same video data.

[0026] In the example of Fig. 2, a broadcaster LV is live streaming a talk. The user terminal 20 of the broadcaster LV records an image and audio of the broadcaster LV while he or she is talking, generating video data, and transmits the video data 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.

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

[0028] Audio and video recording on the user terminal 20 of the broadcaster LV and playback of video data on the user terminals 30a and 30b of viewers AU1 and AU2 are performed substantially simultaneously. When one viewer AU1 inputs a comment on the content of the broadcaster LV's conversation into the user terminal 30a, the server 10 displays the comment in real time on the user terminal 20 of the broadcaster LV and also on the user terminals 30a and 30b of each viewer AU1 and AU2. After reading the comment, the broadcaster LV expands the conversation by overlaying the content. The video and audio of the conversation are output to the user terminals 30a and 30b of each viewer AU1 and AU2, thereby recognizing that a conversation between the broadcaster LV and viewer AU1 has been established. In this way, the live streaming system 1 realizes live streaming that enables two-way communication, not one-way communication.

[0029] Figure 3 is a block diagram showing the functions and configuration of the 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 a computer program, 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.

[0030] A user downloads and installs a live streaming application program (hereinafter referred to as a live streaming app) according to this embodiment from a download site to the user terminal 20, 30 via the network NW. Alternatively, the live streaming app may be pre-installed on the user terminal 20, 30. When the user terminal 20, 30 executes the live streaming app, 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 streaming app will be described as functions of the user terminal 20, 30. These functions are actually functions realized by the user terminal 20, 30 by the live streaming app. 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 a web browser on the user terminal 20, 30 via the network NW and executed by the web browser.

[0031] 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 back, and a non-distribution processing unit 400 that processes requests from active users. A 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 the profile of a broadcaster, or viewing archives. A user terminal on which the distribution unit 100 is active is on the broadcaster's side, i.e., the user terminal that generates the video data, a user terminal on which the viewing unit 200 is active is on the viewer's side, i.e., the user terminal that plays back the video data, and a user terminal on which the non-distribution processing unit 400 is active is the user terminal of an active user.

[0032] 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 via the microphone. The audio control unit 104 acquires audio data from the microphone. The video transmission unit 106 transmits video data including the image data acquired by the imaging control unit 102 and the 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 performed substantially simultaneously.

[0033] 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 video on the display by playing video data to be transmitted by the video transmission unit 106. The distribution-side UI control unit 108 is connected to input means (not shown in FIG. 2) such as a touch panel, keyboard, or display, and acquires input from the distributor via these input means. The distribution-side UI control unit 108 superimposes a predetermined frame image on the video. The frame image includes various user interface objects (hereinafter simply referred to as objects) for receiving input from the distributor, comments entered by viewers, 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.

[0034] 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 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 types of information associated with the live distribution from the server 10 via the network NW.

[0035] 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 distribution. The viewing-side communication unit 204 receives video data related to the live distribution in which the distributor and viewers participate from the server 10 via the network NW.

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

[0037] 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 live broadcast selections by active users, and displays this on the display. The non-broadcast UI control unit 402 generates a profile screen for any user and displays it on the display. The non-broadcast UI control unit 402 plays archives created by recording and filming past live broadcasts.

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

[0039] Fig. 4 is a block diagram showing the functions and configuration of the server 10 of Fig. 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.

[0040] Figure 5 is a data structure diagram showing an example of the stream DB 314 in Figure 4. The stream DB 314 stores information about live streaming currently being performed. The stream DB 314 stores, 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 describes the content of the live streaming.

[0041] In the live streaming platform provided by the live streaming system 1 according to this embodiment, when a user performs a live stream, 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 registered as a streamer ID at one time may be registered as a viewer ID at another time.

[0042] The content tags for live streaming may be tags specified by the streamer when the streamer starts the live streaming, or tags obtained by a model generated by machine learning analyzing the live streaming in real time.

[0043] 6 is a data structure diagram showing an example of the user DB 318 of FIG. 4. The user DB 318 stores information about users. The user DB 318 stores a user ID that identifies a user, points held by the user, rewards granted to the user, the remaining time of the user's waiting period, the user's level, and the user's attributes, in association with each other. The user's attributes include the user's age range, gender, and hair color.

[0044] Points are electronic value circulated within the live streaming platform. Users purchase points using credit cards 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 a streamer receives from the live streaming platform administrator. On the live streaming platform, when a viewer gives a gift to a streamer during or outside of a live stream, the viewer's points are consumed and the streamer's reward increases accordingly.

[0045] The level is an indicator of a user's performance as a broadcaster on the live streaming platform. In another embodiment, the level may be an indicator of a user's performance as a viewer on the live streaming platform, or may be an indicator of a user's performance as both a broadcaster and a viewer. The level may increase or decrease based on the number of live streams, the duration of the live streams, the total viewed time of the live streams, the total viewing time of the live streams as a viewer, 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 within the stream. Alternatively, the level may be determined automatically using predetermined rules or machine learning models.

[0046] Fig. 7 is a data structure diagram showing an example of the gift DB 320 in Fig. 4. The gift DB 320 stores information about gifts that can be used by viewers in live streaming. A gift is electronic data that has the following characteristics. ·Can be purchased with points or money, or given for free. Something that viewers can give to the streamer. Giving a gift to a streamer is also called using a gift or throwing a gift. Some gifts are purchased and used at the same time, while others can be used at any time by the viewer after purchase. When viewers give gifts to streamers, the streamer will receive a corresponding 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.

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

[0048] 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 for that live broadcast is shortened. The waiting period may be shortened by decreasing the remaining time of the current waiting period by a predetermined amount, or by increasing the speed of the waiting period countdown. For example, when the gift "SH1" in FIG. 7 is used during a live broadcast, the remaining time of the waiting period for that live broadcast is decreased by 30 seconds. In other words, if the remaining time is 2 minutes and 15 seconds, using the gift "SH1" reduces the remaining time to 1 minute and 45 seconds.

[0049] FIG. 8 is a data structure diagram showing an example of the core time distribution list 338 of FIG. 4. The core time distribution list 338 is a list of live distributions within the core time (priority provision period). The 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 stores the distributor ID of the distributor of the live distribution within the core time, the stream ID of the live distribution, and the start time of the core time of the live distribution, in association with each other.

[0050] 9 is a data structure diagram showing an example of the recommendation list DB 340 of FIG. 4. The recommendation list DB 340 holds, for each user, a recommendation list that is a list of live broadcasts (hereinafter referred to as recommended broadcasts) within 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 the recommended broadcast for that user in association with the matching score value between the recommended broadcast and that user. In the recommendation list, the recommended broadcasts are sorted in descending order of matching score.

[0051] 4, the core time processing unit 330 controls the core time of a live distribution currently in progress. When the core time processing unit 330 receives a core time start request from the user terminal 20 of a distributor who is currently performing live distribution via the network NW, the core time processing unit 330 starts the core time of the live distribution.

[0052] 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 enables the start of the next core time 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.

[0053] In this embodiment, the length of the core time is fixed as a system parameter. However, 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 in response to changes in parameters during live streaming. The core time processing unit 330 may measure the level of excitement in the live streaming during the core time, and if that level meets a predetermined extension condition, perform processing to extend the core time of the live streaming by a predetermined amount. The level of excitement may be calculated using a formula that inputs the number of comments, the number and value of gifts, the number of cheers, etc. The extension condition may be met when the level of excitement exceeds a threshold or when that state continues for a predetermined period of time. Alternatively, when a viewer uses a core time extension gift during a live streaming session, the core time processing unit 330 may perform processing to extend the core time of the live streaming session. Alternatively, when a payment is received from the broadcaster of a live streaming session within the core time, the core time processing unit 330 may perform processing to extend the core time of the live streaming session. If the length of the core time is adjusted dynamically and / or depending on the user, the user DB 318 may hold the length of the core time for each user.

[0054] 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 no core time start request is 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 shorter 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 sufficiently shorter than the length of the core time. Setting the length of the master update period to be shorter than the length of the core time reduces the number of live distributions that remain in the core time distribution list 338 even after the core time has expired.

[0055] The waiting period management unit 332 shortens the waiting period on the condition that a broadcaster performing a live broadcast or a viewer watching the live broadcast pays a fee. The waiting period management unit 332 adjusts the length of the waiting period according to changes in parameters during the live broadcast. The waiting period management unit 332 may measure the level of excitement of a live broadcast outside of core time, and if the level satisfies a predetermined shortening condition, perform processing to shorten the waiting period of the live broadcast by a predetermined amount. The shortening condition may be satisfied if the level of excitement exceeds a threshold or if that state continues for a predetermined period of time. Conversely, if the level of excitement of a live broadcast outside of core time satisfies a predetermined waiting extension condition, the waiting period management unit 332 may perform processing to extend the waiting period of the live broadcast by a predetermined amount. The waiting extension condition may be satisfied if the level of excitement falls below a threshold, if that state continues for a predetermined period of time, or if the live broadcast is determined to be in an idle state. Alternatively, when a viewer uses a waiting period shortening gift during a live broadcast, the waiting period management unit 332 may perform processing to shorten the waiting period for the live broadcast. Alternatively, when a broadcaster of a live broadcast outside of the core time makes payment, the waiting period management unit 332 may perform processing to shorten the waiting period for the live broadcast.

[0056] The waiting period management unit 332 adjusts the waiting period by increasing or decreasing the remaining time of the waiting period 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 value of the remaining time of the waiting period of user "LR1." In the example of FIG. 6, the waiting period management unit 332 changes the remaining time of the waiting period of user "LR1" from "58 minutes 40 seconds" to "28 minutes 40 seconds."

[0057] The matching unit 334 calculates a matching score between a user logged in to the live streaming platform and each live stream during the core time. The matching unit 334 acquires attributes of the live streams during the core time. More specifically, the matching unit 334 references the stream DB 314 to identify the broadcaster ID and content tag of the live stream during the core time. The matching unit 334 references the user DB 318 to acquire the attributes and level of the broadcaster corresponding to the identified broadcaster ID. The attributes of the live stream during the core time include the attributes and level of the broadcaster of the live stream, and the content tag. The matching unit 334 references the user DB 318 to identify 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 stream during 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). The calculation of such a matching score between a live broadcast and a user may be realized using known matching techniques such as those described in Patent Document 2 and Patent Document 3, for example.

[0058] The recommendation processing unit 336 manages or updates the recommendation list DB 340. When a new user logs in to the live streaming platform, the recommendation processing unit 336 calculates a matching score between the user and each live stream 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 it in the recommendation list DB 340. Specifically, the recommendation processing unit 336 generates a recommendation list for the user by sorting the stream IDs of the live streams within the core time so that the higher the matching score, the higher the ranking. The recommendation processing unit 336 associates the generated recommendation list with the user ID of the user and registers it in the recommendation list DB 340.

[0059] The recommendation processing unit 336 updates the recommendation list for a user each time the recommendation update period for that 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 of the length of the core time. Alternatively, the length of the recommendation update period may be set to a fixed value sufficiently shorter 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 updates to the core time distribution list 338 can be reflected in the recommended distributions in real time. For example, a distributor can feel the effect of increased exposure opportunities due to entering the core time more quickly.

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

[0061] The distribution information providing unit 302 performs processing to provide the user with information about live distributions within the core time in priority over information about live distributions outside the core time. The distribution information providing unit 302 performs processing to provide the user with information about only live distributions within the core time. More specifically, the distribution information providing unit 302 selects a live distribution to provide to the user from among the recommended distributions registered in a recommendation list for each user.

[0062] 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 a live stream outside core time. Live streams "ST1" and "ST3" are provided to users in priority over live stream "ST2." In this embodiment, as shown in Figure 1, live streams selected from a list of recommended streams (consisting of live streams within core time) are provided to users by default, and live streams outside core time are configured to be viewable only by going to a different mode, a different tab, searching, or other more effort.

[0063] 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 streams for that user, generated by the recommendation processing unit 336, to that user's user terminal. The streaming information providing unit 302 begins providing video data of the live streaming that is registered at the top to that user's user terminal. 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 begun to be provided includes the user's user ID. This makes the user a viewer of the live streaming.

[0064] The relay unit 304 relays the transmission of video data from the user terminal 20 of the broadcaster of a live broadcast started by the broadcast information providing unit 302 to the user terminal 30 of the viewer. The relay unit 304 receives, from the viewer-side communication unit 204, a signal indicating a user input by the viewer during the live broadcast, i.e., during playback of the video data. The signal indicating the user input includes a swipe signal indicating a swipe or slide input in any of the up, down, left, or right directions, 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 being viewed by the viewer, and an object ID identifying the object. If the object is a gift icon, the object ID is a gift ID. In this case, the object designation signal becomes a gift use signal indicating the viewer's use of a gift for the broadcaster. Similarly, the relay unit 304 receives, from the broadcasting-side communication unit 110 of the broadcasting unit 100 of the user terminal 20, a signal indicating a user input by the broadcaster during playback of the video data, such as an object designation signal.

[0065] 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 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 begins relaying the transmission of video data related to the selected live stream from the user terminal of the broadcaster of the selected live stream to the user terminal of the viewer who requested the stream change request.

[0066] The gift processing unit 308 updates the user DB 318 so as to increase the distributor's reward according to the reward for the gift identified by the gift ID included in the gift use signal. The gift processing unit 308 refers to the gift DB 320 and identifies the reward corresponding to the gift ID included in the received gift use signal. The gift processing unit 308 updates the user DB 318 so as to add the identified reward to the reward corresponding to the distributor ID included in the gift use signal.

[0067] In response to receiving the gift use signal, the payment processing unit 310 processes the payment of the gift value by the viewer. 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.

[0068] 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 performed by the user terminal 20 of a broadcaster during live streaming. During live streaming, the broadcaster's UI control unit 108 displays a live streaming room screen on the display, including a video of the broadcaster generated by the broadcaster. On the live streaming room screen, the broadcaster can check comments, check how their live streaming appears, give instructions to end the streaming, and give instructions to start core time. The broadcaster UI control unit 108 then activates a core time button on the live streaming room screen displayed on the display (S202). The core time button is an object for receiving an instruction to start core time from the broadcaster during live streaming. Activating such an object, and the deactivation described below, include activating and deactivating the object. For example, activating the core time button may involve starting to display the core time button, starting to accept taps or designations on the core time button, or transitioning the core time button to a state where it can be pressed or designated. Disabling the core time button may involve ceasing the display of the core time button, ceasing the acceptance of taps or designations on the core time button, or transitioning the core time button to a state where it cannot be pressed or designated. The display mode of the core time button may differ when the core time button is enabled and when it is disabled. In this case, enabled core time buttons may be displayed more emphasized than disabled core time buttons. Button emphasis or non-emphasis may be expressed using color, darkness, or size.

[0069] 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 streaming related to the live streaming room screen on which the tapped core time button is displayed, and transmits the request to the server 10 via the network NW (S206).

[0070] 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 streaming room screen displayed on the display (S208). When the time arrives when the next core time can be started, the user terminal 20 begins accepting an instruction to start the next core time. The delivery-side UI control unit 108 determines whether the waiting period has elapsed since the core time button was disabled in step S208 (S210). This determination may be realized, for example, by the delivery-side UI control unit 108 counting using a timing unit such as a timer, or 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 waiting period count 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 determination result 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 start of the previous core time.

[0071] 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, thereby starting to accept an instruction to start the next core time.

[0072] FIG. 11 is a representative screen diagram of a live streaming room screen 630 displayed on the display of the broadcaster's user terminal 20. The live streaming room screen 630 in FIG. 11 corresponds to the state in step S204 of FIG. 10 where the screen is waiting for the user to tap the core time button. The live streaming room screen 630 displays video images generated by the broadcaster's user terminal 20 in real time. The live streaming room screen 630 includes a video image 632 of the broadcaster obtained by playing video data to be transmitted by the video transmission unit 106, a comment display area 634, a broadcast end button 636, and a core time button 638. The broadcasting-side UI control unit 108 generates the live streaming room screen 630 by superimposing other objects, namely, the broadcast end button 636, the comment display area 634, and the core time button 638, on the video image 632 obtained by playing the video data.

[0073] 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 on the live streaming room screen 630.

[0074] The distribution end button 636 is an object for receiving an instruction from the distributor to stop providing live distribution.

[0075] 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 via the network NW to the server 10. 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.

[0076] FIG. 12 is a representative screen diagram of a live streaming room screen 630 displayed on the display of the broadcaster's user terminal 20. The live streaming room screen 630 in FIG. 12 corresponds to the state immediately after the core time button is disabled in step S208 of 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 broadcasting-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 is tapped in this state, the broadcasting-side UI control unit 108 ignores the tap. 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 value of the waiting period or the remaining time obtained from the server 10. When a live broadcast is within core time, the live broadcasting room screen 630 includes a core time object 644. The presence of the core time object 644 allows the broadcaster to know that they are within core time. When the server 10 registers the live broadcast in the core time broadcast list 338 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 core time and transmits it to the user terminal 20 of the broadcaster of the live broadcast 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.

[0077] 12, when the core time expires, the delivery-side communication unit 110 receives an end message from the server 10 informing the user of the end of the core time, and the delivery-side UI control unit 108 includes the end message in the comment display area 634. The delivery-side UI control unit 108 stops displaying the core time object 644. After that, when the standby 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.

[0078] 13 is a flowchart showing the flow of a series of processes 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 broadcaster of the currently ongoing live broadcast (S220). If the core time processing unit 330 does not receive a core time start request (N in S220), it determines whether 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, which will be described later. 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.

[0079] If a core time start request has been 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 the information about the live broadcast of the broadcaster who is the requestor (or sender) of the core time start request received in step S220 at the top of the core time broadcast list 338. The core time processing unit 330 associates the stream ID included in the core time start request, the broadcaster ID of the broadcaster of the live broadcast identified by the stream ID, and the time when the core time start request was received, and registers them at the top of the core time broadcast list 338. 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 streams 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 stream registered in the core time distribution list 338. The core time processing unit 330 deletes from the core time distribution list 338 any live stream whose calculated difference exceeds the length of the core time.

[0080] FIG. 14 is a flowchart showing a series of processes in the live streaming system 1 when providing live streaming 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 the 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. Upon receiving the launch signal, the server 10 detects the launch of the live streaming app on the user terminal that sent the signal.

[0081] The matching unit 334 acquires the attributes and viewing history of the user (hereinafter referred to as the target user) of the user terminal whose activation 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 activation 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 stream list 338 (S244).

[0082] 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 recommendation list in the recommendation list DB 340 (S246). The stream information providing unit 302 transmits information about 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 immediately upon launching the live streaming app. To achieve this, the stream information providing unit 302 starts broadcasting video data of the top-ranked live stream.

[0083] The recommendation processing unit 336 determines whether the recommendation update period has elapsed since the previous update of the recommendation list for the target user (S250). If the recommendation update period has elapsed (Y in S250), the process proceeds to the recommendation list update process of steps S252, S254, and S256 described below. If the recommendation update period has not elapsed (N in S250), the process proceeds to step S258. As a result, the update interval of the recommendation list becomes equal to or equivalent to the recommendation update period.

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

[0085] 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 processing unit 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 this replacement is realized. The process then returns to step S248.

[0086] If the recommendation update period has not elapsed (N in S250), the distribution information providing unit 302 determines whether 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.

[0087] If the broadcast change request is a request for the next live broadcast ("Next Live Broadcast" in S260), the relay unit 304 transmits information about a live broadcast that is one rank lower than the live broadcast currently being viewed by the target user in the recommendation list for the target user to the target user's user terminal via the network NW (S262). When the relay unit 304 receives a swipe signal indicating an up swipe from the target user's user terminal, it refers to the stream DB 314 and identifies a stream ID that includes the target user's user ID included in the swipe signal as a viewer ID. The live broadcast identified by the identified stream ID is the live broadcast 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 video data of the live broadcast identified by the acquired stream ID to the target user's user terminal. 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.

[0088] If the broadcast change request is a request for the previous live broadcast ("Previous Live Broadcast" in S260), the relay unit 304 transmits information about a live broadcast that is ranked one level higher than the live broadcast currently being viewed by the target user in the recommendation list for the target user to the target user's user terminal via the network NW (S264). When the relay unit 304 receives a swipe signal indicating a down swipe from the target user's user terminal, it refers to the stream DB 314 and identifies a stream ID that includes the target user's user ID included in the swipe signal as a viewer ID. The live broadcast identified by the identified stream ID is the live broadcast 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 ranked one level 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 broadcast identified by the acquired stream ID to the target user's user terminal. 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.

[0089] Explaining using the examples of Figures 5 and 9, the target user "VR1" is currently watching live stream "ST1" as shown in Figure 5. When the target user "VR1" swipes up, the relay unit 304 refers to the recommendation list DB 340 in Figure 9 and identifies the live stream "ST4" that is one position 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 then 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 Figure 9 and identifies the live stream "ST1" that is one position 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 then starts relaying the live stream "ST1."

[0090] FIG. 15 is a representative screen diagram of a live streaming room screen 608 displayed on the display of the user device of the target user. When the live streaming app is launched on the user device of the target user and the user device receives video data for the live stream at the top of the recommendation list from the server 10, the viewer UI control unit 202 of the user device generates the live streaming room screen 608 shown in FIG. 15 and displays it on the display. The live streaming room screen 608 displays video images generated by the broadcaster's user device 20 in real time. The live streaming room screen 608 includes 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 an end viewing button 620. The viewer 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 end viewing button 620, on the video image 610 obtained by playing the video data.

[0091] The comment input area 616 accepts comments entered by viewers. The viewer-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. At the same time, the viewer-side UI control unit 202 updates the comment display area 618 to display the comment entered in the comment input area 616.

[0092] The view end button 620 is an object for receiving an instruction from the viewer to stop viewing the live broadcast.

[0093] When the viewer-side UI control unit 202 detects an upward swipe or a downward swipe on the live streaming room screen 608, it generates a swipe signal including the direction of the detected swipe 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.

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

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

[0096] In this embodiment, to watch a live stream outside of core time, a 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 streaming app, to display the live stream selection screen, and then tap the thumbnail of the live stream outside of core time. In this way, the system is designed to make watching live streams outside of core time more time-consuming than watching live streams within core time.

[0097] In the above-described embodiments, examples of the database (DB) are a hard disk and a semiconductor memory. Furthermore, based on the description in this specification, those skilled in the art will understand 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, or the like.

[0098] According to the live streaming system 1 of this embodiment, a broadcaster can specify the timing at which their live stream 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 the timing when their live stream is most appealing, which encourages more viewers to join and stay in the live stream. As a result, interaction with viewers is stimulated, and broadcaster satisfaction is improved. Furthermore, viewers can enjoy the live stream even more because they can watch more appealing live streams one after another with simple operations.

[0099] Furthermore, in the live streaming system 1 according to the present 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 streamers to benefit from the core time.

[0100] Furthermore, in the live streaming system 1 according to this embodiment, the core time can be extended and the waiting period can be adjusted depending on the payment of fees by viewers and broadcasters and parameters of the live streaming, thereby providing viewers and / or broadcasters with the freedom and incentive to adjust their exposure.

[0101] Furthermore, in the live streaming system 1 according to the present embodiment, viewers are provided with live streams during core time in a so-called reel format, and the press of the core time button by the streamer is reflected in the reel list in real time. This reduces the time lag between the instruction to start core time and the increase in exposure, thereby increasing streamer satisfaction, and also attracting viewers by providing them with a succession of highly attractive live streams in reel format.

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

[0103] The information processing device 900 includes a CPU 901, a read-only memory (ROM) 902, and a random-access memory (RAM) 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 also includes an imaging device (not shown) such as a camera. The CPU 901 is an example of a hardware configuration for realizing functions realized by the components described herein. The functions described herein may be realized by circuits programmed to realize the described functions. Circuits programmed to realize the functions described herein include a central processing unit (CPU), a digital signal processor (DSP), a general-purpose processor, an application-specific processor, an integrated circuit, an application-specific integrated circuit (ASIC), 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.

[0104] The CPU 901 functions as an arithmetic processing unit and control unit, and controls all or part of the operations within the information processing device 900 in accordance with various programs recorded in the ROM 902, RAM 903, storage device 919, or removable recording medium 923. For example, the CPU 901 controls all of the operations of the functional units included in the server 10 and the user terminals 20 and 30 in this embodiment. The ROM 902 stores programs and calculation parameters used by the CPU 901. The RAM 903 temporarily stores programs used in the execution of the CPU 901, as well as parameters that change as appropriate during the execution. The CPU 901, ROM 902, and RAM 903 are interconnected by a host bus 907, which is an internal bus such as a CPU bus. The host bus 907 is further connected to an external bus 911, such as a PCI (Peripheral Component Interconnect / Interface) bus, via a bridge 909.

[0105] 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 physical quantities into electrical signals, 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 externally connected device 927 such as a mobile phone that supports 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 the signal 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.

[0106] The output device 917 is configured by a device that can notify the user of acquired information visually or audibly. 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. The output device 917 outputs the results obtained by processing by the information processing device 900 as video such as text or images, or as sound such as audio.

[0107] 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, by 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. The storage device 919 stores programs and various data executed by the CPU 901, as well as various data acquired from the outside.

[0108] The drive 921 is a reader / writer for a removable recording medium 923 such as a magnetic disk, optical disk, magneto-optical disk, or semiconductor memory, and is built into or externally attached to the information processing device 900. The drive 921 reads 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.

[0109] The connection port 925 is a port for directly connecting a device to the information processing device 900. The connection port 925 can 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 can 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 can be exchanged between the information processing device 900 and the external device 927.

[0110] The communication device 929 is, for example, a communication interface configured with a communication device for connecting to a network NW. The communication device 929 can be, for example, a communication card for a wired or wireless LAN (Local Area Network), Bluetooth (registered trademark), or 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, such as the Internet, a home LAN, infrared communication, radio wave communication, or satellite communication. The communication device 929 also functions as a communication unit.

[0111] 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 moving images.

[0112] The above describes the configuration and operation of the live streaming 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.

[0113] In the embodiment, as an example of providing a user with information about live streams within core time prior to information about live streams outside core time, a case has been described in which a user is required to spend more effort watching a live stream outside core time than watching a live stream within core time. However, this is not limited to this. For example, when calculating a matching score between a user and a currently viewable live stream, a calculation formula may be set so that the matching score for a live stream within core time is higher than the matching score for a live stream outside core time. Alternatively, live streams outside core time may be removed from a recommendation list presented to a user. Alternatively, a configuration may be adopted in which live streams within core time are given priority when generating a recommendation list for a user.

[0114] When the distribution information providing unit 302 according to the modified example receives a request for information about live streams from a user terminal via the network NW, it references the stream DB 314 and generates a list of live streams that are currently available for viewing. This list may include live streams during core time and live streams outside core time. The distribution information providing unit 302 adjusts this list so that live streams during core time are provided to the user with priority over live streams outside core time. For example, the distribution information providing unit 302 removes live streams outside core time from the list. Alternatively, the distribution information providing unit 302 sorts the list so that live streams during core time are ranked higher than live streams outside 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 stream selection screen based on the received list and displays it on the display of the user terminal.

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

[0116] In the embodiment, a case has been described in which the priority of provision is divided depending on whether the live broadcast is within or outside of core time, but this is not limited to this, and for example, the priority of provision may be divided depending on whether the broadcaster is within or outside of core time.

[0117] In the embodiment, a case has been described in which a list of live broadcasts within core time is independently set up as core time broadcast list 338, but this is not limited to this. For example, the stream DB 314 or the user DB 318 may be configured to further store information indicating whether each live broadcast or each broadcaster is in core time, and the remaining time.

[0118] In the embodiment, the previous live broadcast is identified from the recommendation list. However, this is not limiting. For example, a user's viewing history may be maintained, and when a previous live broadcast is requested, the previous live broadcast may be identified from the viewing history. In this case, if a user wants to view a live broadcast that was previously viewed but is no longer in the core time and is no longer included in the updated recommendation list, the user can easily return to that live broadcast.

[0119] In the embodiment, the recommendation list is managed by the server 10, but the present invention is not limited to this, and a user's recommendation list may be managed by the user terminal of the user. In this case, the user terminal obtains the latest content of the core time distribution list 338 from the server every time the recommendation list is updated.

[0120] In the embodiment, a recommendation list is provided for each user, but this is not limiting. For example, ranking by matching score may not be necessary. In this case, when the server detects that an app has been launched on a user terminal, it starts relaying the live stream registered at the top of the core time distribution list 338 to the user terminal. When a request to change the distribution is received, it refers to the core time distribution list 338 to determine the next live stream to be provided. Alternatively, when the server detects that an app has been launched on a user terminal, it sends a copy of the core time distribution list 338 to the user terminal. The user terminal then refers to the copy to determine the live stream to receive. In this case, the server sends the updated core time distribution list 338 to each user terminal every time the core time distribution list 338 is updated.

[0121] In the embodiment, the core time distribution list 338 is updated each time the broadcaster presses the core time button, but this is not limiting, and a configuration may be adopted in which new registrations to the core time distribution list 338 are performed by batch processing. For example, a configuration may be adopted in which a temporary list is provided to accumulate information about live broadcasts for which the core time button has been pressed, and the core time distribution list 338 is periodically updated with the contents of the temporary list.

[0122] In the embodiment, a case where the live streaming room screen for a live stream during core time is switched by swiping up or down has been described, but this is not limited to this. For example, instead of the live streaming room screen, videos or images previously uploaded to the system by the broadcaster of the live stream during core time may be displayed and the display may be switched. These videos or images may include objects for viewing the corresponding live stream (currently ongoing and within core time). Alternatively, clips (short videos), archives, or previews generated from the live stream during core time may be displayed and the display may be switched.

[0123] In the embodiment, the recommendation list is updated every recommendation update period, but this is not limiting, and the recommendation list may be updated 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 on the current recommendation list.

[0124] In the embodiment, the display of the core time button is started or resumed after the waiting period has elapsed. However, this is not limited to this. For example, the timing at which core time can begin may be determined based on factors such as absolute time specification or live streaming parameter conditions. For example, one 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, the core time button may start displaying when the score of a live stream outside of core time exceeds a predetermined threshold or when a special gift is used. Alternatively, the display or non-display of core time may be controlled depending on the streamer's level. Alternatively, a list of streamers eligible to display the core time button may be prepared, and the core time button may be displayed only in live streams by streamers included on that list. By setting a limit on the number of streamers that can be included on this list, the number of live streams during core time can be limited, thereby enhancing the effectiveness of core time. The list may be managed by the administrator of the live streaming platform. For example, inclusion on the list may be used as a prize for event winners.

[0125] In the embodiment, a case has been described in which live streams during core time are prioritized over live streams outside core time due to the difference in the effort required to view them, but this is not limited to this. For example, different recommendation logic, recommendation methods, recommendation algorithms, etc. may be used for live streams during core time and live streams outside core time. Alternatively, live streams during core time may be provided to users in a different format than live streams outside core time. For example, a live streaming app may have a tab that collects only live streams (thumbnails of) those during core time.

[0126] The conversion rates from gift points to rewards in the embodiments are merely examples, and may be set appropriately by, for example, an administrator of the live distribution system.

[0127] The technical idea of the embodiment may be applied to virtual live streaming or live commerce, in which an avatar that moves in sync with the streamer's movements is used instead of an image of the streamer.

[0128] 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 processes, 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 intent of this disclosure.

[0129] At least some 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 some 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

1. a start means for starting a priority provision period of a live distribution when a request to start 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 the timing at which the next priority provision period of the live streaming can start; The server includes a processing means for performing processing to provide information on live distribution within a priority provision period to users in preference to information on live distribution outside the priority provision period.

2. 2. The server according to claim 1, wherein the management means enables the start of a next priority provision period when a waiting period longer than the priority provision period has elapsed since the start of the priority provision period.

3. The server according to claim 2 , wherein the management unit shortens the waiting period on condition that a distributor who is currently live streaming or a viewer who is watching the live streaming pays a fee.

4. The server according to claim 2 , wherein the management means adjusts the length of the priority provision period, the length of the standby period, or both in response to changes in parameters during live distribution.

5. 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.

6. The server according to claim 1 , wherein the processing means selects a live broadcast to be provided to the user from a list of live broadcasts within a priority provision period.

7. The server according to claim 6, further comprising an update means for registering a live broadcast whose priority provision period has just started in the list, and for removing from the list a live broadcast whose priority provision period has just started in the past and has expired.

8. 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.

9. When a request to start a priority provision period is received via a network from a terminal of a broadcaster who is currently broadcasting live, the priority provision period of the live broadcast is started; Managing the timing at which the next priority period for the live streaming can begin; and performing a process for providing information about live distribution within a priority provision period to a user in preference to information about live distribution outside the priority provision period.

10. On the device of the live broadcaster, A function to receive instructions from the streamer to start the priority provision period during live streaming, a function of transmitting a priority provision period start request to the server according to claim 1 via a network when receiving a priority provision period start instruction; 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 be started, and a computer program for realizing this function.

Images