JP4655550B2 - Virtual live performance support system and virtual live performance support processing program - Google Patents

Description

  The present invention relates to a virtual live performance support system and a virtual live performance support processing program, and more particularly to a virtual live performance support system and a virtual live performance that support a plurality of performers to participate and perform through a network. Is related to the support processing program.

With recent remarkable improvements in communication infrastructure, it has become possible to transmit a large amount of data at high speed via a network such as the Internet. Therefore, many proposals have been made regarding the content to be transmitted in anticipation of further speeding up in the future.
In a proposed music game system, two music production game devices corresponding to different parts are connected by a communication unit that transmits performance progress information synchronized with BGM performance music, and each device player is like an actual band. Each part is to be played. (See Patent Document 1)
In another proposed music distribution system, musical scores for each part are released from a plurality of terminals by releasing the musical score for each part to a communication network and reproducing the performance or singing for each part according to the musical score. It is received, the pass / fail is determined for each part, and music data is created by combining one piece of original music data for each part from the pass. (See Patent Document 2)
In another proposed music activity support system, when all users who are members of a band connect terminal devices via a communication network, the server notifies each user to that effect and prompts the performance. By receiving and storing data indicating performances performed in parallel by each user from each terminal device, the results of the ensemble by a plurality of users are stored. (See Patent Document 3)
JP 2000-317144 A JP 2002-297136 A JP 2004-212632 A

  However, although the proposals in Patent Document 1 to Patent Document 3 have an advantage that a plurality of performers can perform through each terminal and network, evaluations from listeners and other performers are not obtained. Therefore, there is a high possibility that the ensemble will be self-satisfactory, and it is not possible to expect improvement in the technique of each player. In addition, some performers may not be able to offer their live performances to listeners even though they are live performances, so it is not possible to develop their music activities as a business, and it can be expected that they will open up a professional career. Can not.

  The present invention is to solve such a conventional problem, and an unspecified number of performers and listeners participate through a network to perform a virtual live performance in groups at any time. By providing the virtual live performances to the listeners who perform, the evaluation from the listeners and other performers can be obtained, so that the performance of each player can be expected to improve and music activities as a business The purpose is to be able to deploy.

The virtual live performance support system according to claim 1, wherein each player constituting a plurality of parts of the virtual live performance according to a virtual live performance performance application from an arbitrary terminal device connected via a network. And a first server for managing a performance schedule;
In the virtual live performance according to the performance schedule managed by the first server, the performance data of the player's part received from the terminal device of the performer who applied for the performance is used. And a second server that transmits the performance data of a plurality of parts that are transmitted from the terminal device of each performer to the terminal device that has been subscribed to the virtual live performance and that is stored in a predetermined storage unit.
In response to a purchase application for performance data of a virtual live performance from an arbitrary terminal device connected via the network, the settlement data is sent to a settlement institution, and when the end of settlement is received from the settlement institution, the predetermined memory is stored. Find the performance data corresponding to the application from the device, and a third server that sends performance data the search to the arbitrary terminal apparatus,
When the second server transmits performance data of a virtual live performance currently being performed to the terminal device for the trial application, the second server sends a notice of unpopularity from a predetermined number of terminal devices for the trial application. When it is received, the live performance is stopped.

The virtual live performance support processing program according to claim 2 is stored in a computer.
A first step of managing each player and a performance schedule constituting a plurality of parts of the virtual live performance in response to a performance application of the virtual live performance from an arbitrary terminal device connected via a network;
In the virtual live performance according to the performance schedule managed in the first step, the performance data of the performer's part received from the terminal device of the performer who applied for performance is used as the terminal device of the performer of the other part. And the performance data of a plurality of parts received from each performer's terminal device are stored in a predetermined storage means, and the currently playing virtual If live performance data is being transmitted to the terminal device for the trial application, and if a notice of disapproval is received from a predetermined number of terminal devices for the trial application, the live performance is stopped. Two steps,
In response to a purchase application for performance data of a virtual live performance from an arbitrary terminal device connected via the network, the settlement data is sent to a settlement institution, and when the end of settlement is received from the settlement institution, the predetermined memory is stored. A third step of retrieving performance data corresponding to the application from the means and transmitting the retrieved performance data to the arbitrary terminal device;
Is executed.

  According to the virtual live performance support system and the support processing program of the present invention, it is possible to expect improvement in the technology of each player by obtaining evaluations from listeners and other players, and music activities. Can be developed as a business. In addition, anyone can perform virtual live performances and audition performances at any time and anywhere via a network deployed around the world, such as the Internet, enabling the realization of a music ubiquitous service business.

Hereinafter, an embodiment of a virtual live performance support system according to the present invention will be described with reference to the drawings.
FIG. 1 is a diagram showing a configuration of a virtual live performance support system. The plurality of terminal devices 1 are information processing devices such as personal computers that can be connected to various servers via the Internet 2. Although not shown, an operation unit, a display unit, a control unit such as a CPU, a program memory such as a ROM, Work memory such as RAM is provided. The session manager server 3, the broadcast manager server 4, and the shop manager server 5 support the virtual live performance in response to a virtual live performance performance application or trial application from any terminal device 1 connected via the Internet 2. Server. Each server includes a control unit such as a CPU, a program memory such as a ROM, and a work memory such as a RAM.

The session manager server 3 manages the performer and performance schedule of the virtual live performance. For this purpose, a performer database (DB) 6 and a performance program database 7 are connected to the session manager server 3 to store registered performer data and performance schedule data.
The broadcast manager server 4 transmits the performance data of the virtual live performance to the terminal device 1 that has applied for performance.
The shop manager server 5 transmits the performance data of the virtual live performance to the terminal device 1 that has applied for trial listening, and sells the performance data to the terminal device 1 that has applied for purchase. For this purpose, the listener database 8 is connected to the shop manager server 5 and the registered listener data is stored. Further, the shop manager server 5 can be connected to a bank or other settlement organization (not shown) in order to receive the price of the performance data sold.
The session manager server 3, the broadcast manager server 4 and the shop manager server 5 are connected to a music database 9 for storing virtual live performance data and existing performance data described later. Arbitrary performance data is retrieved by each server according to the performance schedule.
The session manager server 3, the broadcast manager server 4, and the shop manager server 5 are connected to each other via a system bus 10, and commands and data are transmitted and received between the servers as needed. Therefore, it is also possible to construct a system with these three servers 3, 4 and 5 as a single server.

