JPH09321915A - Broadcast center - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide the broadcast system in which charging on users is impartially imposed. SOLUTION: A host computer generates an aggregation file (S610) in a CPU memory and discriminates whether or not a subscriber number counter indicates number of registration parties of a subscriber database or over (S630), resulting that when the number is not the registration number or over (S630: No), data equipment to one record are acquired from the file (S660). The subscriber record acquired subscriber database is compared with a subscriber code in a record (S670), and when they are coincident, whether or not the subscriber number is 2 or over is discriminated. As a result, when the result indicates two persons or over, a monetary amount obtained by dividing a monetary amount per one music by number of subscribers is set to a calculated monetary amount work. Thus, the share of charge depending on 'split bill' by number of the users is properly realized.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a broadcasting center with a request response function, which sequentially broadcasts broadcasting information according to a broadcasting request individually made by a viewer, in accordance with a predetermined order. The present invention relates to a broadcasting center effective for use in a system that charges a predetermined fee for request response.

[0002]

2. Description of the Related Art At present, a new form of TV broadcasting called interactive television is becoming popular between a local television broadcasting center such as a CATV system and a subscriber terminal. .
Then, the broadcasting center of such a system not only sends the decided information at the decided time, but also sequentially broadcasts the broadcasting information according to the broadcast request individually made by the viewer in a predetermined order. It also has a request response function. For example, a program time frame (or a dedicated channel provided) that handles only karaoke broadcasting called a karaoke request program is adopted, and in this program, a request from a viewer is received via a telephone, etc. For example, it broadcasts karaoke on request.

When broadcasting karaoke according to a request in this way, for example, it is conceivable that requests up to a predetermined number of songs are received and reserved, and karaoke according to the reservation request is sequentially broadcast. . In this case, there may be a request that the request itself has already been reserved but the corresponding karaoke song has not yet started broadcasting. If the request in such a state and the newly made request are the same, if you reserve even the newly made request, the same karaoke song will be broadcast many times,
It will lead to a rut of the broadcast content.

Further, as a user who has made a request,
Whether the song you requested or someone else's request, the karaoke song you want should be broadcast, so your request has already been met by broadcasting the karaoke song requested by another person. Becomes Therefore, even if the karaoke song corresponding to the one requested by the user is broadcasted this time, since the same karaoke song has already been broadcasted, the necessity for the requesting user becomes very small.

Therefore, when the request itself has already been reserved but the same request for broadcasting the karaoke piece corresponding thereto has not been started yet, the reservation data for broadcasting the corresponding karaoke piece is made. As for, it is preferable not to register in order to enhance the broadcast content.

On the other hand, in the case of broadcasting information according to a request as described above, when a predetermined fee is imposed on the response to the request, not a so-called quantitative fee system but a pay-per-use fee system. The need to introduce comes out. That is, the requesting user bears (paies) the fee.

However, with respect to the charge collection in this case, it may be inconvenient if the charge is simply calculated based on only the number of requests. This is because, as described above, some of the requested items are not registered as the reservation data of the karaoke piece to be broadcast, from the viewpoint of preventing the content of the broadcast from becoming routine. In such a case, if the fee is simply calculated based on the number of requests, the number of broadcast songs and the number of requests for which the fee is collected will be different, and the broadcasting system side will get some free It will be a situation that will end up.

On the other hand, in the case of a karaoke piece for which duplicate requests have been made, it is possible to charge only the user who made the initial request and not charge the user who made subsequent duplicate requests. Depending on the order, there will be a problem that the fee paid becomes unfair. In other words, extremely speaking, theoretically, some users may be charged as usual for all requests depending on the timing of the request, and conversely, some users may not be charged at all for all requests. There is.

The same problem is conceivable not only for television broadcasting but also for radio broadcasting and other broadcasting. The present invention basically has a function of broadcasting broadcast information in response to a request from a viewer and storing performance information for charging a predetermined fee corresponding to the request for each viewer who has requested. While preparing, if there are more duplicate requests, we will improve the content of the broadcast, and at the same time, we will establish a broadcasting center that can respond appropriately to improve the convenience of the user, such as so-called “split sharing”. The purpose is to provide.

[0010]

Means for Solving the Problems and Effects of the Invention The broadcasting center of the present invention made to achieve this object receives broadcast requests individually made from viewers using a communication line and stores the requests. Request accepting means for automatically accumulating as data in the means, broadcasting means for sequentially broadcasting broadcasting information according to a broadcast request stored in the request accumulating means in a predetermined order, and the request accepting means With a request response function provided with a charging record information storage unit that stores record information for charging a predetermined fee corresponding to the broadcast request stored in the request storage unit for each viewer who requested the broadcast. In the broadcast center, the broadcast request received by the request receiving means is already stored in the request storage means, but the broadcast information of the broadcast information according to the broadcast request is received by the broadcast means. If the transmission is a duplicate broadcast request that is the same as the broadcast request that has not been started yet, the request receiving unit is configured not to execute storage in the request storing unit, and is received by the request receiving unit. Regarding the broadcast request, of course, if it is not the duplicate broadcast request,
A request reception result storage unit that stores at least a viewer identification number for each target broadcast information as the request reception result even when the request accumulation unit does not perform the accumulation because of the duplicate broadcast request. And, based on the number of viewer identification information corresponding to the broadcast information in the requested reception record storage means at the time of broadcasting the broadcast information, a charge for one broadcast information is paid according to the number of information. The billing record information storage unit stores the billing record information set in this manner in all the corresponding viewers in the billing record information storage unit.

