Computer program and server

Abstract

To provide a computer program and a server, which provide a good fortune-telling experience through live distribution.SOLUTION: A live distribution system 1 comprises a server 10, a user terminal 20 at the distributor side, and user terminals 30a and 30b at the viewer side. A computer program causes the user terminals 30a and 30b at a playing side of video data related to live distribution to achieve the functions of: receiving video data from the server 10 via a network NW; displaying a plurality of objects associated with fortune-telling on displays of the user terminals at the playing side; receiving designation of one object each designated by users AU1 and AU2 at the playing side from among the plurality of objects; and acquiring, during live distribution, a fortune-telling result entered by a user LV at a generating side to which information corresponding to the designated object is presented.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] The present disclosure relates to computer programs and servers.

Background Art

[0002] With the development of IT technology, the ways of information exchange have changed. In the Showa era, one-way information transmission such as newspapers and televisions was dominant. In the Heisei era, mobile phones and personal computers became popular, and the communication speed of the Internet was greatly improved. As a result, real-time two-way communication services such as chat services emerged, and on-demand video distribution services were accepted with the reduction of storage costs. Currently, in the Reiwa era, with the further improvement of the functions of smartphones and the speed of networks represented by 5G, services that realize real-time communication by video, especially live streaming services, are rapidly increasing in popularity. Live streaming services are expanding their users, especially among young people, as services that allow everyone to share the same enjoyable time even when they are in different places.

[0003] <00000​​​​​​​​​​​​​​​​​"Liver Army", 17LIVE, URL: https: / / helpfeel.com / 17media-jp / %E3%83%A9%E3%82%A4%E3 %83%90%E3%83%BC%E3%82%A2%E3%83%BC%E3%83%9F%E3%83%BC-5d1b19ed60a44d0017857bf6 [Overview of the Initiative] [Problems that the invention aims to solve]

[0005] Given the strong affinity between fortune-telling, which relies heavily on dialogue with clients, and live streaming, which enables two-way communication between broadcasters and viewers, the demand for live fortune-telling is expected to grow. However, traditional live streaming lacks the features necessary to provide a good fortune-telling experience.

[0006] This disclosure was made in light of these challenges, and its purpose is to provide technology that can deliver a good fortune-telling experience through live streaming. [Means for solving the problem]

[0007] Certain aspects of this disclosure relate to a computer program. This computer program provides a user terminal on the playback side of video data related to live streaming with the following functions: a function to receive video data from a server via a network; a function to display multiple objects associated with fortune-telling on the display of the user terminal on the playback side; a function to accept a designation of one of the multiple objects by the user on the playback side; and a function to obtain the fortune-telling result entered by the user on the generating side who has been presented with information corresponding to the designated object during live streaming.

[0008] Another aspect of the present invention is also a computer program. This computer program provides a user terminal on the generating side of the video data related to live streaming with the function of transmitting video data to a server via a network, a function of displaying information corresponding to an object specified by the playback user from among a plurality of objects associated with fortune-telling on the display of the generating user terminal, and a function of receiving input of fortune-telling results from the generating user who has been presented with the information.

[0009] A further aspect of the present invention is a server. This server includes means for relaying the transmission of video data related to live streaming from a user terminal on the generating side to a user terminal on the playback side; means for receiving identification information of an object specified by the user on the playback side from the user terminal on the playback side, from among a plurality of objects associated with fortune-telling displayed on the display of the user terminal on the playback side; means for identifying information corresponding to the specified object based on the received identification information; means for transmitting the identified information to the user terminal on the generating side; means for receiving the fortune-telling result entered by the user on the generating side who was presented with the identified information from the user terminal on the generating side; and means for providing the received fortune-telling result to the user terminal on the playback side.

[0010] Furthermore, any combination of the above components, or any substitution of components or expressions of the present invention between devices, methods, systems, computer programs, recording media storing computer programs, etc., are also valid embodiments of the present invention. [Effects of the Invention]

[0011] According to the present invention, a good fortune-telling experience can be provided through live streaming. [Brief explanation of the drawing]

[0012] [Figure 1] This is a schematic diagram showing the configuration of a live streaming system according to an embodiment. [Figure 2]It is a block diagram showing an example of the hardware configuration of an information processing apparatus according to an embodiment. [Figure 3] It is a block diagram showing the functions and configuration of the user terminal in FIG. 1. [Figure 4] It is a block diagram showing the functions and configuration of the server in FIG. 1. [Figure 5] It is a data structure diagram showing an example of the stream DB in FIG. 4. [Figure 6] It is a data structure diagram showing an example of the user DB in FIG. 4. [Figure 7] It is a data structure diagram showing an example of the schedule DB in FIG. 4. [Figure 8] It is a data structure diagram showing an example of the gift DB in FIG. 4. [Figure 9] It is a data structure diagram showing an example of the customization DB in FIG. 4. [Figure 10] It is a data structure diagram showing an example of the horoscope history DB in FIG. 4. [Figure 11] It is a flowchart showing the flow of a series of processes related to private tarot divination distribution in a live distribution system. [Figure 12] It is a representative screen diagram of a distribution schedule registration screen displayed on the display of the distributor's user terminal. [Figure 13] It is a representative screen diagram of a distribution schedule notification screen displayed on the display of the follower's user terminal. [Figure 14] It is a representative screen diagram of a distribution schedule notification screen displayed on the display of the follower's user terminal. [Figure 15] It is a representative screen diagram of a live distribution room screen displayed on the display of the viewer's user terminal. [Figure 16] It is a flowchart showing the flow of a series of processes related to creating calendar information in the server. [Figure 17] It is a representative screen diagram of a calendar display screen displayed on the display of the user terminal that is the source of the calendar information request. [Figure 18]It is a representative screen diagram of a delivery reminder screen displayed on the display of the user terminal of the deliverer. [Figure 19] It is a chart showing the flow of processing in private tarot fortune-telling delivery. [Figure 20] It is a representative screen diagram of a delivery-side live delivery room screen displayed on the display of the user terminal of the deliverer. [Figure 21] It is a representative screen diagram of a card selection screen displayed on the display of the user terminal of the viewer. [Figure 22] It is a representative screen diagram of a selection result screen displayed on the display of the user terminal of the viewer. [Figure 23] It is a representative screen diagram of a fortune-telling result selection screen displayed on the display of the user terminal of the deliverer. [Figure 24] It is a representative screen diagram of a fortune-telling result explanation screen displayed on the display of the user terminal of the viewer. [Figure 25] It is a representative screen diagram of a fortune-telling history screen displayed on the display of the user terminal of the viewer. [Figure 26] It is a representative screen diagram of a card selection screen displayed on the display of the user terminal of the viewer in the all-viewer participation type tarot fortune-telling delivery according to the modified example. [Figure 27] It is a representative screen diagram of a fortune-telling result display screen displayed on the display of the user terminal of the viewer.

Mode for Carrying Out the Invention

[0013] Hereinafter, the same or equivalent components, members, processes, and signals shown in each drawing are denoted by the same reference numerals, and redundant explanations are omitted as appropriate. In addition, some members that are not important for explanation in each drawing are omitted from the display.

[0014] In the live delivery system according to the embodiment, a mechanism is provided that enables the fortune-telling deliverer to smoothly and effectively conduct fortune-telling live deliveries. As a result, the fortune-telling live deliveries can be enlivened and further popularized.

[0015] Furthermore, this embodiment provides viewers with a function to check the history of their fortune-telling results. One of the drawbacks of live streaming is that the content of the stream is not recorded. Therefore, if a viewer forgets the content of a fortune-telling live stream, there was previously no way to address this. In contrast, this embodiment has a mechanism that saves the results of fortune-telling live streams as data, so viewers can recall the content of a fortune-telling they have forgotten by referring to their history.