Next, the contents of data stored in the performance program database 7, the performer database 6, the song database 9, and the listener database 8 will be described with reference to FIGS.
As shown in FIG. 2 (A), the performance program database is managed in an area of performance program IDs (in this case, numbers 1, 2, 3,..., N) for each virtual live performance. The area includes an area for a song name / ID, a performance start time, a performance time, and a predetermined number of parts (for example, a melody part such as a guitar, a drum part, and a bass part). Each part area includes a player ID area and a questionnaire data area.
As shown in FIG. 2B, the performer database is composed of registered performer areas, and each performer area is composed of performer ID, password, and profile areas.
As shown in FIG. 3C, the song database is composed of a plurality of song areas. In addition to the performance data songs in the virtual live performance, existing performance data songs prepared in advance are stored in the songs. The virtual live performance song area includes a session name, a performance program ID, and song data, that is, performance data area. Although existing song data is not shown, famous songs played by professional performers are classified and stored in each part.
As shown in FIG. 3D, the listener database includes registered listener areas, and each listener area includes listener ID, password, and profile areas.

Next, the virtual live performance support process executed by the system of FIG. 1 will be described.
First, the processing of the terminal device 1 will be described based on the operation flowcharts shown in FIGS. 4 to 17 and the screens shown in FIGS. In FIG. 4, after a predetermined initialization (step SA1), an initial screen is displayed (step SA2). On the initial screen, as shown in FIG. 18, the application of the session site is started, and explanations of the support system and a plurality of options displayed at the bottom of the screen are registration 101, performance 102, trial listening 103, and back 104 switches. A message to select one of them is displayed. Here, the registration 101 is a switch connected to the session registration site for registration in the support system, the performance 102 is a switch connected to the performance site for applying for a virtual live performance, and the switch of the trial listening 103 is a virtual live performance. It is a switch that connects to the audition site in order to apply for the audition of the performance. A return 104 is a switch for ending the application at the session site.

  Next, it is determined whether or not an operation for connecting to the session registration site has been performed by selecting the registration 101 (step SA3). When this operation is performed, connection to the session manager server 3 is performed (step SA4). The start screen is received (step SA5), and the start screen is displayed (step SA6). As shown in FIG. 19, the start screen displays a message for selecting whether to participate in a virtual live performance session or to audition, and switches for session selection registration 105 and audition registration 106 as options. Is done.

  Then, it is determined whether or not session participation is requested by selecting the session participation registration 105 (step SA7). When session participation is requested, a session participation request is sent to the session manager server 3 (step SA8). The consent screen is received (step SA9), and the consent screen is displayed (step SA10). When a trial listening is requested, the trial listening request is sent to the session manager server (step SA11). On the consent screen for session participation, as shown in FIG. 20, an explanation of the operation of this site and the copyright or neighboring rights is displayed along with a message for registering self-data. A switch indicating to do 107 and disagree (exit) 108 is displayed.

  In accordance with the selection of any switch, in the flow of FIG. 5, it is determined whether or not to agree (step SA12), and if agreed, the fact of consent is sent to the session manager server 3 (step SA13). Then, after receiving the registration screen (step SA14) and stopping the connection, the registration screen is displayed (step SA15). As shown in FIG. 21, the performance registration screen is registered as an option together with a message to input the player's profile, main instrument, ie, part, desired music, password, ID, bank name and account number of the transaction. A switch indicating that it is to be registered 109 and 110 indicating that it is not registered is displayed.

In this performance registration screen, it is determined whether or not a profile has been input (step SA16), and if it has been input, the profile is stored in the work memory (step SA17). In addition, it is determined whether or not the desired musical piece and part have been input (step SA18). When the desired musical piece and part are input, the desired musical piece and part are stored in the work memory (step SA19).
Alternatively, it is determined whether or not to register 110 is selected (step SA20). When this is selected, the connection is stopped (step SA21), and the process proceeds to step SA2 in FIG. 4 to display the initial screen. To do.

On the other hand, it is determined whether or not to register 109 is selected (step SA22). When this is selected, a profile is sent to the session manager server 3 (step SA23), and the desired performance piece and part are sent. Send (step SA24). Also, a preview screen for the performance schedule is received (step SA25), and the preview screen is displayed (step SA26). As shown in FIG. 23, the notice screen displays the contents of the requested virtual live performance, the part in charge, the song title, the performance date and time, and the scheduled members. If the scheduled members of all parts are not available, the part is displayed as undecided. Further, the notice screen displays a switch 111 for confirming and accepting the performance reservation and for not accepting (reservation cancellation) 112.
Also, a switch 113 in the detailed description section of the song is displayed, and clicking on this switch 111 displays the detail 114 of the song in a window as shown in FIG. In the song details 114, detailed instructions for virtual live performance and the waiting time until the scheduled performance time are displayed.

In the screen of FIG. 23, it is determined whether or not to accept 111 or not to accept 112 is selected (step SA27), and when OK is selected, an OK command is sent to the session manager server 3. (Step SA28), an ID and a password are acquired (step SA29). Then, the connection is stopped, and the process proceeds to step SA2 in FIG. 4 to display the initial screen.
On the other hand, when it is selected not to accept, an NG command is sent to the session manager server 3 (step SA30), the connection is stopped (step SA21), and the process proceeds to step SA2 in FIG. 4 to display the initial screen. indicate.

  In step SA3 in FIG. 4, if the connection operation is not performed on the registration site, it is determined whether or not the connection operation has been performed on the performance site by selecting the performance 102 on the initial screen in FIG. 18 (step SA31 in FIG. 6). . When this connection operation is performed, the session manager server 3 is connected (step SA32), and a performance site connection request is sent (step SA33). The ID and password request screen is received (step SA34), and the request screen is displayed (step SA35). Although not shown in the figure, this request screen displays a message for prompting input of an ID and a password, an input area, and a switch for sending instructions.

  When the ID and password are entered on this request screen, the characters and numbers of the entered ID are displayed, and a specific symbol (for example, asterisk “*”) is displayed according to the entered password (step SA36), and the mail is sent. The ID and password input in response to the instruction are sent to the session manager server 3 (step SA37). Then, a session standby screen is received (step SA38), and a waiting time is further received (step SA39). Next, the waiting time is overwritten and displayed on the session waiting screen (step SA40). As shown in FIG. 25, the session standby screen displays the part of the virtual live performance, the name of the song, the performance date and time, and the scheduled members, as well as “XX minutes until the session start”. So that the waiting time is displayed. Furthermore, various information is displayed on the information broadcast window 115 when the performance is near. For example, a message that prompts the user to connect a musical instrument or a message that advises performance is displayed so that the performance data can be sent.

In the waiting time during which the session standby screen is displayed, it is determined whether or not the playing screen has been received (step SA41 in FIG. 7). That is, it is determined whether or not the waiting time has ended and the performance start time has been reached. When the screen during performance is not received, that is, when the waiting time has not ended yet, the waiting time is received at step SA39 in FIG. 6, and the waiting time is overwritten and displayed on the session waiting screen (step SA40). . Therefore, the waiting time overwritten on the session waiting screen decreases as time elapses.
In step SA41, when a performance screen is received, the session performance screen is displayed (step SA42). As shown in FIG. 26, the session session performance screen displays the theme being played, the part in charge, the song title, the performance date, and the scheduled members, and the information broadcast window 115 introduces the performer and the band. Message is displayed.