The broadcasting center of the present invention having the above structure is
The request receiving means receives the broadcast request individually made by the viewer using the communication line, and automatically stores it as data in the request storing means. Then, the broadcasting means stores the broadcasting information according to the broadcasting request stored in the request accumulating means,
It has a request response function that broadcasts sequentially according to a predetermined order.

[0012] Further, in the charging record information storage means, record information for charging a predetermined fee corresponding to the broadcast request stored in the request storage means by the broadcast request receiving means is provided for each viewer who has made a broadcast request. You can remember. Predetermined charges and fees are separately collected based on this record information. For example, an automatic withdrawal from a financial institution or a charge collection staff on the manager side goes directly to the user to collect the charges.

In this way, the basic functions of request response and storage of record information for billing are provided, and further the following functions are exhibited. That is, the broadcast request received by the request accepting unit is already stored in the request storing unit, but the broadcast of the broadcast information corresponding to the broadcast request by the broadcast unit is the same as the broadcast request that has not been started yet. In the case of a duplicate broadcast request, the request receiving means does not execute the accumulation in the request accumulating means if the received broadcast request is a duplicate broadcast request.

As described above, when the received broadcast request is a duplicate broadcast request, by not accumulating in the request accumulating means, it is possible to prevent the broadcasting of information that is not necessary to be broadcast, and Leads to fulfillment. In other words, in the case of a duplicate broadcast request, the broadcast information corresponding to the broadcast request that has already been stored but has not started broadcasting will be broadcast from now on, so for the viewer who made the duplicate broadcast request, The broadcast information will satisfy the request. Therefore, if duplicate broadcast requests are stored as they are, the same broadcast information will be broadcast after the broadcast information corresponding to the broadcast request made by the user is broadcast. The need for is very thin.

Therefore, by controlling not to broadcast the broadcast information corresponding to such a duplicate broadcast request, it is possible to prevent the broadcast of unnecessary broadcast information while satisfying the viewer's request. It is possible to enhance the broadcast content. In particular, when the period for accepting a broadcast request is limited, it is not necessary for a person who really wants to make a broadcast request because of a needless broadcast request, or the broadcast time is delayed. It hinders the enrichment of contents and the convenience of users. Therefore, not broadcasting such unnecessary broadcast information leads to the enhancement of the broadcast content and the convenience of the user.

Further, according to the present invention, the broadcast request received by the request accepting means is requested not only when it is not a duplicate broadcast request but also when the request is not accumulated in the request accumulating means because it is a duplicate broadcast request. At least a viewer identification number is stored in the reception result storage means as a request reception result for each target broadcast information. Then, based on the number of viewer identification information corresponding to the broadcast information in the request reception record storage unit at the time of broadcasting the broadcast information, the billing record setting unit corresponds to one broadcast information according to the number of information. Billing record information set to bear the fee
The billing record information storage means stores it for all the relevant viewers.

As a result, it becomes possible to appropriately deal with the charge collection. For example, if it is simply calculated as a normal charge based only on the actual performance of broadcast requests (for example, the number of times), the number of broadcast information actually broadcast differs from the number of broadcast requests subject to charge collection, and the broadcast system business The situation will be such that some of the workers take some money. Also,
It is possible to charge only the user who first made a broadcast request, and not to the user who made a duplicate broadcast request thereafter, but this makes the charges to be unfair depending on the order of broadcast requests. Will end up. In other words, extremely speaking, theoretically, some users will be charged as usual for all broadcast requests depending on the timing of broadcast request, and conversely, some users will not be charged for all broadcast requests at all. there's a possibility that.

Therefore, according to the present invention, the normal charge for the number of broadcast information actually broadcast can be collected at the broadcasting center side, and also for the user side, if a plurality of charges are used, the charge can be obtained. It is preferable from the point of fair and sound system operation because it can realize an appropriate fee burden according to the number of users.

That is, basically, a function of broadcasting broadcasting information in response to a request from a viewer and storing performance information for charging a predetermined fee corresponding to the request for each viewer In addition, when there are duplicate requests, it is possible to take appropriate measures to improve the convenience of the user, such as so-called “split split”, while enhancing the broadcast content. Of. In addition, in the case of "paying the charge for one broadcasting information according to the number of information", the above-mentioned "divided bill" which is borne in average by the number of information is general, but other burden method Does not exclude. For example, if a certain condition is met, it is also possible to adopt a method in which the fee burden for that user is discounted from the average, and the remaining fees are divided by the other users. is there.

As described above, when the broadcast requests are duplicated under a certain condition, the broadcast requests are not stored in the request storage means, but the broadcast center determines the number of broadcast requests based on the number of broadcast requests. For example, it is preferable to leave a record of the fact that the broadcast request itself has been made for various reasons such as creating a request ranking. Therefore, even in the case of the present invention, the request reception record itself can be stored,
It is also advantageous for use in creating request rankings.

Further, as described in claim 2, in the case of the duplicate broadcast request, the fact that the broadcast requests are duplicated is notified to the viewer side who has transmitted the broadcast request via the communication line. You may respond as voice information. In this way, the viewer can recognize that the broadcast requests are duplicated.

Further, although the response means responds to the viewer that the broadcast requests are duplicated, as described in claim 3, in addition to the fact that the broadcast requests are duplicated, it is already stored. Information about the broadcast start schedule of the broadcast information according to the earliest of the broadcast requests that have not been broadcast may be returned.

