JP4653564B2 - リクエスト番組制作放送システム，サーバ，方法，プログラム - Google Patents

Description

本発明は、ユーザからの楽曲リクエストを受けてリクエスト番組を制作放送するシステムに関する。

以前より、ラジオなどでリスナーの楽曲リクエストを受け付けて放送するというリクエスト番組が知られている。このようなリクエスト番組を制作するには、まず電話やＦＡＸを用いてリスナーからの楽曲リクエストを募り、それを手作業で集計して放送する楽曲を決め、さらに放送する楽曲のＣＤやテープなどを探し出して実際に放送する、という手法が一般的である。

これに対し、例えば特許文献１では、リスナーであるユーザがＷｅｂサーバを通じて提示されたリクエスト可能な楽曲を選定してリクエストし、管理サーバは集計をして、その結果を元にリクエスト番組の放送を行うシステムが開示されている。
特許３６１５７５０号

しかしながら、このようなシステムではリクエスト可能な楽曲が限られているため、リスナーであるユーザは、好みの楽曲をリクエストできないことがほとんどである。また、たとえ好みの楽曲をリクエストできたとしても、投票方式を採用しているため、リクエストした楽曲が放送されるとは限られず、さらにリクエストした楽曲がいつ放送されるのかも知ることができないので、リスナーであるユーザの期待感を損ねる結果と成り得る。

ところで、このような問題とは別に、Ｗｅｂサーバを通じて着信メロディーのようなデータやＣＤのような物品である商品をユーザに販売するサービスが従来行われている。ユーザが購入するこれらの商品は、当然にユーザの好みを反映させているものであり、よって購入した商品に対応する楽曲、すなわち着信メロディーの基となった楽曲やＣＤに収録されている楽曲等もユーザの好みの楽曲であるといえる。

そこで、本発明ではこれらの問題を解決するべく、購入した商品に対応する楽曲をリクエストでき、さらにはリクエストした楽曲が放送される時間を知ることも可能とするリクエスト番組制作放送システムを提供することを目的とする。

かかる課題を解決するべく、請求項１の発明にかかるリクエスト番組制作放送システムは、ユーザによって操作され楽曲のリクエストを行う通信端末と、ネットワークを介して通信端末と相互に通信し、通信端末より楽曲のリクエストを受け付けてリクエスト番組を制作放送するサーバとから成り、通信端末は固有の端末ＩＤを有しており、サーバは前記固有の端末ＩＤを基に個々の通信端末を識別可能であって、サーバは、楽曲との１対１の関係性を有する商品と楽曲との対応を記憶している楽曲マスタデータベースと、個々の通信端末ごとに購入した商品の履歴を記録する商品購入履歴データベースと、を備え、通信端末による商品購入が実施されて前記商品購入履歴データベースに新たに購入した商品の履歴が追加されると、前記楽曲マスタデータベースを参照し、通信端末が購入した商品に対応する楽曲を通信端末ごとに固有の楽曲リストに追加する楽曲リスト生成手段、通信端末による楽曲リクエスト要求を受け付けると、前記楽曲リスト生成手段により生成された楽曲リストを通信端末に送信し、通信端末より楽曲リストから選択された楽曲を受信すると、この受信した選択楽曲をリクエスト楽曲として受け付けるリクエスト受付手段、番組で放送する楽曲名と、その楽曲が実際に放送される時間との関係を示す番組スケジュールを記憶しており、前記リクエスト受付手段によりリクエスト楽曲を受け付けると、当該リクエスト楽曲を番組スケジュールに組み込み可能な時間を判断して組み込み番組スケジュールを生成する番組スケジュール生成手段、前記番組スケジュール生成手段により生成された番組スケジュールに沿って番組を放送する番組放送手段、を備えることを特徴とする。
また、請求項１に記載の発明は請求項２に記載したように、前記楽曲マスタデータベースは、さらに楽曲との１対１の関係性を有さない商品と楽曲との対応を、楽曲に付された固有の管理ＩＤを当該商品と結びつけることにより記憶していることを特徴としても良い。

請求項１又は請求項２の発明にかかるリクエスト番組制作放送システムによれば、まずユーザが使用する通信端末により商品購入が実施される。商品購入を可能とする機能は、本発明にかかるシステムのサーバが提供しても良いし、別のサーバによって提供されていても良いが、いずれにしても公知の電子商取引システムにより行われる。また、ここで商品とは、ＣＤやアーティストグッズのような現実の物品であってもよいし、アーティストの画像や着信メロディーのような再生可能なデータであってもよい。

次に、サーバは楽曲マスタデータベースを参照し、ユーザが購入した商品に対応する楽曲を探索し、特定した楽曲をユーザごとに固有の楽曲リストに追加する。ここでユーザが購入した商品に対応する楽曲とは、例えば商品がＣＤであるならば当該ＣＤに収録されている楽曲、画像ならば当該画像に写っているアーティストの楽曲、着信メロディーならば当該着信メロディーとなっている楽曲、などである。また、１つの商品に対し１つの楽曲が楽曲リストに追加されることとしてもよいし、複数の楽曲が楽曲リストに追加されることとしてもよい。

次に、サーバはユーザからの楽曲リクエスト要求を受け付けると、前記楽曲リストをユーザに提示し、楽曲リストの中からのリクエスト楽曲の選択を受け付ける。ここでユーザによる楽曲リクエスト要求およびリクエスト楽曲の選択は、例えばユーザに携帯電話機などの通信端末を用いてサーバにアクセスさせることにより受け付けても良いし、楽曲リストの提示もユーザが用いる通信端末を通じて行っても良い。また、楽曲リストからリクエスト楽曲を選択できるのは１曲のみとしてもよいし、複数曲を選択可能としてもよい。

次に、サーバは受け付けたリクエスト楽曲を番組スケジュール構築手段が記憶する番組スケジュールに組み込み、番組放送手段が当該番組スケジュールを基に番組を放送する。ここで、番組の放送は番組スケジュールの楽曲名および放送される時間の情報に基づいて自動で行われてもよい。また番組の放送は、インターネットを利用したストリーミング放送であってもよいし、ラジオ放送やテレビ放送であってもよい。また、放送を受信する端末は携帯電話機やパーソナルコンピュータであってもよいし、ラジオ受信機やテレビ受信機であってもよい。

さらに請求項１又は２に記載の発明にかかるリクエスト番組制作放送システムは、請求項３に記載したように、サーバが、前記楽曲マスタデータベースにさらに楽曲の再生時間情報を記憶しており、前記リクエスト受付手段がリクエスト楽曲を受け付けると、楽曲マスタデータベースに記憶された楽曲の再生時間情報と、前記番組スケジュール生成手段に記憶された番組スケジュールとを参照し、当該リクエスト楽曲を番組スケジュールに組み込んで放送可能な日時を探索して、その結果を通信端末に送信する放送日時候補通知手段、をさらに有し、前記番組スケジュール生成手段は、通信端末より、前記放送日時候補通知手段によって送信された放送可能な日時の中から放送希望日時の選択を受け付けると、受け付けた放送希望日時に当該リクエスト楽曲を組み込んだ番組スケジュールを生成しても良い。