[0016] Figure 1 is a schematic diagram showing the configuration of a live streaming system 1 according to an embodiment of the present disclosure. The live streaming system 1 provides a two-way live streaming service that allows broadcasters (also called Livers or Streamers) LV and viewers (also called audiences) AU (AU1, AU2, ...) to communicate in real time. As shown in Figure 1, the live streaming system 1 comprises a server 10, a user terminal 20 on the broadcaster's side, and user terminals 30 (30a, 30b, ...) on the viewer's side. Broadcasters and viewers are sometimes collectively referred to as users. The server 10 may be composed of one or more information processing devices connected to a network NW. User terminals 20 and 30 may be mobile terminals such as smartphones, tablet terminals, laptop PCs, recorders, portable game consoles, or wearable devices, or they may be stationary devices such as desktop PCs. The server 10, user terminals 20 and 30 are connected to each other via various wired or wireless networks NW so that they can communicate with one another.

[0017] The live streaming system 1 involves a streamer (LV), a viewer (AU), and an administrator (not shown) who manages the server 10. The streamer (LV) is a person who broadcasts content in real time by recording or videotaping their own songs, talks, performances, fortune-telling, game commentary, etc., on their user terminal 20 and uploading it directly to the server 10. In this embodiment, the streamer (LV) provides fortune-telling to the viewer (AU) through live streaming. The streamer (LV) may or may not be a fortune teller. The administrator provides a platform for live streaming of content on the server 10 and mediates or manages real-time interactions between the streamer (LV) and the viewer (AU). The viewer (AU) accesses the platform on their user terminal 30 to select and watch the desired content. During the live streaming of this content, the viewer (AU) can comment or show support via their user terminal 30, and the streamer (LV) providing the content responds to such comments and support. This response is transmitted to the viewer (AU) via video and / or audio, thus establishing two-way communication.

[0018] In this specification, "live streaming" may mean a data transmission method that enables content recorded on the broadcaster LV's user terminal 20 to be played back and viewed on the viewer AU's user terminal 30 in substantially real time, or it may mean the streaming itself realized by such a transmission method. Live streaming may be realized using existing live streaming technologies such as HTTP Live Streaming, Common Media Application Format, Web Real-Time Communications, Real-Time Messaging Protocol, or MPEG DASH. Live streaming includes a transmission method that enables the viewer AU to view the content with a predetermined delay while the broadcaster LV is recording the content. Regarding the magnitude of the delay, at least a delay large enough for communication between the broadcaster LV and the viewer AU to take place is permitted. However, live streaming is distinguished from so-called on-demand streaming, where the entire data of the recorded content is temporarily stored on a server, and then the data is provided to the user from the server at any time requested by the user.

[0019] In this specification, "video data" refers to data that includes image data (also called video data) generated by the imaging function of user terminals 20 and 30, and audio data (also called audio data) generated by the audio input function of user terminals 20 and 30. The video data is played back on user terminals 20 and 30, enabling users to view the content. In this embodiment, it is assumed that between the time the video data is generated on the distributor's user terminal and the time it is played back on the viewer's user terminal, processing is performed to change the format, size, and specifications of the data, such as compression, decompression, encoding, decoding, and transcoding. Since the content represented by the video data (e.g., moving images and sound) does not substantially change before and after such processing, in this embodiment, the video data after such processing is described as being the same as the video data before such processing. That is, 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.

[0020] In the example shown in Figure 1, the streamer LV is live-streaming fortune-telling. The streamer LV's user terminal 20 generates video data by recording the image and sound of the streamer LV performing the fortune-telling, and transmits it to the server 10 via the network NW. In addition, the user terminal 20 displays the recorded video VD of the streamer LV on its display, allowing the streamer LV to confirm the content of the broadcast.

[0021] The user terminals 30a and 30b of viewers AU1 and AU2, who requested the platform to view the live stream of broadcaster LV, respectively receive video data related to the live stream via the network NW. By playing the received video data, they display video images VD1 and VD2 on their displays and output sound from their speakers. The video images VD1 and VD2 displayed on each user terminal 30a and 30b are substantially identical to the video image VD captured by broadcaster LV's user terminal 20, and the sound output by each user terminal 30a and 30b is substantially identical to the sound recorded by broadcaster LV's user terminal 20.

[0022] The recording and video recording on the broadcaster LV's user terminal 20 and the playback of video data on the viewer AU1 and AU2's user terminals 30a and 30b are performed substantially simultaneously. When one viewer AU1 enters a comment on the content of the broadcaster LV's fortune-telling into user terminal 30a, server 10 displays the comment in real time on the broadcaster LV's user terminal 20, as well as on the user terminals 30a and 30b of each viewer AU1 and AU2. When the broadcaster LV reads the comment and engages in conversation over its content, the video and audio of that conversation are output to the user terminals 30a and 30b of each viewer AU1 and AU2, thereby recognizing that a conversation has taken place between the broadcaster LV and viewer AU1. In this way, the live streaming system 1 realizes live streaming that enables two-way communication rather than one-way communication.

[0023] Figure 3 is a block diagram showing the functions and configuration of user terminal 20 in Figure 1. User terminal 30 has the same functions and configuration as user terminal 20. Each block shown in Figure 3 and subsequent block diagrams can be realized hardware-wise by elements and mechanical devices such as the CPU of a computer, and software-wise by computer programs, etc., but here we are depicting functional blocks realized through the cooperation of these. Therefore, it will be understood by those skilled in the art who have read this specification that these functional blocks can be realized in various ways by combinations of hardware and software.

[0024] The broadcaster (LV) and viewer (AU) download and install the live streaming application program according to this embodiment (hereinafter referred to as the live streaming app) from a download site via the network (NW) to the user terminals 20 and 30. Alternatively, the live streaming app may be pre-installed on the user terminals 20 and 30. When the live streaming app is executed by the user terminals 20 and 30, the user terminals 20 and 30 communicate with the server 10 via the network (NW) and realize various functions. Hereinafter, the functions realized by the execution of the live streaming app by the user terminals 20 and 30 (their CPUs or other processors) will be described as functions of the user terminals 20 and 30. These functions are actually functions that the live streaming app enables on the user terminals 20 and 30. In other embodiments, these functions may be realized by a computer program written in a programming language such as HTML (HyperText Markup Language), which is transmitted from the server 10 to the web browser of the user terminals 20 and 30 via the network (NW) and executed by that web browser.

[0025] The user terminal 20 includes a distribution unit 100 that generates video data recording the user's image and voice and provides it to the server 10, and a viewing unit 200 that retrieves the video data from the server 10 and plays it back. The user activates the distribution unit 100 when distributing data, and the viewing unit 200 when viewing data. The user terminal with the distribution unit 100 active is the distributor side, i.e., the user terminal that generates the video data, and the user terminal with the viewing unit 200 active is the viewer side, i.e., the user terminal that plays back the video data.

[0026] The distribution unit 100 includes an image capture control unit 102, an audio control unit 104, a video transmission unit 106, and a distribution-side UI control unit 108. The image capture control unit 102 is connected to a camera (not shown in Figure 3) and controls image capture by the camera. The image capture control unit 102 acquires image data from the camera. The audio control unit 104 is connected to a microphone (not shown in Figure 3) and controls audio input from the microphone. The audio control unit 104 acquires audio data from the microphone. The video transmission unit 106 transmits video data, including image data acquired by the image capture control unit 102 and audio data acquired by the audio control unit 104, to the server 10 via the network NW. The transmission of video data by the video transmission unit 106 is performed in real time. That is, the generation of video data by the image capture 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. 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 Figure 3) and displays moving images on the display by playing the video data that is to be transmitted by the video transmission unit 106. The distribution-side UI control unit 108 displays operation objects and instruction receiving objects on the display and accepts tap input from the broadcaster.

[0027] The viewing unit 200 includes a viewing-side UI control unit 202, a superimposed information generation unit 204, and an input information transmission unit 206. The viewing unit 200 receives video data related to live streaming from the server 10 via a network NW. The viewing-side UI control unit 202 controls the UI for viewers. The viewing-side UI control unit 202 is connected to a display and speaker (not shown in Figure 3) and plays the received video data to display the video on the display and output sound from the speaker. The simultaneous output of an image on the display and sound from the speaker can be described as "video data being played." The viewing-side UI control unit 202 is connected to input means such as a touch panel, keyboard, and display (not shown in Figure 3) and acquires user input through these input means. The superimposed information generation unit 204 superimposes a predetermined frame image onto the video data image acquired from the server 10. The frame image includes various user interface objects (hereinafter simply referred to as "objects") for receiving input from the user, comments entered by the viewer, and information obtained from the server 10. The input information transmission unit 206 transmits the user input obtained by the viewer-side UI control unit 202 to the server 10 via the network NW.

