音楽概念データ処理方法及び映像表示装置及び音楽概念データ処理サーバ
【課題】本発明では、音楽の概念或いは印象を地域映像により密接に関連付けることができる音楽概念データ処理方法及び映像表示装置及び音楽概念データ処理サーバを提供する。
【解決手段】本発明の一実施例は、データファイルには、それぞれ映像提供地域を示す複数の目的地情報と前記複数の目的地情報の中の１つ又は複数に関連付けされており、かつ楽曲の概念を表す複数の語彙分類ノード情報とを含む概念グラフのデータを格納する。検索部により、再生用として選択された楽曲の概念を表す楽曲概念情報と類似又は同一意味の語彙分類ノード情報を前記複数の語彙分類ノード情報中から検索し、検索した語彙分類ノード情報に対応するヒット目的地情報を前記複数の目的地情報の中から抽出し、かつ前記楽曲用概念情報を変更して複数回前記検索を実行して、前記選択された楽曲に関連性の高い１つ又は複数のヒット目的地情報を取得し、前記１つ又は複数のヒット目的地情報を対応する目的地の映像取得用として出力する。
【解決手段】本発明の一実施例は、データファイルには、それぞれ映像提供地域を示す複数の目的地情報と前記複数の目的地情報の中の１つ又は複数に関連付けされており、かつ楽曲の概念を表す複数の語彙分類ノード情報とを含む概念グラフのデータを格納する。検索部により、再生用として選択された楽曲の概念を表す楽曲概念情報と類似又は同一意味の語彙分類ノード情報を前記複数の語彙分類ノード情報中から検索し、検索した語彙分類ノード情報に対応するヒット目的地情報を前記複数の目的地情報の中から抽出し、かつ前記楽曲用概念情報を変更して複数回前記検索を実行して、前記選択された楽曲に関連性の高い１つ又は複数のヒット目的地情報を取得し、前記１つ又は複数のヒット目的地情報を対応する目的地の映像取得用として出力する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、音楽概念データ処理方法及び映像表示装置及び音楽概念データ処理サーバに関するもので、音楽の概念或いは印象を地域映像に関連付けることができる装置である。
【背景技術】
【０００２】
ユーザ端末装置から、出発地と目的地を入力すると、ネットワーク上にあるサイトの情報、コンテンツサーバのコンテンツ、ライブカメラのライブ映像を取得できる技術がある。このシステムでは、ユーザは表示部に表示される画像等のコンテンツを閲覧しつつ、自宅等に居ながらにして旅行に出たかのような擬似旅行を体験することができる（例えば特許文献１）。
【０００３】
またカラオケシステムにおいて、楽曲データがジャンル分けされており、ネットワークに接続されたライブカメラも複数の場所にジャンル分けされて設置されているものがある（特許文献２）。このカラオケシステムでは、顧客が楽曲を選択すると、その楽曲にあったライブカメラ映像が送信されてくる。送信されてきた映像は、カラオケ用の映像として表示部に背景表示される。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００７−１５６５６２号公報
【特許文献２】特開２００２−２９７１６７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
音楽とライブ映像を関連付ける場合、さらに的確で欲しいという要望がある。また音楽とライブ映像を関連付が固定ではなく、自動的な更新・変更が可能であり、融通性をもって実行されて欲しいという要望もある。
【０００６】
そこでこの発明の一実施例は、音楽の概念或いは印象を地域映像により密接に関連付けることができる音楽概念データ処理方法及び映像表示装置及び音楽概念データ処理サーバを提供することを目的とする。
【課題を解決するための手段】
【０００７】
上記の課題を解決するために、本発明の一実施例は、データファイルと検索部を有し、
前記データファイルには、それぞれ映像提供地域を示す複数の目的地情報と前記複数の目的地情報の中の１つ又は複数に関連付けされており、かつ楽曲の概念を表す複数の語彙分類ノード情報とを含む概念グラフのデータを格納しておき、
前記検索部では、再生用として選択された楽曲の概念を表す楽曲概念情報と類似又は同一意味の語彙分類ノード情報を前記複数の語彙分類ノード情報中から検索し、検索した語彙分類ノード情報に対応するヒット目的地情報を前記複数の目的地情報の中から抽出し、かつ前記楽曲用概念情報を変更して複数回前記検索を実行して、前記選択された楽曲に関連性の高い１つ又は複数のヒット目的地情報を取得し、前記１つ又は複数のヒット目的地情報を対応する目的地の映像取得用として出力することを特徴とする。
【発明の効果】
【０００８】
上記した処理により本発明は音楽の概念或いは印象を地域映像により密接に関連付けることができるという効果を奏する。
【図面の簡単な説明】
【０００９】
【図１】本発明に係る一実施例の装置を示すブロック図である。
【図２】本発明で用いられる音楽データ管理テーブルの例を示す図クである。
【図３】本発明で用いられるライブカメラ管理テーブルの例を示す図である。
【図４】本発明で用いられる概念グラフの例を示す図である。
【図５】本発明で用いられる概念グラフのデータ構造の例を示す図である。
【図６】本発明で用いられるライブカメラ表示設定ＧＵＩの例を示す図である。
【図７】本発明で用いられる楽曲選択画面の例を示す図である。
【図８】本発明で用いられるライブカメラ管理テーブルの作成フローの例を示す図である。
【図９】本発明で用いられる概念グラフ検索フローの例を示す図である。
【図１０】ジャンルによる概念グラフの検索例を示す図である。
【図１１】キーワードによる概念グラフの検索例１を示す図である。
【図１２】キーワードによる概念グラフの検索例２を示す図である。
【図１３】ライブカメラ管理テーブルへのデータの格納例１を示す図である。
【図１４】ライブカメラ管理テーブルへのデータの格納例２を示す図である。
【図１５】完成したライブカメラ管理テーブルの例を示す図である。
【図１６】ライブカメラ表示フローの例を示す図である。
【図１７】本発明の装置の利用シーンの例を示す図である。
【図１８】本発明に係る他の実施例であり、サーバーの構成を示すブロック図である。
【発明を実施するための形態】
【００１０】
以下、本発明の実施の形態について、詳細に説明する。図１は本発明が適用された映像表示装置の構成例を示す。アンテナ１は、チューナ部２に接続されており地上デジタル放送を受信する。チューナ部２は、テレビ放送を受信・選局する部分である。本実施例では、デジタル放送を受信して、受信チャンネルの信号を一旦IF（中間周波数）信号に変換する装置である。デジタル復調部３は、IF信号からデジタル信号（TS：トランスポートストリーム）を取り出し、MPEG処理部４へ送る。MPEG処理部４は、デジタル復調部３あるいは通信部１５から送られたトランスポートストリームを処理し、映像/音声のデコードを行う。デコードされた映像データはLCD（液晶装置）制御部６へ渡す。また、音声データは音声出力部７へ渡すことで、音声を再生する。
【００１１】
超解像処理部５は、MPEG処理部４に接続されており、デジタル化の際に失われた信号を復元し、映像の画素を増やすことで映像の解像度を高める処理を行う部分である。通常、地上デジタル放送の解像度1440×1080を、フル・ハイ・ディフィニション（HD）画質の解像度1920×1080へアップコンバートするために用いるが、本実施例ではテレビ放送の解像度よりもはるかに劣るライブカメラ映像の画質を、フルHD画質へアップコンバートするために利用している。
【００１２】
LCD制御部６は、超解像処理部５に接続されており、映像データをフルHD画質の液晶ディスプレイ７（以下LCDディスプレイ７）へ送り、画像を表示する。
【００１３】
LCDディスプレイ７は、ＬＣＤ制御部６に接続されており、ＭＰＥＧ処理部４がデコードし、超解像処理部５がアップコンバートした映像データを表示する。すなわち、地上デジタル放送の番組とライブカメラ映像を表示するディスプレイである。
【００１４】
音声出力部８はスピーカー９に接続され、ＭＰＥＧ処理部４と音楽再生部１３が出力した音声データをスピーカー９に出力する。すなわち、音声出力部８は、地上デジタル放送の音声、あるいは、音楽再生時の楽曲のいずれかを出力する。スピーカー９は音声出力部８に接続されており、音声あるいは楽曲を出力する。
【００１５】
システム制御部１０は、本発明の各処理部の動作を統括的に制御するための処理部である。制御部１０は、図として明示していないが、制御プログラムを格納するROMと、後述の処理の作業領域として必要となるRAMと、ライブカメラ設定などを記憶する不揮発性メモリ（フラッシュメモリ）を備えている。
【００１６】
操作部１１はリモートコントローラ（以下リモコンと略称）１２からの制御コマンドを受信し、システム制御部１０に送る。リモコン１２は、本発明の操作をするための装置であり、操作部１１に対して赤外線を利用した無線通信で制御コマンドを与える。リモコン１２には、数字を入力するためのテンキーが設けられており、チャンネル番号の入力を可能としている。また、リモコン１２には、十字キーが設けられており、楽曲リストの選択や設定項目の選択などのＧＵＩ（Graphical User Interface）操作を可能としている。
【００１７】
実施例では、ライブカメラ映像の切り替えの有無や、ライブカメラ映像の自動切換え間隔の指定といったシステムの設定と、音楽を再生する際に、アルバムや楽曲を選択するために使用する。
【００１８】
HDD制御部１３は、記憶部１４に接続し、記憶部１４のデータ（映像データ、音楽データ、システムデータ）の読み書きを制御する。記憶部１４はハードディスクドライブ（HDD）である。例えば、MPEG形式の映像データ、MP3形式の音楽データ、システムデータを格納する。
【００１９】
システムデータとは、例えば、音楽データ管理テーブル（図２参照）、ライブカメラ映像制御部２２が利用するライブカメラ管理テーブル（図３参照）、検索式生成部２０が使用する概念グラフ（図４参照）等のデータである。
【００２０】
音楽データ管理テーブル（図２）は、公知の技術である「gracenoteのCDDB」に登録されているアルバム名、アーティスト名、ジャンルなどの楽曲データを格納するテーブルである。
【００２１】
ライブカメラ管理テーブル（図３）は、リーフノードのカウンタ（Cnt：後述）、ライブカメラの優先順位（order）、ライブカメラの表示時間（time）、ライブカメラが設置された場所（location）、ライブカメラのURLを格納するテーブルである。
【００２２】
概念グラフ（図４）は、概念同士の相互関係をグラフ構造で定義したものであり、実施例では、「音楽ジャンル」及び「キーワード」と「場所（リーフノード）」を関連付けるために用いる。例えば、「ロックフェラーセンターのクリスマスツリー」が一般的に有名であれば、「クリスマスツリー」とロックフェラーセンターのある「ニューヨーク」をグラフ構造で結びつける。
【００２３】
つまり、概念グラフには、映像提供地域を示す複数の目的地情報（ローマ、ウィーン、ニューヨーク、パリ、ロッキー、スイスアルプス、モンブラン、マウントクック、ワイキキ、バリ島等）が含まれる。また、複数の目的地情報の中の１つ又は複数に関連付けされており、かつ楽曲の概念を表す複数の語彙分類ノード情報（雪、クリスマス、クラシック、ジャズ、イルミネーション、クリスマスツリー、スノーボード、スキー、サーフィンなど）が含まれる。
【００２４】
図５に概念グラフのデータ構造の例を示す。カウンタ（Cnt）は、実施例においては、リーフノードで有効な領域で、ジャンルあるいはキーワードに対応する中間ノードから、図４の概念グラフを下方追跡したときに、リーフノード（目的地情報）に到達した回数を保持するために使用する。この回数が大きい場所（リーフノード）ほど、再生中の楽曲と関連が強い場所となり、ライブカメラの表示優先順位（order）が高くなる。
【００２５】
本装置では、再生用の楽曲が選択されると、楽曲の概念を表す楽曲概念情報と類似又は同一意味の語彙分類ノード情報が複数の語彙分類ノード情報中から検索される。そして、検索した語彙分類ノード情報に対応するヒット目的地情報が複数の目的地情報の中から抽出される。さらに楽曲概念情報を変更（タイトルや解説に含まれる用語、例えば図４のサーフィンをビーチに対応する用語に変更）して複数回前記検索を実行すると、選択された楽曲に関連性の高い１つ又は複数のヒット目的地情報（ワイキキ、バリ島などの地名、地域の名称）を取得することができる。１つ又は複数のヒット目的地情報が特定されると、この情報が検索エンジン１７に送信され、対応する目的地の映像取得用として、ライブカメラのURLを取得することができる。ライブカメラのURLは、図３のライブカメラ管理テーブルに格納される。
【００２６】
なお、実施例では、記憶部１４にハードディスクを使用しているが、例えば、SSD(Solid State Drive)といった他の記憶媒体を利用しても、もちろん構わない。
【００２７】
通信部１５は、インターネットに接続するためのネットワークアダプタである。実施例では、通信部１５を通じてインターネット１６に接続して、検索エンジン１７によりライブカメラ映像を検索し、また、ライブカメラ映像のストリームを受信する。
【００２８】
なお、上記１〜１５の各部は、録画機能を有するネットワーク対応型のデジタルTVの標準的な構成にも対応する。
【００２９】
インターネット１６は、通信プロトコルTCP/IPにより全世界のネットワークを相互に接続したコンピュータネットワークである。
【００３０】
検索エンジン１７は、インターネットで公開されている情報をキーワード等により検索できるWebサイトである。Ｇｏｏｇｌｅ（登録商標）やＹａｈｏｏ（登録商標）などで広く公知の技術である。実施例では、ライブカメラを検索するために用いる。
【００３１】
ライブカメラ１８は、国内外の様々な場所に設置されているカメラのライブ映像をインターネットで発信するシステムである。ライブカメラには2種類あり、数十秒ごとに静止画が送られてくるカメラと動画が送られてくるカメラがあるが、実施例は後者を利用する。なお、簡単のためストリーム形式はMPEGとする。インターネットを通じて送信されたライブカメラ１７のストリームデータは、通信部１５で受信し、MPEG処理部４でデコード、超解像処理部５でアップコンバートして、LCD制御部６へ出力する。
【００３２】
音楽再生部１９は、記憶部１４に格納された例えばMP3形式の音楽データをデコードし、出力を音声出力部８へ送る。また、音楽再生用のGUIも有し、例えばアルバム名やタイトル名をLCD制御部６を通じて、LCDディスプレイ７に表示することも可能である。なお、再生すべきアルバムやタイトルの選択は、リモコン１２を使って行う。
【００３３】
なお、上記符号６〜１４、１９の各部は、ハードディスクオーディオの標準的な構成にも対応する。このように、本実施例は、「録画機能を有するネットワーク対応型のデジタルTV」と「ハードディスクオーディオ」を融合した構成を基本としている。
【００３４】
本発明の装置で特に特徴的な部分は以下の３つの構成を有する点にあり、以下説明する。
【００３５】
検索式生成部２０は、後述の概念グラフから目的地情報を検索する検索部である。この検索式生成部２０は、楽曲概念情報としてのジャンル、アルバム名及びタイトル名、さらには、作曲家、等の情報から、検索すべきライブカメラの設置場所（例えば、ニューヨークやパリといった地名や都市名である目的地情報）を求め、検索式を生成する。アルバム名とタイトル名については、言語処理技術の１つである形態素解析を用いて、それらを構成する最小単位に分解し、キーワードを日本語に翻訳した後、概念グラフを検索する。
【００３６】
このように、検索式生成部２０の機能は、再生中の楽曲の情報で概念グラフを検索し、楽曲に対応する場所のライブカメラを検索するための検索式を生成するものである。
【００３７】
メタ検索エンジン部２１は、検索式生成部２０が生成した検索式を検索エンジン１７に送信して、検索式に合致するライブカメラのURLを求める。
【００３８】
通常、ライブカメラのURLは複数求まるので、メタ検索エンジン部２１は、条件による選択処理も行うことができる。実施例では、簡単のため、基本的に、検索エンジン１７が提示する適合率が高いライブカメラ（先頭）を選択する。しかし、検索で求まるライブカメラには、時間帯で動作していないものや検索時点で廃止になったものなど、動作していないものも含まれるので、通信部１５を通じて、接続テストを行い、動作しているライブカメラのURLをライブカメラ管理テーブルのライブカメラＵＲＬの項目（Live camera URL）にセットする。すなわち、実施例では、適合率が高く、かつ、動作中であるライブカメラが選択の条件である。
【００３９】
インターネット１６が地球全体の種々の地域をカバーしているので夜間地域のライブカメラからの映像は暗くて見えない場合がある。またメンテナンス中のライブカメラも存在することが考えられるので、このようなライブカメラからの映像は無意味となる。
【００４０】
このような各種の要素を考慮し、メタ検索エンジン２１の機能は、上記検索式で検索エンジン１７を起動し、検索エンジンが１７が返してきた結果をフィルタする処理である。
【００４１】
ライブカメラ映像制御部２２は、ライブカメラ管理テーブルのURLとライブカメラ表示条件（自動的に切り替えるか、切り替えの間隔は何分か）に基き、適宜ライブカメラに接続し、映像をLCDディスプレイ７に表示させる機能を有している。このようにライブカメラ映像制御部２２の機能は、ライブカメラ管理テーブルのライブカメラＵＲＬに基き、ライブカメラ映像を取得し、ユーザの指定によっては一定時間毎に複数の映像を切り替えながらLCDディスプレイ７に表示するものである。
【００４２】
以下、（１）まず、ライブカメラ表示の設定を行い、（２）次に、楽曲の再生を行うことで、（３）LCDディスプレイ７にライブカメラ映像の表示が行われる過程を説明する。
【００４３】
（１）ライブカメラ表示の設定
ライブカメラの設定は、図６に示すような、グラフィックユーザインターフェース（ＧＵＩ）（図６（A)）を使い、リモコン１２（図６（B)）により行う。
【００４４】
・リモコン１２の「LC設定ボタン」を押下げると、例えば、図６（A)のような、「ライブカメラ設定画面」が、LCDディスプレイ７上に表示されるので、十字キーで項目を選択し、テンキーで数値を入力して、設定ボタンで確定する。
【００４５】
・実施例では、例えばライブカメラ表示を「する」、ライブカメラ選択を「自動切換え」、ライブカメラ表示最大台数を「２」台まで、ライブカメラ切り替え間隔を「５」分として、設定ボタンを押した例を示している。
【００４６】
・システム制御部１０は、不揮発性メモリ領域の各変数に対して、以下のように値をセットする。
【００４７】
変数LiveCameraSW = 1 (楽曲再生時にライブカメラ映像を表示するか否か・・・「0」:表示しない、「1」:表示する)
変数LiveCameraMode = 1 (「0」:固定（優先順位が最も高いライブカメラのみ表示）、「1」:一定時間で自動切換え)
変数LiveCameraMax = 2 （「１」以上の整数。表示するライブカメラの総数）
変数LiveCameraInterval = 5 （自動切換えの間隔（分））
以上の手順で、ライブカメラ設定が完了する。なお、設定は不揮発性メモリに保存されるため、変更がない限り、この操作は１度行えばよい。
【００４８】
（２）楽曲の再生
楽曲の再生はクライアントＴＶは、リモコン１２の「音楽サーバ」ボタンを押すことで行う。「音楽サーバ」ボタンを押すと、システム制御部１０は、まず、図７（A)の「楽曲選択画面」をLCDディスプレイ７上に表示する。実施例では、ユーザは、リモコン１２（図７（B)）の十字キーで、アルバムタイトル「BC’s Christmas Classics」の楽曲タイトル「Snow! Snow! Snow!」を選択する。次に、「楽曲選択画面」の再生ボタン「三角印」（左から２番目）を押し下げる。
【００４９】
システム制御部１０は、音楽再生部１９に対して、選択された楽曲の属性情報「アルバムNo=1、タイトルNo=7」と「楽曲再生コマンド」を送る。音楽再生部１９は、HDD制御部１３を通じて、記憶部１４から楽曲データを読み出し、デコードして、音声出力を音声出力部８に送る。上記の操作及び処理により、楽曲「Snow! Snow! Snow!」の再生が始まる。
【００５０】
（３）ライブカメラ映像の表示
システム制御部１０は、楽曲再生コマンドの発行と並行して、変数LiveCameraSWのチェックを行い、ライブカメラ画像の表示を行うべきか否かを判定する。実施例では、変数LiveCameraSW =1（ライブカメラ映像を表示する）であるため、「楽曲選択画面」を閉じて、ライブカメラ映像を表示するため、図８の処理を開始する。
【００５１】
(3.1)概念グラフの検索
システム制御部１０は、検索式生成部２０に対して、再生中の楽曲の情報「アルバムNo=1、タイトルNo=7」を送る。検索式生成部２０は、まず、概念グラフの検索を行う（ステップS801）。概念グラフの検索の詳細は、図９の処理フローで説明する。説明では、記憶部１４に格納された図４の概念グラフのデータベースを用いる。
【００５２】
まず、再生中の楽曲の情報「アルバムNo=1、タイトルNo=7」で音楽データ管理テーブルを検索し、アルバム名「BC’ｓ Christmas」、タイトル名「Snow!,Snow!,Snoｗ！」、楽曲ジャンル「Jazz&Fusion」を抽出する（ステップS901〜S904）。次のステップS905は楽曲のジャンルデータが存在しなかった場合のチェックである。
【００５３】
実施例では、ジャンルデータが取得できるので、概念グラフのノード「Jazz&Fusion」からリーフノードである「ニューヨーク」、「パリ」を見つけ、同ノードのカウンタ（Cnt）をインクリメントする（ステップS905からS908）。結果、リーフノードのカウンタは図１０のようになる。
【００５４】
次に、言語処理技術として知られた形態素解析により、アルバム名からキーワード「BC’s,Christmas」、タイトル名からキーワード「Snow,Snow,Snow」をそれぞれ抽出して、図としては明示していない「リスト」に登録する。
【００５５】
この結果、リストには、｛BC’s,Christmas,Snow,Snow,Snow｝の５つのキーワードが登録される（ステップS909、S910）。概念グラフは、日本語による作成を前提としているため、ここでリストを日本語に変換する（キーワードの正規化処理）。日本語変換には、図として明示していない辞書を用いるが、辞書には概念グラフのノードに現われる名詞のみを登録するため、固有名詞は空白となる（実施例では「BC’ｓ」が空白となる）。結果、日本語変換されたリストは、｛クリスマス、雪、雪、雪｝となる（ステップS911）。
【００５６】
次に、キーワードの１つである「クリスマス」をリストから取り出して（ステップS912）、概念グラフの該当ノードを見つけ、リーフノードまで追跡する。すると、やはりリーフノードである「ニューヨーク」、「パリ」に到達するので、各ノードのカウンタをインクリメントする（ステップS913,S914）。
【００５７】
結果、リーフノードのカウンタは図１１のようになる。リストには、キーワード｛雪,雪,雪｝が残っているので（ステップS915）、残りのキーワード「雪」を３回取り出す（ステップS912〜S915）と、最終的に各リーフノードのカウンタは、図１２のようになる（ニューヨークのCntが５、パリのCntが３）。
【００５８】
このように、中間ノードからの到達回数であるカウンタ（Cnt）の値（重み付けされた値）は、選択された楽曲と特定な場所の関連の強さを示しており、この値は、後述の処理で、ライブカメラ表示の順番を決めるために用いる（楽曲に強い関連がある場所のライブカメラを優先的に表示するために用いる）。以上で、ステップS801の処理は終了する。
【００５９】
(3.2)ライブカメラ管理テーブルの作成
次に、検索式生成部２０は、概念グラフのルーフノードだけを取り出してリストを作成し（ステップS802）、記憶部１４に、図３のようなライブカメラ管理テーブルを作成する。（ステップS803）さらに、前記リストから、カウンタ（Cnt）値が非ゼロのリーフノードを変数LiveCameraMaxの数（実施例では２）まで取り出して、リーフノードのカウント（Cnt）をライブカメラ管理テーブルのカウント（Cnt）に、語彙をロケーション（location）にセットする（ステップS804〜S811）。
【００６０】
実施例では、LiveCameraMaxは２なので、カウンタ値が非ゼロであるリーフノード「ニューヨーク」、「パリ」を取り出して、その都市名をカウンタの値と共にライブカメラ管理テーブルの場所（location）に格納する。この段階で、ライブカメラ管理テーブルは図１３のようになる。
【００６１】
次に、ライブカメラ管理テーブルで語彙がセットされた行を１行ずつ取りだして、カウント（Cnt）の大きい順に決まるライブカメラ表示順序（order）、既設定の変数LiveCameraInterval（= 5）の値である表示切替時間（time）をセットする。（ステップS813〜S816）結果、ライブカメラ管理テーブルは図１４のようになる。
【００６２】
(3.3)ライブカメラ管理テーブルにライブカメラのURLをセット
次に、検索式生成部２０は、ライブカメラ管理テーブルで語彙がセットされた行を１行ずつ取りだして、インターネット上のライブカメラを検索するための検索式を作成し、メタ検索エンジン部２１を介して検索エンジン１７と通信を行う。メタ検索エンジン部２１は、検索エンジン１７で検索した検索結果から、検索ノイズ（後述）を除去した後に、ライブカメラのURLをライブカメラ管理テーブル（Live camera URL）にセットする（ステップS817〜S822）。
【００６３】
検索式は、ライブカメラを検索するためのキーワードと、ライブカメラ管理テーブルの場所（location）を組み合わせて検索する。例えば、広く知られた検索エンジンである「Google」でライブカメラを検索するためのキーワードは、「inurl:ViewerFrame?Mode=」である（一般に、このキーワードは、使用する検索エンジン毎に異なる）。さらに絞込みを行うために、検索式に場所（location）を追加して、最終的な検索式とする。例えば、ニューヨークのライブカメラを検索するのであれば、「ニューヨーク」と「inurl:ViewerFrame?Mode=」を連結して、検索式「ニューヨーク inurl:ViewerFrame?Mode=」を得る（ステップS818）。
【００６４】
検索式生成部２０が作成した検索式はメタ検索エンジン部（２１）に渡り、メタ検索エンジン部２１は検索エンジン１７を起動する（ステップS819）。一般に、検索エンジンで検索をおこなった場合、意図しない検索結果が混じる。これを検索ノイズと呼ぶ。
【００６５】
本発明において最も問題となる検索ノイズは、未動作ライブカメラの存在である。そこで、メタ検索エンジン部２１は、ライブカメラ管理テーブルに登録する候補のＵＲＬについて、実際に接続して、動作を確認する（具体的には、接続することで、ストリーミングが受信できるかを確認する）。もし、ストリーミングが受信できれば、そのまま、ＵＲＬをライブカメラ管理テーブルのライブカメラＵＲＬ（Live camera URL）の項に登録し、受信できなかった場合は検索結果の２番目の候補について同様の操作を行い、受信可能なURLを探す（ステップS820）。
【００６６】
実施例では、「ニューヨーク」、「パリ」について、受信可能なものとして、
URL「http://XX.85.XX.104/ViewerFrame?Mode=…」と
URL「http://XX.33.XX.138/ViewerFrame?Mode=…」が見つかったものとする。すると結果として最終的には、ライブカメラ管理テーブルは図１５のようになる。
【００６７】
(3.4)ライブカメラ映像の表示
メタ検索エンジン部２１からライブカメラ管理テーブルの作成終了の通知を受けたライブカメラ映像制御部２２は、例えば、図１５の同テーブルに基き、図１６の処理フローを開始する。
【００６８】
まず、優先度１（order=1）の行をサーチし、登録されているURLを取り出す（ステップS1601〜S1603）。次に、変数変数LiveCameraModeは1（自動切換え）なので、カウントダウンタイマーに変数LiveCameraInterval の値である５（5分）をセットする（ステップS1604〜S1605）。
【００６９】
ステップS1603で取り出したURLは「http://XX.85.XX.104/ViewerFrame?Mode=…」となるので、同URLを通信部１５に送り、同時にシステム制御部１０に対して、ライブカメラ映像の表示を開始する旨を通知する。通知を受けたシステム制御部１０は、通信部１５に対して、ライブカメラ１８への接続コマンド送る（ステップS1606）。
【００７０】
さらに、システム制御部１０は、ライブカメラから送信されたストリームデータをMPEG処理部４に接続して、デコード結果は超解像処理部５でアップスケーリングして、LCD制御部６に送る（ステップS1607〜S1609）。結果、まず、優先度１のライブカメラ映像がLCDディスプレイ７に表示される。
【００７１】
ライブカメラ映像制御部２２は、LiveCameraModeは1（自動切換え）のとき、ライブカメラ映像の表示と並行して、カウントダウンタイマーを作動させる。カウントダウンタイマーの値が０になったら、優先度（order）をインクリメント(ステップS1615）して、再度新しい優先度（すなわちorder=2）でライブカメラ管理テーブルの行をサーチし、該当行のURLを取り出して同様の処理を繰り返す（ステップS1612〜S1615、S1602〜S1613）。
【００７２】
ライブカメラの表示が一巡したら、変数orderを１に戻し（ステップS1601）、表示順位１のライブカメラからの表示を繰り返す。
【００７３】
(3.4)ライブカメラ映像の表示終了
システム制御部１０がライブカメラ映像の表示中止のコマンドを受けるか、システム制御部１０が楽曲の再生終了を検出した場合は、ライブカメラ表示を終了して処理を終える（ステップS1610〜S1611、S1616）。
【００７４】
上記の処理で、例えば図１７のように、音楽サーバ機能をもつネットワーク型のＴＶにおいて、楽曲の再生時、LCDディスプレイ７に、音楽に合ったライブカメラの映像が表示できる。図７の左側はライブカメラの設定、再生する楽曲の選択の様子を示し、図７の右側は実際に音楽が再生され、映像として目的地のカメラからの現地映像が表示されている様子を示す。
【００７５】
このように、本発明では、ユーザが任意に選択した音楽について、そのジャンルやタイトルに基き、音楽の概念或いは印象に対応した的確なライブカメラ映像をインターネットから選択し、ＴＶ画面に表示することで、リラクゼーション効果を得ることができる。また、表示される映像は、ライブカメラの映像であり刻々と変化するため、例えば、ヒーリングＤＶＤと異なり、長時間見ても飽きることが無い。さらに、ライブカメラの選択も変わるため、同じ音楽を毎日再生しても意外性を得ることができる。
【００７６】
本発明は、特に、画面を窓と見なせるような、壁掛け型の大画面ＴＶで効果を発揮するものである。
【００７７】
なお、本発明は上記した実施の形態そのままに限定されるものではなく、実施段階ではその趣旨を逸脱しない範囲で構成要素を種々変形して具体化することが可能である。また以下に述べるような各実施例を組み合わせて実現してもよいことは勿論である。
【００７８】
上記した実施例では、ライブカメラ選択時に「地域」を考慮しなかったが、予め、北半球/南半球、北米/ヨーロッパ、日本など地域を指定してライブカメラを絞り込むようにしてもよい。
【００７９】
さらに上記した実施例では、ライブカメラ選択時に「時差」を考慮しなかったが、記憶部１４にタイムゾーン一覧データをもち、メタ検索エンジン部２１は、ローカルタイムと時差（予め指定）の少ない地域のライブカメラを優先的に選択してもよい。また、あえて、時差の大きい地域のライブカメラ（昼夜を逆転）を優先的に選択するようにしてもよい。
【００８０】
また上記した実施例では、ライブカメラ映像をそのまま表示したが、ローカルタイムとの時差が大きいライブカメラ映像については、先方の時間がローカルタイムの時間になったときに内蔵のハードディスクへ予め録画しておき、次回の楽曲再生時に利用してもよい（ライブカメラのタイムシフト再生機能）。
【００８１】
この機能は、日本の夕食時に音楽を再生したときに、前日のニューヨークの夜景（録画したライブカメラ映像）を見る場合に効果を発揮する。
【００８２】
さらに上記した実施例では、メタ検索エンジン部２１が除去する検索ノイズは、「起動していないライブカメラ」のみであったが、「子供に見せるには不適切なライブカメラ」を検索ノイズとして除去するようにしてもよい（ライブカメラのペアレンタル制御）。
【００８３】
上記した実施例では、簡単のため、概念グラフをジャンルとアルバム名、タイトル名から抽出したキーワードで検索したが、歌詞がある場合、歌詞を形態素解析して得たキーワードも含めて検索することで、ライブカメラ選択の精度を上げるようにしてもよい。
【００８４】
上記した実施例では、ジャンルやアルバム名/タイトル名のキーワードといった楽曲の属性で概念グラフを検索したが、楽曲の曲構造やリズム解析の結果で概念グラフを検索するようにしてもよい。その場合、ポピュラー音楽、サンバ音楽などのパターンを検出して、その分類で概念グラフを検索する。楽曲から直接特徴量を抽出して利用することで、ジャンルが不明で、アルバム名/タイトル名からキーワードが抽出できない場合に効果を発揮する。
【００８５】
上記した実施例では、「ロケーション」に関わる概念グラフを用いたが、他の概念グラフ（例えば、「夜景」など「シーン」に関わる概念グラフ）を使っても良いし、複数の概念グラフを組み合わせても構わない。
【００８６】
上記した実施例では、予め格納した概念グラフに基き「ロケーション」を決定したが、同グラフをユーザ自身が定義する、あるいは、追加/修正を行えるようにしてもよい。この場合は、概念グラフの追加/修正モードを実行する。すると例えば、図４に示したツリー図と、図５に示したようなデータ構造のテーブルがLCDディスプレイに表示される。利用者は、ツリー図のノードを指定し、データ構造テーブルを表示し、修正を行うことができる。また新たなノードを設定する場合は、図４のノードのスペース部にカーソルを移動させ、「決定」ボタンを操作すると、図５のテーブルが現れるので、語彙、上位ノード番号、下位ノード番号、分類、ノードタイプ、を入力する。ノード番号は、自動的に割り振られる。
【００８７】
上記した実施例では、予め格納した概念グラフに基き「ロケーション」を決定したが、操作部１１及び制御部１０の制御に基づいて、同グラフを外部サーバからダウンロードするようにしてもよい。また、同グラフをユーザが改良してアップロードし、他のユーザに提供するようにしてもよい。
【００８８】
上記した実施例では、「検索式生成部、メタ検索エンジン部、ライブカメラ映像制御部」の各部と「前記各部が使用するデータ」を「ＴＶ側」に持たせたが、例えば、外部サーバを用意し、それらを「外部サーバ側」に持たせて実現してもよい。つまり上記の実施例では、音楽データ管理テーブル（図２）、概念グラフ（図４）のデータファイルが記憶部１４に格納されているとして説明した。しかしこの場所に限らず、音楽データ管理テーブル、概念グラフは、外部のサーバにおいて管理されていてもよい。音楽データ管理テーブル、概念グラフは、外部のサーバにある場合、利用者が選択した楽曲のタイトル名がサーバに送信される。すると、外部のサーバに設けられた検索式生成部及びメタ検索エンジン部が検索を実行し、選択した楽曲に関連するライブカメラのURLが送信されてくる。
【００８９】
図１８には、サーバ側に検索式生成部２０、メタ検索エンジン部２１、ライブカメラ映像制御部２２が設けられた例を示している。また図１と対応する部分には同一符号を付している。このサーバでは、データファイル１４には、それぞれ映像提供地域を示す複数の目的地情報と前記複数の目的地情報の中の１つ又は複数に関連付けされており、かつ楽曲の概念を表す複数の語彙分類ノード情報とを含む概念グラフのデータが格納されている。また受信情報処理部１０aは、外部のクライアント（TV）よりネットワーク１６を介して再生希望の楽曲の情報を受け取ることができる。検索式生成部２０は、楽曲の概念を表す楽曲概念情報と類似又は同一意味の語彙分類ノード情報を前記複数の語彙分類ノード情報中から検索し、検索した語彙分類ノード情報に対応するヒット目的地情報を前記複数の目的地情報の中から抽出し、かつ前記楽曲概念情報を変更して複数回前記検索を実行して、前記選択された楽曲に関連性の高い１つ又は複数のヒット目的地情報を取得する。
【００９０】
メタ検索エンジン部２１は、通信部１５を介して前記１つ又は複数のヒット目的地情報を利用して対応するカメラ配置情報を取得する。すると送信情報処理部１０ｂがカメラ配置情報をクライアントであるTVに送信する。カメラ配置情報を取得する動作は、先の実施例で説明した動作と同じである。上記した概念グラフのデータは、クライアント側で改良されアップロードされたものであってもよい。また、クライアント側で改良された概念グラフデータをサーバ側で管理することにより、複数ユーザにより改良された概念グラフデータを自動的に集約することもできる。概念グラフデータにいわゆる集合知を適用することで、概念グラフデータの精度をさらに高めることが可能となる。
【００９１】
従来技術では、音楽に組み合わせる映像は画一的で、繰り返し見ると飽きるという問題点があった。また、すべての音楽に映像を組み合わせたコンテンツがあるとは限らなかった。
【００９２】
本発明は、上記問題を鑑みたもので、ユーザが任意に選択した音楽について、そのジャンルやタイトルに対応するライブカメラ映像をインターネットから選択/表示することで、ヒーリングと意外性を実現する手段及び装置を提供する。
【産業上の利用可能性】
【００９３】
本発明は、サーバ、セットトップボックス、テレビジョン（TV）受信装置、コンパクトな映像表示装置、録画装置などで音楽概念データ処理するのに有効である。
【符号の説明】
【００９４】
１・・・アンテナ、２・・・チューナ部、４・・・MPEG処理部、５・・・超解像処理部、６・・・LCD制御部、７・・・LCDディスプレイ、８・・・音声出力部、９・・・スピーカー、１０・・・システム制御部、１１・・・操作部、１２・・・リモコン、１３・・・HDD制御部、１４・・・記憶部、１５・・・通信部、１６・・インターネット、１７・・・検索エンジン、１８・・・ライブカメラ、１９・・・音楽再生部、２０・・・検索式生成部、２１・・・メタ検索エンジン部、２２・・・ライブカメラ映像制御部。
【技術分野】
【０００１】
本発明は、音楽概念データ処理方法及び映像表示装置及び音楽概念データ処理サーバに関するもので、音楽の概念或いは印象を地域映像に関連付けることができる装置である。
【背景技術】
【０００２】
ユーザ端末装置から、出発地と目的地を入力すると、ネットワーク上にあるサイトの情報、コンテンツサーバのコンテンツ、ライブカメラのライブ映像を取得できる技術がある。このシステムでは、ユーザは表示部に表示される画像等のコンテンツを閲覧しつつ、自宅等に居ながらにして旅行に出たかのような擬似旅行を体験することができる（例えば特許文献１）。
【０００３】
またカラオケシステムにおいて、楽曲データがジャンル分けされており、ネットワークに接続されたライブカメラも複数の場所にジャンル分けされて設置されているものがある（特許文献２）。このカラオケシステムでは、顧客が楽曲を選択すると、その楽曲にあったライブカメラ映像が送信されてくる。送信されてきた映像は、カラオケ用の映像として表示部に背景表示される。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００７−１５６５６２号公報
【特許文献２】特開２００２−２９７１６７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
音楽とライブ映像を関連付ける場合、さらに的確で欲しいという要望がある。また音楽とライブ映像を関連付が固定ではなく、自動的な更新・変更が可能であり、融通性をもって実行されて欲しいという要望もある。
【０００６】
そこでこの発明の一実施例は、音楽の概念或いは印象を地域映像により密接に関連付けることができる音楽概念データ処理方法及び映像表示装置及び音楽概念データ処理サーバを提供することを目的とする。
【課題を解決するための手段】
【０００７】
上記の課題を解決するために、本発明の一実施例は、データファイルと検索部を有し、
前記データファイルには、それぞれ映像提供地域を示す複数の目的地情報と前記複数の目的地情報の中の１つ又は複数に関連付けされており、かつ楽曲の概念を表す複数の語彙分類ノード情報とを含む概念グラフのデータを格納しておき、
前記検索部では、再生用として選択された楽曲の概念を表す楽曲概念情報と類似又は同一意味の語彙分類ノード情報を前記複数の語彙分類ノード情報中から検索し、検索した語彙分類ノード情報に対応するヒット目的地情報を前記複数の目的地情報の中から抽出し、かつ前記楽曲用概念情報を変更して複数回前記検索を実行して、前記選択された楽曲に関連性の高い１つ又は複数のヒット目的地情報を取得し、前記１つ又は複数のヒット目的地情報を対応する目的地の映像取得用として出力することを特徴とする。
【発明の効果】
【０００８】
上記した処理により本発明は音楽の概念或いは印象を地域映像により密接に関連付けることができるという効果を奏する。
【図面の簡単な説明】
【０００９】
【図１】本発明に係る一実施例の装置を示すブロック図である。
【図２】本発明で用いられる音楽データ管理テーブルの例を示す図クである。
【図３】本発明で用いられるライブカメラ管理テーブルの例を示す図である。
【図４】本発明で用いられる概念グラフの例を示す図である。
【図５】本発明で用いられる概念グラフのデータ構造の例を示す図である。
【図６】本発明で用いられるライブカメラ表示設定ＧＵＩの例を示す図である。
【図７】本発明で用いられる楽曲選択画面の例を示す図である。
【図８】本発明で用いられるライブカメラ管理テーブルの作成フローの例を示す図である。
【図９】本発明で用いられる概念グラフ検索フローの例を示す図である。
【図１０】ジャンルによる概念グラフの検索例を示す図である。
【図１１】キーワードによる概念グラフの検索例１を示す図である。
【図１２】キーワードによる概念グラフの検索例２を示す図である。
【図１３】ライブカメラ管理テーブルへのデータの格納例１を示す図である。
【図１４】ライブカメラ管理テーブルへのデータの格納例２を示す図である。
【図１５】完成したライブカメラ管理テーブルの例を示す図である。
【図１６】ライブカメラ表示フローの例を示す図である。
【図１７】本発明の装置の利用シーンの例を示す図である。
【図１８】本発明に係る他の実施例であり、サーバーの構成を示すブロック図である。
【発明を実施するための形態】
【００１０】
以下、本発明の実施の形態について、詳細に説明する。図１は本発明が適用された映像表示装置の構成例を示す。アンテナ１は、チューナ部２に接続されており地上デジタル放送を受信する。チューナ部２は、テレビ放送を受信・選局する部分である。本実施例では、デジタル放送を受信して、受信チャンネルの信号を一旦IF（中間周波数）信号に変換する装置である。デジタル復調部３は、IF信号からデジタル信号（TS：トランスポートストリーム）を取り出し、MPEG処理部４へ送る。MPEG処理部４は、デジタル復調部３あるいは通信部１５から送られたトランスポートストリームを処理し、映像/音声のデコードを行う。デコードされた映像データはLCD（液晶装置）制御部６へ渡す。また、音声データは音声出力部７へ渡すことで、音声を再生する。
【００１１】
超解像処理部５は、MPEG処理部４に接続されており、デジタル化の際に失われた信号を復元し、映像の画素を増やすことで映像の解像度を高める処理を行う部分である。通常、地上デジタル放送の解像度1440×1080を、フル・ハイ・ディフィニション（HD）画質の解像度1920×1080へアップコンバートするために用いるが、本実施例ではテレビ放送の解像度よりもはるかに劣るライブカメラ映像の画質を、フルHD画質へアップコンバートするために利用している。
【００１２】
LCD制御部６は、超解像処理部５に接続されており、映像データをフルHD画質の液晶ディスプレイ７（以下LCDディスプレイ７）へ送り、画像を表示する。
【００１３】
LCDディスプレイ７は、ＬＣＤ制御部６に接続されており、ＭＰＥＧ処理部４がデコードし、超解像処理部５がアップコンバートした映像データを表示する。すなわち、地上デジタル放送の番組とライブカメラ映像を表示するディスプレイである。
【００１４】
音声出力部８はスピーカー９に接続され、ＭＰＥＧ処理部４と音楽再生部１３が出力した音声データをスピーカー９に出力する。すなわち、音声出力部８は、地上デジタル放送の音声、あるいは、音楽再生時の楽曲のいずれかを出力する。スピーカー９は音声出力部８に接続されており、音声あるいは楽曲を出力する。
【００１５】
システム制御部１０は、本発明の各処理部の動作を統括的に制御するための処理部である。制御部１０は、図として明示していないが、制御プログラムを格納するROMと、後述の処理の作業領域として必要となるRAMと、ライブカメラ設定などを記憶する不揮発性メモリ（フラッシュメモリ）を備えている。
【００１６】
操作部１１はリモートコントローラ（以下リモコンと略称）１２からの制御コマンドを受信し、システム制御部１０に送る。リモコン１２は、本発明の操作をするための装置であり、操作部１１に対して赤外線を利用した無線通信で制御コマンドを与える。リモコン１２には、数字を入力するためのテンキーが設けられており、チャンネル番号の入力を可能としている。また、リモコン１２には、十字キーが設けられており、楽曲リストの選択や設定項目の選択などのＧＵＩ（Graphical User Interface）操作を可能としている。
【００１７】
実施例では、ライブカメラ映像の切り替えの有無や、ライブカメラ映像の自動切換え間隔の指定といったシステムの設定と、音楽を再生する際に、アルバムや楽曲を選択するために使用する。
【００１８】
HDD制御部１３は、記憶部１４に接続し、記憶部１４のデータ（映像データ、音楽データ、システムデータ）の読み書きを制御する。記憶部１４はハードディスクドライブ（HDD）である。例えば、MPEG形式の映像データ、MP3形式の音楽データ、システムデータを格納する。
【００１９】
システムデータとは、例えば、音楽データ管理テーブル（図２参照）、ライブカメラ映像制御部２２が利用するライブカメラ管理テーブル（図３参照）、検索式生成部２０が使用する概念グラフ（図４参照）等のデータである。
【００２０】
音楽データ管理テーブル（図２）は、公知の技術である「gracenoteのCDDB」に登録されているアルバム名、アーティスト名、ジャンルなどの楽曲データを格納するテーブルである。
【００２１】
ライブカメラ管理テーブル（図３）は、リーフノードのカウンタ（Cnt：後述）、ライブカメラの優先順位（order）、ライブカメラの表示時間（time）、ライブカメラが設置された場所（location）、ライブカメラのURLを格納するテーブルである。
【００２２】
概念グラフ（図４）は、概念同士の相互関係をグラフ構造で定義したものであり、実施例では、「音楽ジャンル」及び「キーワード」と「場所（リーフノード）」を関連付けるために用いる。例えば、「ロックフェラーセンターのクリスマスツリー」が一般的に有名であれば、「クリスマスツリー」とロックフェラーセンターのある「ニューヨーク」をグラフ構造で結びつける。
【００２３】
つまり、概念グラフには、映像提供地域を示す複数の目的地情報（ローマ、ウィーン、ニューヨーク、パリ、ロッキー、スイスアルプス、モンブラン、マウントクック、ワイキキ、バリ島等）が含まれる。また、複数の目的地情報の中の１つ又は複数に関連付けされており、かつ楽曲の概念を表す複数の語彙分類ノード情報（雪、クリスマス、クラシック、ジャズ、イルミネーション、クリスマスツリー、スノーボード、スキー、サーフィンなど）が含まれる。
【００２４】
図５に概念グラフのデータ構造の例を示す。カウンタ（Cnt）は、実施例においては、リーフノードで有効な領域で、ジャンルあるいはキーワードに対応する中間ノードから、図４の概念グラフを下方追跡したときに、リーフノード（目的地情報）に到達した回数を保持するために使用する。この回数が大きい場所（リーフノード）ほど、再生中の楽曲と関連が強い場所となり、ライブカメラの表示優先順位（order）が高くなる。
【００２５】
本装置では、再生用の楽曲が選択されると、楽曲の概念を表す楽曲概念情報と類似又は同一意味の語彙分類ノード情報が複数の語彙分類ノード情報中から検索される。そして、検索した語彙分類ノード情報に対応するヒット目的地情報が複数の目的地情報の中から抽出される。さらに楽曲概念情報を変更（タイトルや解説に含まれる用語、例えば図４のサーフィンをビーチに対応する用語に変更）して複数回前記検索を実行すると、選択された楽曲に関連性の高い１つ又は複数のヒット目的地情報（ワイキキ、バリ島などの地名、地域の名称）を取得することができる。１つ又は複数のヒット目的地情報が特定されると、この情報が検索エンジン１７に送信され、対応する目的地の映像取得用として、ライブカメラのURLを取得することができる。ライブカメラのURLは、図３のライブカメラ管理テーブルに格納される。
【００２６】
なお、実施例では、記憶部１４にハードディスクを使用しているが、例えば、SSD(Solid State Drive)といった他の記憶媒体を利用しても、もちろん構わない。
【００２７】
通信部１５は、インターネットに接続するためのネットワークアダプタである。実施例では、通信部１５を通じてインターネット１６に接続して、検索エンジン１７によりライブカメラ映像を検索し、また、ライブカメラ映像のストリームを受信する。
【００２８】
なお、上記１〜１５の各部は、録画機能を有するネットワーク対応型のデジタルTVの標準的な構成にも対応する。
【００２９】
インターネット１６は、通信プロトコルTCP/IPにより全世界のネットワークを相互に接続したコンピュータネットワークである。
【００３０】
検索エンジン１７は、インターネットで公開されている情報をキーワード等により検索できるWebサイトである。Ｇｏｏｇｌｅ（登録商標）やＹａｈｏｏ（登録商標）などで広く公知の技術である。実施例では、ライブカメラを検索するために用いる。
【００３１】
ライブカメラ１８は、国内外の様々な場所に設置されているカメラのライブ映像をインターネットで発信するシステムである。ライブカメラには2種類あり、数十秒ごとに静止画が送られてくるカメラと動画が送られてくるカメラがあるが、実施例は後者を利用する。なお、簡単のためストリーム形式はMPEGとする。インターネットを通じて送信されたライブカメラ１７のストリームデータは、通信部１５で受信し、MPEG処理部４でデコード、超解像処理部５でアップコンバートして、LCD制御部６へ出力する。
【００３２】
音楽再生部１９は、記憶部１４に格納された例えばMP3形式の音楽データをデコードし、出力を音声出力部８へ送る。また、音楽再生用のGUIも有し、例えばアルバム名やタイトル名をLCD制御部６を通じて、LCDディスプレイ７に表示することも可能である。なお、再生すべきアルバムやタイトルの選択は、リモコン１２を使って行う。
【００３３】
なお、上記符号６〜１４、１９の各部は、ハードディスクオーディオの標準的な構成にも対応する。このように、本実施例は、「録画機能を有するネットワーク対応型のデジタルTV」と「ハードディスクオーディオ」を融合した構成を基本としている。
【００３４】
本発明の装置で特に特徴的な部分は以下の３つの構成を有する点にあり、以下説明する。
【００３５】
検索式生成部２０は、後述の概念グラフから目的地情報を検索する検索部である。この検索式生成部２０は、楽曲概念情報としてのジャンル、アルバム名及びタイトル名、さらには、作曲家、等の情報から、検索すべきライブカメラの設置場所（例えば、ニューヨークやパリといった地名や都市名である目的地情報）を求め、検索式を生成する。アルバム名とタイトル名については、言語処理技術の１つである形態素解析を用いて、それらを構成する最小単位に分解し、キーワードを日本語に翻訳した後、概念グラフを検索する。
【００３６】
このように、検索式生成部２０の機能は、再生中の楽曲の情報で概念グラフを検索し、楽曲に対応する場所のライブカメラを検索するための検索式を生成するものである。
【００３７】
メタ検索エンジン部２１は、検索式生成部２０が生成した検索式を検索エンジン１７に送信して、検索式に合致するライブカメラのURLを求める。
【００３８】
通常、ライブカメラのURLは複数求まるので、メタ検索エンジン部２１は、条件による選択処理も行うことができる。実施例では、簡単のため、基本的に、検索エンジン１７が提示する適合率が高いライブカメラ（先頭）を選択する。しかし、検索で求まるライブカメラには、時間帯で動作していないものや検索時点で廃止になったものなど、動作していないものも含まれるので、通信部１５を通じて、接続テストを行い、動作しているライブカメラのURLをライブカメラ管理テーブルのライブカメラＵＲＬの項目（Live camera URL）にセットする。すなわち、実施例では、適合率が高く、かつ、動作中であるライブカメラが選択の条件である。
【００３９】
インターネット１６が地球全体の種々の地域をカバーしているので夜間地域のライブカメラからの映像は暗くて見えない場合がある。またメンテナンス中のライブカメラも存在することが考えられるので、このようなライブカメラからの映像は無意味となる。
【００４０】
このような各種の要素を考慮し、メタ検索エンジン２１の機能は、上記検索式で検索エンジン１７を起動し、検索エンジンが１７が返してきた結果をフィルタする処理である。
【００４１】
ライブカメラ映像制御部２２は、ライブカメラ管理テーブルのURLとライブカメラ表示条件（自動的に切り替えるか、切り替えの間隔は何分か）に基き、適宜ライブカメラに接続し、映像をLCDディスプレイ７に表示させる機能を有している。このようにライブカメラ映像制御部２２の機能は、ライブカメラ管理テーブルのライブカメラＵＲＬに基き、ライブカメラ映像を取得し、ユーザの指定によっては一定時間毎に複数の映像を切り替えながらLCDディスプレイ７に表示するものである。
【００４２】
以下、（１）まず、ライブカメラ表示の設定を行い、（２）次に、楽曲の再生を行うことで、（３）LCDディスプレイ７にライブカメラ映像の表示が行われる過程を説明する。
【００４３】
（１）ライブカメラ表示の設定
ライブカメラの設定は、図６に示すような、グラフィックユーザインターフェース（ＧＵＩ）（図６（A)）を使い、リモコン１２（図６（B)）により行う。
【００４４】
・リモコン１２の「LC設定ボタン」を押下げると、例えば、図６（A)のような、「ライブカメラ設定画面」が、LCDディスプレイ７上に表示されるので、十字キーで項目を選択し、テンキーで数値を入力して、設定ボタンで確定する。
【００４５】
・実施例では、例えばライブカメラ表示を「する」、ライブカメラ選択を「自動切換え」、ライブカメラ表示最大台数を「２」台まで、ライブカメラ切り替え間隔を「５」分として、設定ボタンを押した例を示している。
【００４６】
・システム制御部１０は、不揮発性メモリ領域の各変数に対して、以下のように値をセットする。
【００４７】
変数LiveCameraSW = 1 (楽曲再生時にライブカメラ映像を表示するか否か・・・「0」:表示しない、「1」:表示する)
変数LiveCameraMode = 1 (「0」:固定（優先順位が最も高いライブカメラのみ表示）、「1」:一定時間で自動切換え)
変数LiveCameraMax = 2 （「１」以上の整数。表示するライブカメラの総数）
変数LiveCameraInterval = 5 （自動切換えの間隔（分））
以上の手順で、ライブカメラ設定が完了する。なお、設定は不揮発性メモリに保存されるため、変更がない限り、この操作は１度行えばよい。
【００４８】
（２）楽曲の再生
楽曲の再生はクライアントＴＶは、リモコン１２の「音楽サーバ」ボタンを押すことで行う。「音楽サーバ」ボタンを押すと、システム制御部１０は、まず、図７（A)の「楽曲選択画面」をLCDディスプレイ７上に表示する。実施例では、ユーザは、リモコン１２（図７（B)）の十字キーで、アルバムタイトル「BC’s Christmas Classics」の楽曲タイトル「Snow! Snow! Snow!」を選択する。次に、「楽曲選択画面」の再生ボタン「三角印」（左から２番目）を押し下げる。
【００４９】
システム制御部１０は、音楽再生部１９に対して、選択された楽曲の属性情報「アルバムNo=1、タイトルNo=7」と「楽曲再生コマンド」を送る。音楽再生部１９は、HDD制御部１３を通じて、記憶部１４から楽曲データを読み出し、デコードして、音声出力を音声出力部８に送る。上記の操作及び処理により、楽曲「Snow! Snow! Snow!」の再生が始まる。
【００５０】
（３）ライブカメラ映像の表示
システム制御部１０は、楽曲再生コマンドの発行と並行して、変数LiveCameraSWのチェックを行い、ライブカメラ画像の表示を行うべきか否かを判定する。実施例では、変数LiveCameraSW =1（ライブカメラ映像を表示する）であるため、「楽曲選択画面」を閉じて、ライブカメラ映像を表示するため、図８の処理を開始する。
【００５１】
(3.1)概念グラフの検索
システム制御部１０は、検索式生成部２０に対して、再生中の楽曲の情報「アルバムNo=1、タイトルNo=7」を送る。検索式生成部２０は、まず、概念グラフの検索を行う（ステップS801）。概念グラフの検索の詳細は、図９の処理フローで説明する。説明では、記憶部１４に格納された図４の概念グラフのデータベースを用いる。
【００５２】
まず、再生中の楽曲の情報「アルバムNo=1、タイトルNo=7」で音楽データ管理テーブルを検索し、アルバム名「BC’ｓ Christmas」、タイトル名「Snow!,Snow!,Snoｗ！」、楽曲ジャンル「Jazz&Fusion」を抽出する（ステップS901〜S904）。次のステップS905は楽曲のジャンルデータが存在しなかった場合のチェックである。
【００５３】
実施例では、ジャンルデータが取得できるので、概念グラフのノード「Jazz&Fusion」からリーフノードである「ニューヨーク」、「パリ」を見つけ、同ノードのカウンタ（Cnt）をインクリメントする（ステップS905からS908）。結果、リーフノードのカウンタは図１０のようになる。
【００５４】
次に、言語処理技術として知られた形態素解析により、アルバム名からキーワード「BC’s,Christmas」、タイトル名からキーワード「Snow,Snow,Snow」をそれぞれ抽出して、図としては明示していない「リスト」に登録する。
【００５５】
この結果、リストには、｛BC’s,Christmas,Snow,Snow,Snow｝の５つのキーワードが登録される（ステップS909、S910）。概念グラフは、日本語による作成を前提としているため、ここでリストを日本語に変換する（キーワードの正規化処理）。日本語変換には、図として明示していない辞書を用いるが、辞書には概念グラフのノードに現われる名詞のみを登録するため、固有名詞は空白となる（実施例では「BC’ｓ」が空白となる）。結果、日本語変換されたリストは、｛クリスマス、雪、雪、雪｝となる（ステップS911）。
【００５６】
次に、キーワードの１つである「クリスマス」をリストから取り出して（ステップS912）、概念グラフの該当ノードを見つけ、リーフノードまで追跡する。すると、やはりリーフノードである「ニューヨーク」、「パリ」に到達するので、各ノードのカウンタをインクリメントする（ステップS913,S914）。
【００５７】
結果、リーフノードのカウンタは図１１のようになる。リストには、キーワード｛雪,雪,雪｝が残っているので（ステップS915）、残りのキーワード「雪」を３回取り出す（ステップS912〜S915）と、最終的に各リーフノードのカウンタは、図１２のようになる（ニューヨークのCntが５、パリのCntが３）。
【００５８】
このように、中間ノードからの到達回数であるカウンタ（Cnt）の値（重み付けされた値）は、選択された楽曲と特定な場所の関連の強さを示しており、この値は、後述の処理で、ライブカメラ表示の順番を決めるために用いる（楽曲に強い関連がある場所のライブカメラを優先的に表示するために用いる）。以上で、ステップS801の処理は終了する。
【００５９】
(3.2)ライブカメラ管理テーブルの作成
次に、検索式生成部２０は、概念グラフのルーフノードだけを取り出してリストを作成し（ステップS802）、記憶部１４に、図３のようなライブカメラ管理テーブルを作成する。（ステップS803）さらに、前記リストから、カウンタ（Cnt）値が非ゼロのリーフノードを変数LiveCameraMaxの数（実施例では２）まで取り出して、リーフノードのカウント（Cnt）をライブカメラ管理テーブルのカウント（Cnt）に、語彙をロケーション（location）にセットする（ステップS804〜S811）。
【００６０】
実施例では、LiveCameraMaxは２なので、カウンタ値が非ゼロであるリーフノード「ニューヨーク」、「パリ」を取り出して、その都市名をカウンタの値と共にライブカメラ管理テーブルの場所（location）に格納する。この段階で、ライブカメラ管理テーブルは図１３のようになる。
【００６１】
次に、ライブカメラ管理テーブルで語彙がセットされた行を１行ずつ取りだして、カウント（Cnt）の大きい順に決まるライブカメラ表示順序（order）、既設定の変数LiveCameraInterval（= 5）の値である表示切替時間（time）をセットする。（ステップS813〜S816）結果、ライブカメラ管理テーブルは図１４のようになる。
【００６２】
(3.3)ライブカメラ管理テーブルにライブカメラのURLをセット
次に、検索式生成部２０は、ライブカメラ管理テーブルで語彙がセットされた行を１行ずつ取りだして、インターネット上のライブカメラを検索するための検索式を作成し、メタ検索エンジン部２１を介して検索エンジン１７と通信を行う。メタ検索エンジン部２１は、検索エンジン１７で検索した検索結果から、検索ノイズ（後述）を除去した後に、ライブカメラのURLをライブカメラ管理テーブル（Live camera URL）にセットする（ステップS817〜S822）。
【００６３】
検索式は、ライブカメラを検索するためのキーワードと、ライブカメラ管理テーブルの場所（location）を組み合わせて検索する。例えば、広く知られた検索エンジンである「Google」でライブカメラを検索するためのキーワードは、「inurl:ViewerFrame?Mode=」である（一般に、このキーワードは、使用する検索エンジン毎に異なる）。さらに絞込みを行うために、検索式に場所（location）を追加して、最終的な検索式とする。例えば、ニューヨークのライブカメラを検索するのであれば、「ニューヨーク」と「inurl:ViewerFrame?Mode=」を連結して、検索式「ニューヨーク inurl:ViewerFrame?Mode=」を得る（ステップS818）。
【００６４】
検索式生成部２０が作成した検索式はメタ検索エンジン部（２１）に渡り、メタ検索エンジン部２１は検索エンジン１７を起動する（ステップS819）。一般に、検索エンジンで検索をおこなった場合、意図しない検索結果が混じる。これを検索ノイズと呼ぶ。
【００６５】
本発明において最も問題となる検索ノイズは、未動作ライブカメラの存在である。そこで、メタ検索エンジン部２１は、ライブカメラ管理テーブルに登録する候補のＵＲＬについて、実際に接続して、動作を確認する（具体的には、接続することで、ストリーミングが受信できるかを確認する）。もし、ストリーミングが受信できれば、そのまま、ＵＲＬをライブカメラ管理テーブルのライブカメラＵＲＬ（Live camera URL）の項に登録し、受信できなかった場合は検索結果の２番目の候補について同様の操作を行い、受信可能なURLを探す（ステップS820）。
【００６６】
実施例では、「ニューヨーク」、「パリ」について、受信可能なものとして、
URL「http://XX.85.XX.104/ViewerFrame?Mode=…」と
URL「http://XX.33.XX.138/ViewerFrame?Mode=…」が見つかったものとする。すると結果として最終的には、ライブカメラ管理テーブルは図１５のようになる。
【００６７】
(3.4)ライブカメラ映像の表示
メタ検索エンジン部２１からライブカメラ管理テーブルの作成終了の通知を受けたライブカメラ映像制御部２２は、例えば、図１５の同テーブルに基き、図１６の処理フローを開始する。
【００６８】
まず、優先度１（order=1）の行をサーチし、登録されているURLを取り出す（ステップS1601〜S1603）。次に、変数変数LiveCameraModeは1（自動切換え）なので、カウントダウンタイマーに変数LiveCameraInterval の値である５（5分）をセットする（ステップS1604〜S1605）。
【００６９】
ステップS1603で取り出したURLは「http://XX.85.XX.104/ViewerFrame?Mode=…」となるので、同URLを通信部１５に送り、同時にシステム制御部１０に対して、ライブカメラ映像の表示を開始する旨を通知する。通知を受けたシステム制御部１０は、通信部１５に対して、ライブカメラ１８への接続コマンド送る（ステップS1606）。
【００７０】
さらに、システム制御部１０は、ライブカメラから送信されたストリームデータをMPEG処理部４に接続して、デコード結果は超解像処理部５でアップスケーリングして、LCD制御部６に送る（ステップS1607〜S1609）。結果、まず、優先度１のライブカメラ映像がLCDディスプレイ７に表示される。
【００７１】
ライブカメラ映像制御部２２は、LiveCameraModeは1（自動切換え）のとき、ライブカメラ映像の表示と並行して、カウントダウンタイマーを作動させる。カウントダウンタイマーの値が０になったら、優先度（order）をインクリメント(ステップS1615）して、再度新しい優先度（すなわちorder=2）でライブカメラ管理テーブルの行をサーチし、該当行のURLを取り出して同様の処理を繰り返す（ステップS1612〜S1615、S1602〜S1613）。
【００７２】
ライブカメラの表示が一巡したら、変数orderを１に戻し（ステップS1601）、表示順位１のライブカメラからの表示を繰り返す。
【００７３】
(3.4)ライブカメラ映像の表示終了
システム制御部１０がライブカメラ映像の表示中止のコマンドを受けるか、システム制御部１０が楽曲の再生終了を検出した場合は、ライブカメラ表示を終了して処理を終える（ステップS1610〜S1611、S1616）。
【００７４】
上記の処理で、例えば図１７のように、音楽サーバ機能をもつネットワーク型のＴＶにおいて、楽曲の再生時、LCDディスプレイ７に、音楽に合ったライブカメラの映像が表示できる。図７の左側はライブカメラの設定、再生する楽曲の選択の様子を示し、図７の右側は実際に音楽が再生され、映像として目的地のカメラからの現地映像が表示されている様子を示す。
【００７５】
このように、本発明では、ユーザが任意に選択した音楽について、そのジャンルやタイトルに基き、音楽の概念或いは印象に対応した的確なライブカメラ映像をインターネットから選択し、ＴＶ画面に表示することで、リラクゼーション効果を得ることができる。また、表示される映像は、ライブカメラの映像であり刻々と変化するため、例えば、ヒーリングＤＶＤと異なり、長時間見ても飽きることが無い。さらに、ライブカメラの選択も変わるため、同じ音楽を毎日再生しても意外性を得ることができる。
【００７６】
本発明は、特に、画面を窓と見なせるような、壁掛け型の大画面ＴＶで効果を発揮するものである。
【００７７】
なお、本発明は上記した実施の形態そのままに限定されるものではなく、実施段階ではその趣旨を逸脱しない範囲で構成要素を種々変形して具体化することが可能である。また以下に述べるような各実施例を組み合わせて実現してもよいことは勿論である。
【００７８】
上記した実施例では、ライブカメラ選択時に「地域」を考慮しなかったが、予め、北半球/南半球、北米/ヨーロッパ、日本など地域を指定してライブカメラを絞り込むようにしてもよい。
【００７９】
さらに上記した実施例では、ライブカメラ選択時に「時差」を考慮しなかったが、記憶部１４にタイムゾーン一覧データをもち、メタ検索エンジン部２１は、ローカルタイムと時差（予め指定）の少ない地域のライブカメラを優先的に選択してもよい。また、あえて、時差の大きい地域のライブカメラ（昼夜を逆転）を優先的に選択するようにしてもよい。
【００８０】
また上記した実施例では、ライブカメラ映像をそのまま表示したが、ローカルタイムとの時差が大きいライブカメラ映像については、先方の時間がローカルタイムの時間になったときに内蔵のハードディスクへ予め録画しておき、次回の楽曲再生時に利用してもよい（ライブカメラのタイムシフト再生機能）。
【００８１】
この機能は、日本の夕食時に音楽を再生したときに、前日のニューヨークの夜景（録画したライブカメラ映像）を見る場合に効果を発揮する。
【００８２】
さらに上記した実施例では、メタ検索エンジン部２１が除去する検索ノイズは、「起動していないライブカメラ」のみであったが、「子供に見せるには不適切なライブカメラ」を検索ノイズとして除去するようにしてもよい（ライブカメラのペアレンタル制御）。
【００８３】
上記した実施例では、簡単のため、概念グラフをジャンルとアルバム名、タイトル名から抽出したキーワードで検索したが、歌詞がある場合、歌詞を形態素解析して得たキーワードも含めて検索することで、ライブカメラ選択の精度を上げるようにしてもよい。
【００８４】
上記した実施例では、ジャンルやアルバム名/タイトル名のキーワードといった楽曲の属性で概念グラフを検索したが、楽曲の曲構造やリズム解析の結果で概念グラフを検索するようにしてもよい。その場合、ポピュラー音楽、サンバ音楽などのパターンを検出して、その分類で概念グラフを検索する。楽曲から直接特徴量を抽出して利用することで、ジャンルが不明で、アルバム名/タイトル名からキーワードが抽出できない場合に効果を発揮する。
【００８５】
上記した実施例では、「ロケーション」に関わる概念グラフを用いたが、他の概念グラフ（例えば、「夜景」など「シーン」に関わる概念グラフ）を使っても良いし、複数の概念グラフを組み合わせても構わない。
【００８６】
上記した実施例では、予め格納した概念グラフに基き「ロケーション」を決定したが、同グラフをユーザ自身が定義する、あるいは、追加/修正を行えるようにしてもよい。この場合は、概念グラフの追加/修正モードを実行する。すると例えば、図４に示したツリー図と、図５に示したようなデータ構造のテーブルがLCDディスプレイに表示される。利用者は、ツリー図のノードを指定し、データ構造テーブルを表示し、修正を行うことができる。また新たなノードを設定する場合は、図４のノードのスペース部にカーソルを移動させ、「決定」ボタンを操作すると、図５のテーブルが現れるので、語彙、上位ノード番号、下位ノード番号、分類、ノードタイプ、を入力する。ノード番号は、自動的に割り振られる。
【００８７】
上記した実施例では、予め格納した概念グラフに基き「ロケーション」を決定したが、操作部１１及び制御部１０の制御に基づいて、同グラフを外部サーバからダウンロードするようにしてもよい。また、同グラフをユーザが改良してアップロードし、他のユーザに提供するようにしてもよい。
【００８８】
上記した実施例では、「検索式生成部、メタ検索エンジン部、ライブカメラ映像制御部」の各部と「前記各部が使用するデータ」を「ＴＶ側」に持たせたが、例えば、外部サーバを用意し、それらを「外部サーバ側」に持たせて実現してもよい。つまり上記の実施例では、音楽データ管理テーブル（図２）、概念グラフ（図４）のデータファイルが記憶部１４に格納されているとして説明した。しかしこの場所に限らず、音楽データ管理テーブル、概念グラフは、外部のサーバにおいて管理されていてもよい。音楽データ管理テーブル、概念グラフは、外部のサーバにある場合、利用者が選択した楽曲のタイトル名がサーバに送信される。すると、外部のサーバに設けられた検索式生成部及びメタ検索エンジン部が検索を実行し、選択した楽曲に関連するライブカメラのURLが送信されてくる。
【００８９】
図１８には、サーバ側に検索式生成部２０、メタ検索エンジン部２１、ライブカメラ映像制御部２２が設けられた例を示している。また図１と対応する部分には同一符号を付している。このサーバでは、データファイル１４には、それぞれ映像提供地域を示す複数の目的地情報と前記複数の目的地情報の中の１つ又は複数に関連付けされており、かつ楽曲の概念を表す複数の語彙分類ノード情報とを含む概念グラフのデータが格納されている。また受信情報処理部１０aは、外部のクライアント（TV）よりネットワーク１６を介して再生希望の楽曲の情報を受け取ることができる。検索式生成部２０は、楽曲の概念を表す楽曲概念情報と類似又は同一意味の語彙分類ノード情報を前記複数の語彙分類ノード情報中から検索し、検索した語彙分類ノード情報に対応するヒット目的地情報を前記複数の目的地情報の中から抽出し、かつ前記楽曲概念情報を変更して複数回前記検索を実行して、前記選択された楽曲に関連性の高い１つ又は複数のヒット目的地情報を取得する。
【００９０】
メタ検索エンジン部２１は、通信部１５を介して前記１つ又は複数のヒット目的地情報を利用して対応するカメラ配置情報を取得する。すると送信情報処理部１０ｂがカメラ配置情報をクライアントであるTVに送信する。カメラ配置情報を取得する動作は、先の実施例で説明した動作と同じである。上記した概念グラフのデータは、クライアント側で改良されアップロードされたものであってもよい。また、クライアント側で改良された概念グラフデータをサーバ側で管理することにより、複数ユーザにより改良された概念グラフデータを自動的に集約することもできる。概念グラフデータにいわゆる集合知を適用することで、概念グラフデータの精度をさらに高めることが可能となる。
【００９１】
従来技術では、音楽に組み合わせる映像は画一的で、繰り返し見ると飽きるという問題点があった。また、すべての音楽に映像を組み合わせたコンテンツがあるとは限らなかった。
【００９２】
本発明は、上記問題を鑑みたもので、ユーザが任意に選択した音楽について、そのジャンルやタイトルに対応するライブカメラ映像をインターネットから選択/表示することで、ヒーリングと意外性を実現する手段及び装置を提供する。
【産業上の利用可能性】
【００９３】
本発明は、サーバ、セットトップボックス、テレビジョン（TV）受信装置、コンパクトな映像表示装置、録画装置などで音楽概念データ処理するのに有効である。
【符号の説明】
【００９４】
１・・・アンテナ、２・・・チューナ部、４・・・MPEG処理部、５・・・超解像処理部、６・・・LCD制御部、７・・・LCDディスプレイ、８・・・音声出力部、９・・・スピーカー、１０・・・システム制御部、１１・・・操作部、１２・・・リモコン、１３・・・HDD制御部、１４・・・記憶部、１５・・・通信部、１６・・インターネット、１７・・・検索エンジン、１８・・・ライブカメラ、１９・・・音楽再生部、２０・・・検索式生成部、２１・・・メタ検索エンジン部、２２・・・ライブカメラ映像制御部。
【特許請求の範囲】
【請求項１】
それぞれ映像提供地域を示す複数の目的地情報と前記複数の目的地情報の中の１つ又は複数に関連付けされており、かつ楽曲の概念を表す複数の語彙分類ノード情報とを含む概念グラフのデータを格納したデータファイルと、
再生希望の楽曲の情報が与えられたとき、前記楽曲の概念を表す楽曲概念情報と類似又は同一意味の語彙分類ノード情報を前記複数の語彙分類ノード情報中から検索し、検索した語彙分類ノード情報に対応するヒット目的地情報を前記複数の目的地情報の中から抽出し、かつ前記楽曲概念情報を変更して複数回前記検索を実行して、前記選択された楽曲に関連性の高い１つ又は複数のヒット目的地情報を取得する検索部と、
前記１つ又は複数のヒット目的地情報に対応するカメラ配置情報を取得する検索及び通信部と、
を有したことを特徴とする映像表示装置。
【請求項２】
前記データファイルに格納されている前記楽曲概念情報は、楽曲のジャンル、アルバム名、タイトル名のいずれか又は組み合わせ又は全てであり、前記複数の語彙分類ノード情報は、前記ジャンル、アルバム名、タイトル名を表す複数の語彙であることを特徴とする請求項１記載の映像表示装置。
【請求項３】
検索及び通信部は、取得した複数のカメラ配置情報の中から停止しているカメラの配置情報を検索ノイズとして除去し、残りのライブカメラの配置情報をライブカメラ管理テーブルにセットすることを特徴とする請求項１記載の映像表示装置。
【請求項４】
前記複数のカメラ配置情報に基づいて取り込まれるライブカメラ映像の切り替えの有無や、ライブカメラ映像の自動切換え間隔の指定を含むシステム設定を行うための制御部を有することを特徴とする請求項３記載の映像表示装置。
【請求項５】
前記複数のカメラ配置情報に基づいて取り込まれるライブカメラ映像は、予め記録媒体に格納されており、次回に対応するカメラ配置情報が取り込まれたときライブカメラ映像制御部の制御に基づいて再生されることを特徴とする請求項３記載の映像表示装置。
【請求項６】
前記概念グラフのデータは、外部サーバからダウンロードされたデータであることを特徴とする請求項１記載の映像表示装置。
【請求項７】
前記概念グラフのデータは、操作入力より追加/修正を可能としていることを特徴とする請求項１記載の映像表示装置。
【請求項８】
それぞれ映像提供地域を示す複数の目的地情報と前記複数の目的地情報の中の１つ又は複数に関連付けされており、かつ楽曲の概念を表す複数の語彙分類ノード情報とを含む概念グラフのデータを格納したデータファイルと、
外部のクライアントより再生希望の楽曲の情報を受け取る受信情報処理部と、
前記楽曲の概念を表す楽曲概念情報と類似又は同一意味の語彙分類ノード情報を前記複数の語彙分類ノード情報中から検索し、検索した語彙分類ノード情報に対応するヒット目的地情報を前記複数の目的地情報の中から抽出し、かつ前記楽曲概念情報を変更して複数回前記検索を実行して、前記選択された楽曲に関連性の高い１つ又は複数のヒット目的地情報を取得する検索部と、
前記１つ又は複数のヒット目的地情報を利用して対応するカメラ配置情報を取得する検索及び通信部と、
前記カメラ配置情報を前記クライアントに送信する送信情報処理部と
を有したことを特徴とする音楽概念データ処理サーバ。
【請求項９】
前記概念グラフのデータは、前記クライアント側で改良されアップロードされたものであることを特徴とする請求項８記載の音楽概念データ処理サーバ。
【請求項１０】
データファイルと検索部を用いる音楽概念データ処理方法において、
前記データファイルには、
それぞれ映像提供地域を示す複数の目的地情報と前記複数の目的地情報の中の１つ又は複数に関連付けされており、かつ楽曲の概念を表す複数の語彙分類ノード情報とを含む概念グラフのデータを格納しておき、
前記検索部により、
再生用として選択された楽曲の概念を表す楽曲概念情報と類似又は同一意味の語彙分類ノード情報を前記複数の語彙分類ノード情報中から検索し、
検索した語彙分類ノード情報に対応するヒット目的地情報を前記複数の目的地情報の中から抽出し、
かつ前記楽曲概念情報を変更して複数回前記検索を実行して、前記選択された楽曲に関連性の高い１つ又は複数のヒット目的地情報を取得し、
前記１つ又は複数のヒット目的地情報を対応する目的地の映像取得用として出力することを特徴とする音楽概念データ処理方法。
【請求項１】
それぞれ映像提供地域を示す複数の目的地情報と前記複数の目的地情報の中の１つ又は複数に関連付けされており、かつ楽曲の概念を表す複数の語彙分類ノード情報とを含む概念グラフのデータを格納したデータファイルと、
再生希望の楽曲の情報が与えられたとき、前記楽曲の概念を表す楽曲概念情報と類似又は同一意味の語彙分類ノード情報を前記複数の語彙分類ノード情報中から検索し、検索した語彙分類ノード情報に対応するヒット目的地情報を前記複数の目的地情報の中から抽出し、かつ前記楽曲概念情報を変更して複数回前記検索を実行して、前記選択された楽曲に関連性の高い１つ又は複数のヒット目的地情報を取得する検索部と、
前記１つ又は複数のヒット目的地情報に対応するカメラ配置情報を取得する検索及び通信部と、
を有したことを特徴とする映像表示装置。
【請求項２】
前記データファイルに格納されている前記楽曲概念情報は、楽曲のジャンル、アルバム名、タイトル名のいずれか又は組み合わせ又は全てであり、前記複数の語彙分類ノード情報は、前記ジャンル、アルバム名、タイトル名を表す複数の語彙であることを特徴とする請求項１記載の映像表示装置。
【請求項３】
検索及び通信部は、取得した複数のカメラ配置情報の中から停止しているカメラの配置情報を検索ノイズとして除去し、残りのライブカメラの配置情報をライブカメラ管理テーブルにセットすることを特徴とする請求項１記載の映像表示装置。
【請求項４】
前記複数のカメラ配置情報に基づいて取り込まれるライブカメラ映像の切り替えの有無や、ライブカメラ映像の自動切換え間隔の指定を含むシステム設定を行うための制御部を有することを特徴とする請求項３記載の映像表示装置。
【請求項５】
前記複数のカメラ配置情報に基づいて取り込まれるライブカメラ映像は、予め記録媒体に格納されており、次回に対応するカメラ配置情報が取り込まれたときライブカメラ映像制御部の制御に基づいて再生されることを特徴とする請求項３記載の映像表示装置。
【請求項６】
前記概念グラフのデータは、外部サーバからダウンロードされたデータであることを特徴とする請求項１記載の映像表示装置。
【請求項７】
前記概念グラフのデータは、操作入力より追加/修正を可能としていることを特徴とする請求項１記載の映像表示装置。
【請求項８】
それぞれ映像提供地域を示す複数の目的地情報と前記複数の目的地情報の中の１つ又は複数に関連付けされており、かつ楽曲の概念を表す複数の語彙分類ノード情報とを含む概念グラフのデータを格納したデータファイルと、
外部のクライアントより再生希望の楽曲の情報を受け取る受信情報処理部と、
前記楽曲の概念を表す楽曲概念情報と類似又は同一意味の語彙分類ノード情報を前記複数の語彙分類ノード情報中から検索し、検索した語彙分類ノード情報に対応するヒット目的地情報を前記複数の目的地情報の中から抽出し、かつ前記楽曲概念情報を変更して複数回前記検索を実行して、前記選択された楽曲に関連性の高い１つ又は複数のヒット目的地情報を取得する検索部と、
前記１つ又は複数のヒット目的地情報を利用して対応するカメラ配置情報を取得する検索及び通信部と、
前記カメラ配置情報を前記クライアントに送信する送信情報処理部と
を有したことを特徴とする音楽概念データ処理サーバ。
【請求項９】
前記概念グラフのデータは、前記クライアント側で改良されアップロードされたものであることを特徴とする請求項８記載の音楽概念データ処理サーバ。
【請求項１０】
データファイルと検索部を用いる音楽概念データ処理方法において、
前記データファイルには、
それぞれ映像提供地域を示す複数の目的地情報と前記複数の目的地情報の中の１つ又は複数に関連付けされており、かつ楽曲の概念を表す複数の語彙分類ノード情報とを含む概念グラフのデータを格納しておき、
前記検索部により、
再生用として選択された楽曲の概念を表す楽曲概念情報と類似又は同一意味の語彙分類ノード情報を前記複数の語彙分類ノード情報中から検索し、
検索した語彙分類ノード情報に対応するヒット目的地情報を前記複数の目的地情報の中から抽出し、
かつ前記楽曲概念情報を変更して複数回前記検索を実行して、前記選択された楽曲に関連性の高い１つ又は複数のヒット目的地情報を取得し、
前記１つ又は複数のヒット目的地情報を対応する目的地の映像取得用として出力することを特徴とする音楽概念データ処理方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【公開番号】特開２０１０−２１８４２３（Ｐ２０１０−２１８４２３Ａ）
【公開日】平成２２年９月３０日（２０１０．９．３０）
【国際特許分類】
【出願番号】特願２００９−６６６４８（Ｐ２００９−６６６４８）
【出願日】平成２１年３月１８日（２００９．３．１８）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【Ｆターム（参考）】
【公開日】平成２２年９月３０日（２０１０．９．３０）
【国際特許分類】
【出願日】平成２１年３月１８日（２００９．３．１８）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【Ｆターム（参考）】
[ Back to top ]