Moreover, you may make it display the advice with respect to a performance as a music progresses. For example, “I want a change in the song, so please rehearse it.” “Adlib may be done faithfully to the chord, and the B ♭ major scale is OK.” “The 7th of Gm7 is minor. "Please play as it is because the chord is tensioned."
Further, a timing image such as a metronome or the current measure may be displayed on the playing screen to synchronize the performance of each part.

  Next, when it is connected to the broadcast server 4 (step SA43) and performance data is received (step SA44), it deletes its own part (step SA45) and generates a sound according to the performance of its own part (step SA45). Step SA46). Also, it detects its own performance data (step SA47) and sends its performance data to the broadcast server 4 (step SA48). During performance, it is determined whether or not an end signal is received from the broadcast server 4 (step SA49). If no end signal is received, a virtual live performance is performed while repeating the loop from step SA44 to step SA49. When the end signal is received in step SA49, the session manager server 3 is connected (step SA50).

  Next, the session end screen and the session name are received (step SA51 in FIG. 8), and the session end screen is displayed (step SA52). On the session end screen, as shown in FIG. 27, the received session name is displayed, and a message indicating that trial listening or purchase is possible is displayed in the broadcast information window 115. In addition, as options for transition to other screens, a questionnaire screen 116 for answering a questionnaire, an end screen (top screen) 117 for returning to the initial screen, a preview screen 118 for auditioning the performance as stream data, a performance A switch of a purchase screen 119 for downloading and purchasing the contents is displayed.