[0028] Figure 4 is a block diagram showing the functions and configuration of server 10 in Figure 1. Server 10 comprises a distribution information provision unit 302, a relay unit 304, a schedule management unit 306, a gift processing unit 308, a payment processing unit 310, a tarot processing unit 312, a stream DB 314, a schedule DB 316, a user DB 318, a gift DB 320, a customization DB 322, and a fortune-telling history DB 324.

[0029] Figure 5 is a data structure diagram showing an example of the Stream DB 314 in Figure 4. The Stream DB 314 holds information about live streaming that is currently taking place. The Stream DB 314 associates a Stream ID, which identifies a live stream on the live streaming platform provided by the Live Streaming System 1, a Streamer ID, which is a user ID that identifies the streamer of the live stream, and a Viewer ID, which is a user ID that identifies the viewers of the live stream. In the live streaming platform provided by the Live Streaming System 1 according to this embodiment, when a user conducts a live stream, that user becomes a streamer, and when the same user watches a live stream conducted by another user, they become a viewer. Therefore, the distinction between streamer and viewer is not fixed, and a user ID that was registered as a streamer ID at one time may be registered as a viewer ID at another time.

[0030] Figure 6 is a data structure diagram showing an example of the user DB318 in Figure 4. The user DB318 holds information about users. The user DB318 associates a user ID that identifies a user, the points that the user has, follower IDs which are the user IDs of other users that the user follows, and followed-by IDs which are the user IDs of other users that the user follows. Points are electronic value that circulates within the live streaming platform. When a streamer receives a gift from a viewer during a live stream, the streamer's points increase by the value corresponding to that gift. Points are used, for example, to determine the amount of reward or money that a streamer receives from the administrator of the live streaming platform.

[0031] Figure 7 is a data structure diagram showing an example of the schedule DB 316 in Figure 4. The schedule DB 316 holds the schedule of planned live streams. The schedule DB 316 stores, in association with a schedule ID that identifies the schedule, a broadcaster ID of the broadcaster who will be conducting the live stream related to that schedule, the scheduled start date and time of the live stream, the scheduled end date and time of the live stream, a flag indicating whether or not the live stream is a private stream, a specific viewer ID, and a tarot type. In the following, this embodiment will describe the case in which a broadcaster conducts a live stream of tarot readings, but it will be apparent to those skilled in the art who have read this specification that the technical ideas of this embodiment can also be applied to live streams of other types of fortune-telling, such as astrology.

[0032] A private broadcast is a live broadcast in which only specific viewers designated in advance, other than the broadcaster, can participate. The technology for realizing such private broadcasts is publicly known and will not be described in detail in this specification. A schedule with the private flag set to "Y" and a specific viewer ID registered is a scheduled live broadcast in which only the specific viewer identified by the specific viewer ID can participate. For example, the schedule with schedule ID "SC002" in the schedule DB316 in Figure 7 is a live broadcast scheduled to be broadcast by broadcaster ID "ABCFO" from 10:00 to 11:00 on January 3rd, and is a private broadcast in which only the specific viewer identified by specific viewer ID "001A" can participate. In this live broadcast, the broadcaster plans to offer a one-card tarot reading to the specific viewer. A schedule with the private flag set to "Y" and no specific viewer ID registered is a private broadcast in which reservations are being accepted or can be made. For example, the schedule with schedule ID "SC004" in schedule DB316 in Figure 7 is the schedule for a private two-card tarot reading broadcast by broadcaster ID "ABCFO" from 11:00 to 11:30 on January 5th. Since no specific viewer ID is registered, it indicates that the private broadcast is currently accepting reservations to participate.

[0033] Figure 8 is a data structure diagram showing an example of the gift DB320 in Figure 4. The gift DB320 holds information about gifts that viewers can use during live streaming. A gift is electronic data with the following characteristics: • Can be purchased with points or money, or given away for free. • Something that viewers can send to streamers. Sending a gift to a streamer is also called using a gift or throwing a gift. Some gifts require both purchase and use to occur simultaneously, while others allow viewers to use them at their own discretion after purchase. When a viewer sends a gift to a streamer, the streamer is awarded points corresponding to the gift, and in some cases, effects associated with the gift occur. For example, an effect corresponding to the gift may appear on the live stream screen.

[0034] The Gift DB320 stores a Gift ID that identifies a gift, the points awarded to the streamer when the gift is sent to the streamer, and the Schedule ID of the schedule if the gift corresponds to a schedule. Viewers can send a gift to the streamer during a live stream by paying a price corresponding to the points awarded for the desired gift. This payment may be made by an appropriate electronic payment method, for example, by the viewer paying the administrator points equivalent to the points awarded (for example, the points awarded themselves, points obtained by multiplying the points awarded by a predetermined coefficient such as 1.2, or points obtained by adding a predetermined fee to the points awarded). Alternatively, payment may be made by bank transfer or credit card.

[0035] Gifts associated with a schedule ID may also be called schedule gifts, and they allow viewers to purchase a streamer's tarot reading session as a gift during a live stream. When a viewer sends a schedule gift to a streamer, a private stream is set up between the streamer and the viewer. Sending a schedule gift is a form of reservation for participation in a private stream, which involves payment.

[0036] Figure 9 is a data structure diagram showing an example of the customized DB322 in Figure 4. The customized DB322 holds the content of tarot readings customized for each broadcaster. The customized DB322 associates and stores the broadcaster ID that identifies the broadcaster, the tarot type, the card ID and its description that identify the tarot card, the choices of fortune-telling results presented to the broadcaster when a viewer draws that tarot card, and comments. The customized DB322 is configured so that broadcasters can register and update its content. Broadcasters access the customized DB322 on the server 10 via the user terminal 20 and view the content of the tarot readings they have registered. Broadcasters update and save the registered content as needed. The user terminal 20 and the server 10 are configured to enable broadcasters to perform such operations. In the customized DB322, multiple choices are registered for each card ID, and these multiple choices differ depending on the card ID.

[0037] Figure 10 is a data structure diagram showing an example of the fortune-telling history DB324 in Figure 4. The fortune-telling history DB324 stores a history of fortune-telling results entered by the broadcaster and presented to viewers during a live tarot reading. The fortune-telling history DB324 stores the user ID of the viewer who participated in the live tarot reading, the start time of the live broadcast, the broadcaster's ID, the type of tarot reading performed in the live broadcast, and the fortune-telling result, all associated with each other. The fortune-telling result includes the card ID of the tarot card presented in the tarot reading and the viewer's fortune entered or selected by the broadcaster in relation to that card.

[0038] Returning to Figure 4, when the distribution information provision unit 302 receives notification from the broadcaster's user terminal 20 via the network NW that a live broadcast will be started, it registers the stream ID that identifies the live broadcast and the broadcaster ID of the broadcaster of the live broadcast in the stream DB 314. When the distribution information provision unit 302 receives a request for information about live broadcasts from the viewer's user terminal 30's viewing unit 200 via the network NW, it refers to the stream DB 314 and generates a list of currently viewable live broadcasts. The distribution information provision unit 302 sends the generated list to the requesting user terminal 30 via the network NW. The viewer-side UI control unit 202 of the requesting user terminal 30 generates a live broadcast selection screen based on the received list and displays it on the user terminal 30's display.

[0039] When the input information transmission unit 206 of the user terminal 30 receives a live stream selection from a viewer on the live stream selection screen, it generates a distribution request including the stream ID of the selected live stream and sends it to the server 10 via the network NW. The distribution information provision unit 302 starts providing the live stream identified by the stream ID included in the received distribution request to the requesting user terminal 30. The distribution information provision unit 302 updates the stream DB 316 so that the viewer ID of the viewer of the requesting user terminal 30 is included in the viewer ID of the stream ID.