ここで、放送可能な日時の候補の提示は、全ての放送可能な日時を提示しても良いし、推奨される放送日時候補をサーバが選んで提示しても良い。また、ユーザが選択した日や時間帯についてのみ放送可能な日時を提示しても良い。

さらに請求項１乃至３の何れかに記載の発明にかかるリクエスト番組制作放送システムは、請求項４に記載したように、サーバが、前記番組スケジュール生成手段がリクエスト楽曲を組み込んだ番組スケジュールを生成すると、当該リクエスト楽曲をリクエストした通信端末に対し、楽曲が放送される日時を通知する放送時間通知手段、をさらに有していても良い。
ここで放送時間の通知は、たとえば電子メールなどで行っても良いし、ユーザがサーバにアクセスした際に通知する、などとしても良い。

請求項１乃至４の何れかに記載の発明にかかるリクエスト番組制作放送システムは、請求項５に記載したように、前記リクエスト受付手段で受け付ける楽曲リクエストには優先度が異なる複数のリクエストが存在し、前記番組スケジュール生成手段は、さらに、既に優先度が相対的に下位のリクエストに基づくリクエスト楽曲が組み込まれている時間であっても、優先度が相対的に上位のリクエストに基づくリクエスト楽曲を優先的に組み込んで番組スケジュールを生成するというリクエストの上書きを行っても良い。
ここで優先度が相対的に下位のリクエストと上位のリクエストとの関係は、例えば無料で行えるリクエストと所定の金額を支払うことによって行える有料のリクエストのようなものであってもよいし、非会員でも行えるリクエストと会員のみが行えるリクエストのようなものであってもよい。

さらに請求項１乃至５の何れかに記載の発明にかかるリクエスト番組制作放送システムは、請求項６に記載したように、サーバは、前記番組スケジュール生成手段が前記リクエストの上書きを行ったと判断すると、優先度が相対的に下位のリクエストを行った通信端末に対して通知を行い、再リクエストもしくはリクエストの取り消しを受け付ける手段、をさらに有していても良い。

ここで、上書きされた下位のリクエストを行ったユーザに対して通知は、例えば電子メールなどで行っても良いし、ユーザがサーバにアクセスした際に通知する、などとしても良い。また、前記再リクエストは、再度下位のリクエストによって行われてもよいし、上書きがされないよう上位のリクエストによって行うことを可能としても良い。

また本発明は、本発明にかかるリクエスト番組制作放送システムの各々の構成に対応して、サーバにより実行されるリクエスト番組制作放送方法として把握することもできる。 すなわち、請求項７の発明にかかるリクエスト番組制作放送方法は、商品と楽曲との関係を記憶している楽曲マスタデータベースと、個々の通信端末ごとに購入した商品の履歴を記録する商品購入履歴データベースと、を備えるサーバがユーザによって操作され楽曲のリクエストを行う通信端末とネットワークを介して相互に通信し、通信端末より楽曲のリクエストを受け付けてリクエスト番組を制作放送する方法であって、サーバは、商品と楽曲との関係を記憶している楽曲マスタデータベースと、個々の通信端末ごとに購入した商品の履歴を記録する商品購入履歴データベースと、を備え、通信端末による商品購入が実施されて前記商品購入履歴データベースに新たに購入した商品の履歴が追加されると、前記楽曲マスタデータベースを参照し、通信端末が購入した商品に対応する楽曲を通信端末ごとに固有の楽曲リストに追加する楽曲リスト生成ステップ、通信端末による楽曲リクエスト要求を受け付けると、前記楽曲リスト生成ステップにおいて生成された楽曲リストを通信端末に送信し、通信端末より楽曲リストから選択された楽曲を受信すると、この受信した選択楽曲をリクエスト楽曲として受け付けるリクエスト受付ステップ、番組で放送する楽曲名と、その楽曲が実際に放送される時間との関係を示す番組スケジュールを記憶しており、前記リクエスト受付ステップにおいてリクエスト楽曲を受け付けると、当該リクエスト楽曲を組み込んだ番組スケジュールを生成する番組スケジュール生成ステップ、前記番組スケジュール生成ステップにおいて生成された番組スケジュールに沿って番組を放送する番組放送ステップ、を備えることを特徴とする。

さらに、請求項７記載の発明にかかるリクエスト番組制作放送方法は、請求項８に記載したように、前記楽曲マスタデータベースにさらに楽曲の再生時間情報を記憶しており、前記リクエスト受付ステップにおいてリクエスト楽曲を受け付けると、楽曲マスタデータベースに記憶された楽曲の再生時間情報と、前記番組スケジュール生成において記憶された番組スケジュールとを参照し、当該リクエスト楽曲を番組スケジュールに組み込んで放送可能な日時を探索して、その結果を通信端末に送信する放送日時候補通知ステップ、をさらに有し、前記番組スケジュール生成ステップにおいては、通信端末より、前記放送日時候補通知ステップにおいて送信された放送可能な日時の中から放送希望日時の選択を受け付けると、受け付けた放送希望日時に当該リクエスト楽曲を組み込んだ番組スケジュールを生成しても良い。

さらに、請求項７又は８に記載の発明にかかるリクエスト番組制作放送方法は、請求項９に記載したように、前記番組スケジュール生成ステップにおいてリクエスト楽曲を組み込んだ番組スケジュールを生成すると、当該リクエスト楽曲をリクエストした通信端末に対し、楽曲が放送される日時を通知する放送時間通知ステップ、をさらに有していても良い。

さらに、請求項７乃至９の何れかに記載の発明にかかるリクエスト番組制作放送方法は、請求項１０に記載したように、前記リクエスト受付ステップにおいて受け付ける楽曲リクエストには優先度が異なる複数のリクエストが存在し、前記番組スケジュール生成においては、さらに、既に優先度が相対的に下位のリクエストに基づくリクエスト楽曲が組み込まれている時間であっても、優先度が相対的に上位のリクエストに基づくリクエスト楽曲を優先的に組み込んで番組スケジュールを生成するというリクエストの上書きを行っても良い。

さらに、請求項７乃至１０の何れかに記載の発明にかかるリクエスト番組制作放送方法は、請求項１１に記載したように、前記番組スケジュール生成ステップにおいて前記リクエストの上書きを行ったと判断すると、優先度が相対的に下位のリクエストを行った通信端末に対して通知を行い、再リクエストもしくはリクエストの取り消しを受け付けるステップをさらに有していても良い。

また本発明は、本発明にかかるリクエスト番組制作放送システムの各々の構成に対応して、サーバにより実行されるリクエスト番組制作放送プログラムとして把握することもできる。

