ホーム > 特許ランキング > 株式会社ＮＦＴ ＪＡＰＡＮ
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024101297
(43)【公開日】2024-07-29
(54)【発明の名称】プログラム、情報処理方法及び情報処理装置
(51)【国際特許分類】
A63F 13/79 20140101AFI20240722BHJP
A63F 13/58 20140101ALI20240722BHJP
A63F 13/798 20140101ALI20240722BHJP
A63F 13/65 20140101ALI20240722BHJP
G10L 25/51 20130101ALI20240722BHJP
A63F 13/814 20140101ALI20240722BHJP
A63F 13/424 20140101ALI20240722BHJP
【ＦＩ】
A63F13/79
A63F13/58
A63F13/798
A63F13/65
G10L25/51
A63F13/814
A63F13/424
【審査請求】未請求
【請求項の数】12
【出願形態】ＯＬ
(21)【出願番号】P 2023005198
(22)【出願日】2023-01-17
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＪＡＶＡＳＣＲＩＰＴ
(71)【出願人】
【識別番号】523019734
【氏名又は名称】株式会社ＮＦＴ ＪＡＰＡＮ
(74)【代理人】
【識別番号】100114557
【弁理士】
【氏名又は名称】河野 英仁
(74)【代理人】
【識別番号】100078868
【弁理士】
【氏名又は名称】河野 登夫
(72)【発明者】
【氏名】川本 学
(72)【発明者】
【氏名】笹嶋 邦則
(57)【要約】
【課題】仮想的なアイドルのアイドルＮＦＴを、当該アイドルを割り当てたユーザに付与することが可能なプログラム等を提供すること。
【解決手段】一つの側面に係るプログラムは、学習モデルにより生成されたアイドルをユーザに割り当て、前記アイドルの属性をブロックチェーンシステム２に記憶し、前記アイドルのアイドルＮＦＴを前記ブロックチェーンシステム２上で前記ユーザに付与する処理をコンピュータ１に実行させる。これにより、仮想的なアイドルのアイドルＮＦＴを、当該アイドルを割り当てたユーザに付与することが可能となる。
【選択図】図１
【解決手段】一つの側面に係るプログラムは、学習モデルにより生成されたアイドルをユーザに割り当て、前記アイドルの属性をブロックチェーンシステム２に記憶し、前記アイドルのアイドルＮＦＴを前記ブロックチェーンシステム２上で前記ユーザに付与する処理をコンピュータ１に実行させる。これにより、仮想的なアイドルのアイドルＮＦＴを、当該アイドルを割り当てたユーザに付与することが可能となる。
【選択図】図１
【特許請求の範囲】
【請求項1】
学習モデルにより生成されたアイドルをユーザに割り当て、
前記アイドルの属性をブロックチェーンシステムに記憶し、
前記アイドルのアイドルＮＦＴ（非代替性トークン；Non-Fungible Token）を前記ブロックチェーンシステム上で前記ユーザに付与する
処理をコンピュータに実行させるプログラム。
前記アイドルの属性をブロックチェーンシステムに記憶し、
前記アイドルのアイドルＮＦＴ（非代替性トークン；Non-Fungible Token）を前記ブロックチェーンシステム上で前記ユーザに付与する
処理をコンピュータに実行させるプログラム。
【請求項2】
前記ユーザの音声の入力を受け付け、
受け付けた音声に基づき、前記学習モデルにより生成されたアイドルを前記ユーザに割り当てる
請求項１に記載のプログラム。
受け付けた音声に基づき、前記学習モデルにより生成されたアイドルを前記ユーザに割り当てる
請求項１に記載のプログラム。
【請求項3】
前記ユーザの音声に基づくパラメータを特定し、
特定したパラメータを、割り当てた前記アイドルの属性の一つとして記憶部に記憶する
請求項２に記載のプログラム。
特定したパラメータを、割り当てた前記アイドルの属性の一つとして記憶部に記憶する
請求項２に記載のプログラム。
【請求項4】
前記アイドルのライブを含むミッションのクリアにより前記属性を更新する
請求項１または２に記載のプログラム。
請求項１または２に記載のプログラム。
【請求項5】
前記属性は、前記アイドルの体力及び歌唱可能な楽曲を含み、
前記体力が所定範囲内である場合に、所定場所での該アイドルの歌唱を行い、
歌唱に伴い所定条件が成立した場合に、前記アイドルのレベルをアップする
請求項１または２に記載のプログラム。
前記体力が所定範囲内である場合に、所定場所での該アイドルの歌唱を行い、
歌唱に伴い所定条件が成立した場合に、前記アイドルのレベルをアップする
請求項１または２に記載のプログラム。
【請求項6】
前記ユーザに割り当てたアイドルと、前記ユーザとは異なる第２ユーザに割り当てたアイドルからなるアイドル群とを含むアイドルユニットを結成する
請求項１または２に記載のプログラム。
請求項１または２に記載のプログラム。
【請求項7】
前記アイドルユニットに、歌唱可能な楽曲を含む属性が付与されており、
前記アイドルユニットの全員の体力が所定範囲内である場合に、所定場所での前記アイドルユニットの歌唱を行い、
歌唱に伴い所定条件が成立した場合に、前記アイドルユニットのレベルをアップする
請求項６に記載のプログラム。
前記アイドルユニットの全員の体力が所定範囲内である場合に、所定場所での前記アイドルユニットの歌唱を行い、
歌唱に伴い所定条件が成立した場合に、前記アイドルユニットのレベルをアップする
請求項６に記載のプログラム。
【請求項8】
所定場所でのアイドルユニット同士のライブ対戦を実行し、
前記ライブ対戦における各アイドルユニットの総合スコアに基づき、前記ライブ対戦で勝利したアイドルユニットを決定する
請求項６に記載のプログラム。
前記ライブ対戦における各アイドルユニットの総合スコアに基づき、前記ライブ対戦で勝利したアイドルユニットを決定する
請求項６に記載のプログラム。
【請求項9】
前記アイドルユニットのフォーメーション及び属性、並びに、前記アイドルユニットに含まれる各アイドルの属性に基づき、前記アイドルユニットの総合レベルを判定するための前記総合スコアを変動させる
請求項８に記載のプログラム。
請求項８に記載のプログラム。
【請求項10】
前記属性は、前記アイドルの出身地を含み、
前記アイドルユニットに含まれる各アイドルの出身地と、前記ライブ対戦を開催するライブ会場の客の出身地とに基づき、前記アイドルユニットの総合レベルを判定するための前記総合スコアを変動させる
請求項９に記載のプログラム。
前記アイドルユニットに含まれる各アイドルの出身地と、前記ライブ対戦を開催するライブ会場の客の出身地とに基づき、前記アイドルユニットの総合レベルを判定するための前記総合スコアを変動させる
請求項９に記載のプログラム。
【請求項11】
学習モデルにより生成されたアイドルをユーザに割り当て、
前記アイドルの属性をブロックチェーンシステムに記憶し、
前記アイドルのアイドルＮＦＴを前記ブロックチェーンシステム上で前記ユーザに付与する
情報処理方法。
前記アイドルの属性をブロックチェーンシステムに記憶し、
前記アイドルのアイドルＮＦＴを前記ブロックチェーンシステム上で前記ユーザに付与する
情報処理方法。
【請求項12】
制御部を備える情報処理装置であって、
前記制御部は、
学習モデルにより生成されたアイドルをユーザに割り当て、
前記アイドルの属性をブロックチェーンシステムに記憶し、
前記アイドルのアイドルＮＦＴを前記ブロックチェーンシステム上で前記ユーザに付与する
情報処理装置。
前記制御部は、
学習モデルにより生成されたアイドルをユーザに割り当て、
前記アイドルの属性をブロックチェーンシステムに記憶し、
前記アイドルのアイドルＮＦＴを前記ブロックチェーンシステム上で前記ユーザに付与する
情報処理装置。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、プログラム、情報処理方法及び情報処理装置に関する。
【背景技術】
【0002】
近年、仮想的なアイドルに関する技術の開発が盛んに進められている。特許文献１には、顔素材ライブラリからターゲットオブジェクトの特徴情報にマッチングすることにより確定されたターゲット仮想顔と、動作ビデオライブラリから特徴情報にマッチングすることにより確定されたターゲット動作ビデオとにおける顔画像を融合し、ターゲットオブジェクトに対応する仮想的なアイドルを生成する仮想アイドルの生成方法が開示されている。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】特開２０２２－１８５０９６号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
しかしながら、特許文献１に係る発明は、生成された仮想的なアイドルのアイドルＮＦＴ（非代替性トークン；Non-Fungible Token）を、当該アイドルを割り当てたユーザに付与することができないという問題がある。
【0005】
一つの側面では、仮想的なアイドルのアイドルＮＦＴを、当該アイドルを割り当てたユーザに付与することが可能なプログラム等を提供することを目的とする。
【課題を解決するための手段】
【0006】
一つの側面に係るプログラムは、学習モデルにより生成されたアイドルをユーザに割り当て、前記アイドルの属性をブロックチェーンシステムに記憶し、前記アイドルのアイドルＮＦＴを前記ブロックチェーンシステム上で前記ユーザに付与する処理をコンピュータに実行させる。
【発明の効果】
【0007】
一つの側面では、仮想的なアイドルのアイドルＮＦＴを、当該アイドルを割り当てたユーザに付与することが可能となる。
【図面の簡単な説明】
【0008】
【図1】アイドルＮＦＴシステムの概要を示す説明図である。
【図2】サーバの構成例を示すブロック図である。
【図3】ユーザＤＢ及びアイドルＤＢのレコードレイアウトの一例を示す説明図である。
【図4】割当ＤＢ及びアイドルＮＦＴＤＢのレコードレイアウトの一例を示す説明図である。
【図5】ブロックチェーンのノードの構成例を示すブロック図である。
【図6】ユーザ端末の構成例を示すブロック図である。
【図7】アイドルＮＦＴをユーザに付与する処理を説明する説明図である。
【図8】ユーザにアイドルを割り当てる画面の一例を示す説明図である。
【図9】アイドルデータを記憶する際の処理手順を示すフローチャートである。
【図10】ユーザにアイドルを割り当てる際の処理手順を示すフローチャートである。
【図11】ユーザにアイドルＮＦＴを付与する際の処理手順を示すフローチャートである。
【図12】実施形態２におけるサーバの構成例を示すブロック図である。
【図13】ミッションＤＢのレコードレイアウトの一例を示す説明図である。
【図14】ミッションを行う画面の一例を示す説明図である。
【図15】アイドルの属性を更新する際の処理手順を示すフローチャートである。
【図16】アイドルの属性を更新する際の処理手順を示すフローチャートである。
【図17】実施形態３におけるサーバの構成例を示すブロック図である。
【図18】アイドルユニットＤＢのレコードレイアウトの一例を示す説明図である。
【図19】実施形態３におけるアイドルＤＢ及び割当ＤＢのレコードレイアウトの一例を示す説明図である。
【図20】アイドルユニットの属性を更新する際の処理手順を示すフローチャートである。
【図21】アイドルユニットの属性を更新する際の処理手順を示すフローチャートである。
【図22】実施形態４におけるサーバの構成例を示すブロック図である。
【図23】対戦ＤＢ及びスコアマスタＤＢのレコードレイアウトの一例を示す説明図である。
【図24】ライブ対戦を実行する画面の一例を示す説明図である。
【図25】優勝アイドルユニットを決定する際の処理手順を示すフローチャートである。
【図26】総合スコアを変動させる処理のサブルーチンの処理手順を示すフローチャートである。
【図27】出身地に基づく総合スコアを変動させる処理のサブルーチンの処理手順を示すフローチャートである。
【図28】実施形態５におけるミッションＤＢのレコードレイアウトの一例を示す説明図である。
【発明を実施するための形態】
【0009】
以下、本発明をその実施の形態を示す図面に基づいて詳述する。
【0010】
（実施形態１）
実施形態１は、学習モデルにより生成された仮想的なアイドル（以下、アイドルと読み替える）をユーザに割り当て、当該アイドルのアイドルＮＦＴをブロックチェーンシステム上でユーザに付与する形態に関する。
実施形態１は、学習モデルにより生成された仮想的なアイドル（以下、アイドルと読み替える）をユーザに割り当て、当該アイドルのアイドルＮＦＴをブロックチェーンシステム上でユーザに付与する形態に関する。
【0011】
ＮＦＴは、鑑定書または所有証明書付きのデジタルデータであり、仮想通貨と同様にデータ管理にブロックチェーン技術が用いられ、改ざん・偽造ができない仕組みである。学習モデルにより生成されたアイドルをユーザに割り当て、当該アイドルに対応するアイドルＮＦＴをブロックチェーンシステム上で当該ユーザに発行することができる。
【0012】
図１は、アイドルＮＦＴシステムの概要を示す説明図である。本実施形態のシステムは、情報処理装置１、ブロックチェーンシステム２及び情報処理端末３を含み、各装置はインターネット等のネットワークＮを介して情報の送受信を行う。
【0013】
情報処理装置１は、種々の情報に対する処理、記憶及び送受信を行う情報処理装置である。情報処理装置１は、例えばサーバ装置、パーソナルコンピュータまたは汎用のタブレットＰＣ（パソコン）等である。本実施形態において情報処理装置１はサーバ装置であるものとし、以下では簡潔のためサーバ１と読み替える。
【0014】
ブロックチェーンシステム２は、分散型台帳技術又は分散型ネットワークである。ブロックチェーンシステム２は、コンセンサス処理を実行する複数のノード２１により構成される。ノード２１の各々は、当該コンセンサス処理の実行を通じて、ブロックチェーンデータのコピーを保持する。ブロックチェーンシステム２は、ブロックと呼ばれるデータの単位を一定時間ごとに生成し、鎖のように連結していくことによりデータを保管する。
【0015】
ブロックチェーンシステム２は、ピアツーピア（Peer to Peer）ネットワークと分散型タイムスタンプサーバの使用により自律的に管理される。鎖状に保存しているため、ブロック内のデータを一度記憶した場合、該データを遡及的に変更することが難しい。なお、ブロックチェーンシステム２は、パブリック型、プライベート型、コンソーシアム型のいずれであっても良い。データの単位はブロックではなく個々のトランザクションであっても良い。また、データの保存は鎖状以外にも有向非巡回グラフ等の保存形式であっても良い。以下では簡潔のため、ブロックチェーンシステム２をブロックチェーン２と読み替える。
【0016】
情報処理端末３は、ユーザの音声の入力受付、及び当該ユーザに割り当てたアイドルの表示等を行う端末装置である。情報処理端末３は、例えばスマートフォン、携帯電話、アップルウォッチ（Apple Watch：登録商標）等のウェアラブルデバイス、タブレット、またはパーソナルコンピュータ端末等の情報処理機器である。以下では簡潔のため、情報処理端末３をユーザ端末３と読み替える。
【0017】
本実施形態に係るサーバ１は、ユーザの音声の入力を受け付ける。サーバ１は、受け付けた音声に基づき、学習モデルにより生成されたアイドルを当該ユーザに割り当てる。サーバ１は、当該アイドルの属性をブロックチェーン２に記憶する。サーバ１は、当該アイドルのアイドルＮＦＴをブロックチェーン２上で当該ユーザに付与する。
【0018】
図２は、サーバ１の構成例を示すブロック図である。サーバ１は、制御部１１、記憶部１２、通信部１３、読取部１４及び大容量記憶部１５を含む。各構成はバスＢで接続されている。
【0019】
制御部１１は、ＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro-Processing Unit）、ＧＰＵ（Graphics Processing Unit）、ＦＰＧＡ（Field Programmable Gate Array）、ＤＳＰ（Digital Signal Processor）、または量子プロセッサ等の演算処理装置を含む。制御部１１は、記憶部１２に記憶された制御プログラム１Ｐ（プログラム製品）を読み出して実行することにより、サーバ１に係る種々の情報処理または制御処理等を行う。
【0020】
また、制御プログラム１Ｐには、例えばイーサリアムのGeth（Go-Ethereum）等のスマートコントラクトの生成・実行、仮想通貨の送金、アカウントの作成、またはマイニング等の処理を実行するプログラムが含まれる。制御部１１は、ハッシュ値算出部１１ａ及び電子署名作成部１１ｂを含む。ハッシュ値算出部１１ａは、暗号学的ハッシュ関数を用いて各種情報のハッシュ値を算出する処理を行う。電子署名作成部１１ｂは、偽造又は改ざんを防止するため、公開鍵暗号方式に基づくデジタル認証用の署名を生成する。
【0021】
なお、制御プログラム１Ｐは、単一のコンピュータ上で、または１つのサイトにおいて配置されるか、もしくは複数のサイトにわたって分散され、通信ネットワークによって相互接続された複数のコンピュータ上で実行されるように展開することができる。なお、図２では制御部１１を単一のプロセッサであるものとして説明するが、マルチプロセッサであっても良い。
【0022】
記憶部１２はＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）等のメモリ素子を含み、制御部１１が処理を実行するために必要な制御プログラム１Ｐ又はデータ等を記憶している。また、記憶部１２は、制御部１１が演算処理を実行するために必要なデータ等を一時的に記憶する。通信部１３は通信に関する処理を行うための通信モジュールであり、ネットワークＮを介して、ブロックチェーン２のノード２１またはユーザ端末３等との間で情報の送受信を行う。
【0023】
読取部１４は、ＣＤ（Compact Disc）－ＲＯＭ又はＤＶＤ（Digital Versatile Disc）－ＲＯＭを含む可搬型記憶媒体１ａを読み取る。制御部１１が読取部１４を介して、制御プログラム１Ｐを可搬型記憶媒体１ａより読み取り、大容量記憶部１５に記憶しても良い。また、ネットワークＮ等を介して他のコンピュータから制御部１１が制御プログラム１Ｐをダウンロードし、大容量記憶部１５に記憶しても良い。さらにまた、半導体メモリ１ｂから、制御部１１が制御プログラム１Ｐを読み込んでも良い。
【0024】
大容量記憶部１５は、例えばＨＤＤ（Hard disk drive：ハードディスク）、またはＳＳＤ（Solid State Drive：ソリッドステートドライブ）等の記録媒体を備える。大容量記憶部１５は、ユーザＤＢ（database）１５１、アイドルＤＢ１５２、割当ＤＢ１５３及びアイドルＮＦＴＤＢ１５４を含む。
【0025】
ユーザＤＢ１５１は、ユーザに関する情報を記憶している。アイドルＤＢ１５２は、学習モデルにより生成されたアイドルに関する情報を記憶している。割当ＤＢ１５３は、アイドルをユーザに割り当てた情報を記憶している。アイドルＮＦＴＤＢ１５４は、アイドルのアイドルＮＦＴに関する情報を記憶している。
【0026】
なお、本実施形態において記憶部１２及び大容量記憶部１５は一体の記憶装置として構成されていても良い。また、大容量記憶部１５は複数の記憶装置により構成されていても良い。更にまた、大容量記憶部１５はサーバ１に接続された外部記憶装置であっても良い。
【0027】
サーバ１は、種々の情報処理及び制御処理等をコンピュータ単体で実行しても良いし、複数のコンピュータで分散して実行しても良い。また、サーバ１は、１台のサーバ内に設けられた複数の仮想マシンによって実現されても良いし、クラウドサーバを用いて実現されても良い。
【0028】
図３は、ユーザＤＢ１５１及びアイドルＤＢ１５２のレコードレイアウトの一例を示す説明図である。
ユーザＤＢ１５１は、ユーザＩＤ列及び音声データ列を含む。ユーザＩＤ列は、各ユーザを識別するために、一意に特定されるユーザのＩＤを記憶している。音声データは、ユーザの音声データを記憶している。
ユーザＤＢ１５１は、ユーザＩＤ列及び音声データ列を含む。ユーザＩＤ列は、各ユーザを識別するために、一意に特定されるユーザのＩＤを記憶している。音声データは、ユーザの音声データを記憶している。
【0029】
アイドルＤＢ１５２は、学習モデルにより生成された各アイドルのデータを記憶している。なお、学習モデルに関しては後述する。アイドルＤＢ１５２は、アイドルＩＤ列、名前列、アイドルデータ列、属性列及び音声パラメータ基準値列を含む。アイドルＩＤ列は、各アイドルを識別するために、一意に特定されるアイドルのＩＤを記憶している。名前列は、アイドルの名前を記憶している。アイドルデータ列は、学習モデルにより生成されたアイドルデータ（例えば、アイドルの画像データ）を記憶している。
【0030】
属性列は、上述した学習モデルにより生成された各アイドルに付与された属性を記憶している。属性は、体力、楽曲、ダンス及び美しさ等を含む。なお、アイドルへの属性付与処理に関しては後述する。
【0031】
属性列は、体力列、楽曲列、ダンス列及び美しさ列を含む。体力列は、アイドルの体力を示す体力値を記憶している。体力値は、例えば、１～１２の数値で、数値が大きい程体力が強いことを示すように予め定められている。なお、体力値の段階数は、１２に限られない。楽曲列は、アイドルが歌唱可能な楽曲、または歌唱動画等を記憶している。
【0032】
ダンス列は、アイドルが踊り可能なダンスを記憶している。美しさ列は、アイドルの美しさを示すレベルを記憶している。美しさは、例えば、１～１０の数値で、数値が大きい程美しさの評価が高いことを示すように予め定められている。なお、アイドルの属性は、上述した体力、楽曲、ダンス及び美しさに限るものではない。例えば属性は、後述するアイドルの出身地等を含んでも良い。
【0033】
音声パラメータ基準値列は、音声に基づくパラメータの基準値（範囲等）を記憶している。なお、パラメータに関しては後述する。
【0034】
図４は、割当ＤＢ１５３及びアイドルＮＦＴＤＢ１５４のレコードレイアウトの一例を示す説明図である。
【0035】
割当ＤＢ１５３は、割当ＩＤ列、ユーザＩＤ列、アイドルＩＤ列、レベル列及び属性列を含む。割当ＩＤ列は、ユーザにアイドルを割り当てた割当データを識別するために、一意に特定される割当データのＩＤを記憶している。ユーザＩＤ列は、ユーザを特定するユーザＩＤを記憶している。アイドルＩＤ列は、アイドルを特定するアイドルＩＤを記憶している。
【0036】
レベル列は、アイドルのレベルを記憶している。例えば、アイドルの体力、歌唱可能な楽曲、踊り可能なダンスまたは美しさ等の属性に応じて、複数のレベルを設けても良い。例えば、レベル１～５で、レベルが高いほどアイドルの評価または能力が高いことを示すように予め定められている。
【0037】
属性列は、体力列、楽曲列、ダンス列、美しさ列及び音声パラメータ列を含む。体力列、楽曲列、ダンス列及び美しさ列は、図３と同様であるため、説明を省略する。音声パラメータ列は、ユーザの音声に基づいて特定されたパラメータを記憶している。
【0038】
アイドルＮＦＴＤＢ１５４は、アイドルＮＦＴに関する情報を記憶している。例えば、ブロックチェーン２上で、Ｅｔｈｅｒｅｕｍの一つのスマートコントラクト規格であるＥＲＣ７２１を利用し、鑑定書等のようにその「真正性」または「価値」を証明することができるアイドルＮＦＴを発行しても良い。ＥＲＣ７２１が利用された場合、アイドルＮＦＴは、トークン（Token）ＩＤ、ユーザのウォレットアドレス（所有者アドレス）及びトークンＵＲＩ（Uniform Resource Identifier）等で構成される。
【0039】
アイドルＮＦＴの発行時に、当該アイドルＮＦＴのトークンＩＤ、ウォレットアドレス及びトークンＵＲＩ等はブロックチェーン２上で記憶される。トークンＵＲＩは、アイドルＮＦＴに対するメタデータの場所を示す属性である。メタデータの場所は、例えばメタデータ（画像または動画等）のＵＲＬ（Uniform Resource Locator）等である。なお、メタデータそのものは、例えばＪＳＯＮ（JavaScript Object Notation）形式で外部のデータベース装置に記憶されても良い。
【0040】
なお、アイドルＮＦＴの発行に関しては、ＥＲＣ７２１に限定されず、例えば、ＥＲＣ１１５５またはＥＲＣ４９０７等を利用しても良い。
【0041】
アイドルＮＦＴＤＢ１５４は、ユーザＩＤ列、アイドルＩＤ列及びアイドルＮＦＴ列を含む。ユーザＩＤ列は、ユーザを特定するユーザＩＤを記憶している。アイドルＩＤ列は、アイドルを特定するアイドルＩＤを記憶している。
【0042】
アイドルＮＦＴ列は、トークンＩＤ列、ウォレットアドレス列及びトークンＵＲＩ列を含む。トークンＩＤ列は、アイドルＮＦＴのトークンＩＤを記憶している。ウォレットアドレス列は、アイドルＮＦＴを保有するユーザのウォレットアドレス（オーナーＩＤ；保有者ＩＤ）を記憶している。トークンＵＲＩ列は、アイドルＮＦＴのトークンＵＲＩを記憶している。
【0043】
なお、上述した各ＤＢの記憶形態は一例であり、データ間の関係が維持されていれば、他の記憶形態であっても良い。
【0044】
図５は、ブロックチェーン２のノード２１の構成例を示すブロック図である。ブロックチェーン２のノード２１は、制御部２１１、記憶部２１２、通信部２１３、受付部２１４、出力部２１５、ブロック生成部２１６、ブロック検証部２１７及びブロック共有部２１８を含む。各構成はバスＢで接続されている。
【0045】
制御部２１１は、他ノード２１（端末）の制御部２１１と自律分散的に協調して、最新のブロックチェーン（台帳：ブロックチェーンデータのコピー）を記憶部２１２に保持する。記憶部２１２には、分散型のネットワークへブロードキャストされたトランザクションが含まれたブロックチェーン（台帳）、及びブロック内の情報の検証処理に必要となる情報等が記憶される。
【0046】
通信部２１３は、通信に関する処理を行うための通信モジュールである。受付部２１４は、外部ノード２１から、ブロックチェーン２が管理するブロックチェーン２である分散型のネットワークに記録する情報を受け付ける。出力部２１５は、外部ノード２１からの要求に応じて、自身が保持するブロックチェーン２の情報を出力する。
【0047】
ブロック生成部２１６は、受付部２１４が受け付けた情報を基に、ブロックチェーン２に追加するブロックを生成する。ブロック生成部２１６は、前ブロックに基づく情報と受付部２１４が受け付けた情報とを含むブロックを生成する。また、ブロック生成部２１６は、自身が生成したブロックまたは後述するブロック共有部２１８を介して他のノード２１が生成したブロックに対して、所定のコンセンサス処理として、例えば、ノンスを探索する処理または署名を付与する処理を行った上で、自身が管理するブロックチェーン２にブロックを追加する。なお、ブロック生成部２１６が生成したブロックに対して、複数のノード２１が所定のコンセンサス処理を行って得られたものが、最終的にブロックチェーン２に追加されるブロックとなる。
【0048】
ブロック検証部２１７は、自身が保持するブロックチェーン２にブロックを追加する際に、該ブロック内の情報の検証を行う。通常、追加対象とされるブロックは、自ノード２１を含むノード２１群において最も早く規則が満たされたブロックであるが、悪意のあるノード２１が含まれていた場合等を考慮して、実際に規則が満たされているか等を検証しても良い。
【0049】
ブロック共有部２１８は、ブロックチェーン２に属するノード２１間で情報交換を行う。ブロック共有部２１８は、より具体的には、受付部２１４が受け付けた情報、ブロック生成部２１６が生成したブロック、及び他のノード２１から受け付けたブロック等を、適宜他のノード２１に送信する。これにより、可能な限り全てのノード２１でこれらの情報および最新のブロックチェーン２を共有する。
【0050】
なお、図５の構成はあくまで一例であって、ブロックチェーンのノード２１は、改ざんが困難なブロックチェーン２を複数のノードが共有して管理するための所定のコンセンサス処理を実行可能であり、外部ノードからの要求に応じて分散型のネットワークへの情報追加、及び分散型のネットワークに記録された情報の参照が可能なノードであれば、具体的な構成は問わない。
【0051】
なお、サーバ１は、ブロックチェーン２のノード２１であっても良い。
【0052】
図６は、ユーザ端末３の構成例を示すブロック図である。ユーザ端末３は、制御部３１、記憶部３２、通信部３３、入力部３４、表示部３５、マイク３６及びスピーカ３７を含む。各構成はバスＢで接続されている。
【0053】
制御部３１はＣＰＵまたはＭＰＵ等の演算処理装置を含み、記憶部３２に記憶された制御プログラム３Ｐ（プログラム製品）を読み出して実行することにより、ユーザ端末３に係る種々の情報処理、または制御処理等を行う。また、制御部３１は、ハッシュ値算出部３１ａ及び電子署名作成部３１ｂを含む。ハッシュ値算出部３１ａは、暗号学的ハッシュ関数を用いて、ウォレットアドレス等を算出する処理を行う。電子署名作成部３１ｂは、偽造又は改ざんを防止するため、公開鍵暗号方式に基づくデジタル認証用の署名を生成する。
【0054】
また制御プログラム３Ｐには、例えばイーサリアムのGeth等のスマートコントラクトの生成・実行、仮想通貨の送金、アカウントの作成、またはマイニング等の処理を実行するプログラムが含まれる。なお、図６では制御部３１を単一のプロセッサであるものとして説明するが、マルチプロセッサであっても良い。
【0055】
記憶部３２はＲＡＭ、ＲＯＭ等のメモリ素子を含み、制御部３１が処理を実行するために必要な制御プログラム３Ｐ又はデータ等を記憶している。また、記憶部３２は、制御部３１が演算処理を実行するために必要なデータ等を一時的に記憶する。
【0056】
通信部３３は通信に関する処理を行うための通信モジュールであり、ネットワークＮを介して、サーバ１等と情報の送受信を行う。入力部３４は、キーボード、マウスまたは表示部３５と一体化したタッチパネルでも良い。表示部３５は、液晶ディスプレイ又は有機ＥＬ（electroluminescence）ディスプレイ等であり、制御部３１の指示に従い各種情報を表示する。
【0057】
マイク３６は、音を電気信号に変換する装置である。スピーカ３７は、電気信号を音に変換する装置である。なお、マイク３６及びスピーカ３７は、Ｂｌｕｅｔｏｏｔｈ（登録商標）のような短距離無線通信方式によりユーザ端末３に接続されたヘッドセットであっても良い。
【0058】
図７は、アイドルＮＦＴをユーザに付与する処理を説明する説明図である。ユーザ端末３は、ユーザの音声の入力を受け付ける。ユーザ端末３は、ユーザＩＤに対応付けて、受け付けたユーザの音声データをサーバ１に送信する。サーバ１は、ユーザ端末３から送信されたユーザＩＤ及び音声データを受信する。サーバ１は、ユーザＩＤ対応付けて、受信した音声データをユーザＤＢ１５１に記憶する。
【0059】
サーバ１は、受信した音色データから音声のパラメータ（特徴量）を特定する。音声のパラメータは、音声のピッチ、話速（発話速度またはテンポ）及び抑揚（イントネーション）のうち少なくとも１つであっても良い。発話内容は、例えば、予め設定した定形文をユーザに発話させた音声データ（定型音声データ）を取得しても良く、または、自由にユーザに発話させた音声データ（自由音声データ）を取得しても良い。定型文は、例えば「アイドル、こんにちは！」等であっても良い。なお、音声のパラメータが取得できるものであれば、発話内容または発話の長さは、特に制限されない。なお、定型音声データ及び自由音声データの両方は取得されても良い。
【0060】
ピッチは、音声の高低を示す音高である。ピッチ周波数の取得処理に関しては、例えばサーバ１は、音声データ（音声信号）を周波数スペクトルに変換し、変換した周波数スペクトルを周波数軸上でずらしながら自己相関波形を求める。サーバ１は、求めた自己相関波形における複数の極値の出現順番と複数の極値の出現位置を示すずらし周波数量である出現周波数との分布を回帰分析し、回帰直線の傾きに基づいてピッチ周波数を求める。
【0061】
話速は、例えば所定時間内に話者が発した単語数により表される。話速は、感情（例えば、怒り）の表現度合いによって変化される。サーバ１は、例えば音声信号のスペクトル変化量の時間的な変化パターンにより、話速に基づくパラメータを音声データから抽出する。なお、上述した話速の抽出手法のほかに、音声認識に基づいて話速を抽出する公知手法等が利用されても良い。
【0062】
抑揚は、音声データの各単位内の強度変化パターンを表す。音声データの単位は、例えば、音声に含まれる文章を構成する単語または節である。サーバ１は、音声データの強さの変化に基づいて、当該音声データの抑揚を抽出する。例えばサーバ１は、音声データを複数の単位に分割し、各単位内における強さの変化、または、単位間における強さの変化を、当該音声データの抑揚として抽出する。
【0063】
なお、ピッチ、話速または抑揚のほかには、音声のパラメータは、周波数スペクトル、音声強度またはフォルマント周波等を含んでも良い。
【0064】
音声のパラメータは、例えば、周波数解析処理等を用いて特定される。例えば、サーバ１は、ユーザの音声データに対して所定区間（数十ｍｓ）毎に周波数分析を行い、音声の周波数成分情報である音響スペクトルを求める。サーバ１は、求めた音響スペクトルに基づいて、ユーザの音声のパラメータの解析処理を行う。なお、サーバ１は、音声データを入力した場合に、音声のパラメータを出力する学習済みの学習モデルを用いて、音声のパラメータを特定しても良い。
【0065】
サーバ１は、特定した音声のパラメータと、アイドルＤＢ１５２に記憶された各アイドルの音声のパラメータの基準値とを比較することにより、割当対象となるアイドルを特定する。例えば、サーバ１は、特定した音声のパラメータが、記憶された各アイドルの音声のパラメータの基準値の範囲内であるか否かを判定する。サーバ１は、特定した音声のパラメータが基準値の範囲内である場合、該当するアイドルを特定する。
【0066】
なお、サーバ１は、複数のアイドルを特定した場合、特定した複数のアイドルからランダムに１つのアイドルを抽出しても良い。または、サーバ１は、特定した複数のアイドルの属性に基づき該当するアイドルを抽出しても良い。例えば、サーバ１は、複数のアイドルのうち、体力値の一番高いアイドル、または、美しさの値の一番高いアイドルを抽出する。
【0067】
なお、本実施形態では、ユーザの音声データに基づくアイドルの特定処理を説明したが、これに限るものではない。例えば、サーバ１は、ユーザの指紋画像、顔画像または手のひらの静脈画像等の生体データを利用し、アイドルの特定処理を行っても良い。または、サーバ１は、ユーザのモーション（ダンスまたは体操等の動作）データを利用して、アイドルの特定処理を行っても良い。
【0068】
以下では、ユーザの顔画像によるアイドルの特定処理の例を説明するが、他の種類のデータ（指紋画像、手のひらの静脈画像またはモーションデータ等）にも同様に適用することができる。
【0069】
例えば、ユーザの顔画像に基づき構築された、ユーザのタイプを分類可能な学習済みの第１分類モデルを利用しても良い。ユーザのタイプは、例えば、可愛いタイプ、かっこいいタイプ、または美人タイプ等を含む。第１分類モデルは、ユーザの顔画像を入力とし、当該ユーザのタイプを分類した分類結果を出力とするニューラルネットワークを構築済みの分類器である。例えば、ＤＮＮ（Deep Neural Network(s)）、ＣＮＮ（Convolution Neural Network）、ＲＣＮＮ（Regions with Convolutional Neural Network）またはＹＯＬＯ（You Only Look Once）、ＳＶＭ（Support Vector Machine）、ベイジアンネットワーク、トランスフォーマー（Transformer）ネットワーク、または回帰木等の任意の物体検出アルゴリズムを利用し、大量のユーザの顔画像内における顔領域の特徴量を学習するディープラーニングを行うことで第１分類モデルを生成することができる。
【0070】
サーバ１は、ユーザの顔画像を取得した場合、取得した顔画像を第１分類モデルに入力して、当該ユーザのタイプを分類した分類結果を出力する。サーバ１は、第１分類モデルから出力された分類結果に基づき、当該ユーザに割り当てるアイドルを特定する。
【0071】
具体的には、学習モデルにより生成されたアイドルに対し、予め複数のアイドルのタイプが設けられる。アイドルのタイプは、例えばユーザのタイプと同様に、可愛いタイプ、かっこいいタイプ、または美人タイプ等を含む。サーバ１は、第１分類モデルから出力されたユーザのタイプとアイドルのタイプとを比較する。サーバ１は、ユーザのタイプと一致する複数のアイドルを抽出し、抽出した複数のアイドルから、例えばランダムに１つのアイドルを選定する。サーバ１は、選定したアイドルを、ユーザに割り当てるアイドルとして特定する。
【0072】
なお、上述した処理に限るものではない。例えば、ユーザの顔画像に基づき構築された、ユーザのタイプ及び年齢層を分類可能な学習済みの第２分類モデルを利用しても良い。年齢層は、例えば、１２歳以下、１３歳以上１９歳以下、２０歳以上２９歳以下、３０歳以上４９歳以下、５０歳以上のように区分けされて良い。第２分類モデルは、ユーザの顔画像を入力とし、当該ユーザのタイプ及び年齢層を分類した分類結果を出力とするニューラルネットワークを構築済みの分類器である。
【0073】
サーバ１は、ユーザの顔画像を取得した場合、取得した顔画像を第２分類モデルに入力して、当該ユーザのタイプ及び年齢層を分類した分類結果を出力する。サーバ１は、第２分類モデルから出力されたユーザのタイプ及び年齢層と、予め設けられたアイドルのタイプ及び年齢層とを比較する。サーバ１は、ユーザのタイプ及び年齢層と一致する複数のアイドルを抽出し、抽出した複数のアイドルから、例えばランダムに１つのアイドルを選定する。サーバ１は、選定したアイドルを、ユーザに割り当てるアイドルとして特定する。
【0074】
なお、ユーザのタイプ及び年齢層の他に、例えば、性別等を更に加えてアイドルの特定処理を行っても良い。
【0075】
なお、上述した分類処理に関しては、ユーザの音声にも同様に適用することができる。例えば、ユーザの音声データに基づき構築された、ユーザのタイプを分類可能な学習済みの第３分類モデルを利用しても良い。第３分類モデルは、ユーザの音声データを入力とし、当該ユーザのタイプを分類した分類結果を出力とするニューラルネットワークを構築済みの分類器である。例えば、ＤＮＮ等を利用し、大量のユーザの音声データの特徴量（パラメータ）を学習するディープラーニングを行うことで第３分類モデルを生成することができる。
【0076】
サーバ１は、ユーザの音声データを取得した場合、取得した音声データを第３分類モデルに入力して、当該ユーザのタイプを分類した分類結果を出力する。サーバ１は、第３分類モデルから出力されたユーザのタイプと、予め設けられたアイドルのタイプとを比較する。サーバ１は、ユーザのタイプと一致する複数のアイドルを抽出し、抽出した複数のアイドルから、例えばランダムに１つのアイドルを選定する。サーバ１は、選定したアイドルを、ユーザに割り当てるアイドルとして特定する。
【0077】
なお、上述した分類に基づくアイドルの特定処理に限るものではない。例えば、ユーザの顔画像内における顔領域の特徴量と、学習モデルにより生成されたアイドルの顔領域の特徴量とに基づいて、アイドルの特定処理を行っても良い。顔領域の特徴量は、顔の属性（髪型、輪郭、肌の状態、目元、または化粧の有無等）の特徴量を数値化したものである。例えば、サーバ１は、ユーザの顔画像内における顔領域の特徴量と、各アイドルの顔領域の特徴量との類似度を算出する。サーバ１は、類似度の最も高いアイドルを、ユーザに割り当てるアイドルとして特定する。
【0078】
なお、上述したアイドルの特定処理に限るものではない。例えば、ユーザの音声、生体データ（指紋画像、顔画像または手のひらの静脈画像等）、及びモーションデータのいずれかを含む組み合わせデータを利用して、アイドルの特定処理を行っても良い。
【0079】
サーバ１は、特定したアイドルのアイドルＩＤに基づき、当該アイドルのアイドルデータ及び属性（体力、楽曲、ダンスまたは美しさ等）をアイドルＤＢ１５２から取得する。サーバ１は、特定したアイドルをユーザに割り当て、割当データを割当ＤＢ１５３に記憶する。
【0080】
具体的には、サーバ１は、割当データを特定するための割当ＩＤを割り振る。サーバ１は、割り振った割当ＩＤに対応付けて、ユーザＩＤ、アイドルＩＤ、レベルの初期値（例えば、レベル１）、アイドルＤＢ１５２から取得されたアイドルの属性（体力、楽曲、ダンスまたは美しさ等）、及びユーザの音声に基づくパラメータ（音声のピッチ、話速または抑揚等）を一つのレコードとして割当ＤＢ１５３に記憶する。
【0081】
サーバ１は、ユーザに割り当てたアイドルに関する情報をユーザ端末３に送信する。アイドルに関する情報は、アイドルＩＤ、属性及びアイドルデータを含む。ユーザ端末３は、サーバ１から送信されたアイドルに関する情報を受信して画面に表示する。
【0082】
サーバ１は、ユーザＩＤ及びアイドルＩＤに対応付けて、当該アイドルの属性をブロックチェーン２のいずれかのノード２１に送信する。ブロックチェーン２のノード２１は、サーバ１から送信されたユーザＩＤ、アイドルＩＤ及びアイドルの属性を受信して記憶（記録）する。
【0083】
ブロックチェーン２のノード２１は、当該アイドルのアイドルＮＦＴをユーザに付与（発行）する。例えば、ブロックチェーン２がＥｔｈｅｒｅｕｍである場合、サーバ１は、Ｅｔｈｅｒｅｕｍの一つのスマートコントラクト規格であるＥＲＣ７２１を利用してアイドルＮＦＴを発行する。ＥＲＣ７２１規格を用いれば、ブロックチェーン２上の全てのアイドルＮＦＴを開示しているが、改ざんすることはできないため、保有者（所有者）または帰属情報等を付けることが可能となる。発行されたアイドルＮＦＴのトークンＩＤ、ユーザのウォレットアドレス（保有者アドレス）及びトークンＵＲＩ等がブロックチェーン２上で記憶される。
【0084】
なお、アイドルＮＦＴを管理者に発行した場合、管理者は保有する当該アイドルＮＦＴをユーザ（発行対象者）に譲渡する。この場合、ブロックチェーン２は、アイドルＮＦＴのトークンＩＤ及びトークンＵＲＩ（メタデータの場所）を引き継ぐようにする。ブロックチェーン２は、アイドルＮＦＴのウォレットアドレスを、管理者のウォレットアドレスからユーザのウォレットアドレスに変更する。ブロックチェーン２は、譲渡後のアイドルＮＦＴのトークンＩＤ（変更なし）、変更後のウォレットアドレス、及びトークンＵＲＩ（変更なし）等を記憶する。
【0085】
また、アイドルＮＦＴの保有者は、アイドルＮＦＴの売買または移転を介して、暗号資産と同様にアイドルＮＦＴを自由に取引できる。
【0086】
ブロックチェーン２のノード２１は、ユーザに付与したアイドルＮＦＴに関する情報をサーバ１に送信する。アイドルＮＦＴに関する情報は、例えば、アイドルＮＦＴのトークンＩＤ、ユーザのウォレットアドレスまたはトークンＵＲＩ等を含む。サーバ１は、ブロックチェーン２のノード２１から送信されたアイドルＮＦＴに関する情報を受信する。
【0087】
サーバ１は、受信したアイドルＮＦＴに関する情報をアイドルＮＦＴＤＢ１５４に記憶する。具体的には、サーバ１は、ユーザＩＤ及びアイドルＩＤに対応付けて、ブロックチェーン２上で発行されたアイドルＮＦＴ（トークンＩＤ、ユーザのウォレットアドレスまたはトークンＵＲＩ等）を一つのレコードとしてアイドルＮＦＴＤＢ１５４に記憶する。
【0088】
図８は、ユーザにアイドルを割り当てる画面の一例を示す説明図である。
図８Ａは、ユーザの音声の入力受付画面の一例を示す説明図である。当該画面は、受付ボタン（呼ぶボタン）１２ａ及び発話テキスト表示欄１２ｂを含む。受付ボタン１２ａは、ユーザへのアイドルの割当指示を受け付けるボタンである。発話テキスト表示欄１２ｂは、ユーザの発話を示すテキスト（発話テキスト）を表示する表示欄である。
図８Ａは、ユーザの音声の入力受付画面の一例を示す説明図である。当該画面は、受付ボタン（呼ぶボタン）１２ａ及び発話テキスト表示欄１２ｂを含む。受付ボタン１２ａは、ユーザへのアイドルの割当指示を受け付けるボタンである。発話テキスト表示欄１２ｂは、ユーザの発話を示すテキスト（発話テキスト）を表示する表示欄である。
【0089】
ユーザ端末３は、ユーザによる受付ボタン１２ａのタッチ（クリック）操作を受け付けた場合、マイク３６を介して、ユーザの音声の入力を受け付ける。ユーザ端末３は、受け付けた音声に対して音声認識処理を行って、発話テキストの変換処理を行う。例えば、ユーザ端末３は、発話内容を示す発話テキストを生成する音声認識エンジン等を利用し、受け付けた音声を発話テキストに変換しても良い。なお、発話テキストの変換処理は、サーバ１側で行われても良い。
【0090】
ユーザ端末３は、変換した発話テキストを発話テキスト表示欄１２ｂに表示する。図示のように、ユーザの発話テキストは「こんにちは！アイドル」である。ユーザ端末３は、ユーザＩＤに対応付けて、受け付けたユーザの音声データをサーバ１に送信する。
【0091】
図８Ｂは、割り当てられたアイドルの表示画面の一例を示す説明図である。当該画面は、名前表示欄１２ｃ、属性表示欄１２ｄ及びアイドル表示欄１２ｅを含む。名前表示欄１２ｃは、アイドルの名前を表示する表示欄である。属性表示欄１２ｄは、アイドルの属性を表示する表示欄である。アイドル表示欄１２ｅは、アイドルデータを表示する表示欄である。なお、アイドル表示欄１２ｅには、アイドルの画像またはサムネイル画像等が表示されても良い。
【0092】
サーバ１は、ユーザ端末３から送信された音声データから、例えば、周波数解析処理等を用いて当該音声のパラメータを特定する。音声のパラメータは、音声のピッチ、話速または抑揚等を含む。サーバ１は、特定した音声のパラメータと、アイドルＤＢ１５２に記憶された各アイドルの音声のパラメータの基準値とを比較することにより、割当対象となるアイドルを特定する。
【0093】
サーバ１は、特定したアイドルのアイドルＩＤに基づき、当該アイドルの名前、アイドルデータ及び属性（体力、楽曲、ダンスまたは美しさ等）をアイドルＤＢ１５２から取得する。サーバ１は、取得したアイドルＩＤ、アイドルの名前、アイドルデータ及び属性をユーザ端末３に送信する。
【0094】
ユーザ端末３は、サーバ１から送信されたアイドルＩＤ、アイドルの名前、アイドルデータ及び属性を受信する。ユーザ端末３は、受信したアイドルの名前を名前表示欄１２ｃに表示し、受信した属性を属性表示欄１２ｄに表示し、受信したアイドルデータをアイドル表示欄１２ｅに表示する。
【0095】
図９は、アイドルデータを記憶する際の処理手順を示すフローチャートである。サーバ１の制御部１１は、アイドルを生成するための学習モデルを取得する（ステップＳ２１）。
【0096】
学習モデルとしては、例えば、テキスト（情景等）の説明文から画像を出力するＡＩ（Artificial Intelligence）サービス（例えば、Midjourney）が提供する学習済みの学習モデル等を用いることができる。なお、学習モデルは、例えば、ＤＮＮ、ＣＮＮ、ＲＣＮＮ、Ｆａｓｔ ＲＣＮＮ、Ｆａｓｔｅｒ ＲＣＮＮ、ＳＳＤ、ＹＯＬＯ、ＳＶＭ、ベイジアンネットワーク、トランスフォーマーネットワーク、または回帰木等を利用して構築されても良い。なお、アイドルを生成するための学習モデルは、サーバ１または外部の情報処理装置により構築されても良い。
【0097】
例えば、制御部１１は、Midjourneyが提供する学習済みの学習モデルを通信部１３により外部の情報処理装置から取得しても良い。または、制御部１１は通信部１３を介して、当該学習モデルが記憶された外部の情報処理装置に直接アクセスしても良い。
【0098】
制御部１１は、取得した学習モデルを利用してアイドルを生成する（ステップＳ２２）。例えば制御部１１は、学習モデルがMidjourneyである場合、テキストの説明文（例えば、白い肌に金髪の少女）を学習モデルに入力して、当該テキストの説明文に対応するアイドルの画像を出力する。
【0099】
制御部１１は、生成したアイドルに対し、名前の設定を受け付ける（ステップＳ２３）。例えば制御部１１は、ゲームアプリケーションの設計者等の端末を通じて、当該設計者による名前の入力を受け付けても良い。または、制御部１１は、予め用意された複数の名前からランダムに１つの名前を抽出しても良い。
【0100】
制御部１１は、生成したアイドルに対し、属性（体力、楽曲、ダンスまたは美しさ等）の設定を受け付ける（ステップＳ２４）。属性の受付処理は特に限定されるものではない。例えば、制御部１１は、ゲームアプリケーションの設計者等の端末を通じて、当該設計者による属性の設定を受け付ける。例えば、設定された属性が「体力：６、楽曲：ｍｕｓｉｃ２及びｍｕｓｉｃ３、ダンス：ダンスＡ、美しさ：２」であっても良い。または、制御部１１は、予め用意された複数の体力値、美しさの値、楽曲またはダンスからランダムに選定し、当該アイドルの属性として用いても良い。
【0101】
制御部１１は、生成したアイドルに対し、アイドルをユーザに割り当てる際に用いられる音声のパラメータの基準値の設定を受け付ける（ステップＳ２５）。例えば、制御部１１は、予め用意された複数の音声のパラメータの基準値から、１つの音声のパラメータの基準値をランダムに抽出しても良い。または、制御部１１は、ゲームアプリケーションの設計者等の端末を通じて、当該設計者による音声のパラメータの基準値の入力を受け付けても良い。
【0102】
制御部１１は、アイドルデータを大容量記憶部１５のアイドルＤＢ１５２に記憶し（ステップＳ２６）、処理を終了する。具体的には、制御部１１は、生成したアイドルに対してアイドルＩＤを割り振る。制御部１１は、割り振ったアイドルＩＤに対応付けて、アイドルの名前、アイドルデータ（例えば、アイドルの画像データ）、属性（体力、楽曲、ダンス及び美しさ等）及び音声のパラメータの基準値を一つのレコードとしてアイドルＤＢ１５２に記憶する。
【0103】
図１０は、ユーザにアイドルを割り当てる際の処理手順を示すフローチャートである。ユーザ端末３の制御部３１は、ユーザの音声の入力をマイク３６により受け付ける（ステップＳ３０１）。制御部３１は、ユーザＩＤ、及び受け付けたユーザの音声データを通信部３３によりサーバ１に送信する（ステップＳ３０２）。サーバ１の制御部１１は、ユーザ端末３から送信されたユーザＩＤ及び音声データを通信部１３により受信する（ステップＳ１０１）。
【0104】
制御部１１は、ユーザＩＤ対応付けて、受信した音声データを大容量記憶部１５のユーザＤＢ１５１に記憶する（ステップＳ１０２）。制御部１１は、例えば、周波数解析処理等を用いて、音色データから音声のパラメータ（音声のピッチ、話速または抑揚等）を特定する（ステップＳ１０３）。制御部１１は、大容量記憶部１５のアイドルＤＢ１５２に記憶された各アイドルの音声のパラメータの基準値を取得する（ステップＳ１０４）。
【0105】
制御部１１は、特定した音声のパラメータと、取得した各アイドルの音声のパラメータの基準値とを比較することにより、割当対象となるアイドルを特定する（ステップＳ１０５）。例えば、制御部１１は、特定した音声のパラメータが、記憶された各アイドルの音声のパラメータの基準値の範囲内であるか否かを判定する。制御部１１は、特定した音声のパラメータが基準値の範囲内である場合、該当するアイドルを特定する。
【0106】
制御部１１は、特定したアイドルのアイドルＩＤに基づき、当該アイドルのアイドルデータ及び属性（体力、楽曲、ダンスまたは美しさ等）を大容量記憶部１５のアイドルＤＢ１５２から取得する（ステップＳ１０６）。制御部１１は、特定したアイドルをユーザに割り当てた割当データを大容量記憶部１５の割当ＤＢ１５３に記憶する（ステップＳ１０７）。
【0107】
具体的には、制御部１１は、割当データを特定するための割当ＩＤを割り振る。制御部１１は、割り振った割当ＩＤに対応付けて、ユーザＩＤ、アイドルＩＤ、レベルの初期値（例えば、レベル１）、アイドルの属性（体力、楽曲、ダンスまたは美しさ等）、及びステップＳ１０３の処理で特定されたユーザの音声のパラメータを一つのレコードとして割当ＤＢ１５３に記憶する。
【0108】
制御部１１は、ユーザに割り当てたアイドルのアイドルＩＤ、アイドルデータ及び属性を通信部１３によりユーザ端末３に送信する（ステップＳ１０８）。ユーザ端末３の制御部３１は、サーバ１から送信されたアイドルＩＤ、アイドルデータ及び属性を通信部３３により受信する（ステップＳ３０３）。制御部３１は、受信したアイドルＩＤ、アイドルデータ及び属性を表示部３５により表示し（ステップＳ３０４）、処理を終了する。
【0109】
図１１は、ユーザにアイドルＮＦＴを付与する際の処理手順を示すフローチャートである。サーバ１の制御部１１は、ユーザＩＤ及びアイドルＩＤに基づき、ユーザに割り当てたアイドルの属性を大容量記憶部１５の割当ＤＢ１５３を取得する（ステップＳ１１１）。取得された属性は、アイドルの体力、楽曲、ダンス、美しさ及びユーザの音声に基づくパラメータを含む。
【0110】
制御部１１は、アイドルの属性の記憶処理のトランザクションを作成する（ステップＳ１１２）。トランザクションは、ブロックチェーン２における取引記録であり、ブロックチェーン２の参加者間での各種の情報及び価値の移転を記憶している。作成されたトランザクションは、ユーザＩＤ、ユーザに割り当てたアイドルのアイドルＩＤ及び属性等を含む。制御部１１は、作成したトランザクションを通信部１３によりブロックチェーン２のいずれかのノード２１に送信する（ステップＳ１１３）。
【0111】
ブロックチェーン２のノード２１の制御部２１１は、サーバ１から送信されたトランザクションを通信部２１３により受信する（ステップＳ２１１）。制御部２１１は、受信したトランザクションに含まれるユーザＩＤ、アイドルＩＤ及び属性を記憶部２１２に記憶する（ステップＳ２１２）。
【0112】
具体的には、トランザクションを受信したノード２１の制御部２１１は、ブロック生成部２１６を介して、受信したトランザクションに含まれるユーザＩＤ、アイドルＩＤ及び属性と、自身が管理しているブロックチェーン２の情報とを基に作成した前ブロック管理情報とを少なくとも含むブロックを生成する。そして、ブロックチェーン２のノード２１各々の制御部２１１は、所定のコンセンサス処理をブロック生成部２１６により実行する。
【0113】
ブロックチェーン２は、ブロックとよばれる所定のデータ構造を有するデータ群を時系列に並べたものであり、取引内容を記した台帳としての役割を有する。各ブロックは、取引内容等の当該ブロックに記録したいデータの他に、一つ以上前のブロック（以下、前ブロックという）の情報と、改ざんの有無を検知するための情報（ノンスまたは署名等）とを含む。ノンスは、あるデータ領域に対して、その領域内のデータを一方向性関数により処理したときに得られる値が予め決められた規則を満たすように設定される、当該データ領域内の値である。
【0114】
ブロックチェーン２には、２台以上のノード２１が参加する所定のコンセンサスアルゴリズムに従った処理を経て新たなブロックが追加される。例えば、コンセンサスアルゴリズムの一つであるＰｏＷでは、前ブロックの情報とノンスとを含む各ブロック（データ群）に対して、「ブロックのＨａｓｈ値が閾値以下であること」といった規則が予め決められており、ブロックを追加する際に、そのような規則を満たすようなノンスを複数のノードが同時並列的に探索する処理がブロック検証部２１７により行われる。なお、ＰｏＷ以外にもＢＦＴ（Byzantine fault tolerance）等のコンセンサスアルゴリズムがある。
【0115】
ブロックチェーン２のノード２１各々の制御部２１１は、所定のコンセンサス処理を実行した後に、ブロック共有部２１８を介して、ブロック生成部２１６が生成したブロックを記憶部２１２に記憶（追加）する。
【0116】
ノード２１の制御部２１１は、当該ブロックチェーン２上でアイドルＮＦＴを発行する（ステップＳ２１３）。例えば、ブロックチェーン２がＥｔｈｅｒｅｕｍである場合、制御部１１は、Ｅｔｈｅｒｅｕｍの一つのスマートコントラクト規格であるＥＲＣ７２１を利用してアイドルＮＦＴを発行しても良い。ノード２１の制御部２１１は、発行したアイドルＮＦＴのトークンＩＤ、ユーザのウォレットアドレス及びトークンＵＲＩを記憶部２１２に記憶する（ステップＳ２１４）。
【0117】
ノード２１の制御部２１１は、発行したアイドルＮＦＴを通信部２１３によりサーバ１に送信する（ステップＳ２１５）。サーバ１の制御部１１は、ブロックチェーン２のノード２１から送信されたアイドルＮＦＴを通信部１３により受信する（ステップＳ１１４）。制御部１１は、受信したアイドルＮＦＴを大容量記憶部１５のアイドルＮＦＴＤＢ１５４に記憶し（ステップＳ１１５）、処理を終了する。
【0118】
具体的には、制御部１１は、ユーザＩＤ及びアイドルＩＤに対応付けて、ブロックチェーン２上で発行されたアイドルＮＦＴのトークンＩＤ、ユーザのウォレットアドレス及びトークンＵＲＩを一つのレコードとしてアイドルＮＦＴＤＢ１５４に記憶する。
【0119】
本実施形態によると、ユーザの音声に基づき、学習モデルにより生成されたアイドルを当該ユーザに割り当てることが可能となる。
【0120】
本実施形態によると、ユーザに割り当てたアイドルの属性をブロックチェーン２に記憶することが可能となる。
【0121】
本実施形態によると、ユーザに割り当てたアイドルのアイドルＮＦＴをブロックチェーン２上で当該ユーザに付与することが可能となる。
【0122】
（実施形態２）
実施形態２は、ミッションのクリアによりアイドルの属性を更新する形態に関する。なお、実施形態１と重複する内容については説明を省略する。
実施形態２は、ミッションのクリアによりアイドルの属性を更新する形態に関する。なお、実施形態１と重複する内容については説明を省略する。
【0123】
図１２は、実施形態２におけるサーバ１の構成例を示すブロック図である。なお、図２と重複する内容については同一の符号を付して説明を省略する。大容量記憶部１５には、ミッションＤＢ１５５が含まれる。ミッションＤＢ１５５は、アイドルのレベルをアップするためのミッション（タスク）に関する情報を記憶している。
【0124】
図１３は、ミッションＤＢ１５５のレコードレイアウトの一例を示す説明図である。ミッションＤＢ１５５は、ミッションＩＤ列、種類列、内容列、会場列及びクリア条件列を含む。ミッションＩＤ列は、各ミッションを識別するために、一意に特定されるミッションのＩＤを記憶している。ミッションは、ゲームアプリケーション内の課題である。本実施形態では、ミッションのクリアに伴い、アイドルのレベルをアップすることができる。
【0125】
種類列は、ミッションの種類を記憶している。ミッションの種類は、例えば、ライブまたはダンス競技等を含む。内容列は、ミッションの内容及び開催日時等を記憶している。会場列は、ミッション（例えば、ライブ）を開催する会場を記憶している。クリア条件列は、ミッションをクリアする条件を記憶している。クリア条件は、各ミッションの内容に応じて適宜設定することが可能である。例えば、ミッションの種類がライブである場合、当該ミッションのクリア条件は「所定のファン数（例えば、１００人）に達成すること」等であっても良い。
【0126】
図１４は、ミッションを行う画面の一例を示す説明図である。なお、本実施形態では、ミッションの種類がライブである例を説明するが、他の種類のミッションにも同様に適用することができる。以下では、仮想的な駅の前に開催する「駅前ライブ」の例を説明する。ユーザに割り当てたアイドルは「駅前ライブ」に参加することができる。
【0127】
「駅前ライブ」となるミッションは、アイドルの体力値が所定範囲（例えば、１～１２）内である場合、所定場所での当該アイドルの歌唱を行う。所定場所は、「駅前ライブ」を開催する仮想的な場所（例えば、東京駅または大阪駅）である。アイドルの歌唱をさせる毎に、当該アイドルの体力値は消費される。
【0128】
歌唱の時間または楽曲の難易度等に基づいて、アイドルの消費体力値を設けることができる。例えば、アイドルが楽曲を歌唱させた場合、一定時間の経過（例えば、２０秒）毎に、当該アイドルにおける所定の体力値（例えば、１）を消費しても良い。または、難易度の低い楽曲より、アイドルが難易度の高い楽曲を歌唱させた場合、一定時間の経過毎に、当該アイドルにおける所定の体力値（例えば、１）より多くの体力値（例えば、２）を消費しても良い。
【0129】
歌唱に伴いミッションのクリア条件が成立した場合、歌唱を行ったアイドルのレベルをアップさせる。例えば、アイドルの歌唱に伴い、当該アイドルのファン数が所定のファン数（例えば、１００人）以上である場合、当該アイドルのレベルをアップさせる。なお、ファン数の加算アルゴリズムは、例えば、「駅前ライブ」の開催場所、開催日時、歌唱を行うアイドルのレベルまたは属性等に応じて設けられても良い。
【0130】
例えば、開催場所が１日の利用者数の多い仮想的な駅（例えば、新宿駅）である場合、アイドルの歌唱に伴い多くのファン数を設けても良い。例えば、新宿駅における最初のファン数が５０人であり、一定の歌唱時間の経過（例えば、１０秒）毎に、アイドルのファン数に、利用者の少ない仮想的な駅より所定のファン数（例えば、１０人）の倍数（例えば、２倍）を加算しても良い。
【0131】
または、開催日時が利用者の多い時間帯（例えば、２０：００～２２：００）内である場合、アイドルの歌唱に伴い多くのファン数を設けても良い。例えば、「２０：００～２２：００」である時間帯において、一定の歌唱時間の経過（例えば、１０秒）毎に、アイドルのファン数に、利用者の少ない時間帯（例えば、１０：００～１２：００）より所定のファン数（例えば、１０人）の倍数（例えば、３倍）を加算しても良い。
【0132】
または、アイドルのレベルが高いほど、ファン数が多くなるように設けても良い。例えば、レベルに応じる増加ファン数が、「レベル１：３人、レベル２：５人、レベル３：８人…」であっても良い。例えば、サーバ１は、最初のファン数が５０人であり、一定の歌唱時間の経過毎に、アイドルのファン数に当該アイドルのレベルに対応する増加ファン数を加算しても良い。
【0133】
または、アイドルの属性（体力、楽曲、ダンス及び美しさ等）に応じてファン数を加算することができる。例えば、体力値、楽曲の数、ダンスの数または美しさの値に応じて、複数のファン数の加算レベルを設けても良い。例えば、「加算レベル１：３人、加算レベル２：５人、加算レベル３：８人…」であっても良い。サーバ１は、一定の歌唱時間の経過毎に、アイドルのファン数に、当該アイドルの属性に応じた加算レベルに対応するファン数を加算する。
【0134】
更にまた、開催場所、開催日時、アイドルのレベル及び属性等の組み合わせに基づいて、ファン数の加算アルゴリズムを設けても良い。
【0135】
更にまた、サーバ１は、アイドルに複数の楽曲を歌唱させた場合、１つの楽曲の再生が終了した後に、アイドルのファン数に、所定のファン数（例えば、５０人）を加算しても良い。
【0136】
「駅前ライブ」となるミッションをクリアした場合、アイドルの体力、楽曲、ダンスまたは美しさを含む当該アイドルの属性を更新する。例えば、アイドルの体力値を所定の増加量（例えば、１）に応じて増加しても良い。または、アイドルが歌唱可能な楽曲を増加させても良く、または、アイドルが踊り可能なダンスを増加させても良い。更にまた、アイドルの美しさを向上させても良い。なお、レベルアップに伴う属性の更新内容は、ゲームアプリケーション内で任意に設けられても良い。
【0137】
【0138】
当該画面は、開催場所表示欄１３ａ、ファン表示欄１３ｂ、アイドルデータ表示欄１３ｃ、メッセージ表示欄１３ｄ及び体力値表示欄１３ｅを含む。開催場所表示欄１３ａは、ライブの仮想的な開催場所（例えば、新宿駅または東京駅）を表示する表示欄である。ファン表示欄１３ｂは、ミッションをクリアするためにファン数、またはファン数の達成状況を表示する表示欄である。
【0139】
アイドルデータ表示欄１３ｃは、アイドルのデータを表示する表示欄である。メッセージ表示欄１３ｄは、アイドルの名前及びメッセージ等を表示する表示欄である。体力値表示欄１３ｅは、アイドルの体力値を表示する表示欄である。
【0140】
ユーザ端末３は、サーバ１のミッションＤＢ１５５から、ミッションの種類がライブであるライブ一覧を取得する。ライブ一覧は、各ライブのミッションＩＤ、内容、会場及びクリア条件等を含む。ユーザ端末３は、例えば、歌唱設定の受付画面（図示なし）を通じて、取得したライブ一覧から、ユーザによるライブの開催日時、仮想的な開催場所（例えば、新宿駅）、歌唱の楽曲及びダンス等の設定情報を受け付ける。歌唱の楽曲は、ユーザまたはシステム等により、アイドルが歌唱可能な楽曲から選択されても良い。ユーザ端末３は、受け付けた開催場所を開催場所表示欄１３ａに表示する。
【0141】
ユーザ端末３は、ユーザＩＤ及びユーザに割り当てたアイドルのアイドルＩＤに基づいて、ブロックチェーン２のノード２１から、当該アイドルの属性（体力値及び楽曲）を取得する。なお、ユーザ端末３は、割当ＩＤに基づいてアイドルの属性をサーバ１の割当ＤＢ１５３から取得しても良い。
【0142】
ユーザ端末３は、アイドルＩＤに基づいて、当該アイドルの名前及びアイドルのデータをサーバ１のアイドルＤＢ１５２から取得する。ユーザ端末３は、メッセージ（例えば、「今日のライブも全力です！」）を取得する。なお、メッセージは、予めユーザ端末３の記憶部３２に記憶されても良い。ユーザ端末３は、割当ＩＤに基づいて、当該アイドルのレベルをサーバ１の割当ＤＢ１５３から取得する。
【0143】
ユーザ端末３は、取得したアイドルのデータをアイドルデータ表示欄１３ｃに表示する。ユーザ端末３は、取得したアイドルの名前及びメッセージをメッセージ表示欄１３ｄに表示する。ユーザ端末３は、取得したアイドルの属性に含まれる体力値を体力値表示欄１３ｅに表示する。
【0144】
ユーザ端末３は、受け付けた歌唱の設定情報（開催日時、開催場所及び歌唱の楽曲等）をサーバ１に送信する。サーバ１は、ユーザ端末３から送信された設定情報を受信する。サーバ１は、設定情報に含まれるライブの開催日時になると、アイドルの体力値が所定範囲（例えば、１～１２）内であるか否かを判定する。
【0145】
サーバ１は、アイドルの体力値が所定範囲内である場合、受信した設定情報に含まれる楽曲をユーザ端末３に配信する。ユーザ端末３は、配信された楽曲の再生を開始する。なお、アイドルが所定の曲数（例えば、３）の楽曲を歌唱させることができる。サーバ１から所定の曲数の楽曲をユーザ端末３に配信した場合、ユーザ端末３は、配信された複数の楽曲を順次に再生する。
【0146】
ユーザ端末３は、所定の時間間隔（例えば、１０秒）毎に、ファン数及び消費体力値をサーバ１から取得する。ユーザ端末３は、取得したファン数をファン表示欄１３ｂに表示し、消費体力値に基づく最新の体力値を体力値表示欄１３ｅに表示する。
【0147】
ユーザ端末３は、楽曲の再生が終了していない、且つ、体力値が所定範囲内である場合、楽曲の再生を続ける。ユーザ端末３は、アイドルの体力値が所定範囲外である場合、楽曲の再生が終了するか、または、当該アイドルの体力の回復処理を行う。体力の回復処理は、例えば、楽曲の再生を一時停止し、所定の時間間隔（例えば、１０秒）毎に、所定の体力値（例えば、１）を加算しても良い。なお、ゲームアプリケーション内に設定されている体力回復用のアイテム（例えば、魔法の飲み物）またはイベント等により、アイドルの体力を回復することができる。
【0148】
サーバ１は、ユーザ端末３側での楽曲の再生が終了したと検知した場合、ライブのファン数と、所定のファン数（例えば、１００人）とを比較する。サーバ１は、ライブのファン数が所定のファン数を達成した場合、アイドルのレベルをアップする。サーバ１は、アイドルのレベル及び属性を割当ＤＢ１５３に更新する。具体的には、サーバ１は、割当ＩＤに対応付けて、レベルアップ後のレベル、更新後の体力値、楽曲、ダンスまたは美しさを割当ＤＢ１５３に更新する。
【0149】
サーバ１は、更新後のアイドルの属性をブロックチェーン２のノード２１に記憶する。具体的には、サーバ１は、アイドルの属性の更新処理のトランザクションを作成する。作成されたトランザクションは、ユーザＩＤ、ユーザに割り当てたアイドルのアイドルＩＤ及び更新後の属性等を含む。
【0150】
サーバ１は、作成したトランザクションをブロックチェーン２のいずれかのノード２１に送信する。ブロックチェーン２のノード２１は、サーバ１から送信されたトランザクションを受信する。ノード２１は、受信したトランザクションに含まれるユーザＩＤ、アイドルＩＤ及び更新後の属性を記憶する。
【0151】
サーバ１は、ミッションのクリア画面（図１４Ｂ）及びレベルアップ画面（図１４Ｃ）をユーザ端末３に送信する。ユーザ端末３は、サーバ１から送信されたミッションのクリア画面及びレベルアップ画面を受信して順次に表示する。例えば、ユーザ端末３は、ミッションのクリア画面を表示した後に、所定の時間間隔（例えば、５秒）を経過した場合、レベルアップ画面を表示しても良い。
【0152】
図示のように、ミッションのクリア画面には、「目標ファン数到達！ 新宿駅クリア」となったメッセージ、及び目標ファン数到達を示す画像が表示される。レベルアップ画面には、レベルをアップした旨を含むメッセージ、アイドルのデータ、アイドルの名前及びレベルアップに伴い更新された属性（楽曲等）が表示される。
【0153】
図１５及び図１６は、アイドルの属性を更新する際の処理手順を示すフローチャートである。サーバ１の制御部１１は、ミッションの種類がライブであるライブ一覧を大容量記憶部１５のミッションＤＢ１５５から取得する（ステップＳ１２１）。ライブ一覧は、各ライブのミッションＩＤ、内容、会場及びクリア条件等を含む。制御部１１は、ユーザＩＤ及びアイドルＩＤに基づいて、ブロックチェーン２のノード２１から、当該アイドルの属性（体力値及び楽曲）を通信部１３により取得する（ステップＳ１２２）。
【0154】
制御部１１は、取得したライブ一覧及びアイドルの属性を通信部１３によりユーザ端末３に送信する（ステップＳ１２３）。ユーザ端末３の制御部３１は、サーバ１から送信されたライブ一覧及びアイドルの属性を通信部３３により受信する（ステップＳ３２１）。制御部３１は、受信したライブ一覧及びアイドルの属性を表示部３５により表示する（ステップＳ３２２）。
【0155】
制御部３１は、入力部３４を介して、ライブ一覧からユーザによる歌唱の設定情報を受け付ける（ステップＳ３２３）。設定情報は、ライブの仮想的な開催場所（例えば、新宿駅）、ライブの開催日時及び歌唱の楽曲等を含む。制御部３１は、受け付けた歌唱の設定情報を通信部３３によりサーバ１に送信する（ステップＳ３２４）。
【0156】
サーバ１の制御部１１は、ユーザ端末３から送信された歌唱の設定情報を通信部１３により受信する（ステップＳ１２４）。制御部１１は、受信した歌唱の設定情報に応じて、ライブの開催日時になるか否かを判定する（ステップＳ１２５）。制御部１１は、ライブの開催日時になっていない場合（ステップＳ１２５でＮＯ）、待機する。制御部１１は、ライブの開催日時になる場合（ステップＳ１２５でＹＥＳ）、アイドルの体力値が所定範囲（例えば、１～１２）内であるか否かを判定する（ステップＳ１２６）。
【0157】
制御部１１は、アイドルの体力値が所定範囲外である場合（ステップＳ１２６でＮＯ）、歌唱不可の旨を含むメッセージを通信部１３によりユーザ端末３に送信する（ステップＳ１２７）。ユーザ端末３の制御部３１は、サーバ１から送信されたメッセージを通信部３３により受信する（ステップＳ３２５）。制御部３１は、受信したメッセージを表示部３５により表示し（ステップＳ３２６）、処理を終了する。
【0158】
制御部１１は、アイドルの体力値が所定範囲内である場合（ステップＳ１２６でＹＥＳ）、楽曲の配信を開始する（ステップＳ１２８）。例えば、制御部１１は、大容量記憶部１５のアイドルＤＢ１５２、または外部の楽曲配信サーバから該当する楽曲を取得する。制御部１１は、取得した楽曲を通信部１３によりユーザ端末３に送信（配信）する。
【0159】
制御部１１は、楽曲が終了したか否かを判定する（ステップＳ１２９）。制御部１１は、楽曲が終了していない場合（ステップＳ１２９でＮＯ）、アイドルの体力値が所定範囲内であるか否かを判定する（ステップＳ１３０）。制御部１１は、体力値が所定範囲外である場合（ステップＳ１３０でＮＯ）、後述するステップＳ１３１の処理に遷移する。制御部１１は、体力値が所定範囲内である場合（ステップＳ１３０でＹＥＳ）、ステップＳ１２９の処理に戻る。
【0160】
制御部１１は、楽曲の再生が終了した場合（ステップＳ１２９でＹＥＳ）、楽曲の配信を終了する（ステップＳ１３１）。制御部１１は、ライブのファン数と、所定のファン数（例えば、１００人）とを比較することにより、ライブのファン数が所定のファン数を達成したか否かを判定する（ステップＳ１３２）。制御部１１は、ライブのファン数が所定のファン数を達成していない場合（ステップＳ１３２でＮＯ）、処理を終了する。
【0161】
制御部１１は、ライブのファン数が所定のファン数を達成した場合（ステップＳ１３２でＹＥＳ）、アイドルのレベルをアップする（ステップＳ１３３）。例えば、制御部１１は、現在のレベル２からレベル３にアップする。制御部１１は、アイドルの属性を更新する（ステップＳ１３４）。例えば、制御部１１は、アイドルの体力値、及び、当該アイドルが歌唱可能な楽曲の増加処理を行っても良い。
【0162】
制御部１１は、割当ＩＤに対応付けて、レベルアップ後のレベル、更新後の属性（体力値及び楽曲等）を大容量記憶部１５の割当ＤＢ１５３に更新する（ステップＳ１３５）。制御部１１は、ユーザＩＤ、ユーザに割り当てたアイドルのアイドルＩＤ及び更新後の属性等を含むアイドルの属性の更新処理のトランザクションを作成する（ステップＳ１３６）。
【0163】
制御部１１は、作成したトランザクションを通信部１３によりブロックチェーン２のいずれかのノード２１に送信する（ステップＳ１３７）。ブロックチェーン２のノード２１の制御部２１１は、サーバ１から送信されたトランザクションを通信部２１３により受信する（ステップＳ２３１）。ノード２１の制御部２１１は、受信したトランザクションに含まれるユーザＩＤ、アイドルＩＤ及び更新後の属性を記憶部２１２に記憶する（ステップＳ２３２）。
【0164】
本実施形態によると、ミッションのクリアによりアイドルの属性を更新することが可能となる。
【0165】
本実施形態によると、アイドルの歌唱に伴い所定の条件が成立した場合、当該アイドルのレベルをアップすることが可能となる。
【0166】
（実施形態３）
実施形態３は、ユーザに割り当てたアイドルと、当該ユーザとは異なる第２ユーザに割り当てたアイドルからなるアイドル群とを含むアイドルユニットを結成する形態に関する。なお、実施形態１～２と重複する内容については説明を省略する。
実施形態３は、ユーザに割り当てたアイドルと、当該ユーザとは異なる第２ユーザに割り当てたアイドルからなるアイドル群とを含むアイドルユニットを結成する形態に関する。なお、実施形態１～２と重複する内容については説明を省略する。
【0167】
図１７は、実施形態３におけるサーバ１の構成例を示すブロック図である。なお、図１２と重複する内容については同一の符号を付して説明を省略する。大容量記憶部１５には、アイドルユニットＤＢ１５６が含まれる。アイドルユニットＤＢ１５６は、アイドルユニットに関する情報を記憶している。
【0168】
図１８は、アイドルユニットＤＢ１５６のレコードレイアウトの一例を示す説明図である。アイドルユニットＤＢ１５６は、ユニットＩＤ列、ユニット名列、アイドルＩＤ列、レベル列、ユニット属性列及びフォーメーション列を含む。
【0169】
ユニットＩＤ列は、各アイドルユニットを識別するために、一意に特定されるアイドルユニットのＩＤを記憶している。ユニット名列は、ユニットの名称を記憶している。アイドルＩＤ列は、アイドルを特定するアイドルＩＤを記憶している。レベル列は、アイドルユニットのレベルを記憶している。
【0170】
ユニット属性列は、楽曲列及びダンス列を含む。楽曲列は、アイドルユニットが歌唱可能な楽曲、または歌唱動画等を記憶している。なお、アイドルユニットが歌唱可能な楽曲は、アイドルユニットのレベルに応じて設けられても良い。例えば、「レベル１：ｍｕｓｉｃ１、ｍｕｓｉｃ２及びｍｕｓｉｃ３、レベル２：ｍｕｓｉｃ４、ｍｕｓｉｃ５及びｍｕｓｉｃ６…」であっても良い。ダンス列は、アイドルユニットが踊り可能なダンスを記憶している。なお、アイドルユニットの属性は、楽曲及びダンスに限らず、例えば、年齢層等を含んでも良い。
【0171】
フォーメーション列は、歌唱またはダンスを行う際に、アイドルユニットのフォーメーションを記憶している。フォーメーションは、例えば、横１列のパターン、横２列のパターン、縦１列パターン、縦２列パターン、１－２－４（横１列：１人 横２列：２人 横３列：４人）パターン、１－５（横１列：１人 横２列：５人）パターン、または２－３（横１列：２人 横２列：３人）パターン等を含む。
【0172】
図１９は、実施形態３におけるアイドルＤＢ１５２及び割当ＤＢ１５３のレコードレイアウトの一例を示す説明図である。なお、図３及び図４と重複する内容については説明を省略する。アイドルＤＢ１５２及び割当ＤＢ１５３の属性列は、出身地列を含む。出身地列は、アイドルの出身地を記憶している。
【0173】
ユーザに割り当てたアイドルと、当該ユーザとは異なる第２ユーザに割り当てたアイドルからなるアイドル群とを含むアイドルユニットを結成することができる。例えば、各アイドルの出身地に基づき、地元密着のアイドルユニットを結成させる。具体的には、ユーザＡ氏にアイドル１を割り当て、ユーザＢ氏にアイドル２を割り当て、ユーザＣ氏にアイドル３を割り当てる。サーバ１は、同一の出身地（例えば、埼玉）であるアイドル１、アイドル２及びアイドル３をアイドルＤＢ１５２から抽出する。サーバ１は、抽出したアイドル１、アイドル２及びアイドル３を含むアイドルユニットを結成させる。
【0174】
または、アイドルを割り当てたユーザの応募により、アイドルユニットを結成することができる。具体的には、サーバ１は、アイドルのレベルまたは属性（体力、楽曲、ダンス、美しさ及び出身地等）を含むアイドルユニットの募集情報を各ユーザ端末３に送信する。各ユーザ端末３は、サーバ１から送信された募集情報に応じて、ユーザによる応募要求を受け付ける。各ユーザ端末３は、受け付けた応募要求をサーバ１に送信する。応募要求には、ユーザＩＤ、アイドルＩＤ、アイドルのレベルまたは属性等が含まれる。サーバ１は、各ユーザ端末３から送信された応募要求を受信する。サーバ１は、受信した応募要求に応じて、例えば、応募者となるアイドルのレベルまたは属性と、募集情報に含まれるレベルまたは属性との一致性の高いアイドルを応募の先着順で複数抽出する。
【0175】
なお、異なる出身地である複数のアイドルを含むアイドルユニットを結成することもできる。なお、アイドルユニットに含まれるアイドルの数は特に限定されるものではない。
【0176】
アイドルユニットを１つのグループとして、ライブ等のミッションを行うことができる。ミッションは、例えば、アイドルユニットに対し、ライブが仮想的な駅の前に開催する「駅前ライブ」である。「駅前ライブ」となるミッションは、アイドルユニットの全員の体力値が所定範囲（例えば、１～各アイドルの体力値の最大値の合計値）内である場合、所定の仮想的な場所（例えば、東京駅または大阪駅）でのアイドルユニットの歌唱を行う。アイドルユニットの歌唱をさせる毎に、当該アイドルユニットに含まれる各アイドルの体力値は消費される。
【0177】
なお、各アイドルユニットの属性、歌唱の時間または楽曲の難易度等に基づいて、異なる消費体力値を設けても良い。例えば、アイドルユニットが楽曲を歌唱させた場合、一定時間の経過（例えば、２０秒）毎に、当該アイドユニットに含まれる各アイドルにおける所定の体力値（例えば、１）を消費しても良い。または、難易度の低い楽曲より、アイドルユニットが難易度の高い楽曲を歌唱させた場合、一定時間の経過毎に、当該アイドユニットに含まれる各アイドルにおける所定の体力値（例えば、１）より多くの体力値（例えば、２）を消費しても良い。
【0178】
歌唱に伴いミッションのクリア条件が成立した場合、歌唱を行ったアイドルユニットのレベルをアップさせる。例えば、アイドルユニットの歌唱に伴い、当該アイドルユニットのファン数が所定のファン数（例えば、１０００人）以上である場合、当該アイドルユニットのレベルをアップさせる。なお、ファン数は、例えば、「駅前ライブ」の開催場所、開催日時、または、歌唱を行うアイドルユニットのレベル等に応じて設けられても良い。
【0179】
「駅前ライブ」となるミッションをクリアした場合、アイドルユニットのレベルをアップさせ、当該アイドルユニットの属性（楽曲またはダンス等）を更新させる。
【0180】
図２０及び図２１は、アイドルユニットの属性を更新する際の処理手順を示すフローチャートである。なお、図１５及び図１６と重複する内容については同一の符号を付して説明を省略する。サーバ１の制御部１１は、ステップＳ１２１の処理を実行した後に、アイドルユニットのユニットＩＤに基づき、当該アイドルユニットの属性（楽曲またはダンス等）を大容量記憶部１５のアイドルユニットＤＢ１５６から取得する（ステップＳ１４１）。
【0181】
制御部１１は、ステップＳ１２３～Ｓ１２４の処理を実行する。制御部１１は、アイドルユニットの全員の体力値を算出する（ステップＳ１４２）。全員の体力値は、アイドルユニットに含まれる各アイドルの体力値の合計値である。制御部１１は、ステップＳ１２５～Ｓ１３１の処理を実行する。
【0182】
制御部１１は、各アイドルユニットのファン数を取得する（ステップＳ１４３）。制御部１１は、複数のアイドルユニットのうち、１つのアイドルユニットのファン数を取得する（ステップＳ１４４）。制御部１１は、取得したアイドルユニットのファン数が所定のファン数を達成したか否かを判定する（ステップＳ１４５）。制御部１１は、アイドルユニットのファン数が所定のファン数を達成していない場合（ステップＳ１４５でＮＯ）、処理を終了する。
【0183】
制御部１１は、アイドルユニットのファン数が所定のファン数を達成した場合（ステップＳ１４５でＹＥＳ）、アイドルユニットのレベルをアップする（ステップＳ１４６）。制御部１１は、アイドルユニットの属性を更新する（ステップＳ１４７）。例えば、制御部１１は、アイドルユニットが歌唱可能な楽曲の増加処理を行っても良い。制御部１１は、アイドルユニットのユニットＩＤに基づき、更新後の属性を大容量記憶部１５のアイドルユニットＤＢ１５６に記憶する。
【0184】
制御部１１は、複数のアイドルユニットのうち、当該アイドルユニットが最後のアイドルユニットであるか否かを判定する（ステップＳ１４８）。制御部１１は、当該アイドルユニットが最後のアイドルユニットである場合（ステップＳ１４８でＹＥＳ）、処理を終了する。制御部１１は、当該アイドルユニットが最後のアイドルユニットでない場合（ステップＳ１４８でＮＯ）、ステップＳ１４４の処理に戻る。
【0185】
本実施形態によると、ユーザに割り当てたアイドルと、当該ユーザとは異なる第２ユーザに割り当てたアイドルからなるアイドル群とを含むアイドルユニットを結成することが可能となる。
【0186】
本実施形態によると、ミッションのクリアによりアイドルユニットの属性を更新することが可能となる。
【0187】
本実施形態によると、アイドルユニットの歌唱に伴い所定の条件が成立した場合、当該アイドルユニットのレベルをアップすることが可能となる。
【0188】
（実施形態４）
実施形態４は、アイドルユニット同士のライブ対戦を実行する形態に関する。なお、実施形態１～３と重複する内容については説明を省略する。所定の仮想的な場所（例えば、新宿駅または大阪駅）でのアイドルユニット同士のライブ対戦を実行することができる。ライブ対戦における各アイドルユニットの総合スコアに基づき、ライブ対戦で優勝したアイドルユニットを決定することができる。
実施形態４は、アイドルユニット同士のライブ対戦を実行する形態に関する。なお、実施形態１～３と重複する内容については説明を省略する。所定の仮想的な場所（例えば、新宿駅または大阪駅）でのアイドルユニット同士のライブ対戦を実行することができる。ライブ対戦における各アイドルユニットの総合スコアに基づき、ライブ対戦で優勝したアイドルユニットを決定することができる。
【0189】
図２２は、実施形態４におけるサーバ１の構成例を示すブロック図である。なお、図１７と重複する内容については同一の符号を付して説明を省略する。大容量記憶部１５には、対戦ＤＢ１５７及びスコアマスタＤＢ１５８が含まれる。対戦ＤＢ１５７は、アイドルユニット同士のライブ対戦に関する情報を記憶している。スコアマスタＤＢ１５８は、属性等の項目に対応するスコアを記憶している。
【0190】
図２３は、対戦ＤＢ１５７及びスコアマスタＤＢ１５８のレコードレイアウトの一例を示す説明図である。
対戦ＤＢ１５７は、対戦ＩＤ列、対戦日時列、対戦場所列、ユニットＩＤ列及び総合スコア列を含む。対戦ＩＤ列は、アイドルユニット同士のライブ対戦を実行した対戦データを識別するために、一意に特定される対戦データのＩＤを記憶している。
対戦ＤＢ１５７は、対戦ＩＤ列、対戦日時列、対戦場所列、ユニットＩＤ列及び総合スコア列を含む。対戦ＩＤ列は、アイドルユニット同士のライブ対戦を実行した対戦データを識別するために、一意に特定される対戦データのＩＤを記憶している。
【0191】
対戦日時列は、アイドルユニット同士のライブ対戦を実行した日時情報を記憶している。対戦場所列は、アイドルユニット同士のライブ対戦を実行した場所を記憶している。ユニットＩＤ列は、対戦を実行した複数のアイドルユニットＩＤを記憶している。総合スコア列は、各アイドルユニットの総合レベルを判定するための総合スコアを記憶している。
【0192】
スコアマスタＤＢ１５８は、種類列、項目列及びスコア列を含む。種類列は、項目の種類（アイドルユニット及びアイドル）を記憶している。項目は、アイドルユニットのフォーメーション及び属性、並びに、アイドルユニットに含まれる各アイドルの属性を含む。項目列は、項目の名称を記憶している。スコア列は、各項目に対応するスコアを記憶している。
【0193】
図２４は、ライブ対戦を実行する画面の一例を示す説明図である。
図２４Ａは、ライブ対戦の受付画面の一例を示す説明図である。当該画面では、第１アイドルユニット表示欄１４ａ、及び第２アイドルユニット表示欄１４ｂを含む。第１アイドルユニット表示欄１４ａは、第１アイドルユニットのデータ及びユニットの名称を表示する表示欄である。第２アイドルユニット表示欄１４ｂは、第２アイドルユニットのデータ及びユニットの名称を表示する表示欄である。
図２４Ａは、ライブ対戦の受付画面の一例を示す説明図である。当該画面では、第１アイドルユニット表示欄１４ａ、及び第２アイドルユニット表示欄１４ｂを含む。第１アイドルユニット表示欄１４ａは、第１アイドルユニットのデータ及びユニットの名称を表示する表示欄である。第２アイドルユニット表示欄１４ｂは、第２アイドルユニットのデータ及びユニットの名称を表示する表示欄である。
【0194】
サーバ１は、ライブ対戦の対戦ＩＤに基づき、ライブ対戦に参加する複数のアイドルユニットのユニットＩＤを対戦ＤＢ１５７から取得する。サーバ１は、取得した各ユニットＩＤに基づき、各アイドルユニットの名称、及び各アイドルユニットに含まれる複数のアイドルのアイドルＩＤをアイドルユニットＤＢ１５６から取得する。サーバ１は、取得した各アイドルＩＤに基づき、各アイドルのデータをアイドルＤＢ１５２から取得する。
【0195】
サーバ１は、各アイドルユニットに含まれる複数のアイドルのデータに基づいて、各アイドルユニットのデータを作成する。サーバ１は、作成した各アイドルユニットのデータ及びユニットの名称をユーザ端末３に送信する。ユーザ端末３は、サーバ１から送信された各アイドルユニットのデータ及びユニットの名称を受信する。ユーザ端末３は、受信した各アイドルユニットのデータ及びユニットの名称を画面に表示する。
【0196】
図示のように、ユーザ端末３は、第１アイドルユニット表示欄１４ａに、「ユニットＡ」であるアイドルユニットのデータ及び名称を表示する。ユーザ端末３は、第２アイドルユニット表示欄１４ｂに、「ユニットＢ」であるアイドルユニットのデータ及び名称を表示する。なお、図２４Ａでは、ライブ対戦にユニットＡ及びユニットＢを参加した例を説明したが、これに限るものではない。ライブ対戦に参加するアイドルユニットの数は特に限定されるものではない。
【0197】
サーバ１は、ライブ対戦の対戦ＩＤに基づき、対戦日時及び対戦場所を対戦ＤＢ１５７から取得する。サーバ１は、対戦日時になると、アイドルユニットの全員の体力値を算出する。全員の体力値は、アイドルユニットに含まれる各アイドルの体力値の合計値である。サーバ１は、算出した全員の体力値が所定範囲（例えば、１～各アイドルの体力値の最大値の合計値）内であるか否かを判定する。
【0198】
サーバ１は、算出した全員の体力値が所定範囲内である場合、アイドルユニットが歌唱可能な楽曲をアイドルユニットＤＢ１５６から取得する。なお、楽曲は、ユーザ端末３側でユーザにより選択されても良い。サーバ１は、取得した楽曲をユーザ端末３に送信（配信）する。ユーザ端末３は、サーバ１から送信された楽曲の再生を開始する。
【0199】
ユーザ端末３は、楽曲の再生が終了していない、且つ、全員の体力値が所定範囲内である場合、楽曲の再生を続ける。サーバ１は、所定の時間間隔（例えば、１０秒）毎に、各アイドルユニットに含まれる各アイドルの消費体力値を取得する。サーバ１は、取得した各アイドルの消費体力値に基づき、各アイドルユニットの全員の体力値を再算出する。
【0200】
サーバ１は、再算出した全員の体力値が所定範囲内である場合、楽曲の配信を続ける。または、サーバ１は、全員の体力値が所定範囲外である場合、楽曲の配信を終了するか、または、ゲームアプリケーション内に設けられている体力回復用のアイテムまたはイベント等によりアイドルユニットの体力を回復させる。サーバ１は、各アイドルユニットの総合スコアに基づき、ライブ対戦で優勝したアイドルユニットを決定する。なお、総合スコアに基づく決定処理に関しては後述する。サーバ１は、ライブ対戦の結果画面（図２４Ｂ）をユーザ端末３に送信する。
【0201】
図２４Ｂは、ライブ対戦の結果画面の一例を示す説明図である。当該画面では、第１アイドルユニット結果表示欄１４ｃ及び第２アイドルユニット結果表示欄１４ｄを含む。第１アイドルユニット結果表示欄１４ｃは、第１アイドルユニットのライブ対戦の結果を表示する表示欄である。第２アイドルユニット結果表示欄１４ｄは、第２アイドルユニットのライブ対戦の結果を表示する表示欄である。
【0202】
ユーザ端末３は、サーバ１から送信されたライブ対戦の結果画面を表示する。図示のように、ユニットＡは優勝したアイドルユニットである。ユニットＡのライブ対戦の結果は第１アイドルユニット結果表示欄１４ｃに表示され、ユニットＢのライブ対戦の結果は第２アイドルユニット結果表示欄１４ｄに表示される。
【0203】
図２５は、優勝アイドルユニットを決定する際の処理手順を示すフローチャートである。サーバ１の制御部１１は、ライブ対戦の対戦ＩＤに基づき、ライブ対戦に参加する複数のアイドルユニットのユニットＩＤを大容量記憶部１５の対戦ＤＢ１５７から取得する（ステップＳ１５１）。制御部１１は、ライブ対戦の対戦ＩＤに基づき、対戦日時及び対戦場所等を含む対戦情報を大容量記憶部１５の対戦ＤＢ１５７から取得する（ステップＳ１５２）。
【0204】
制御部１１は、対戦情報に含まれる対戦日時になるか否かを判定する（ステップＳ１５３）。制御部１１は、対戦日時になっていない場合（ステップＳ１５３でＮＯ）、待機する。制御部１１は、対戦日時になる場合（ステップＳ１５３でＹＥＳ）、アイドルユニット同士のライブ対戦を実行する（ステップＳ１５４）。例えば、制御部１１は、ライブ対戦に参加した各アイドルユニットの全員の体力値を算出する。制御部１１は、算出した各アイドルユニットの全員の体力値が所定範囲内である場合、ライブの仮想的な対戦場所（例えば、新宿駅）で各アイドルユニットを順次に歌唱させる。
【0205】
制御部１１は、各アイドルユニットの総合スコアの初期値を設定する（ステップＳ１５５）。例えば制御部１１は、各アイドルユニットにおける所定の総合スコアの初期値（例えば、０点または１点）を設定しても良い。
【0206】
制御部１１は、総合スコアを変動させる処理のサブルーチンを実行する（ステップＳ１５６）。なお、総合スコアの変動処理のサブルーチンに関しては後述する。制御部１１は、各アイドルユニットの総合スコアに基づき、例えば、総合スコアの一番高いアイドルユニットを優勝したアイドルユニットとして決定する（ステップＳ１５７）。
【0207】
制御部１１は、ライブ対戦の結果を大容量記憶部１５の対戦ＤＢ１５７に記憶する（ステップＳ１５８）。具体的には、制御部１１は、ライブ対戦の対戦ＩＤに基づき、各アイドルユニットの総合スコアを対戦ＤＢ１５７に記憶する。制御部１１は、ライブ対戦の結果を通信部１３によりユーザ端末３に送信する（ステップＳ１５９）。
【0208】
ユーザ端末３の制御部３１は、サーバ１から送信されたライブ対戦の結果を通信部３３により受信する（ステップＳ３５１）。制御部３１は、受信したライブ対戦の結果を表示部３５により表示し（ステップＳ３５２）、処理を終了する。
【0209】
図２６は、総合スコアを変動させる処理のサブルーチンの処理手順を示すフローチャートである。サーバ１の制御部１１は、ライブ対戦の対戦ＩＤに基づき、ライブ対戦に参加する複数のアイドルユニットのユニットＩＤを大容量記憶部１５の対戦ＤＢ１５７から取得する（ステップＳ０１）。制御部１１は、取得した各アイドルユニットのユニットＩＤに基づき、各アイドルユニットのフォーメーション及び属性（楽曲またはダンス等）を大容量記憶部１５のアイドルユニットＤＢ１５６から取得する（ステップＳ０２）。
【0210】
制御部１１は、各アイドルユニットに含まれる各アイドルの属性（体力、楽曲、ダンスまたは美しさ等）を取得する（ステップＳ０３）。具体的には、制御部１１は、各アイドルユニットのユニットＩＤに基づき、各アイドルユニットに含まれる複数のアイドルのアイドルＩＤを大容量記憶部１５のアイドルユニットＤＢ１５６から取得する。制御部１１は、取得した各アイドルのアイドルＩＤに基づき、各アイドルの属性を大容量記憶部１５の割当ＤＢ１５３から取得する。なお、制御部１１は、各アイドルの属性をブロックチェーン２のノード２１から取得しても良い。
【0211】
制御部１１は、取得した各アイドルユニットのフォーメーション及び属性、並びに、各アイドルの属性に対応するスコアを大容量記憶部１５のスコアマスタＤＢ１５８から取得する（ステップＳ０４）。制御部１１は、取得したスコアに基づき、総合スコアを算出する（ステップＳ０５）。制御部１１は、総合スコアの変動処理のサブルーチンを終了してリターンする。
【0212】
例えば、制御部１１は、アイドルユニットのフォーメーションに対応するスコアを、当該アイドルユニットのフォーメーションスコアとして取得する。制御部１１は、アイドルユニットの属性（例えば、楽曲及びダンス）に対応するスコアに基づき、当該アイドルユニットの属性スコア（例えば、楽曲スコア＋ダンススコア）を算出する。
【0213】
制御部１１は、アイドルユニットに含まれる各アイドルの属性（例えば、体力、楽曲、ダンス及び美しさ）に対応するスコアに基づき、各アイドルのスコア（例えば、体力スコア＋楽曲スコア＋ダンススコア＋美しさスコア）を算出する。制御部１１は、各アイドルのスコアの合計を個人スコアとして算出する。制御部１１は、算出したフォーメーションスコアと、アイドルユニットの属性スコアと、個人スコアとの合計を、当該アイドルユニットの総合スコアとして算出する。
【0214】
なお、上述した総合スコアの算出処理に限るものではない。例えば、アイドルユニットのフォーメーション及び属性、並びに、当該アイドルユニットに含まれる各アイドルの属性に対し、比重係数を設けても良い。
【0215】
比重係数は、計算要素（フォーメーション及び属性等）の重要度または影響力等により設定された係数である。影響力が大きいほど、比重係数が大きくなる。例えば、属性において、「楽曲」の影響力が「ダンス」より大きい場合、「楽曲」に対し大きい比重係数（例えば、０．２）が設定され、「ダンス」に対し小さい比重係数（例えば、０．１）が設定されても良い。なお、比重係数は、予め記憶部１２または大容量記憶部１５に記憶されても良い。
【0216】
制御部１１は、ステップＳ０４の処理で取得された各項目に対応するスコアと、各項目の比重係数とに基づいて、各項目の比重係数付きスコア（スコア×比重係数）を算出する。制御部１１は、算出した各項目の比重係数付きスコアの合計を、総合スコアとして算出しても良い。
【0217】
また、アイドルユニットに含まれる各アイドルの出身地と、ライブを開催するライブ会場（開催場所）の客の出身地とに基づき、アイドルユニットの総合スコアを変動させることができる。
【0218】
図２７は、出身地に基づく総合スコアを変動させる処理のサブルーチンの処理手順を示すフローチャートである。なお、図２６と重複する内容については同一の符号を付して説明を省略する。ステップＳ０３の処理で取得された各アイドルの属性には、アイドルの出身地が含まれる。
【0219】
サーバ１の制御部１１は、ステップＳ０５の処理を実行した後に、ライブを開催するライブ会場の客の出身地を取得する（ステップＳ１１）。なお、客の出身地は、仮想的なライブ会場（例えば、新宿駅）に応じて、ゲームアプリケーション内で予め設けられても良い。例えば、ライブ会場が新宿駅である場合、客の出身地は「東京都：６０％、北海道：２０％、福岡県１０％…」等であっても良い。
【0220】
制御部１１は、アイドルの出身地と、一番多いの客の出身地とが一致するか否かを判定する（ステップＳ１２）。制御部１１は、アイドルの出身地と、一番多いの客の出身地とが一致する場合（ステップＳ１２でＹＥＳ）、総合スコアに所定のスコアを加算する（ステップＳ１３）。所定のスコアは、例えば、固定値（例えば、５）、または総合スコアの割合（例えば、５％）等であっても良い。制御部１１は、出身地に基づく総合スコアの変動処理のサブルーチンを終了してリターンする。
【0221】
制御部１１は、アイドルの出身地と、一番多いの客の出身地とが一致していない場合（ステップＳ１２でＮＯ）、総合スコアから所定のスコアを減算する（ステップＳ１４）。制御部１１は、出身地に基づく総合スコアの変動処理のサブルーチンを終了してリターンする。
【0222】
なお、上述した出身地に基づく総合スコアの変動処理は一例であり、出身地に基づく総合スコアの加算または減算のアルゴリズムは限定されない。
【0223】
本実施形態によると、各アイドルユニットの総合スコアに基づき、当該ライブ対戦で勝利したアイドルユニットを決定することが可能となる。
【0224】
本実施形態によると、アイドルユニットのフォーメーション及び属性、並びに、当該アイドルユニットに含まれる各アイドルの属性に基づき、当該アイドルユニットの総合スコアを変動させることが可能となる。
【0225】
本実施形態によると、アイドルユニットに含まれる各アイドルの出身地と、当該ライブを開催するライブ会場の客の出身地とに基づき、当該アイドルユニットの総合スコアを変動させることが可能となる。
【0226】
（実施形態５）
実施形態５は、アイドルのレベル、またはアイドルユニットのレベルに応じたライブ会場でミッションを行う形態に関する。なお、実施形態１～４と重複する内容については説明を省略する。
実施形態５は、アイドルのレベル、またはアイドルユニットのレベルに応じたライブ会場でミッションを行う形態に関する。なお、実施形態１～４と重複する内容については説明を省略する。
【0227】
図２８は、実施形態５におけるミッションＤＢ１５５のレコードレイアウトの一例を示す説明図である。なお、図１３と重複する内容については説明を省略する。ミッションＤＢ１５５は、会場ランク列、アイドルレベル列及びアイドルユニットレベル列を含む。
【0228】
会場ランク列は、ライブを開催する仮想的なライブ会場のランクを記憶している。ライブ会場は、複数のランクを用いて段階的に表わされる。例えば、ランク１～５まで５段階のランクを設けても良い。それぞれのランクには、複数の会場が含まれる。図示のように、ランク４には東京駅及び大阪駅が含まれる。
【0229】
アイドルレベル列は、ライブ会場に対応するアイドルのレベルを記憶している。アイドルユニットレベル列は、ライブ会場に対応するアイドルユニットのレベルを記憶している。
【0230】
以下では、アイドルのレベルに基づきライブ会場を取得する処理を説明するが、アイドルユニットにも同様に適用することができる。
【0231】
サーバ１は、ライブであるミッションの種類、及びアイドルのレベルに基づき、ミッションＩＤ、内容、ライブ会場及びクリア条件等を含むライブ一覧をミッションＤＢ１５５から取得する。サーバ１は、ユーザＩＤ及びアイドルＩＤに基づいて、ブロックチェーン２のノード２１から、当該アイドルの属性（体力値及び楽曲等）を取得する。サーバ１は、取得したライブ一覧及びアイドルの属性をユーザ端末３に送信する。
【0232】
ユーザ端末３、サーバ１から送信されたライブ一覧及びアイドルの属性を受信する。ユーザ端末３は、受信したライブ一覧及びアイドルの属性を表示する。ユーザ端末３は、ライブ一覧からユーザによる歌唱の設定情報を受け付ける。設定情報は、仮想的なライブ会場（例えば、東京駅）、開催日時及び歌唱の楽曲等を含む。ユーザ端末３は、受け付けた歌唱の設定情報をサーバ１に送信する。
【0233】
サーバ１は、ユーザ端末３から送信された歌唱の設定情報に応じて、ライブの開催日時になると、アイドルの体力値が所定範囲内であるか否かを判定する。サーバ１は、アイドルの体力値が所定範囲内である場合、設定情報に含まれるライブ会場で当該アイドルの歌唱を行う。
【0234】
このように、アイドルのレベルまたはアイドルユニットのレベルが高いほど、ライブ会場のランクが高くなる。レベルアップに伴い、上位ランクのライブ会場で所定のミッション（例えば、ライブ）を行うことができる。
【0235】
本実施形態によると、アイドルのレベル、またはアイドルユニットのレベルに応じたライブ会場でミッションを行うことにより、アイドルまたはアイドルユニットを精進させてレベルアップを目指すことが可能となる。
【0236】
今回開示された実施の形態はすべての点で例示であって、制限的なものではないと考えられるべきである。本発明の範囲は、上記した意味ではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味及び範囲内でのすべての変更が含まれることが意図される。
【0237】
各実施形態に記載した事項は相互に組み合わせることが可能である。また、特許請求の範囲に記載した独立請求項及び従属請求項は、引用形式に関わらず全てのあらゆる組み合わせにおいて、相互に組み合わせることが可能である。さらに、特許請求の範囲には他の２以上のクレームを引用するクレームを記載する形式（マルチクレーム形式）を用いているが、これに限るものではない。マルチクレームを少なくとも一つ引用するマルチクレーム（マルチマルチクレーム）を記載する形式を用いて記載しても良い。
【符号の説明】
【0238】
１ 情報処理装置（サーバ）
１１ 制御部
１１ａ ハッシュ値算出部
１１ｂ 電子署名作成部
１２ 記憶部
１３ 通信部
１４ 読取部
１５ 大容量記憶部
１５１ ユーザＤＢ
１５２ アイドルＤＢ
１５３ 割当ＤＢ
１５４ アイドルＮＦＴＤＢ
１５５ ミッションＤＢ
１５６ アイドルユニットＤＢ
１５７ 対戦ＤＢ
１５８ スコアマスタＤＢ
１ａ 可搬型記憶媒体
１ｂ 半導体メモリ
１Ｐ 制御プログラム
２ ブロックチェーンシステム（ブロックチェーン）
２１ ノード
２１１ 制御部
２１２ 記憶部
２１３ 通信部
２１４ 受付部
２１５ 出力部
２１６ ブロック生成部
２１７ ブロック検証部
２１８ ブロック共有部
３ 情報処理端末（ユーザ端末）
３１ 制御部
３１ａ ハッシュ値算出部
３１ｂ 電子署名作成部
３２ 記憶部
３３ 通信部
３４ 入力部
３５ 表示部
３６ マイク
３７ スピーカ
３Ｐ 制御プログラム
１１ 制御部
１１ａ ハッシュ値算出部
１１ｂ 電子署名作成部
１２ 記憶部
１３ 通信部
１４ 読取部
１５ 大容量記憶部
１５１ ユーザＤＢ
１５２ アイドルＤＢ
１５３ 割当ＤＢ
１５４ アイドルＮＦＴＤＢ
１５５ ミッションＤＢ
１５６ アイドルユニットＤＢ
１５７ 対戦ＤＢ
１５８ スコアマスタＤＢ
１ａ 可搬型記憶媒体
１ｂ 半導体メモリ
１Ｐ 制御プログラム
２ ブロックチェーンシステム（ブロックチェーン）
２１ ノード
２１１ 制御部
２１２ 記憶部
２１３ 通信部
２１４ 受付部
２１５ 出力部
２１６ ブロック生成部
２１７ ブロック検証部
２１８ ブロック共有部
３ 情報処理端末（ユーザ端末）
３１ 制御部
３１ａ ハッシュ値算出部
３１ｂ 電子署名作成部
３２ 記憶部
３３ 通信部
３４ 入力部
３５ 表示部
３６ マイク
３７ スピーカ
３Ｐ 制御プログラム
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26】
【図27】
【図28】