[0040] The relay unit 304 relays the transmission of video data from the broadcaster's user terminal 20 to the viewer's user terminal 30 in a live broadcast initiated by the distribution information provision unit 302. The relay unit 304 receives a signal from the input information transmission unit 206 indicating user input from the viewer during video data playback. The signal indicating user input may be an object specification signal indicating the specification of an object displayed on the user terminal 30's display, and this object specification signal includes the viewer's viewer ID, the broadcaster ID of the broadcaster conducting the live broadcast that the viewer is watching, and an object ID that identifies the object. If the object is a gift, the object ID becomes the gift ID. Similarly, the relay unit 304 receives a signal indicating user input from the broadcaster during video data playback, such as an object specification signal, from the distribution unit 100 of the user terminal 20.

[0041] The schedule management unit 306 manages the live streaming schedule on the live streaming platform provided by the live streaming system 1. The schedule management unit 306 communicates with the streamer's user terminal 20 to receive requests from the streamer to register a new live streaming schedule or to modify or delete an existing schedule. The schedule management unit 306 updates the schedule DB 316 based on the received new registration request or modification / deletion request. The schedule management unit 306 also notifies the streamer's followers when a new schedule is registered.

[0042] The schedule management unit 306 receives a calendar information request from the user to obtain the live streaming schedule by communicating with the user's user terminal 30. The schedule management unit 306 obtains the necessary information by referring to the schedule DB 316 and provides it to the user terminal 30.

[0043] When a viewer inputs a command to send a scheduled gift to the broadcaster during a live stream into the user terminal 30, the user terminal 30 sends an object specification signal containing the gift ID of the specified scheduled gift to the server 10. The gift processing unit 308 refers to the gift DB 320 and identifies the grant points and schedule ID corresponding to the scheduled gift identified by the gift ID included in the object specification signal. The gift processing unit 308 updates the user DB 318 to increase the broadcaster's points according to the identified grant points. For example, the gift processing unit 308 updates the user DB 318 to add the identified grant points to the points corresponding to the broadcaster ID included in the object specification signal.

[0044] The gift processing unit 308 notifies the schedule management unit 306 of the identified schedule ID. The schedule management unit 306 updates the schedule DB 316 to register the viewer ID included in the object specification signal as the specific viewer ID for the schedule identified by the notified schedule ID. With this update, the viewer's reservation to participate in the private broadcast is considered complete. The gift processing unit 308 deletes the schedule gift identified by the gift ID included in the object specification signal from the gift DB 320. This prevents duplicate reservations.

[0045] The payment processing unit 310 processes the payment of consideration associated with the scheduled gift by the viewer. The payment processing unit 310 updates the user DB 318 to subtract the points for the consideration of the scheduled gift, identified by the gift ID included in the object designation signal, from the viewer's points, identified by the viewer ID included in the object designation signal.

[0046] The functions of the tarot processing unit 312 will be described later.

[0047] The operation of the live streaming system 1 with the above configuration will now be explained. Figure 11 is a flowchart showing the sequence of processes related to a private tarot reading broadcast in the live streaming system 1. A broadcaster who intends to broadcast a private tarot reading accesses the server 10 via the user terminal 20 and registers a broadcast schedule (S502). The schedule management unit 306 registers the broadcast schedule received from the broadcaster in the schedule DB 316. The schedule management unit 306 accepts push notifications, gifting during live broadcasts, and reservations via the broadcast calendar for the registered broadcast schedule (S504). Once a reservation is complete and the broadcast start date and time are approaching, the schedule management unit 306 sends a reminder notification to the broadcaster's user terminal 20 and the user terminal 30 of the reserved viewer (S506). The broadcaster starts the private tarot reading broadcast via the user terminal 20, and the reserved viewer participates in the broadcast via the user terminal 30 (S508). After the broadcast ends, if requested by the viewer, the user terminal 30 of the viewer who participated in the broadcast displays a tarot reading history screen including the tarot reading results on the display (S510).

[0048] Figure 12 is a representative screen view of the distribution schedule registration screen 600 displayed on the display of the distributor's user terminal 20 in step S502 of Figure 11. The distribution schedule registration screen 600 has an area for receiving input of the scheduled start date and time of distribution, an area for receiving input of the scheduled end date and time of distribution, a checkbox for specifying whether or not the distribution is a private tarot reading distribution, an area for receiving selection of the type of tarot reading in a pull-down format, an area for setting the points required to reserve the distribution, a checkbox for specifying whether or not to make the reservation an auction format, a checkbox for specifying whether or not to notify the distributor's followers that the schedule has been registered along with the distribution schedule registration, a register button, and a cancel button. The distributor enters the necessary information in each area of ​​the distribution schedule registration screen 600 and taps the register button. When the user terminal 20 detects the tap of the register button, it acquires the information entered in each area of ​​the distribution schedule registration screen 600. The user terminal 20 generates a schedule registration request signal including the acquired information and sends it to the server 10 via the network NW. The schedule management unit 306 registers a new distribution schedule (hereinafter referred to as the private tarot reading distribution schedule) in the schedule DB 316 based on the various information contained in the received schedule registration request signal.

[0049] Figure 13 is a representative screen view of the distribution schedule notification screen 602 displayed on the follower's user terminal 30 in step S504 of Figure 11. The distribution schedule notification screen 602 in Figure 13 corresponds to the case where the distributor checks "Notify followers" on the distribution schedule registration screen 600 in Figure 12 and taps the registration button without checking "Auction". In this case, the schedule management unit 306 identifies the distributor's followers, identified by the distributor ID included in the received schedule registration request signal, by referring to the user DB 318. The schedule management unit 306 notifies the identified follower's user terminal 30 of the private tarot reading distribution schedule. Based on this notification, the user terminal 30 displays the distribution schedule notification screen 602 on its display. The distribution schedule notification screen 602 displays the start date and time of the registered private tarot reading distribution, the distributor, the type of tarot reading, and the number of points required for reservation. The distribution schedule notification screen 602 further includes a button 604 for receiving instructions from followers to reserve participation in a private tarot reading distribution, along with acceptance of payment. When button 604 is tapped, the user terminal 30 generates a reservation request signal including the follower's user ID and sends it to the server 10 via the network NW.

[0050] Upon receiving a reservation request signal, the server performs the following processing: (1) The schedule management unit 306 updates the schedule DB 316 so that the user ID included in the received reservation request signal is registered as the specific viewer ID for the private tarot reading distribution schedule. (2) The gift processing unit 308 updates the user DB 318 to increase the points of the broadcaster of a private tarot reading broadcast according to the number of points required to reserve the broadcast. (3) The payment processing unit 310 updates the user DB 318 to deduct the number of points required to reserve a private tarot reading from the points of the user identified by the user ID included in the received reservation request signal. Upon completion of these processes, your reservation to participate in the private tarot reading session is complete.

[0051] Figure 14 is a representative screen view of the distribution schedule notification screen 606 displayed on the follower's user terminal 30 in step S504 of Figure 11. The distribution schedule notification screen 606 in Figure 14 corresponds to the case where the broadcaster checks "Notify followers" and "Auction" and taps the registration button on the distribution schedule registration screen 600 in Figure 12. In this case, unlike in Figure 13, an auction is held for reservations of the private tarot reading broadcast. The technology for realizing such an auction is publicly known and will not be described in detail herein. After the auction, the process of completing the reservation of the private tarot reading broadcast as a specific viewer by the winning follower is the same as the process described with respect to Figure 13.