すなわち、請求項１２の発明にかかるリクエスト番組制作放送プログラムは、商品と楽曲との関係を記憶している楽曲マスタデータベースと、個々の通信端末ごとに購入した商品の履歴を記録する商品購入履歴データベースと、を備えるサーバがユーザによって操作され楽曲のリクエストを行う通信端末とネットワークを介して相互に通信し、通信端末より楽曲のリクエストを受け付けてリクエスト番組を制作放送する方法であって、サーバは、商品と楽曲との関係を記憶している楽曲マスタデータベースと、個々の通信端末ごとに購入した商品の履歴を記録する商品購入履歴データベースと、を備え、通信端末による商品購入が実施されて前記商品購入履歴データベースに新たに購入した商品の履歴が追加されると、前記楽曲マスタデータベースを参照し、通信端末が購入した商品に対応する楽曲を通信端末ごとに固有の楽曲リストに追加する楽曲リスト生成ステップ、通信端末による楽曲リクエスト要求を受け付けると、前記楽曲リスト生成ステップにおいて生成された楽曲リストを通信端末に送信し、通信端末より楽曲リストから選択された楽曲を受信すると、この受信した選択楽曲をリクエスト楽曲として受け付けるリクエスト受付ステップ、番組で放送する楽曲名と、その楽曲が実際に放送される時間との関係を示す番組スケジュールを記憶しており、前記リクエスト受付ステップにおいてリクエスト楽曲を受け付けると、当該リクエスト楽曲を組み込んだ番組スケジュールを生成する番組スケジュール生成ステップ、前記番組スケジュール生成ステップにおいて生成された番組スケジュールに沿って番組を放送する番組放送ステップ、をコンピュータに実行させることを特徴とする。

また、請求項１２に記載の発明にかかるリクエスト番組制作放送プログラムは、請求項１３に記載したように、前記楽曲マスタデータベースにさらに楽曲の再生時間情報を記憶しており、前記リクエスト受付ステップにおいてリクエスト楽曲を受け付けると、楽曲マスタデータベースに記憶された楽曲の再生時間情報と、前記番組スケジュール生成において記憶された番組スケジュールとを参照し、当該リクエスト楽曲を番組スケジュールに組み込んで放送可能な日時を探索して、その結果を通信端末に送信する放送日時候補通知ステップ、をさらにコンピュータに実行させ、前記番組スケジュール生成ステップにおいては、通信端末より、前記放送日時候補通知ステップにおいて送信された放送可能な日時の中から放送希望日時の選択を受け付けると、受け付けた放送希望日時に当該リクエスト楽曲を組み込んだ番組スケジュールを生成しても良い。

また、請求項１２又は１３に記載の発明にかかるリクエスト番組制作放送プログラムは、請求項１４に記載したように、前記番組スケジュール生成ステップにおいてリクエスト楽曲を組み込んだ番組スケジュールを生成すると、当該リクエスト楽曲をリクエストした通信端末に対し、楽曲が放送される日時を通知する放送時間通知ステップ、をさらにコンピュータに実行させても良い。

また、請求項１２乃至１４の何れかに記載の発明にかかるリクエスト番組制作放送プログラムは、請求項１５に記載したように、前記リクエスト受付ステップにおいて受け付ける楽曲リクエストには優先度が異なる複数のリクエストが存在し、前記番組スケジュール生成においては、さらに、既に優先度が相対的に下位のリクエストに基づくリクエスト楽曲が組み込まれている時間であっても、優先度が相対的に上位のリクエストに基づくリクエスト楽曲を優先的に組み込んで番組スケジュールを生成するというリクエストの上書きを行っても良い。

また、請求項１２乃至１５の何れかに記載の発明にかかるリクエスト番組制作放送プログラムは、請求項１６に記載したように、前記番組スケジュール生成ステップにおいて前記リクエストの上書きを行ったと判断すると、優先度が相対的に下位のリクエストを行った通信端末に対して通知を行い、再リクエストもしくはリクエストの取り消しを受け付けるステップをさらにコンピュータに実行させても良い。

本発明によれば、ユーザは購入した商品に対応する楽曲をリクエストすることが可能となる。購入した商品はユーザの好みを示すものであるので、ユーザは自分好みの楽曲をリクエストすることが可能になるという効果を奏する。
また本発明によれば、リクエスト楽曲がいつ放送されるのかリクエストをしたユーザに通知されるので、リスナーであるユーザは放送されるリクエスト楽曲を確実に聴くことができ、期待感を損ねることがない、という効果を奏する。

以下、本発明を実施するための最良の形態について、図面を参照して詳細に説明する。図面の説明において同一の要素には同一の符号を付し、重複する説明を省略する。
なお、実施形態は第一の実施形態と第二の実施形態の二種類を説明するが、両者ともに使用するシステムは同一であるので、まずはシステムの構成について説明する。

まず、システム全体の構成について説明する。図１は、本実施形態におけるシステム全体の概略構成を示す図である。このシステムは、携帯電話機１とサーバ２が、携帯電話網３およびインターネット４を介して接続可能に構成されている。携帯電話網３はインターネット４に接続されたゲートウェイサーバ５、パケット交換処理を行うパケット網６、基地局７を備え、携帯電話機１とインターネット４との接続を可能とする。携帯電話機１は、ＨＴＴＰ(Hyper Text Transfer Protocol)によりＷＷＷ（World Wide Web, 以下Ｗｅｂと省略する）閲覧を可能にするＷｅｂブラウザやメールの送受信を行うメーラを標準装備しており、更にアプリケーションプログラムをダウンロードして記憶し実行することも可能である。なお、携帯電話機１の内部構成については後に図２を用いて説明する。

サーバ２は、商品購入サイトの運営およびリクエスト番組の制作放送を行う。サーバ２には曲マスタデータベース（以下データベースをＤＢと省略する）８、マイ曲リストＤＢ９、リクエスト放送ＤＢ１０が接続されており、曲マスタＤＢ８には放送用曲データおよび曲マスタテーブルが、マイ曲リストＤＢ９にはマイ曲リストテーブルが、リクエスト放送ＤＢ１０にはリクエストスケジュールテーブルとリクエストテンポラリテーブルが、それぞれ設けられている。これらのテーブルの詳細な構成については後述する。

サーバ２は、Ｗｅｂサーバ、メールサーバ、アプリケーションサーバ等としての一般的な処理機能を備えている。なお、曲マスタＤＢ８、マイ曲リストＤＢ９、リクエスト放送ＤＢ１０の各データベースは、それぞれのサーバ２に内蔵されていてもよい。また、サーバ２は一台のハードウエアによってその機能を実現されていても良いし、複数のハードウエアによってその機能を実現されていても良い。なお、サーバ２の詳細については後に図３および図４を用いて説明する。

図２は本実施形態における携帯電話機１のハードウエア構成例を示すブロック図である。受信部１１は、携帯電話網３を介してサーバ２からのデータの配信を受信する。音声出力部１２は、スピーカ等が適用され、受信部１１が受信したデータのうち音声データについて音声信号に変換して音声を再生する。表示部１３は、液晶画面などが適用され、受信したデータのうち画像データやテキストデータなどの表示可能なものを表示する。操作部１４は、携帯電話機１に備えられている操作キーが適用され、ユーザによって操作される。

内部メモリ１５は携帯電話機１に内蔵されている記憶装置であり、また外部メモリ１６は携帯電話機１に取り付けられたメモリーカードなどが適用され、いずれも必要なデータを保存する。なお、携帯電話機１は端末に固有のユーザＩＤを有しているが、このユーザＩＤは内部メモリ１５もしくは外部メモリ１６のいずれかに保存され、必要に応じて読み出される。