Then, it is determined whether any switch is selected. It is determined whether or not the questionnaire screen 116 has been selected (step SA53). When this switch is selected, the questionnaire screen is received (step SA54) and the questionnaire screen is displayed (step SA55). On the questionnaire screen, as shown in FIG. 28, a screen for inputting data of a plurality of items regarding the impression after performance is displayed, and a send switch 120 for sending the questionnaire and returning to the previous screen is displayed. In this state, it is determined whether or not data has been input (step SA56). When the data has been input, the data is stored in the transmission buffer of the RAM (step SA57). Next, it is determined whether or not a sending operation has been performed by selecting the sending switch 120 (step SA). When this operation is performed, the stored questionnaire data is sent to the session manager server 3 (step SA59). Thereafter, the process proceeds to step SA51, where the end screen and the session name are received, and the end screen of FIG. 26 is displayed again (step SA52).
Note that this questionnaire data may be stored in the performer database 6 so that it can be totaled.
When the questionnaire screen is not selected, it is determined whether or not the end screen is selected (step SA60). When this screen is selected, the connection with the session manager server 3 is stopped (step of FIG. 5). SA21), the process proceeds to step SA2 in FIG. 4 to display the initial screen.

  If the end screen is not selected in step SA60, it is determined whether or not the audition screen is selected in the flow of FIG. 9 (step SA61). When this screen is selected, it connects to the shop manager server 5 (step SA62) and sends a trial listening request with the session name (step SA63). A trial listening request screen is received from the shop manager server 5 in response to this transmission (step SA64), and the trial listening request screen is displayed (step SA65). As shown in FIG. 29, the audition request screen displays the name, song name, part name and session name of the performer who requested the audition, as well as the audition button 121, for returning to the previous screen. A switch on the previous screen 122 and a purchase screen 119 for downloading and purchasing the performance contents is displayed.

  In this screen, it is determined whether or not the audition request button 121 is operated (step SA66). When the audition request button 121 is operated, a request for data for audition is sent to the shop manager server 5 by the session name ( Step SA67). Then, data for trial listening is acquired from the shop manager server 5 (step SA68), and trial listening processing is performed (step SA69). When the trial listening of the music is completed, the trial listening data is cleared (step SA70), and the process proceeds to step SA66. As shown in the trial listening request screen of FIG. 29, since the trial listening can be performed any number of times, when the trial listening request button 121 is operated again after the trial listening of the music is completed, the loop from step SA67 to step SA70 is repeated.

  If the preview request button 121 is not operated in step SA66, it is determined whether or not the previous screen 122 has been selected on the preview request screen of FIG. 29 (step SA71). When the previous screen 122 is selected, it connects to the session manager server 3 (step SA72), moves to step SA51 in FIG. 8, receives the session end screen and the session name from the session manager server 3, A screen is displayed (step SA52). If the previous screen is not selected in step SA71 of FIG. 9, it is determined whether or not the purchase screen 119 is selected on the screen of FIG. 29 (step SA73). In step SA61, it is also determined whether or not purchase is selected even if trial listening is not selected (step SA75).

  When purchase is selected in step SA74, that is, when purchase is selected while connected to the session manager server 3, the connection is made to the shop manager server 5 (step SA75). After connecting to the shop manager server 5 or when purchase is selected in step SA73, that is, when purchase is selected while connected to the session manager server 3, a purchase request is sent with the session name ( Step SA76 in FIG. Then, the purchase screen is received (step SA77), and the purchase screen is displayed (step SA78). As shown in FIG. 30, the purchase screen displays the session name and the purchase price. As with the preview screen, the previous screen 122 and the purchase settlement screen 123 serve as options for the audition button 121 and screen change. Is displayed. Therefore, even before making a purchase settlement, a trial listening can be made to confirm again.

In this state, it is determined whether or not a viewing request has been made (step SA79). When a trial listening request has been made, a trial listening is requested by the session name (step SA80). Then, viewing data is acquired (step SA81), and trial listening processing is performed (step SA82). When the trial listening of the song is completed, the viewing data is cleared (step SA83), and the process proceeds to step SA79 to determine whether or not there is a further trial listening request. If there is a further audition request, the processes in steps SA80 to SA83 are repeated. If there is no audition request, it is determined whether or not a purchase settlement request has been made by selecting the purchase settlement screen 123 (step SA84). .
If the purchase settlement request is not made, it is determined whether or not the previous screen 122 has been selected (step SA85). If the previous screen 122 has been selected, the session manager server 3 is connected (step SA86). The process proceeds to step SA51 in the flow 8 to receive an end screen.

If a purchase settlement request is made in step SA84, a purchase request is made with the session name (step SA87). Then, the purchase settlement screen is received (step SA88), and the purchase settlement screen is displayed (step SA89). As shown in FIG. 31, switches 124 and 125 for selecting a session name, a purchase price, and a settlement method are displayed on the purchase settlement screen, and a purchase decision switch 126 is displayed. In addition, switches for the previous screen 122 and the top screen 127 are displayed as screen change options.
On this screen, it is determined whether or not the top screen is selected (step SA90). When the top screen is selected, the process proceeds to step SA2 in the flow of FIG. 4 to display the initial screen. If the top screen is not selected, it is determined whether or not the previous screen is selected (step SA91). If the previous screen is selected, the process proceeds to step SA76, and a purchase request is sent with the session name.

  If the previous screen is not selected, it is determined whether or not settlement data has been input in the flow of FIG. 11 (step SA92). If settlement data has been input, the settlement data is transmitted to the RAM. Store in the buffer (step SA93). Next, it is determined whether or not a purchase decision has been selected (step SA94). If a purchase decision has been selected, it is connected to the shop manager server 5 (step SA95) and payment data is sent (step SA96). . Then, the virtual live performance session data is downloaded (step SA97), and the session data is stored in a predetermined area of the RAM (step SA98). After the session data is stored or when purchase decision is not selected in step SA94, the process proceeds to step SA90 in the flow of FIG.

  In step SA11 in the flow of FIG. 4, when a trial listening request is sent, it is a listener trial listening request, not a session participation. In this case, in the flow of FIG. 12, the consent screen is received from the session manager server 3 (step SA99), and the consent screen is displayed (step SA100). In the listener's consent screen, as shown in FIG. 22, the listener's profile, favorite musical instrument, desired music piece, password, ID, transaction bank name, account number, and the like are registered as options. A switch of “109” and “not registered” 110 is displayed.

  In this screen, it is determined whether or not a switch to agree is selected (step SA101). If a switch that does not agree is selected, the process proceeds to step SA21 in the flow of FIG. The process proceeds to step SA2 and an initial screen is displayed. On the other hand, when the switch to agree is selected, it connects to the shop manager server 5 (step SA102) and sends listener consent (step SA103). Then, the listener registration screen is received (step SA104), and the listener registration screen (not shown) is displayed (step SA105). In the listener registration screen, it is determined whether or not a profile has been input (step SA106). If a profile has been input, the profile is stored in the RAM transmission buffer (step SA107).

Next, it is determined whether or not registration has been selected (step SA108). When it is selected not to register, the process proceeds to step SA21 in the flow of FIG. 5 to stop the connection, and then the process proceeds to step SA2 in FIG. 4 to display the initial screen. On the other hand, when registration is selected, in the flow of FIG. 13, the stored profile is sent (step SA109), and the ID and password are acquired (step SA110). Next, a listener audition request is sent (step SA111), a listener audition screen is received (step SA112), and the listener audition screen is displayed (step SA113). As shown in FIG. 32, the listener audition screen displays a message indicating that a live audition or a past performance audition is selected, as well as an area indicating the content currently being played and an area for inputting past performance information. The In addition, a live preview screen 128 and a search result screen 129 for searching for past performances are displayed as screen change options.
If you right-click on an area showing the content of the current performance or perform an equivalent screen operation, a menu screen for the scheduled live performance will be displayed in the window, and a request to listen to any live performance will be requested. May be accepted.

  In this screen, it is determined whether or not the live audition is selected (step SA114). When the live audition is selected, a live audition request is sent to the shop manager server 5 (step SA115) and sent to the broadcast server 4. Connect (step SA116). Then, a live preview screen is acquired from the broadcast server 4 (step SA117), and the live preview screen is displayed (step SA118). As shown in FIG. 33, the name of the currently playing song, the name of the session, the part of the performer, and the name are displayed on the information broadcast window 130 on the live preview screen. When there is a message from the performer, the message is displayed in the information broadcast window 131.

If the live audition is not selected in step SA114, it is determined whether or not search data for past performance music has been input (step SA119). If the search data is input, the search data is stored in the transmission buffer. (Step SA120). Next, it is determined whether or not a search request has been made (step SA121). If no search request has been made, the process proceeds to step SA114. If a search request has been made, the search request is sent to the broadcast server 4. Send (step SA122). Then, the search result screen is received (step SA123), and the search result screen is displayed (step SA124).
A menu screen may be displayed on the listener audition screen in FIG. In the case of such a configuration, it is also possible to select a search item from the menu and search directly from the music database 9 without going through the shop manager server 5.

  For example, when the search request is a song of “dead leaves”, the search result screen displays a session name that matches the search request as shown in FIG. Further, a purchase screen 119 is displayed as a screen change option. In this screen, it is determined whether or not a session name has been designated by a screen operation such as double-clicking (step SA125). When any session name is designated, the designated session name is emphasized by a bold font or a frame. (Step SA126), the player's part, name, photo, etc. of the session are displayed, and a trial listening request is sent with the session name (step SA127). Then, trial listening data is acquired (step SA128), and trial listening processing is performed (step SA129). When the song ends or when the performance stop 134 switch is operated, the audition data is cleared (step SA130), and the process proceeds to step SA125 to determine whether or not a session name is designated.

  If the session name is not specified, it is determined whether or not a purchase request has been made by a switch on the purchase screen 119 (step SA131). If a purchase request is made, a purchase request is sent by the session name (step SA132). The purchase confirmation screen is received (step SA133), and the purchase confirmation screen is displayed (step SA134). As shown in FIG. 35, a session name and a price are displayed on the purchase (download) confirmation screen, and a previous screen 122 and a purchase settlement screen 123 are displayed as screen change options.

  On this screen, it is determined whether the previous screen 122 is selected to return to the previous screen (step SA135) or the purchase settlement screen 123 is selected for purchase settlement (step SA136). When returning to the previous screen, the process proceeds to step SA122 in the flow of FIG. 13 to send a search request, and the search screen of FIG. 34 is displayed again through steps SA123 and SA124 of FIG. On the other hand, in the case of a payment request, the process proceeds to the flow of FIG. 15, receives a payment screen from the shop manager server 5 (step SA137), stops the connection, and displays the payment screen (step SA138).

  As shown in FIG. 36, the settlement screen displays switches 124 and 125 for selecting a session name, a purchase price, and a settlement method, and a purchase decision switch 126. In addition, switches for the previous screen 122 and the top screen 127 are displayed as screen change options. That is, the content of the settlement screen in FIG. 36 is the same as the settlement screen for performers shown in FIG. 31 except for the numerical value of the price. In the case of a listener, as a matter of course, the price (200 yen) is higher than the price (100 yen) when the performer purchases his / her virtual live performance session data.

  In this screen, it is determined whether or not settlement data has been input (step SA139). If settlement data has been input, the settlement data is stored in the transmission buffer (step SA140). Next, it is determined whether or not a purchase decision is made by operating the purchase decision switch 126 (step SA141a). When a purchase decision is made, the purchase manager is connected to the shop manager server 5 (step SA141b) and the settlement data is obtained. Send (step SA142). Then, the session data is downloaded (step SA143) and stored in a predetermined area of the RAM (step SA144). Next, the process proceeds to step SA21 in the flow of FIG. 5, the connection with the shop manager server 5 is stopped, and the process proceeds to step SA2 in the flow of FIG. 4 to display the initial screen.

  If no purchase decision is made in step SA141a in FIG. 15, it is determined whether or not the previous screen 122 is selected (step SA145) or the top screen 127 is selected (step SA146) on the screen in FIG. To do. When the previous screen is selected, the process proceeds to step SA132 in FIG. 14, and a purchase request is sent with the session name. In this case, the purchase (download) confirmation screen shown in FIG. 35 is displayed. However, since the purchase decision has been abandoned, it is possible to go further to the previous screen and select another session name or search again. become. On the other hand, when the top screen is selected, the process proceeds to step SA2 in the flow of FIG. 4 to display the initial screen.

  After the live preview screen of FIG. 33 is displayed in step SA118 of the flow of FIG. 13, the process proceeds to the flow of FIG. 16 and whether or not a change signal has been received from the broadcast server 4 (step SA147) or is canceled. It is determined whether a screen has been received (step SA148). When the change signal is received, since the virtual live performance session has been changed, the process proceeds to step SA117 in FIG. 13 to obtain the changed live preview screen and display the live preview screen ( Step SA118). In the flow of FIG. 16, when the change signal is not received and the cancel screen is received, the connection of the broadcast server 4 is stopped and the cancel screen is displayed (step SA149). If the cancel screen is not received, it is determined whether or not the switch 132 for returning to the screen of FIG. 33 has been selected (step SA151). When the return switch 132 is selected or after the cancel screen is displayed in step SA149, the shop manager server 5 is connected (step SA150), and the process proceeds to step SA111 in the flow of FIG. In order to audition, send a listener audition request.

  In the flow of FIG. 16, when neither the change signal nor the stop screen is received and the return switch 132 is not selected, the performance data is received (step SA152) and the sound generation process is performed (step SA153). In this case, messages from the current performer are sequentially displayed in the information broadcast window 131 on the screen of FIG. In this state, the listener can select the unpopular switch 133 if the performance is so bad that it cannot be heard. That is, it is determined whether or not the unfavorable switch 133 is turned on during the sounding of step SA153 in FIG. 16 (step SA154), and when this switch is turned on, an unpopular signal is sent (step SA155).

  If the unpopular switch is not turned on or if the unpopular switch is turned on, the process proceeds to step SA147. However, if neither the change signal nor the stop screen is received and the return switch is not selected, performance data is received. The process of sounding is repeated. Therefore, even if the listener cannot tolerate listening, the performance is continued unless a stop screen is received. In this case, the switch for returning is selected, and a listener audition request is sent to listen to another song. If there are many listeners who have turned on the unpopular switch, a stop screen is received in step SA148, and a stop screen is displayed in step SA149. As shown in FIG. 37, the cancel screen displays a session name and a player name together with a message indicating that the session performance is canceled due to unpopularity.

  Even if the performer is connected to the session manager server 3 in step SA4 of the flow of FIG. 4 to perform a virtual live performance, if a request for listening is sent in step SA11 without making a session participation request for the time being, If the profile is sent in step SA109 in the flow of FIG. 13 and the ID and password are acquired in step SA110, a listener audition request can be sent in step SA111. However, a user who is not a performer but who wants to listen to or purchase a session performance as a listener from the beginning can also register with this system.

  That is, when the trial listening 103 is selected on the initial screen of FIG. 18, it is determined in step SA156 in the flow of FIG. 17 that a connection operation has been made to the trial listening site. In this case, connection to the shop manager server 5 (step SA157), a trial listening request is sent (step SA158), an agreement screen is received (step SA159), and an agreement screen similar to FIG. 20 is displayed (step SA159). Step SA160). Then, it is determined whether or not to agree (step SA161). If not agreed, the connection is stopped (step SA21 in FIG. 5), and an initial screen is displayed. When agreeing, a listener consent is sent (step SA162), a listener registration screen is received (step SA163), and a listener registration screen similar to FIG. 22 is displayed (step SA164).

  Next, it is determined whether or not a profile has been input (step SA165). When the profile has been input, the profile is stored in the transmission buffer (step SA166). Then, it is determined whether or not registration is selected (step SA167). If not registered, the connection with the shop manager server 5 is stopped (step SA21 in FIG. 5), and an initial screen is displayed, but registration is performed. In this case, the profile is sent (step SA168), and the ID and password are acquired (step SA169). Thereafter, the process proceeds to step SA111 in the flow of FIG. 13 and a listener audition request is sent to the shop manager server 5.