[0052] Figure 15 is a representative screen view of the live streaming room screen 608 displayed on the viewer's user terminal 30. The live streaming room screen 608 has an image 610 of the broadcaster obtained by playing video data received from the server 10, and a plurality of gift icons 612, each representing a corresponding scheduled gift. When playback of the video data begins, that is, when viewing of the live stream begins, the relay unit 304 of the server 10 refers to the gift DB 320 to identify an available gift ID. For scheduled gifts, the relay unit 304 refers to the schedule DB 316 to identify a reservable private tarot reading streaming schedule registered by the broadcaster of the live stream that is about to be viewed. The relay unit 304 refers to the gift DB 320 to identify the gift ID corresponding to the identified private tarot reading streaming schedule as an available gift ID. The relay unit 304 generates gift information including the identified gift ID and sends it to the user terminal 30. The gift information associates the gift ID corresponding to the private tarot reading streaming schedule and holds the start date and time, end date and time, tarot type, and compensation according to the points awarded. The superimposed information generation unit 204 of the user terminal 30 includes a gift icon 612 of the scheduled gift, identified by the gift ID included in the gift information, in the frame image. This gift icon 612 displays the start date and time, end date and time, tarot type, and price of the private tarot reading delivery schedule corresponding to the scheduled gift in text. The viewer-side UI control unit 202 displays a moving image on the display with the frame image superimposed.

[0053] The broadcaster calls upon viewers during the live stream to purchase a scheduled gift corresponding to the gift icon 612. When the viewer-side UI control unit 202 receives the viewer's selection of a scheduled gift, i.e., the specification of the gift icon 612, the input information transmission unit 206 generates an object specification signal including the gift ID of the specified scheduled gift, the viewer ID, and the broadcaster ID, and sends it to the server 10 via the network NW. The processing at the server 10 after receiving this object specification signal is as described above. In addition, the gift processing unit 308 updates the user DB 318 so that viewers identified by the viewer ID included in the received object specification signal follow the broadcaster identified by the broadcaster ID included in the object specification signal. In other words, a mechanism is provided where viewers automatically become followers of the broadcaster by reserving the broadcaster's private tarot reading stream, or to put it another way, viewers cannot participate in the broadcaster's private tarot reading stream unless they are followers of the broadcaster. This promotes following among users and further revitalizes the live streaming platform. Note that instead of or in addition to following, subscriptions such as Army described in Non-Patent Literature 2 may be used.

[0054] Thus, the user terminal 30 has a function that, during a regular live stream conducted before the start of a private tarot reading session, accepts instructions from viewers to reserve participation in the private tarot reading session, along with their acceptance of payment. For example, detecting a tap on the gift icon 612 corresponds to accepting such an instruction.

[0055] Figure 16 is a flowchart showing the sequence of processes involved in creating calendar information on server 10. The schedule management unit 306 communicates with the user's user terminal 30 and receives a calendar information request from the user terminal 30 to obtain the live streaming schedule (S602). The schedule management unit 306 refers to the user DB 318 and obtains the follow destination ID corresponding to the user ID of the requesting user included in the received calendar information request (S604). The schedule management unit 306 refers to the schedule DB 316 and identifies the live streaming schedule registered by the streamer identified by the obtained follow destination ID (S606). If the identified live streaming schedule includes a private tarot reading streaming schedule (YES in S608), the schedule management unit 306 repeats the following process consisting of S610, S612, S614, and S616 until all of the included private tarot reading streaming schedules are processed.

[0056] The Schedule Management Unit 306 refers to the Schedule DB 316 and determines whether a specific viewer ID is registered in the Private Tarot Reading Streaming Schedule (S610). If it is not registered (NO in S610), the Schedule Management Unit 306 retrieves the points corresponding to the Private Tarot Reading Streaming Schedule from the Gift DB 320 (S612). The process then returns to step S610. If it is registered (YES in S610), the Schedule Management Unit 306 determines whether the registered specific viewer ID matches the user ID of the requesting user included in the calendar information request (S614). If they match (YES in S614), nothing is done and the process returns to step S610. If they do not match (NO in S614), the Schedule Management Unit 306 removes the mismatched Private Tarot Reading Streaming Schedule from the Live Streaming Schedule identified in step S606 (S616). The process then returns to step S610.

[0057] If it is determined in step S608 that the schedule is not included (NO in S608), or after all private tarot reading streaming schedules have been processed, the schedule management unit 306 retrieves information on the identified live streaming schedule from the schedule DB 316 (S618). As a result, the following information is obtained: (1) information on non-private live streaming schedules registered by streamers followed by the requesting user, (2) information on private tarot reading streaming schedules that the requesting user has booked among the private tarot reading streaming schedules registered by streamers followed by the requesting user, and (3) information on private tarot reading streaming schedules that are available for booking among the private tarot reading streaming schedules registered by streamers followed by the requesting user, and the points to be awarded.

[0058] The schedule management unit 306 transmits the live streaming schedule information obtained in step S618 to the user terminal 30 that sent the calendar information request (S620). Figure 17 is a representative screen view of the calendar display screen 614 displayed on the display of the user terminal 30 that sent the calendar information request. The calendar display screen 614 has a schedule item 616 corresponding to (1) above, a schedule item 618 corresponding to (2) above, and a schedule item 620 corresponding to (3) above. The schedule item 618 corresponding to (2) above has a button 622 that displays text indicating that the schedule is reserved. This button 622 is inactive before the start of the live streaming related to the schedule, and becomes active when the live streaming starts, allowing the user to enter the streaming room of the live streaming by tapping the button 622. The schedule item 620 corresponding to (3) above displays the start date and time of the private tarot reading stream, the streamer, the type of tarot reading, and the number of points required for reservation. The schedule item 620 further includes a button 624 for receiving instructions from the user to reserve participation in a private tarot reading session, along with acceptance of payment. When button 624 is tapped, the user terminal 30 generates a reservation request signal including the user's user ID and sends it to the server 10 via the network NW. Subsequent processing is as described with reference to Figure 13.

[0059] Figure 18 is a representative screen view of the distribution reminder screen 626 displayed on the broadcaster's user terminal 20 in step S506 of Figure 11. The distribution reminder screen 626 includes the start date and time of the private tarot reading distribution schedule to be reminded, a specific viewer ID, a tarot type, a start button, and a later button. When the broadcaster taps the start button, the private tarot reading distribution begins. The broadcaster can also start the private tarot reading distribution by a method other than the distribution reminder screen 626.

[0060] Figure 19 is a chart showing the processing flow in a private tarot reading live stream. In a private tarot reading live stream, video data is transmitted from the streamer's user terminal 20 to the viewer's user terminal 30 via the server 10. At the same time, comments / audio entered by the viewer are transmitted from the viewer's user terminal 30 to the streamer's user terminal 20 via the server 10. These processes together are called the private live streaming process S702.

[0061] The broadcast-side UI control unit 108 of the broadcaster's user terminal 20 receives a fortune-telling start instruction from the broadcaster (S704). Upon receiving the fortune-telling start instruction, the broadcast-side UI control unit 108 of the broadcaster's user terminal 20 generates a fortune-telling start request and sends it to the server 10 via the network NW (S706). Upon receiving the fortune-telling start request, the tarot processing unit 312 of the server 10 generates a fortune-telling start instruction and sends it to the viewer's user terminal 30 via the network NW (S708).

[0062] When the viewer's user terminal 30 receives a fortune-telling start instruction, the viewer-side UI control unit 202 displays the card selection screen on the display (S710). That is, the viewer-side UI control unit 202 starts displaying the card selection screen in response to the broadcaster's instructions during the live broadcast. The card selection screen has multiple card objects associated with the tarot reading. The viewer-side UI control unit 202 accepts the viewer's selection of one of the multiple card objects displayed on the card selection screen (S712). The input information transmission unit 206 of the viewer's user terminal 30 generates card selection information including selected card identification information that identifies the card object specified in step S712, and transmits it to the server 10 via the network NW (S714).

[0063] The tarot processing unit 312 of server 10 identifies the tarot cards to be presented to the broadcaster and viewers by processing the selected card identification information contained in the received card selection information using a predetermined algorithm (S716). The tarot processing unit 312 refers to the customized DB 322 and identifies the fortune-telling result options corresponding to the identified tarot cards (S718). The tarot processing unit 312 generates identification card information, including the card ID of the tarot card identified in step S716, and transmits it to the viewer's user terminal 30 via the network NW (S720). The tarot processing unit 312 generates a fortune-telling result selection request, including the card ID of the tarot card identified in step S716 and the options identified in step S718, and transmits it to the broadcaster's user terminal 20 via the network NW (S722).