送信部１７は、サーバ２にデータを送信する。制御部１８は、サーバ２に接続するための制御や、データを送信するための制御や、受信したデータを音声出力部１２及び表示部１３に出力させる制御を行う。

図３は本実施形態におけるサーバ２のハードウエア構成例を示すブロック図である。ＣＰＵ（Central Processing Unit）１９は、周知のＯＳ（Operating System）、サーバプログラムおよび本発明の機能を実現するためのプログラムを実行することにより、サーバ２全体を制御する。主記憶装置２０はＲＡＭ（Random Access Memory）などが適用され、ＣＰＵ１９がプログラムを実行する際に使用する各種データを記録する。補助記憶装置２１はハードディスクなどが適用され、また外部記憶装置２２はＤＶＤ−ＲＯＭなどが適用され、いずれも電源が切られた際にも残しておく必要があるデータを記録する。入力装置２３はマウスやキーボードなどの入力デバイスが適用される。表示装置２４は液晶ディスプレイなどが適用される。通信装置２５は外部機器とデータを送受信する装置である。

図４は本実施形態におけるサーバ２の機能を表したブロック図である。これらの機能は図３に示したハードウエアによって実現されるものである。
通信インタフェース２６は、図示しないルータやファイヤウォールサーバを介してインターネット４に接続され、インターネット４を介して携帯電話機１との双方向通信を実現する。

商品販売実行部２７は、携帯電話機１を使用するユーザにＷｅｂを通じてＣＤやアーティストグッズのような物品や携帯電話機向け着信メロディーや待ち受け画像などを販売する。商品販売のシステムとしては、例えば、ユーザが一ヶ月あたり３００円支払って商品販売サイトと利用契約を結ぶと、商品販売サイトはユーザに３０ポイントを与えて、ユーザはその与えられたポイントを消費して希望する商品を購入する、といったものがある。ただし、他の公知のシステムにより行われていても良い。

リクエスト受付・処理部２８は、携帯電話機１を使用するユーザからの楽曲リクエストを受け付けたり、リクエストをしたユーザに通知を行ったりする。放送スケジュール管理部２９は、リクエスト受付・処理部２８が受け付けた楽曲リクエストをスケジュールに組み込むなどの番組スケジュールの管理を行う。なお、これらの詳細な処理については後述する。

放送実行部３０は、番組スケジュール管理部２９が管理する番組スケジュールに基づきリクエスト番組の放送を行う。本実施形態においては、携帯電話機１上で動作するアプリケーションを利用することにより再生可能としたストリーミング放送で行うが、他の公知の手法、例えばＰＣ向けストリーミング放送、ＦＭラジオ放送やテレビ放送などであってもよい。また、放送を受信するのは携帯電話機１であってもよいし、他の受信機であってもよい。

次に、各データベースに格納されているデータテーブルについて説明する。図５は曲マスタＤＢ８に格納されている曲マスタテーブルの内容例を示す説明図である。マテリアルＩＤ５１は商品ごとに固有のＩＤであり、また商品が着信メロディーであるときはその着信メロディーの元となった楽曲そのものを識別する機能も有する。例えばマテリアルＩＤ「１２３４５６」は、アーティスト「ＡＡＡ」のタイトル「ａｂｃｄ」という楽曲を示すと共に、この楽曲を元に作成された着信メロディーという商品も示す、ということである。
マテリアルタイプ５２は、その商品が着信メロディーであるかそれ以外かを示す値である。本実施形態では「１」のときに着信メロディー、「０」のときにそれ以外のＣＤやアーティストグッズなどであることを示す。

タイトル５３は商品の名称である。例えば、商品が着信メロディーであるときにはその楽曲名が、ＣＤであるときにはそのＣＤのタイトルが、アーティストグッズや待ち受け画像の場合にはそのタイトルが、これに該当する。アーティスト５４は、その商品に関連するアーティスト名であり、例えば着信メロディーの基となった楽曲を演奏するアーティスト名であり、待ち受け画像の場合にはその画像に写っているアーティストである。

放送可能フラグ５５は、マテリアルＩＤ５１に対応する楽曲がリクエスト番組で放送可能か否かを示す値であり、本実施形態では「１」のときに放送可能、「０」のときに放送不可を示す。なお、放送可能であるためには、マテリアルタイプ５２が「１」であり、かつ、放送用のデータがまだ用意されていない、などの放送できない特別な事情が無いことが必要である。

再生時間５６は、放送可能フラグ５５が「１」のものについてその再生時間を示すものである。関連マテリアルＩＤ５７は、そのマテリアルタイプ５２が「０」、すなわち着信メロディー以外である場合に、その商品に関連する楽曲のマテリアルＩＤが記録される。例えば、マテリアルＩＤ「１２３４５８」であるＣＤにタイトル「ｂｃｄｅ」という楽曲が収録されているような場合、ここにはその楽曲のマテリアルＩＤである「１２３４５７」が格納される。

図６はマイ曲リストＤＢ９に格納されているマイ曲リストテーブルの内容例を示す説明図である。ここでマイ曲リストとは、各ユーザが商品を購入することによってリクエスト可能となった曲を表示するリストのことである。

ユーザＩＤ６１はユーザが使用する端末に固有のＩＤであり、これによって個人を特定することが可能となる。登録マテリアルＩＤ６２はユーザごとのマイ曲リストに表示される楽曲のマテリアルＩＤ５１であり、ユーザが着信メロディーを購入した場合にはその着信メロディーのマテリアルＩＤ５１が、ＣＤを購入した場合にはそのマテリアルＩＤに登録された関連マテリアルＩＤ５７が、それぞれ登録されることとなる。

図７はリクエスト放送ＤＢに格納されているリクエストスケジュールテーブルの内容例を示す説明図である。
リクエストＩＤ７１は、各ユーザによりなされたリクエストを管理するための固有のＩＤである。リクエスト楽曲７２は、ユーザによりリクエストされた楽曲のマテリアルＩＤ５１である。リクエスト日時７３は、リクエスト楽曲７２が放送される予定の日時である。リクエストユーザ７４は、リクエストを行ったユーザのユーザＩＤ６１である。

課金フラグ７５は、そのリクエストが無料で行われたか有料で行われたかを示す値であり、本実施形態では「０」のときは無料、「１」のときは有料をそれぞれ示す。自動放送フラグは、そのリクエストが無料で行われたものであって有料リクエストにより上書きがされた場合、番組スケジュールの空き時間に組み込んで良いことを示す値である。

確定フラグ７７は、そのリクエストが確定していることを示す値であり、本実施形態ではリクエスト日時７３が１時間後となった時点でスケジュールが確定する。また、「０」のとき未確定、「１」のとき確定を示し、確定しているスケジュールについては上書きを行うことができない。なお、この課金フラグ７５、自動放送フラグ７６および確定フラグ７７は、後に説明する第二の実施形態のみで使用する値である。

図８はリクエスト放送ＤＢに格納されているリクエストテンポラリテーブルの内容例を示す説明図である。このリクエストテンポラリテーブルは、後に説明する第二の実施形態において、有料リクエストによって上書きされた無料リクエストの内容を一時的に保存しておくためのテーブルである。記録されているデータについては図７で説明したリクエストスケジュールテーブルと同様のものであるので、ここでは説明を省略する。