Next, the operation of the broadcast server 4 will be described with reference to the flowcharts of the main routine shown in FIGS.
In the flow of FIG. 38, the current time is acquired (step SB1), and it is determined whether or not the flag STF indicating broadcasting of performance data is “0 (broadcast stop)” (step SB2). If the STF is “0”, the performance program database 7 is searched (step SB3) to determine whether there is a performance program whose current time is the start time (step SB4). If there is a performance program whose current time is the start time, STF is set to “1 (broadcast)” (step SB5), and an empty area is secured in the song database 9 (step SB6). Next, it is determined whether or not a trial listening request from any terminal device 1 transferred via the shop manager server 5 has been received (step SB7a). If a trial listening request is not received, the process proceeds to step SB2. If a trial listening request is received, a live audition screen based on the performance program is created (step SB7b). Next, a register NG for sending the change signal indicating the change of the session and the terminal device 1 requesting the audition of the live audition screen (step SB8) and accumulating the number of reception of the unpopular signal from the terminal device 1 is stored. It is cleared to “0” (step SB9). Then, the process proceeds to step SB2.
If the STF is “1” in step SB2, it is determined whether or not it is the end time of the song being played (step SB10). If it is the song end time, the STF is reset to “0” (step SB11), and an end signal is sent to the terminal device 1 (step SB12). And it transfers to step SB1 and acquires the present time.

  If it is not the end time of the song being played at step SB10, that is, if the performance continues, it is determined whether or not an unpopular signal has been received from the terminal device 1 in the flow of FIG. 39 (step SB13). . When an unpopular signal is received, the value of NG is incremented (step SB14), and it is determined whether or not the value of NG has reached a specified value (step SB15). When the NG value reaches the specified value, the STF is reset to “0” (step SB16) and the music data is cleared (step SB17). Then, a stop screen is sent to the terminal device 1 (step SB18), and a stop signal is sent to the session manager server 3 (step SB19). And it transfers to step SB1 of FIG. 38 and acquires the present time.

  If no unpopular signal is received in step SB13 in FIG. 39, or if the NG value is less than the specified value in step SB15, the performance data of each part transmitted is received (step SB20) and received. The performance data of each part thus transmitted is transmitted to the other terminal devices 1 other than the terminal device 1 of that part (step SB21). In this case, it is determined whether or not there is an undetermined part (step SB22). If there is an undetermined part, performance data of an exemplary (or existing) part is transmitted (step SB23). Thereafter, the process proceeds to step SB1 in FIG. 38 to acquire the current time.

Next, the operation of the session manager server 3 will be described with reference to flowcharts of interrupt processing shown in FIGS. 40 to 56 executed in response to an interrupt generated during execution of a main routine (not shown).
When a connection request to the registration site is received from the terminal device 1, the start screen shown in FIG. 19 is sent in the flow of FIG. 40 (step SC1). When a session participation request is received from the terminal device 1, the consent screen shown in FIG. 20 is sent in the flow of FIG. 41 (step SC2). When consent is received from the terminal device 1, a registration screen is sent in the flow of FIG. 42 (step SC3). When not agreeing from the terminal device 1, the connection with the terminal device 1 is stopped in the flow of FIG. 43 (step SC4).