[0064] The viewer's user terminal 30's viewing-side UI control unit 202 displays a selection result screen on the display that includes a tarot card identified by the card ID contained in the received specific card information (S724).

[0065] The broadcaster's user terminal 20's broadcast-side UI control unit 108 displays a fortune-telling result selection screen on the display, which includes the tarot card identified by the card ID included in the received fortune-telling result selection request and the options included in the request (S726). The broadcaster's UI control unit 108 accepts the broadcaster's selection of one of the multiple options for the fortune-telling result displayed on the fortune-telling result selection screen (S728). The broadcaster's UI control unit 108 generates a fortune-telling result response including the selected fortune-telling result and sends it to the server 10 via the network NW (S730). The server 10's tarot processing unit 312 registers the selected fortune-telling result included in the received fortune-telling result response in the fortune-telling history DB 324 (S732). The tarot processing unit 312 sends the received fortune-telling result response to the viewer's user terminal 30 (S734).

[0066] The viewer's user terminal 30's viewer-side UI control unit 202 displays a fortune-telling result explanation screen on its display, which includes the selected fortune-telling result included in the received fortune-telling result response (S736). As a result, the viewer's user terminal 30 obtains the fortune-telling result selected by the broadcaster who was presented with the tarot card corresponding to the card object specified in step S712 during the private tarot reading broadcast, and provides the obtained fortune-telling result to the viewer. A screen similar to the fortune-telling result explanation screen shown to the viewer is also displayed on the broadcaster's user terminal 20's display (S738). The private live broadcast processing S702 continues to run in parallel during the above series of fortune-telling processes.

[0067] Figure 20 is a representative screen view of the broadcaster's live streaming room screen 630 displayed on the broadcaster's user terminal 20 in step S704 of Figure 19. The broadcaster's live streaming room screen 630 has an image of the broadcaster 634 and a button 632 for selecting a card. When a private tarot reading broadcast begins, the broadcaster is shown the broadcaster's live streaming room screen 630, and the viewer is shown the viewer's live streaming room screen 630, excluding the selection button 632. The broadcaster, who is the fortune teller, first interacts with the viewer and obtains information about the viewer. The broadcaster can use this information when selecting and explaining the fortune-telling results later. The broadcaster gives a signal to start the fortune-telling by tapping the selection button 632 on the broadcaster's live streaming room screen 630 at the appropriate time. When the broadcaster's user terminal 20 detects this tap, it generates a fortune-telling start request and sends it to the server 10.

[0068] Figure 21 is a representative screen view of the card selection screen 636 displayed on the viewer's user terminal 30 in step S710 of Figure 19. The card selection screen 636 includes an image 638 of the broadcaster obtained by playing video data received from the server 10, and a group of face-down card objects 640 that mimic the arrangement of face-down tarot cards. Each face-down card object is distinguished by a face-down card ID. The broadcaster prompts the viewer to select one face-down card object during the live broadcast, and the viewer selects one face-down card object from the group of face-down card objects 640 by tapping. The viewer's user terminal 30 generates card selection information including the face-down card ID of the tapped face-down card object and sends it to the server 10 via the network NW.

[0069] The tarot processing unit 312 identifies the tarot cards to be presented to the viewers and broadcasters by one of the following methods: (1) Completely random The tarot processing unit 312 randomly identifies one tarot card, regardless of the face-down card ID included in the received card selection information. In this case, the viewer's selection of a face-down card object acts as a trigger for the random algorithm's selection of a tarot card. (2) Decide in advance Before sending the instruction to start the tarot reading, the tarot processing unit 312 determines the tarot card corresponding to the face-down card ID and records it in a predetermined storage unit (not shown). The tarot processing unit 312 identifies the tarot card corresponding to the face-down card ID included in the received card selection information by referring to the predetermined storage unit. (3) Random algorithm according to the selected card The tarot processing unit 312 identifies a tarot card using a random selection algorithm that uses the face-down card ID included in the received card selection information as a seed value. In any case, the tarot card identified by the tarot processing unit 312 corresponds to the face-down card object selected by the viewer.

[0070] Figure 22 is a representative screen view of the selection result screen 642 displayed on the viewer's user terminal 30 in step S724 of Figure 19. The selection result screen 642 includes an image of the broadcaster 638 and an image of a tarot card 644 identified by a card ID included in the specific card information received from the server 10. While this screen is displayed on the viewer's user terminal 30, the fortune-telling result selection screen is displayed on the broadcaster's user terminal 20.

[0071] Figure 23 is a representative screen view of the fortune-telling result selection screen 646 displayed on the display of the broadcaster's user terminal 20 in step S726 of Figure 19. The fortune-telling result selection screen 646 includes an image of the broadcaster 634, an image of a tarot card 648 identified by a card ID included in the fortune-telling result selection request received from the server 10, and a selection of fortune-telling results 650 included in the request. The broadcaster selects a fortune-telling result from among the multiple selections 650 by tapping while looking at the presented image of the tarot card 648. The broadcaster's user terminal 20 generates a fortune-telling result response including the tapped selection and sends it to the server 10 via the network NW.

[0072] Figure 24 is a representative screen view of the fortune-telling result explanation screen 654 displayed on the viewer's user terminal 30 in step S736 of Figure 19. The fortune-telling result explanation screen 654 includes an image 638 of the broadcaster, an image 656 of a tarot card identified by a card ID included in specific card information received from the server 10, and a fortune-telling result 658 selected by the broadcaster, which is included in the fortune-telling result response received from the server 10. While the fortune-telling result explanation screen 654 is displayed to the viewer, the broadcaster explains the meaning of the tarot card drawn and why the presented fortune-telling result 658 was obtained, etc., through the live broadcast. If the viewer has any questions or opinions about the fortune-telling result 658, they can immediately contact the broadcaster via comments or other means and receive an answer. In this way, in a private tarot reading broadcast, not only is the fortune-telling result presented, but dialogue between the broadcaster and the viewer about the fortune-telling result is promoted, which can further increase the satisfaction of both the broadcaster and the viewer.

[0073] Figure 25 is a representative screen view of the fortune-telling history screen 660 displayed on the viewer's user terminal 30 in step S510 of Figure 11. The fortune-telling history screen 660 includes the viewer's user ID 662 and a fortune-telling history display area 664 that displays the fortune-telling results from private tarot reading sessions that the viewer has participated in in the past. The fortune-telling history display area 664 displays, for each private tarot reading session that the viewer has participated in, the date, the broadcaster ID, the image of the tarot card presented, and the fortune-telling result selected by the broadcaster, in association with each session.

[0074] When the viewer's user terminal 30 receives a history display instruction from the viewer, the viewer-side UI control unit 202 generates a history acquisition request including the viewer's user ID and sends it to the server 10 via the network NW. The tarot processing unit 312 of the server 10 acquires the past fortune-telling results of the user identified by the user ID included in the received history acquisition request from the fortune-telling history DB 324. In the example in Figure 10, if the history acquisition request includes user ID "001A", the tarot processing unit 312 acquires the following records as fortune-telling result history: record "Start date and time = 1 / 3, 10:00, broadcaster ID = ABCFO, tarot type = one oracle, fortune-telling result = card ID: XX, love luck great" and record "Start date and time = 1 / 5, 12:00, broadcaster ID = ZZZPP, tarot type = one oracle, fortune-telling result = card ID: YY, career luck great". The tarot processing unit 312 generates response information including the history of acquired fortune-telling results and sends it via the network NW to the user terminal 30 that sent the history acquisition request. The viewing-side UI control unit 202 of the user terminal 30 configures the content to be displayed in the fortune-telling history display area 664 based on the received response information and displays the fortune-telling history screen 660 having the fortune-telling history display area 664 on the display.

[0075] In the embodiments described above, examples of the holding portion include a hard disk and a semiconductor memory. Furthermore, it will be understood by those skilled in the art who have read this specification that each portion can be realized based on the description herein by a CPU (not shown), a module of an installed application program, a module of a system program, or a semiconductor memory that temporarily stores the contents of data read from the hard disk.