次に、これまで説明したシステムをどのように利用して、リクエスト番組制作放送が行われるかを図９から図１５に示したフローチャートおよび図１６に示した画面遷移図を用い、第一の実施形態および第二の実施形態それぞれについて詳細に説明する。

（第一の実施形態）
図９と図１０は、図１〜図８の実施形態に対応した、本発明にかかるリクエスト番組制作放送システムによるリクエスト受付処理フローの第一の実施形態を示すフローチャートである。このリクエスト受付処理は、ユーザが操作する携帯電話機１がサーバ２の用意するＷｅｂサイトにアクセスし、相互にデータを送受信して行われる。

なお、Ｗｅｂサイトへのアクセスは、ユーザにあらかじめ知らされたＵＲＬを直接入力して行われてもよいし、電子メールや他のＷｅｂサイト等により通知されたリンクを指定することにより行われても良い。

まず、携帯電話機１はＷｅｂブラウザを用いてサーバ２が用意するリクエストサイトにアクセスする（ＳＣ９０１）。このアクセス時に、携帯電話機１は端末の固有ＩＤであるユーザＩＤ６１をサーバ２に通知する。

サーバ２は携帯電話機１よりアクセスを受け付けると、通知されたユーザＩＤ６１を元にマイ曲リストＤＢを参照してマイ曲リストを取得し（ＳＳ９０１）、さらに曲マスタＤＢ８を参照して楽曲情報すなわちタイトル５３やアーティスト５４などを取得する（ＳＳ９０２）。

次に、サーバ２は放送可能フラグ５５を確認してマイ曲リストにリクエスト不可曲があるか否かを判断する（ＳＳ９０３）。リクエスト不可曲がある場合には、そのリクエスト不可曲をマイ曲リストから一時的に削除し（ＳＳ９０４）、携帯電話機１にそのマイ曲リストを送信する（ＳＳ９０５）。

なお、この処理はリクエスト不可能な曲をユーザに提示してしまわないために行うものであり、曲マスタＤＢ８に格納された曲マスタテーブルを書き換えるものではない。また、携帯電話機１に送信されるマイ曲リストは、登録マテリアルＩＤを元にタイトル５３およびアーティスト５４のリストに変換されている。

次に、携帯電話機１はマイ曲リストを受信して表示し（ＳＣ９０２）、ユーザが表示されたマイ曲リストからリクエストする曲を選択して携帯電話１がこれを送信すると（ＳＣ９０３）、サーバ２はリクエスト曲を受信する（ＳＳ９０６）。するとサーバ２はリクエスト曲の再生時間を確認し（ＳＳ９０７）、リクエストスケジュールＤＢを参照してリクエスト可能日時を取得し携帯電話機１に送信する（ＳＳ９０８）。

次に、携帯電話機１はリクエスト可能日時を受信して表示すると（ＳＣ９０４）、ユーザはその中から希望日時を選択し、その希望日時は携帯電話機１によってサーバ２に送信される（ＳＣ９０５）。サーバ２は希望日時を受信すると（ＳＳ９０９）、その希望日時を元にリクエストスケジュールＤＢにリクエスト曲を登録する（ＳＳ９１０）。

さらにサーバ２は、リクエストをしたユーザに対し、リクエスト曲がいつ放送されるのかを記載した放送時間の通知を送信し（ＳＳ９１１）、その通知を携帯電話機１が受信する（ＳＣ９０６）。なおこの通知はＷｅｂ上で行われても良いし、電子メールによって行われても良い。以上をもってリクエスト受付処理が完了する。

図１１は、図１〜図９の実施形態に対応した、本発明にかかるリクエスト番組制作放送システムのサーバ２によるリクエスト番組放送処理フローを示すフローチャートである。前述のように、本実施形態においては、放送は携帯電話機１上で動作するアプリケーションで再生可能としたストリーミング放送で行う。

まず、サーバ２はリクエスト放送ＤＢのリクエストスケジュールテーブルを参照し、スケジュールを読み込む（ＳＳ１１０１）。次にサーバはリクエスト日時７３が現在時刻と合致し、放送時間であると判断すると（ＳＳ１１０２でｙｅｓ）、曲マスタＤＢに格納されたリクエスト曲の放送用曲データを取得し（ＳＳ１１０３）、放送を実行する（ＳＳ１１０４）。なお、これらの処理は強制的に終了させる（ＳＳ１１０５でｙｅｓ）まで継続される。

以上、図９から図１１を用いて説明したのが本発明にかかるリクエスト番組制作放送システムの第一の実施形態である。次に、第二の実施形態について説明する。第二の実施形態は、第一の実施形態のリクエスト受付処理を基本として、リクエストを無料と有料の二段階としたものである。

（第二の実施形態）
図１２と図１３は、図１〜図８の実施形態に対応した、本発明にかかるリクエスト番組制作放送システムによるリクエスト受付処理フローの第二の実施形態を示すフローチャートである。なお、ＳＣ１２０１〜ＳＣ１２０２とＳＳ１２０１〜ＳＳ１２０５については、図９を用いて説明した第一の実施形態のＳＣ９０１〜ＳＣ９０２とＳＳ９０１〜ＳＳ９０５のそれぞれと同一であるため、ここでは説明を省略する。

本実施形態においては、携帯電話機１がマイ曲リストを受信して表示すると（ＳＣ１２０２）、ユーザはリクエストする曲を選択し（ＳＣ１２０３）、さらにリクエストを有料で行うか無料で行うかを選択して、携帯電話機１はこれらリクエスト曲と有料／無料の選択を送信する（ＳＣ１２０４）。なお本実施形態では、リクエストを無料で行うと他の有料で行われたリクエストによって上書きされてしまうが、有料で行うとそのようなことがない。

次に、サーバ２はリクエスト曲と有料／無料の選択を受信すると（ＳＳ１２０６）、曲マスタＤＢを参照してリクエスト曲の楽曲情報を取得する（ＳＳ１２０７）。リクエストが有料で行われている場合（ＳＳ１２０８で有料）は、有料でリクエスト可能な日時、すなわち空いている日時のみならず無料リクエストが既に入っている日時をも取得して送信する（ＳＳ１２０９）。なお、無料で行われている場合（ＳＳ１２０８で無料）は、空いている日時のみ取得して送信する（ＳＳ１２１０）。

ＳＣ１２０５〜ＳＣ１２０７とＳＳ１２１１については、図９を用いて説明した第一の実施形態のＳＣ９０４〜ＳＣ９０６とＳＳ９０９のそれぞれと同一であるため、ここでは説明を省略する。

本実施形態においては、サーバ２はリクエストスケジュールを登録する際（ＳＳ１２１２）、リクエスト放送ＤＢ１０のリクエストスケジュールテーブルにリクエスト楽曲７２やリクエスト日時７３等の他に、リクエストが有料／無料のいずれであるかを示す課金フラグ７５もリクエストスケジュールテーブルに記録する。

また、放送日時の通知送信が完了すると（ＳＳ１２１３，ＳＣ１２０７）、有料リクエストによる無料リクエストの上書きが発生したか否かを判断する（ＳＳ１２１４）。そして上書きが発生していた場合には、次の図１４を用いて説明する上書き通知・再リクエスト処理を実行し（ＳＳ１２１５）、処理が完了する。