When the virtual live performance player's profile and the desired performance are received from the terminal device 1, the received contents are temporarily stored (step SC11) in the flow of FIG. 44, and the performance program database 7 is searched. (Step SC12). Then, it is determined whether or not there is a program of a desired performance (step SC13). If there is such a program, it is determined whether or not there is a vacant part of the desired performance (step SC14). If there is a vacancy in the part, a notice screen is created based on the desired musical piece program (step SC15).
If there is no program for the desired performance in step SC13, or if there is no free part in the desired performance in step SC14, the free time is searched from the performance program database 7 (step SC16). Then, a preview screen is created based on the desired song name, idle performance date and time, and desired part (step SC17).
The notice screen created in step SC15 or step SC17 is sent to the terminal device 1 (step SC18), and the process returns to the main routine. As a result, the notice screen shown in FIG. 23 is displayed on the terminal device 1.

In the notice screen that has been sent, when an acknowledgment is received from the terminal device 1, in the flow of FIG. 45, an ID and a password are created (step SC21), and the profile of the performer temporarily stored is set to the ID and password. The password is stored in the performer database 6 together with the password (step SC22). Next, the performer ID is stored in the desired part of the designated performance program database 7 (step SC23). Then, the ID and password are sent to the terminal device 1 (step SC24), and the process returns to the main routine.
In the notice screen that has been sent, when it is received from the terminal device 1 that it does not agree, the temporarily stored data such as the player's profile is cleared in the flow of FIG. 46 (step SC25), and the main routine is entered. Return.

  When a connection request to the performance site is received from the terminal device 1, an ID and password request screen is sent in the flow of FIG. 47 (step SC31). When the ID and password input on the screen of ID and password are received from the terminal device 1, authentication processing based on the ID and password is performed in the flow of FIG. 48 (step SC 41), and the performance program database 7 performs the performance. The program is searched (step SC42). Then, the time from the current time to the start of the performance program searched, that is, the waiting time is detected (step SC43). A session standby screen is created based on the searched performance program and waiting time (step SC44), and the session standby screen is sent to the terminal device 1 (step SC45). As a result, the session standby screen shown in FIG. 25 is displayed on the terminal device 1.

FIG. 49 is a flowchart of a timer interrupt at regular intervals in the session manager server 3. It is determined whether or not there is a terminal device 1 that is displaying the session standby screen (step SC51). If there is no such terminal device 1, the process returns to the main routine. If there is a corresponding terminal device 1, The waiting time previously sent to the terminal device 1 is subtracted (step SC52). As a result of this subtraction, it is determined whether or not the waiting time has reached “0” (step SC 53). If the waiting time has not reached “0”, the subtracted waiting time is sent to the terminal device 1. (Step SC54), the process returns to the main routine. As a result, the waiting time on the session waiting screen in FIG. 25 is updated.
When the waiting time reaches “0” in step SC53, a playing screen is created (step SC55), the created playing screen is sent to the terminal device 1 (step SC56), and the process returns to the main routine. As a result, the playing screen shown in FIG. 26 is displayed on the terminal device 1.

When a session end signal is received from the broadcast server 4, a session name is created in the flow of FIG. 50 (step SC61), stored in the corresponding area of the song database 9 (step SC62), and an end screen based on the session name Is created (step SC63). The end screen and the session name are sent to the terminal device 1 (step SC64), and the process returns to the main routine. As a result, the session end screen shown in FIG.
When the session manager server 3 receives various requests or signals according to the operation of the terminal device 1 on the session end screen of FIG. Then, processing corresponding to the request or signal is performed.
When a questionnaire request is received from the terminal device 1, a questionnaire screen is sent in the flow of FIG. 51 (step SC71). When the request for the previous screen is received from the terminal device 1, the end screen and the session name are sent in the flow of FIG. 52 (step SC81).
When questionnaire data is received from the terminal device 1, the questionnaire data is stored in the performance program database 7 in the flow of FIG. 53 (step SC91), and an end screen and a session name are sent (step SC92). When the end signal is received from the terminal device 1, the connection is stopped in the flow of FIG. 54 (step SC101). When a trial listening request is received from the terminal device 1, an agreement screen is sent in the flow of FIG. 55 (step SC111). When a stop signal is received from the broadcast server 4, the performance program database 7 is searched in the flow of FIG. 56 (step SC121), and the searched program is deleted (step SC122).

Next, the operation of the shop manager server 5 will be described with reference to the flowcharts of interrupt processing shown in FIGS. 57 to 71 executed in response to an interrupt generated during execution of a main routine (not shown).
When the virtual live performance session name and the audition request are received from the terminal device 1, the audition request screen is sent in the flow of FIG. 57 (step SD1). When the session name and the trial listening operation are received from the terminal device 1, the music database 9 is searched based on the session name in the flow of FIG. 58 (step SD11), and the trial data is generated based on the searched music data (step SD11). SD12), the trial data is sent (step SD13). When the previous screen request is received from the terminal device 1, the previous screen request is sent to the session manager server 3 in the flow of FIG. 59 (step SD21).

  When a session name and a purchase request are received from the terminal device 1, a purchase screen is sent in the flow of FIG. 60 (step SD31). As a result, the purchase (download) screen of FIG. 30 is displayed on the terminal device 1. When a session name and a purchase settlement request are received from the terminal device 1, a purchase settlement screen is sent in the flow of FIG. 61 (step SD41). As a result, the purchase settlement screen shown in FIG. 31 is displayed on the terminal device 1. When a request for a top screen is received from the terminal device 1, a registration site connection request is sent to the session manager server 3 in the flow of FIG. 62 (step SD51).

  When the settlement data such as the session name, bank name, and account number is received from the terminal device 1, the settlement data is sent to the settlement organization in the flow of FIG. 63 (step SD61). Thereafter, when the settlement end is received from the settlement organization, the corresponding song data is retrieved from the song database 9 in the flow of FIG. 64 (step SD71), and the song is sent to the terminal device 1 that has sent the settlement data. Data is sent (step SD72).

  When the listener consent is received from the terminal device 1, a listener registration screen is sent in the flow of FIG. 65 (step SD81). As a result, the preview / purchase screen of FIG. 22 is displayed on the terminal device 1. Thereafter, when the listener profile is received from the terminal device 1, the ID and password and the received profile are stored in the listener database 8 in the flow of FIG. 66 (step SD91), and the ID and password are sent to the terminal device 1. (Step SD92). Next, when a listener audition request is received from the terminal device 1, a listener audition screen is sent in the flow of FIG. 67 (step SD101). As a result, the listener audition screen shown in FIG. 32 is displayed on the terminal device 1.

  Thereafter, when a live audition request is received from the terminal device 1, the currently executed performance program is searched in the flow of FIG. 68 (step SD111), and the address and session name of the terminal device 1 of the audition request are included. The live audition request is transferred to the broadcast server 4 (step SD112). As a result, the broadcast server 4 creates a live audition screen based on the program in step SB7b of FIG. 38 and sends the live audition screen in step SB8, so that the live audition screen of FIG. 33 is displayed on the terminal device 1. The

  When search data is received from the terminal device 1, in the flow of FIG. 69, the music database 9 is searched based on the search data (step SD121), and a search result screen is created based on the search result (step SD122). A result screen is sent (step SD123). As a result, the search result screen of FIG. 34 is displayed on the terminal device 1. When a request for connection to the trial listening site is received from the terminal device 1, an ID and a password screen are sent in the flow of FIG. 70 (step SD131). And when ID and a password are received from the terminal device 1, an authentication process is performed in the flow of FIG. 71 (step SD141).

