知財求人 - 知財ポータルサイト「IP Force」
特許7037225バーチャル御神輿イベント提供システム及びバーチャルイベント提供システム
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B1)
(11)【特許番号】
(24)【登録日】2022-03-08
(45)【発行日】2022-03-16
(54)【発明の名称】バーチャル御神輿イベント提供システム及びバーチャルイベント提供システム
(51)【国際特許分類】
G06T 19/00 20110101AFI20220309BHJP
【ＦＩ】
G06T19/00 A
【請求項の数】
12
(21)【出願番号】P 2021122478
(22)【出願日】2021-07-27
【審査請求日】2021-07-27
【早期審査対象出願】
(73)【特許権者】
【識別番号】509200657
【氏名又は名称】小川 祐樹
(74)【代理人】
【識別番号】100155158
【弁理士】
【氏名又は名称】渡部 仁
(72)【発明者】
【氏名】小川 祐樹
【審査官】村松 貴士
(56)【参考文献】
【文献】特開平０９－１１４３６０（ＪＰ，Ａ）
【文献】宮里勉，外1名，“臨場感通信会議におけるマルチモーダルインタラクション”，情報処理学会研究報告，社団法人情報処理学会，1995年，Vol.95, No.73，p.1-8
【文献】岸本征将，外4名，“ジェスチャ認識を利用した祇園祭・粽投げのバーチャル体験”，「人文科学とコンピュータシンポジウム」，社団法人情報処理学会，2019年，p.97-102
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０６Ｔ １９／００
(57)【特許請求の範囲】
【請求項1】
ユーザが利用するユーザ端末と通信可能に接続され、御神輿を担ぐイベントをバーチャル空間にて実施するバーチャル御神輿イベントを前記ユーザに提供するバーチャル御神輿イベント提供システムであって、前記ユーザ端末には、ユーザの動作内容を検出する動作内容検出装置が接続されており、
前記バーチャル御神輿イベントの参加者を募集するための募集情報を登録する募集情報記憶手段に登録された前記募集情報に基づいて、前記バーチャル御神輿イベントの参加者を募集するイベント参加者募集手段と、
前記バーチャル御神輿イベントに対応する御神輿及び当該御神輿を担ぐ場所であるイベント会場の写真データを含むイベント用写真データを登録するイベント用写真データ記憶手段に登録された前記イベント用写真データに基づいて、御神輿の３Ｄモデルである御神輿モデル及びイベント会場の３Ｄモデルであるイベント会場モデルを含むイベント用モデルを生成するイベント用モデル生成手段と、
前記バーチャル御神輿イベントの参加者の写真データである参加者写真データを登録する参加者写真データ記憶手段に登録された前記参加者写真データに基づいて、前記参加者の３Ｄアバターを生成する３Ｄアバター生成手段と、
前記御神輿モデルの担ぎ手として割り当てられたユーザである担ぎ手ユーザの前記ユーザ端末から送信された、前記動作内容検出装置の検出情報に基づいて、当該御神輿モデルの動作及び当該担ぎ手ユーザに対応する３Ｄアバターの動作を制御するモデル動作制御手段と、
前記イベント会場の表示情報並びに前記モデル動作制御手段で動作が制御される前記御神輿モデル及び前記３Ｄアバターの表示情報を含むバーチャル御神輿イベントの提供に必要なイベント提供情報を前記ユーザ端末に送信するイベント提供情報送信手段と、を備えることを特徴とするバーチャル御神輿イベント提供システム。
【請求項2】
請求項１において、前記動作内容検出装置は、ジャイロセンサを有するコントローラ又は撮像装置の少なくとも一方であり、
前記モデル動作制御手段は、前記担ぎ手ユーザの前記ユーザ端末から送信された、前記コントローラを持ったユーザの動作に応じた前記ジャイロセンサの検出値又は前記撮像装置で撮像したユーザの撮像画像データの少なくとも一方に基づいて、当該御神輿モデルの動作及び当該担ぎ手ユーザに対応する３Ｄアバターの動作を制御することを特徴とするバーチャル御神輿イベント提供システム。
【請求項3】
請求項１又は２において、前記モデル動作制御手段は、前記担ぎ手ユーザの動作タイミングが予め設定した動作タイミングと一致するか否かを判定し、一致すると判定した場合に予め設定された一致用の動作をするように前記御神輿モデルの動作及び前記３Ｄアバターの動作を制御し、一致しないと判定した場合に予め設定された不一致用の動作をするように前記御神輿モデルの動作及び前記３Ｄアバターの動作を制御することを特徴とするバーチャル御神輿イベント提供システム。
【請求項4】
請求項３において、御神輿の備える鈴の音の音響情報を含むイベント用音響情報を登録するイベント用音響情報記憶手段に登録された前記イベント用音響情報に基づいて、前記バーチャル御神輿イベント中に出力する出力用音響情報を生成する出力用音響情報生成手段をさらに備え、
前記イベント提供情報送信手段は、前記出力用音響情報生成手段で生成された出力用音響情報を前記イベント提供情報として前記ユーザ端末に送信するようになっており、
前記出力用音響情報生成手段は、前記モデル動作制御手段で前記担ぎ手ユーザの動作タイミングが一致すると判定した場合に、前記出力用音響情報として一致用の鈴の音を鳴らす音響情報を生成し、一致しないと判定した場合に予め設定された不一致用の鈴の音を鳴らす出力用音響情報を生成するか、鈴の音を鳴らさない出力用音響情報を生成するか又は出力用音響情報を生成しないようになっていることを特徴とするバーチャル御神輿イベント提供システム。
【請求項5】
請求項３又は４において、前記モデル動作制御手段は、前記御神輿モデルの担ぎ手のうちからリーダーを選定し、選定したリーダーの動作タイミングを、前記予め設定した動作タイミングとすることを特徴とするバーチャル御神輿イベント提供システム。
【請求項6】
請求項３乃至５のいずれか１項において、前記イベント提供情報送信手段は、前記モデル動作制御手段で前記担ぎ手ユーザの動作タイミングが一致しないと判定した場合に、当該動作タイミングが一致しない原因となった担ぎ手ユーザのユーザ端末に、前記イベント提供情報として、前記動作タイミングを修正するためのタイミング修正情報を送信することを特徴とするバーチャル御神輿イベント提供システム。
【請求項7】
請求項３乃至６のいずれか１項において、複数の前記御神輿モデルが登場するバーチャル御神輿イベントにおいて、御神輿モデルごとに前記担ぎ手ユーザの前記動作タイミングを評価する動作タイミング評価手段と、
前記動作タイミング評価手段の評価結果に基づいて、前記御神輿モデルごとに順位を決定する順位決定手段と、をさらに備えることを特徴とするバーチャル御神輿イベント提供システム。
【請求項8】
請求項１乃至７のいずれか１項において、前記募集情報は、募集人数の情報及び募集期限の情報を含み、
前記イベント参加者募集手段は、前記募集情報に基づいて参加人数の上限又は下限及び募集期限を含む参加者募集用の回覧情報を生成し、過去にバーチャル御神輿イベントに参加したことのある登録ユーザのなかから代表ユーザを選定し、選定した代表ユーザの前記ユーザ端末に前記回覧情報を送信するようになっており、
前記ユーザ端末は、
受信した前記回覧情報に対してバーチャル御神輿イベントへの参加の可否を示す情報を付加する参加可否情報付加手段と、
受信した回覧情報に対して次の回覧先のユーザの情報を付加する回覧先情報付加手段と、
前記参加の可否を示す情報及び前記次の回覧先のユーザの情報が付加された回覧情報を当該次の回覧先のユーザの前記ユーザ端末に送信する第１回覧情報送信手段と、
前記参加の可否を示す情報が付加された回覧情報に基づいて、当該回覧情報に対応するバーチャル御神輿イベントの参加人数が規定に達している又は現在の日時が募集期限に達していると判定した場合に、当該回覧情報を前記代表ユーザの前記ユーザ端末に送信する第２回覧情報送信手段と、
当該ユーザ端末のユーザが代表ユーザに設定されており且つ前記参加人数が規定に達しているか又は受信日時が募集期限に達している回覧情報を受信した場合に、受信した回覧情報に基づいて参加メンバーを確定し、確定した参加メンバーの情報を当該バーチャル御神輿イベント提供システムの管理下にある端末に送信するメンバー情報送信手段とを備えることを特徴とするバーチャル御神輿イベント提供システム。
【請求項9】
請求項８において、前記イベント参加者募集手段は、登録した各ユーザの前記回覧情報の回覧先に選択された回数を計数するとともに計数した回数をユーザ情報記憶手段に登録し、当該ユーザ情報記憶手段に登録された前記回数に基づいて代表ユーザを選定することを特徴とするバーチャル御神輿イベント提供システム。
【請求項10】
請求項１乃至９のいずれか１項において、前記御神輿モデルの移動する移動ルートの設定を担当する担当者が利用する担当者端末が通信可能に接続され、
前記担当者端末からの指示情報に基づいて、実際の地形、建物、道路を撮像した撮像画像データに基づいて構成された３Ｄマップデータを有する地図アプリケーションソフトの提供する地図上で、１又は複数のイベント開催地及びスタート地点からゴール地点までの前記移動ルートを設定するルート設定手段をさらに備え、
前記イベント用モデル生成手段は、前記ルート設定手段で設定された１又は複数の前記イベント開催地及び前記移動ルートに対応する前記３Ｄマップデータに基づいて、前記イベント会場モデルを生成することを特徴とするバーチャル御神輿イベント提供システム。
【請求項11】
請求項１０において、前記ルート設定手段は、前記担当者端末を介した前記担当者からの要求に応じて、前記御神輿モデルの移動ルートとして、前記バーチャル御神輿イベントに参加する複数の参加者の住居の近くをなるべく多く通るルート、車通りが比較的少ないルート、道幅が比較的広いルート又は過去採用したルートを、要求元の前記担当者に推奨することを特徴とするバーチャル御神輿イベント提供システム。
【請求項12】
ユーザが利用するユーザ端末と通信可能に接続され、複数の参加者が同一の対象物の動作を制御するイベントをバーチャル空間にて実施するバーチャルイベントを前記ユーザに提供するバーチャルイベント提供システムであって、前記ユーザ端末には、ユーザの動作内容を検出する動作内容検出装置が接続されており、
前記バーチャルイベントの参加者を募集するための募集情報を登録する募集情報記憶手段に登録された前記募集情報に基づいて、前記バーチャルイベントの参加者を募集するイベント参加者募集手段と、
前記バーチャルイベントに対応する前記対象物及び当該対象物の動作を制御する場所であるイベント会場の写真データを含むイベント用写真データを登録するイベント用写真データ記憶手段に登録された前記イベント用写真データに基づいて、前記対象物の３Ｄモデルである対象物モデル及びイベント会場の３Ｄモデルであるイベント会場モデルを含むイベント用モデルを生成するイベント用モデル生成手段と、
前記バーチャルイベントの参加者の写真データである参加者写真データを登録する参加者写真データ記憶手段に登録された前記参加者写真データに基づいて、前記参加者の３Ｄアバターを生成する３Ｄアバター生成手段と、
前記対象物モデルに割り当てられたユーザである割り当てユーザの前記ユーザ端末から送信された、前記動作内容検出装置の検出情報に基づいて、当該対象物モデルの動作及び前記割り当てユーザに対応する３Ｄアバターの動作を制御するモデル動作制御手段と、
前記イベント会場の表示情報並びに前記モデル動作制御手段で動作が制御される前記対象物モデル及び前記３Ｄアバターの表示情報を含むバーチャルイベントの提供に必要なイベント提供情報を、前記ユーザ端末に送信するイベント提供情報送信手段と、を備えることを特徴とするバーチャルイベント提供システム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、御神輿を担ぐイベントをバーチャル空間上で実現したバーチャル御神輿イベントを提供するバーチャル御神輿イベント提供システムに関する。
【背景技術】
【0002】
従来、オンラインゲーム内で実行されるイベント等に合わせて、ユーザに複雑な操作を行なわせることなく、アバターに複雑な動作をさせることで、オンラインゲームの趣向性を向上させることができる仮想モデル表示システムの発明がある（特許文献１を参照）。
かかる仮想モデル表示システムでは、例えば、ユーザのマウス等のコントローラの操作によって、お祭りやぐらのオブジェクトの近くにアバターを移動させることで、予め用意されたアニメーションデータに基づいてアバターが複雑な動作で盆踊りを踊りだすといったものである。
かかる仮想モデル表示システムでは、例えば、ユーザのマウス等のコントローラの操作によって、お祭りやぐらのオブジェクトの近くにアバターを移動させることで、予め用意されたアニメーションデータに基づいてアバターが複雑な動作で盆踊りを踊りだすといったものである。
【先行技術文献】
【特許文献】
【0003】
【文献】特許４６２７８０２号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
しかしながら、特許文献１の従来技術では、ユーザは、コントローラを操作してアバターを所定位置に移動させるのみで、後は、コンピュータがアバターを自動で動作させる。そのため、所定位置に移動後は、ユーザはコンピュータによって制御されたアバターの動作を見ているだけとなり、ユーザの実際の動作（例えば、手を振る、踊るなどの動作）がアバターの動作に反映されるといったことがない。そのため、例えば、複数の参加者がタイミングを合わせて動作を行って同一の御神輿を担ぐようなイベントをバーチャル化した場合に、参加者全員の実際の動作に応じたアバターの動作及び御神輿の３Ｄモデル（以下、「御神輿モデル」という）の動作を表現することができない。
【0005】
そこで、本発明は、このような従来の技術の有する未解決の課題に着目してなされたものであって、バーチャル御神輿イベントにおいて、同一の御神輿モデルの担ぎ手に割り当てられた参加者の実際の動作を３Ｄアバター及び御神輿モデルの動作に反映させることができるバーチャル御神輿イベント提供システムを提供することを目的としている。
【課題を解決するための手段】
【0006】
〔発明１〕 上記目的を達成するために、発明１のバーチャル御神輿イベント提供システムは、ユーザが利用するユーザ端末と通信可能に接続され、御神輿を担ぐイベントをバーチャル空間にて実施するバーチャル御神輿イベントを前記ユーザに提供するバーチャル御神輿イベント提供システムであって、前記ユーザ端末には、ユーザの動作内容を検出する動作内容検出装置が接続されており、前記バーチャル御神輿イベントの参加者を募集するための募集情報を登録する募集情報記憶手段に登録された前記募集情報に基づいて、前記バーチャル御神輿イベントの参加者を募集するイベント参加者募集手段と、前記バーチャル御神輿イベントに対応する御神輿及び当該御神輿を担ぐ場所であるイベント会場の写真データを含むイベント用写真データを登録するイベント用写真データ記憶手段に登録された前記イベント用写真データに基づいて、御神輿の３Ｄモデルである御神輿モデル及びイベント会場の３Ｄモデルであるイベント会場モデルを含むイベント用モデルを生成するイベント用モデル生成手段と、前記バーチャル御神輿イベントの参加者の写真データである参加者写真データを登録する参加者写真データ記憶手段に登録された前記参加者写真データに基づいて、前記参加者の３Ｄアバターを生成する３Ｄアバター生成手段と、前記御神輿モデルの担ぎ手として割り当てられたユーザである担ぎ手ユーザの前記ユーザ端末から送信された、前記動作内容検出装置の検出情報に基づいて、当該御神輿モデルの動作及び当該担ぎ手ユーザに対応する３Ｄアバターの動作を制御するモデル動作制御手段と、前記イベント会場の表示情報並びに前記モデル動作制御手段で動作が制御される前記御神輿モデル及び前記３Ｄアバターの表示情報を含むバーチャル御神輿イベントの提供に必要なイベント提供情報を前記ユーザ端末に送信するイベント提供情報送信手段と、を備える。
【0007】
このような構成であれば、イベント参加者募集手段によって、募集情報記憶手段に登録された募集情報に基づいてバーチャル御神輿イベントの参加者が募集され、イベント用モデル生成手段によって、イベント用写真データ記憶手段に登録されたイベント用写真データに基づいてイベント用モデルが生成される。加えて、３Ｄアバター生成手段によって、参加者写真データ記憶手段に登録された参加者写真データに基づいて３Ｄアバターが生成され、モデル動作制御手段によって、御神輿モデルの担ぎ手ユーザのユーザ端末から送信された、動作内容検出装置の検出情報に基づいて、御神輿モデルの動作及び担ぎ手ユーザに対応する３Ｄアバターの動作が制御される。そして、イベント提供情報送信手段によって、イベント会場の表示情報並びにモデル動作制御手段で動作が制御される御神輿モデル及び３Ｄアバターの表示情報を含むイベント提供情報がユーザ端末に送信される。
【0008】
ここで、ユーザ端末は、例えば、ユーザの管理下にあるＰＣ、ノートＰＣ、タブレット、スマートフォンなどの端末の他、ゲームセンター、アミューズメントセンター等の遊技施設に設置された端末（ゲーム機械等を含む）などのユーザの管理下にない端末も含む。
また、動作内容検出装置は、ユーザの動作内容を検出できる機能を有するものであり、例えば、多軸ジャイロセンサ、圧力センサ等が搭載されたコントローラ、ビデオカメラ、モーションキャプチャデバイス等が該当する。
また、本システムは、単一の装置、端末その他の機器として実現するようにしてもよいし、複数の装置、端末その他の機器を通信可能に接続したネットワークシステムとして実現するようにしてもよい。後者の場合、各構成要素は、それぞれ通信可能に接続されていれば、複数の機器等のうちいずれに属していてもよい。
また、動作内容検出装置は、ユーザの動作内容を検出できる機能を有するものであり、例えば、多軸ジャイロセンサ、圧力センサ等が搭載されたコントローラ、ビデオカメラ、モーションキャプチャデバイス等が該当する。
また、本システムは、単一の装置、端末その他の機器として実現するようにしてもよいし、複数の装置、端末その他の機器を通信可能に接続したネットワークシステムとして実現するようにしてもよい。後者の場合、各構成要素は、それぞれ通信可能に接続されていれば、複数の機器等のうちいずれに属していてもよい。
【0009】
〔発明２〕 さらに、発明２のバーチャル御神輿イベント提供システムは、発明１のバーチャル御神輿イベント提供システムにおいて、前記動作内容検出装置は、ジャイロセンサを有するコントローラ又は撮像装置の少なくとも一方であり、前記モデル動作制御手段は、前記担ぎ手ユーザの前記ユーザ端末から送信された、前記コントローラを持ったユーザの動作に応じた前記ジャイロセンサの検出値又は前記撮像装置で撮像したユーザの撮像画像データの少なくとも一方に基づいて、当該御神輿モデルの動作及び当該担ぎ手ユーザに対応する３Ｄアバターの動作を制御する。
【0010】
このような構成であれば、モデル動作制御手段によって、担ぎ手ユーザのユーザ端末から送信された、コントローラを持ったユーザの動作に応じたジャイロセンサの検出値又は撮像装置で撮像したユーザの撮像画像データの少なくとも一方に基づいて、御神輿モデルの動作及び担ぎ手ユーザに対応する３Ｄアバターの動作が制御される。
〔発明３〕 さらに、発明３のバーチャル御神輿イベント提供システムは、発明１又は２のバーチャル御神輿イベント提供システムにおいて、前記モデル動作制御手段は、前記担ぎ手ユーザの動作タイミングが予め設定した動作タイミングと一致するか否かを判定し、一致すると判定した場合に予め設定された一致用の動作をするように前記御神輿モデルの動作及び前記３Ｄアバターの動作を制御し、一致しないと判定した場合に予め設定された不一致用の動作をするように前記御神輿モデルの動作及び前記３Ｄアバターの動作を制御する。
〔発明３〕 さらに、発明３のバーチャル御神輿イベント提供システムは、発明１又は２のバーチャル御神輿イベント提供システムにおいて、前記モデル動作制御手段は、前記担ぎ手ユーザの動作タイミングが予め設定した動作タイミングと一致するか否かを判定し、一致すると判定した場合に予め設定された一致用の動作をするように前記御神輿モデルの動作及び前記３Ｄアバターの動作を制御し、一致しないと判定した場合に予め設定された不一致用の動作をするように前記御神輿モデルの動作及び前記３Ｄアバターの動作を制御する。
【0011】
このような構成であれば、モデル動作制御手段によって、担ぎ手ユーザの動作タイミングが予め設定した動作タイミングと一致するか否かを判定し、一致すると判定した場合に予め設定された一致用の動作をするように御神輿モデルの動作及びＤアバターの動作が制御され、一致しないと判定した場合に予め設定された不一致用の動作をするように御神輿モデルの動作及び３Ｄアバターの動作が制御される。
〔発明４〕 さらに、発明４のバーチャル御神輿イベント提供システムは、発明３のバーチャル御神輿イベント提供システムにおいて、御神輿の備える鈴の音の音響情報を含むイベント用音響情報を登録するイベント用音響情報記憶手段に登録された前記イベント用音響情報に基づいて、前記バーチャル御神輿イベント中に出力する出力用音響情報を生成する出力用音響情報生成手段をさらに備え、前記イベント提供情報送信手段は、前記出力用音響情報生成手段で生成された出力用音響情報を前記イベント提供情報として前記ユーザ端末に送信するようになっており、前記出力用音響情報生成手段は、前記モデル動作制御手段で前記担ぎ手ユーザの動作タイミングが一致すると判定された場合に、前記出力用音響情報として一致用の鈴の音を鳴らす音響情報を生成し、一致しないと判定した場合に予め設定された不一致用の鈴の音を鳴らす出力用音響情報を生成するか、鈴の音を鳴らさない出力用音響情報を生成するか又は出力用音響情報を生成しないようになっている。
〔発明４〕 さらに、発明４のバーチャル御神輿イベント提供システムは、発明３のバーチャル御神輿イベント提供システムにおいて、御神輿の備える鈴の音の音響情報を含むイベント用音響情報を登録するイベント用音響情報記憶手段に登録された前記イベント用音響情報に基づいて、前記バーチャル御神輿イベント中に出力する出力用音響情報を生成する出力用音響情報生成手段をさらに備え、前記イベント提供情報送信手段は、前記出力用音響情報生成手段で生成された出力用音響情報を前記イベント提供情報として前記ユーザ端末に送信するようになっており、前記出力用音響情報生成手段は、前記モデル動作制御手段で前記担ぎ手ユーザの動作タイミングが一致すると判定された場合に、前記出力用音響情報として一致用の鈴の音を鳴らす音響情報を生成し、一致しないと判定した場合に予め設定された不一致用の鈴の音を鳴らす出力用音響情報を生成するか、鈴の音を鳴らさない出力用音響情報を生成するか又は出力用音響情報を生成しないようになっている。
【0012】
このような構成であれば、出力用音響情報生成手段によって、イベント用音響情報記憶手段に登録されたイベント用音響情報に基づいて、バーチャル御神輿イベント中に出力する出力用音響情報が生成され、イベント提供情報送信手段によって、出力用音響情報生成手段で生成された出力用音響情報がイベント提供情報としてユーザ端末に送信される。加えて、出力用音響情報生成手段によって、モデル動作制御手段で担ぎ手ユーザの動作タイミングが一致すると判定した場合に、出力用音響情報として一致用の鈴の音を鳴らす音響情報が生成され、一致しないと判定した場合に予め設定された不一致用の鈴の音を鳴らす出力用音響情報が生成されるか、鈴の音を鳴らさない出力用音響情報が生成されるか又は出力用音響情報が生成されない。
【0013】
〔発明５〕 さらに、発明５のバーチャル御神輿イベント提供システムは、発明３又は４のバーチャル御神輿イベント提供システムにおいて、前記モデル動作制御手段は、前記御神輿モデルの担ぎ手のうちからリーダーを選定し、選定したリーダーの動作タイミングを、前記予め設定した動作タイミングとする。
このような構成であれば、モデル動作制御手段によって、御神輿モデルの担ぎ手のうちからリーダーが選定され、選定されたリーダーの動作タイミングが予め設定された動作タイミングとされる。
このような構成であれば、モデル動作制御手段によって、御神輿モデルの担ぎ手のうちからリーダーが選定され、選定されたリーダーの動作タイミングが予め設定された動作タイミングとされる。
【0014】
〔発明６〕 さらに、発明５のバーチャル御神輿イベント提供システムは、発明３乃至５のいずれか１のバーチャル御神輿イベント提供システムにおいて、前記イベント提供情報送信手段は、前記モデル動作制御手段で前記担ぎ手ユーザの動作タイミングが一致しないと判定した場合に、当該動作タイミングが一致しない原因となった担ぎ手ユーザのユーザ端末に、前記イベント提供情報として、前記動作タイミングを修正するためのタイミング修正情報を送信する。
【0015】
このような構成であれば、イベント提供情報送信手段によって、モデル動作制御手段で担ぎ手ユーザの動作タイミングが一致しないと判定した場合に、動作タイミングが一致しない原因となった担ぎ手ユーザのユーザ端末に、イベント提供情報として、動作タイミングを修正するためのタイミング修正情報が送信される。
〔発明７〕 さらに、発明７のバーチャル御神輿イベント提供システムは、発明３乃至６のいずれか１のバーチャル御神輿イベント提供システムにおいて、複数の前記御神輿モデルが登場するバーチャル御神輿イベントにおいて、御神輿モデルごとに前記担ぎ手ユーザの前記動作タイミングを評価する動作タイミング評価手段と、前記動作タイミング評価手段の評価結果に基づいて、前記御神輿モデルごとに順位を決定する順位決定手段と、をさらに備える。
〔発明７〕 さらに、発明７のバーチャル御神輿イベント提供システムは、発明３乃至６のいずれか１のバーチャル御神輿イベント提供システムにおいて、複数の前記御神輿モデルが登場するバーチャル御神輿イベントにおいて、御神輿モデルごとに前記担ぎ手ユーザの前記動作タイミングを評価する動作タイミング評価手段と、前記動作タイミング評価手段の評価結果に基づいて、前記御神輿モデルごとに順位を決定する順位決定手段と、をさらに備える。
【0016】
このような構成であれば、動作タイミング評価手段によって、複数の御神輿モデルが登場するバーチャル御神輿イベントにおいて、御神輿モデルごとに担ぎ手ユーザの動作タイミングが評価され、順位決定手段によって、動作タイミング評価手段の評価結果に基づいて、御神輿モデルごとに順位が決定される。
〔発明８〕 さらに、発明８のバーチャル御神輿イベント提供システムは、発明１乃至７のいずれか１のバーチャル御神輿イベント提供システムにおいて、前記募集情報は、募集人数の情報及び募集期限の情報を含み、前記イベント参加者募集手段は、前記募集情報に基づいて参加人数の上限又は下限及び募集期限を含む参加者募集用の回覧情報を生成し、過去にバーチャル御神輿イベントに参加したことのある登録ユーザのなかから代表ユーザを選定し、選定した代表ユーザの前記ユーザ端末に前記回覧情報を送信するようになっており、前記ユーザ端末は、受信した前記回覧情報に対してバーチャル御神輿イベントへの参加の可否を示す情報を付加する参加可否情報付加手段と、受信した回覧情報に対して次の回覧先のユーザの情報を付加する回覧先情報付加手段と、前記参加の可否を示す情報及び前記次の回覧先のユーザの情報が付加された回覧情報を当該次の回覧先のユーザの前記ユーザ端末に送信する第１回覧情報送信手段と、前記参加の可否を示す情報が付加された回覧情報に基づいて、当該回覧情報に対応するバーチャル御神輿イベントの参加人数が規定に達している又は現在の日時が募集期限に達していると判定した場合に、当該回覧情報を前記代表ユーザの前記ユーザ端末に送信する第２回覧情報送信手段と、当該ユーザ端末のユーザが代表ユーザに設定されており且つ前記参加人数が規定に達しているか又は受信日時が募集期限に達している回覧情報を受信した場合に、受信した回覧情報に基づいて参加メンバーを確定し、確定した参加メンバーの情報を当該バーチャル御神輿イベント提供システムの管理下にある端末に送信するメンバー情報送信手段とを備える。
〔発明８〕 さらに、発明８のバーチャル御神輿イベント提供システムは、発明１乃至７のいずれか１のバーチャル御神輿イベント提供システムにおいて、前記募集情報は、募集人数の情報及び募集期限の情報を含み、前記イベント参加者募集手段は、前記募集情報に基づいて参加人数の上限又は下限及び募集期限を含む参加者募集用の回覧情報を生成し、過去にバーチャル御神輿イベントに参加したことのある登録ユーザのなかから代表ユーザを選定し、選定した代表ユーザの前記ユーザ端末に前記回覧情報を送信するようになっており、前記ユーザ端末は、受信した前記回覧情報に対してバーチャル御神輿イベントへの参加の可否を示す情報を付加する参加可否情報付加手段と、受信した回覧情報に対して次の回覧先のユーザの情報を付加する回覧先情報付加手段と、前記参加の可否を示す情報及び前記次の回覧先のユーザの情報が付加された回覧情報を当該次の回覧先のユーザの前記ユーザ端末に送信する第１回覧情報送信手段と、前記参加の可否を示す情報が付加された回覧情報に基づいて、当該回覧情報に対応するバーチャル御神輿イベントの参加人数が規定に達している又は現在の日時が募集期限に達していると判定した場合に、当該回覧情報を前記代表ユーザの前記ユーザ端末に送信する第２回覧情報送信手段と、当該ユーザ端末のユーザが代表ユーザに設定されており且つ前記参加人数が規定に達しているか又は受信日時が募集期限に達している回覧情報を受信した場合に、受信した回覧情報に基づいて参加メンバーを確定し、確定した参加メンバーの情報を当該バーチャル御神輿イベント提供システムの管理下にある端末に送信するメンバー情報送信手段とを備える。
【0017】
このような構成であれば、イベント参加者募集手段によって、参加人数の上限又は下限及び募集期限を含む参加者募集用の回覧情報が生成され、登録ユーザのなかから代表ユーザが選定され、選定された代表ユーザのユーザ端末に回覧情報が送信される。加えて、ユーザ端末では、参加可否情報付加手段によって、受信した回覧情報に対してバーチャル御神輿イベントの参加の可否を示す情報が付加され、回覧先情報付加手段によって、受信した回覧情報に対して次の回覧先のユーザの情報が付加され、第１回覧情報送信手段によって、参加の可否を示す情報及び次の回覧先のユーザの情報が付加された回覧情報が次の回覧先のユーザのユーザ端末に送信される。さらに、第２回覧情報送信手段によって、参加人数が規定に達している又は現在の日時が募集期限に達していると判定した回覧情報が代表ユーザのユーザ端末に送信される。なおさらに、ユーザ端末を利用するユーザが代表ユーザである場合に、メンバー情報送信手段によって、参加人数が規定に達している又は現在の日時が募集期限に達している回覧情報を受信した場合に、受信した回覧情報に基づいて参加メンバーが確定され、確定された参加メンバーの情報がバーチャル御神輿イベント提供システムの管理下にある端末に送信される。
【0018】
〔発明９〕 さらに、発明９のバーチャル御神輿イベント提供システムは、発明８のバーチャル御神輿イベント提供システムにおいて、前記イベント参加者募集手段は、登録した各ユーザの前記回覧情報の回覧先に選択された回数を計数するとともに計数した回数をユーザ情報記憶手段に登録し、当該ユーザ情報記憶手段に登録された前記回数に基づいて代表ユーザを選定する。
このような構成であれば、イベント参加者募集手段によって、登録されたユーザごとに回覧情報の回覧先に選択された回数が計数され、計数された回数がユーザ情報記憶手段に登録される。加えて、ユーザ情報記憶手段に登録された回数に基づいて、代表ユーザが選定される。
このような構成であれば、イベント参加者募集手段によって、登録されたユーザごとに回覧情報の回覧先に選択された回数が計数され、計数された回数がユーザ情報記憶手段に登録される。加えて、ユーザ情報記憶手段に登録された回数に基づいて、代表ユーザが選定される。
【0019】
〔発明１０〕 さらに、発明１０のバーチャル御神輿イベント提供システムは、発明１乃至９のいずれか１のバーチャル御神輿イベント提供システムにおいて、前記御神輿モデルの移動する移動ルートの設定を担当する担当者が利用する担当者端末が通信可能に接続され、
前記担当者端末からの指示情報に基づいて、実際の地形、建物、道路等を撮像した撮像画像データに基づいて構成された３Ｄマップデータを有する地図アプリケーションソフトの提供する地図上で、１又は複数のイベント開催地及びスタート地点からゴール地点までの前記移動ルートを設定するルート設定手段をさらに備え、
前記イベント用モデル生成手段は、前記ルート設定手段で設定された１又は複数の前記イベント開催地及び前記移動ルートに対応する前記３Ｄマップデータに基づいて、前記イベント会場モデルを生成する。
前記担当者端末からの指示情報に基づいて、実際の地形、建物、道路等を撮像した撮像画像データに基づいて構成された３Ｄマップデータを有する地図アプリケーションソフトの提供する地図上で、１又は複数のイベント開催地及びスタート地点からゴール地点までの前記移動ルートを設定するルート設定手段をさらに備え、
前記イベント用モデル生成手段は、前記ルート設定手段で設定された１又は複数の前記イベント開催地及び前記移動ルートに対応する前記３Ｄマップデータに基づいて、前記イベント会場モデルを生成する。
【0020】
このような構成であれば、ルート設定手段によって、担当者端末からの指示情報に基づいて、３Ｄマップデータを有する地図アプリケーションソフトの提供する地図上で、１又は複数のイベント開催地及びスタート地点からゴール地点までの御神輿モデルの移動ルートが設定される。加えて、イベント用モデル生成手段によって、ルート設定手段で設定された１又は複数のイベント開催地及び移動ルートに対応する３Ｄマップデータに基づいてイベント会場モデルが生成される。
【0021】
〔発明１１〕 さらに、発明１１のバーチャル御神輿イベント提供システムは、発明１０のバーチャル御神輿イベント提供システムにおいて、前記ルート設定手段は、前記担当者端末を介した前記担当者からの要求に応じて、前記御神輿モデルの移動ルートとして、前記バーチャル御神輿イベントに参加する複数の参加者の住居の近くを比較的多く通るルート、車通りが比較的少ないルート、道幅が比較的広いルート又は過去採用したルートを、要求元の前記担当者に推奨する。
【0022】
このような構成であれば、ルート設定手段によって、担当者端末からの要求に応じて、御神輿モデルの移動ルートとして、バーチャル御神輿イベントに参加する複数の参加者の住居の近くを比較的多く通るルート、車通りが比較的少ないルート、道幅が比較的広いルート又は過去採用したルートが、要求元の担当者に推奨される。
【発明の効果】
【0023】
以上説明したように、発明１のバーチャル御神輿イベント提供システムによれば、ユーザの動作内容を御神輿モデル及び３Ｄアバターの動作制御に反映することができるので、従来と比較して、ユーザのイベントへの寄与度を向上することができる。その結果、バーチャル御神輿イベントの興趣を向上することができる。
また、発明２のバーチャル御神輿イベント提供システムによれば、ジャイロセンサを搭載したコントローラ又は撮像装置の撮像画像の少なくとも一方によってユーザの動作タイミング又はユーザの動作姿勢等の情報を得ることができ、ユーザのより細かい動作内容を反映した動作制御を行うことができる。
また、発明２のバーチャル御神輿イベント提供システムによれば、ジャイロセンサを搭載したコントローラ又は撮像装置の撮像画像の少なくとも一方によってユーザの動作タイミング又はユーザの動作姿勢等の情報を得ることができ、ユーザのより細かい動作内容を反映した動作制御を行うことができる。
【0024】
また、発明３のバーチャル御神輿イベント提供システムによれば、複数の担ぎ手の動作タイミングを一致させるというゲーム性を付与することができるとともに、一致時と不一致時とで動作内容を異ならせるようにしたので、イベントの興趣を向上できるとともに、イベント中の御神輿を担ぐ動作に対するユーザの意欲（やる気）を向上することができる。
また、発明４のバーチャル御神輿イベント提供システムによれば、複数の担ぎ手の動作タイミングを一致させるというゲーム性を付与することができるとともに、一致時と不一致時とで動作内容及び鈴の音の音響出力内容を異ならせるようにしたので、イベントの興趣を向上できるとともに、イベント中の御神輿を担ぐ動作に対するユーザの意欲（やる気）を向上することができる。
また、発明４のバーチャル御神輿イベント提供システムによれば、複数の担ぎ手の動作タイミングを一致させるというゲーム性を付与することができるとともに、一致時と不一致時とで動作内容及び鈴の音の音響出力内容を異ならせるようにしたので、イベントの興趣を向上できるとともに、イベント中の御神輿を担ぐ動作に対するユーザの意欲（やる気）を向上することができる。
【0025】
また、発明５のバーチャル御神輿イベント提供システムによれば、リーダーの動作タイミングとの一致判定が行われるので、リーダー以外の担ぎ手ユーザはリーダーに対応する３Ｄアバターの動作タイミングに合わせて動作を行うことで容易に動作タイミングを合わせることができる。
また、発明６のバーチャル御神輿イベント提供システムによれば、タイミング不一致の原因となっている不一致ユーザは、タイミング修正情報によって、動作タイミングをどのように修正すればよいか解るので、担ぎ中のタイミング修正を容易に行うことができる。
また、発明６のバーチャル御神輿イベント提供システムによれば、タイミング不一致の原因となっている不一致ユーザは、タイミング修正情報によって、動作タイミングをどのように修正すればよいか解るので、担ぎ中のタイミング修正を容易に行うことができる。
【0026】
また、発明７のバーチャル御神輿イベント提供システムによれば、御神輿モデルごとに担ぎ手の動作タイミングを評価し、その評価結果に基づいて御神輿モデルごとに順位付けを行うようにしたので、各御神輿モデルを担ぐ担ぎ手のグループ間で順位を競うことができる。その結果、担ぎ手ユーザのバーチャル御神輿イベントに対する参加意欲等を向上することができる。
また、発明８のバーチャル御神輿イベント提供システムによれば、代表ユーザを起点に、例えば代表ユーザの知人及び回覧先に選ばれた各ユーザの知人等に回覧情報を回すことができるので、参加メンバーを集めやすくすることができる。
また、発明８のバーチャル御神輿イベント提供システムによれば、代表ユーザを起点に、例えば代表ユーザの知人及び回覧先に選ばれた各ユーザの知人等に回覧情報を回すことができるので、参加メンバーを集めやすくすることができる。
【0027】
また、発明９のバーチャル御神輿イベント提供システムによれば、例えば、回覧先として選択された回数の多いユーザを代表ユーザとして選定することができるので、比較的人気の高い（知人の多い）ユーザを起点に回覧情報を回覧することができる。その結果、参加メンバーをより集めやすくすることができる。
また、発明１０のバーチャル御神輿イベント提供システムによれば、御神輿モデルの移動ルートを簡易に設定することができることに加えて、設定した移動ルートによるイベント会場モデルを容易に生成することができる。また、実在するイベントにおける御神輿の移動ルートに縛られずに、オリジナルの移動ルートへの変更も簡易に行うことができる。
また、発明１０のバーチャル御神輿イベント提供システムによれば、御神輿モデルの移動ルートを簡易に設定することができることに加えて、設定した移動ルートによるイベント会場モデルを容易に生成することができる。また、実在するイベントにおける御神輿の移動ルートに縛られずに、オリジナルの移動ルートへの変更も簡易に行うことができる。
【0028】
また、発明１１のバーチャル御神輿イベント提供システムによれば、イベント会場の設定を担当する担当者は、御神輿モデルの移動ルートを、推奨された候補のうちから選択することができるので、容易に移動ルートの設定を行うことができる。
【図面の簡単な説明】
【0029】
【図1】本実施の形態に係るネットワークシステムの構成を示すブロック図である。
【図2】バーチャル御神輿イベント提供サーバ１００のハードウェア構成の一例を示す図である。
【図3】（ａ）～（ｃ）は、ユーザ情報管理テーブル４００、募集情報テーブル４１０及びイベント参加者管理テーブル４１５のデータ構造を示す図である。
【図4】（ａ）～（ｅ）は、イベント用写真データ管理テーブル４２０、イベント用モデル管理テーブル４３０、参加者写真データ管理テーブル４４０、アバター管理テーブル４５０及び音響データ管理テーブル４６０のデータ構造を示す図である。
【図5】イベント参加者募集処理を示すフローチャートである。
【図6】イベント用モデル生成処理を示すフローチャートである。
【図7】３Ｄアバター生成処理を示すフローチャートである。
【図8】第１の実施の形態に係るモデル動作制御処理を示すフローチャートである。
【図9】第１の実施の形態に係る御神輿を担ぎ中のモデル動作制御処理を示すフローチャートである。
【図10】イベント参加中の担ぎ手ユーザＡの動作状態の一例を示す図である。
【図11】複数の３Ｄアバター７００が御神輿モデル６００を担いでいる状態を示す図である。
【図12】（ａ）及び（ｂ）は、動作タイミングが一致したときの鈴の挙動を示す図である。
【図13】タイミング修正情報の表示例を示す図である。
【図14】第２の実施の形態に係る御神輿を担ぎ中のモデル動作制御処理を示すフローチャートである。
【図15】第２の実施の形態に係る御神輿を担ぎ中のモデル動作制御処理を示すフローチャートである。
【図16】第３の実施の形態に係るユーザ情報管理テーブル４００Ａのデータ構造を示す図である。
【図17】第３の実施の形態に係るイベント参加者募集処理を示すフローチャートである。
【図18】回覧情報回覧処理を示すフローチャートである。
【図19】回覧先選択回数更新処理を示すフローチャートである。
【図20】第４の実施の形態に係るイベント会場モデル生成処理を示すフローチャートである。
【図21】イベント開催地が１つの場合の地図アプリの地図画像上で手動で移動ルートを設定している様子を示す図である。
【図22】イベント開催地が複数の場合の地図アプリの地図画像上で移動ルートを手動で設定している様子を示す図である。
【発明を実施するための形態】
【0030】
〔第１の実施の形態〕
以下、本発明の第１の実施の形態を説明する。図１乃至図１３は、第１の実施の形態を示す図である。
〔構成〕
まず、第１の実施の形態の構成を説明する。
図１は、第１の実施の形態に係るネットワークシステムの構成を示すブロック図である。
インターネット１９９には、図１に示すように、イベント開催者の要求に応じてバーチャル御神輿イベントをユーザ（イベント参加者）に提供する企業の管理下にあるバーチャル御神輿イベント提供サーバ１００と、ユーザごとに設置されたユーザ端末２００とが接続されている。加えて、イベント開催者の事務局ごとに設置された事務局端末３００が接続されている。
以下、本発明の第１の実施の形態を説明する。図１乃至図１３は、第１の実施の形態を示す図である。
〔構成〕
まず、第１の実施の形態の構成を説明する。
図１は、第１の実施の形態に係るネットワークシステムの構成を示すブロック図である。
インターネット１９９には、図１に示すように、イベント開催者の要求に応じてバーチャル御神輿イベントをユーザ（イベント参加者）に提供する企業の管理下にあるバーチャル御神輿イベント提供サーバ１００と、ユーザごとに設置されたユーザ端末２００とが接続されている。加えて、イベント開催者の事務局ごとに設置された事務局端末３００が接続されている。
【0031】
ここで、バーチャル御神輿イベントとは、ＶＲ（Virtual Reality）技術等の３ＤＣＧ（three-dimensional computer graphics）技術を用いて構成されたバーチャル空間上で神社等が開催する御神輿を担ぐイベントを実施するものである。御神輿イベントは、例えば、神社をスタート地点にして、一般道路等に沿って複数の担ぎ手が御神輿を担いで移動する他、海が近い地域では海岸を移動したり海に入ったりもして、元来た経路又は別の経路を通って再びスタート地点の神社に戻ってくるといった内容のイベントとなる。従って、参加者（担ぎ手）の３Ｄモデルに加えて、御神輿、神社、道路、歩道、建物、海岸、海などのイベント会場をバーチャルモデル化する必要がある。
【0032】
〔バーチャル御神輿イベント提供サーバ１００のハードウェア構成〕
次に、バーチャル御神輿イベント提供サーバ１００のハードウェア構成を説明する。
図２は、バーチャル御神輿イベント提供サーバ１００のハードウェア構成の一例を示す図である。
バーチャル御神輿イベント提供サーバ１００は、図２に示すように、制御プログラムに基づいて演算及びシステム全体を制御するＣＰＵ（Central Processing Unit）３０と、所定領域に予めＣＰＵ３０の制御プログラム等を格納しているＲＯＭ（Read Only Memory）３２と、ＲＯＭ３２等から読み出したデータやＣＰＵ３０の演算過程で必要な演算結果を格納するためのＲＡＭ（Random Access Memory）３４と、外部装置に対してデータの入出力を媒介するＩ／Ｆ（interface）３８とで構成されており、これらは、データを転送するための信号線であるバス３９で相互に且つデータ授受可能に接続されている。なお、Ｉ／Ｆ３８には、ネットワークアダプタの機能も含まれている。
次に、バーチャル御神輿イベント提供サーバ１００のハードウェア構成を説明する。
図２は、バーチャル御神輿イベント提供サーバ１００のハードウェア構成の一例を示す図である。
バーチャル御神輿イベント提供サーバ１００は、図２に示すように、制御プログラムに基づいて演算及びシステム全体を制御するＣＰＵ（Central Processing Unit）３０と、所定領域に予めＣＰＵ３０の制御プログラム等を格納しているＲＯＭ（Read Only Memory）３２と、ＲＯＭ３２等から読み出したデータやＣＰＵ３０の演算過程で必要な演算結果を格納するためのＲＡＭ（Random Access Memory）３４と、外部装置に対してデータの入出力を媒介するＩ／Ｆ（interface）３８とで構成されており、これらは、データを転送するための信号線であるバス３９で相互に且つデータ授受可能に接続されている。なお、Ｉ／Ｆ３８には、ネットワークアダプタの機能も含まれている。
【0033】
Ｉ／Ｆ３８には、外部装置として、ヒューマンインターフェースとしてデータの入力が可能なキーボードやマウス等からなる入力装置４０と、データやテーブル等をファイルとして格納する記憶装置４２と、画像信号に基づいて画面を表示する表示装置４４と、インターネット１９９に接続するための信号線（図示略）とが接続されている。
〔ユーザ端末２００のハードウェア構成〕
ユーザ端末２００は、上記バーチャル御神輿イベント提供サーバ１００のような据え置き型を想定した端末、または、ノートＰＣ、スマートフォン、タブレットなどの携帯型の端末から構成されている。ユーザ端末２００には、Ｉ／Ｆを介して、図１に示すように、ビデオカメラ５０と、コントローラ５２とが有線接続又は無線接続されている。また、図示省略するが、ユーザ端末２００には、バーチャル御神輿イベントに参加する参加者間で音声チャットを行うことができるように、Ｉ／Ｆを介してマイク及びスピーカが接続されている。
〔ユーザ端末２００のハードウェア構成〕
ユーザ端末２００は、上記バーチャル御神輿イベント提供サーバ１００のような据え置き型を想定した端末、または、ノートＰＣ、スマートフォン、タブレットなどの携帯型の端末から構成されている。ユーザ端末２００には、Ｉ／Ｆを介して、図１に示すように、ビデオカメラ５０と、コントローラ５２とが有線接続又は無線接続されている。また、図示省略するが、ユーザ端末２００には、バーチャル御神輿イベントに参加する参加者間で音声チャットを行うことができるように、Ｉ／Ｆを介してマイク及びスピーカが接続されている。
【0034】
ビデオカメラ５０は、撮像範囲内に存在する被写体の動画像を撮像することができ、撮像により得られた撮像画像データは、Ｉ／Ｆを介してユーザ端末２００に出力する。
コントローラ５２は、コントロールレバーと、複数のボタンと、６軸ジャイロセンサとを備えている。そして、ユーザのコントロールレバーの操作やボタン操作に応じた出力情報をユーザ端末２００に出力する。加えて、ユーザが手に持って振ったり、持った状態で動作をしたりすることで、動作内容に応じたジャイロセンサの検出値をＩ／Ｆを介してユーザ端末２００に出力する。
コントローラ５２は、コントロールレバーと、複数のボタンと、６軸ジャイロセンサとを備えている。そして、ユーザのコントロールレバーの操作やボタン操作に応じた出力情報をユーザ端末２００に出力する。加えて、ユーザが手に持って振ったり、持った状態で動作をしたりすることで、動作内容に応じたジャイロセンサの検出値をＩ／Ｆを介してユーザ端末２００に出力する。
【0035】
〔事務局端末３００のハードウェア構成〕
事務局端末３００は、上記ユーザ端末２００と同様に、据え置き型を想定した端末、または、ノートＰＣ、スマートフォン、タブレットなどの携帯型の端末から構成されている。
〔各種テーブルについて〕
次に、記憶装置４２に記憶されている各種テーブルについて説明する。
図３（ａ）～（ｃ）は、ユーザ情報管理テーブル４００、募集情報テーブル４１０及びイベント参加者管理テーブル４１５のデータ構造を示す図である。
事務局端末３００は、上記ユーザ端末２００と同様に、据え置き型を想定した端末、または、ノートＰＣ、スマートフォン、タブレットなどの携帯型の端末から構成されている。
〔各種テーブルについて〕
次に、記憶装置４２に記憶されている各種テーブルについて説明する。
図３（ａ）～（ｃ）は、ユーザ情報管理テーブル４００、募集情報テーブル４１０及びイベント参加者管理テーブル４１５のデータ構造を示す図である。
【0036】
記憶装置４２には、図３（ａ）に示すように、ユーザ情報管理テーブル４００が記憶されている。
ユーザ情報管理テーブル４００には、図３（ａ）に示すように、ユーザＩＤごとに１つのレコードが登録されている。各レコードは、ユーザＩＤ、ユーザの住所、ユーザの氏名、ユーザのメールアドレス、ログインパスワード、ユーザが過去に参加したイベントのイベントＩＤ、その他の情報が登録されている。ここで、ユーザＩＤは、ユーザを識別するためのＩＤである。
ユーザ情報管理テーブル４００には、図３（ａ）に示すように、ユーザＩＤごとに１つのレコードが登録されている。各レコードは、ユーザＩＤ、ユーザの住所、ユーザの氏名、ユーザのメールアドレス、ログインパスワード、ユーザが過去に参加したイベントのイベントＩＤ、その他の情報が登録されている。ここで、ユーザＩＤは、ユーザを識別するためのＩＤである。
【0037】
また、記憶装置４２には、図３（ｂ）に示すように、募集情報テーブル４１０が記憶されている。
募集情報テーブル４１０には、図３（ｂ）に示すように、イベントＩＤごとに１つのレコードが登録されている。各レコードは、イベントＩＤ、イベント名、神社の名称、メールアドレス、神輿基数、募集人数、募集期限、開催日、その他の情報が登録されている。ここで、イベントＩＤは、募集に係るバーチャル御神輿イベントを識別するためのＩＤであり、神社の名称は、イベントに関係する神社の名称である。特定の神社に関係しないオリジナルのイベントの場合は、神社の名称は空欄又はイベント開催者の団体名などとなる。
募集情報テーブル４１０には、図３（ｂ）に示すように、イベントＩＤごとに１つのレコードが登録されている。各レコードは、イベントＩＤ、イベント名、神社の名称、メールアドレス、神輿基数、募集人数、募集期限、開催日、その他の情報が登録されている。ここで、イベントＩＤは、募集に係るバーチャル御神輿イベントを識別するためのＩＤであり、神社の名称は、イベントに関係する神社の名称である。特定の神社に関係しないオリジナルのイベントの場合は、神社の名称は空欄又はイベント開催者の団体名などとなる。
【0038】
また、記憶装置４２には、図３（ｃ）に示すように、イベント参加者管理テーブル４１５が記憶されている。
イベント参加者管理テーブル４１５には、図３（ｃ）に示すように、イベントＩＤごとに１つのレコードが登録されている。各レコードは、イベントＩＤ、イベントに参加する参加者（ユーザ）のユーザＩＤ、参加者の合計人数、その他の情報が登録されている。ここで、ユーザＩＤは、イベントへの参加が決定したユーザ全員のユーザＩＤが登録される。
イベント参加者管理テーブル４１５には、図３（ｃ）に示すように、イベントＩＤごとに１つのレコードが登録されている。各レコードは、イベントＩＤ、イベントに参加する参加者（ユーザ）のユーザＩＤ、参加者の合計人数、その他の情報が登録されている。ここで、ユーザＩＤは、イベントへの参加が決定したユーザ全員のユーザＩＤが登録される。
【0039】
また、図４（ａ）～（ｅ）は、イベント用写真データ管理テーブル４２０、イベント用モデル管理テーブル４３０、参加者写真データ管理テーブル４４０、アバター管理テーブル４５０及び音響データ管理テーブル４６０のデータ構造を示す図である。
記憶装置４２には、図４（ａ）に示すように、イベント用写真データ管理テーブル４２０が記憶されている。
イベント用写真データ管理テーブル４２０には、図４（ａ）に示すように、写真ＩＤごとに１つのレコードが登録されている。各レコードは、イベントＩＤ、写真ＩＤ、写真種別（例えば、神社、御神輿、イベント会場、その他）、その他の情報が登録されている。ここで、写真ＩＤは、登録された各イベント用写真データを識別するためのＩＤである。
記憶装置４２には、図４（ａ）に示すように、イベント用写真データ管理テーブル４２０が記憶されている。
イベント用写真データ管理テーブル４２０には、図４（ａ）に示すように、写真ＩＤごとに１つのレコードが登録されている。各レコードは、イベントＩＤ、写真ＩＤ、写真種別（例えば、神社、御神輿、イベント会場、その他）、その他の情報が登録されている。ここで、写真ＩＤは、登録された各イベント用写真データを識別するためのＩＤである。
【0040】
また、記憶装置４２には、図４（ｂ）に示すように、イベント用モデル管理テーブル４３０が記憶されている。
イベント用モデル管理テーブル４３０には、図４（ｂ）に示すように、モデルＩＤごとに１つのレコードが登録されている。各レコードは、イベントＩＤ、モデルＩＤ、モデル種別（神社、御神輿、イベント会場、その他）、作成日、登録日、その他の情報が登録されている。ここで、モデルＩＤは、登録されたイベント用モデルを識別するためのＩＤである。
イベント用モデル管理テーブル４３０には、図４（ｂ）に示すように、モデルＩＤごとに１つのレコードが登録されている。各レコードは、イベントＩＤ、モデルＩＤ、モデル種別（神社、御神輿、イベント会場、その他）、作成日、登録日、その他の情報が登録されている。ここで、モデルＩＤは、登録されたイベント用モデルを識別するためのＩＤである。
【0041】
また、記憶装置４２には、図４（ｃ）に示すように、参加者写真データ管理テーブル４４０が記憶されている。
参加者写真データ管理テーブル４４０には、図４（ｃ）に示すように、ユーザＩＤごとに１つのレコードが登録されている。各レコードは、ユーザＩＤ、写真ＩＤ、登録日、その他の情報が登録されている。ここで、写真ＩＤは、登録された写真を識別するためのＩＤである。
また、記憶装置４２には、図４（ｄ）に示すように、アバター管理テーブル４５０が記憶されている。
参加者写真データ管理テーブル４４０には、図４（ｃ）に示すように、ユーザＩＤごとに１つのレコードが登録されている。各レコードは、ユーザＩＤ、写真ＩＤ、登録日、その他の情報が登録されている。ここで、写真ＩＤは、登録された写真を識別するためのＩＤである。
また、記憶装置４２には、図４（ｄ）に示すように、アバター管理テーブル４５０が記憶されている。
【0042】
アバター管理テーブル４５０には、図４（ｄ）に示すように、ユーザＩＤごとに１つのレコードが登録されている。各レコードは、ユーザＩＤ、アバターＩＤ、作成日、その他の情報が登録されている。ここで、アバターＩＤは、登録された３Ｄアバターを識別するためのＩＤである。
また、記憶装置４２には、図４（ｅ）に示すように、音響データ管理テーブル４６０が記憶されている。
音響データ管理テーブル４６０には、図４（ｅ）に示すように、イベントＩＤごとに１つのレコードが登録されている。各レコードは、イベントＩＤ、音響種類（例えば、担ぎ前ＢＧＭ、担ぎ中ＢＧＭ、一致用の鈴の音、不一致用の鈴の音）、登録日、その他の情報が登録されている。
また、記憶装置４２には、図４（ｅ）に示すように、音響データ管理テーブル４６０が記憶されている。
音響データ管理テーブル４６０には、図４（ｅ）に示すように、イベントＩＤごとに１つのレコードが登録されている。各レコードは、イベントＩＤ、音響種類（例えば、担ぎ前ＢＧＭ、担ぎ中ＢＧＭ、一致用の鈴の音、不一致用の鈴の音）、登録日、その他の情報が登録されている。
【0043】
なお、記憶装置４２は、図示省略するが、上記各種テーブルの他にも、事務局端末３００から受信したイベント用写真データが登録されたイベント用写真データライブラリ、イベント用モデルが登録されたイベント用モデルライブラリ、参加者写真データが登録された参加者写真データライブラリ、３Ｄアバターが登録されたアバターライブラリ、音響データが登録された音響データライブラリ等を記憶している。
〔バーチャル御神輿イベント提供サーバ１００の機能について〕
次に、バーチャル御神輿イベント提供サーバ１００の機能について説明する。
〔バーチャル御神輿イベント提供サーバ１００の機能について〕
次に、バーチャル御神輿イベント提供サーバ１００の機能について説明する。
【0044】
バーチャル御神輿イベント提供サーバ１００は、ＣＰＵ３０において、ＲＯＭ３２の所定領域に格納されている所定のプログラムを実行することで実現される機能として、以下の機能を有している。
バーチャル御神輿イベント提供サーバ１００は、インターネット１９９を介して受信した事務局端末３００からの募集情報を、記憶装置４２の募集情報テーブル４１０に登録する機能を有している。加えて、インターネット１９９を介して受信した事務局端末３００からのイベント用写真データを、記憶装置４２のイベント用写真データライブラリに登録する機能を有している。さらに、イベント用写真データの管理情報を、イベント用写真データ管理テーブル４２０に登録する機能を有している。
バーチャル御神輿イベント提供サーバ１００は、インターネット１９９を介して受信した事務局端末３００からの募集情報を、記憶装置４２の募集情報テーブル４１０に登録する機能を有している。加えて、インターネット１９９を介して受信した事務局端末３００からのイベント用写真データを、記憶装置４２のイベント用写真データライブラリに登録する機能を有している。さらに、イベント用写真データの管理情報を、イベント用写真データ管理テーブル４２０に登録する機能を有している。
【0045】
さらに、バーチャル御神輿イベント提供サーバ１００は、インターネット１９９を介して受信したユーザ端末２００からのバーチャル御神輿イベント用のアプリケーションソフト（以下、「イベント用アプリ」という）を利用するユーザの情報を、記憶装置４２のユーザ情報管理テーブル４００に登録する機能を有している。
さらに、バーチャル御神輿イベント提供サーバ１００は、インターネット１９９を介して受信したユーザ端末２００からの３Ｄアバターを作成するための参加者の写真データを、記憶装置４２の参加者写真データライブラリに登録する機能を有している。さらに、参加者写真データの管理情報を、参加者写真データ管理テーブル４４０に登録する機能を有している。
さらに、バーチャル御神輿イベント提供サーバ１００は、インターネット１９９を介して受信したユーザ端末２００からの３Ｄアバターを作成するための参加者の写真データを、記憶装置４２の参加者写真データライブラリに登録する機能を有している。さらに、参加者写真データの管理情報を、参加者写真データ管理テーブル４４０に登録する機能を有している。
【0046】
さらに、バーチャル御神輿イベント提供サーバ１００は、募集情報テーブル４１０に登録された募集情報に基づいて、バーチャル御神輿イベントの参加者を募集するＷｅｂページ（以下、「参加者募集ページ」という）を生成し、生成した参加者募集ページの情報を、イベント用アプリを介してユーザ端末２００がアクセス可能に提供する機能を有している。
〔ユーザ端末２００の機能について〕
次に、ユーザ端末２００の機能について説明する。
〔ユーザ端末２００の機能について〕
次に、ユーザ端末２００の機能について説明する。
【0047】
ユーザ端末２００は、ＣＰＵにおいて、ＲＯＭの所定領域に格納されている所定のプログラム（イベント用アプリ等）を実行することで実現される機能として、以下に示す機能を有している。
ユーザ端末２００は、イベント用アプリを実行することで実現される機能として、アプリ起動後に表示される新規登録用の入力画面に、入力装置を介してユーザ情報を入力し、入力されたユーザ情報をバーチャル御神輿イベント提供サーバ１００に送信する機能を有している。ユーザ情報が登録されることで、以降は、ログインＩＤ（ユーザＩＤ又はメールアドレス）及びログインパスワードを入力することでイベント用アプリを利用することができるようになる。
ユーザ端末２００は、イベント用アプリを実行することで実現される機能として、アプリ起動後に表示される新規登録用の入力画面に、入力装置を介してユーザ情報を入力し、入力されたユーザ情報をバーチャル御神輿イベント提供サーバ１００に送信する機能を有している。ユーザ情報が登録されることで、以降は、ログインＩＤ（ユーザＩＤ又はメールアドレス）及びログインパスワードを入力することでイベント用アプリを利用することができるようになる。
【0048】
さらに、ユーザ端末２００は、イベント用アプリを実行することで実現される機能として、バーチャル御神輿イベント提供サーバ１００の提供する参加者募集ページにアクセスする機能を有している。加えて、入力装置を介したユーザの操作入力に応じて、参加するバーチャル御神輿イベントの選択や、バーチャル御神輿イベントに参加する参加者（ユーザ）の情報を入力する処理を行う機能を有している。さらに、入力された情報をバーチャル御神輿イベント提供サーバ１００に送信する機能を有している。
【0049】
さらに、ユーザ端末２００は、イベント用アプリを実行することで実現される機能として、バーチャル御神輿イベントにて３Ｄアバターの作成に必要な、参加者写真データをバーチャル御神輿イベント提供サーバ１００に送信する機能を有している。なお、写真データのみに限らず、身長、体重、体形、髪形等の情報も送信するようにしてもよい。
さらに、ユーザ端末２００は、イベント用アプリを実行することで実現される機能として、参加登録をしたバーチャル御神輿イベントの開催日に、イベントに参加する機能を有している。バーチャル御神輿イベントに参加することで、バーチャル御神輿イベント提供サーバ１００からのバーチャル御神輿イベントの提供に必要な情報（以下、「イベント提供情報」という）を受信し、受信したイベント提供情報に基づいて、ユーザ端末２００に接続された表示装置へと画像を表示したり、スピーカ（不図示）から楽曲や効果音を出力したりする。
さらに、ユーザ端末２００は、イベント用アプリを実行することで実現される機能として、参加登録をしたバーチャル御神輿イベントの開催日に、イベントに参加する機能を有している。バーチャル御神輿イベントに参加することで、バーチャル御神輿イベント提供サーバ１００からのバーチャル御神輿イベントの提供に必要な情報（以下、「イベント提供情報」という）を受信し、受信したイベント提供情報に基づいて、ユーザ端末２００に接続された表示装置へと画像を表示したり、スピーカ（不図示）から楽曲や効果音を出力したりする。
【0050】
さらに、ユーザ端末２００は、バーチャル御神輿イベントに参加中は、ユーザのコントローラ５２の方向レバーの操作やボタン操作に応じた操作出力情報を、ユーザ操作情報としてバーチャル御神輿イベント提供サーバ１００に送信する処理を実行する。加えて、御神輿モデルを担ぐイベントシーンでは、ユーザがビデオカメラ５０の撮像範囲内にてコントローラ５２を持って例えば御神輿を担ぐ動作を行うことで、ビデオカメラ５０で撮像したユーザの撮像画像データと、ユーザの動作に応じた６軸ジャイロセンサの検出値とを、ユーザ動作情報としてバーチャル御神輿イベント提供サーバ１００に送信する処理を実行する。
【0051】
〔事務局端末３００の機能について〕
次に、事務局端末３００の機能について説明する。
事務局端末３００は、ＣＰＵにおいて、ＲＯＭの所定領域に格納されている所定のプログラムを実行することで実現される機能として、以下に示す機能を有している。
事務局端末３００は、バーチャル御神輿イベント提供サーバ１００の提供するイベント情報登録用のＷｅｂページ（以下、「イベント登録ページ」と称す）において、入力装置を介した開催者の操作入力に応じて、バーチャル御神輿イベントの募集情報を入力する処理を行う機能を有している。加えて、入力された募集情報をバーチャル御神輿イベント提供サーバ１００に送信する機能を有している。
次に、事務局端末３００の機能について説明する。
事務局端末３００は、ＣＰＵにおいて、ＲＯＭの所定領域に格納されている所定のプログラムを実行することで実現される機能として、以下に示す機能を有している。
事務局端末３００は、バーチャル御神輿イベント提供サーバ１００の提供するイベント情報登録用のＷｅｂページ（以下、「イベント登録ページ」と称す）において、入力装置を介した開催者の操作入力に応じて、バーチャル御神輿イベントの募集情報を入力する処理を行う機能を有している。加えて、入力された募集情報をバーチャル御神輿イベント提供サーバ１００に送信する機能を有している。
【0052】
さらに、事務局端末３００は、イベント登録ページにおいて、開催者の操作入力に応じて、イベント用写真データをバーチャル御神輿イベント提供サーバ１００に送信する処理を行う機能を有している。
〔イベント参加者募集処理〕
次に、バーチャル御神輿イベント提供サーバ１００で実行されるイベント参加者募集処理の処理手順について説明する。
図５は、イベント参加者募集処理を示すフローチャートである。
ＣＰＵ３０は、ＲＯＭ３２の所定領域に格納されている所定のプログラムを起動させ、そのプログラムに従って、登録されたバーチャル御神輿イベントごとに、図５のフローチャートに示すイベント参加者募集処理を実行する。
〔イベント参加者募集処理〕
次に、バーチャル御神輿イベント提供サーバ１００で実行されるイベント参加者募集処理の処理手順について説明する。
図５は、イベント参加者募集処理を示すフローチャートである。
ＣＰＵ３０は、ＲＯＭ３２の所定領域に格納されている所定のプログラムを起動させ、そのプログラムに従って、登録されたバーチャル御神輿イベントごとに、図５のフローチャートに示すイベント参加者募集処理を実行する。
【0053】
イベント参加者募集処理は、ＣＰＵ３０において実行されると、図５に示すように、まず、ステップＳ１００に移行する。
ステップＳ１００では、ユーザ端末２００からの参加者募集ページを介した参加申込を受け付けたか否かを判定し、受け付けたと判定した場合(YES）は、ステップＳ１０２に移行し、そうでないと判定した場合（NO）は、ステップＳ１１２に移行する。
ステップＳ１０２に移行した場合は、参加申込を受け付けた参加者のユーザ情報を取得して、ステップＳ１０４に移行する。ここで、参加者の情報としては、ユーザＩＤ等の情報が該当する。
ステップＳ１００では、ユーザ端末２００からの参加者募集ページを介した参加申込を受け付けたか否かを判定し、受け付けたと判定した場合(YES）は、ステップＳ１０２に移行し、そうでないと判定した場合（NO）は、ステップＳ１１２に移行する。
ステップＳ１０２に移行した場合は、参加申込を受け付けた参加者のユーザ情報を取得して、ステップＳ１０４に移行する。ここで、参加者の情報としては、ユーザＩＤ等の情報が該当する。
【0054】
ステップＳ１０４では、ステップＳ１０２で取得したユーザ情報から、イベント参加者管理テーブル４１５にアクセスし、二重登録となるか否か、同じ時間帯の他のイベントに参加しているか否か等を確認することで、参加条件を満たすか否かを判定する。そして、参加条件を満たすと判定した場合(YES）は、ステップＳ１０６に移行し、そうでないと判定した場合（NO）は、参加不可を示す情報を該当のユーザ端末２００に送信して、ステップＳ１００に移行する。
【0055】
ステップＳ１０６に移行した場合は、参加申込をしたユーザの情報をイベント参加者の情報として、イベント参加者管理テーブル４１５に登録する。その後、ステップＳ１０８に移行する。
ステップＳ１０８では、募集人数の上限に達したか否かを判定し、達したと判定した場合(YES）は、ステップＳ１１０に移行し、そうでないと判定した場合（NO）は、ステップＳ１００に移行する。
ステップＳ１１０に移行した場合は、該当するイベントの参加者募集ページを閉鎖する処理を行って、一連の処理を終了する。ここで、閉鎖する処理は、申し込みの受け付けを終了する、ページにアクセスできないようにするといった処理となる。
ステップＳ１０８では、募集人数の上限に達したか否かを判定し、達したと判定した場合(YES）は、ステップＳ１１０に移行し、そうでないと判定した場合（NO）は、ステップＳ１００に移行する。
ステップＳ１１０に移行した場合は、該当するイベントの参加者募集ページを閉鎖する処理を行って、一連の処理を終了する。ここで、閉鎖する処理は、申し込みの受け付けを終了する、ページにアクセスできないようにするといった処理となる。
【0056】
また、ステップＳ１００において、参加申込を受け付けがなくステップＳ１１２に移行した場合は、募集期限を過ぎたか否かを判定し、過ぎたと判定した場合(YES）は、ステップＳ１１０に移行し、そうでないと判定した場合（NO）は、ステップＳ１００に移行する。
〔イベント用モデル生成処理〕
次に、バーチャル御神輿イベント提供サーバ１００で実行されるイベント用モデル生成処理の処理手順について説明する。
図６は、イベント用モデル生成処理を示すフローチャートである。
〔イベント用モデル生成処理〕
次に、バーチャル御神輿イベント提供サーバ１００で実行されるイベント用モデル生成処理の処理手順について説明する。
図６は、イベント用モデル生成処理を示すフローチャートである。
【0057】
ＣＰＵ３０は、ＲＯＭ３２の所定領域に格納されている所定のプログラムを起動させ、そのプログラムに従って、図６のフローチャートに示すイベント用モデル生成処理を実行する。
イベント用モデル生成処理は、ＣＰＵ３０において実行されると、図６に示すように、まず、ステップＳ１５０に移行する。
ステップＳ１５０では、イベント用写真データ管理テーブル４２０に基づいて、イベントＩＤごとに、イベント用写真データライブラリからイベント用写真データを取得して、ステップＳ１５２に移行する。
イベント用モデル生成処理は、ＣＰＵ３０において実行されると、図６に示すように、まず、ステップＳ１５０に移行する。
ステップＳ１５０では、イベント用写真データ管理テーブル４２０に基づいて、イベントＩＤごとに、イベント用写真データライブラリからイベント用写真データを取得して、ステップＳ１５２に移行する。
【0058】
ステップＳ１５２では、ステップＳ１５０で取得したイベント用写真データに基づいて、イベント用モデルを生成して、ステップＳ１５４に移行する。
ここで、イベント用写真データは、神社、御神輿、イベント会場（祭り会場）などの３Ｄモデルが生成可能な写真データであり、これらイベントに登場する物体や構造物などを様々な角度から撮影した写真データがある方が望ましい。なお、地形、建物、道路などの実物を上空や地上から撮影した写真データを用いて作成された３Ｄマップで使用されている３Ｄマップデータを利用してイベント用モデルを生成することも可能である。
ここで、イベント用写真データは、神社、御神輿、イベント会場（祭り会場）などの３Ｄモデルが生成可能な写真データであり、これらイベントに登場する物体や構造物などを様々な角度から撮影した写真データがある方が望ましい。なお、地形、建物、道路などの実物を上空や地上から撮影した写真データを用いて作成された３Ｄマップで使用されている３Ｄマップデータを利用してイベント用モデルを生成することも可能である。
【0059】
ステップＳ１５４では、ステップＳ１５２で生成したイベント用モデルを、イベント用モデルライブラリに登録するとともに、生成したイベント用モデルの管理情報をイベント用モデル管理テーブル４３０に登録する。その後、ステップＳ１５６に移行する。
ステップＳ１５６では、登録された全てのイベントの全てのイベント用モデルを生成したか否かを判定し、生成したと判定した場合（YES）は、一連の処理を終了し、そうでないと判定した場合（NO）は、ステップＳ１５０に移行する。
ステップＳ１５６では、登録された全てのイベントの全てのイベント用モデルを生成したか否かを判定し、生成したと判定した場合（YES）は、一連の処理を終了し、そうでないと判定した場合（NO）は、ステップＳ１５０に移行する。
【0060】
〔３Ｄアバター生成処理〕
次に、バーチャル御神輿イベント提供サーバ１００で実行される３Ｄアバター生成処理の処理手順について説明する。
図７は、３Ｄアバター生成処理を示すフローチャートである。
ＣＰＵ３０は、ＲＯＭ３２の所定領域に格納されている所定のプログラムを起動させ、そのプログラムに従って、図７のフローチャートに示す３Ｄアバター生成処理を実行する。
３Ｄアバター生成処理は、ＣＰＵ３０において実行されると、図７に示すように、まず、ステップＳ１７０に移行する。
次に、バーチャル御神輿イベント提供サーバ１００で実行される３Ｄアバター生成処理の処理手順について説明する。
図７は、３Ｄアバター生成処理を示すフローチャートである。
ＣＰＵ３０は、ＲＯＭ３２の所定領域に格納されている所定のプログラムを起動させ、そのプログラムに従って、図７のフローチャートに示す３Ｄアバター生成処理を実行する。
３Ｄアバター生成処理は、ＣＰＵ３０において実行されると、図７に示すように、まず、ステップＳ１７０に移行する。
【0061】
ステップＳ１７０では、参加者写真データ管理テーブル４４０に基づいて、参加者写真データライブラリから参加者写真データを取得して、ステップＳ１７２に移行する。
ステップＳ１７２では、ステップＳ１７０で取得した参加者写真データに基づいて、参加者の３Ｄアバターを生成して、ステップＳ１７４に移行する。
ここで、参加者写真データは、参加者の３Ｄモデルが生成可能な写真データであり、最低限、正面から撮影した顔写真があれば、コンピュータ側で補完等を行って頭部のモデルを生成することができる。また、この場合にボディは予め用意されたモデルを用いて生成する。衣装については、参加するイベントに応じて変更できるようになっている。
ステップＳ１７２では、ステップＳ１７０で取得した参加者写真データに基づいて、参加者の３Ｄアバターを生成して、ステップＳ１７４に移行する。
ここで、参加者写真データは、参加者の３Ｄモデルが生成可能な写真データであり、最低限、正面から撮影した顔写真があれば、コンピュータ側で補完等を行って頭部のモデルを生成することができる。また、この場合にボディは予め用意されたモデルを用いて生成する。衣装については、参加するイベントに応じて変更できるようになっている。
【0062】
一方、参加者写真データは、参加者を様々な角度から撮影した頭部や全身の写真データがある方が望ましく、この場合は、これら写真データから参加者本人により近い３Ｄアバターを生成することができる。
ステップＳ１７４では、ステップＳ１７２で生成した３Ｄアバターを、３Ｄアバターライブラリに登録するとともに、生成した３Ｄアバターの管理情報をアバター管理テーブル４５０に登録する。その後、ステップＳ１７６に移行する。
ステップＳ１７４では、ステップＳ１７２で生成した３Ｄアバターを、３Ｄアバターライブラリに登録するとともに、生成した３Ｄアバターの管理情報をアバター管理テーブル４５０に登録する。その後、ステップＳ１７６に移行する。
【0063】
ステップＳ１７６では、登録された全ての参加者の３Ｄアバターを生成したか否かを判定し、生成したと判定した場合（ＹＥＳ）は、一連の処理を終了し、そうでないと判定した場合（ＮＯ）は、ステップＳ１７０に移行する。ここで、過去に３Ｄアバターを生成したことのある参加者については、３Ｄアバターの生成を行なわないようにしてもよい。
〔モデル動作制御処理〕
次に、バーチャル御神輿イベント提供サーバ１００で実行されるモデル動作制御処理の処理手順について説明する。
〔モデル動作制御処理〕
次に、バーチャル御神輿イベント提供サーバ１００で実行されるモデル動作制御処理の処理手順について説明する。
【0064】
図８は、モデル動作制御処理を示すフローチャートである。
ＣＰＵ３０は、ＲＯＭ３２の所定領域に格納されている所定のプログラムを起動させ、そのプログラムに従って、図８のフローチャートに示すモデル動作制御処理を実行する。
モデル動作制御処理は、イベント開催後に実行される処理であり、ＣＰＵ３０において実行されると、図８に示すように、まず、ステップＳ２００に移行する。
ステップＳ２００では、御神輿モデルを担ぎ中か否かを判定し、担ぎ中であると判定した場合（YES）は、ステップＳ２０２に移行し、そうでないと判定した場合（NO）は、ステップＳ２０８に移行する。
ＣＰＵ３０は、ＲＯＭ３２の所定領域に格納されている所定のプログラムを起動させ、そのプログラムに従って、図８のフローチャートに示すモデル動作制御処理を実行する。
モデル動作制御処理は、イベント開催後に実行される処理であり、ＣＰＵ３０において実行されると、図８に示すように、まず、ステップＳ２００に移行する。
ステップＳ２００では、御神輿モデルを担ぎ中か否かを判定し、担ぎ中であると判定した場合（YES）は、ステップＳ２０２に移行し、そうでないと判定した場合（NO）は、ステップＳ２０８に移行する。
【0065】
ステップＳ２０２に移行した場合は、バーチャル御神輿イベント（以下、単に「イベント」と略称する）に参加している御神輿モデルの担ぎ手である担ぎ手ユーザのユーザ端末２００からのユーザ動作情報を受信したか否かを判定し、受信したと判定した場合（YES）は、ステップＳ２０４に移行し、そうでないと判定した場合（NO）は、ステップＳ２００に移行する。
ここで、図１０は、イベント参加中の担ぎ手ユーザＡの動作状態の一例を示す図である。例えば、図１０に示すように、イベントに参加している担ぎ手ユーザＡは、ビデオカメラ５０の撮像範囲５００内にて、コントローラ５２を担ぎ棒を担ぐ側の手に持って、実際に担いでいるような姿勢をとり、この姿勢で図１０中の矢印に示すように膝を曲げ伸ばしするなどして上下動し、実際に御神輿を担ぐような動作を行う。これにより、ビデオカメラ５０で撮像した御神輿を担ぐ姿勢で上下動する担ぎ手ユーザＡの撮像画像データと、上下動したことによるコントローラ５２の６軸ジャイロセンサのセンサ検出値とが、ユーザ動作情報としてバーチャル御神輿イベント提供サーバ１００に送信される。
ここで、図１０は、イベント参加中の担ぎ手ユーザＡの動作状態の一例を示す図である。例えば、図１０に示すように、イベントに参加している担ぎ手ユーザＡは、ビデオカメラ５０の撮像範囲５００内にて、コントローラ５２を担ぎ棒を担ぐ側の手に持って、実際に担いでいるような姿勢をとり、この姿勢で図１０中の矢印に示すように膝を曲げ伸ばしするなどして上下動し、実際に御神輿を担ぐような動作を行う。これにより、ビデオカメラ５０で撮像した御神輿を担ぐ姿勢で上下動する担ぎ手ユーザＡの撮像画像データと、上下動したことによるコントローラ５２の６軸ジャイロセンサのセンサ検出値とが、ユーザ動作情報としてバーチャル御神輿イベント提供サーバ１００に送信される。
【0066】
なお、ユーザ端末２００（クライアント）とバーチャル御神輿イベント提供サーバ１００との接続方式は、参加者（３Ｄアバター）の数や御神輿モデルの数に応じて、数が少ない場合は完全同期型とし、数が多い場合は非同期型とすることが望ましい。ここで、完全同期型は、１フレーム単位で完全に同期させる方式であり、例えば、フレームレートが６０であれば、１秒間に６０回同期をとることになる。一方、非同期型は、情報量が多くて１フレームでの同期が難しい場合の方式であり、数フレームで同期する方式となる。
【0067】
また、バーチャル御神輿イベント提供サーバ１００の負荷を軽減するために、イベントの提供に必要な各種イベント用モデルのデータや３Ｄアバターのデータは、ユーザ端末２００に予めダウンロードしておくことが望ましい。
ステップＳ２０４に移行した場合は、同一の御神輿モデルに割り当てられた各担ぎ手ユーザのユーザ動作情報に基づいて担ぎ中動作制御処理を実行して、ステップＳ２０６に移行する。なお、ステップＳ２０２～Ｓ２０４の処理は、イベントに複数基の御神輿モデルが参加している場合に、御神輿モデルごとに行われる処理となる。
ステップＳ２０４に移行した場合は、同一の御神輿モデルに割り当てられた各担ぎ手ユーザのユーザ動作情報に基づいて担ぎ中動作制御処理を実行して、ステップＳ２０６に移行する。なお、ステップＳ２０２～Ｓ２０４の処理は、イベントに複数基の御神輿モデルが参加している場合に、御神輿モデルごとに行われる処理となる。
【0068】
ステップＳ２０６では、担ぎ中動作制御処理又は通常動作制御処理で生成されたイベント提供情報を、イベントに参加している各ユーザのユーザ端末２００に送信して、一連の処理を終了し元の処理に復帰する。ここでのユーザは、担ぎ手ユーザだけではなく、担ぎ手では無いが見物のために参加しているユーザも含んでいてもよい。このことは、ステップＳ２１０のユーザについても同様である。
これにより、イベント提供情報を受信した各ユーザのユーザ端末２００の表示装置には、担ぎ中動作制御処理又は通常動作制御処理で生成された各種イベント提供情報に応じた画像が表示され、スピーカからは担ぎ中動作制御処理又は通常動作制御処理で生成された各種イベント提供情報に応じた音響情報が出力される。
これにより、イベント提供情報を受信した各ユーザのユーザ端末２００の表示装置には、担ぎ中動作制御処理又は通常動作制御処理で生成された各種イベント提供情報に応じた画像が表示され、スピーカからは担ぎ中動作制御処理又は通常動作制御処理で生成された各種イベント提供情報に応じた音響情報が出力される。
【0069】
ここで、図１１は、複数の３Ｄアバター７００が御神輿モデル６００を担いでいる状態を示す図である。各担ぎ手ユーザのユーザ端末２００の表示装置には、例えば、図１１に示すように、複数の担ぎ手ユーザ（参加者）に対応する複数の３Ｄアバター７０＿１，７０＿２，７０＿３，７０＿４，７０＿５・・・が、御神輿モデル６００を担ぐ動画像が表示される。以下、３Ｄアバター７０＿１，７０＿２，７０＿３，７０＿４，７０＿５・・・を区別しない場合に、単に「３Ｄアバター７００」という。
【0070】
なお、図１１の例では、御神輿モデル６００は、複数の担ぎ棒６２０を備えており、また屋根の４隅に設けられた蕨手６１０にはそれぞれ鈴６３０が吊るされている。
一方、ステップＳ２００において、御神輿モデルを担ぎ中ではなくステップＳ２０８に移行した場合は、イベントに参加しているユーザのユーザ端末２００からのユーザ操作情報を受信したか否かを判定し、受信したと判定した場合（YES）は、ステップＳ２１０に移行し、そうでないと判定した場合（NO）は、ステップＳ２００に移行する。
一方、ステップＳ２００において、御神輿モデルを担ぎ中ではなくステップＳ２０８に移行した場合は、イベントに参加しているユーザのユーザ端末２００からのユーザ操作情報を受信したか否かを判定し、受信したと判定した場合（YES）は、ステップＳ２１０に移行し、そうでないと判定した場合（NO）は、ステップＳ２００に移行する。
【0071】
ステップＳ２１０に移行した場合は、各ユーザのユーザ操作情報に基づいて通常動作制御処理を実行して、ステップＳ２０６に移行する。
ここで、通常動作制御処理は、コントローラ５２の移動キーやボタンの操作に応じて、御神輿モデル６００を担いでいない状態の３Ｄアバター７００をイベント会場内で移動させるなどの動作をさせる処理である。なお、本実施の形態において、イベント会場内ではユーザ間での音声チャットができるようになっている。
ここで、通常動作制御処理は、コントローラ５２の移動キーやボタンの操作に応じて、御神輿モデル６００を担いでいない状態の３Ｄアバター７００をイベント会場内で移動させるなどの動作をさせる処理である。なお、本実施の形態において、イベント会場内ではユーザ間での音声チャットができるようになっている。
【0072】
〔担ぎ中動作制御処理〕
次に、上記ステップＳ２０４で実行される担ぎ中動作制御処理の処理手順について説明する。
図９は、担ぎ中動作制御処理を示すフローチャートである。
担ぎ中動作制御処理は、ＣＰＵ３０において実行されると、図９に示すように、まず、ステップＳ２５０に移行する。
ステップＳ２５０では、同一の御神輿モデルの担ぎ手として割り当てられた複数の担ぎ手ユーザのグループについて、受信したユーザ動作情報を解析して、ステップＳ２５２に移行する。ここで、ユーザ動作情報に含まれる各担ぎ手ユーザの６軸ジャイロセンサの検出値及び各担ぎ手ユーザの撮像画像データから例えば各担ぎ手ユーザの上下動のタイミングや動作姿勢等の動作内容を解析する。なお、神社によって御神輿の担ぎ方が異なるため、イベントの開催に係る神社ごとに動作姿勢等の判定内容を変更する必要がある。
次に、上記ステップＳ２０４で実行される担ぎ中動作制御処理の処理手順について説明する。
図９は、担ぎ中動作制御処理を示すフローチャートである。
担ぎ中動作制御処理は、ＣＰＵ３０において実行されると、図９に示すように、まず、ステップＳ２５０に移行する。
ステップＳ２５０では、同一の御神輿モデルの担ぎ手として割り当てられた複数の担ぎ手ユーザのグループについて、受信したユーザ動作情報を解析して、ステップＳ２５２に移行する。ここで、ユーザ動作情報に含まれる各担ぎ手ユーザの６軸ジャイロセンサの検出値及び各担ぎ手ユーザの撮像画像データから例えば各担ぎ手ユーザの上下動のタイミングや動作姿勢等の動作内容を解析する。なお、神社によって御神輿の担ぎ方が異なるため、イベントの開催に係る神社ごとに動作姿勢等の判定内容を変更する必要がある。
【0073】
ステップＳ２５２では、ステップＳ２５０の解析結果に基づいて、同一グループの複数の担ぎ手ユーザの動作姿勢が御神輿を担ぐ姿勢となっており且つ動作タイミングが一致しているか否かを判定する。そして、御神輿を担ぐ姿勢となっており且つ動作タイミングが一致していると判定した場合（YES）は、ステップＳ２５４に移行し、そうでないと判定した場合（NO）は、ステップＳ２５８に移行する。
ここで、動作タイミングについては、予めグループ内のリーダーを一人決めておき、リーダーの動作タイミングと他の担ぎ手ユーザの動作タイミングとの一致度をそれぞれ計算し、他の担ぎ手ユーザ全員の一致度が予め設定した閾値以内（例えばズレが０．５秒以内）であれば動作タイミングが一致していると判定する。また、例えば、図１１の例では、３Ｄアバター７００＿１をリーダーに設定する。
ここで、動作タイミングについては、予めグループ内のリーダーを一人決めておき、リーダーの動作タイミングと他の担ぎ手ユーザの動作タイミングとの一致度をそれぞれ計算し、他の担ぎ手ユーザ全員の一致度が予め設定した閾値以内（例えばズレが０．５秒以内）であれば動作タイミングが一致していると判定する。また、例えば、図１１の例では、３Ｄアバター７００＿１をリーダーに設定する。
【0074】
また、御神輿モデル６００の担ぎ手は、実在するユーザに対応する３Ｄアバター７００だけに限らず、参加人数が足りない場合などはコンピュータが制御する担ぎ手（３Ｄアバター７００）を採用してもよい。また、この場合に、コンピュータ制御される３Ｄアバター７００のなかからリーダーを選定してもよい。この場合のリーダーに対応する３Ｄアバター７００には、過去の担ぎ手ユーザのなかから選定した担ぎの上手な担ぎ手ユーザに対応する３Ｄアバター７００の動作を模倣させてもよい。
【0075】
ステップＳ２５４に移行した場合は、一致用の動作パターンでグループ全員の３Ｄアバター及び御神輿モデルの動作を制御する。その後、ステップＳ２５６に移行する。
ステップＳ２５６では、記憶装置４２に記憶された音響データ管理テーブル４６０及び音響データライブラリに登録された情報に基づいて、一致用の鈴の音の音響情報を含む出力用音響情報を生成して、一連の処理を終了し元の処理に復帰する。
これにより、ステップＳ２０６で、一致用の動作パターン情報を含む３Ｄアバター及び御神輿モデルの表示情報と、一致用の鈴の音の音響情報を含む出力用音響情報とを含むイベント提供情報が、同一グループの各担ぎ手ユーザのユーザ端末２００に送信される。
ステップＳ２５６では、記憶装置４２に記憶された音響データ管理テーブル４６０及び音響データライブラリに登録された情報に基づいて、一致用の鈴の音の音響情報を含む出力用音響情報を生成して、一連の処理を終了し元の処理に復帰する。
これにより、ステップＳ２０６で、一致用の動作パターン情報を含む３Ｄアバター及び御神輿モデルの表示情報と、一致用の鈴の音の音響情報を含む出力用音響情報とを含むイベント提供情報が、同一グループの各担ぎ手ユーザのユーザ端末２００に送信される。
【0076】
ここで、図１２（ａ）及び（ｂ）は、動作タイミングが一致したときの表示例を示す図である。各担ぎ手ユーザのユーザ端末２００の表示装置には、例えば、図１２（ａ）及び（ｂ）に示すように、御神輿モデル６００が傾くことなくタイミングを揃えて真っすぐに上下動し、且つ、複数の鈴６３０がタイミングを揃えて上に跳ね上がる動画像が表示され、スピーカからは、「チリーン♪」と綺麗な音色の鈴の音が出力される。
一方、ステップＳ２５２において、動作タイミングが一致してなくステップＳ２５８に移行した場合は、不一致用の動作パターンでグループ全員の３Ｄアバター及び御神輿モデルの動作を制御する。その後、ステップＳ２６０に移行する。
一方、ステップＳ２５２において、動作タイミングが一致してなくステップＳ２５８に移行した場合は、不一致用の動作パターンでグループ全員の３Ｄアバター及び御神輿モデルの動作を制御する。その後、ステップＳ２６０に移行する。
【0077】
ここで、不一致用の動作パターンは、動作タイミングが合わないときの御神輿モデル６００の動作パターンであり、例えば、御神輿モデル６００が不規則に揺れたり、傾いて上下動したりする動作パターンである。
また、例えば、同一グループの複数の担ぎ手ユーザの動作タイミングについて、８割以上の担ぎ手ユーザが一致している場合と、６割以上８割未満の担ぎ手ユーザが一致している場合と、３割以上６割未満の担ぎ手ユーザが一致している場合と、といったように、一致する担ぎ手ユーザの割合に応じてそれぞれ異なる動作パターンを用意する構成としてもよい。
また、例えば、同一グループの複数の担ぎ手ユーザの動作タイミングについて、８割以上の担ぎ手ユーザが一致している場合と、６割以上８割未満の担ぎ手ユーザが一致している場合と、３割以上６割未満の担ぎ手ユーザが一致している場合と、といったように、一致する担ぎ手ユーザの割合に応じてそれぞれ異なる動作パターンを用意する構成としてもよい。
【0078】
ステップＳ２６０では、記憶装置４２に記憶された音響データ管理テーブル４６０及び音響データライブラリに登録された各種情報に基づいて、不一致用の鈴の音の音響情報を含む出力用音響情報を生成して、一連の処理を終了し元の処理に復帰する。
ここで、不一致用の鈴の音は、例えば「ガランゴロン」といったように動作タイミングが不一致のときに鳴る音となる。または、鈴の音を鳴らさない出力用音響情報を生成するようにしてもよいし、出力用音響情報を生成しないようにしてもよい。また、不一致用の鈴の音についても、不一致用の動作パターンと同様に、一致する担ぎ手ユーザの割合に応じてそれぞれ異なる音響データを用意する構成としてもよい。
ここで、不一致用の鈴の音は、例えば「ガランゴロン」といったように動作タイミングが不一致のときに鳴る音となる。または、鈴の音を鳴らさない出力用音響情報を生成するようにしてもよいし、出力用音響情報を生成しないようにしてもよい。また、不一致用の鈴の音についても、不一致用の動作パターンと同様に、一致する担ぎ手ユーザの割合に応じてそれぞれ異なる音響データを用意する構成としてもよい。
【0079】
ステップＳ２６２では、ステップＳ２５０の解析結果等に基づいて、動作タイミングが一致していない担ぎ手ユーザに対して、タイミング修正情報を生成する。その後、一連の処理を終了して元の処理に復帰する。
これにより、ステップＳ２０６で、不一致用の動作パターン情報を含む３Ｄアバター及び御神輿モデルの表示情報と、不一致用の鈴の音の音響情報を含む出力用音響情報と、タイミング修正情報とを含むイベント提供情報が、同一グループの各担ぎ手ユーザのユーザ端末２００に送信される。
これにより、ステップＳ２０６で、不一致用の動作パターン情報を含む３Ｄアバター及び御神輿モデルの表示情報と、不一致用の鈴の音の音響情報を含む出力用音響情報と、タイミング修正情報とを含むイベント提供情報が、同一グループの各担ぎ手ユーザのユーザ端末２００に送信される。
【0080】
ここで、図１３は、タイミング修正情報の表示例を示す図である。
タイミング修正情報は、動作タイミングの修正が必要な担ぎ手ユーザに対してのみ表示される情報であり、図１３に示すように、御神輿を担ぐ動作のタイミングを示す矢印で示される。具体的に、持ち上げるタイミングのときに上矢印の色が変わり、下に降ろすタイミングのときに下矢印の色が変わってタイミングを知らせる。また、各担ぎ手ユーザのユーザ端末２００の表示装置には、例えば、自身に対応する３Ｄアバター７００を示す星のマークが頭上に表示される。また、動作タイミングのみに限らず、担ぐ姿勢についての修正情報を生成し、その修正情報も表示するようにしてもよい。また、頭上のマークは、リーダーとして選定された３Ｄアバター７００の頭上にも色や形状の異なるものを常に表示するようにしてもよい。
タイミング修正情報は、動作タイミングの修正が必要な担ぎ手ユーザに対してのみ表示される情報であり、図１３に示すように、御神輿を担ぐ動作のタイミングを示す矢印で示される。具体的に、持ち上げるタイミングのときに上矢印の色が変わり、下に降ろすタイミングのときに下矢印の色が変わってタイミングを知らせる。また、各担ぎ手ユーザのユーザ端末２００の表示装置には、例えば、自身に対応する３Ｄアバター７００を示す星のマークが頭上に表示される。また、動作タイミングのみに限らず、担ぐ姿勢についての修正情報を生成し、その修正情報も表示するようにしてもよい。また、頭上のマークは、リーダーとして選定された３Ｄアバター７００の頭上にも色や形状の異なるものを常に表示するようにしてもよい。
【0081】
なお、御神輿モデル６００を担ぐイベントの開始前に、各担ぎ手ユーザに対応する３Ｄアバター７００の担ぐ位置を決める必要がある。例えば、図１３に示すような表示画面にて、空いている位置に３Ｄアバター７００を移動させることで決めるか、または、リーダーが各３Ｄアバター７００の担ぐ位置を決めてもよい。
〔第１の実施の形態の効果〕
次に、第１の実施の形態の効果を説明する。
第１の実施の形態では、御神輿モデル６００の担ぎ手として割り当てられたユーザである担ぎ手ユーザのユーザ端末２００から送信された、ビデオカメラ５０で撮像した御神輿を担ぐ動作をする担ぎ手ユーザの撮像画像データ及びコントローラ５２を手で持った担ぎ手ユーザの動作に応じた６軸ジャイロセンサの検出値を含むユーザ動作情報に基づいて、御神輿モデル６００の動作及び担ぎ手ユーザに対応する３Ｄアバター７００の動作を制御するようにした。
〔第１の実施の形態の効果〕
次に、第１の実施の形態の効果を説明する。
第１の実施の形態では、御神輿モデル６００の担ぎ手として割り当てられたユーザである担ぎ手ユーザのユーザ端末２００から送信された、ビデオカメラ５０で撮像した御神輿を担ぐ動作をする担ぎ手ユーザの撮像画像データ及びコントローラ５２を手で持った担ぎ手ユーザの動作に応じた６軸ジャイロセンサの検出値を含むユーザ動作情報に基づいて、御神輿モデル６００の動作及び担ぎ手ユーザに対応する３Ｄアバター７００の動作を制御するようにした。
【0082】
このような構成であれば、担ぎ手ユーザの動作内容を御神輿モデル６００及び３Ｄアバター７００の動作制御に反映することができるので、３Ｄアバター７００が御神輿モデル６００を自動で担ぐのを見ているだけの従来の構成と比較して、担ぎ手ユーザのバーチャル御神輿イベントへの寄与度を向上することができる。その結果、バーチャル御神輿イベントの興趣を向上することができる。
また、６軸ジャイロセンサのセンサ検出値からユーザの上下動のタイミングを検出でき、また、撮像画像データからユーザの担ぐ姿勢や動作などを検出できるので、ユーザのより細かい動作内容を反映した御神輿モデル６００の動作制御及び担ぎ手ユーザに対応する３Ｄアバター７００の動作制御を行うことができる。
また、６軸ジャイロセンサのセンサ検出値からユーザの上下動のタイミングを検出でき、また、撮像画像データからユーザの担ぐ姿勢や動作などを検出できるので、ユーザのより細かい動作内容を反映した御神輿モデル６００の動作制御及び担ぎ手ユーザに対応する３Ｄアバター７００の動作制御を行うことができる。
【0083】
また、第１の実施の形態では、担ぎ手ユーザの動作タイミングが予め設定した動作タイミングと一致するか否かを判定し、一致すると判定した場合に予め設定された一致用の動作をするように御神輿モデル６００の動作及び３Ｄアバター７００の動作を制御し、一致しないと判定した場合に予め設定された不一致用の動作をするように御神輿モデル６００の動作及び３Ｄアバター７００の動作を制御するようにした。
このような構成であれば、担ぎ手ユーザが他の担ぎ手（コンピュータ制御の３Ｄアバター７００を含む）と動作タイミングを一致させるというゲーム性を付与することができるとともに、一致時と不一致時とで動作内容を異ならせるようにしたので、御神輿モデルを担ぐイベントの興趣を向上できるとともに、イベント中の御神輿を担ぐ動作を行うことへの担ぎ手ユーザの意欲（やる気）を向上することができる。
このような構成であれば、担ぎ手ユーザが他の担ぎ手（コンピュータ制御の３Ｄアバター７００を含む）と動作タイミングを一致させるというゲーム性を付与することができるとともに、一致時と不一致時とで動作内容を異ならせるようにしたので、御神輿モデルを担ぐイベントの興趣を向上できるとともに、イベント中の御神輿を担ぐ動作を行うことへの担ぎ手ユーザの意欲（やる気）を向上することができる。
【0084】
また、第１の実施の形態では、担ぎ手ユーザの動作タイミングが、予め設定した動作タイミングと一致していると判定した場合に、出力用音響情報として一致用の鈴の音を鳴らす音響情報を生成し、一致しないと判定した場合に予め設定された不一致用の鈴の音を鳴らす出力用音響情報を生成するか、鈴の音を鳴らさない出力用音響情報を生成するか又は出力用音響情報を生成しないようにした。
このような構成であれば、一致時と不一致時とで御神輿モデル６００及び３Ｄアバター７００の動作内容に加えて鈴の音の音響出力内容を異ならせることができるので、御神輿モデルを担ぐイベントの興趣を向上できるとともに、イベント中の御神輿を担ぐ動作を御行うことへのユーザの意欲（やる気）を向上することができる。
このような構成であれば、一致時と不一致時とで御神輿モデル６００及び３Ｄアバター７００の動作内容に加えて鈴の音の音響出力内容を異ならせることができるので、御神輿モデルを担ぐイベントの興趣を向上できるとともに、イベント中の御神輿を担ぐ動作を御行うことへのユーザの意欲（やる気）を向上することができる。
【0085】
また、第１の実施の形態では、御神輿モデル６００の担ぎ手（コンピュータ制御の３Ｄアバター７００を含む）のうちからリーダーを選定し、選定したリーダーの動作タイミングを、一致及び不一致を判定するための動作タイミングとするようにした。
このような構成であれば、リーダーの動作タイミングとの一致判定が行われるので、リーダー以外の担ぎ手ユーザはリーダーに対応する３Ｄアバター７００の動作タイミングに合わせて動作を行うことで容易に動作タイミングを合わせることができる。
このような構成であれば、リーダーの動作タイミングとの一致判定が行われるので、リーダー以外の担ぎ手ユーザはリーダーに対応する３Ｄアバター７００の動作タイミングに合わせて動作を行うことで容易に動作タイミングを合わせることができる。
【0086】
また、第１の実施の形態では、動作タイミングが一致しない原因となった担ぎ手ユーザのユーザ端末２００に、動作タイミングを修正するためのタイミング修正情報を送信するようにした。
このような構成であれば、タイミング不一致の原因となっている担ぎ手ユーザは、タイミング修正情報によって、動作タイミングをどのように修正すればよいか解るので、担ぎ中のタイミング修正を容易に行うことができる。
〔対応関係〕
第１の実施の形態において、ビデオカメラ５０及びコントローラ５２が、動作内容検出装置に対応し、ステップＳ１００～Ｓ１１２が、発明１のイベント参加者募集手段に対応し、記憶装置４２が、発明１の募集情報記憶手段、イベント用写真データ記憶手段、参加者写真データ記憶手段及びイベント用音響情報記憶手段に対応している。
このような構成であれば、タイミング不一致の原因となっている担ぎ手ユーザは、タイミング修正情報によって、動作タイミングをどのように修正すればよいか解るので、担ぎ中のタイミング修正を容易に行うことができる。
〔対応関係〕
第１の実施の形態において、ビデオカメラ５０及びコントローラ５２が、動作内容検出装置に対応し、ステップＳ１００～Ｓ１１２が、発明１のイベント参加者募集手段に対応し、記憶装置４２が、発明１の募集情報記憶手段、イベント用写真データ記憶手段、参加者写真データ記憶手段及びイベント用音響情報記憶手段に対応している。
【0087】
また、第１の実施の形態において、ステップＳ１５０～Ｓ１５６が、発明１のイベント用モデル生成手段に対応し、ステップＳ１７０～Ｓ１７６が、発明１の３Ｄアバター生成手段に対応している。
また、第１の実施の形態において、ステップＳ２００～Ｓ２０４及びＳ２５０～Ｓ２５４並びにＳ２５８が、発明１のモデル動作制御手段に対応し、ステップＳ２０６及びＳ２６２が、発明１のイベント提供情報送信手段に対応し、ステップＳ２５６及びＳ２６０が、出力用音響情報生成手段に対応している。
また、第１の実施の形態において、ステップＳ２００～Ｓ２０４及びＳ２５０～Ｓ２５４並びにＳ２５８が、発明１のモデル動作制御手段に対応し、ステップＳ２０６及びＳ２６２が、発明１のイベント提供情報送信手段に対応し、ステップＳ２５６及びＳ２６０が、出力用音響情報生成手段に対応している。
【0088】
〔第２の実施の形態〕
次に、本発明の第２の実施の形態を説明する。図１４乃至図１５は、第２の実施の形態を示す図である。
上記第１の実施の形態においては、単基の御神輿モデル６００を複数の担ぎ手によって担ぐバーチャル御神輿イベントを提供する場合について説明した。第２の実施の形態は、例えば、それぞれ異なる神社の複数基の御神輿モデル６００を、それぞれ別々のユーザグループで担ぐ場合に、各ユーザグループ間で競い合う（順位付けを行う）ことができるバーチャル御神輿イベントを提供する点で上記第１の実施の形態と異なる。以下、上記第１の実施の形態と異なる部分についてのみ説明し、重複する部分については説明を省略する。
次に、本発明の第２の実施の形態を説明する。図１４乃至図１５は、第２の実施の形態を示す図である。
上記第１の実施の形態においては、単基の御神輿モデル６００を複数の担ぎ手によって担ぐバーチャル御神輿イベントを提供する場合について説明した。第２の実施の形態は、例えば、それぞれ異なる神社の複数基の御神輿モデル６００を、それぞれ別々のユーザグループで担ぐ場合に、各ユーザグループ間で競い合う（順位付けを行う）ことができるバーチャル御神輿イベントを提供する点で上記第１の実施の形態と異なる。以下、上記第１の実施の形態と異なる部分についてのみ説明し、重複する部分については説明を省略する。
【0089】
第２の実施の形態では、例えば、神奈川県茅ヶ崎市の浜降祭のように、複数の神社が協力して開催する御神輿イベントをバーチャル御神輿イベントとして提供する場合において、各神社の御神輿モデルを担ぐユーザグループ間にて御神輿モデルごとに動作タイミングを評価する。そして、この評価結果に基づいて御神輿モデルごとに順位付けを行うことでユーザグループ間で順位を競い合う要素を有するバーチャル御神輿イベントを提供する。
〔モデル動作制御処理〕
以下、バーチャル御神輿イベント提供サーバ１００で実行されるモデル動作制御処理の処理手順について説明する。
〔モデル動作制御処理〕
以下、バーチャル御神輿イベント提供サーバ１００で実行されるモデル動作制御処理の処理手順について説明する。
【0090】
図１４は、第２の実施の形態に係るモデル動作制御処理を示すフローチャートである。
ＣＰＵ３０は、ＲＯＭ３２の所定領域に格納されている所定のプログラムを起動させ、そのプログラムに従って、図１４のフローチャートに示すモデル動作制御処理を実行する。
モデル動作制御処理は、イベント開催後に実行される処理であり、ＣＰＵ３０において実行されると、図１４に示すように、まず、ステップＳ３００に移行する。
ステップＳ３００では、御神輿モデルを担ぎ中か否かを判定し、担ぎ中であると判定した場合（YES）は、ステップＳ３０２に移行し、そうでないと判定した場合（NO）は、ステップＳ３０８に移行する。
ＣＰＵ３０は、ＲＯＭ３２の所定領域に格納されている所定のプログラムを起動させ、そのプログラムに従って、図１４のフローチャートに示すモデル動作制御処理を実行する。
モデル動作制御処理は、イベント開催後に実行される処理であり、ＣＰＵ３０において実行されると、図１４に示すように、まず、ステップＳ３００に移行する。
ステップＳ３００では、御神輿モデルを担ぎ中か否かを判定し、担ぎ中であると判定した場合（YES）は、ステップＳ３０２に移行し、そうでないと判定した場合（NO）は、ステップＳ３０８に移行する。
【0091】
ステップＳ３０２に移行した場合は、担ぎ手ユーザのユーザ端末２００からのユーザ動作情報を受信したか否かを判定し、受信したと判定した場合（YES）は、ステップＳ３０４に移行し、そうでないと判定した場合（NO）は、ステップＳ３１２に移行する。
ステップＳ３０４に移行した場合は、複数の御神輿モデル６００について各御神輿モデル６００の各担ぎ手ユーザのユーザ動作情報に基づいて担ぎ中動作制御処理を実行して、ステップＳ３０６に移行する。
ステップＳ３０４に移行した場合は、複数の御神輿モデル６００について各御神輿モデル６００の各担ぎ手ユーザのユーザ動作情報に基づいて担ぎ中動作制御処理を実行して、ステップＳ３０６に移行する。
【0092】
ステップＳ３０６では、担ぎ中動作制御処理若しくは通常動作制御処理で生成された情報を含むイベント提供情報、又はステップＳ３１４で決定された順位情報を含むイベント提供情報をイベントに参加している各ユーザのユーザ端末２００に送信して、一連の処理を終了し元の処理に復帰する。
これにより、イベント提供情報を受信した各ユーザのユーザ端末２００の表示装置には、担ぎ中動作制御処理及び通常動作制御処理で生成された各種イベント提供情報に応じた画像が表示され、スピーカからは担ぎ中動作制御処理又は通常動作制御処理で生成された各種イベント提供情報に応じた音響情報が出力される。また、全ての御神輿モデルが目的地に到着した後に、各ユーザのユーザ端末２００の表示装置には順位情報が表示される。
これにより、イベント提供情報を受信した各ユーザのユーザ端末２００の表示装置には、担ぎ中動作制御処理及び通常動作制御処理で生成された各種イベント提供情報に応じた画像が表示され、スピーカからは担ぎ中動作制御処理又は通常動作制御処理で生成された各種イベント提供情報に応じた音響情報が出力される。また、全ての御神輿モデルが目的地に到着した後に、各ユーザのユーザ端末２００の表示装置には順位情報が表示される。
【0093】
ここで、ステップＳ３０８～Ｓ３１０の処理は、第１の実施の形態のステップＳ２０８～Ｓ２１０の処理と同様となるので説明を省略する。
一方、ステップＳ３０８において、ユーザ操作情報を受信せずにステップＳ３１２に移行した場合は、イベントに参加している全ての御神輿モデル６００が目的地（ゴール）に到着したか否かを判定する。そして、到着したと判定した場合（YES）は、ステップＳ３１４に移行し、そうでないと判定した場合（NO）は、ステップＳ３００に移行する。
一方、ステップＳ３０８において、ユーザ操作情報を受信せずにステップＳ３１２に移行した場合は、イベントに参加している全ての御神輿モデル６００が目的地（ゴール）に到着したか否かを判定する。そして、到着したと判定した場合（YES）は、ステップＳ３１４に移行し、そうでないと判定した場合（NO）は、ステップＳ３００に移行する。
【0094】
ステップＳ３１４に移行した場合は、ステップＳ３０４の処理でカウントされた一致回数に基づいて、御神輿モデルごとの順位を決定して、ステップＳ３０６に移行する。具体的に、一致回数が多いほど上手に担げていることになるので、担ぐのが上手な順（一致回数が多い順）に順位付けが行われる。
〔担ぎ中動作制御処理〕
次に、上記ステップＳ３０４で実行される担ぎ中動作制御処理の処理手順について説明する。
図１５は、第２の実施の形態に係る担ぎ中動作制御処理を示すフローチャートである。
〔担ぎ中動作制御処理〕
次に、上記ステップＳ３０４で実行される担ぎ中動作制御処理の処理手順について説明する。
図１５は、第２の実施の形態に係る担ぎ中動作制御処理を示すフローチャートである。
【0095】
担ぎ中動作制御処理は、ＣＰＵ３０において実行されると、図１５に示すように、まず、ステップＳ３５０に移行する。
なお、ステップＳ３５０～Ｓ３５６の処理及びステップＳ３６０～Ｓ３６４の処理については、上記第１の実施の形態のステップＳ２５０～Ｓ２５６の処理及びステップＳ２５８～Ｓ２６２の処理と同様となるので説明を省略する。
ステップＳ３５８では、動作タイミングの一致回数をカウントして、一連の処理を終了し元の処理に復帰する。即ち、御神輿モデルごとに一致判定の行われた回数がカウントされる。
なお、ステップＳ３５０～Ｓ３５６の処理及びステップＳ３６０～Ｓ３６４の処理については、上記第１の実施の形態のステップＳ２５０～Ｓ２５６の処理及びステップＳ２５８～Ｓ２６２の処理と同様となるので説明を省略する。
ステップＳ３５８では、動作タイミングの一致回数をカウントして、一連の処理を終了し元の処理に復帰する。即ち、御神輿モデルごとに一致判定の行われた回数がカウントされる。
【0096】
〔第２の実施の形態の効果〕
次に、第２の実施の形態の効果を説明する。
第２の実施の形態では、複数の御神輿モデル６００が参加するバーチャル御神輿イベントにおいて、御神輿モデル６００ごとに担ぎ手の動作タイミングを評価（一致回数をカウント）し、その評価結果に基づいて御神輿モデル６００ごとに順位付けを行うようにした。
このような構成であれば、各御神輿モデル６００を担ぐ担ぎ手ユーザのグループ間で順位を競うことができるので、担ぎ手ユーザのバーチャル御神輿イベントに対する興趣や参加意欲等を向上することができる。
次に、第２の実施の形態の効果を説明する。
第２の実施の形態では、複数の御神輿モデル６００が参加するバーチャル御神輿イベントにおいて、御神輿モデル６００ごとに担ぎ手の動作タイミングを評価（一致回数をカウント）し、その評価結果に基づいて御神輿モデル６００ごとに順位付けを行うようにした。
このような構成であれば、各御神輿モデル６００を担ぐ担ぎ手ユーザのグループ間で順位を競うことができるので、担ぎ手ユーザのバーチャル御神輿イベントに対する興趣や参加意欲等を向上することができる。
【0097】
〔対応関係〕
第２の実施の形態において、ステップＳ３５８が、発明７の動作タイミング評価手段に対応し、ステップＳ３１４が、発明７の順位決定手段に対応している。
〔第３の実施の形態〕
次に、本発明の第３の実施の形態を説明する。図１６乃至図１９は、第３の実施の形態を示す図である。
上記第１の実施の形態においては、バーチャル御神輿イベントの参加者の募集をＷｅｂページにて行う場合について説明したが、第３の実施の形態では、各ユーザ間で回覧情報を回覧することで行う点で異なる。以下、上記第１の実施の形態と異なる部分についてのみ説明し、重複する部分については説明を省略する。
第２の実施の形態において、ステップＳ３５８が、発明７の動作タイミング評価手段に対応し、ステップＳ３１４が、発明７の順位決定手段に対応している。
〔第３の実施の形態〕
次に、本発明の第３の実施の形態を説明する。図１６乃至図１９は、第３の実施の形態を示す図である。
上記第１の実施の形態においては、バーチャル御神輿イベントの参加者の募集をＷｅｂページにて行う場合について説明したが、第３の実施の形態では、各ユーザ間で回覧情報を回覧することで行う点で異なる。以下、上記第１の実施の形態と異なる部分についてのみ説明し、重複する部分については説明を省略する。
【0098】
まず、第３の実施の形態に係るユーザ情報管理テーブル４００Ａのデータ構造について説明する。
図１６は、第３の実施の形態に係るユーザ情報管理テーブル４００Ａのデータ構造を示す図である。
記憶装置４２には、図１６に示すように、ユーザ情報管理テーブル４００Ａが記憶されている。
ユーザ情報管理テーブル４００Ａには、図１６に示すように、ユーザＩＤごとに１つのレコードが登録されている。各レコードは、ユーザＩＤ、ユーザの住所、ユーザの氏名、ユーザのメールアドレス、ログインパスワード、ユーザが過去に参加したイベントのイベントＩＤ、回覧先選択回数、その他の情報が登録されている。ここで、回覧先選択回数は、イベント参加者を募集する回覧情報の回覧において、回覧先に選択された回数である。
図１６は、第３の実施の形態に係るユーザ情報管理テーブル４００Ａのデータ構造を示す図である。
記憶装置４２には、図１６に示すように、ユーザ情報管理テーブル４００Ａが記憶されている。
ユーザ情報管理テーブル４００Ａには、図１６に示すように、ユーザＩＤごとに１つのレコードが登録されている。各レコードは、ユーザＩＤ、ユーザの住所、ユーザの氏名、ユーザのメールアドレス、ログインパスワード、ユーザが過去に参加したイベントのイベントＩＤ、回覧先選択回数、その他の情報が登録されている。ここで、回覧先選択回数は、イベント参加者を募集する回覧情報の回覧において、回覧先に選択された回数である。
【0099】
〔イベント参加者募集処理〕
次に、バーチャル御神輿イベント提供サーバ１００で実行されるイベント参加者募集処理の処理手順について説明する。
図１７は、第３の実施の形態に係るイベント参加者募集処理を示すフローチャートである。
ＣＰＵ３０は、ＲＯＭ３２の所定領域に格納されている所定のプログラムを起動させ、そのプログラムに従って、図１７のフローチャートに示すイベント参加者募集処理を実行する。
イベント参加者募集処理は、ＣＰＵ３０において実行されると、図１７に示すように、まず、ステップＳ５００に移行する。
次に、バーチャル御神輿イベント提供サーバ１００で実行されるイベント参加者募集処理の処理手順について説明する。
図１７は、第３の実施の形態に係るイベント参加者募集処理を示すフローチャートである。
ＣＰＵ３０は、ＲＯＭ３２の所定領域に格納されている所定のプログラムを起動させ、そのプログラムに従って、図１７のフローチャートに示すイベント参加者募集処理を実行する。
イベント参加者募集処理は、ＣＰＵ３０において実行されると、図１７に示すように、まず、ステップＳ５００に移行する。
【0100】
ステップＳ５００では、記憶装置４２の募集情報テーブル４１０に登録された募集情報のうち、募集処理が未処理の募集情報を取得して、ステップＳ５０２に移行する。
ステップＳ５０２では、イベントの名称、内容、場所、開催日、募集人数の上限又は下限及び募集期限を含むイベント参加者募集用の回覧情報を生成して、ステップＳ５０４に移行する。
ステップＳ５０４では、記憶装置４２のユーザ情報管理テーブル４００に登録されたユーザのなかから代表ユーザを選択して、ステップＳ５０６に移行する。
ステップＳ５０２では、イベントの名称、内容、場所、開催日、募集人数の上限又は下限及び募集期限を含むイベント参加者募集用の回覧情報を生成して、ステップＳ５０４に移行する。
ステップＳ５０４では、記憶装置４２のユーザ情報管理テーブル４００に登録されたユーザのなかから代表ユーザを選択して、ステップＳ５０６に移行する。
【0101】
ここでは、ユーザ情報管理テーブル４００Ａに登録されている各ユーザの回覧先選択回数の情報に基づいて、回覧先選択回数の比較的多いユーザを代表ユーザとして選択する。例えば、過去に同じイベントに参加しているユーザのなかから回覧先選択回数の一番多いユーザを代表ユーザとして選択したり、過去に代表ユーザとして選択されたことがないユーザのなかから回覧先選択回数の一番多いユーザを代表ユーザとして選択したりする。
ステップＳ５０６では、ステップＳ５０２で生成した回覧情報を、ステップＳ５０４で選択した代表ユーザのユーザ端末２００に送信して、ステップＳ５０８に移行する。
ステップＳ５０６では、ステップＳ５０２で生成した回覧情報を、ステップＳ５０４で選択した代表ユーザのユーザ端末２００に送信して、ステップＳ５０８に移行する。
【0102】
ここで、回覧情報の送付は、バーチャル御神輿イベント参加用のアプリケーション上のメッセージ機能を用いて行われる。なお、この構成に限らず、例えば、登録されたメールアドレス宛てに送信するなど他の構成としてもよい。
ステップＳ５０８では、記憶装置４２の募集情報テーブル４１０に登録された全ての募集情報に対する回覧情報を送信したか否かを判定し、送信したと判定した場合（YES）は、一連の処理を終了し、そうでないと判定した場合（NO）は、ステップＳ５００に移行する。
ステップＳ５０８では、記憶装置４２の募集情報テーブル４１０に登録された全ての募集情報に対する回覧情報を送信したか否かを判定し、送信したと判定した場合（YES）は、一連の処理を終了し、そうでないと判定した場合（NO）は、ステップＳ５００に移行する。
【0103】
〔回覧情報回覧処理〕
次に、ユーザ端末２００で実行される回覧情報回覧処理の処理手順について説明する。
図１８は、回覧情報回覧処理を示すフローチャートである。
ユーザ端末２００のＣＰＵは、ＲＯＭの所定領域に格納されている所定のプログラムを起動させ、そのプログラムに従って、図１８のフローチャートに示す回覧情報回覧処理を実行する。
回覧情報回覧処理は、ユーザ端末２００のＣＰＵにおいて実行されると、図１８に示すように、まず、ステップＳ６００に移行する。
次に、ユーザ端末２００で実行される回覧情報回覧処理の処理手順について説明する。
図１８は、回覧情報回覧処理を示すフローチャートである。
ユーザ端末２００のＣＰＵは、ＲＯＭの所定領域に格納されている所定のプログラムを起動させ、そのプログラムに従って、図１８のフローチャートに示す回覧情報回覧処理を実行する。
回覧情報回覧処理は、ユーザ端末２００のＣＰＵにおいて実行されると、図１８に示すように、まず、ステップＳ６００に移行する。
【0104】
ステップＳ６００では、回覧情報を受信したか否かを判定し、受信したと判定した場合（YES）は、ステップＳ６０２に移行し、そうでないと判定した場合（NO）は、受信するまで判定処理を繰り返す。
ステップＳ６０２に移行した場合は、バーチャル御神輿イベントの運営からの回覧か否かを判定し、運営からの回覧であると判定した場合（YES）は、ステップＳ６０４に移行し、そうでないと判定した場合（NO）は、ステップＳ６１０に移行する。
ステップＳ６０２に移行した場合は、バーチャル御神輿イベントの運営からの回覧か否かを判定し、運営からの回覧であると判定した場合（YES）は、ステップＳ６０４に移行し、そうでないと判定した場合（NO）は、ステップＳ６１０に移行する。
【0105】
ステップＳ６０４に移行した場合は、受信した回覧情報に、イベントへの参加の可否を示す情報を付加して、ステップＳ６０６に移行する。ここで、運営からの回覧情報を受信した場合は、受信したユーザ端末２００のユーザが代表ユーザとなる。
ステップＳ６０６では、フレンド登録されたユーザなどのうちから次の回覧先を選択して、ステップＳ６０８に移行する。これにより、次の回覧先のユーザの情報（ユーザＩＤ等）が回覧情報に付加される。
ステップＳ６０６では、フレンド登録されたユーザなどのうちから次の回覧先を選択して、ステップＳ６０８に移行する。これにより、次の回覧先のユーザの情報（ユーザＩＤ等）が回覧情報に付加される。
【0106】
ステップＳ６０８では、回覧情報を次の回覧先に送信して、一連の処理を終了する。
一方、ステップＳ６０２において、運営からの回覧ではなくステップＳ６１０に移行した場合は、代表ユーザへの戻りの回覧か否かを判定し、戻りの回覧であると判定した場合（YES）は、ステップＳ６１２に移行し、そうでないと判定した場合（NO）は、ステップＳ６１６に移行する。
ステップＳ６１２に移行した場合は、回覧情報に含まれる参加を表明しているユーザを参加メンバーとして確定し、ステップＳ６１４に移行する。
一方、ステップＳ６０２において、運営からの回覧ではなくステップＳ６１０に移行した場合は、代表ユーザへの戻りの回覧か否かを判定し、戻りの回覧であると判定した場合（YES）は、ステップＳ６１２に移行し、そうでないと判定した場合（NO）は、ステップＳ６１６に移行する。
ステップＳ６１２に移行した場合は、回覧情報に含まれる参加を表明しているユーザを参加メンバーとして確定し、ステップＳ６１４に移行する。
【0107】
ステップＳ６１４では、確定した参加メンバーの情報であるメンバー情報（ユーザＩＤ等）を、バーチャル御神輿イベント提供サーバ１００に送信して、一連の処理を終了する。
また、ステップＳ６１０において代表ユーザへの戻りではなくステップＳ６１６に移行した場合は、回覧先に選ばれたユーザとして、受信した回覧情報に参加の可否を示す情報を付加して、ステップＳ６１８に移行する。
ステップＳ６１８では、参加人数が規定人数に達しているか又は現在日時が募集期限に達しているか否かを判定し、規定人数に達している又は期限に達していると判定した場合（YES）は、ステップＳ６２０に移行し、そうでないと判定した場合（NO）は、ステップＳ６２２に移行する。
また、ステップＳ６１０において代表ユーザへの戻りではなくステップＳ６１６に移行した場合は、回覧先に選ばれたユーザとして、受信した回覧情報に参加の可否を示す情報を付加して、ステップＳ６１８に移行する。
ステップＳ６１８では、参加人数が規定人数に達しているか又は現在日時が募集期限に達しているか否かを判定し、規定人数に達している又は期限に達していると判定した場合（YES）は、ステップＳ６２０に移行し、そうでないと判定した場合（NO）は、ステップＳ６２２に移行する。
【0108】
ステップＳ６２０に移行した場合は、ステップＳ６１６で参加の可否を示す情報を付加した回覧情報を、代表ユーザのユーザ端末２００に送信して、一連の処理を終了する。
一方、ステップＳ６２２に移行した場合は、フレンド登録されたユーザなどのうちから次の回覧先を選択して、ステップＳ６２４に移行する。これにより、次の回覧先のユーザの情報が回覧情報に付加される。
ステップＳ６２４では、回覧情報を次の回覧先に送信して、一連の処理を終了する。
一方、ステップＳ６２２に移行した場合は、フレンド登録されたユーザなどのうちから次の回覧先を選択して、ステップＳ６２４に移行する。これにより、次の回覧先のユーザの情報が回覧情報に付加される。
ステップＳ６２４では、回覧情報を次の回覧先に送信して、一連の処理を終了する。
【0109】
〔回覧先選択回数更新処理〕
次に、バーチャル御神輿イベント提供サーバ１００で実行される回覧先選択回数更新処理の処理手順について説明する。
図１９は、回覧先選択回数更新処理を示すフローチャートである。
ＣＰＵ３０は、ＲＯＭ３２の所定領域に格納されている所定のプログラムを起動させ、そのプログラムに従って、図１９のフローチャートに示す回覧先選択回数更新処理を実行する。
回覧先選択回数更新処理は、ＣＰＵ３０において実行されると、図１９に示すように、まず、ステップＳ７００に移行する。
次に、バーチャル御神輿イベント提供サーバ１００で実行される回覧先選択回数更新処理の処理手順について説明する。
図１９は、回覧先選択回数更新処理を示すフローチャートである。
ＣＰＵ３０は、ＲＯＭ３２の所定領域に格納されている所定のプログラムを起動させ、そのプログラムに従って、図１９のフローチャートに示す回覧先選択回数更新処理を実行する。
回覧先選択回数更新処理は、ＣＰＵ３０において実行されると、図１９に示すように、まず、ステップＳ７００に移行する。
【0110】
ステップＳ７００では、代表ユーザのユーザ端末２００からのメンバー情報を受信したか否かを判定し、受信したと判定した場合（YES）は、ステップＳ７０２に移行し、そうでないと判定した場合（NO）は、受信するまで判定処理を繰り返す。
ステップＳ７０２に移行した場合は、受信したメンバー情報に基づいて、参加メンバーの情報を記憶装置４２のイベント参加者管理テーブル４１５に登録して、ステップＳ７０４に移行する。
ステップＳ７０４では、参加メンバー情報から回覧先に選択されたユーザの情報を抽出して、ステップＳ７０６に移行する。
ステップＳ７０２に移行した場合は、受信したメンバー情報に基づいて、参加メンバーの情報を記憶装置４２のイベント参加者管理テーブル４１５に登録して、ステップＳ７０４に移行する。
ステップＳ７０４では、参加メンバー情報から回覧先に選択されたユーザの情報を抽出して、ステップＳ７０６に移行する。
【0111】
ステップＳ７０６では、記憶装置４２のユーザ情報管理テーブル４００Ａに登録されている該当ユーザの回覧先選択回数を更新（カウントアップ）して、一連の処理を終了する。
〔第３の実施の形態の効果〕
次に、第３の実施の形態の効果を説明する。
第３の実施の形態では、バーチャル御神輿イベント提供サーバ１００は、募集情報に基づいて、イベントの名称、内容、場所、開催日、募集人数の上限又は下限及び募集期限を含む参加者募集用の回覧情報を生成し、過去にバーチャル御神輿イベントに参加したことのある登録ユーザのなかから代表ユーザを選定し、選定した代表ユーザのユーザ端末２００に回覧情報を送信するようにした。加えて、ユーザ端末２００は、受信した回覧情報に対してバーチャル御神輿イベントへの参加の可否を示す情報を付加可能とし、受信した回覧情報に対して次の回覧先のユーザの情報を付加可能とし、参加の可否を示す情報及び次の回覧先のユーザの情報が付加された回覧情報を次の回覧先のユーザのユーザ端末２００に送信するようにした。また、参加の可否を示す情報が付加された回覧情報に基づいて、この回覧情報に対応するバーチャル御神輿イベントの参加人数が規定に達している又は現在の日時が募集期限に達していると判定した場合に、この回覧情報を代表ユーザのユーザ端末２００に送信するようにした。さらにまた、ユーザ端末２００のユーザが代表ユーザに選定されており且つ参加人数が規定に達しているか又は現在日時が募集期限に達している回覧情報を受信した場合に、受信した回覧情報に基づいて参加メンバーを確定し、確定した参加メンバーの情報をバーチャル御神輿イベント提供サーバ１００に送信するようにした。
〔第３の実施の形態の効果〕
次に、第３の実施の形態の効果を説明する。
第３の実施の形態では、バーチャル御神輿イベント提供サーバ１００は、募集情報に基づいて、イベントの名称、内容、場所、開催日、募集人数の上限又は下限及び募集期限を含む参加者募集用の回覧情報を生成し、過去にバーチャル御神輿イベントに参加したことのある登録ユーザのなかから代表ユーザを選定し、選定した代表ユーザのユーザ端末２００に回覧情報を送信するようにした。加えて、ユーザ端末２００は、受信した回覧情報に対してバーチャル御神輿イベントへの参加の可否を示す情報を付加可能とし、受信した回覧情報に対して次の回覧先のユーザの情報を付加可能とし、参加の可否を示す情報及び次の回覧先のユーザの情報が付加された回覧情報を次の回覧先のユーザのユーザ端末２００に送信するようにした。また、参加の可否を示す情報が付加された回覧情報に基づいて、この回覧情報に対応するバーチャル御神輿イベントの参加人数が規定に達している又は現在の日時が募集期限に達していると判定した場合に、この回覧情報を代表ユーザのユーザ端末２００に送信するようにした。さらにまた、ユーザ端末２００のユーザが代表ユーザに選定されており且つ参加人数が規定に達しているか又は現在日時が募集期限に達している回覧情報を受信した場合に、受信した回覧情報に基づいて参加メンバーを確定し、確定した参加メンバーの情報をバーチャル御神輿イベント提供サーバ１００に送信するようにした。
【0112】
このような構成であれば、代表ユーザを起点に、代表ユーザの知人及び回覧先に選ばれた各ユーザの知人等で回覧情報を回覧することができるので参加メンバーを集めやすくすることができる。例えば、過去にバーチャル御神輿イベントで交流のあったユーザやいつもチームを組んでいるユーザの間で回覧情報が回覧される。
また、第３の実施の形態において、登録した各ユーザの回覧情報の回覧先に選択された回数を計数するとともに計数した回数である回覧先選択回数を記憶装置４２のユーザ情報管理テーブル４００Ａに登録し、登録された回覧先選択回数に基づいて代表ユーザを選定するようにした。
また、第３の実施の形態において、登録した各ユーザの回覧情報の回覧先に選択された回数を計数するとともに計数した回数である回覧先選択回数を記憶装置４２のユーザ情報管理テーブル４００Ａに登録し、登録された回覧先選択回数に基づいて代表ユーザを選定するようにした。
【0113】
このような構成であれば、例えば、回覧先として選択された回数の多いユーザを代表ユーザとして選定することができるので、比較的人気の高い（知人が多い）ユーザを起点に回覧情報を回覧することができる。その結果、参加メンバーをより集めやすくすることができる。
〔対応関係〕
第３の実施の形態において、ステップＳ５００～Ｓ５０８が、発明８及び９のイベント参加者募集手段に対応し、ステップＳ６０４及びＳ６１６が、発明８の参加可否情報付加手段に対応し、ステップＳ６０６及びＳ６２２が、発明８の回覧先情報付加手段に対応し、ステップＳ６０９及びＳ６２４が、発明８の第１回覧情報送信手段に対応している。
〔対応関係〕
第３の実施の形態において、ステップＳ５００～Ｓ５０８が、発明８及び９のイベント参加者募集手段に対応し、ステップＳ６０４及びＳ６１６が、発明８の参加可否情報付加手段に対応し、ステップＳ６０６及びＳ６２２が、発明８の回覧先情報付加手段に対応し、ステップＳ６０９及びＳ６２４が、発明８の第１回覧情報送信手段に対応している。
【0114】
また、第３の実施の形態において、ステップＳ６１８及びＳ６２０が、発明８の第２回覧情報送信手段に対応し、ステップＳ６１０～Ｓ６１４が、発明８のメンバー情報送信手段に対応し、記憶装置４２が、発明９のユーザ情報記憶手段に対応している。
〔第４の実施の形態〕
次に、本発明の第４の実施の形態を説明する。図２０乃至図２２は、第４の実施の形態を示す図である。
上記第１の実施の形態においては、イベント開催者（事務局）側が登録した写真データに基づいて、御神輿モデル６００の移動ルートを含むイベント会場モデルを生成する場合について説明した。これに対し、第４の実施の形態では、実際の地形、建物、道路等を撮像した撮像画像データに基づいて構成された３Ｄマップデータを有する地図アプリケーションソフト（以下、「地図アプリ」と略称する）を利用してバーチャル御神輿イベントのイベント開催地及び御神輿モデル６００の移動ルートを設定する。加えて、３Ｄマップデータに基づいてイベント会場モデルを生成する点が異なる。以下、上記第１の実施の形態と異なる部分についてのみ説明し、重複する部分については説明を省略する。
〔第４の実施の形態〕
次に、本発明の第４の実施の形態を説明する。図２０乃至図２２は、第４の実施の形態を示す図である。
上記第１の実施の形態においては、イベント開催者（事務局）側が登録した写真データに基づいて、御神輿モデル６００の移動ルートを含むイベント会場モデルを生成する場合について説明した。これに対し、第４の実施の形態では、実際の地形、建物、道路等を撮像した撮像画像データに基づいて構成された３Ｄマップデータを有する地図アプリケーションソフト（以下、「地図アプリ」と略称する）を利用してバーチャル御神輿イベントのイベント開催地及び御神輿モデル６００の移動ルートを設定する。加えて、３Ｄマップデータに基づいてイベント会場モデルを生成する点が異なる。以下、上記第１の実施の形態と異なる部分についてのみ説明し、重複する部分については説明を省略する。
【0115】
第４の実施の形態では、地図アプリを利用して、バーチャル御神輿イベントの開催地及び御神輿モデル６００の移動ルートの設定並びにイベント会場モデルの生成を行うようになっている。３Ｄマップデータを有する地図アプリとしては、利用の可否は別にして、例えば、Googleマップ（登録商標）や、GoogleEarth（登録商標）などがある。
〔イベント会場モデル生成処理〕
以下、バーチャル御神輿イベント提供サーバ１００で実行されるイベント会場モデル生成処理の処理手順について説明する。
〔イベント会場モデル生成処理〕
以下、バーチャル御神輿イベント提供サーバ１００で実行されるイベント会場モデル生成処理の処理手順について説明する。
【0116】
図２０は、イベント会場モデル生成処理を示すフローチャートである。
ＣＰＵ３０は、ＲＯＭ３２の所定領域に格納されている所定のプログラムを起動させ、そのプログラムに従って、図２０のフローチャートに示すイベント会場モデル生成処理を実行する。
イベント会場モデル生成処理は、ＣＰＵ３０において実行されると、図２０に示すように、まず、ステップＳ８００に移行する。
ステップＳ８００では、イベント会場の設定を担当する担当者（以下、単に「担当者」という）の利用する事務局端末３００又はユーザ端末２００（以下、「担当者端末」と略称する）からのイベント開催地の設定に係る受信情報に基づいて、地図アプリを利用してイベント開催地を設定するか否かを判定する。そして、設定すると判定した場合（YES）は、ステップＳ８０１に移行し、そうでないと判定した場合（NO）は、一連の処理を終了する。
ＣＰＵ３０は、ＲＯＭ３２の所定領域に格納されている所定のプログラムを起動させ、そのプログラムに従って、図２０のフローチャートに示すイベント会場モデル生成処理を実行する。
イベント会場モデル生成処理は、ＣＰＵ３０において実行されると、図２０に示すように、まず、ステップＳ８００に移行する。
ステップＳ８００では、イベント会場の設定を担当する担当者（以下、単に「担当者」という）の利用する事務局端末３００又はユーザ端末２００（以下、「担当者端末」と略称する）からのイベント開催地の設定に係る受信情報に基づいて、地図アプリを利用してイベント開催地を設定するか否かを判定する。そして、設定すると判定した場合（YES）は、ステップＳ８０１に移行し、そうでないと判定した場合（NO）は、一連の処理を終了する。
【0117】
ここで、イベント会場モデルの設定は、イベントを開催する事務局又はイベントに参加するユーザのいずれにも設定可能となっている。これにより、例えば、実在する御神輿イベントをバーチャル化したものに限らず、オリジナルのバーチャル御神輿イベントを開催できるようになっている。
ステップＳ８０１に移行した場合は、担当者端末からの１又は複数のイベント開催地の情報を取得（受信）して、ステップＳ８０２に移行する。
ここで、イベント開催地の情報は、例えば、地図アプリの地図画像上での神社の選択情報等が該当する。また、別途、イベント開催地の住所の情報等を入力してもよい。
ステップＳ８０１に移行した場合は、担当者端末からの１又は複数のイベント開催地の情報を取得（受信）して、ステップＳ８０２に移行する。
ここで、イベント開催地の情報は、例えば、地図アプリの地図画像上での神社の選択情報等が該当する。また、別途、イベント開催地の住所の情報等を入力してもよい。
【0118】
ステップＳ８０２では、担当者端末からの手動設定の選択に係る受信情報に基づいて、御神輿モデルの移動ルートを手動で設定するか否かを判定する。そして、手動で設定すると判定した場合（YES）は、ステップＳ８０４に移行し、そうでないと判定した場合（NO）は、ステップＳ８１２に移行する。
ステップＳ８０４に移行した場合は、担当者端末からの手動設定されたルート情報を取得（受信）して、ステップＳ８０６に移行する。
ここで、図２１は、イベント開催地が１つの場合の地図アプリの地図画像上で手動で移動ルートを設定している様子を示す図である。
ステップＳ８０４に移行した場合は、担当者端末からの手動設定されたルート情報を取得（受信）して、ステップＳ８０６に移行する。
ここで、図２１は、イベント開催地が１つの場合の地図アプリの地図画像上で手動で移動ルートを設定している様子を示す図である。
【0119】
手動で移動ルートを設定する場合は、イベント会場の設定を担当する担当者端末の表示装置に、例えば、図２１に示す地図画像が表示される。この地図画像は、御神輿モデル６００の移動ルートを指定するためのもので２Ｄ表示でも３Ｄ表示でもよい。担当者は、入力装置を用いて、表示された地図画像上で移動ルートを設定することができる。図２１の例では、ステップＳ８０１で取得したイベント開催地の情報に基づいて、「鶴岡八幡宮」が丸で囲まれた状態となっている。また、図２１の例では、同図中の矢線で示したように、「鶴岡八幡宮」をスタートして、三の鳥居を通過した後に段葛を通って二の鳥居に向かって進み、二の鳥居を抜けた先を左折してその先をさらに左折して小町大路へと入り、小町大路を進んだ先で交差する横大路を左折して、再び三の鳥居を通って「鶴岡八幡宮」に戻ってくる移動ルートが設定されている。
【0120】
また、複数のコミュニティ（例えば神社）にて共催イベントを開催する場合に、複数のイベント開催地を設定することが可能となっている。図２２は、イベント開催地が複数の場合の地図アプリの地図画像上で移動ルートを手動で設定している様子を示す図である。
図２２に示すように、地図画像上には、ステップＳ８０１で取得した複数のイベント開催地の情報に基づいて、共催イベントのイベント開催地となる複数の神社が丸で囲まれた状態で表示されている。ユーザは、マウス等の入力装置を用いて、表示された地図画像上で複数のイベント開催地を結ぶ移動ルートを設定することができる。図２２の例では、イベント開催地として設定された「御霊神社」、「金刀比羅神社」、「八雲神社」及び「住吉神社」を結ぶ移動ルートが設定されている。具体的に、図２２の例では、「御霊神社」をスタートして、「住吉神社」→「八雲神社」→「金刀比羅神社」を通って、再び「御霊神社」に戻ってくる移動ルートが設定されている。
図２２に示すように、地図画像上には、ステップＳ８０１で取得した複数のイベント開催地の情報に基づいて、共催イベントのイベント開催地となる複数の神社が丸で囲まれた状態で表示されている。ユーザは、マウス等の入力装置を用いて、表示された地図画像上で複数のイベント開催地を結ぶ移動ルートを設定することができる。図２２の例では、イベント開催地として設定された「御霊神社」、「金刀比羅神社」、「八雲神社」及び「住吉神社」を結ぶ移動ルートが設定されている。具体的に、図２２の例では、「御霊神社」をスタートして、「住吉神社」→「八雲神社」→「金刀比羅神社」を通って、再び「御霊神社」に戻ってくる移動ルートが設定されている。
【0121】
ステップＳ８０６では、ステップＳ８０１及びＳ８０４、又はステップＳ８０１及びＳ８２４で取得した１又は複数のイベント開催地の情報及び移動ルートのルート情報に対応する３Ｄマップデータを地図アプリから取得して、ステップＳ８０８に移行する。
ステップＳ８０８では、ステップＳ８０６で取得した３Ｄマップデータを用いて、イベント会場モデルを生成する。その後、ステップＳ８１０に移行する。
ここで、３Ｄマップデータは、例えば、イベント用写真データライブラリに登録されたイベント用写真データで不足する分を補う形で用いるようにしてもよい。例えば、３Ｄマップデータに含まれる不足分の写真データを取得してイベント用写真ライブラリに登録し、登録したイベント用写真データを用いてイベント会場モデルを生成する。また、例えば、３Ｄマップデータに含まれるモデルデータから、不足分のモデルデータを取得してイベント会場モデルを生成する。また、不足分を補う形に限らず、地図アプリの３Ｄマップデータのみを用いてイベント会場モデルを生成してもよい。
ステップＳ８０８では、ステップＳ８０６で取得した３Ｄマップデータを用いて、イベント会場モデルを生成する。その後、ステップＳ８１０に移行する。
ここで、３Ｄマップデータは、例えば、イベント用写真データライブラリに登録されたイベント用写真データで不足する分を補う形で用いるようにしてもよい。例えば、３Ｄマップデータに含まれる不足分の写真データを取得してイベント用写真ライブラリに登録し、登録したイベント用写真データを用いてイベント会場モデルを生成する。また、例えば、３Ｄマップデータに含まれるモデルデータから、不足分のモデルデータを取得してイベント会場モデルを生成する。また、不足分を補う形に限らず、地図アプリの３Ｄマップデータのみを用いてイベント会場モデルを生成してもよい。
【0122】
ステップＳ８１０では、ステップＳ８０８で生成したイベント会場モデルを、イベント用モデルライブラリに登録するとともに、生成したイベント会場モデルの管理情報をイベント用モデル管理テーブル４３０に登録する。このとき、移動ルートの情報もイベント用モデルライブラリに登録する。その後、一連の処理を終了する。
一方、ステップＳ８０２で手動設定が選択されずにステップＳ８１２に移行した場合は、担当者端末からの移動ルートの候補に係る受信情報に基づいて、移動ルートの候補を表示するか否かを判定する。そして、表示すると判定した場合（YES）は、ステップＳ８１４に移行し、そうでないと判定した場合（NO）は、ステップＳ８０２に移行する。
一方、ステップＳ８０２で手動設定が選択されずにステップＳ８１２に移行した場合は、担当者端末からの移動ルートの候補に係る受信情報に基づいて、移動ルートの候補を表示するか否かを判定する。そして、表示すると判定した場合（YES）は、ステップＳ８１４に移行し、そうでないと判定した場合（NO）は、ステップＳ８０２に移行する。
【0123】
ステップＳ８１４に移行した場合は、ユーザ情報管理テーブル４００からイベント参加者全員の住所情報を取得して、ステップＳ８１６に移行する。
ステップＳ８１６では、地図アプリ及び交通情報アプリからイベント開催地周辺の道路情報を取得して、ステップＳ８１８に移行する。ここで、道路情報は、道幅等の情報、渋滞情報等の交通情報などが含まれる。なお、イベントごとの御神輿モデルの移動ルートの最大範囲は予め設定されており、この範囲内の道路情報を取得する。
ステップＳ８１６では、地図アプリ及び交通情報アプリからイベント開催地周辺の道路情報を取得して、ステップＳ８１８に移行する。ここで、道路情報は、道幅等の情報、渋滞情報等の交通情報などが含まれる。なお、イベントごとの御神輿モデルの移動ルートの最大範囲は予め設定されており、この範囲内の道路情報を取得する。
【0124】
ステップＳ８１８では、記憶装置４２のイベント用モデルライブラリから、過去に採用されたルート情報を取得して、ステップＳ８２０に移行する。
ステップＳ８２０では、ステップＳ８１４～Ｓ８１８で取得した各種情報に基づいて、担当者に対して推奨する移動ルートの情報であるルート候補情報を生成して、ステップＳ８２２に移行する。
ここでは、ルート候補情報として、イベント参加者の住居の近くをなるべく多く通るルート、車通りが比較的少ないルート、道幅が比較的広いルート及び過去採用したルートのルート情報を生成する。
ステップＳ８２０では、ステップＳ８１４～Ｓ８１８で取得した各種情報に基づいて、担当者に対して推奨する移動ルートの情報であるルート候補情報を生成して、ステップＳ８２２に移行する。
ここでは、ルート候補情報として、イベント参加者の住居の近くをなるべく多く通るルート、車通りが比較的少ないルート、道幅が比較的広いルート及び過去採用したルートのルート情報を生成する。
【0125】
ステップＳ８２２では、ステップＳ８２０で生成したルート候補情報を、担当者端末に送信して、ステップＳ８２４に移行する。
これにより、担当者端末の表示装置には、例えば、図２１又は図２２に示すような矢線で、複数のルート候補が表示される。表示内容としては、例えば、カーナビゲーションシステムのように、複数のルート候補のうち、選択したものが色濃く（又は明るく）表示され、他のルートが薄く（又は暗く）表示されるようにする。また、選択状態のルート候補について、それぞれルートの内容を説明する文章、距離、設定時速による移動時間等の情報を表示してもよい。担当者は、マウス等の入力装置によって、複数のルート候補のうちいずれか１つを選択した状態で決定ボタンなどを押下することで移動ルートの選択が確定する。
これにより、担当者端末の表示装置には、例えば、図２１又は図２２に示すような矢線で、複数のルート候補が表示される。表示内容としては、例えば、カーナビゲーションシステムのように、複数のルート候補のうち、選択したものが色濃く（又は明るく）表示され、他のルートが薄く（又は暗く）表示されるようにする。また、選択状態のルート候補について、それぞれルートの内容を説明する文章、距離、設定時速による移動時間等の情報を表示してもよい。担当者は、マウス等の入力装置によって、複数のルート候補のうちいずれか１つを選択した状態で決定ボタンなどを押下することで移動ルートの選択が確定する。
【0126】
ステップＳ８２４では、担当者端末からのルート選択に係る受信情報に基づいて、選択されたルート候補のルート情報を取得して、ステップＳ８０６に移行する。
〔第４の実施の形態の効果〕
次に、第４の実施の形態の効果を説明する。
第４の実施の形態では、バーチャル御神輿イベントのイベント会場の設定を担当する担当者が利用する事務局端末３００又はユーザ端末２００からの指示情報に基づいて、実際の地形、建物、道路等を撮像した撮像画像データに基づいて構成された３Ｄマップデータを有する地図アプリケーションソフトの提供する地図上で、１又は複数のイベント開催地及びスタート地点からゴール地点までの御神輿モデル６００の移動ルートを設定し、設定した１又は複数のイベント開催地及び移動ルートに対応する３Ｄマップデータに基づいて、イベント会場モデルを生成するようにした。
〔第４の実施の形態の効果〕
次に、第４の実施の形態の効果を説明する。
第４の実施の形態では、バーチャル御神輿イベントのイベント会場の設定を担当する担当者が利用する事務局端末３００又はユーザ端末２００からの指示情報に基づいて、実際の地形、建物、道路等を撮像した撮像画像データに基づいて構成された３Ｄマップデータを有する地図アプリケーションソフトの提供する地図上で、１又は複数のイベント開催地及びスタート地点からゴール地点までの御神輿モデル６００の移動ルートを設定し、設定した１又は複数のイベント開催地及び移動ルートに対応する３Ｄマップデータに基づいて、イベント会場モデルを生成するようにした。
【0127】
このような構成であれば、御神輿モデルの移動ルートを容易に設定できることに加えて、設定した移動ルートによるイベント会場モデルを容易に生成することができる。また、実在するイベントにおける御神輿の移動ルートに縛られずに、オリジナルの移動ルートへの変更も簡易に行うことができる。
また、第４の実施の形態において、担当者端末を介した担当者からの要求に応じて、御神輿モデル６００の移動ルートとして、バーチャル御神輿イベントに参加する複数の参加者の住居の近くをなるべく多く通るルート、車通りが比較的少ないルート、道幅が比較的広いルート又は過去採用したルートを、要求元の担当者に推奨する。
また、第４の実施の形態において、担当者端末を介した担当者からの要求に応じて、御神輿モデル６００の移動ルートとして、バーチャル御神輿イベントに参加する複数の参加者の住居の近くをなるべく多く通るルート、車通りが比較的少ないルート、道幅が比較的広いルート又は過去採用したルートを、要求元の担当者に推奨する。
【0128】
このような構成であれば、担当者は、御神輿モデル６００の移動ルートを、推奨された候補のうちから選択することができるので、容易に移動ルートの設定を行うことができる。
〔対応関係〕
第４の実施の形態において、ステップＳ８００～Ｓ８０４並びにＳ８１２～Ｓ８２４は、発明１０及び１１のルート設定手段に対応している。
〔変形例〕
上記実施の形態において、ビデオカメラ５０及びコントローラ５２の６軸ジャイロセンサによって、イベントに参加しているユーザの動作情報（動作姿勢も含む）を取得する構成としたが、この構成に限らない。例えば、ビデオカメラ５０及びコントローラ５２に代えて、マイクロソフト社のＫｉｎｅｃｔ（登録商標）やＡＳＵＳ社のＸｔｉｏｎ Ｐｒｏ（登録商標）等のモーションキャプチャデバイスを用いる構成としてもよい。また、モーションキャプチャデバイスとコントローラ５２とを組み合わせて用いる構成としてもよい。モーションキャプチャデバイスを用いることで、ユーザのより詳細な動きの情報を取得できるので、ユーザの動きに応じたより細かな御神輿モデル６００の動作及び３Ｄアバター７００の動作を制御することができる。
〔対応関係〕
第４の実施の形態において、ステップＳ８００～Ｓ８０４並びにＳ８１２～Ｓ８２４は、発明１０及び１１のルート設定手段に対応している。
〔変形例〕
上記実施の形態において、ビデオカメラ５０及びコントローラ５２の６軸ジャイロセンサによって、イベントに参加しているユーザの動作情報（動作姿勢も含む）を取得する構成としたが、この構成に限らない。例えば、ビデオカメラ５０及びコントローラ５２に代えて、マイクロソフト社のＫｉｎｅｃｔ（登録商標）やＡＳＵＳ社のＸｔｉｏｎ Ｐｒｏ（登録商標）等のモーションキャプチャデバイスを用いる構成としてもよい。また、モーションキャプチャデバイスとコントローラ５２とを組み合わせて用いる構成としてもよい。モーションキャプチャデバイスを用いることで、ユーザのより詳細な動きの情報を取得できるので、ユーザの動きに応じたより細かな御神輿モデル６００の動作及び３Ｄアバター７００の動作を制御することができる。
【0129】
また、上記実施の形態及びその変形例において、リアルな写真データから生成された各種３Ｄモデルをアニメーション表示させることで実現されるバーチャル御神輿イベントを提供する構成としたが、この構成に限らない。例えば、ヘッドマウントディスプレイシステムを導入して、ＶＲ空間上で実現されるバーチャル御神輿イベントを提供する構成としてもよい。
また、上記実施の形態及びその変形例において、ビデオカメラ５０及びコントローラ５２の６軸ジャイロセンサによって、イベントに参加しているユーザの動作情報を取得し、取得したユーザ動作情報に基づいて、御神輿モデル６００の動作及び３Ｄアバター７００の動作を制御する構成としたが、この構成に限らない。例えば、御神輿モデル６００の上下動に合わせて単純にコントローラ５２を振るだけのモードを設定できるようにして、子供や老人などが気軽に参加できる構成としてもよい。
また、上記実施の形態及びその変形例において、ビデオカメラ５０及びコントローラ５２の６軸ジャイロセンサによって、イベントに参加しているユーザの動作情報を取得し、取得したユーザ動作情報に基づいて、御神輿モデル６００の動作及び３Ｄアバター７００の動作を制御する構成としたが、この構成に限らない。例えば、御神輿モデル６００の上下動に合わせて単純にコントローラ５２を振るだけのモードを設定できるようにして、子供や老人などが気軽に参加できる構成としてもよい。
【0130】
また、上記実施の形態及びその変形例において、複数の担ぎ手の動作タイミングの一致度に基づいて御神輿モデル６００及び３Ｄアバター７００の動作内容並びに鈴の音の出力内容を制御する構成としたが、この構成に限らない。例えば、複数の担ぎ手の掛け声のタイミングの一致度にも基づいて御神輿モデル６００及び３Ｄアバター７００の動作内容並びに鈴の音及び掛け声の出力内容等を制御する構成としてもよい。
また、上記実施の形態及びその変形例において、タイミング修正情報として、上矢印及び下矢印を表示し、上下動のタイミングに合わせて矢印の色を変更する構成を例に挙げて説明したが、この構成に限らない。例えば、矢印の色を変更する構成に加えて又は代えて、上下動のタイミングに合わせて「上（うえ）」「下（した）」と音声出力によって正しいタイミングを知らせる構成としてもよい。また、上下のタイミングだけに限らず、担ぐ姿勢を修正するための情報を表示又は音声出力してもよい。
また、上記第２の実施の形態及びその変形例において、同じグループの担ぎ手全員の動作タイミングが一致した回数に基づいて、順位付けを行う構成としたが、この構成に限らない。例えば、各判定タイミングにおける動作タイミングの一致度を計算し、スタートからゴールまでの一致度の平均値に基づいて順位付けを行う構成とするなど他の構成としてもよい。
また、上記実施の形態及びその変形例において、タイミング修正情報として、上矢印及び下矢印を表示し、上下動のタイミングに合わせて矢印の色を変更する構成を例に挙げて説明したが、この構成に限らない。例えば、矢印の色を変更する構成に加えて又は代えて、上下動のタイミングに合わせて「上（うえ）」「下（した）」と音声出力によって正しいタイミングを知らせる構成としてもよい。また、上下のタイミングだけに限らず、担ぐ姿勢を修正するための情報を表示又は音声出力してもよい。
また、上記第２の実施の形態及びその変形例において、同じグループの担ぎ手全員の動作タイミングが一致した回数に基づいて、順位付けを行う構成としたが、この構成に限らない。例えば、各判定タイミングにおける動作タイミングの一致度を計算し、スタートからゴールまでの一致度の平均値に基づいて順位付けを行う構成とするなど他の構成としてもよい。
【0131】
また、本発明は、バーチャル御神輿イベントに限らずに、複数人で同一の対象物の動作を制御するスポーツなどのイベント（例えば、ボート競技など）にも適用可能である。この場合に以下の構成としてもよい。
（構成１）
ユーザが利用するユーザ端末と通信可能に接続され、複数の参加者が同一の対象物の動作を制御するイベントをバーチャル空間にて実施するバーチャルイベントを前記ユーザに提供するバーチャルイベント提供システムであって、
前記ユーザ端末には、ユーザの動作内容を検出する動作内容検出装置が接続されており、
前記バーチャルイベントの参加者を募集するための募集情報を登録する募集情報記憶手段に登録された前記募集情報に基づいて、前記バーチャルイベントの参加者を募集するイベント参加者募集手段と、
前記バーチャルイベントに対応する対象物及び当該対象物の動作を制御する場所であるイベント会場の写真データを含むイベント用写真データを登録するイベント用写真データ記憶手段に登録された前記イベント用写真データに基づいて、前記対象物の３Ｄモデルである対象物モデル及びイベント会場の３Ｄモデルであるイベント会場モデルを含むイベント用モデルを生成するイベント用モデル生成手段と、
前記バーチャルイベントの参加者の写真データである参加者写真データを登録する参加者写真データ記憶手段に登録された前記参加者写真データに基づいて、前記参加者の３Ｄアバターを生成する３Ｄアバター生成手段と、
前記対象物モデルに割り当てられたユーザである割り当てユーザの前記ユーザ端末から送信された、前記動作内容検出装置の検出情報に基づいて、当該対象物モデルの動作及び前記割り当てユーザに対応する３Ｄアバターの動作を制御するモデル動作制御手段と、
前記イベント会場の表示情報並びに前記対象物モデル動作制御手段で動作が制御される前記対象物モデル及び前記３Ｄアバターの表示情報を含むバーチャルイベントの提供に必要なイベント提供情報を、前記ユーザ端末に送信するイベント提供情報送信手段と、を備えることを特徴とするバーチャルイベント提供システム。
（構成１）
ユーザが利用するユーザ端末と通信可能に接続され、複数の参加者が同一の対象物の動作を制御するイベントをバーチャル空間にて実施するバーチャルイベントを前記ユーザに提供するバーチャルイベント提供システムであって、
前記ユーザ端末には、ユーザの動作内容を検出する動作内容検出装置が接続されており、
前記バーチャルイベントの参加者を募集するための募集情報を登録する募集情報記憶手段に登録された前記募集情報に基づいて、前記バーチャルイベントの参加者を募集するイベント参加者募集手段と、
前記バーチャルイベントに対応する対象物及び当該対象物の動作を制御する場所であるイベント会場の写真データを含むイベント用写真データを登録するイベント用写真データ記憶手段に登録された前記イベント用写真データに基づいて、前記対象物の３Ｄモデルである対象物モデル及びイベント会場の３Ｄモデルであるイベント会場モデルを含むイベント用モデルを生成するイベント用モデル生成手段と、
前記バーチャルイベントの参加者の写真データである参加者写真データを登録する参加者写真データ記憶手段に登録された前記参加者写真データに基づいて、前記参加者の３Ｄアバターを生成する３Ｄアバター生成手段と、
前記対象物モデルに割り当てられたユーザである割り当てユーザの前記ユーザ端末から送信された、前記動作内容検出装置の検出情報に基づいて、当該対象物モデルの動作及び前記割り当てユーザに対応する３Ｄアバターの動作を制御するモデル動作制御手段と、
前記イベント会場の表示情報並びに前記対象物モデル動作制御手段で動作が制御される前記対象物モデル及び前記３Ｄアバターの表示情報を含むバーチャルイベントの提供に必要なイベント提供情報を、前記ユーザ端末に送信するイベント提供情報送信手段と、を備えることを特徴とするバーチャルイベント提供システム。
【0132】
また、上記第３の実施の形態及びその変形例において、受信した回覧情報にイベントへの参加の可否を示す情報を付加する際に、単なる参加の可否のみに限らず、参加の条件を設定してもよい。例えば、メンバーが５人以上集まる場合は参加、女性が３人以上集まる場合は参加等の条件を設定し、代表ユーザは、戻ってきた回覧情報から設定した条件に合致する場合に参加を確定する。
また、上記実施の形態及びその変形例においては、インターネット１９９からなるネットワークシステムに適用した場合について説明したが、これに限らず、例えば、インターネット１９９と同一方式により通信を行ういわゆるイントラネットに適用してもよい。もちろん、インターネット１９９と同一方式により通信を行うネットワークに限らず、任意の通信方式のネットワークに適用することができる。
また、上記実施の形態及びその変形例においては、インターネット１９９からなるネットワークシステムに適用した場合について説明したが、これに限らず、例えば、インターネット１９９と同一方式により通信を行ういわゆるイントラネットに適用してもよい。もちろん、インターネット１９９と同一方式により通信を行うネットワークに限らず、任意の通信方式のネットワークに適用することができる。
【0133】
また、上記実施の形態及びその変形例において、図５乃至図９、図１４乃至図１５、図１７乃至図２０のフローチャートに示す処理を実行するにあたってはいずれも、ＲＯＭに予め格納されているプログラムを実行する場合について説明したが、これに限らず、これらの手順を示したプログラムが記憶された記憶媒体から、そのプログラムをＲＡＭに読み込んで実行するようにしてもよい。
【符号の説明】
【0134】
１００…バーチャル御神輿イベント提供サーバ、 ２００…ユーザ端末、 ３００…事務局端末、 ３０…ＣＰＵ、 ３２…ＲＯＭ、 ３４…ＲＡＭ、 ３８…Ｉ／Ｆ、 ３９…バス、 ４０…入力装置、 ４２…記憶装置、 ４４…表示装置、 ５０…ビデオカメラ、 ５２…コントローラ、 １９９…インターネット、 ４００…ユーザ情報管理テーブル、 ４１０…募集情報テーブル、 ４１５…イベント参加者管理テーブル、 ４２０…イベント用写真データ管理テーブル、 ４３０…イベント用モデル管理テーブル、 ４４０…参加者写真データ管理テーブル、 ４５０…アバター管理テーブル、 ５００…撮像範囲、 ６００…御神輿モデル、 ６１０…蕨手、 ６２０…担ぎ棒、 ６３０…鈴、 ７００…３Ｄアバター
【要約】
【課題】バーチャル御神輿イベントにおいて、御神輿モデルの担ぎ手に割り当てられたユーザの実際の動作を御神輿モデルの動作に反映させることができるバーチャル御神輿イベント提供システムを提供する。
【解決手段】バーチャル御神輿イベント提供サーバ１００は、御神輿モデル６００の担ぎ手に割り当てられた担ぎ手ユーザの利用するユーザ端末２００から送信された、ビデオカメラ５０で撮像されたユーザの撮像画像データ及びユーザの動作に応じたコントローラ５２の６軸ジャイロセンサのセンサ検出値に基づいて、御神輿モデル６００の動作及び担ぎ手ユーザに対応する３Ｄアバター７００の動作を制御する。
【選択図】 図８
【解決手段】バーチャル御神輿イベント提供サーバ１００は、御神輿モデル６００の担ぎ手に割り当てられた担ぎ手ユーザの利用するユーザ端末２００から送信された、ビデオカメラ５０で撮像されたユーザの撮像画像データ及びユーザの動作に応じたコントローラ５２の６軸ジャイロセンサのセンサ検出値に基づいて、御神輿モデル６００の動作及び担ぎ手ユーザに対応する３Ｄアバター７００の動作を制御する。
【選択図】 図８
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】