図１４は、図１３のＳＳ１２１５に示した上書き通知・再リクエスト処理フローを示すフローチャートである。
まず、サーバ２は上書きされたリクエストをしたユーザに通知を行う（ＳＳ１４０１）。本実施形態においてこの通知は電子メールにより行われる。次に、携帯電話機１はこの通知を受信すると（ＳＣ１４０１）、電子メールに記載されたＵＲＬを選択するなどしてリクエストサイトにアクセスする（ＳＣ１４０２）。

次にサーバは、リクエストスケジュールＤＢのリクエストテンポラリテーブルを参照して上書きされたリクエストのリクエスト曲を取得し（ＳＳ１４０２）、リクエストスケジュールＤＢを参照して無料でリクエスト可能な日時を取得して送信する（ＳＳ１４０３）。

携帯電話機１はリクエスト可能日時を受信し表示すると（ＳＣ１４０３）、ユーザに再リクエストをするか否か（ＳＣ１４０４）、および再リクエストをするならば（ＳＣ１４０４でｙｅｓ）リクエスト時間を指定するか否か（ＳＣ１４０５）の選択を要求する。ここで再リクエストをするが時間指定をしない場合（ＳＣ１４０５でｎｏ）には、時間未指定リクエストとしてサーバ２に送信される（ＳＣ１４０６）。

なお、この時間未指定リクエストは、サーバでリクエストスケジュールが行われる際に、リクエスト放送ＤＢに設けられたリクエストスケジュールテーブルの自動放送フラグ７６が「１」として登録される。

再リクエストをし、時間も指定する場合には（ＳＣ１４０５でｙｅｓ）、ユーザはその中から希望日時を選択し、その希望日時は携帯電話機１によってサーバ２に送信される（ＳＣ１４０７）。ＳＣ１４０８とＳＳ１４０４〜ＳＳ１４０６は、図９と図１０を用いて説明した第一の実施形態のＳＣ９０６とＳＳ９０９〜ＳＳ９１１のそれぞれと同一であるため、ここでは説明を省略する。

図１５は図１２から図１４を用いて説明した第二の実施形態における、リクエスト受付開始からリクエスト確定までのサーバの処理フローの例を示すフロー図である。
サーバ２は、リクエスト受付を開始すると（ＳＳ１５０１）図１２と図１３で説明したリクエスト受付処理の実行を開始する（ＳＳ１５０２）。

次に、サーバ２は適宜スケジュールＤＢのリクエストスケジュールテーブルを参照し、現在時刻の１時間後に放送開始予定の登録リクエストがあるか否かを判断する（ＳＳ１５０４）。該当するリクエストが登録されている場合には（ＳＳ１５０４でｙｅｓ）リクエストスケジュールテーブルの放送確定フラグ７７を「１」とし、そのリクエストを確定させる（ＳＳ１５０５）。

さらにリクエストをしたユーザにリクエスト楽曲の放送スケジュールが確定した旨メール等で通知する（ＳＳ１５０６）。なお、これらの処理は強制的に終了させる（ＳＳ１５０７でｙｅｓ）まで継続される。
以上、図１２から図１５を用いて説明したのが本発明にかかるリクエスト番組制作放送システムの第二の実施形態である。

最後に、第一および第二の両実施形態における携帯電話１の表示部１３に表示される画面遷移の例を示す。図１６は、携帯電話１がサーバ２の用意するリクエストサイトにアクセスしてリクエストを実行する際の画面遷移の例である。

画面（Ａ）はリクエストサイトにアクセスした時に最初に表示する画面である。ここで「リクエストする」を選択すると（１３ａ）、マイ曲リスト（１３ｂ）を表示しリクエスト曲を受け付ける画面（Ｂ）に遷移する。ユーザはここでリクエストを希望する楽曲を選択し「決定」を選択する（１３ｃ）。なお、楽曲の選択は複数行うことも可能となっている。「決定」が選択されると、携帯電話機１がサーバ２にリクエスト曲を送信するとともに、画面（Ｃ）に遷移する。

画面（Ｃ）はリクエストする時間帯を選択させる画面である。この画面遷移の例においては、リクエストを希望する日時を指定した後に詳細な時間を選択するようになっている。ユーザがドロップダウンリストによってリクエストを希望する時間帯を選択して「決定」を選択すると、携帯電話機１がサーバ２にアクセスしてリクエスト可能時間を取得するとともに、画面（Ｄ）に遷移する。

画面（Ｄ）は、詳細なリクエスト時間を選択させる画面である。この例では、ユーザは１０時からと希望したので、１０時台でリクエスト可能な時間が表示される。ユーザは再度ドロップダウンリストによってリクエストを希望する時間を選択して「決定」選択すると、携帯電話機１がリクエスト日時をサーバ２に送信する。

サーバ２はここでリクエスト放送ＤＢ１０に格納されたリクエストスケジュールテーブルにリクエスト楽曲７２やリクエスト日時７３等を記録する。そして、携帯電話機１では画面（Ｅ）に遷移し、リクエストを受け付けた旨が表示される。

以下では本実施形態の利点を説明する。上述のように本実施形態では、ユーザが購入したＣＤや着信メロディー等の商品に対応する楽曲をリクエストすることが可能であるため、ユーザは好みの楽曲をリクエストすることが可能である。

また、リクエストした曲がいつ放送されるのか知ることができるため、リスナーであるユーザは自分がリクエストした曲を確実に聴くことができる。さらに、本リクエスト番組制作放送システムによれば、リクエスト番組の制作および放送が全てサーバにより行われるため、人手をかけずにリクエスト番組放送を行うことが可能となる。

また、別の側面から捉えれば、リスナーであるユーザは特定の楽曲をリクエストしたいためにその楽曲の着信メロディーを購入する、といったことも図れるため、リクエスト番組制作放送のみならず、商品販売サイトの販売促進にも繋がり得る。

以上、本発明をその実施形態に基づいて詳細に説明した。しかし、本発明は上記実施形態に限定されるものではない。本発明は、その要旨を逸脱しない範囲で様々な変形が可能である。

例えば、本実施形態では放送を携帯電話機１上で動作するアプリケーションを利用することにより再生可能としたストリーミング放送で行っているが、他の公知の手法、例えばＰＣ向けストリーミング放送、ＦＭラジオ放送やテレビ放送などであってもよいし、放送を受信するのは携帯電話機１であってもよいし、他の受信機であってもよい。

本発明は、ユーザからの楽曲リクエストを受け付けてリクエスト番組を制作放送するシステムで利用可能である。