[0076] According to the live streaming system 1 of this embodiment, in a live tarot reading stream, the viewer first performs the action of selecting a face-down card object. Next, the tarot card corresponding to that action is presented to the streamer, and the streamer selects the reading result. The selected reading result is then presented to both the viewer and the streamer during the live tarot reading stream. The streamer explains why that result was obtained, and provides any supplementary information during the live stream, and the viewer can comment with any questions they may have at that time. This provides a mechanism that allows the streamer to conduct live tarot reading streams smoothly and effectively. As a result, live tarot reading streams can be made more popular and further promoted.

[0077] In addition to this embodiment, other forms of live tarot readings can be considered, for example, (1) a form in which the broadcaster manipulates physical tarot cards in their hands and live streams the process, and (2) a form in which viewers select cards, like in a tarot reading game, and the results are presented automatically and mechanically. In this embodiment of live tarot readings, the tarot cards are identified by the direct actions of the viewers, so compared to form (1), it can enhance the viewers' sense of participation in the live stream. Also, in this embodiment of live tarot readings, the fortune-telling results presented by the broadcaster are entered into a terminal by the broadcaster, recorded as data, and presented to the viewers. Therefore, it is possible to view the history of fortune-telling results later, improving user convenience compared to form (1). Furthermore, in this embodiment of live tarot readings, each time a viewer selects a face-down card object and a corresponding tarot card is presented, the broadcaster selects the most appropriate option from the choices of fortune-telling results and presents it to the viewers. Even if two viewers draw the same tarot card, the fortune-telling result presented to one viewer may differ from the result presented to the other viewer. Similarly, the fortune-telling result presented to a viewer after drawing a tarot card in a live tarot reading stream by a certain streamer may differ from the fortune-telling result presented to the same viewer after drawing the same card in another live tarot reading stream by the same streamer. In this embodiment, the fortune-telling result is adjusted to better suit the viewer within the live tarot reading stream, based on the content of the dialogue between the streamer (who is the fortune teller) and the viewer, the timing of the reading, and the streamer's experience and intuition. Therefore, compared to the case where the same fortune-telling result is always given for the same tarot card, as in the game form of (2), the streamer is given more freedom in determining the fortune-telling result, improving the quality of the reading, and viewers are also more satisfied because they can receive a reading that is more customized to them.

[0078] Furthermore, in the live streaming system 1 according to this embodiment, the system requests the streamer to input the fortune-telling results and records the input results, allowing viewers to view a history of their fortune-telling results. This means that even if a viewer who participated in a tarot reading live stream forgets their fortune-telling results, they can recall them by viewing the history. As a result, user convenience is improved.

[0079] Furthermore, the live streaming system 1 according to this embodiment is configured to allow each streamer to customize the content of their tarot readings by providing a customizable DB322, making it easier for streamers to differentiate their tarot readings from those of other streamers. In addition, the platform can enrich the tarot reading content by hosting live streams of tarot readings with a wide variety of content.

[0080] Referring to Figure 2, the hardware configuration of the information processing device according to this embodiment will be described. Figure 2 is a block diagram showing an example of the hardware configuration of the information processing device according to this embodiment. The illustrated information processing device 900 can, for example, realize the server 10 and user terminals 20 and 30 in this embodiment.

[0081] The information processing device 900 includes a CPU 901, a ROM (Read Only Memory) 903, and a RAM (Random Access Memory) 905. 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. Furthermore, the information processing device 900 may include an imaging device such as a camera (not shown). The information processing device 900 may also have a processing circuit such as a DSP (Digital Signal Processor) or an ASIC (Application Specific Integrated Circuit) instead of, or together with, the CPU 901.

[0082] The CPU 901 functions as an arithmetic processing unit and control unit, controlling the overall operation or a part of the operation within the information processing unit 900 according to various programs recorded in the ROM 903, RAM 905, storage device 919, or removable recording medium 923. For example, the CPU 901 controls the overall operation of each functional unit included in the server 10 and user terminals 20 and 30, respectively, in this embodiment. The ROM 903 stores programs and arithmetic parameters used by the CPU 901. The RAM 905 temporarily stores programs used in the execution of the CPU 901 and parameters that change as appropriate during its execution. The CPU 901, ROM 903, and RAM 905 are interconnected by a host bus 907, which is composed of internal buses such as the CPU bus. Furthermore, the host bus 907 is connected to an external bus 911, such as a PCI (Peripheral Component Interconnect / Interface) bus, via a bridge 909.

[0083] The input device 915 may be a device operated by the user, such as a mouse, keyboard, touch panel, buttons, switches, and levers, or it may be a device that converts physical quantities into electrical signals, such as a sound sensor like 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 also be a remote control device that uses infrared or other radio waves, or it may be an external connection device 927 such as a mobile phone that is compatible with the operation of the information processing device 900. The input device 915 includes an input control circuit that generates an input signal based on information input by the user or a physical quantity sensed and outputs it to the CPU 901. By operating this input device 915, the user inputs various data to the information processing device 900 or instructs it to perform processing operations.

[0084] The output device 917 is comprised of a device capable of notifying the user of acquired information visually or audibly. The output device 917 may be, for example, a display such as an LCD, PDP, or OLED, an audio output device such as a speaker and headphones, or a printer. The output device 917 outputs the results obtained from the processing of the information processing device 900 as text or images, or as sound.

[0085] The storage device 919 is a data storage device configured as an example of the storage unit of the information processing device 900. The storage device 919 is composed of, for example, a magnetic storage device such as an HDD (Hard Disk Drive), a semiconductor storage device, an optical storage device, or a magneto-optical storage device. This storage device 919 stores programs executed by the CPU 901, various data, and various data acquired from external sources.

[0086] The drive 921 is a reader / writer for removable recording media 923, such as magnetic disks, optical disks, magneto-optical disks, or semiconductor memory, and is either built into or external to the information processing device 900. The drive 921 reads information recorded on the installed removable recording media 923 and outputs it to the RAM 905. The drive 921 also writes data to the installed removable recording media 923.

[0087] The connection port 925 is a port for directly connecting equipment to the information processing device 900. The connection port 925 may be, for example, a USB (Universal Serial Bus) port, an IEEE1394 port, or a SCSI (Small Computer System Interface) port. Alternatively, the connection port 925 may be an RS-232C port, an optical audio terminal, or an HDMI (High-Definition Multimedia Interface) 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.

[0088] The communication device 929 is a communication interface composed of, for example, a communication device for connecting to a network NW. The communication device 929 may be, for example, a communication card for wired or wireless LAN (Local Area Network), Bluetooth®, or WUSB (Wireless USB). Alternatively, the communication device 929 may be a router for optical communication, a router for ADSL (Asymmetric Digital Subscriber Line), or a modem for various types of communication. The communication device 929 sends and receives signals, for example, to the Internet or 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 wireless, and may be, for example, the Internet, a home LAN, infrared communication, radio wave communication, or satellite communication. The communication device 929 performs the function of a communication unit.

[0089] An imaging device such as a camera (not shown) is a device that captures real space and generates an image using various components such as an image sensor, such as a CCD (Charge Coupled Device) or CMOS (Complementary Metal Oxide Semiconductor), and a lens for controlling the imaging of a subject onto the image sensor. The imaging device may capture still images or it may capture moving images.

[0090] The configuration and operation of the live streaming system 1 according to this embodiment have been described above. This embodiment is illustrative, and it will be understood by those skilled in the art that various modifications are possible in combinations of each component and each process, and that such modifications are also within the scope of this disclosure.

[0091] While the embodiment described an example of a private tarot reading broadcast, the technical ideas of this embodiment can be applied to tarot reading broadcasts involving multiple viewers. For example, a tarot reading broadcast between a broadcaster and a specific viewer may be configured to allow other viewers to participate. That is, a tarot reading broadcast may be configured to allow viewers other than those who have reserved to participate to join. In this tarot reading broadcast, other viewers will act as spectators, watching the tarot reading broadcast being conducted for the specific viewer. To allow the broadcaster to set whether or not to make the tarot reading broadcast private, an item to select whether or not to make it a private broadcast may be added to the broadcast schedule registration screen 600 in Figure 12.