Further, as the broadcasting information broadcast from such a broadcasting center, for example, information for karaoke can be considered. In this case, as described in claim 4, the broadcasting means is
The television broadcasting means is capable of transmitting audio information and video information, and the broadcasting information broadcast by the broadcasting means is a karaoke performance sound corresponding to the requested karaoke song and a video in which a lyrics telop is combined with the background video. May be included.

Of course, even if only the karaoke performance sound is broadcast as the broadcasting information, it can be established as karaoke, but in the present karaoke, an image in which the lyrics telop is combined with the background image is no longer displayed together with the karaoke performance. Since it is becoming common knowledge, it can be said that it is preferable to broadcast the broadcasting information including the karaoke performance sound and the video in which the lyrics telop is combined with the background video. In this case, the broadcasting center and the subscriber terminal may be connected by a wire like a so-called CATV, or may be wireless as in a normal broadcasting system. Further, it may be considered that only audio information or only video information is used.

When receiving the broadcast request from the viewer, the request receiving means transmits predetermined audio information for guidance to the viewer side, and receives the broadcast request as a response to the audio information for guidance. Good. In this case, the viewer only needs to operate in accordance with the guidance voice information, and the convenience of the viewer is further improved. For example, since it is necessary to actually transmit the viewer identification information and the like, it is convenient to have guidance.

The communication line used by the request receiving means for receiving the broadcast request may be a telephone line, or if bidirectional full-duplex communication is realized via a CATV coaxial cable. The coaxial cable may be used.
In the case of a telephone line, for example, a request number or the like may be input with a push button or the like of a telephone, the request number may be transmitted as a code using a dial tone, and the request receiving means may receive it.

[0027]

BEST MODE FOR CARRYING OUT THE INVENTION An embodiment of a broadcasting center of the present invention will be described below with reference to the drawings. FIG. 1 is a block diagram showing a schematic configuration of a broadcasting center 10 of this embodiment. As shown in FIG. 1, the broadcasting center 10 includes a host computer 11 as control means corresponding to “billing history setting means” and “response means”, a “billing history information storage means”, and a “request reception history storage means”. Storage device 12 as a display device, a display device 13 as a display device, a karaoke reproducing device 14, and a broadcasting device 16 as a "broadcasting device".
And a voice response device 20 as "request receiving means". Further, the broadcasting center 10 has a public telephone line 40
It is connected to a large number of subscriber telephones 50 via.

Each of the constituent devices will be described including the role of the broadcasting center 10 and the relation with the entire broadcasting system. The voice response device 20 accepts a broadcast request from the viewer, and when the broadcast is a predetermined “duplicate broadcast request”, the fact is notified, and information regarding the broadcast start schedule of the broadcast information corresponding to the broadcast request is provided as voice information. To respond as. The duplicate broadcast request will be described later.

First, the reception of the broadcast request will be described in detail. The main broadcast center 10 stores broadcast requests individually made by viewers, and sequentially broadcasts broadcast information (karaoke information in the case of the present embodiment) according to the broadcast requests. Although it has a response function, the viewer can watch the television receiver (not shown) connected to the main broadcasting center 10 by the cable TV at his home while A request is made to broadcast desired karaoke information through a general public telephone line 40. This broadcast request is made by a predetermined "request code". This is synonymous with the "song number" in a general karaoke device only for providing karaoke viewing. Since the request is made by a numerical code, the viewer actually makes a tone transmission of the request code by dialing the subscriber telephone set 50 or pressing down the touch-tone telephone. It is assumed that this request code has been notified to the viewer in advance by a distributed product or the like.

The call from the viewer is automatically accepted by the voice response device 20 in the broadcasting center 10. The voice response device 20 has a built-in synthetic voice means (not shown).
Is used to send a message registered in advance by the viewer to enter the request code and prompt the guidance, and is controlled by the host computer 11 to receive the call, send the message, and receive the pulse code. I do.

The request code accepted by the voice response device 20 is judged by the host computer 11 whether the code is valid or not by collating with the database on the external storage device 12, and if it is valid, the host computer 11 It is stored in the internal CPU memory 11b (see FIG. 2). The CPU memory 11b corresponds to "request accumulating means".

When the host computer 11 accepts the request, it creates a message for notifying it as voice information. Then, the voice response device 2
From 0, it responds to the subscriber's telephone set 50 on the viewer side that has made a broadcast request via the public telephone line 40.

The accumulated request code is passed to the karaoke reproducing apparatus 14 controlled by the host computer 11 to reproduce the video. Note that the karaoke reproduction device 14 of the present embodiment can reproduce the karaoke performance sound and also the background image in which the lyrics telop is synthesized. Therefore, the broadcasting means 16 is a television broadcasting means. It should be noted that the karaoke reproducing apparatus 14 is not necessary because there is no need to have an image considering the gist of the invention.
Shall reproduce only the karaoke performance sound, and the broadcasting means 1
6 may be a so-called radio broadcasting means. Of course, when applied to other than karaoke, conversely, it may be considered that only the image is displayed.

The broadcast content broadcast by the broadcasting means 16 is received by a receiving facility such as a television receiver on the viewer side and can be viewed as a karaoke program. In addition,
The broadcasting center 10 and the receiving equipment on the viewer side may be connected by wire like a CATV system, or may be wireless like a normal broadcasting system.

The display device 13 is connected to the host computer 11 and can display these situations. This is used for confirmation by the operator of the broadcast center 10. Subsequently, a signal flow centering on the host computer 11 will be described with reference to FIG.