本実施形態におけるシステム全体の概略構成を示す図である。 本実施形態における携帯電話機のハードウエア構成例を示すブロック図である。 本実施形態におけるサーバのハードウエア構成例を示すブロック図である。 本実施形態におけるサーバの機能を表したブロック図である。 曲マスタＤＢに格納されている曲マスタテーブルの内容例を示す説明図である。 マイ曲リストＤＢに格納されているマイ曲リストテーブルの内容例を示す説明図である。 リクエスト放送ＤＢに格納されているリクエストスケジュールテーブルの内容例を示す説明図である。 リクエスト放送ＤＢに格納されているリクエストテンポラリテーブルの内容例を示す説明図である。 図１〜図８の実施形態に対応した、本発明にかかるリクエスト番組制作放送システムによるリクエスト受付処理フローの第一の実施形態を示すフローチャートである。 図１〜図８の実施形態に対応した、本発明にかかるリクエスト番組制作放送システムによるリクエスト受付処理フローの第一の実施形態を示すフローチャートである。 図１〜図９の実施形態に対応した、本発明にかかるリクエスト番組制作放送システムのサーバによるリクエスト番組放送処理フローを示すフローチャートである。 図１〜図８の実施形態に対応した、本発明にかかるリクエスト番組制作放送システムによるリクエスト受付処理フローの第二の実施形態を示すフローチャートである。 図１〜図８の実施形態に対応した、本発明にかかるリクエスト番組制作放送システムによるリクエスト受付処理フローの第二の実施形態を示すフローチャートである。 図１３のＳＳ１２１５に示した上書き通知・再リクエスト処理フローを示すフローチャートである。 図１２から図１４を用いて説明した第二の実施形態における、リクエスト受付開始からリクエスト確定までのサーバの処理フローの例を示すフロー図である。 図１６は、携帯電話１がサーバ２の用意するリクエストサイトにアクセスしてリクエストを実行する際の画面遷移の例である。

符号の説明

１…携帯電話
２…サーバ
３…携帯電話網
４…インターネット
５…ゲートウェイサーバ
６…パケット網
７…基地局
８…曲マスタＤＢ
９…マイ曲リストＤＢ
１０…リクエスト放送ＤＢ
１１…受信部
１２…音声出力部
１３…表示部
１４…操作部
１５…内部メモリ
１６…外部メモリ
１７…送信部
１８…制御部
１９…ＣＰＵ
２０…主記憶装置
２１…補助記憶装置
２２…外部記憶装置
２３…入力装置
２４…表示装置
２５…通信装置
２６…通信インタフェース
２７…商品販売実行部
２８…リクエスト受付・処理部
２９…番組スケジュール管理部
３０…放送実行部
５１…マテリアルＩＤ
５２…マテリアルタイプ
５３…タイトル
５４…アーティスト
５５…放送可能フラグ
５６…再生時間
５７…関連マテリアルＩＤ
６１…ユーザＩＤ
６２…登録マテリアルＩＤ
７１…リクエストＩＤ
７２…リクエスト楽曲
７３…リクエスト日時
７４…リクエストユーザ
７５…課金フラグ
７６…自動放送フラグ
７７…放送確定フラグ

Claims (16)

1. ユーザによって操作され楽曲のリクエストを行う通信端末と、ネットワークを介して通信端末と相互に通信し、通信端末より楽曲のリクエストを受け付けてリクエスト番組を制作放送するサーバとから成り、
   通信端末は固有の端末ＩＤを有しており、サーバは前記固有の端末ＩＤを基に個々の通信端末を識別可能であって、
   サーバは、
   楽曲との１対１の関係性を有する商品と楽曲との対応を記憶している楽曲マスタデータベースと、個々の通信端末ごとに購入した商品の履歴を記録する商品購入履歴データベースと、を備え、
   通信端末による商品購入が実施されて前記商品購入履歴データベースに新たに購入した商品の履歴が追加されると、前記楽曲マスタデータベースを参照し、通信端末が購入した商品に対応する楽曲を通信端末ごとに固有の楽曲リストに追加する楽曲リスト生成手段、
   通信端末による楽曲リクエスト要求を受け付けると、前記楽曲リスト生成手段により生成された楽曲リストを通信端末に送信し、通信端末より楽曲リストから選択された楽曲を受信すると、この受信した選択楽曲をリクエスト楽曲として受け付けるリクエスト受付手段、
   番組で放送する楽曲名と、その楽曲が実際に放送される時間との関係を示す番組スケジュールを記憶しており、前記リクエスト受付手段によりリクエスト楽曲を受け付けると、当該リクエスト楽曲を番組スケジュールに組み込み可能な時間を判断して組み込み番組スケジュールを生成する番組スケジュール生成手段、
   前記番組スケジュール生成手段により生成された番組スケジュールに沿って番組を放送する番組放送手段、
   を備えることを特徴とするリクエスト番組制作放送システム。
2. 前記楽曲マスタデータベースは、さらに楽曲との１対１の関係性を有さない商品と楽曲との対応を、楽曲に付された固有の管理ＩＤを当該商品と結びつけることにより記憶していること
   を特徴とする請求項１記載のリクエスト番組制作放送システム。
3. サーバは、
   前記楽曲マスタデータベースにさらに楽曲の再生時間情報を記憶しており、
   前記リクエスト受付手段がリクエスト楽曲を受け付けると、楽曲マスタデータベースに記憶された楽曲の再生時間情報と、前記番組スケジュール生成手段に記憶された番組スケジュールとを参照し、当該リクエスト楽曲を番組スケジュールに組み込んで放送可能な日時を探索して、その結果を通信端末に送信する放送日時候補通知手段、
   をさらに有し、
   前記番組スケジュール生成手段は、通信端末より、前記放送日時候補通知手段によって送信された放送可能な日時の中から放送希望日時の選択を受け付けると、受け付けた放送希望日時に当該リクエスト楽曲を組み込んだ番組スケジュールを生成すること、
   を特徴とする請求項１又は２に記載のリクエスト番組制作放送システム。
4. サーバは、
   前記番組スケジュール生成手段がリクエスト楽曲を組み込んだ番組スケジュールを生成すると、当該リクエスト楽曲をリクエストした通信端末に対し、楽曲が放送される日時を通知する放送時間通知手段、
   をさらに有することを特徴とする請求項１乃至３の何れかに記載のリクエスト番組制作放送システム。
5. 前記リクエスト受付手段で受け付ける楽曲リクエストには優先度が異なる複数のリクエストが存在し、
   前記番組スケジュール生成手段は、さらに、既に優先度が相対的に下位のリクエストに基づくリクエスト楽曲が組み込まれている時間であっても、優先度が相対的に上位のリクエストに基づくリクエスト楽曲を優先的に組み込んで番組スケジュールを生成するというリクエストの上書きを行うこと、
   を特徴とする請求項１乃至４の何れかに記載のリクエスト番組制作放送システム。
6. サーバは、
   前記番組スケジュール生成手段が前記リクエストの上書きを行ったと判断すると、優先度が相対的に下位のリクエストを行った通信端末に対して通知を行い、再リクエストもしくはリクエストの取り消しを受け付ける手段、
   をさらに有することを特徴とする請求項１乃至５の何れかに記載のリクエスト番組制作放送システム。