As described above, according to the above embodiment, the session manager server 3 responds to a virtual live performance performance application from any terminal device 1 connected via the Internet 2 with a plurality of virtual live performance performances. Manage each performer and performance schedule that make up the part. In the virtual live performance according to the performance schedule managed by the session manager server 3, the broadcast server 4 receives the performance data of the performer's part received from the terminal device 1 of the performer who applied for the performance. The performance data of a plurality of parts transmitted to the terminal device 1 of each performer and the terminal device 1 for which a trial listening application has been applied to the virtual live performance is received in the music database 9. Remember. In response to a purchase application for performance data of a virtual live performance from an arbitrary terminal device 1 connected via the Internet 2, the shop manager server 5 transmits performance data corresponding to the application.
Therefore, by obtaining evaluations from listeners and other performers, it is possible to expect improvements in the skills of each performer and to develop music activities as a business. In addition, anyone can perform virtual live performances and audition performances at any time and anywhere via a network deployed around the world, such as the Internet, enabling the realization of a music ubiquitous service business.

In the virtual live performance support system according to the embodiment, the session manager server 3 is configured such that when the virtual live performance corresponding to the performance application is composed of a predetermined number of parts, there is no performance application for all the parts. The performance data of a part for which no performance application has been made is read from the music database 9 and assigned as a performer of that part.
Therefore, even if all the part performers are not available, a virtual live performance can be performed if the minimum number of part performers participate.

In the virtual live performance support system according to the embodiment, the broadcast server 4 transmits the performance data of the virtual live performance currently being performed to the terminal device 1 that has applied for trial listening. If you receive an unpopular notification from, stop the live performance.
Accordingly, it is possible to prevent the use of live performance resources including performance time and network occupancy due to live performance that is unpopular with many listeners who are listening.

In the virtual live performance support system according to the embodiment, the shop manager server 5 transmits the performance data in response to a purchase application for the performance data of the virtual live performance from an arbitrary terminal device 1. Settlement is performed to receive purchase consideration from the account number of the financial institution of the user of the device 1.
Therefore, it is possible to provide a quick service for the purchase application and to reduce the cost for the settlement process.

In the virtual live performance support system according to the embodiment, the session manager server 3 reaches the terminal device 1 corresponding to the performance application for the virtual live performance until the virtual live performance start time is reached based on the performance schedule. Give notice of performance time.
Therefore, the performer does not need to wait in front of the terminal device until his / her performance starts, and can effectively use the waiting time.

In the virtual live performance support system in the embodiment, the shop manager server 5 responds to a trial application when a trial application for performance data of a virtual live performance performed in the past from any terminal device 1 is made. The performance data to be searched is retrieved from the music database 9 and transmitted to the terminal device 1.
Therefore, even if the listener misses a virtual live performance that has been performed in the past, the listener can examine whether or not to purchase the performance data by trial listening.

  In the above embodiment, the invention of the apparatus for executing the virtual live performance support processing program stored in advance in the program memory by the control unit such as the CPU has been described. However, the present invention is realized by a system such as a general-purpose personal computer. It is also possible to do. In other words, a virtual live performance support processing program installed on a hard disk of a personal computer or downloaded from a network such as the Internet is installed on a virtual live performance support processing program recorded on a storage medium such as a flexible disk (FD), CD, or MD. Can be installed and the program can be executed by the CPU of the personal computer. In this case, the invention of the program and the invention of the recording medium on which the program is recorded can be realized.

That is, the virtual live performance support processing program according to the present invention is:
A first step of managing each player and a performance schedule constituting a plurality of parts of the virtual live performance in response to a virtual live performance performance application from an arbitrary terminal device connected via a network; In the virtual live performance according to the performance schedule managed by one step, the performance data of the performer's part received from the terminal device of the performer who applied for the performance, A second step of transmitting performance data of a plurality of parts transmitted from the terminal device of each performer to a terminal device for which a trial listening application has been applied for virtual live performance, and storing the performance data in a predetermined storage means; and the network In response to purchase application for performance data of virtual live performance from any terminal device connected via A third step of transmitting the performance data corresponding to the write, the execution.

  In the first step, when the virtual live performance related to the performance application is composed of a predetermined number of parts, if there is no performance application for all the parts, the performance data of the part for which there is no performance application is stored in the memory It is read out from the means and assigned as performance data of the performer of the part.

  In the second step, when performance data of a virtual live performance currently being performed is transmitted to the terminal device for the trial application, a notification of unpopularity is received from a predetermined number or more of terminal devices related to the trial application. When it is received, the live performance is stopped.

  In the third step, when the performance data is transmitted in response to the purchase application for the performance data of the virtual live performance from an arbitrary terminal device, the purchase price is calculated from the account number of the financial institution of the user of the terminal device. Make a payment to receive.

  In the first step, a notice of performance time is given to the terminal device corresponding to the performance application for the virtual live performance until the start time of the virtual live performance is reached based on the performance schedule.

  In the third step, when a trial application for performance data of a virtual live performance performed in the past from any terminal device is made, the performance data corresponding to the trial application is retrieved from the storage means and the terminal Send to device.

In the above-described embodiment, the shop manager server 5 may be configured to receive a request from a listener by providing a function of a song or performer request site. When the requested song or the virtual live performance of the performer is scheduled, the shop manager server 5 may notify the terminal device or mobile phone of the listener who requested the information.
Furthermore, in the above embodiment, when a performer is clicked on the performer screen of FIG. 32, a menu screen of the performer's profile may be displayed in a window so that desired items can be browsed.
Furthermore, in the above embodiment, the information on the notice screen of FIG. 23 may be sent not only to the terminal device 1 but also to the performer's mobile phone. In addition, the performer may use a calendar function of the mobile phone to apply for a performance from the mobile phone.
Further, in the above embodiment, the session manager server 3 aggregates the data of performers waiting for the part because the desired part is not prepared, randomly organizes the session, and performs the performance of the corresponding part of the session. You may make the structure proposed to a person.