As shown in FIG. 2, the voice response device 20 is connected to the CPU 11a of the host computer 11 by a control signal. The CPU 11a controls the voice response device 20 with respect to waiting for an incoming call on the public telephone line 40 (see FIG. 1) and control with respect to the transmission of a voice message in the device 20 after receiving a call (selection from a plurality of messages). . The voice response device 20 returns the dial pulse received through the public telephone line 40 to the host computer 11 as numerical information. As a result, the request from the viewer through the public telephone line 40 is automatically accepted. The numerical value returned from the voice response device 20 is stored in the CPU memory 11b.

The external storage device 12 is an external storage of the host computer 11 in which a database relating to request codes or a billing record table is stored, and data is read and written between the devices. Thereby, the CPU 1
Reference numeral 1a is for performing search / verification of request code and log recording.

The karaoke reproducing device 14 is connected to the CPU 11a by a control signal. The CPU 11a can transmit a request code (song number), cause the device 14 to reproduce a karaoke piece, and control the start / end of the reproduction. In addition, the karaoke playback device 14
The status of reproduction (reproduction in progress, reproduction end, etc.) is returned to the CPU 11a. Thereby, the CPU 11a can reproduce the karaoke piece by the request code.

Next, the operation of the broadcasting center 10 of this embodiment will be described with reference to the drawings. 10 to 15 are C
It is a flowchart which shows the process sequence of the program performed by PU11a, and FIGS. 3-9 is a data structure figure which this program handles.

The details of the processing flow will be described below. 10 to 12 are flowcharts of request automatic acceptance / registration processing, and FIG. 13 is a flowchart of request reproduction processing. These processings are so-called multitask processings that operate independently at the same time. In addition, FIG. 14 is a flowchart of the billing aggregation process executed at a predetermined timing (monthly, daily, etc.).
5 is a flowchart of the charge amount calculation process executed during the charge totaling process.

First, the request automatic acceptance / registration processing (FIGS. 10 to 12) will be described. This process shows an automatic acceptance of a request from the subscriber side through the public telephone line 40 and a registration procedure of the request in the CPU memory 11b. In addition, this subscriber simply means this broadcasting center 10
It does not mean that you can receive broadcasts from, but that you have the right to request. For example, in a CATV system, all are subscribers if they are automatically entitled to the request when they join the system. In the case of broadcasting in a normal wireless format, for example, it is conceivable to separately contract to collect a predetermined fee instead of making a request. In that case, only the person who made the contract becomes the subscriber.

First, in the first step S100 of FIG. 10, the voice response device 20 is controlled so as to be able to receive an incoming call through the public telephone line 40, and in a succeeding step S110, an incoming call is received from the subscriber telephone set 50. Wait until. And
If there is an incoming call (S110: YES), the process proceeds to S120.

In S120, a voice response message (for example, "please enter the subscriber number") is sent from the voice response device 20 to prompt the user to enter the subscriber number to be visited first. Then, in S130, the transmission of a dial pulse from the subscriber telephone 50 is awaited. The entered number is S
At 140, the data is stored in the subscriber code area C3 of the request reception buffer (see FIG. 5) on the CPU memory 11b. This is repeated until all the 5-digit subscriber numbers are input (S150).

