特開2023-1322コンテンツ再生装置、コンテンツ配信サーバ、コンテンツ配信システム、制御方法及びプログラム
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2023001322
(43)【公開日】2023-01-04
(54)【発明の名称】コンテンツ再生装置、コンテンツ配信サーバ、コンテンツ配信システム、制御方法及びプログラム
(51)【国際特許分類】
G10K 15/02 20060101AFI20221222BHJP
【ＦＩ】
G10K15/02
【審査請求】有
【請求項の数】1
【出願形態】ＯＬ
(21)【出願番号】P 2022180122
(22)【出願日】2022-11-10
(62)【分割の表示】P 2021031574の分割
【原出願日】2014-03-26
(31)【優先権主張番号】P 2013077595
(32)【優先日】2013-04-03
(33)【優先権主張国・地域又は機関】JP
(71)【出願人】
【識別番号】000005016
【氏名又は名称】パイオニア株式会社
(74)【代理人】
【識別番号】100107331
【弁理士】
【氏名又は名称】中村 聡延
(72)【発明者】
【氏名】梨本 大奨
(72)【発明者】
【氏名】鎌田 喬浩
(57)【要約】
【課題】所定の道路に関連付けられたコンテンツを適切に再生することが可能なコンテンツ再生装置を提供する。
【解決手段】コンテンツ再生装置は、所定の道路に関連付けられたコンテンツの配信をコンテンツ配信サーバに対して要求して、当該コンテンツをコンテンツ配信サーバから取得するコンテンツ取得手段と、コンテンツ取得手段が取得したコンテンツを再生する再生手段と、を備える。
【選択図】図３
【解決手段】コンテンツ再生装置は、所定の道路に関連付けられたコンテンツの配信をコンテンツ配信サーバに対して要求して、当該コンテンツをコンテンツ配信サーバから取得するコンテンツ取得手段と、コンテンツ取得手段が取得したコンテンツを再生する再生手段と、を備える。
【選択図】図３
【特許請求の範囲】
【請求項1】
所定の道路に関連付けられたコンテンツの配信をコンテンツ配信サーバに対して要求して、当該コンテンツを前記コンテンツ配信サーバから取得するコンテンツ取得手段と、
前記コンテンツ取得手段が取得したコンテンツを再生する再生手段と、
を備えることを特徴とするコンテンツ再生装置。
前記コンテンツ取得手段が取得したコンテンツを再生する再生手段と、
を備えることを特徴とするコンテンツ再生装置。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、コンテンツを配信する技術分野に関する。
【背景技術】
【0002】
従来から、音楽や動画などのコンテンツを配信する種々の技術が提案されている。例えば、特許文献１には、ユーザごとに設定された走行環境ごとの選曲条件に応じて、楽曲を選択して配信する技術が提案されている。例えば、渋滞時にはクラシック音楽を選曲し、高速道路の走行時にはフォークソングを選曲している。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】特開２００３－１５０１７６号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
しかし、特許文献１では、ユーザが予め選曲条件を設定する必要がある。
【0005】
本発明が解決しようとする課題としては、上記のものが一例として挙げられる。本発明は、所定の道路に関連付けられたコンテンツを適切に再生することが可能なコンテンツ再生装置などを提供することを主な目的とする。
【課題を解決するための手段】
【0006】
請求項に記載の発明では、コンテンツ再生装置は、所定の道路に関連付けられたコンテンツの配信をコンテンツ配信サーバに対して要求して、当該コンテンツを前記コンテンツ配信サーバから取得するコンテンツ取得手段と、前記コンテンツ取得手段が取得したコンテンツを再生する再生手段と、を備えることを特徴とする。
【図面の簡単な説明】
【0007】
【図1】第１実施例に係る楽曲配信システムの概略構成を示すブロック図である。
【図2】現在情報及び再生情報の一例を示す。
【図3】走行中の道路に応じた楽曲を再生するための処理フローを示す。
【図4】楽曲データの再生中において、再生する楽曲データを切り替えるための処理フローを示す。
【図5】第２実施例に係る楽曲配信システムの概略構成を示すブロック図である。
【図6】道路交通情報生成処理のフローチャートである。
【図7】配信料計算処理のフローチャートである。
【図8】配信曲登録処理のフローチャートである。
【図9】配信対象指定処理のフローチャートである。
【図10】楽曲配信処理のフローチャートである。
【発明を実施するための形態】
【0008】
本発明の１つの観点では、コンテンツ再生装置は、所定の道路に関連付けられたコンテンツの配信をコンテンツ配信サーバに対して要求して、当該コンテンツを前記コンテンツ配信サーバから取得するコンテンツ取得手段と、前記コンテンツ取得手段が取得したコンテンツを再生する再生手段と、を備える。
【0009】
上記のコンテンツ再生装置は、所定の道路に関連付けられたコンテンツの配信をコンテンツ配信サーバに対して要求して、当該コンテンツをコンテンツ配信サーバから取得して再生する。これにより、道路に関連付けられたコンテンツを適切に再生することが可能となる。
【0010】
上記のコンテンツ再生装置の一態様では、移動体の現在位置を取得する現在位置取得手段を更に備え、前記コンテンツ取得手段は、前記現在位置に基づき、前記移動体が通過中の道路に関連付けられたコンテンツの配信を前記コンテンツ配信サーバに対して要求する。
【0011】
この態様によれば、移動体が通過中の道路に関連付けられたコンテンツを適切に再生することができる。よって、コンテンツ再生装置のユーザにとっては、移動中に様々なコンテンツの提供を受けることができる。また、コンテンツ事業者（レコード会社など）にとっては、コンテンツを多くのユーザに提供することができ、コンテンツの広告効果などを向上させることが可能となる。
【0012】
上記のコンテンツ再生装置の他の一態様では、前記現在位置の近傍における複数の道路のそれぞれに関連付けられたコンテンツを識別するためのコンテンツ識別情報を取得するコンテンツ識別情報取得手段と、前記コンテンツ識別情報取得手段が取得したコンテンツ識別情報の中で、前記移動体が通過中の道路に関連付けられたコンテンツに対応するコンテンツ識別情報を特定するコンテンツ識別情報特定手段と、を更に備え、前記コンテンツ取得手段は、前記コンテンツ識別情報特定手段が特定したコンテンツ識別情報に対応するコンテンツの配信を、前記コンテンツ配信サーバに対して要求する。これにより、移動体が通過中の道路に関連付けられたコンテンツを適切に取得することができる。
【0013】
上記のコンテンツ再生装置の他の一態様では、前記コンテンツ識別情報特定手段は、前記再生手段によるコンテンツの再生中に、前記移動体が通過中の道路に関連付けられたコンテンツに対応するコンテンツ識別情報を特定し、前記コンテンツ取得手段は、前記再生手段によるコンテンツの再生中に前記コンテンツ識別情報特定手段が特定したコンテンツ識別情報が、前記再生中のコンテンツに対応するコンテンツ識別情報と異なる場合に、前記コンテンツ識別情報特定手段が特定したコンテンツ識別情報に対応するコンテンツの配信を前記コンテンツ配信サーバに対して要求して、当該コンテンツを前記コンテンツ配信サーバから取得し、前記再生手段は、前記再生中のコンテンツから、前記コンテンツ取得手段が取得したコンテンツへ、再生する対象を切り替える。これにより、再生すべきコンテンツ（通過中の道路に応じたコンテンツ）を適切に再生することができる。
【0014】
上記のコンテンツ再生装置の一態様では、前記コンテンツ取得手段は、前記移動体が通過中の道路、及び前記移動体の進行方向の両方に関連付けられたコンテンツの配信を、前記コンテンツ配信サーバに対して要求する。これにより、進行方向に応じたコンテンツを取得することができる。
【0015】
上記のコンテンツ再生装置において好適には、前記現在位置に基づいて、前記移動体が通過中の道路を特定する道路特定手段を更に備えていても良い。この場合、上記したコンテンツ取得手段は、道路特定手段によって特定された道路を用いて、当該道路に関連付けられたコンテンツの配信をコンテンツ配信サーバに対して要求する。
【0016】
好適な例では、前記再生手段は、前記移動体が前記道路を通過する時間が、当該道路に関連付けられたコンテンツの再生時間よりも長い場合、当該コンテンツを繰り返し再生しても良い。これにより、道路の通過中に１つのコンテンツを再生し終えた場合に、そのコンテンツを何度も視聴させることができる。
【0017】
また、好適な例では、前記道路には、複数のコンテンツが関連付けられており、前記再生手段は、前記移動体が前記道路を通過する時間が、当該道路に関連付けられた１つのコンテンツの再生時間よりも長い場合、当該コンテンツの次のコンテンツを再生しても良い。これにより、道路の通過中に複数のコンテンツを視聴させることができる。
【0018】
また、好適な例では、前記再生手段は、前記移動体が前記道路を通過する時間が、当該道路に関連付けられたコンテンツの再生時間よりも短くても、当該コンテンツの再生を途中で停止することなく、当該コンテンツを最後まで再生しても良い。これにより、１つのコンテンツの全体を視聴させることができる。
【0019】
また、好適な例では、前記コンテンツは、当該コンテンツが関連付けられた道路を前記移動体が通過する時間に応じた再生時間を有していても良い。これにより、移動体が道路を通過している最中に、１つのコンテンツの全体を適切に再生することができる。
【0020】
また、好適な例では、前記再生手段がコンテンツを再生した場合に、その旨を示す情報を前記コンテンツ配信サーバに供給する手段を更に備えていても良い。これにより、コンテンツ配信サーバにおいて、コンテンツの再生回数や視聴履歴や視聴率を得ることができる。
【0021】
また、好適な例では、前記コンテンツに関連する情報を、当該コンテンツが関連付けられた道路に付加して表示させる手段を更に備えていても良い。これにより、道路に関連付けられたコンテンツを容易に把握させることができる。
【0022】
本発明の他の観点では、コンテンツ配信サーバは、道路ごとにコンテンツを関連付けて記憶する記憶手段と、前記記憶手段から、コンテンツ再生装置の要求に応じた道路に関連付けられたコンテンツを読み出して、当該コンテンツを前記コンテンツ再生装置に配信するコンテンツ配信手段と、を備える。
【0023】
また、本発明の他の観点では、コンテンツ再生装置及びコンテンツ配信サーバを有するコンテンツ配信システムであって、前記コンテンツ再生装置は、所定の道路に関連付けられたコンテンツの配信を前記コンテンツ配信サーバに対して要求して、当該コンテンツを前記コンテンツ配信サーバから取得するコンテンツ取得手段と、前記コンテンツ取得手段が取得したコンテンツを再生する再生手段と、を備え、前記コンテンツ配信サーバは、道路ごとにコンテンツを関連付けて記憶する記憶手段と、前記記憶手段から、前記コンテンツ再生装置の要求に応じた道路に関連付けられたコンテンツを読み出して、当該コンテンツを前記コンテンツ再生装置に配信するコンテンツ配信手段と、を備える。
【0024】
また、本発明の他の観点では、コンテンツ再生装置によって実行される制御方法は、所定の道路に関連付けられたコンテンツの配信をコンテンツ配信サーバに対して要求して、当該コンテンツを前記コンテンツ配信サーバから取得するコンテンツ取得工程と、前記コンテンツ取得工程が取得したコンテンツを再生する再生工程と、を備える。
【0025】
また、本発明の他の観点では、コンピュータを有するコンテンツ再生装置によって実行されるプログラムは、前記コンピュータを、所定の道路に関連付けられたコンテンツの配信をコンテンツ配信サーバに対して要求して、当該コンテンツを前記コンテンツ配信サーバから取得するコンテンツ取得手段、前記コンテンツ取得手段が取得したコンテンツを再生する再生手段、として機能させる。
【0026】
また、本発明の他の観点では、コンテンツ配信サーバによって実行される制御方法は、道路ごとにコンテンツを関連付けて記憶する記憶工程と、前記記憶工程で記憶されたコンテンツの中から、コンテンツ再生装置の要求に応じた道路に関連付けられたコンテンツを取得し、当該コンテンツを前記コンテンツ再生装置に配信するコンテンツ配信工程と、を備える。
【0027】
また、本発明の他の観点では、コンピュータを有するコンテンツ配信サーバによって実行されるプログラムは、前記コンピュータを、道路ごとにコンテンツを関連付けて記憶する記憶手段、前記記憶手段で記憶されたコンテンツの中から、コンテンツ再生装置の要求に応じた道路に関連付けられたコンテンツを取得し、当該コンテンツを前記コンテンツ再生装置に配信するコンテンツ配信手段、として機能させる。
【0028】
本発明の他の観点では、コンテンツ配信サーバは、道路毎にコンテンツを配信するための料金情報を関連付けて記憶部に記憶する記憶手段と、前記記憶部から、コンテンツ登録装置の要求に応じて、前記道路の情報と当該道路に関連付けられた料金情報とを前記コンテンツ登録装置へ送信する送信手段と、前記送信手段によって前記道路の情報と当該道路に関連付けられた料金情報とを送信した後、当該コンテンツ登録装置から送信されるコンテンツの識別情報と当該コンテンツを配信する道路の情報と受信する受信手段と、受信したコンテンツの識別情報を、受信した前記道路の情報に関連付けて前記記憶部に登録する登録手段と、を備える。
【0029】
上記のコンテンツ配信サーバは、道路毎にコンテンツを配信するための料金情報を関連付けて記憶部に記憶している。コンテンツ登録装置からの要求があると、コンテンツ配信サーバは、道路の情報と当該道路に関連付けられた料金情報とを要求元のコンテンツ登録装置へ送信する。また、送信手段によって前記道路の情報と当該道路に関連付けられた料金情報とを送信した後、コンテンツ配信サーバは、当該コンテンツ登録装置から送信されるコンテンツの識別情報と当該コンテンツを配信する道路の情報と受信し、コンテンツの識別情報を前記道路の情報に関連付けて前記記憶部に登録する登録する。これにより、コンテンツ登録装置からの要求に応じて、道路に対してコンテンツを対応付けて登録することができる。
【0030】
上記のコンテンツ配信サーバの一態様では、前記料金情報は、対応する道路の交通量に応じて設定されている。これにより、道路の交通量に応じてコンテンツの配信料金を調整することができる。
【0031】
上記のコンテンツ配信サーバの他の一態様は、道路を指定したコンテンツ配信要求に基づいて、コンテンツを端末装置へ配信する配信手段を備え、前記料金情報は、対応する道路に関して、前記配信手段が前記端末装置へコンテンツを配信する優先度に応じて設定されている。これにより、コンテンツがユーザに配信される優先度に応じてコンテンツの配信料金を調整することができる。
【0032】
上記のコンテンツ配信サーバの他の一態様は、道路を指定したコンテンツ配信要求に基づいて、コンテンツを端末装置へ配信する配信手段を備え、前記料金情報は、前記配信手段による配信実績に応じて設定されている。これにより、実際の配信実績に応じてコンテンツの配信料金を調整することができる。
【0033】
好適な例では、前記料金情報は、対応する道路における進行方向毎に設定される。また、他の好適な例では、前記料金情報は、曜日、時間帯、天候、交通量、交通状況の少なくとも１つに応じて異なる金額に設定される。
【0034】
本発明の他の観点では、コンテンツ配信サーバにより実行される制御方法は、道路毎にコンテンツを配信するための料金情報を関連付けて記憶部に記憶する記憶工程と、前記記憶部から、コンテンツ登録装置の要求に応じて、前記道路の情報と当該道路に関連付けられた料金情報とを前記コンテンツ登録装置へ送信する送信工程と、前記送信工程によって前記道路の情報と当該道路に関連付けられた料金情報とを送信した後、当該コンテンツ登録装置から送信されるコンテンツの識別情報と当該コンテンツを配信する道路の情報と受信する受信工程と、受信したコンテンツの識別情報を、受信した前記道路の情報に関連付けて前記記憶部に登録する登録工程と、を備える。これにより、コンテンツ登録装置からの要求に応じて、道路に対してコンテンツを対応付けて登録することができる。
【0035】
本発明の他の観点では、記憶部とコンピュータとを備えるコンテンツ配信サーバにより実行されるプログラムは、道路毎にコンテンツを配信するための料金情報を関連付けて前記記憶部に記憶する記憶手段、前記記憶部から、コンテンツ登録装置の要求に応じて、前記道路の情報と当該道路に関連付けられた料金情報とを前記コンテンツ登録装置へ送信する送信手段、前記送信手段によって前記道路の情報と当該道路に関連付けられた料金情報とを送信した後、当該コンテンツ登録装置から送信されるコンテンツの識別情報と当該コンテンツを配信する道路の情報と受信する受信手段、受信したコンテンツの識別情報を、受信した前記道路の情報に関連付けて前記記憶部に登録する登録手段、として前記コンピュータを機能させる。このプログラムをコンピュータで実行することにより、コンテンツ配信サーバを実現することができる。
【実施例0036】
以下、図面を参照して本発明の好適な実施例について説明する
［１］第１実施例
［システム構成］
図１は、第１実施例に係る楽曲配信システム１０の概略構成を示すブロック図である。図１に示すように、楽曲配信システム１０は、端末装置１と、サーバ装置２と、を有する。楽曲配信システム１０は、端末装置１の要求に応じてサーバ装置２が楽曲を端末装置１に配信するために好適に利用される。なお、楽曲配信システム１０は本発明における「コンテンツ配信システム」の一例に相当し、端末装置１は本発明における「コンテンツ再生装置」の一例に相当し、サーバ装置２は本発明における「コンテンツ配信サーバ」の一例に相当する。
［１］第１実施例
［システム構成］
図１は、第１実施例に係る楽曲配信システム１０の概略構成を示すブロック図である。図１に示すように、楽曲配信システム１０は、端末装置１と、サーバ装置２と、を有する。楽曲配信システム１０は、端末装置１の要求に応じてサーバ装置２が楽曲を端末装置１に配信するために好適に利用される。なお、楽曲配信システム１０は本発明における「コンテンツ配信システム」の一例に相当し、端末装置１は本発明における「コンテンツ再生装置」の一例に相当し、サーバ装置２は本発明における「コンテンツ配信サーバ」の一例に相当する。
【0037】
端末装置１は、主に、制御部１１と、記憶部１２と、通信部１３と、ＧＰＳ受信機１４と、自立測位装置１５と、表示部１６と、スピーカ１７と、を有する。端末装置１は、車両に搭載されて利用される。例えば、端末装置１は、ナビゲーション装置や、スマートフォンなどの携帯端末装置である。なお、端末装置１が携帯端末装置である場合には、端末装置１は自立測位装置１５を具備していなくても良い。
【0038】
記憶部１２は、図示しないＲＯＭ（Read Only Memory）やＲＡＭ（Random Access Memory）やハードディスクなどの各種のメモリを備えて構成され、端末装置１を制御するための種々の制御プログラムなどが格納されると共に、制御部１１に対してワーキングエリアを提供する。記憶部１２は、後述する制御・処理に必要な種々のデータを記憶している。
【0039】
通信部１３は、サーバ装置２と通信可能に構成されている。例えば、通信部１３は、無線通信方式にて通信を行う。
【0040】
ＧＰＳ受信機１４は、複数のＧＰＳ衛星から、測位用データを含む下り回線データを搬送する電波を受信する。測位用データは、緯度及び経度情報などから端末装置１の絶対的な位置（つまり車両の現在位置）を検出するために用いられる。
【0041】
自立測位装置１５は、図示しない加速度センサや角速度センサや距離センサなどを備える。加速度センサは、例えば圧電素子からなり、車両の加速度を検出し、加速度データを出力する。角速度センサは、例えば振動ジャイロからなり、車両の方向変換時における車両の角速度を検出し、角速度データ及び相対方位データを出力する。距離センサは、車両の車輪の回転に伴って発生されているパルス信号からなる車速パルスを計測する。
【0042】
表示部１６は、例えば液晶ディスプレイなどにより構成され、端末装置１のユーザに対して文字、画像などを表示する。表示部１６を、タッチパネルなどにて構成しても良い。
【0043】
スピーカ１７は、制御部１１による制御に基づき、音声を出力する。
【0044】
制御部１１は、図示しないＣＰＵ（Central Processing Unit）などを備えて構成され、端末装置１全体の制御を行う。制御部１１は、本発明における「コンテンツ取得手段」、「再生手段」、「現在位置取得手段」、「コンテンツ識別情報取得手段」、「コンテンツ識別情報特定手段」及び「道路特定手段」の一例に相当する。なお、制御部１１が行う制御については、詳細は後述する。
【0045】
次に、サーバ装置２は、主に、制御部２１と、記憶部２２と、通信部２３と、を有する。
【0046】
記憶部２２は、図示しないＲＯＭやＲＡＭやハードディスクなどの各種のメモリを備えて構成され、サーバ装置２を制御するための種々の制御プログラムなどが格納されると共に、制御部２１に対してワーキングエリアを提供する。記憶部２２は、後述する制御・処理に必要な種々のデータを記憶している。なお、記憶部２２は、本発明における「記憶手段」の一例に相当する。
【0047】
通信部２３は、端末装置１と通信可能に構成されている。
【0048】
制御部２１は、図示しないＣＰＵなどを備えて構成され、サーバ装置２全体の制御を行う。制御部２１は、本発明における「コンテンツ配信手段」の一例に相当する。なお、制御部２１が行う制御については、詳細は後述する。
【0049】
［制御の概要］
ここでは、本実施例に係る楽曲配信システム１０にて行われる制御の概要について説明する。
ここでは、本実施例に係る楽曲配信システム１０にて行われる制御の概要について説明する。
【0050】
まず、端末装置１は、ＧＰＳ受信機１４及び／又は自立測位装置１５からの出力に基づいて車両の現在位置及び進行方向を求め、現在位置及び進行方向を含む情報（以下では「現在情報」と呼ぶ。）をサーバ装置２に送信する。この場合、端末装置１は、現在情報をサーバ装置２に送信することで、当該現在情報に応じた、楽曲の再生に関連する情報（以下では「再生情報」と呼ぶ。）の送信をサーバ装置２に対して要求する。再生情報は、各リンクの道路形状などを示す道路データや、各リンクを識別するための道路ＩＤ（リンクごとに固有のＩＤ）や、各楽曲を識別するための楽曲ＩＤ（楽曲ごとに固有のＩＤ）などを含む情報である。なお、リンクは、２つの異なる交差点（ノード）を結ぶ１つの線オブジェクトに相当し、以下ではリンクのことを単に道路と表記することがある。
【0051】
他方で、サーバ装置２は、地図上の道路に関連付けて楽曲を記憶している。具体的には、サーバ装置２は、道路に関するデータと楽曲に関するデータとを関連付けて、記憶部２２に記憶している。詳しくは、サーバ装置２は、道路ＩＤや道路データと、楽曲ＩＤや楽曲名称や楽曲データや再生開始位置や配信対象期間などとを関連付けて記憶している。
【0052】
サーバ装置２は、上記のようにして端末装置１から送信された現在情報を受信した場合に、当該現在情報に応じた再生情報を生成する。具体的には、サーバ装置２は、まず、現在情報に含まれる現在位置及び進行方向に基づいて、車両の現在位置の近傍に存在する複数の道路（以下では「近隣道路」と呼ぶ。）を特定する。近隣道路は、車両が走行中の道路を含む、車両の周囲に存在する道路（詳しくは進行方向に存在する道路）である。つまり、近隣道路は、現在位置の近隣の道路ネットワークに相当する。この場合、サーバ装置２は、記憶部２２から、そのような近隣道路のそれぞれの道路ＩＤ及び道路データを読み出す。また、サーバ装置２は、記憶部２２から、当該近隣道路のそれぞれの道路ＩＤ及び道路データに関連付けられた楽曲ＩＤ、楽曲名称及び再生開始位置を読み出す。そして、サーバ装置２は、こうして読み出した道路ＩＤ及び道路データと楽曲ＩＤ、楽曲名称及び再生開始位置とを対応付けることで再生情報を生成し、生成した再生情報を端末装置１に送信する。なお、サーバ装置２は、近隣道路が有する複数の道路（リンク）の数だけ、再生情報を生成する。
【0053】
次に、端末装置１は、上記のようにしてサーバ装置２から送信された再生情報に基づいて、マップマッチングを行うことで、車両が走行中の道路を特定する。具体的には、端末装置１は、近隣道路についての複数の再生情報が有する道路ＩＤ及び道路データと、車両の現在位置及び進行方向とに基づいて、車両が走行中の道路の道路ＩＤを特定する。そして、端末装置１は、再生情報に基づいて、当該道路ＩＤに関連付けられた楽曲ＩＤを特定し、特定した楽曲ＩＤをサーバ装置２に送信する。この場合、端末装置１は、楽曲ＩＤをサーバ装置２に送信することで、当該楽曲ＩＤに対応する楽曲データの送信をサーバ装置２に対して要求する。楽曲データは、音楽コンテンツの１曲分の再生データに相当する（以下では楽曲データのことを単に楽曲と表記することがある。）。
【0054】
次に、サーバ装置２は、上記のようにして端末装置１から送信された楽曲ＩＤを受信した場合に、当該楽曲ＩＤに対応する楽曲データを記憶部２２から読み出し、読み出した楽曲データを端末装置１に送信する。そして、端末装置１は、サーバ装置２から送信された楽曲データを再生する。この場合、端末装置１は、楽曲データに対応する音声をスピーカ１７から出力させる。
【0055】
図２は、上記した現在情報及び再生情報の一例を示している。図２（ａ）に示すように、現在情報１００は、車両の位置（緯度・経度）を示す現在位置１０１と、例えば北を０度として時計回りにて３６０度で方角を表した、車両の進行方向１０２と、端末装置１がサーバ装置２に現在情報を送信した時刻（つまり端末装置１がサーバ装置２に対して再生情報を問い合わせた時刻）を示す現在時刻１０３と、端末装置１のユーザ又は端末装置１自体を識別するためのユーザＩＤ１０４と、を有する。また、図２（ｂ）に示すように、再生情報２００は、車両の現在地付近の道路（リンク）の形状などを示す道路データ２０１と、道路（リンク）ごとに固有の道路ＩＤ２０２と、楽曲ごとに固有の楽曲ＩＤ２０３と、楽曲の名称（題名など）を示す楽曲名称２０４と、楽曲の再生開始時点を示す再生開始位置２０５と、を有する。
【0056】
なお、道路データ２０１は、例えば、１つのリンク上に位置する複数の点の座標（緯度・経度）から成るデータである。道路データ２０１や道路ＩＤ２０２は、一般的な地図データが有するデータである。また、楽曲ＩＤ２０３は、本発明における「コンテンツ識別情報」の一例に相当する。
【0057】
【0058】
図３は、走行中の道路に応じた楽曲を端末装置１で再生させるために行われる処理フローを示している。具体的には、図３では、左側に端末装置１にて行われる処理（楽曲再生処理）のフローを示しており、右側にサーバ装置２にて行われる処理（再生情報送信処理及び楽曲データ送信処理）のフローを示している。楽曲再生処理は、端末装置１で楽曲を再生するために行われる処理であり、端末装置１内の制御部１１によって繰り返し実行される。再生情報送信処理は、サーバ装置２から端末装置１へ再生情報を送信するために行われる処理であり、楽曲データ送信処理は、サーバ装置２から端末装置１へ楽曲データを送信するために行われる処理である。再生情報送信処理及び楽曲データ送信処理は、サーバ装置２内の制御部２１によって繰り返し実行される。
【0059】
まず、端末装置１では、制御部１１が現在情報を生成する（ステップＳ１１１）。具体的には、制御部１１は、ＧＰＳ受信機１４及び／又は自立測位装置１５からの出力に基づいて車両の現在位置を求めると共に、自立測位装置１５からの出力に基づいて車両の進行方向を求める。そして、制御部１１は、求めた現在位置及び進行方向と、端末装置１内の時刻情報を発信するクロック手段（図１では図示せず）から取得した現在時刻と、記憶部１２などから取得したユーザＩＤとを対応付けることで、現在情報を生成する。この後、制御部１１は、生成した現在情報に応じた再生情報の送信をサーバ装置２に対して要求すべく（つまり現在情報に応じた再生情報をサーバ装置２に問い合わせるべく）、通信部１３を介して、当該現在情報をサーバ装置２に送信する（ステップＳ１１２）。
【0060】
次に、サーバ装置２では、通信部２３が、端末装置１から送信された現在情報を受信する（ステップＳ２１１）。そして、制御部２１が、通信部２３が受信した現在情報に基づいて、再生情報を生成する（ステップＳ２１２）。具体的には、制御部２１は、まず、現在情報に含まれる現在位置及び進行方向に基づいて、車両の現在位置の近傍に存在する複数の道路（近隣道路）を特定する。この場合、制御部２１は、記憶部２２から、近隣道路のそれぞれの道路ＩＤ及び道路データを読み出す。また、制御部２１は、記憶部２２から、当該近隣道路のそれぞれの道路ＩＤ及び道路データに関連付けられた楽曲ＩＤ、楽曲名称及び再生開始位置を読み出す。この後、制御部２１は、こうして読み出した道路ＩＤ及び道路データと楽曲ＩＤ、楽曲名称及び再生開始位置とを対応付けることで再生情報を生成し、通信部２３を介して、生成した再生情報を端末装置１に送信する（ステップＳ２１３）。この場合、制御部２１は、近隣道路が有する複数の道路の数だけ、再生情報を生成して送信する。
【0061】
次に、端末装置１では、通信部１３が、サーバ装置２から送信された再生情報を受信する（ステップＳ１１３）。そして、制御部１１が、マップマッチングを行うことで、再生情報に基づいて、車両が走行中の道路を特定する（ステップＳ１１４）。具体的には、制御部１１は、近隣道路についての複数の再生情報が有する道路ＩＤ及び道路データと、車両の現在位置及び進行方向とに基づいて、車両が走行中の道路の道路ＩＤを特定する。例えば、制御部１１は、現在位置に対応する位置座標と同一の位置座標、又は現在位置に対応する位置座標にかなり近い位置座標を含む道路データを特定して、当該道路データに対応する道路ＩＤを特定する。この場合、制御部１１は、車両の進行方向に応じた道路ＩＤを特定する。この後、制御部１１は、再生情報に基づいて、ステップＳ１１４で特定した道路ＩＤに関連付けられた楽曲ＩＤを更に特定し、通信部１３を介して、特定した楽曲ＩＤをサーバ装置２に送信する（ステップＳ１１５）。制御部１１は、特定した楽曲ＩＤに対応する楽曲データの送信をサーバ装置２に対して要求すべく、当該楽曲ＩＤをサーバ装置２に送信する。
【0062】
次に、サーバ装置２では、通信部２３が、端末装置１から送信された楽曲ＩＤを受信する（ステップＳ２２１）。そして、制御部２１が、通信部２３が受信した楽曲ＩＤに対応する楽曲データを記憶部２２から読み出し、通信部２３を介して、読み出した楽曲データを端末装置１に送信する（ステップＳ２２２）。
【0063】
次に、端末装置１では、通信部１３が、サーバ装置２から送信された楽曲データを受信する（ステップＳ１１６）。そして、制御部１１が、通信部１３が受信した楽曲データを再生する（ステップＳ１１７）。この場合、制御部１１は、楽曲データに対応する音声をスピーカ１７から出力させる制御を行う。
【0064】
図４は、楽曲データの再生中において再生する楽曲データを切り替えるために行われる処理フローを示している。具体的には、図４では、左側に端末装置１にて行われる処理（楽曲切り替え処理）のフローを示しており、右側にサーバ装置２にて行われる処理（楽曲データ送信処理）のフローを示している。楽曲切り替え処理は、端末装置１で再生する楽曲データを切り替えるために行われる処理であり、端末装置１内の制御部１１によって繰り返し実行される。楽曲データ送信処理は、図３に示したものと同様であり、ここではその説明を適宜省略する。
【0065】
まず、端末装置１では、制御部１１が、車両の現在位置及び進行方向を取得する（ステップＳ１２１）。具体的には、制御部１１は、ＧＰＳ受信機１４及び／又は自立測位装置１５からの出力に基づいて車両の現在位置を求めると共に、自立測位装置１５からの出力に基づいて車両の進行方向を求める。そして、制御部１１は、図３のステップＳ１１３で取得した再生情報に基づいて、マップマッチングを行うことで、車両が走行中の道路を特定する（ステップＳ１２２）。具体的には、制御部１１は、ステップＳ１１３で取得した近隣道路についての複数の再生情報が有する道路ＩＤ及び道路データと、ステップＳ１２１で取得した車両の現在位置及び進行方向とに基づいて、車両が走行中の道路の道路ＩＤを特定する。この場合、制御部１１は、車両の進行方向に応じた道路ＩＤを特定する。
【0066】
次に、制御部１１は、ステップＳ１１３で取得した再生情報に基づいて、ステップＳ１２２で特定した道路ＩＤに関連付けられた楽曲ＩＤを更に特定する（ステップＳ１２３）。つまり、制御部１１は、現在走行中の道路に応じて再生すべき楽曲の楽曲ＩＤを特定する。そして、制御部１１は、ステップＳ１２３で特定した楽曲ＩＤと、現在再生中の楽曲データの楽曲ＩＤ（図３のステップＳ１１５で特定される）とが異なるか否かを判定する（ステップＳ１２４）。ここでは、制御部１１は、現在再生中の楽曲データを切り替えるべき状況であるか否かを判定している。
【0067】
ステップＳ１２３で特定した楽曲ＩＤと現在再生中の楽曲データの楽曲ＩＤとが一致する場合（ステップＳ１２４：Ｎｏ）、処理はステップＳ１２１に戻る。この場合には、現在再生中の楽曲データを切り替えない。
【0068】
これに対して、ステップＳ１２３で特定した楽曲ＩＤと、現在再生中の楽曲データの楽曲ＩＤとが異なる場合（ステップＳ１２４：Ｙｅｓ）、処理はステップＳ１２５に進む。この場合には、現在再生中の楽曲データを切り替えるべく、ステップＳ１２５以降の処理が行われる。具体的には、制御部１１は、まず、ステップＳ１２３で特定した楽曲ＩＤを、通信部１３を介してサーバ装置２に送信する（ステップＳ１２５）。つまり、制御部１１は、再生すべき楽曲データの送信をサーバ装置２に対して要求すべく、当該楽曲データに対応する楽曲ＩＤをサーバ装置２に送信する。そして、サーバ装置２では、通信部２３が、端末装置１から送信された楽曲ＩＤを受信し（ステップＳ２２１）、制御部２１が、当該楽曲ＩＤに対応する楽曲データを記憶部２２から読み出し、読み出した楽曲データを通信部２３を介して端末装置１に送信する（ステップＳ２２２）。
【0069】
次に、端末装置１では、通信部１３が、サーバ装置２から送信された楽曲データを受信する（ステップＳ１２６）。そして、制御部１１が、通信部１３が受信した楽曲データを再生する（ステップＳ１２７）。つまり、制御部１１は、再生する楽曲データを切り替える。
【0070】
［本実施例の作用・効果］
以上説明した本実施例によれば、道路ごとに楽曲を関連付けてサーバ装置２に記憶させておき、走行中の道路に応じた楽曲を端末装置１に配信して再生させる。したがって、端末装置１のユーザにとっては、走行中に様々な楽曲を聴くことができる。また、レコード会社などの音楽事業者にとっては、楽曲を多くの人に聴いてもらうことができる。よって、楽曲の広告効果などを向上させることが可能となる。
以上説明した本実施例によれば、道路ごとに楽曲を関連付けてサーバ装置２に記憶させておき、走行中の道路に応じた楽曲を端末装置１に配信して再生させる。したがって、端末装置１のユーザにとっては、走行中に様々な楽曲を聴くことができる。また、レコード会社などの音楽事業者にとっては、楽曲を多くの人に聴いてもらうことができる。よって、楽曲の広告効果などを向上させることが可能となる。
【0071】
［変形例］
以下では、上記した実施例に好適な変形例を示す。なお、下記の変形例は、任意に組み合わせて上述の実施例に適用することができる。
以下では、上記した実施例に好適な変形例を示す。なお、下記の変形例は、任意に組み合わせて上述の実施例に適用することができる。
【0072】
（変形例１）
他の例では、サーバ装置２が端末装置１に再生情報又は楽曲データを送信する場合に、アーティスト名や、購入用リンク（楽曲を購入可能なサイトのアドレス）や、歌詞や、発表年月日などを、再生情報又は楽曲データと共に送信しても良い。
他の例では、サーバ装置２が端末装置１に再生情報又は楽曲データを送信する場合に、アーティスト名や、購入用リンク（楽曲を購入可能なサイトのアドレス）や、歌詞や、発表年月日などを、再生情報又は楽曲データと共に送信しても良い。
【0073】
更に他の例では、サーバ装置２が端末装置１に再生情報又は楽曲データを送信する場合に、楽曲のジャケット写真や曲調などを、再生情報又は楽曲データと共に送信しても良い。その場合、端末装置１は、表示部１６に表示された地図画面において、該当する道路上にジャケット写真を表示させたり、該当する道路を曲調に応じた色合いなどで表示させたりすると良い。なお、ジャケット写真や曲調などは、本発明における「コンテンツに関連する情報」の一例に相当する。
【0074】
（変形例２）
他の例では、道路の走行時間が当該道路に関連付けられた楽曲の再生時間（１曲の再生時間）よりも長い場合には、端末装置１は、当該楽曲を繰り返し再生しても良い、つまりループ再生しても良い。
他の例では、道路の走行時間が当該道路に関連付けられた楽曲の再生時間（１曲の再生時間）よりも長い場合には、端末装置１は、当該楽曲を繰り返し再生しても良い、つまりループ再生しても良い。
【0075】
更に他の例では、道路の走行時間が当該道路に関連付けられた楽曲の再生時間（１曲の再生時間）よりも長い場合には、端末装置１は、当該楽曲の再生が終了した際に、当該楽曲の次の楽曲を再生しても良い。その場合、サーバ装置２は、２曲以上の楽曲を道路に関連付けておき、２曲以上の楽曲についての楽曲データを端末装置１に送信すれば良い。
【0076】
更に他の例では、道路の走行時間が当該道路に関連付けられた楽曲の再生時間（１曲の再生時間）よりも短い場合には、端末装置１は、当該楽曲の再生を途中で停止することなく、当該楽曲を最後まで再生しても良い。つまり、再生中の楽曲の終端に至るまで再生しても良い。
【0077】
（変形例３）
他の例では、再生中の楽曲を即購入可能に端末装置１を構成しても良い。その場合、端末装置１に、購入用ＵＩ（User Interface）を具備させれば良い。
他の例では、再生中の楽曲を即購入可能に端末装置１を構成しても良い。その場合、端末装置１に、購入用ＵＩ（User Interface）を具備させれば良い。
【0078】
（変形例４）
他の例では、端末装置１で楽曲が再生された場合に、その旨を示す情報をサーバ装置２に送信しても良い。サーバ装置２は、そのように送信された情報に基づいて、楽曲の再生回数や視聴履歴や視聴率を得ることができる。
他の例では、端末装置１で楽曲が再生された場合に、その旨を示す情報をサーバ装置２に送信しても良い。サーバ装置２は、そのように送信された情報に基づいて、楽曲の再生回数や視聴履歴や視聴率を得ることができる。
【0079】
更に他の例では、楽曲を購入できるように端末装置１が構成されている場合には、端末装置１で楽曲が購入された場合に、その旨を示す情報をサーバ装置２に送信しても良い。サーバ装置２は、そのように送信された情報に基づいて、楽曲の購入回数や購入履歴や購入率を得ることができる。
【0080】
（変形例５）
他の例では、道路の走行時間に応じた再生時間を有する楽曲を、当該道路に関連付けると良い。その場合、渋滞などの種々の状況が加味されるように、道路の走行時間の統計情報に基づいて、再生時間を決めると良い。
他の例では、道路の走行時間に応じた再生時間を有する楽曲を、当該道路に関連付けると良い。その場合、渋滞などの種々の状況が加味されるように、道路の走行時間の統計情報に基づいて、再生時間を決めると良い。
【0081】
（変形例６）
上記した実施例では、端末装置１がマップマッチングを行っていたが、他の例では、端末装置１の代わりにサーバ装置２がマップマッチングを行っても良い。その場合には、サーバ装置２が、近隣道路についての複数の再生情報が有する道路ＩＤ及び道路データと、車両の現在位置及び進行方向とに基づいて、車両が走行中の道路の道路ＩＤを特定すれば良い。
上記した実施例では、端末装置１がマップマッチングを行っていたが、他の例では、端末装置１の代わりにサーバ装置２がマップマッチングを行っても良い。その場合には、サーバ装置２が、近隣道路についての複数の再生情報が有する道路ＩＤ及び道路データと、車両の現在位置及び進行方向とに基づいて、車両が走行中の道路の道路ＩＤを特定すれば良い。
【0082】
（変形例７）
上記した実施例では、進行方向に応じた楽曲を取得していたが、そのような進行方向を用いなくても良い。つまり、進行方向を考慮せずに、走行中の道路にのみ応じた楽曲を取得しても良い。その場合には、道路をどちらの方向に進む場合にも同一の楽曲が取得される。
上記した実施例では、進行方向に応じた楽曲を取得していたが、そのような進行方向を用いなくても良い。つまり、進行方向を考慮せずに、走行中の道路にのみ応じた楽曲を取得しても良い。その場合には、道路をどちらの方向に進む場合にも同一の楽曲が取得される。
【0083】
（変形例８）
上記した実施例では、１つのサーバ装置２のみを用いていたが（図１参照）、本発明は、複数のサーバ装置から成るサーバシステムにも適用可能である。その場合、再生情報を送信するサーバ装置と、楽曲データを送信するサーバ装置とを別にしても良い。
上記した実施例では、１つのサーバ装置２のみを用いていたが（図１参照）、本発明は、複数のサーバ装置から成るサーバシステムにも適用可能である。その場合、再生情報を送信するサーバ装置と、楽曲データを送信するサーバ装置とを別にしても良い。
【0084】
（変形例９）
本発明は、車両において利用される端末装置１への適用に限定はされない。つまり、車内で端末装置１が利用される場合に、本発明を適用することに限定はされない。例えば、本発明は、ユーザが歩行中に端末装置１（スマートフォンなどの携帯端末装置に相当する）を利用する場合にも適用可能である。その場合には、ユーザが歩行中の道路に関連付けられた楽曲を再生すれば良い。このようなことから、本発明における「移動体」には、車両だけでなく、歩行者も含まれるものとする。
本発明は、車両において利用される端末装置１への適用に限定はされない。つまり、車内で端末装置１が利用される場合に、本発明を適用することに限定はされない。例えば、本発明は、ユーザが歩行中に端末装置１（スマートフォンなどの携帯端末装置に相当する）を利用する場合にも適用可能である。その場合には、ユーザが歩行中の道路に関連付けられた楽曲を再生すれば良い。このようなことから、本発明における「移動体」には、車両だけでなく、歩行者も含まれるものとする。
【0085】
また、本発明は、一般的なＰＣ（Personal Computer）にも適用可能である。つまり、上記した端末装置１の代わりに、ＰＣ（タブレットＰＣなども含む）にも適用可能である。その場合、例えば、地図画面をＰＣに表示させ、地図画面上でユーザにより選択された道路に関連付けられた楽曲を再生すれば良い。
【0086】
（変形例１０）
本発明は、音楽（楽曲）への適用に限定はされず、種々のコンテンツに適用可能である。例えば、本発明は、動画のコンテンツにも適用可能である。
本発明は、音楽（楽曲）への適用に限定はされず、種々のコンテンツに適用可能である。例えば、本発明は、動画のコンテンツにも適用可能である。
【0087】
［２］第２実施例
次に、本発明の第２実施例について説明する。第２実施例は、ユーザの端末装置１と、サーバ装置２に加え、楽曲データを提供する配信業者（コンテンツプロバイダ）の配信業者端末３を含む楽曲配信システムである。
次に、本発明の第２実施例について説明する。第２実施例は、ユーザの端末装置１と、サーバ装置２に加え、楽曲データを提供する配信業者（コンテンツプロバイダ）の配信業者端末３を含む楽曲配信システムである。
【0088】
［システム構成］
図５は、第２実施例に係る楽曲配信システム５０の構成を示す。図示のように、楽曲配信システム５０は、端末装置１と、サーバ装置２と、配信業者端末３とを備える。端末装置１の構成は第１実施例と同様である。
図５は、第２実施例に係る楽曲配信システム５０の構成を示す。図示のように、楽曲配信システム５０は、端末装置１と、サーバ装置２と、配信業者端末３とを備える。端末装置１の構成は第１実施例と同様である。
【0089】
配信業者端末３は、配信業者がサーバ装置２に対して楽曲の配信条件を登録する際に使用する端末であり、通常のパーソナルコンピュータ（ＰＣ）などにより構成される。即ち、配信業者端末３は、図示しないＣＰＵ、ＲＯＭ、ＲＡＭ、入力装置、表示装置などを備え、ネットワークを介してサーバ装置２と通信する。
【0090】
サーバ装置２の構成は基本的に第１実施例と同様である。但し、図示のように、第２実施例のサーバ装置２は、記憶部２２内に各種のデータベース（以下、「データベース」を「ＤＢ」と記す。）を備える。具体的に、記憶部２２は、道路ＤＢ２２１、交通統計情報ＤＢ２２２、交通量情報ＤＢ２２３、課金情報ＤＢ２２４、配信管理ＤＢ２２５、楽曲ＤＢ２２６、楽曲メタデータＤＢ２２７を備える。
【0091】
道路ＤＢ２２１は、道路データ（地図データ）を記憶する。道路データは、道路ネットワークを構成するノード及びリンクのデータを含む。ノードは交差点に相当し、リンクは道路に相当する。
【0092】
交通統計情報ＤＢ２２２は、交通統計情報を記憶する。交通統計情報は、多数の車両から取得した走行情報（測位データ）に基づいて生成され、道路毎に、ユーザＩＤ、走行時刻、走行時間、進行方向などを対応付けた情報である。
【0093】
交通量情報ＤＢ２２３は、交通量情報を記憶する。交通量情報は、交通統計情報に基づいて生成され、道路毎に一定時間内の交通量を示す情報である。具体的に、交通量情報は、道路毎の一定時間内の車両の走行台数、ユーザ数、平均旅行時間などを含む。
【0094】
課金情報ＤＢ２２４は、課金情報として道路毎の配信料金を記憶する。配信料金は、ある道路において１つの楽曲をユーザに提供する際に、サーバ装置２の運営者が楽曲の配信業者に対して課金する料金を示す。配信料金は、道路の交通量などに基づいて決定されるが、その詳細は後述する。
【0095】
配信管理ＤＢ２２５は、各道路における楽曲の配信に関する情報、具体的には、配信条件情報と配信実績情報とを記憶する。配信条件情報は、道路毎に設定され、楽曲を配信する条件を示す情報である。例えば、配信条件情報は、ある道路について、配信の対象となる楽曲のＩＤ、その楽曲を配信する曜日、時間帯、天候などの条件を含む。一方、配信実績情報は、道路毎に、実際にその道路を移動した端末装置１に対する楽曲の配信履歴を示す情報である。例えば、配信実績情報は、ある道路において楽曲を配信した日時、回数、配信先の端末装置１のＩＤ又はユーザＩＤなどを含む。
【0096】
楽曲ＤＢ２２６は、楽曲データ、即ち楽曲自体の音楽データを記憶する。楽曲データは、楽曲の識別情報である楽曲ＩＤに対応付けて記憶されている。楽曲データは、例えばＷａｖｅ、ＭＰ３、ｍ４ａなどのデータ形式となっている。
【0097】
楽曲メタデータＤＢ２２７は、楽曲に関連するメタデータを記憶する。具体的にはメタデータは、楽曲のアーティスト名、ジャンル、アルバム名、トラック番号、トラックタイトル、ディスク番号、リリース年などを含む。
【0098】
上記の構成において、サーバ装置２の通信部２３は本発明の送信手段、受信手段の一例であり、制御部２１は本発明の記憶手段、登録手段、配信手段の一例である。
【0099】
［制御の概要］
次に、制御の概要について説明する。本実施例では、まず、サーバ装置２の運営者が道路毎に楽曲を配信する際に配信業者に課金する金額（配信料金）を決定する。この際、サーバ装置２は、多数の端末装置１から車両の走行情報（測位データ）を収集し、道路毎の交通量を算出する。そして、交通量を考慮した計算方法により、道路毎の配信料金を決定する。決定された配信料金は課金情報ＤＢ２２４に記憶される。
次に、制御の概要について説明する。本実施例では、まず、サーバ装置２の運営者が道路毎に楽曲を配信する際に配信業者に課金する金額（配信料金）を決定する。この際、サーバ装置２は、多数の端末装置１から車両の走行情報（測位データ）を収集し、道路毎の交通量を算出する。そして、交通量を考慮した計算方法により、道路毎の配信料金を決定する。決定された配信料金は課金情報ＤＢ２２４に記憶される。
【0100】
次に、配信業者が配信業者端末３を操作して、ユーザに配信すべき楽曲及びその楽曲のメタデータを登録する。楽曲及び楽曲メタデータは、それぞれサーバ装置２内の楽曲ＤＢ２２６及び楽曲メタデータＤＢ２２７に記憶される。
【0101】
次に、配信業者が配信業者端末３を操作してサーバ装置２に配信条件を登録する。具体的には、配信業者は道路毎にユーザに対して配信する楽曲を設定する。また、必要に応じて、その楽曲を配信する曜日、時間帯、天候などの条件も設定する。設定された配信条件は、サーバ２の配信管理ＤＢ２２５に記憶される。
【0102】
こうして楽曲を配信する準備が完了すると、端末装置１が道路を走行するたびに、その道路に対して設定された楽曲が配信される。よって、ユーザは、道路を走行するときに、道路毎に設定された楽曲を聞くことができる。なお、ここでの「配信」はいわゆるストリーミング配信を意味し、端末装置１はサーバ装置２から楽曲データを部分的に受信しつつ再生する。いわゆるダウンロード配信と異なり、再生が終了した際に楽曲データは端末装置１の記憶部には残らない。
【0103】
［処理フロー］
以下、各処理について詳しく説明する。
以下、各処理について詳しく説明する。
【0104】
（道路交通情報生成処理）
まず、道路交通情報生成処理について説明する。道路交通情報生成処理は、複数の端末装置１から収集した走行情報（測位データ）に基づいて、道路交通情報を生成する処理である。道路交通情報生成処理は、測位データ記録処理と、データ通信処理と、交通情報生成処理とを含む。
まず、道路交通情報生成処理について説明する。道路交通情報生成処理は、複数の端末装置１から収集した走行情報（測位データ）に基づいて、道路交通情報を生成する処理である。道路交通情報生成処理は、測位データ記録処理と、データ通信処理と、交通情報生成処理とを含む。
【0105】
図６は、測位データ記録処理、データ通信処理及び交通情報生成処理のフローチャートである。これらの処理は、端末装置１とサーバ装置２とにより実行される。具体的には、端末装置１の制御部１１及びサーバ装置２の制御部２１がそれぞれ予め用意されたプログラムを実行することにより実現される。
【0106】
まず、端末装置１は、測位データ記録処理を行う。端末装置１は、ＧＰＳ受信機１４及び自立測位装置１５の出力に基づいて現在位置を含む測位データを生成し、内部の記憶部１２に記憶する（ステップＳ１３１）。具体的には、端末装置１は、一定時間毎に、測位データとして、車両の現在位置の緯度・経度、進行方向、現在時刻を記憶する。次に、端末装置１は、記録停止条件が成立したか否かを判定する（ステップＳ１３２）。記録停止条件とは、例えば車両が停止した場合などである。端末装置１は、記録停止条件が成立するまで測位データの記録を継続し、記録停止条件が成立すると（ステップＳ１３２：Ｙｅｓ）、測位データ記録処理を終了する。
【0107】
次に、端末装置１及びサーバ装置２は、データ通信処理を行う。まず、端末装置１は、測位データ記録処理で記憶部１２に記憶した測位データを読み出し、端末装置１のユーザＩＤとともにサーバ装置２へ送信する（ステップＳ１３３）。サーバ装置２は、端末装置１から測位データを受信し、記憶部２２に一時保存する（ステップＳ２３１）。これで、データ通信処理は終了する。
【0108】
次に、サーバ装置２は、交通情報生成処理を行う。まず、サーバ装置２は、一時保存した測位データと道路データとを用いてリンクのマッチングを行う（ステップＳ２３２）。即ち、サーバ装置２は、道路ＤＢ２２１を参照し、測位データに含まれる緯度・経度、進行方向に基づいて、測位データが示す道路及び進行方向を特定する。サーバ装置２は、複数の端末装置１から取得した多数の測位データに対してこの処理を行う。そして、サーバ装置２は、ステップＳ２３２の処理結果に基づいて、道路毎に、端末装置１のユーザＩＤ、走行時刻、走行時間、進行方向を計算し、これらを交通統計情報として交通統計情報ＤＢ２２２に保存する（ステップＳ２３３）。これで、交通情報生成処理は終了する。交通情報生成処理により、多数の車両に搭載された端末装置１からの測位データに基づいて、道路毎の交通統計情報が得られる。具体的には、ある時刻における道路毎の交通量（走行車両の数）、進行方向、走行速度などが得られる。
【0109】
（配信料計算処理）
次に、配信料計算処理について説明する。配信料計算処理は、交通量などに基づいて、道路毎に楽曲の配信料金を決定する処理である。配信料計算処理は、交通量計算処理と配信料金計算処理とを含む。
次に、配信料計算処理について説明する。配信料計算処理は、交通量などに基づいて、道路毎に楽曲の配信料金を決定する処理である。配信料計算処理は、交通量計算処理と配信料金計算処理とを含む。
【0110】
図７は、交通量計算処理及び配信料金計算処理のフローチャートである。これらの処理は、サーバ装置２により行われる。具体的には、サーバ装置２の制御部２１が予め用意されたプログラムを実行することにより実現される。
【0111】
まず、サーバ装置２は、交通統計情報ＤＢ２２２から交通統計情報を読出し、道路毎に一定期間毎の交通量を計算する（ステップＳ２４１）。具体的には、サーバ装置２は、交通量として、走行台数、ユーザ数、平均旅行時間（平均速度）などを算出する。そして、サーバ装置２は、算出した交通量を交通量情報ＤＢ２２３に保存する（ステップＳ２４２）。これで、交通量計算処理は終了する。
【0112】
次に、サーバ装置２は、配信料金計算処理を行う。サーバ装置２は、交通量情報ＤＢ２２３から交通量を読出し、道路毎に配信料金を計算する（ステップＳ２４３）。サーバ装置２は、交通量及び配信対象となるユーザ数の期待値などを考慮して、道路リンク及び進行方向毎に配信料金を決定する。具体的には、サーバ装置２は、以下の式（１）により配信料金を計算する。
【0113】
【数1】
【0114】
配信料金「Ｃｉ」は、道路（リンク）毎、かつ、進行方向毎に設定される。基本割引率「ａ」は、各種の理由により、配信業者毎、リンク毎、エリア毎に適用されるものである。ａ＝１の場合には割引なしであり、ａ＜１の場合は配信料金が減額となり、ａ＞１の場合は配信料金が増額となる。例えば、あるエリアの配信料金を標準配信料金より高くする場合にはａ＞１とし、安くする場合にはａ＜１とする。
【0115】
単位時間当たりの交通量「Ｔｉ」は、交通量情報ＤＢ２２３に保存されている道路毎の交通量が使用される。単位交通量当たりの料金「Ｖ」は、交通量当りの単位料金であり、例えば「Ｘ円／１００台」というように設定される。固定費「Ｂｃ」は、楽曲配信システムを運用するための基本コストに相当し、基本的に定額に設定される。
【0116】
成功報酬額「α」は、実際に楽曲を配信した実績に基づいて配信業者からサーバ装置２の運営者に支払われるインセンティブに相当する金額である。成功報酬額「α」は、例えば、実際の配信実績（配信した曲数、配信対象となったユーザ数又は端末数）が所定数を超えた場合に、一定金額又は１曲毎に設定された金額とすることができる。
【0117】
サーバ装置２は、こうして計算した配信料金を、道路毎かつ進行方向毎に課金情報ＤＢに保存する（ステップＳ２４４）。これで、配信料金計算処理は終了する。配信料金計算処理により、道路毎かつ進行方向毎に楽曲の配信料金が決定され、課金情報ＤＢ２２４に用意された状態となる。
【0118】
（配信受注処理）
次に、配信受注処理について説明する。配信受注処理は、配信業者が配信の対象となる楽曲及びその配信対象となる道路や配信条件を設定する処理である。配信受注処理は、配信曲登録処理と配信対象指定処理とを含む。
次に、配信受注処理について説明する。配信受注処理は、配信業者が配信の対象となる楽曲及びその配信対象となる道路や配信条件を設定する処理である。配信受注処理は、配信曲登録処理と配信対象指定処理とを含む。
【0119】
図６は、配信曲登録処理のフローチャートである。この処理は、配信業者端末３及びサーバ装置２により実行される。具体的には、配信業者端末３のＣＰＵなどと、サーバ装置２の制御部２１がそれぞれ予め用意されたプログラムを実行することにより実現される。
【0120】
まず、配信業者が配信業者端末３を操作して配信の対象とする楽曲を選択すると、配信業者端末３はその選択を受け取り、内部のデータベースなどから楽曲データを取得する（ステップＳ３１１）。次に、配信業者端末３は、内部のデータベースなどから、選択された楽曲のメタデータを取得する（ステップＳ３１２）。そして、配信業者端末３は、取得した楽曲データ及びメタデータをサーバ装置２へ送信する（ステップＳ３１３）。
【0121】
サーバ装置２は、配信業者端末３から楽曲データ及びメタデータを受信し（ステップＳ２５１）、それぞれ楽曲データＤＢ２２６及び楽曲メタデータＤＢ２２７に保存する（ステップＳ２５２）。これで、配信曲登録処理が終了する。配信曲登録処理により、配信対象とする楽曲の楽曲データ及びメタデータがサーバ装置２のデータベースに登録される。
【0122】
図９は、配信対象指定処理のフローチャートである。この処理も、配信業者端末３及びサーバ装置２により実行される。
【0123】
まず、配信業者は配信業者端末３を操作して、配信対象を指定するための問い合わせを行う（ステップＳ３２１）。例えば、配信業者は、配信業者端末３でＷｅｂ上のオンラインクライアントシステムにアクセスし、問い合わせを行う。問い合わせの際、配信業者は、配信する楽曲を示す楽曲ＩＤに加えて、配信料金、位置（エリア又は道路リンク）、進行方向、期待される配信回数（配信対象のユーザ数）などの検索条件を指定する。即ち、配信業者は、ある楽曲を配信する際に好適と考えられる条件を問い合わせに含めて送信する。
【0124】
サーバ装置２は、課金情報ＤＢ２２４、地図データＤＢ２２１、配信管理ＤＢ２２５などを参照して、問い合わせに含まれる検索条件に合致する道路（リンク）を検索し、その検索結果として問い合わせに合致する道路の一覧を配信業者端末３へ送信する（ステップＳ２６２）。例えば、配信業者が配信料金を指定した場合、指定された配信料金で楽曲を配信できる道路の一覧が提供される。また、配信業者が期待される配信回数を指定した場合、配信管理ＤＢ２２５に記憶されている配信実績に基づいて、指定された配信回数が期待できる道路の一覧が配信業者に提供される。よって、配信業者は様々な観点から、配信対象とすべき道路を検索することが可能となる。
【0125】
配信業者が受信した一覧を見て配信対象とする道路を指定すると、配信業者端末３はその道路の指定をサーバ装置２へ送信する（ステップＳ３２３）。サーバ装置２は、配信業者端末３から配信対象とする道路の指定を受信し（ステップＳ２６３）、配信管理ＤＢ２２５に保存する（ステップＳ２６４）。これで、配信対象指定処理は終了する。
【0126】
こうして、配信対象指定処理により、道路毎及び進行方向毎に配信される楽曲が設定される。なお、配信業者は、配信対象を指定する際に、配信条件としてさらに曜日、時間帯、天候、道路状況などを指定しても良い。これらは、その楽曲の配信条件として配信管理ＤＢ２２５に記憶される。例えば配信業者は特定の道路における楽曲の配信について、土曜日・日曜日のみ、昼間のみ、晴れの日のみ、渋滞が発生していない場合、などの配信条件を設定することができる。
【0127】
（楽曲配信処理）
次に、楽曲配信処理について説明する。楽曲配信処理は、端末装置１が道路を走行している際に、端末装置１からの要求に応じて、サーバ装置２がその道路に対して設定されている楽曲を配信する処理である。
次に、楽曲配信処理について説明する。楽曲配信処理は、端末装置１が道路を走行している際に、端末装置１からの要求に応じて、サーバ装置２がその道路に対して設定されている楽曲を配信する処理である。
【0128】
図１０は、楽曲配信処理のフローチャートである。この処理は、端末装置１及びサーバ装置２により実行される。具体的には、端末装置１の制御部１１及びサーバ装置２の制御部２１が、予め用意されたプログラムを実行することにより実現される。
【0129】
まず、端末装置１は、車両の現在位置を示す測位データを取得し、その測位データを含めた楽曲配信要求をサーバ装置２に送信する（ステップＳ１４１）。サーバ装置２は、端末装置１から楽曲配信要求を受信し、測位データに基づいて道路ＤＢ２２１を参照して車両が現在走行している道路（リンク）を判定する（ステップＳ２７１）。次に、サーバ装置２は、配信管理ＤＢ２２５を参照して、車両が走行している道路に対して設定されている楽曲を決定し（ステップＳ２７２）、楽曲データ及びメタデータをそれぞれ楽曲ＤＢ２２６、楽曲メタデータＤＢ２２７から取得し（ステップＳ２７３）、それらを端末装置１へ配信する（ステップＳ２７４）。
【0130】
端末装置１は、サーバ装置２から楽曲データ及びメタデータを受信し、楽曲を再生する（ステップＳ１４２）。この際、端末装置１は、受信したメタデータに基づいて、曲名、アーティスト名などを表示する。次に、端末装置１は、再生が停止したか否かを判定する（ステップＳ１４３）。再生が停止する場合とは、例えば端末装置１のユーザが音楽再生を停止した場合などである。再生が停止された場合（ステップＳ１４３：Ｙｅｓ）、楽曲配信処理は終了する。一方、再生が停止されていない場合（ステップＳ１４３：Ｎｏ）、処理はステップＳ１４１へ戻る。そして、端末装置１は、走行している道路が変わった場合、例えば交差点を通過した場合などに、新たに測位データをサーバ装置へ送信する（ステップＳ１４１）。こうして、ユーザが再生を停止しない限り、測位データがサーバ装置２へ送信され、走行中の道路に対応する楽曲が端末装置１により再生される。
【0131】
また、サーバ装置２は、ステップＳ２７４で端末装置１へ楽曲データ及びメタデータを配信すると、その履歴を配信実績情報として配信管理ＤＢ２２５に保存する（ステップＳ２７５）。具体的には、サーバ装置２は、楽曲及びメタデータを送信した日時、道路に対応するリンクＩＤ、送信した楽曲の楽曲ＩＤ、送信先の端末装置１のＩＤ又はユーザＩＤなどを配信実績情報として配信管理ＤＢ２２５に保存する。これにより、サーバ装置２は実際の配信実績情報を蓄積しておくことができる。
【0132】
なお、楽曲が配信されている状態において、端末装置１のユーザがその楽曲を気に入った場合には、その楽曲を購入できるようにすることが好ましい。例えば、ユーザが端末装置１を操作して購入の指示を入力すると、それがサーバ装置２へ送信される。サーバ装置２は代金の決済処理の終了後、楽曲データを端末装置１へ送信（ダウンロード配信）する。これにより、ユーザは楽曲データを購入し、端末装置１に保存することができる。
【0133】
［変形例］
以下に好適な変形例を示す。なお、下記の変形例は、任意に組み合わせて実施例に適用することができる。
以下に好適な変形例を示す。なお、下記の変形例は、任意に組み合わせて実施例に適用することができる。
【0134】
（変形例１）
上記の実施例では、楽曲を道路（リンク）に対応付けて登録しておき、端末装置１を搭載した車両がその道路を走行しているときに楽曲を配信している。この場合、道路の幅の範囲のみでなく、その道路を中心とする所定幅の範囲に対して楽曲を対応付けておいてもよい。例えば、道路の中心から道路に垂直な方向に１００ｍの幅を有するエリアに楽曲を対応付けておく。この場合、例えば車両が道路沿いの施設に入った場合など、車両が道路上から多少外れた場合でも楽曲の配信を継続することができる。
上記の実施例では、楽曲を道路（リンク）に対応付けて登録しておき、端末装置１を搭載した車両がその道路を走行しているときに楽曲を配信している。この場合、道路の幅の範囲のみでなく、その道路を中心とする所定幅の範囲に対して楽曲を対応付けておいてもよい。例えば、道路の中心から道路に垂直な方向に１００ｍの幅を有するエリアに楽曲を対応付けておく。この場合、例えば車両が道路沿いの施設に入った場合など、車両が道路上から多少外れた場合でも楽曲の配信を継続することができる。
【0135】
また、上記の実施例では楽曲を道路（リンク）に対応付けているが、その代わりに、又は、それに加えて、楽曲を交差点（ノード）や施設などに対応付けて登録してもよい。具体的には、交差点に対応するノードや特定の施設を含む所定範囲のエリア（例えば、半径２００ｍの範囲など）に対して楽曲を対応付けてもよい。この場合、端末装置１を搭載した車両がそのエリア内に入ったときに、楽曲が再生される。
【0136】
また、上記の実施例では、楽曲を道路ネットワーク上の道路に対応付けているが、本発明を鉄道ネットワークに適用することもできる。この場合、鉄道ネットワークにおける駅をノード、駅間の線路をリンクとみなして、駅や駅間の線路に対して楽曲を対応付けて配信することができる。また、全ての駅間の線路を別個のリンクとするのではなく、所定の駅間を１つのリンクとするようにリンクを定義することもできる。例えば、山手線全体を１つのリンクとするとか、新幹線の東京から新横浜の間を１つのリンクとしてもよい。なお、この場合にも、駅についてはその周辺の所定距離（例えば半径２００ｍ以内）、駅間については線路から所定距離（例えば１００ｍ以内）の広がりを持ったエリアに楽曲を対応付けるのが好ましい。
【0137】
（変形例２）
上記の実施例では、楽曲の配信料金は式（１）に基づいて決定されているが、さらに様々情報に基づいて配信料の調整が可能である。
上記の実施例では、楽曲の配信料金は式（１）に基づいて決定されているが、さらに様々情報に基づいて配信料の調整が可能である。
【0138】
まず、時間帯によって配信料を変化させてもよい。例えば、１日を夜間と昼間に分類して配信料金を変えたり、１時間又は３０分毎に異なる配信料金を設定したりしてもよい。この場合には、式（１）における割引率として時間帯割引率「ａ１」を導入し、時間帯割引率「ａ１」を基本割引率「ａ」に乗算して配信料金を算出すればよい。
【0139】
また、交通量情報に基づいて、交通量ごとに１日を複数の時間帯に分類し、各時間帯毎に配信料金を変えてもよい。例えば、交通統計情報に基づいて、１日を交通量が多い時間帯、普通の時間帯、少ない時間帯の３つの時間帯に分類し、それらに異なる配信料金を設定してもよい。この場合には、式（１）における割引率として交通量割引率「ａ２」を導入し、交通量の多少による時間帯分類ごとに異なる交通量割引率「ａ２」を基本割引率「ａ」に乗算して配信料金を計算すればよい。なお、交通統計情報を分析し、交通量に基づいて時間帯を分類する処理は、例えばｋ－ｍｉｎｓ法などの既知のクラスタリング手法を適用した自動計算により行うことができる。
【0140】
また、実際の交通状況に基づいて配信料金を変化させてもよい。具体的には、交通統計情報に基づいて、道路リンク１本の走行に要する時間（通過に要する時間）、停車時間、信号待ち時間などによって配信料金を変えてもよい。これにより、例えば通過に要する時間が長い道路リンクは、楽曲の再生に適しているとして配信料金を増額することができる。また、停車している車両が多い道路リンクは、端末装置１を操作してその楽曲の購入操作を行う時間的余裕があり、楽曲の購入につながりやすいとして、配信料金を増額することもできる。この場合には、式（１）における割引率として交通状況割引率「ａ３」を導入し、交通状況割引率「ａ３」を基本割引率「ａ」に乗算して配信料金を算出すればよい。
【0141】
さらには、当日の天候に応じて配信料金を変化させてもよい。例えば雨の日には配信料金を安くしてもよいし、晴天の日は配信料金を高くしてもよい。この場合には、式（１）における割引率として天候況割引率「ａ４」を導入し、天候割引率「ａ４」を基本割引率「ａ」に乗算して配信料金を算出すればよい。
【0142】
（変形例３）
１つの道路リンクに複数の楽曲を対応付けても良い。その場合には、複数の楽曲の再生優先度を定義する。例えば、１つの道路リンクについて、優先度１位で曲Ａ、優先度２位で曲Ｂ、優先度３位で曲Ｃを対応付ける。この場合、端末装置１がその道路リンクに入って楽曲を要求すると、まず曲Ａが配信され、まだ時間があればさらに曲Ｂが配信され、さらに時間があれば曲Ｃが配信される。
１つの道路リンクに複数の楽曲を対応付けても良い。その場合には、複数の楽曲の再生優先度を定義する。例えば、１つの道路リンクについて、優先度１位で曲Ａ、優先度２位で曲Ｂ、優先度３位で曲Ｃを対応付ける。この場合、端末装置１がその道路リンクに入って楽曲を要求すると、まず曲Ａが配信され、まだ時間があればさらに曲Ｂが配信され、さらに時間があれば曲Ｃが配信される。
【0143】
このように再生優先度を導入した場合には、楽曲の配信料金に再生優先度を反映させることが好ましい。即ち、再生優先度が高いほど、配信業者が支払う配信料金が高くなるようにする。これにより、配信業者は、優先的に配信したい楽曲については、高い配信料金を支払って再生優先度を高くすることができる。この場合には、式（１）における割引率として再生優先度割引率「ａ５」を導入し、再生優先度割引率「ａ５」を基本割引率ａに乗算して配信料金を算出すればよい。例えば、再生優先度が１位の楽曲の再生優先度割引率「ａ５＝１．２」として、配信料金を２０％増しとしてもよい。
【0144】
（変形例４）
上記の実施例において、式（１）における成功報酬額αは、基本的に全ユーザに対して同様に適用されるものとなっている。即ち、全ての端末装置１に対する配信実績（曲数、ユーザ数、端末数）に応じて成功報酬額αを決定している。その代わりに、配信した楽曲をユーザが購入した数（購入楽曲数）に基づいて成功報酬額αを決定してもよい。また、特定の属性のユーザ（年齢、性別など）に限定して配信実績を集計し、その配信実績に基づいて成功報酬額αを決定しても良い。
上記の実施例において、式（１）における成功報酬額αは、基本的に全ユーザに対して同様に適用されるものとなっている。即ち、全ての端末装置１に対する配信実績（曲数、ユーザ数、端末数）に応じて成功報酬額αを決定している。その代わりに、配信した楽曲をユーザが購入した数（購入楽曲数）に基づいて成功報酬額αを決定してもよい。また、特定の属性のユーザ（年齢、性別など）に限定して配信実績を集計し、その配信実績に基づいて成功報酬額αを決定しても良い。
【0145】
（変形例５）
上記の実施例では、サーバ装置は楽曲データと楽曲のメタデータを配信しているが、これに加えて、その楽曲の他の関連情報を同時に配信してもよい。例えば、未発売の楽曲についての発売予定日、類似する楽曲、おすすめの楽曲などの情報を同時に配信してもよい。
上記の実施例では、サーバ装置は楽曲データと楽曲のメタデータを配信しているが、これに加えて、その楽曲の他の関連情報を同時に配信してもよい。例えば、未発売の楽曲についての発売予定日、類似する楽曲、おすすめの楽曲などの情報を同時に配信してもよい。
【0146】
（変形例６）
上記の実施例では、サーバ装置２は端末装置１から受信した測位データに基づいて交通統計情報及び交通量を算出しているが、サーバ装置２は外部サーバなどから交通統計情報や交通量情報を取得し、それらを用いて配信料金を決定しても良い。
上記の実施例では、サーバ装置２は端末装置１から受信した測位データに基づいて交通統計情報及び交通量を算出しているが、サーバ装置２は外部サーバなどから交通統計情報や交通量情報を取得し、それらを用いて配信料金を決定しても良い。
【0147】
（変形例７）
本発明は、音楽（楽曲）への適用に限定はされず、種々のコンテンツに適用可能である。例えば、本発明は、動画のコンテンツにも適用可能である。
本発明は、音楽（楽曲）への適用に限定はされず、種々のコンテンツに適用可能である。例えば、本発明は、動画のコンテンツにも適用可能である。
【符号の説明】
【0148】
１ 端末装置
２ サーバ装置
３ 配信業者端末
１１、２１ 制御部
１２、２２ 記憶部
１３、２３ 通信部
１４ ＧＰＳ受信機
１５ 自立測位装置
１６ 表示部
１７ スピーカ
１０、５０ 楽曲配信システム
２２２ 交通統計情報ＤＢ
２２３ 交通情報ＤＢ
２２４ 課金情報ＤＢ
２２５ 配信管理ＤＢ
２ サーバ装置
３ 配信業者端末
１１、２１ 制御部
１２、２２ 記憶部
１３、２３ 通信部
１４ ＧＰＳ受信機
１５ 自立測位装置
１６ 表示部
１７ スピーカ
１０、５０ 楽曲配信システム
２２２ 交通統計情報ＤＢ
２２３ 交通情報ＤＢ
２２４ 課金情報ＤＢ
２２５ 配信管理ＤＢ
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】