The figure which shows the structure of the assistance system of the virtual live performance in embodiment of this invention. (A) is a figure which shows the data structure of the performance program database of FIG. 1, (B) is a figure which shows the data structure of the performer database of FIG. (C) is a figure which shows the data structure of the music database of FIG. 1, (D) is a figure which shows the data structure of the listener database of FIG. The flowchart which shows operation | movement of the terminal device of FIG. The flowchart which shows operation | movement of the terminal device following FIG. The flowchart which shows operation | movement of the terminal device following FIG. 7 is a flowchart showing the operation of the terminal device following FIG. The flowchart which shows operation | movement of the terminal device following FIG. The flowchart which shows operation | movement of the terminal device following FIG. 10 is a flowchart showing the operation of the terminal device following FIG. 11 is a flowchart showing the operation of the terminal device following FIG. The flowchart which shows operation | movement of the terminal device following FIG. The flowchart which shows operation | movement of the terminal device following FIG. 14 is a flowchart showing the operation of the terminal device following FIG. The flowchart which shows operation | movement of the terminal device following FIG. 14 is a flowchart showing the operation of the terminal device following FIG. 7 is a flowchart showing the operation of the terminal device following FIG. The figure of the initial screen displayed on the terminal device of FIG. The figure of the start screen displayed on the terminal device of FIG. The figure of the consent screen displayed on the terminal device of FIG. The figure of the performance registration screen displayed on the terminal device of FIG. The figure of the trial listening / purchase registration screen displayed on the terminal device of FIG. The figure of the notice screen displayed on the terminal device of FIG. The figure of the music detailed description part in the notice screen displayed on the terminal device of FIG. The figure of the session standby screen displayed on the terminal device of FIG. The figure of the screen during performance displayed on the terminal device of FIG. The figure of the session end screen displayed on the terminal device of FIG. The figure of the questionnaire screen displayed on the terminal device of FIG. The figure of the preview screen for performers displayed on the terminal unit of FIG. The figure of the purchase screen displayed on the terminal device of FIG. The figure of the purchase settlement screen displayed on the terminal device of FIG. The figure of the listener audition screen displayed on the terminal device of FIG. The figure of the live audition screen displayed on the terminal device of FIG. The figure of the search result screen displayed on the terminal device of FIG. The figure of the purchase screen displayed on the terminal device of FIG. The figure of the purchase settlement screen displayed on the terminal device of FIG. The figure of the cancellation screen displayed on the terminal device of FIG. The flowchart of the main routine in the broadcast server of FIG. The flowchart of the main routine of the broadcast server following FIG. 6 is a flowchart of sending a start screen in the session manager server of FIG. The flowchart of consent screen transmission in the session manager server of FIG. The flowchart of registration screen transmission in the session manager server of FIG. The flowchart of the connection stop in the session manager server of FIG. The flowchart of the profile reception process in the session manager server of FIG. The flowchart of the reception process of consent consent in the session manager server of FIG. The flowchart of the reception process of consent disapproval in the session manager server of FIG. The flowchart of the reception process of the performance site connection request in the session manager server of FIG. The flowchart of the reception process of ID and password in the session manager server of FIG. The flowchart of the timer interrupt in the session manager server of FIG. The flowchart of the reception process of the session end signal in the session manager server of FIG. The flowchart of the reception process of the questionnaire request | requirement in the session manager server of FIG. The flowchart of the reception process of the previous screen request in the session manager server of FIG. The flowchart of the reception process of the questionnaire data in the session manager server of FIG. 4 is a flowchart of end signal reception processing in the session manager server of FIG. 1. 5 is a flowchart of a process for receiving a trial listening request in the session manager server of FIG. The flowchart of the reception process of the cancellation signal in the session manager server of FIG. 7 is a flowchart of a process for sending a preview request screen in the shop manager server of FIG. The flowchart of the reception process of session name trial listening operation in the shop manager server of FIG. The flowchart of the reception process of the previous screen request | requirement in the shop manager server of FIG. The flowchart of the reception process of the purchase request in the shop manager server of FIG. The flowchart of the sending process of the purchase settlement screen in the shop manager server of FIG. The flowchart of the reception process of the top screen request | requirement in the shop manager server of FIG. The flowchart of the payment data reception process in the shop manager server of FIG. The flowchart of the reception process of the payment end in the shop manager server of FIG. The flowchart of the reception process of listener consent in the shop manager server of FIG. The flowchart of the reception process of the listener profile in the shop manager server of FIG. The flowchart of the reception process of the listener audition request in the shop manager server of FIG. The flowchart of the transmission process of the live audition request | requirement screen in the shop manager server of FIG. The flowchart of the search data reception process in the shop manager server of FIG. The flowchart of the reception process of the audition site connection in the shop manager server of FIG. The flowchart of ID and password reception processing in the shop manager server of FIG.

Explanation of symbols

1 terminal device 2 internet 3 session manager server 4 broadcast server 5 shop manager server 6 performer database 7 performance program database 8 listener database 9 song database

Claims (2)

A first server that manages each player who configures a plurality of parts of the virtual live performance and a performance schedule in response to a virtual live performance performance application from an arbitrary terminal device connected via a network;
In the virtual live performance according to the performance schedule managed by the first server, the performance data of the player's part received from the terminal device of the performer who applied for the performance is used. And a second server that transmits the performance data of a plurality of parts that are transmitted from the terminal device of each performer to the terminal device that has been subscribed to the virtual live performance and that is stored in a predetermined storage unit.
In response to a purchase application for performance data of a virtual live performance from an arbitrary terminal device connected via the network, the settlement data is sent to a settlement institution, and when the end of settlement is received from the settlement institution, the predetermined memory is stored. Find the performance data corresponding to the application from the device, and a third server that sends performance data the search to the arbitrary terminal apparatus,
When the second server transmits performance data of a virtual live performance currently being performed to the terminal device for the trial application, the second server sends a notice of unpopularity from a predetermined number of terminal devices for the trial application. A virtual live performance support system characterized by stopping the live performance when received. On the computer,
A first step of managing each player and a performance schedule constituting a plurality of parts of the virtual live performance in response to a performance application of the virtual live performance from an arbitrary terminal device connected via a network;
In the virtual live performance according to the performance schedule managed in the first step, the performance data of the performer's part received from the terminal device of the performer who applied for performance is used as the terminal device of the performer of the other part. And the performance data of a plurality of parts received from each performer's terminal device are stored in a predetermined storage means, and the currently playing virtual If live performance data is being transmitted to the terminal device for the trial application, and if a notice of disapproval is received from a predetermined number of terminal devices for the trial application, the live performance is stopped. Two steps,
In response to a purchase application for performance data of a virtual live performance from an arbitrary terminal device connected via the network, the settlement data is sent to a settlement institution, and when the end of settlement is received from the settlement institution, the predetermined memory is stored. A third step of retrieving performance data corresponding to the application from the means and transmitting the retrieved performance data to the arbitrary terminal device;
A virtual live performance support program that runs

Images