When a 5-digit subscriber number is entered (S15
(0: YES), the process proceeds to S160, and it is verified whether or not the subscriber number is valid. This is done by referring to the subscriber database (FIG. 7) on the external storage device 12. As a result of this comparison, if it is determined that the number is not valid (S170: NO), a voice message (for example, "Please re-enter subscriber number") requesting re-input is reproduced (S180), and the process proceeds to S130. Return.

If the first entered subscriber number is valid, or if the second entered subscriber number is valid (S170: YES), the process proceeds to S190 (see FIG. 11). In S190, a voice response message is sent,
Prompt for request code. Continued S200-220
Then, the transmission of the dial pulse is waited, the input number is stored in the request code area C2 of the request reception buffer (FIG. 5), and this is repeated until all the five-digit request codes are input.

When a 5-digit request code is input (S220: YES), the request code is collated. This is executed by querying the request database (FIG. 3) on the external storage device 12. And S24
A value of 0 determines whether the number is valid. If it is determined that the number is not a valid number (S240: NO), the process proceeds to S250, a voice message (for example, “Please re-enter request code”) requesting re-input is played, and the process returns to S200.

If the request code input first is valid, or if the request code input again is valid (S240: YES), the process proceeds to S260. In S260, it is determined whether or not the same request code is included in the request code areas B2 of the request execution table (FIG. 4) on the CPU memory 11b, in which the reproduction flag B1 is "unknown". . Here, the request execution table will be described. As shown in FIG. 4, this request execution table is made up of three items including a reproduction flag B1, a request code B2, and a scheduled performance start time B3.

In the process of S310 (see FIG. 12) described later, when it is determined that new registration is to be made,
In S330, the contents of the request reception buffer (FIG. 5) are additionally registered in the request code area B2 indicated by the reception pointer B5 in the request execution table (FIG. 4). This additional registration is performed by copying the request code C2 to the request code area B2 indicated by the reception pointer B5 and setting the reproduction flag B1 to "not yet". In the initial state, the reproduction flag B1 is set to "none", and the request code B2 is set to an undefined value. As for the scheduled performance start time B3, when the previous request code B2 is registered, the playback time of the song is added to determine the scheduled performance start time B3 for the next newly registered performance. When the new registration is completed, the reception pointer B5 is advanced to the next area on the request execution table (FIG. 4). Therefore, in the column of the scheduled performance start time B3 of the area, the above-mentioned "performance when newly registered" is performed. The scheduled start time ”will be written.

Returning to FIG. 11, in S260, the request code area B2 of this request execution table (FIG. 4).
It is determined whether or not there is the same request code among those whose reproduction flag B1 is "not yet". If it is already registered (S260:
(YES), the process proceeds to S270, and the registered scheduled performance start time is taken out. For example, if the newly accepted request code is “01301”, the same one has already been registered, so this is a “duplicate request” and the performance start plan corresponding to the registered request code is scheduled. The time "12:30" will be taken out.

On the other hand, if not registered (S260:
No), the process proceeds to S280 to retrieve the scheduled performance start time in the case of new registration. This is for the area indicated by the reception pointer B5, and in the case shown in FIG.
9 minutes ". When the registered scheduled performance start time is extracted in S270, the voice response message for the duplicate request is transmitted in S290.
This is a voice response message for notifying the viewer of the registered scheduled performance start time together with the fact that it is a duplicate request. For example, "The same request has already been accepted and it is a duplicate request.
Will be broadcast as XXth song from now on around ◇◇ hour □□ minutes. It is a content such as ".

On the other hand, when the scheduled performance start time in the case of new registration is extracted in S280, a voice response message for new request is sent in S295. This is a voice response message for notifying the viewer of the scheduled performance start time in the case of the above new registration together with the fact that the acceptance of the request has been completed. For example, “You have received your request.
From now on, it will be broadcast as the XXth song at about ◇◇ hour □□ minutes. It is a content such as ".

As a result, the requesting viewer first knows whether the request is a new request or a duplicate request, and in any case, it is immediately the same as the song requested by him or the requested one. Know the broadcast time (start time) of the song.

After the processing of S290 or S295, S
Move to 300 and disconnect the line. When the line disconnection process in S300 ends, S310 (see FIG. 12)
Move to In S310, it is determined whether to newly register. Whether to newly register or not in S310 is determined by the above-described judgment in S260, if it is already registered, it is determined that new registration is not performed, and if it is not registered, it is determined that new registration is performed. To do.

In the case of new registration, the processing from S320 is executed. That is, in S320, the received date and time is written in the area C1 of the reception time of the request reception buffer (FIG. 5) as a time stamp. When the processing up to this point is completed, the request reception buffer shown in FIG. 5 has three elements: reception time C1, valid request code C2, and valid subscriber code C3, and the actual request can be received. Therefore, in subsequent S330, the contents of the request reception buffer (FIG. 5) are newly registered in the request code area B2 indicated by the reception pointer B5 in the request execution table (FIG. 4). In this new registration, the request reception buffer (FIG. 5) shows the request code C2 and the request code area B2 indicated by the reception pointer.
It has been described above that the reproduction flag B1 is set to "not yet" by copying to the.

After the completion of the new registration processing in S330, S3
Move to 40. In S340, the reception pointer B5 is advanced to the next area on the request execution table (FIG. 4).
This operation is reflected in the operation of the request reproduction process (FIG. 13) described later. Further, in the subsequent S350, in order to retain the received request as a log record, in the request log file (FIG. 6) of the external storage device 12, the reception time area D1, the request code area D2, the subscriber code area D3 (this D1 D3 has the same elements as the request reception buffer in FIG. 5). Further, in this case, since it is a new request, "1" is set in the overlapping number area D4. The duplicate number will be described in detail later.

Next, in S360, the value of the number of requests waiting to be played is incremented, and in S370, the reproduction time which is an element of the request database (FIG. 3) retrieved based on the request code C2 of the request reception buffer (FIG. 5). The value of A3 is added to the latest scheduled performance start time in the request execution table of FIG. 4 (written in the previous area indicated by the reception pointer B5). As a result, the scheduled performance start time for the next request is calculated, and this time is written in the scheduled performance start time area B3 indicated by the reception pointer B5.

After this, the incoming call waiting state (S1
00), and the subsequent processing is repeated. On the other hand, if new registration is not performed (S310: NO), the process of S380 is executed and then the process returns to S100. In S380, in order to hold the received request as a log record, as in S350 described above, the reception time area D1, the request code area D2, and the subscriber code area D in the request log file (FIG. 6) of the external storage device 12 are stored.
Copy each element to 3. Since this is a duplicate request in this case, a predetermined value is set in the duplicate number area D4 unlike S350. This predetermined value is a value obtained by adding 1 to the duplicate number of the same request code immediately before. That is, since it is determined in S260 that the request is a duplicate request, among the already stored identical request codes that have been determined to be the duplicate request, the duplicate number of the one stored immediately before is 1 Will be added. Therefore, "2"
This is the above value.

Here, the duplicate number will be supplementarily described. This indicates the number of duplicates, and if it is a new request that does not duplicate, it is set with the duplicate number "1" in S350. That is, this request is the first request in the request execution table. On the other hand, in the case of a duplicate request, since the same song has already been requested in the request execution table, for example, “2” is set for the second song and “3” is set for the third song. Note that this duplicate number only means that the same song exists in the requested songs for which the performance has not started yet in the request execution table, and is requested after the same song has already been played. The new request will be set with the duplicate number "1".

For example, in FIG. 6, the request code “01301” of the file shown in FIG. 6 is the same as the request code “01301” of the file shown in
The duplicate number is "1" in the file indicated by, but the duplicate number is "2" in the file indicated by. this is,
It indicates that the request indicated by is made before the music of the request code “01301” of the file indicated by is played. On the other hand, the request code “01301” of the file shown by is the same as the request code of the file shown by and, but the duplicate number is “1”. This means that when the request indicated by is made, there is no request having the request code of "01301" in the request execution table (FIG. 4) waiting for performance. That is, since the request indicated by the above is already broadcast, a negative determination is made in S260 of FIG. 11, and the request is registered as a new request.

Since a request from a viewer is made regardless of whether it is a new request or a duplicate request, the duplicate number is stored in order to keep a log of the request itself. If the value is other than "1", it is recorded in the request log file (Fig. 6).
However, in the billing aggregation process (FIG. 14) to be described later, it is inconvenient if the aggregation is performed based on only the fact that the request is made without distinction between the case of a new request and the case of a duplicate request. If they overlap, it is necessary to consider the degree of overlap, so the overlap number is provided to distinguish between them.

The inconveniences are as follows, for example. One of the inconveniences is that, for example, if the fee is calculated only based on the request history, the number of karaoke songs actually broadcast and the number of requests subject to fee collection differ, and the broadcasting system The situation may be such that the business operator takes some money for free. In the case of duplicate requested karaoke songs, it may be possible to charge only the first requesting user and not the subsequent duplicate requesting user, but this will depend on the order of the requests. There is a problem that the fees paid are unfair. In other words, extremely speaking, theoretically, some users may be charged as usual for all requests depending on the timing of the request, and conversely, some users may not be charged at all for all requests. There is.

Therefore, in the broadcasting center 10 of the present embodiment, if the duplication number is “2” or more, it is known that the duplication request is made. Therefore, based on this, the number of karaoke songs actually broadcast and the charge collection target are set. Match the number of requests and execute an appropriate billing process so that the center side does not get free. Further, it is possible to appropriately deal with the user's convenience improvement, such as “dividing” according to the degree of duplication of requests. Details of this point will be described later.

Next, the request reproduction process (FIG. 13) will be described. This process shows a procedure of reproducing the request code registered in the request execution table (FIG. 4) on the CPU memory 11b. First, the first step S41
At 0, the reproduction flag B1 is extracted from the area indicated by the reproduction pointer B4 in the request execution table (FIG. 4). If the reproduction flag B1 is not "not yet" (S420: N
O), the request execution table (FIG. 4) is completely reproduced, or the registered content is empty, so the request automatic acceptance / registration processing (FIG. 10)
Waiting for additional registration of the request according to FIG. 12) (S4
30).

On the other hand, if the reproduction flag B1 is "not yet",
The process moves to S440, and the request code B2 is taken out.
Then, in S450, the request code B2 is passed to the karaoke reproducing apparatus 14, and a reproduction instruction is issued. further,
In S460, the reproduction flag B1 is changed to "medium", and the subsequent S
At 470, the reproduction state of the karaoke reproduction device 14 is checked.

This is repeated until the end of reproduction is instructed by the karaoke reproducing device 14 (S480: NO). When the reproduction is completed (S480: YES), S490
In step S500, the reproduction pointer B4 is moved to the next table.

Next, in S510, the value of the number of performance waiting requests is decremented. After this, the process returns to S410 again to repeat the reproduction of the next request. As described above, in FIG. 10 to FIG. 12, automatic request acceptance / registration processing,
The request reproduction process has been described with reference to FIG. 13. Next, the charge aggregation process executed at a predetermined timing, for example, every month (or every day or every week) will be described with reference to FIG.
This will be described with reference to the flowchart of FIG. It should be noted that this process may be executed, for example, at a time when the broadcast center 10 is not executing a broadcast-related process (for example, a time zone such as midnight or early morning).

In the charge accounting processing, first, in step S610, an accounting file is created. As shown in FIG. 8, this tabulation file is a table of subscriber codes and their code numbers (subscriber numbers) corresponding to request codes. It is created in the CPU memory 11b based on the data.

Specifically, the data in the predetermined total range in the request log file of FIG. 6 is taken out one by one and totaled. For example, in FIG.
Request code "0
1301 ”is the subscriber code“ 12345 ”and“ 1234 ”
7 ”, and the number of requested subscribers is stored as“ 2 ”.

Similarly, according to the data shown in FIG. 6, the request code “01826” is requested from one subscriber with the subscriber code “12346”, and the number of requested subscribers is stored as “1”. , The request code “015
"37" is requested by one subscriber with the subscriber code "12348", and the number of requested subscribers is stored as "1".

Then, the request code "01301" is requested by the two subscriber codes "12349" and "12350" by the two data shown in FIG. 6, and the requested number of subscribers is "2". It is remembered that there is. Note that the request code “01301” is the same as the request code shown by in FIG. 6 described above, but the duplicate number of the data shown by is “1”.
Therefore, it is counted as a separate file. That is, since the data in the request log file is referenced in order, if the duplicate number is "2" or more, the duplicate number is "1" even if the same request code is entered in FIG. In the case of “,” a new file is set.

Returning to FIG. 14, the subscriber number counter is cleared in S620, and it is determined in the next S630 whether or not the subscriber number counter is equal to or greater than the number of registered persons in the subscriber database (FIG. 7). If the number of subscribers counter is equal to or greater than the number of subscribers in the subscriber database (S63
If the subscriber number counter is not equal to or greater than the number of subscribers in the subscriber database (S630: NO), the process proceeds to S640.

At S640, the subscriber codes are sequentially acquired in the order of registration in the subscriber database.
In subsequent S650, it is determined whether or not the file currently referred to is the file end of the counting file (FIG. 8), and if it is not the file end (S650: N
O), the process proceeds to S660, and the data for one record is acquired from the tabulation file. The record acquisition in S660 is sequentially acquired in the order of the records stored in the tabulation file.

In subsequent S670, the subscriber code acquired from the subscriber database in S630 and S660.
Compare with the subscriber code in the record obtained in. If the two subscriber codes match, the process proceeds to S680, but if they do not match, the process returns to S650.

In step S680, a billing amount calculation process is executed. This charge amount calculation process will be described with reference to FIG. In the charge amount calculation process shown in FIG. 15, first,
The calculated amount work area for storing the calculated result is initialized (S681), and next, whether the number of subscribers in the record acquired in S660 of FIG. It is determined (S682). If the number of subscribers is one (S682: NO),
A prescribed request charge for one song is set in the calculated amount work (S683). On the other hand, when the number of subscribers is two or more (S682: YES), the amount of money for one prescribed song is divided by the number of subscribers who have made duplicate requests, and the obtained amount is set in the calculated amount work (S684). ). Depending on the number of subscribers, it may not be exactly divisible, but in that case, rounding up processing or the like may be performed.

When the calculated amount of work is set in S683 or S684, this process is terminated and S6 of FIG.
Move to 90. In S690, the calculation amount calculated in S680 is added to update the charge amount work. After this, the process returns to S650.

In this way, when the processes of S660 to S690 are executed for each record of the totalizing file of FIG. 8 and the file end is reached (S650: YE
S) Since the calculation of the charge amount for one person has been completed, the process proceeds to S700, and the content of the charge amount work finally updated in S690 is the corresponding subscriber of the charge result table of FIG. Store as a code file. In addition,
At this time, not only the charge amount, but also the breakdown thereof (how many songs have duplicate requests, or the degree of duplication thereof) may be stored.

Since the storage of the billing record for one person is completed, the process proceeds to the process of totaling and storing the billing record for the next subscriber. Specifically, in the subsequent S710, the value of the subscriber number counter is incremented, and then the process returns to S630. S
If a negative determination is made in 630, the next subscriber code is acquired from the subscriber database (FIG. 7) in S640. Then, the processes from S660 are performed.

When the totalization and storage of the billing records for all the subscriber codes stored in the subscriber database (FIG. 7) are completed in this way, an affirmative judgment is made in S630. To finish. Note that FIG.
The data stored in the billing record table shown in Fig. 2 is sent to, for example, a financial institution and collected by automatic withdrawal, or printed as an invoice, and the charge collection staff on the administrator side goes directly to the user and collects it. It will be.
In this case, if the subscriber's address, telephone number, etc. are also registered in the subscriber database (FIG. 7), that information may be added to the billing record table as subscriber information.

The broadcasting center 10 of this embodiment described above
According to this, the basic functions of request response and storage of record information for billing are provided, and further the following functions are exhibited. That is, when the request from the viewer is a duplicate request, S29 in FIG.
As shown in 0, it responds as a voice response message to the viewer side who has requested the duplicate request. Then, although it is stored in the request log storage (FIG. 6), it is not newly registered in the request execution table (FIG. 4).

As described above, when the received request is a duplicate request, by not newly registering it in the request execution table, it is possible to prevent the karaoke piece corresponding to the request that is less necessary from being broadcast, and Leads to fulfillment. That is, in the case of a duplicate request, a karaoke song corresponding to the request that has already been reserved but has not started broadcasting will be broadcast from now on. Therefore, for the viewer who has made the duplicate request, the karaoke song is broadcast. By doing so, the requirements will be met. Therefore, if duplicate requests are registered in the request execution table (Fig. 4) as they are, the karaoke song is the one I want, but in reality, after the karaoke song requested by another person is broadcast, Since the karaoke song according to the user's request will be broadcast, the need for the viewer who has made the duplicate request becomes very small.

Therefore, by controlling not to broadcast the karaoke piece corresponding to the duplicate request,
While satisfying the viewer's request, it is possible to enhance the broadcast content, such as preventing the broadcasting of karaoke songs, which are less necessary. Especially when the period for accepting a request is limited, a person who truly wants to make a request cannot request it because of a needless request, or the broadcast time of the karaoke song according to the request of the person is not available. The delay will hinder the enrichment of broadcast contents and the convenience of users. Therefore, not broadcasting such a karaoke song that is less necessary leads to enhancement of broadcast contents and improvement of user convenience.

Further, as can be seen from the processing shown in FIG. 11, when the received request is a duplicate request, when the received request is stored in the request log file (FIG. 6), the duplicate number is set according to the degree of duplication. I remember. Therefore, in the charge amount calculation process of FIG.
If the duplicate number is 2 or more in 682, it is set to 1 in S684.
All the duplicate subscribers will share the cost of the song and pay.

As a result, it becomes possible to appropriately deal with the charge collection. For example, if the fee is simply calculated based on the number of request logs stored in the request log file (Fig. 6), the number of karaoke songs actually broadcast and the number of requests subject to fee collection differ. As a result, the broadcasting system business side will get some free money. Therefore, according to the present embodiment, the number of karaoke songs actually broadcast matches the number of requests for which fee collection is made, which is preferable in terms of fair and sound system operation.

It is also conceivable to charge only the user who first makes a request and not charge the user who makes a duplicate request thereafter.
The fees paid become unfair depending on the order of broadcast requests. In other words, extremely speaking, theoretically, some users will be charged as usual for all broadcast requests depending on the timing of broadcast request, and conversely, some users will not be charged for all broadcast requests at all. there's a possibility that.

Also in this respect, the broadcasting center 10 of the present embodiment.
Then, if it is used substantially by a plurality, it is possible to realize an appropriate charge burden of, for example, "paying split" according to the number of users, which is preferable in terms of fair and sound system operation. It should be noted that the viewer who has made the duplicate request is replied as a voice response message indicating that the duplicate request has been made. Therefore, the viewer can recognize that the requests are duplicate requests. If it is notified in advance that the charge will be different from the normal request in the case of a duplicate request (for example, it will be free), a voice response message stating that the requests are duplicated I can recognize that.

The request log file in FIG. 6 also stores duplicate requests as logs. This is because it is preferable that the broadcast center 10 keeps a record of the requests themselves made for various reasons such as creating a request ranking based on the number of requests.

Further, in this embodiment, when a request is made, whether the request is a duplicate request or not, the scheduled broadcast start time of the karaoke piece corresponding to the request is viewed as a voice response message. Person is notified. Therefore, the viewer can know in real time when the broadcast of the karaoke song requested by him / her is started. Therefore, you can do other things, for example, before the start of the karaoke song you requested, and you can eliminate the wasteful time of just waiting because you do not know when it will start. The convenience of use can be improved.

Although the embodiments of the present invention have been described according to the specific examples, the present invention is not limited to the specific examples and various modifications can be made without departing from the gist of the invention. Needless to say. For example, in the above-described embodiment, an example in which the karaoke program is used for broadcasting has been described. However, in the present invention, the number of servers that supply broadcasting information is small, and the number of clients that request broadcasting information is large, and both are remote. For some reason, the purpose of the application is to adopt the information supply form called broadcasting.
Therefore, it may be considered that only the audio information or the video information is used as the broadcast information.

[Brief description of drawings]

FIG. 1 is a block diagram showing a schematic configuration of a broadcasting center according to an embodiment.

FIG. 2 is an explanatory diagram showing a signal flow centered on a host computer.

FIG. 3 is a data structure diagram of a request database handled by a host computer.

FIG. 4 is a data structure diagram of a request execution table handled by a host computer.

FIG. 5 is a data structure diagram of a request reception buffer handled by a host computer.

FIG. 6 is a data structure diagram of a request log file handled by the host computer.

FIG. 7 is a data structure diagram of a subscriber database handled by a host computer.

FIG. 8 is a data structure diagram of a counting file handled by a host computer.

FIG. 9 is a data structure diagram of a billing record table handled by the host computer.

FIG. 10 is a flowchart showing a part of request automatic acceptance / registration processing executed by the host computer.

FIG. 11 is a flowchart showing a part of a request automatic acceptance / registration process executed by a host computer.

FIG. 12 is a flowchart showing a part of a request automatic acceptance / registration process executed by a host computer.

FIG. 13 is a flowchart showing a request reproduction process executed by a host computer.

FIG. 14 is a flowchart showing a charge tabulation process executed by a host computer.

FIG. 15 is a flowchart showing a charge amount calculation process executed during the charge aggregation process.

[Explanation of symbols]

10 ... Broadcasting center 11 ... Host computer 11a ... CPU 11b ... CPU memory 12 ... External storage device 13 ... Display device 14 ... Karaoke reproducing device 16 ... Broadcasting means 20 ... Voice response device 40 ... Public telephone line 50 ... Subscriber telephone

Claims (4)

[Claims] 1. A request receiving means for receiving a broadcast request individually made by a viewer using a communication line and automatically accumulating it as data in a request accumulating means, and a broadcast stored in the request accumulating means. Broadcasting means for sequentially broadcasting the broadcasting information according to the request in a predetermined order, and record information for charging a predetermined fee corresponding to the broadcast request stored in the request storing means by the request receiving means. In a broadcasting center with a request response function that includes a billing record information storage unit that stores the broadcast request for each viewer, the broadcast request received by the request reception unit has already been stored in the request storage unit. However, if the broadcasting of the broadcasting information according to the broadcasting request by the broadcasting means is the same as the broadcasting request that has not been started yet, The reception means is configured not to execute the storage in the request storage means, and the broadcast request received by the request reception means,
Not only in the case of the duplicate broadcast request, but also in the case of not performing the accumulation in the request accumulating means because of the duplicate broadcast request, at least the viewer identification number for each target broadcast information is obtained as the request reception record. Based on the requested reception record storage means to be stored and the number of viewer identification information corresponding to the broadcast information in the request reception record storage means at the time of broadcasting of the broadcast information, one of Broadcasting, characterized in that the past record information storage unit stores the past record information set so as to bear the charge for the broadcast information to all corresponding viewers. center. 2. When the broadcast request received by the request receiving unit is the duplicate broadcast request, the communication that the broadcast request is duplicated is transmitted to the viewer side who has transmitted the broadcast request. The broadcasting center according to claim 1, further comprising a response unit that responds as voice information via a line. 3. The broadcast information according to the response means, in addition to the fact that the broadcast requests are duplicated, of the broadcast requests that have already been stored and have not been started yet. The broadcast center according to claim 1 or 2, wherein the broadcast center is also configured to respond to the information about the broadcast start schedule. 4. The broadcast request from the viewer is a request specifying a karaoke piece, and the broadcasting means is a television broadcasting means capable of transmitting audio information and video information, and the broadcasting means broadcasts the information. 4. The broadcasting center according to claim 1, wherein the broadcasting information includes a karaoke performance sound corresponding to the requested karaoke piece and an image in which a lyrics telop is combined with a background image.