[0092] In this case, the streamer can expect the promotional effect and the acquisition of new customers by showing their fortune-telling to a large audience. Viewers, on the other hand, can observe how other specific viewers are getting their fortunes told, which helps them decide which streamer to consult.

[0093] Alternatively, a tarot reading broadcast in which all viewers can participate may be provided. Figure 26 is a representative screen view of the card selection screen 670 displayed on the display of a viewer's user terminal 30 in a modified version of a tarot reading broadcast in which all viewers can participate. The card selection screen 670 has an image 638 of the broadcaster obtained by playing video data received from the server 10, and four face-down card objects 672 that resemble face-down tarot cards. The broadcaster prompts multiple viewers in the live broadcast to choose their favorite face-down card object, and the viewers select one face-down card object from the four face-down card objects 672 by tapping. In the example in Figure 26, the second face-down card object from the right is selected, and a dashed rectangular frame indicating selection is shown around the selected face-down card object.

[0094] In this example, a fee must be paid to select the face-down card object 672. In the example in Figure 26, the fee amount "300pt" is displayed below each face-down card object. When the viewer's user terminal 30 detects a tap on a face-down card object 672, it identifies the face-down card ID of the tapped face-down card object 672 and accepts the payment of the fee.

[0095] When a predetermined condition is met, such as the number of users who have selected a face-down card object 672 reaching a predetermined number, or a predetermined period of time having elapsed, the server 10 performs a process to select one of the four face-down card objects 672. This process may be, for example, a process in which the broadcaster's user terminal 20 accepts the selection of one face-down card object 672 from the broadcaster, or a process in which one face-down card object 672 is selected according to the number of viewers who have selected each face-down card object 672 (for example, selecting the face-down card object 672 that has been selected by the most viewers). The server 10 identifies the tarot card corresponding to the face-down card ID of the face-down card object 672 selected in this way. The correspondence between the face-down card ID and the tarot card (and its card ID) may be set in advance by the broadcaster, or set automatically, and registered in a predetermined storage unit. If the face-down card object 672 selected by a viewer matches the face-down card object 672 selected by the server 10, the same process as described with reference to Figures 22, 23, and 24 is performed for such viewers. If there is no match, server 10 retrieves a comment from the customized DB 322 that corresponds to the card ID of the tarot card corresponding to the face-down card object 672 selected by the viewer. Server 10 generates notification information including the card ID of the tarot card corresponding to the face-down card object 672 selected by server 10, the card ID of the tarot card corresponding to the face-down card object 672 selected by the viewer, and the retrieved comment, and sends it to the viewer's user terminal 30 via the network NW.

[0096] Figure 27 is a representative screen view of the fortune-telling result display screen 674 displayed on the viewer's user terminal 30. The fortune-telling result display screen 674 includes an image 638 of the broadcaster, an image 676 of a tarot card corresponding to a face-down card object 672 selected by the server 10, an image 678 of a tarot card corresponding to a face-down card object 672 selected by the viewer, and a comment 680 included in the notification information. Even if the face-down card object that the viewer selected was not selected as the subject of the fortune-telling, the viewer can check their tarot card by looking at the image 678 of the tarot card, and further learn about the fortune corresponding to their tarot card by looking at the comment 680. This can reduce the feeling of disappointment caused by not being selected.

[0097] The embodiment described a case where payment is made in advance when reserving to watch a tarot reading stream, but it is not limited to this. For example, payment may be made by the viewer to the streamer in the form of a gift at any time during the tarot reading stream, or when selecting a face-down card object. When payment is made when selecting a face-down card object, there may be only one face-down card object to choose from, or the configuration may allow the viewer to choose from multiple face-down card objects with different prices. Alternatively, the payment may be made immediately before the viewer participates in the tarot reading stream.

[0098] In this embodiment, the case in which the fortune-telling history DB 324 is provided on the server 10 has been described, but it is not limited to this, and the viewer's user terminal 30 may also be equipped with a fortune-telling history DB that stores the viewer's past fortune-telling results.

[0099] In this embodiment, with reference to Figure 15, we described a case where a streamer who is a fortune teller sells their private tarot reading schedule during their live stream, but the embodiment is not limited to this. For example, a streamer may sell the private tarot reading schedules of other streamers they like or follow during their live stream. This would further revitalize the fortune-telling live streaming community.

[0100] In this embodiment, new registrations for private tarot reading streaming schedules are notified to followers, and if a viewer uses a schedule gift during a live stream, that viewer is registered as a follower of the streamer. In other words, being a follower of the streamer, or becoming a follower, is a condition for participating in the streamer's private tarot reading stream. This allows for an increase in follower relationships, thereby further strengthening the connection between users. However, the embodiment is not limited to this, and for example, it may be possible to participate in the streamer's private tarot reading stream without following the streamer.

[0101] In this embodiment, we have described a case where a broadcaster is presented with a tarot card corresponding to a face-down card object specified by a viewer, and selects one option from among several choices of fortune-telling results, but we are not limited to this. For example, the broadcaster may look at the presented tarot card and input the fortune-telling result as text into the user terminal 20. Alternatively, the broadcaster may speak the fortune-telling result during the live broadcast, and the user terminal 20, which has a speech-to-text conversion function, may input the fortune-telling result by converting the broadcaster's voice into text.

[0102] In this embodiment, a tarot type is provided, but instead of this, or in addition to this, a fortune-telling category may be provided. For example, fortune-telling categories may include financial luck, love luck, career luck, health luck, etc. The customization DB322 may be configured to allow registration of options for each fortune-telling category. When notifying followers of a new registration of a private tarot reading delivery schedule, the set fortune-telling category may also be notified.

[0103] The conversion rate from the gift price to the gift points in this embodiment is just one example, and these rates may be set as appropriate by, for example, the administrator of the live streaming system 1.

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

[0105] In the processing procedures described herein, particularly those described using flowcharts, it is possible to omit some of the steps constituting the processing procedure, to add steps not explicitly included as constituting the processing procedure, and / or to change the order of such steps. Processing procedures with such omissions, additions, or changes in order are included within the scope of this disclosure, provided they do not deviate from the spirit of this disclosure.

[0106] At least some of the functions implemented by server 10 may be implemented by devices other than server 10, such as user terminals 20 and 30. At least some of the functions implemented by user terminals 20 and 30 may be implemented by devices other than user terminals 20 and 30, such as server 10. For example, the superposition of a predetermined frame image onto an image of video data performed on the playback-side user terminal may be performed by server 10 or on the generation-side user terminal.

Claims

1. On the user device that generates the video data related to the live distribution, A function to transmit video data to a server via a network; a function of displaying information corresponding to an object designated by a user on the playback side among a plurality of objects related to the content of the live distribution on a display of a user terminal on the generation side; A function for accepting input from a generating user to whom the information is presented, and a computer program for realizing this function.

2. the function of accepting includes a function of accepting, by a user on the generating side, a designation of one option among a plurality of options displayed on the display, The computer program product of claim 1 , wherein the plurality of options are different when the information is different.

3. The computer program according to claim 2 , further comprising a function for enabling a user on the generating side to set options corresponding to the information, in the generating side user terminal.

4. The computer program product according to claim 1 , further comprising a function for causing the generating user terminal to receive an instruction to cause the reproducing user terminal to start displaying a plurality of objects during the live distribution.

5. The computer program product according to claim 1 , further comprising a function for receiving registration of a schedule and a fee for the live distribution from a user on the generating side before the live distribution starts.

6. A means for relaying transmission of video data relating to live distribution from a user terminal that generates the video data to a user terminal that plays the video data; a means for receiving, from the user terminal on the playback side, identification information of an object designated by a user on the playback side among a plurality of objects related to the content of the live distribution displayed on a display of the user terminal on the playback side; means for identifying information corresponding to a specified object based on the received identification information; A means for transmitting the specified information to a generating user terminal; A means for receiving, from a generating user terminal, a result input by a generating user who has been presented with the specified information; and means for providing the received result to a playback user terminal.

Images