7. ネットワークを介してユーザによって操作され楽曲のリクエストを行う通信端末と相互に通信し、楽曲との関係性を有する商品と楽曲との対応を記憶している楽曲マスタデータベースと個々の通信端末ごとに購入した商品の履歴を記録する商品購入履歴データベースとを備えるサーバを用い、通信端末より楽曲のリクエストを受け付けてリクエスト番組を制作し放送する方法であって、
   通信端末による商品購入が実施されて前記商品購入履歴データベースに新たに購入した商品の履歴が追加されると、前記楽曲マスタデータベースを参照し、通信端末が購入した商品に対応する楽曲を通信端末ごとに固有の楽曲リストに追加する楽曲リスト生成ステップ、
   通信端末による楽曲リクエスト要求を受け付けると、前記楽曲リスト生成手段により生成された楽曲リストを通信端末に送信し、通信端末より楽曲リストから選択された楽曲を受信すると、この受信した選択楽曲をリクエスト楽曲として受け付けるリクエスト受付ステップ、
   サーバが記憶している、番組で放送する楽曲名とその楽曲が実際に放送される時間との関係を示す番組スケジュールを参照し、前記リクエスト受付ステップにおいてリクエスト楽曲を受け付けると、当該リクエスト楽曲を番組スケジュールに組み込み可能な時間を判断して組み込み番組スケジュールを生成する番組スケジュール生成ステップ、
   前記番組スケジュール生成ステップにより生成された番組スケジュールに沿って番組を放送する番組放送ステップ、
   を備えることを特徴とするリクエスト番組制作放送方法。
8. 前記楽曲マスタデータベースにさらに楽曲の再生時間情報を記憶しているサーバにおいて、
   前記リクエスト受付ステップにおいてリクエスト楽曲を受け付けると、楽曲マスタデータベースに記憶された楽曲の再生時間情報と、前記番組スケジュール生成ステップにおいて記憶された番組スケジュールとを参照し、当該リクエスト楽曲を番組スケジュールに組み込んで放送可能な日時を探索して、その結果を通信端末に送信する放送日時候補通知ステップ、
   をさらに有し、
   前記番組スケジュール生成ステップにおいては、通信端末より、前記放送日時候補通知ステップにおいて送信された放送可能な日時の中から放送希望日時の選択を受け付けると、受け付けた放送希望日時に当該リクエスト楽曲を組み込んだ番組スケジュールを生成すること、
   を特徴とする請求項７記載のリクエスト番組制作放送方法。
9. 前記番組スケジュール生成ステップにおいてリクエスト楽曲を組み込んだ番組スケジュールを生成すると、当該リクエスト楽曲をリクエストした通信端末に対し、楽曲が放送される日時を通知する放送時間通知ステップ、
   をさらに有することを特徴とする請求項７又は８に記載のリクエスト番組制作放送方法。
10. 前記リクエスト受付ステップにおいて受け付ける楽曲リクエストには優先度が異なる複数のリクエストが存在し、
    前記番組スケジュール生成においては、さらに、既に優先度が相対的に下位のリクエストに基づくリクエスト楽曲が組み込まれている時間であっても、優先度が相対的に上位のリクエストに基づくリクエスト楽曲を優先的に組み込んで番組スケジュールを生成するというリクエストの上書きを行うこと、
    を特徴とする請求項７乃至９の何れかに記載のリクエスト番組制作放送方法。
11. 前記番組スケジュール生成ステップにおいて前記リクエストの上書きを行ったと判断すると、優先度が相対的に下位のリクエストを行った通信端末に対して通知を行い、再リクエストもしくはリクエストの取り消しを受け付けるステップ、
    をさらに有することを特徴とする請求項７乃至１０の何れかに記載のリクエスト番組制作放送方法。
12. ネットワークを介してユーザによって操作され楽曲のリクエストを行う通信端末と相互に通信し、楽曲との関係性を有する商品と楽曲との対応を記憶している楽曲マスタデータベースと個々の通信端末ごとに購入した商品の履歴を記録する商品購入履歴データベースとを備えるサーバ上で動作し、通信端末より楽曲のリクエストを受け付けてリクエスト番組を制作し放送するプログラムであって、
    通信端末による商品購入が実施されて前記商品購入履歴データベースに新たに購入した商品の履歴が追加されると、前記楽曲マスタデータベースを参照し、通信端末が購入した商品に対応する楽曲を通信端末ごとに固有の楽曲リストに追加する楽曲リスト生成ステップ、
    通信端末による楽曲リクエスト要求を受け付けると、前記楽曲リスト生成ステップにおいて生成された楽曲リストを通信端末に送信し、通信端末より楽曲リストから選択された楽曲を受信すると、この受信した選択楽曲をリクエスト楽曲として受け付けるリクエスト受付ステップ、
    番組で放送する楽曲名と、その楽曲が実際に放送される時間との関係を示す番組スケジュールを記憶しており、前記リクエスト受付ステップにおいてリクエスト楽曲を受け付けると、当該リクエスト楽曲を組み込んだ番組スケジュールを生成する番組スケジュール生成ステップ、
    前記番組スケジュール生成ステップにおいて生成された番組スケジュールに沿って番組を放送する番組放送ステップ、
    をコンピュータに実行させることを特徴とするリクエスト番組制作放送プログラム。
13. 前記楽曲マスタデータベースにさらに楽曲の再生時間情報を記憶しているサーバにおいて、
    前記リクエスト受付ステップにおいてリクエスト楽曲を受け付けると、楽曲マスタデータベースに記憶された楽曲の再生時間情報と、前記番組スケジュール生成ステップにおいて記憶された番組スケジュールとを参照し、当該リクエスト楽曲を番組スケジュールに組み込んで放送可能な日時を探索して、その結果を通信端末に送信する放送日時候補通知ステップ、
    をさらにコンピュータに実行させ、
    前記番組スケジュール生成ステップにおいては、通信端末より、前記放送日時候補通知ステップにおいて送信された放送可能な日時の中から放送希望日時の選択を受け付けると、受け付けた放送希望日時に当該リクエスト楽曲を組み込んだ番組スケジュールを生成すること、
    を特徴とする請求項１２記載のリクエスト番組制作放送プログラム。
14. 前記番組スケジュール生成ステップにおいてリクエスト楽曲を組み込んだ番組スケジュールを生成すると、当該リクエスト楽曲をリクエストした通信端末に対し、楽曲が放送される日時を通知する放送時間通知ステップ、
    をさらにコンピュータに実行させることを特徴とする請求項１２又は１３に記載のリクエスト番組制作放送プログラム。
15. 前記リクエスト受付ステップにおいて受け付ける楽曲リクエストには優先度が異なる複数のリクエストが存在し、
    前記番組スケジュール生成においては、さらに、既に優先度が相対的に下位のリクエストに基づくリクエスト楽曲が組み込まれている時間であっても、優先度が相対的に上位のリクエストに基づくリクエスト楽曲を優先的に組み込んで番組スケジュールを生成するというリクエストの上書きを行うこと、
    を特徴とする請求項１２乃至１４の何れかに記載のリクエスト番組制作放送プログラム。
16. 前記番組スケジュール生成ステップにおいて前記リクエストの上書きを行ったと判断すると、優先度が相対的に下位のリクエストを行った通信端末に対して通知を行い、再リクエストもしくはリクエストの取り消しを受け付けるステップ、
    をさらにコンピュータに実行させることを特徴とする請求項１２乃至１５の何れかに記載のリクエスト番組制作放送プログラム。

Images