(57)【要約】【課題】ユーザとキャラクタとのインタラクティブなコミュニケーションを実現しながらユーザに提示する注文対象を決定できるゲームシステム等の提供。【解決手段】ゲームシステムは、キャラクタを動作させる処理を行うキャラクタ処理部と、注文対象のリストであるメニューの情報を、キャラクタに対応づけて記憶する記憶部と、キャラクタが行った質問に対するユーザの回答を受け付け、ユーザの回答結果に基づき決定された注文対象を、キャラクタを用いてユーザに提示するための処理を行う提示処理部を含む。提示処理部は、第１のキャラクタが行った質問に対するユーザの回答結果及び第２のキャラクタが行った質問に対するユーザの回答結果の少なくとも一方に基づいて、第１のキャラクタに対応するメニューと第２のキャラクタに対応するメニューの少なくとも一方のメニューの中から、ユーザに対して提示する注文対象を決定する処理を行う。【選択図】図１９
2019107081.tif 000002
【特許請求の範囲】
【請求項１】
キャラクタを動作させる処理を行うキャラクタ処理部と、
注文対象のリストであるメニューの情報を、前記キャラクタに対応づけて記憶する記憶部と、
前記キャラクタが行った質問に対するユーザの回答を受け付け、前記ユーザの回答結果に基づき決定された注文対象を、前記キャラクタを用いて前記ユーザに提示するための処理を行う提示処理部と、
を含み、
前記提示処理部は、
第１のキャラクタが行った質問に対する前記ユーザの回答結果及び第２のキャラクタが行った質問に対する前記ユーザの回答結果の少なくとも一方に基づいて、前記第１のキャラクタに対応するメニューと前記第２のキャラクタに対応するメニューの少なくとも一方のメニューの中から、前記ユーザに対して提示する注文対象を決定する処理を行うことを特徴とするゲームシステム。
【請求項２】
請求項１において、
前記提示処理部は、
前記ユーザの回答結果と、前記第１、第２のキャラクタに対する前記ユーザの愛着度情報とに基づき、前記ユーザに提示する注文対象の決定処理を行うことを特徴とするゲームシステム。
【請求項３】
請求項２において、
前記提示処理部は、
前記ユーザの回答結果と前記愛着度情報に基づき決定される注文対象がメニューの中になかった場合に、注文対象の非存在用の処理を行うことを特徴とするゲームシステム。
【請求項４】
請求項２又は３において、
前記提示処理部は、
前記愛着度情報に応じて、前記ユーザに対して行う質問を変化させる処理を行うことを特徴とするゲームシステム。
【請求項５】
請求項２乃至４のいずれかにおいて、
前記提示処理部は、
前記愛着度情報に応じて、前記ユーザに提示する注文対象又はメニューを変化させる処理を行うことを特徴とするゲームシステム。
【請求項６】
請求項２乃至５のいずれかにおいて、
前記提示処理部は、
実店舗又は仮想店舗への前記ユーザの来店回数に応じて、前記愛着度情報により表される愛着度を増加させる処理を行うことを特徴とするゲームシステム。
【請求項７】
請求項２乃至６のいずれかにおいて、
前記提示処理部は、
前記ユーザに対する課金に応じて、前記愛着度情報により表される愛着度を増加させる処理を行うことを特徴とするゲームシステム。
【請求項８】
請求項６又は７において、
前記提示処理部は、
前記キャラクタに対する前記ユーザの愛着度が所与のしきい値を越えた場合に、注文対象に対して付加物を付加する処理を行うことを特徴とするゲームシステム。
【請求項９】
請求項１乃至８のいずれかにおいて、
前記提示処理部は、
実店舗又は仮想店舗への前記ユーザの来店回数、前記ユーザに対する課金、前記ユーザの位置情報、及び日時情報の少なくとも１つを含むユーザ情報を取得し、前記ユーザ情報に応じて、前記ユーザに対して行う質問、前記ユーザに提示するメニュー、メニューに含まれる注文対象、及び前記キャラクタの対話内容の少なくとも１つを設定する処理を行うことを特徴とするゲームシステム。
【請求項１０】
請求項１乃至８のいずれかにおいて、
前記提示処理部は、
実店舗又は仮想店舗への前記ユーザの来店回数、前記ユーザに対する課金、前記ユーザの位置情報、及び日時情報の少なくとも１つを含むユーザ情報を取得し、前記ユーザの回答結果と前記ユーザ情報とに基づき、前記ユーザに提示する注文対象の決定処理を行うことを特徴とするゲームシステム。
【請求項１１】
請求項１０において、
前記提示処理部は、
前記ユーザの回答結果と前記ユーザ情報に基づき決定される注文対象がメニューの中になかった場合に、注文対象の非存在用の処理を行うことを特徴とするゲームシステム。
【請求項１２】
請求項１乃至１１のいずれかにおいて、
仮想空間の設定処理を行う仮想空間設定部と、
前記仮想空間において仮想カメラから見える画像として、前記ユーザが視界を覆うように装着する頭部装着型表示装置の表示画像を生成する表示処理部を含むことを特徴とするゲームシステム。
【請求項１３】
仮想空間の設定処理を行う仮想空間設定部と、
前記仮想空間に登場するキャラクタの処理を行うキャラクタ処理部と、
注文対象のリストであるメニューの情報を記憶する記憶部と、
前記キャラクタが行った質問に対するユーザの回答を受け付け、前記ユーザの回答結果に基づき決定された注文対象を、前記キャラクタを用いて前記ユーザに提示するための処理を行う提示処理部と、
前記仮想空間において前記ユーザの視点に対応する仮想カメラから見える画像として、前記ユーザが視界を覆うように装着する頭部装着型表示装置の表示画像を生成する表示処理部と、
を含むことを特徴とするゲームシステム。
【請求項１４】
請求項１２又は１３において、
前記提示処理部は、
前記キャラクタに対する前記ユーザの注視情報に応じて、前記ユーザに対して行う質問、前記ユーザに提示するメニュー、メニューに含まれる注文対象、及び前記キャラクタの対話内容の少なくとも１つを設定することを特徴とするゲームシステム。
【請求項１５】
キャラクタを動作させる処理を行うキャラクタ処理部と、
注文対象のリストであるメニューの情報を、前記キャラクタに対応づけて記憶する記憶部と、
前記キャラクタが行った質問に対するユーザの回答を受け付け、前記ユーザの回答結果に基づき決定された注文対象を、前記キャラクタを用いて前記ユーザに提示するための処理を行う提示処理部として、
コンピュータを機能させ、
前記提示処理部は、
第１のキャラクタが行った質問に対する前記ユーザの回答結果及び第２のキャラクタが行った質問に対する前記ユーザの回答結果の少なくとも一方に基づいて、前記第１のキャラクタに対応するメニューと前記第２のキャラクタに対応するメニューの少なくとも一方のメニューの中から、前記ユーザに対して提示する注文対象を決定する処理を行うことを特徴とするプログラム。
【請求項１６】
仮想空間の設定処理を行う仮想空間設定部と、
前記仮想空間に登場するキャラクタの処理を行うキャラクタ処理部と、
注文対象のリストであるメニューの情報を記憶する記憶部と、
前記キャラクタが行った質問に対するユーザの回答を受け付け、前記ユーザの回答結果に基づき決定された注文対象を、前記キャラクタを用いて前記ユーザに提示するための処理を行う提示処理部と、
前記仮想空間において前記ユーザの視点に対応する仮想カメラから見える画像として、前記ユーザが視界を覆うように装着する頭部装着型表示装置の表示画像を生成する表示処理部として、
コンピュータを機能させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ゲームシステム及びプログラム等に関する。
【背景技術】
【０００２】
従来より、インターネットを介してユーザに対して各種商品の販売を行うための電子商取引システムが知られている。このような電子商取引システムの従来技術としては特許文献１に開示される技術が知られている。この電子商取引システムでは、インターネット上の仮想店舗をユーザが訪れると、店員キャラクタが登場して商品説明を行う。そしてユーザの注文の受け付けを行ったり、商品の在庫を管理したり、商品の出荷後は、商品の状態及び場所についての情報をユーザ端末に表示する。また特許文献２には、ヘッドマウントディスプレイユニットを装着した消費者が、目次から商品を選択して注文できるシステムが開示されている。このシステムでは、消費者が所定期間以上連続して視線を留めた視点領域を検出し、その視点領域に商品の概要が掲載されている場合には、当該商品の詳細情報を特定領域に表示する。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００１−２８３０５５号公報
【特許文献２】特開２００８−１５６３４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、従来技術のシステムは、ユーザが購入を所望する商品を正確に特定し、当該商品の注文を受け付けてユーザに購入させることを目的としている。従って、仮想店舗に登場する店員キャラクタは、商品の内容をユーザに正確に伝えるために商品説明を行うだけであり、キャラクタに対するユーザの思い入れや、キャラクタが擬人として有している性格や特徴は何ら考慮されていなかった。このためユーザと店員キャラクタの間の関係は面白味の無い無味乾燥なものになってしまい、ユーザとキャラクタとのインタラクティブなコミュニケーションを実現できなかった。また仮想店舗に登場してユーザとコミュニケーションを行う店員キャラクタは一人だけであり、複数のキャラクタとユーザとのインタラクティブなコミュニケーションに関しては全く考慮されていなかった。
【０００５】
本発明の幾つかの態様によれば、ユーザとキャラクタとのインタラクティブなコミュニケーションを実現しながらユーザに提示する注文対象を決定できるゲームシステム及びプログラム等を提供できる。
【課題を解決するための手段】
【０００６】
本発明の一態様は、キャラクタを動作させる処理を行うキャラクタ処理部と、注文対象のリストであるメニューの情報を、前記キャラクタに対応づけて記憶する記憶部と、前記キャラクタが行った質問に対するユーザの回答を受け付け、前記ユーザの回答結果に基づき決定された注文対象を、前記キャラクタを用いて前記ユーザに提示するための処理を行う提示処理部と、を含み、前記提示処理部は、第１のキャラクタが行った質問に対する前記ユーザの回答結果及び第２のキャラクタが行った質問に対する前記ユーザの回答結果の少なくとも一方に基づいて、前記第１のキャラクタに対応するメニューと前記第２のキャラクタに対応するメニューの少なくとも一方のメニューの中から、前記ユーザに対して提示する注文対象を決定する処理を行うゲームシステムに関係する。また本発明は、上記各部としてコンピュータを機能させるプログラム、又は該プログラムを記憶したコンピュータ読み取り可能な情報記憶媒体に関係する。
【０００７】
本発明の一態様では、キャラクタの質問に対するユーザの回答が受け付けられ、回答結果に基づき決定された注文対象が、キャラクタを用いてユーザに提示される。そしてキャラクタとして第１、第２のキャラクタが登場し、第１のキャラクタの質問に対する回答結果及び第２のキャラクタの質問に対する回答結果の少なくとも一方に基づいて、第１、第２のキャラクタに対応するメニューの少なくとも一方のメニューの中から、注文対象が決定されて、ユーザに対して提示される。このようにすれば、第１のキャラクタや第２のキャラクタが質問してユーザが回答するというようなインタラクティブなコミュニケーションが行われ、このコミュニケーションにおけるユーザの回答結果に応じた注文対象が、メニューの中から決定されて、ユーザに提示されるようになる。従って、ユーザとキャラクタとのインタラクティブなコミュニケーションを実現しながらユーザに提示する注文対象を決定できるゲームシステム等の実現が可能になる。
【０００８】
また本発明の一態様では、前記提示処理部は、前記ユーザの回答結果と、前記第１、第２のキャラクタに対する前記ユーザの愛着度情報とに基づき、前記ユーザに提示する注文対象の決定処理を行ってもよい。
【０００９】
このようにすれば、キャラクタに対する愛着度情報に応じてユーザに提示する注文対象が変化するようになり、愛着度情報を反映させた注文対象の決定処理を実現できる。
【００１０】
また本発明の一態様では、前記提示処理部は、前記ユーザの回答結果と前記愛着度情報に基づき決定される注文対象がメニューの中になかった場合に、注文対象の非存在用の処理を行ってもよい。
【００１１】
このようにすれば、ユーザに提示する注文対象がメニューの中にないような状況が発生した場合にも、注文対象の非存在用の処理を行うことで、これに対応できるようになる。
【００１２】
また本発明の一態様では、前記提示処理部は、前記愛着度情報に応じて、前記ユーザに対して行う質問を変化させる処理を行ってもよい。
【００１３】
このようにすれば、キャラクタに対する愛着度に応じて、キャラクタがユーザに対して行う質問が多様に変化するようになり、ユーザにとって、より飽きが来にくいゲームシステム等の実現が可能になる。
【００１４】
また本発明の一態様では、前記提示処理部は、前記愛着度情報に応じて、前記ユーザに提示する注文対象又はメニューを変化させる処理を行ってもよい。
【００１５】
このようにすれば、キャラクタに対する愛着度に応じて、ユーザに提示する注文対象やメニューが変化するようになり、ユーザにとって、より飽きが来にくいゲームシステム等の実現が可能になる。
【００１６】
また本発明の一態様では、前記提示処理部は、実店舗又は仮想店舗への前記ユーザの来店回数に応じて、前記愛着度情報により表される愛着度を増加させる処理を行ってもよい。
【００１７】
このようにすれば、愛着度の変化が動機づけとなって、実店舗や仮想店舗へのユーザの来店を促すことが可能になる。
【００１８】
また本発明の一態様では、前記提示処理部は、前記ユーザに対する課金に応じて、前記愛着度情報により表される愛着度を増加させる処理を行ってもよい。
【００１９】
このようにすれば、課金の対価を支払うことの効果的な動機づけを、ユーザに与えることが可能になる。
【００２０】
また本発明の一態様では、前記提示処理部は、前記キャラクタに対する前記ユーザの愛着度が所与のしきい値を越えた場合に、注文対象に対して付加物を付加する処理を行ってもよい。
【００２１】
このようにすれば、愛着度がしきい値を超えることで、ユーザは、注文対象のみならず付加物も取得できるようになるため、愛着度を高めることの効果的な動機づけをユーザに与えることが可能になる。
【００２２】
また本発明の一態様では、前記提示処理部は、実店舗又は仮想店舗への前記ユーザの来店回数、前記ユーザに対する課金、前記ユーザの位置情報、及び日時情報の少なくとも１つを含むユーザ情報を取得し、前記ユーザ情報に応じて、前記ユーザに対して行う質問、前記ユーザに提示するメニュー、メニューに含まれる注文対象、及び前記キャラクタの対話内容の少なくとも１つを設定する処理を行ってもよい。
【００２３】
このようにすれば、ユーザの来店回数、ユーザに対する課金、位置情報又は日時情報などのユーザ情報に応じて、キャラクタの愛着度を様々に変化させたり、質問、メニュー、商品又は対話内容を様々に変化させることが可能になる。
【００２４】
また本発明の一態様では、提示処理部は、実店舗又は仮想店舗への前記ユーザの来店回数、前記ユーザに対する課金、前記ユーザの位置情報、及び日時情報の少なくとも１つを含むユーザ情報を取得し、前記ユーザの回答結果と前記ユーザ情報とに基づき、前記ユーザに提示する注文対象の決定処理を行ってもよい。
【００２５】
このようにすれば、ユーザの来店回数、ユーザに対する課金、位置情報又は日時情報などのユーザ情報に応じて、ユーザに提示する注文対象が変化するようになり、ユーザ情報を反映させた注文対象の決定処理を実現できる。
【００２６】
また本発明の一態様では、前記提示処理部は、前記ユーザの回答結果と前記ユーザ情報に基づき決定される注文対象がメニューの中になかった場合に、注文対象の非存在用の処理を行ってもよい。
【００２７】
このようにすれば、ユーザの回答結果とユーザ情報に基づき決定される注文対象がメニューの中にないような状況が発生した場合にも、注文対象の非存在用の処理を行うことで、これに対応できるようになる。
【００２８】
また本発明の一態様では、仮想空間の設定処理を行う仮想空間設定部と、前記仮想空間において仮想カメラから見える画像として、前記ユーザが視界を覆うように装着する頭部装着型表示装置の表示画像を生成する表示処理部を含んでもよい（仮想カメラ設定部と表示処理部としてコンピュータを機能させてもよい）。
【００２９】
このようにすれば、頭部装着型表示装置により実現されるＶＲ空間に登場するキャラクタと、ユーザとのインタラクティブなコミュニケーションを実現しながら、ユーザに提示する注文対象を決定できるゲームシステムの実現が可能になる。
【００３０】
また本発明の一態様は、仮想空間の設定処理を行う仮想空間設定部と、前記仮想空間に登場するキャラクタの処理を行うキャラクタ処理部と、注文対象のリストであるメニューの情報を記憶する記憶部と、前記キャラクタが行った質問に対するユーザの回答を受け付け、前記ユーザの回答結果に基づき決定された注文対象を、前記キャラクタを用いて前記ユーザに提示するための処理を行う提示処理部と、前記仮想空間において前記ユーザの視点に対応する仮想カメラから見える画像として、前記ユーザが視界を覆うように装着する頭部装着型表示装置の表示画像を生成する表示処理部と、を含むゲームシステムに関係する。また本発明は、上記各部としてコンピュータを機能させるプログラム、又は該プログラムを記憶したコンピュータ読み取り可能な情報記憶媒体に関係する。
【００３１】
本発明の一態様では、仮想空間が設定され、仮想空間に登場するキャラクタの質問に対するユーザの回答が受け付けられ、回答結果に基づき決定された注文対象が、キャラクタを用いてユーザに提示される。そして、このときのキャラクタや仮想空間の様子が、ＶＲ空間の画像として頭部装着型表示装置に表示されるようになる。これにより、頭部装着型表示装置により実現されるＶＲ空間に登場するキャラクタと、ユーザとのインタラクティブなコミュニケーションを実現しながら、ユーザに提示する注文対象を決定できるゲームシステム等の実現が可能になる。
【００３２】
また本発明の一態様では、前記提示処理部は、前記キャラクタに対する前記ユーザの注視情報に応じて、前記ユーザに対して行う質問、前記ユーザに提示するメニュー、メニューに含まれる注文対象、及び前記キャラクタの対話内容の少なくとも１つを設定してもよい。
【００３３】
このようにすれば、ユーザの注視状況を反映させた多様な処理を実現できるようになる。
【図面の簡単な説明】
【００３４】
【図１】本実施形態のゲームシステムの構成例を示すブロック図。
【図２】本実施形態に用いられるＨＭＤの一例。
【図３】ユーザが訪れるＶＲカフェの説明図。
【図４】ユーザが訪れるＶＲカフェの説明図。
【図５】図５（Ａ）、図５（Ｂ）はキャラクタとユーザとの対話処理の説明図。
【図６】図６（Ａ）、図６（Ｂ）はキャラクタとユーザとの対話処理の説明図。
【図７】図７（Ａ）、図７（Ｂ）は複数のキャラクタとユーザとの対話処理の説明図。
【図８】複数のキャラクタとユーザとの対話処理の説明図。
【図９】図９（Ａ）〜図９（Ｃ）はメニューの中からユーザに提示する商品を決定する処理の具体例についての説明図。
【図１０】キャラクタ情報や愛着度についての説明図。
【図１１】図１１（Ａ）、図１１（Ｂ）はキャラクタに対するユーザの愛着度の設定処理の説明図。
【図１２】メニューの中にお勧め商品がなかった場合にお勧め商品非存在用の処理を行う処理例のフローチャート。
【図１３】図１３（Ａ）、図１３（Ｂ）はお勧め商品非存在用の処理の一例の説明図。
【図１４】愛着度に応じて質問を変化させる処理のフローチャート。
【図１５】愛着度に応じて新商品、新メニューを発生させる処理のフローチャート。
【図１６】来店回数に応じて愛着度を設定する処理の説明図。
【図１７】図１７（Ａ）、図１７（Ｂ）はユーザへの課金に応じて愛着度を設定する処理の説明図。
【図１８】ユーザの来店回数、課金額、位置情報、日時情報に応じて、キャラクタに対するユーザの愛着度を設定したり、質問、メニューに含まれる商品、対話内容を設定する処理のフローチャート。
【図１９】本実施形態の詳細な処理例を説明するフローチャート。
【図２０】本実施形態の詳細な処理例を説明するフローチャート。
【発明を実施するための形態】
【００３５】
以下、本実施形態について説明する。なお、以下に説明する本実施形態は、特許請求の範囲に記載された本発明の内容を不当に限定するものではない。また本実施形態で説明される構成の全てが、本発明の必須構成要件であるとは限らない。
【００３６】
１．ゲームシステム
図１は、本実施形態のゲームシステム（シミュレーションシステム、シミュレータ）の構成例を示すブロック図である。本実施形態のゲームシステムは、例えばバーチャルリアリティ（ＶＲ）をシミュレートするシステムに適用できる。なお、本実施形態のゲームシステムは図１の構成に限定されず、その構成要素（各部）の一部（例えば仮想空間設定部、仮想カメラ制御部等）を省略したり、他の構成要素を追加するなどの種々の変形実施が可能である。
【００３７】
操作部１６０は、ユーザ（プレーヤ）が種々の操作情報（入力情報）を入力するためのものである。操作部１６０は、例えば操作ボタン、方向指示キー、ジョイスティック、ハンドル、ペダル又はレバー等の種々の操作デバイスにより実現できる。
【００３８】
記憶部１７０は各種の情報を記憶する。記憶部１７０は、処理部１００や通信部１９６などのワーク領域として機能する。ゲームプログラムや、ゲームプログラムの実行に必要なゲームデータは、この記憶部１７０に保持される。記憶部１７０の機能は、半導体メモリ（ＤＲＡＭ、ＶＲＡＭ）、ＨＤＤ（ハードディスクドライブ）、ＳＳＤ、光ディスク装置などにより実現できる。記憶部１７０は、オブジェクト情報記憶部１７２、キャラクタ情報記憶部１７４、会話情報記憶部１７５、メニュー情報記憶部１７６、描画バッファ１７８を含む。
【００３９】
情報記憶媒体１８０（コンピュータにより読み取り可能な媒体）は、プログラムやデータなどを格納するものであり、その機能は、光ディスク（ＤＶＤ、ＢＤ、ＣＤ）、ＨＤＤ、或いは半導体メモリ（ＲＯＭ）などにより実現できる。処理部１００は、情報記憶媒体１８０に格納されるプログラム（データ）に基づいて本実施形態の種々の処理を行う。即ち情報記憶媒体１８０には、本実施形態の各部としてコンピュータ（入力装置、処理部、記憶部、出力部を備える装置）を機能させるためのプログラム（各部の処理をコンピュータに実行させるためのプログラム）が記憶される。
【００４０】
表示部１９０は、本実施形態により生成された画像を出力するものであり、その機能は、後述する図２のＨＭＤ（頭部装着型表示装置）、ＬＣＤ、有機ＥＬディスプレイ、或いはＣＲＴなどにより実現できる。音出力部１９２は、本実施形態により生成された音を出力するものであり、その機能は、スピーカ、或いはヘッドフォンなどにより実現できる。
【００４１】
Ｉ／Ｆ（インターフェース）部１９４は、携帯型情報記憶媒体１９５とのインターフェース処理を行うものであり、その機能はＩ／Ｆ処理用のＡＳＩＣなどにより実現できる。携帯型情報記憶媒体１９５は、ユーザが各種の情報を保存するためのものであり、電源が非供給になった場合にもこれらの情報の記憶を保持する記憶装置である。携帯型情報記憶媒体１９５は、ＩＣカード（メモリカード）、ＵＳＢメモリ、或いは磁気カードなどにより実現できる。
【００４２】
通信部１９６（通信インターフェース）は、有線や無線のネットワークを介して外部（他の装置）との間で通信を行うものであり、その機能は、通信用ＡＳＩＣ又は通信用プロセッサなどのハードウェアや、通信用ファームウェアにより実現できる。
【００４３】
なお本実施形態の各部としてコンピュータを機能させるためのプログラム（データ）は、サーバ（ホスト装置）が有する情報記憶媒体からネットワーク及び通信部１９６を介して情報記憶媒体１８０（あるいは記憶部１７０）に配信してもよい。このようなサーバ（ホスト装置）による情報記憶媒体の使用も本発明の範囲内に含めることができる。
【００４４】
処理部１００（プロセッサ）は、操作部１６０からの操作情報や、後述する図２のＨＭＤ２００（頭部装着型表示装置）でのトラッキング情報（ＨＭＤの位置及び方向の少なくとも一方の情報。視点位置及び視線方向の少なくとも一方の情報）や、プログラムなどに基づいて、キャラクタ処理、提示処理、仮想空間設定処理、仮想カメラ制御処理、ゲーム処理、表示処理、或いは音処理などを行う。
【００４５】
処理部１００の各部が行う本実施形態の各処理（各機能）はプロセッサ（ハードウェアを含むプロセッサ）により実現できる。例えば本実施形態の各処理は、プログラム等の情報に基づき動作するプロセッサと、プログラム等の情報を記憶するメモリにより実現できる。プロセッサは、例えば各部の機能が個別のハードウェアで実現されてもよいし、或いは各部の機能が一体のハードウェアで実現されてもよい。例えば、プロセッサはハードウェアを含み、そのハードウェアは、デジタル信号を処理する回路及びアナログ信号を処理する回路の少なくとも一方を含むことができる。例えば、プロセッサは、回路基板に実装された１又は複数の回路装置（例えばＩＣ等）や、１又は複数の回路素子（例えば抵抗、キャパシター等）で構成することもできる。プロセッサは、例えばＣＰＵ（Central Processing Unit）であってもよい。但し、プロセッサはＣＰＵに限定されるものではなく、ＧＰＵ（Graphics Processing Unit）、或いはＤＳＰ（Digital Signal Processor）等、各種のプロセッサを用いることが可能である。またプロセッサはＡＳＩＣによるハードウェア回路であってもよい。またプロセッサは、アナログ信号を処理するアンプ回路やフィルター回路等を含んでもよい。メモリ（記憶部１７０）は、ＳＲＡＭ、ＤＲＡＭ等の半導体メモリであってもよいし、レジスターであってもよい。或いはハードディスク装置（ＨＤＤ）等の磁気記憶装置であってもよいし、光学ディスク装置等の光学式記憶装置であってもよい。例えば、メモリはコンピュータにより読み取り可能な命令を格納しており、当該命令がプロセッサにより実行されることで、処理部１００の各部の処理（機能）が実現されることになる。ここでの命令は、プログラムを構成する命令セットでもよいし、プロセッサのハードウェア回路に対して動作を指示する命令であってもよい。
【００４６】
処理部１００は、入力処理部１０２、演算処理部１１０、出力処理部１４０を含む。演算処理部１１０は、キャラクタ処理部１１２、提示処理部１１４、仮想空間設定部１１６、仮想カメラ制御部１１７、ゲーム処理部１１、表示処理部１２０、音処理部１３０を含む。上述したように、これらの各部により実行される本実施形態の各処理は、プロセッサ（或いはプロセッサ及びメモリ）により実現できる。なお、これらの構成要素（各部）の一部を省略したり、他の構成要素を追加するなどの種々の変形実施が可能である。
【００４７】
入力処理部１０２は、操作情報やトラッキング情報を受け付ける処理や、記憶部１７０から情報を読み出す処理や、通信部１９６を介して情報を受信する処理を、入力処理として行う。例えば入力処理部１０２は、操作部１６０を用いてユーザが入力した操作情報やＨＭＤのセンサ部等により検出されたトラッキング情報を取得する処理や、読み出し命令で指定された情報を、記憶部１７０から読み出す処理や、外部装置（サーバ等）からネットワークを介して情報を受信する処理を、入力処理として行う。ここで受信処理は、通信部１９６に情報の受信を指示したり、通信部１９６が受信した情報を取得して記憶部１７０に書き込む処理などである。
【００４８】
演算処理部１１０は、各種の演算処理を行う。例えばキャラクタ処理、提示処理、仮想空間設定処理、仮想カメラ制御処理、ゲーム処理（シミュレーション処理）、表示処理、或いは音処理などの演算処理を行う。
【００４９】
キャラクタ処理部１１２（キャラクタ処理のプログラムモジュール）はキャラクタについての種々の処理を行う。提示処理部１１４（提示処理のプログラムモジュール）は、注文対象の提示処理などの種々の処理を行う。キャラクタ処理部１１２、提示処理部１１４の詳細については後述する。
【００５０】
仮想空間設定部１１６（仮想空間設定処理のプログラムモジュール）は、複数のオブジェクトが配置される仮想空間（オブジェクト空間）の設定処理を行う。例えば、キャラクタ（人、ロボット、モンスター又は動物等）、マップ（地形）、建物、観客席、コース（道路）、樹木、壁、水面などの表示物を表す各種オブジェクト（ポリゴン、自由曲面又はサブディビジョンサーフェイスなどのプリミティブ面で構成されるオブジェクト）を仮想空間に配置設定する処理を行う。即ちワールド座標系でのオブジェクトの位置や回転角度（向き、方向と同義）を決定し、その位置（Ｘ、Ｙ、Ｚ）にその回転角度（Ｘ、Ｙ、Ｚ軸回りでの回転角度）でオブジェクトを配置する。具体的には、記憶部１７０のオブジェクト情報記憶部１７２には、仮想空間でのオブジェクト（パーツオブジェクト）の位置、回転角度、移動速度、移動方向等の情報であるオブジェクト情報がオブジェクト番号に対応づけて記憶される。仮想空間設定部１１６は、例えば各フレーム毎にこのオブジェクト情報を更新する処理などを行う。
【００５１】
仮想カメラ制御部１１７は、ユーザの視点に対応する仮想カメラの制御処理を行う。例えば仮想カメラ制御部１１７は、ユーザの一人称視点として設定される仮想カメラの制御を行う。例えば実空間のユーザに対応する仮想空間の仮想ユーザの視点に対応する位置に、仮想カメラを設定して、仮想カメラの視点位置や視線方向を設定することで、仮想カメラの位置（位置座標）や姿勢（回転軸回りでの回転角度）を制御する。そして表示処理部１２０は、表示部１９０（ＨＭＤ等）の表示画像（表示映像）として、仮想空間において仮想カメラ（ユーザ視点）から見える画像を生成する。例えば仮想空間であるオブジェクト空間において所与の視点から見える画像を生成する。生成される画像は例えば立体視用の画像である。
【００５２】
ゲーム処理部１１８（ゲーム処理のプログラムモジュール）はユーザがゲームをプレイするための種々のゲーム処理を行う。別の言い方をすれば、ゲーム処理部１１８（シミュレーション処理部）は、ユーザが仮想現実（バーチャルリアリティ）を体験するための種々のシミュレーション処理を実行する。ゲーム処理は、例えば、ゲーム開始条件が満たされた場合にゲームを開始する処理、開始したゲームを進行させる処理、ゲーム終了条件が満たされた場合にゲームを終了する処理、或いはゲーム成績を演算する処理などである。
【００５３】
表示処理部１２０（表示処理のプログラムモジュール）は、ゲーム画像（シミュレーション画像）の表示処理を行う。例えば処理部１００で行われる種々の処理（ゲーム処理、シミュレーション処理）の結果に基づいて描画処理を行い、これにより画像を生成し、表示部１９０に表示する。具体的には、座標変換（ワールド座標変換、カメラ座標変換）、クリッピング処理、透視変換、或いは光源処理等のジオメトリ処理が行われ、その処理結果に基づいて、描画データ（プリミティブ面の頂点の位置座標、テクスチャ座標、色データ、法線ベクトル或いはα値等）が作成される。そして、この描画データ（プリミティブ面データ）に基づいて、透視変換後（ジオメトリ処理後）のオブジェクト（１又は複数プリミティブ面）を、描画バッファ１７８（フレームバッファ、ワークバッファ等のピクセル単位で画像情報を記憶できるバッファ）に描画する。これにより、オブジェクト空間（仮想空間）において仮想カメラ（所与の視点。左目用、右目用の第１、第２の視点）から見える画像が生成される。なお、表示処理部１２０で行われる描画処理は、頂点シェーダ処理やピクセルシェーダ処理等により実現することができる。
【００５４】
音処理部１３０（音処理のプログラムモジュール）は、処理部１００で行われる種々の処理の結果に基づいて音処理を行う。具体的には、楽曲（音楽、ＢＧＭ）、効果音、又は音声などのゲーム音を生成し、ゲーム音を音出力部１９２に出力させる。
【００５５】
出力処理部１４０は各種の情報の出力処理を行う。例えば出力処理部１４０は、記憶部１７０に情報を書き込む処理や、通信部１９６を介して情報を送信する処理を、出力処理として行う。例えば出力処理部１４０は、書き込み命令で指定された情報を、記憶部１７０に書き込む処理や、外部の装置（サーバ等）に対してネットワークを介して情報を送信する処理を行う。送信処理は、通信部１９６に情報の送信を指示したり、送信する情報を通信部１９６に指示する処理などである。
【００５６】
そして本実施形態のゲームシステムは、図１に示すようにキャラクタ処理部１１２と記憶部１７０と提示処理部１１４を含む。
【００５７】
キャラクタ処理部１１２はキャラクタを動作（行動）させる処理を行う。具体的にはゲーム空間においてキャラクタを動作させたり移動させる処理を行う。例えばキャラクタ処理部１１２は、記憶部１７０のキャラクタ情報記憶部１７４に記憶されるキャラクタ情報に基づいて、ゲーム空間においてキャラクタを行動させるための種々の処理を行う。例えばキャラクタが仮想空間に登場するオブジェクトである場合には、キャラクタ処理部１１２は、仮想空間に登場するキャラクタ（移動体）についての種々の処理を行う。例えばキャラクタ処理部１１２は、操作部１６０によりユーザが入力した操作情報や、取得されたトラッキング情報や、プログラム（移動・動作アルゴリズム）や、各種データ（モーションデータ）などに基づいて、キャラクタ（モデルオブジェクト）を仮想空間内で移動させたり、キャラクタを動作（モーション、アニメーション）させる制御処理を行う。具体的には、キャラクタの移動情報（位置、回転角度、速度、或いは加速度）や動作情報（パーツオブジェクトの位置、或いは回転角度）を、１フレーム（例えば１／６０秒）毎に順次求めるシミュレーション処理を行う。なおフレームは、キャラクタの移動・動作処理（シミュレーション処理）や画像生成処理を行う時間の単位である。
【００５８】
またキャラクタ処理部１１２は、キャラクタとユーザの対話処理を行う。例えばキャラクタがユーザに対して会話（質問）するための種々の処理を行う。具体的には、キャラクタ処理部１１２は、記憶部１７０の会話情報記憶部１７５に記憶されるキャラクタの会話情報（質問情報）に基づいて、キャラクタの発話の音声を音出力部１９２に出力させたり、キャラクタの会話内容を表示部１９０に表示させる処理を行う。またキャラクタの会話情報であるシナリオ情報に基づいて、各種のシナリオに応じた会話の分岐処理を行う。
【００５９】
記憶部１７０は、注文対象のリストであるメニューの情報を記憶する。具体的にはメニュー情報記憶部１７６が、メニューの情報をキャラクタに対応づけて記憶する。例えばキャラクタ情報記憶部１７４には、ゲームに登場する複数のキャラクタについてのキャラクタ情報が記憶されている。メニュー情報記憶部１７６（広義には記憶部）は、これらの複数のキャラクタの各キャラクタに対応づけてメニュー情報を記憶する。メニューには、複数の注文対象がリスト形式で対応づけられている。このメニューは、表示物としてユーザに表示されるものであってもよく、この場合には複数の注文対象がメニューに表示される画像がユーザに表示される。
【００６０】
注文対象は、例えばユーザが購入する商品である。注文対象である商品としては、食べ物、衣服、装飾品、靴、玩具、ゲーム関連商品、家電製品、カメラ等の映像機器、スマートフォン等の携帯通信端末、パーソナルコンピュータ、時計、本、家具、キッチン用品、インテリア用品、食品、ＣＤ、ＤＶＤ、スポーツ関連商品、アウトドア関連商品、生活雑貨関連商品、或いは住宅関連商品などの種々の商品を想定できる。また注文対象は、ユーザに提供されるサービス（役務）であってもよい。例えば注文対象であるサービスとしては、宿泊等の旅行関連のサービス、アミューズメントやホビー関連のサービス、保険関連のサービス、食品関連のサービス、催し関連のサービス、美容やヘルス関連のサービス、住宅関連のサービス、引っ越し関連のサービス、或いはスポーツ関連のサービスなどの種々のサービスを想定できる。また注文対象は、実空間の商品やサービスには限定されず、仮想空間（ゲーム空間、ネットワーク）での仮想的な商品、サービスであってもよい。このような仮想空間の注文対象としては、ゲームのアイテム、ゲームに登場するキャラクタ、ゲームカード等のゲーム媒体、或いは仮想空間でのＶＲ体験のサービスなどの種々のものを想定できる。
【００６１】
提示処理部１１４は、注文対象について提示処理を行う。例えば提示処理部１１４は、キャラクタが行った質問に対するユーザの回答を受け付ける。そしてユーザの回答結果に基づき決定された注文対象を、キャラクタを用いてユーザに提示するための処理を行う。例えばユーザの回答結果に基づき決定された注文対象（お勧めの注文対象）を、キャラクタがユーザに対して提示するための処理を行う。例えばキャラクタが会話を行うことで、決定された注文対象をユーザに提示する。ユーザに提示する注文対象の決定処理は、注文対象決定部１１５が行う。
【００６２】
具体的には本実施形態では、ゲーム空間（仮想空間）に第１、第２のキャラクタを含む複数のキャラクタが登場する。そして提示処理部１１４は、第１のキャラクタが行った質問に対するユーザの回答や、第２のキャラクタが行った質問に対するユーザの回答を受け付ける。そして提示処理部１１４は、第１のキャラクタが行った質問に対するユーザの回答結果及び第２のキャラクタが行った質問に対するユーザの回答結果の少なくとも一方に基づいて、第１のキャラクタに対応するメニューと第２のキャラクタに対応するメニューの少なくとも一方のメニューの中から、ユーザに対して提示する注文対象を決定する処理を行う。例えば第１のキャラクタが行った質問に対するユーザの回答結果と、第２のキャラクタが行った質問に対するユーザの回答結果の両方に基づいて、ユーザに対して提示する注文対象を決定する。或いは、第１のキャラクタが行った質問に対するユーザの回答結果と、第２のキャラクタが行った質問に対するユーザの回答結果の一方に基づいて、ユーザに対して提示する注文対象を決定してもよい。例えば第１、第２のキャラクタの一方のキャラクタのみがユーザに対して質問し、当該質問に対するユーザの回答結果に基づいて、第１のキャラクタに対応するメニューと第２のキャラクタに対応するメニューのいずれかから、ユーザに対して提示する注文対象を決定してもよい。そして提示処理部１１４は、決定された注文対象を、キャラクタを用いてユーザに提示するための処理を行う。なお第１のキャラクタに対応するメニューと第２のキャラクタに対応するメニューは違ったメニューである必要は無く、例えば一部においてリストされる注文対象が共通であってもよい。例えば第１のキャラクタに対応するメニューと第２のキャラクタに対応するメニューの一方のメニューから、ユーザに対して提示する注文対象を決定してもよいし、両方のメニューから、ユーザに対して提示する注文対象を決定してもよい。
【００６３】
ユーザは、例えば音声により、質問に対する回答を入力してもよいし、操作部１６０のキー入力やタッチパネルのタッチ操作などにより、回答を入力してもよい。音声で回答が入力された場合には、提示処理部１１４は、例えば回答の会話の音声認識処理を行い、例えば回答の会話内容をテキストデータ等の会話データとして取得する。例えばユーザの音声から音響モデルに基づき音素列を抽出し、音素列から単語候補を推定する。そして推定された単語候補から言語モデルに基づいて音声の会話内容の認識処理を行って、回答の会話データを取得する。キー入力やタッチ操作により回答が入力された場合には、キー入力やタッチ操作の操作情報に基づいて、回答の会話データを取得する。そして提示処理部１１４は、取得された回答の会話データに基づいて、キャラクタが行った質問に対するユーザの回答結果を判断する。この場合に例えば質問に対する回答を、複数の選択肢として用意しておき、ユーザがどの選択肢を回答として選択したかを判断することで、質問に対するユーザの回答結果を判断してもよい。こうすることで、より簡素な処理で、質問に対するユーザの回答結果を判断できる。
【００６４】
そして提示処理部１１４は、このようにして判断されたユーザの回答結果に基づいて、例えば複数の注文対象のリストであるメニューの中から、ユーザに提示する注文対象を決定する。例えば、ユーザへのお勧めの注文対象を決定する。そして、決定された注文対象を、キャラクタを用いてユーザに提示する。この注文対象の提示は、キャラクタの音声による会話により行ってもよいし、表示部１９０に注文対象を表示することで提示してもよい。例えば、ユーザへのお勧めの注文対象を、キャラクタが音声の会話により喋ったり、お勧めの注文対象の文字等が表示された吹き出し形式の画像等を表示部１９０に表示する。
【００６５】
またユーザに提示する注文対象（お勧めの注文対象）の決定処理としては種々の処理を想定できる。例えばメニューは第１〜第Ｍの注文対象（Ｍは２以上の整数）のリストとなっている。そしてキャラクタはユーザに対して第１〜第Ｎ（Ｎは２以上の整数）の質問を行う。そして第１〜第Ｎの質問の各質問に対して、ユーザがどのような回答を行ったかに応じて、メニューの第１〜第Ｍの注文対象の各注文対象に対して重み付けポイントを付与する。一例としては、第１〜第Ｎの質問の各質問に対して複数の選択肢が用意されており、質問に対する回答として、ユーザがどの選択肢を選択したかに応じて、メニューの第１〜第Ｍの注文対象の各注文対象に対して重み付けポイントを付与する。そしてキャラクタによる第１〜第Ｎの質問が終了すると、第１〜第Ｍの注文対象の各注文対象について、重み付けポイントの合算値を求め、求められた合算値に基づいて、第１〜第Ｍの注文対象の中から、ユーザに提示する注文対象（お勧めの注文対象）を決定して、ユーザに提示する。但し、ユーザに提示する注文対象の決定処理は、上記のような処理に限定されず、種々の変形実施が可能である。例えば第１〜第Ｎの質問に対するユーザの回答を入力とするテーブル、或いは、当該回答を入力とする所定の関数を用意して、当該テーブル又は関数に基づいて、ユーザに提示する注文対象を決定してもよい。例えばユーザに提示する注文対象の決定処理は、キャラクタの第１〜第Ｎの質問に対するユーザの回答が同じであれば、同じ注文対象が一意に決定されるような処理である。
【００６６】
また提示処理部１１４は、ユーザの回答結果と、キャラクタに対するユーザの愛着度情報とに基づき、ユーザに提示する注文対象の決定処理を行う。例えば、ユーザの回答結果と、第１、第２のキャラクタに対するユーザの愛着度情報とに基づき、ユーザに提示する注文対象の決定処理を行う。例えばユーザが質問に対して回答した場合に、その回答結果に基づいて、第１、第２のキャラクタに対応するメニューのうち、愛着度が高いキャラクタに対応するメニューの中から、ユーザに提示する注文対象を決定する。また例えば上述の重み付けポイントの演算の際にキャラクタの愛着度情報を用いてもよい。
【００６７】
愛着度情報は、例えばキャラクタに対するユーザの愛着度の度合いを表すパラメータであり、愛着度の指標となるパラメータである。例えば愛着度情報は、ユーザが種々の操作や種々の行動を行うことで変化するキャラクタの特定のパラメータということができる。例えば下述するように、ユーザが、そのキャラクタを推しキャラクタとして選択したり、そのキャラクタを注視するような操作や行動を行うことで、当該キャラクタの愛着度に対応するパラメータが変化する。また、ユーザが、そのキャラクタと会うために実店舗や仮想店舗に来店したり、そのキャラクタのために課金アイテムを購入するなどして課金に対して対価を支払うと、当該キャラクタの愛着度に対応するパラメータが変化する。またユーザの位置が、そのキャラクタの位置に近づいたり、そのキャラクタのキャンペーン期間や、そのキャラクタ用の特別の日や特別の時間帯になると、当該キャラクタの愛着度に対応するパラメータが変化する。愛着度情報は、このようなユーザの操作や行動で変化するパラメータである。また愛着度情報は、ゲームパラメータの１つである愛着度パラメータとして、キャラクタ処理部１１２、提示処理部１１４、或いはゲーム処理部１１８の各処理に使用される。この愛着度情報は例えばキャラクタに対応づけて記憶部１７０に記憶される。例えば複数のキャラクタが登場する場合に、複数のキャラクタの各キャラクタに対するユーザの愛着度情報が記憶部１７０に記憶される。例えば第１のキャラクタに対するユーザの愛着度情報と第２のキャラクタに対するユーザの愛着度情報が記憶部１７０に記憶される。例えば愛着度情報はキャラクタに対応づけてキャラクタ情報としてキャラクタ情報記憶部１７４に記憶される。或いは複数のキャラクタの各キャラクタに対する愛着度情報を、ユーザ情報として記憶部１７０に記憶してもよい。
【００６８】
例えば複数のキャラクタの中からユーザが推しキャラクタを選択すると、提示処理部１１４は、その推しキャラクタの愛着度を増加させる処理を行う。例えば第１、第２のキャラクタのうちの一方のキャラクタが推しキャラクタとして選択されると、その推しキャラクタの愛着度を増加させる処理を行う。またキャラクタが質問をしている時に、ユーザが、タッチパネルディスプレイにおいてキャラクタをタッチしたり、ＨＭＤ等によりユーザを注視していたことが検出された場合に、提示処理部１１４は、当該キャラクタに対する愛着度を増加させる処理を行う。この場合に、タッチ時間、タッチしている場所、注視時間、或いは注視している場所に応じて、愛着度を増加させたり、減少させたり、増加値又は減少値の大きさを制御してもよい。
【００６９】
また提示処理部１１４は、ユーザの回答結果と愛着度情報に基づき決定される注文対象がメニューの中になかった場合に、注文対象の非存在用の処理を行う。例えばユーザの回答結果とキャラクタの愛着度情報に応じた最適な商品等の注文対象がなかった場合には、特別な処理を行う。例えば注文対象の決定処理において、メニューのリストにある第１〜第Ｍの注文対象の各注文対象に対して、ユーザの回答結果や愛着度情報に応じたポイントを付与する。例えば上記したような重み付けポイントのようなポイントを付与する。そしてキャラクタによる第１〜第Ｎの質問が終了した際に、当該ポイントが所定のしきい値に達していなかった場合には、決定すべき注文対象（最適な注文対象）がメニュー（第１、第２のキャラクタの少なくとも一方のメニュー）の中になかったと判定する。そして提示処理部１１４は、注文対象の非存在用の処理を行う。
【００７０】
注文対象の非存在用の処理は、決定すべき注文対象がメニューになかった場合のために特別に用意された処理である。例えば注文対象の非存在用の処理としては、以下のような処理が考えられる。例えば注文対象の非存在用の処理は、第１のキャラクタ（例えばユーザの推しキャラクタ）が、第２のキャラクタのメニューの注文対象を選択するように誘導する会話を行わせる処理である。或いは、注文対象の非存在用の処理は、決定すべき注文対象が、推しキャラクタのメニューではなく、別のキャラクタのメニューにあった場合に、そのメニューの中から注文対象を決定する処理（ユーザに選択させる処理）である。この場合の別のキャラクタは、ユーザの目の前に登場していないキャラクタであってもよい。或いは、注文対象の非存在用の処理は、基本のメニューとは別に、ユーザに知らされていない裏メニューがあり、その裏メニューの中から注文対象を決定する処理である。
【００７１】
また提示処理部１１４は、愛着度情報に応じて、ユーザに対して行う質問を変化させる処理を行う。例えば第１、第２のキャラクタの少なくとも一方がユーザに対して行う質問を、愛着度情報に応じて変化させる。具体的には愛着度情報に応じて、第１、第２のキャラクタの少なくとも一方のキャラクタがユーザに対して行う質問の内容を変化させたり、質問の回数を増加又は減少させたり、質問の態様を変化させる。例えば愛着度が増加すると、それに応じて、キャラクタの質問に対するユーザの回答の選択肢が増えるようにする。或いは愛着度が増加すると、キャラクタの質問回数が増えるようにする。或いは愛着度が増加すると、それに応じて、質問の会話に分岐が追加されるようにする。例えば質問の会話のシナリオを増やす処理を行う。或いは、登場する第１、第２のキャラクタが質問を行う回数を、愛着度に応じて変化させる。例えば第１、第２のキャラクタのうち、ユーザの愛着度が高い方のキャラクタの質問回数を増加させる。
【００７２】
また提示処理部１１４は、愛着度情報に応じて、ユーザに提示する注文対象又はメニューを変化させる処理を行う。例えば第１、第２のキャラクタの少なくとも一方が提示する注文対象を愛着度情報に応じて変化させたり、第１、第２のキャラクタのメニュー自体を愛着度情報に応じて変化させる。例えばキャラクタに対する愛着度が所定のしきい値を超えたことを条件に出現するような注文対象やメニューを用意する。例えば所定の注文対象については、愛着度が所定のしきい値を超えないと、当該注文対象をキャラクタが提示しないようにする（勧めないようにする）。或いは、愛着度が所与のしきい値を超えると、通常とは異なる特別のメニューを出現させ、この特別のメニューの中から注文対象を決定して、ユーザに提示する。
【００７３】
また提示処理部１１４は、実店舗又は仮想店舗へのユーザの来店回数に応じて、愛着度情報により表される愛着度を増加させる処理を行う。例えば来店回数が増えるにつれて、当該実店舗又は仮想店舗に登場するキャラクタに対する愛着度を増加させる処理を行う。例えば愛着度を来店回数に応じて段階的に増加させる。例えば実店舗又は仮想店舗へのユーザの来店回数の情報を、ユーザ情報に関連づけて登録する。この来店回数の情報を含むユーザ情報を、図１の携帯型情報記憶媒体１９５に記憶しておき、次の来店時に来店回数を更新するようにしてもよい。或いはインターネット等のネットワークを介して店舗（店舗の管理装置）と通信接続されるサーバ（サーバシステム）のデータベース（記憶部）に、来店回数の情報を含むユーザ情報を記憶しておき、次の来店時に当該データベースにアクセスして、来店回数を更新するようにしてもよい。なお実店舗は、例えばＨＭＤを用いたＶＲのシステムなどにおいてユーザが訪れる現実世界（実空間）の店舗である。仮想店舗は、例えばインターネットで利用可能なショッピングサイトなどにある仮想的な店舗である。
【００７４】
また提示処理部１１４は、ユーザに対する課金に応じて、愛着度情報により表される愛着度を増加させる処理を行う。例えばユーザに対する課金に対してユーザが対価を支払うと、特定のキャラクタに対するユーザの愛着度を増加させる。例えばユーザが推しキャラクタを指定して課金の対価を支払うと、例えば課金額等に応じて当該推しキャラクタに対するユーザの愛着度を増加させる。課金の支払いは、ゲーム内通貨で行ってもよいし、現実の通貨によって行ってもよい。また課金アイテム等を購入することによってユーザが課金に対する対価を支払うようにしてもよい。例えば、ユーザが、所望のキャラクタを指定して、課金アイテムであるプレゼントをそのキャラクタに渡すと、そのキャラクタに対する愛着度を増加させる。例えば課金アイテムを渡したキャラクタは、ユーザの推しキャラクタであると判断して、愛着度を増加させる。この場合の愛着度は、例えばユーザが実店舗又は仮想店舗を訪れた際のキャラクタに対する愛着度の初期値（オフセット値）であってもよい。課金に対する支払いによって、キャラクタの愛着度の初期値が増加すると、上述したような愛着度に応じた種々の処理（例えば質問、注文対象又はメニュー等を変化させる処理）において、よりユーザにとって有利な展開になる。
【００７５】
また提示処理部１１４は、キャラクタに対するユーザの愛着度が所与のしきい値を越えた場合に、注文対象に対して付加物を付加する処理を行う。例えば、愛着度が所与のしきい値を越えると、ユーザに提示する注文対象に付加物を付加して提示する。即ち、注文対象に付加物を加えてユーザに提示する。或いは、ユーザに対して注文対象を提示し、その注文対象をユーザが注文した場合に、注文対象と付加物をユーザに付与するようにする。付加物は、例えば注文対象のおまけとなるものである。注文対象が商品である場合に、付加物はおまけの商品である。
【００７６】
また提示処理部１１４は、ユーザ及びキャラクタに関連する外部情報に基づいて、キャラクタの愛着度情報を変化させる処理を行う。例えばユーザ及びキャラクタに関連する外部情報として、連動するゲーム（キャラクタが登場するゲーム）の情報や、キャラクタに関連する商品についてのユーザの購入情報（購入履歴情報）を外部から取得（ネットワーク等を介して取得）する。そしてゲームの情報や商品の購入情報などの外部情報に応じて、愛着度情報により表される愛着度（パラメータ）を変化させる。
【００７７】
また提示処理部１１４は、実店舗又は仮想店舗へのユーザの来店回数、ユーザに対する課金、ユーザの位置情報、及び日時情報の少なくとも１つを含むユーザ情報を取得する。そしてユーザ情報に応じて、ユーザに対して行う質問、ユーザに提示するメニュー、メニューに含まれる注文対象、及びキャラクタの対話内容の少なくとも１つを設定する処理を行う。例えば来店回数、課金、位置情報又は日時情報などのユーザ情報に応じて、質問、メニュー、注文対象又は対話内容を変化させる。ユーザの来店回数やユーザに対する課金については、前述した通りである。ユーザの位置情報は、例えば携帯通信端末の位置センサー（ＧＰＳ等）により判断してもよいし、ユーザがどの店舗に居るかによって判断してもよい。日時情報は、ユーザがゲームをプレイしている日時の情報（時刻、日にち等）である。提示処理部１１４は、来店回数、課金、位置情報又は日時情報に応じて、質問の内容や回数を変化させたり、メニューの種類や内容を変化させたり、メニューに含まれる注文対象の種類や数を変化させたり、或いはキャラクタがユーザに対して行う会話の内容や会話の分岐などを変化させる。
【００７８】
また提示処理部１１４は、実店舗又は仮想店舗へのユーザの来店回数、ユーザに対する課金、ユーザの位置情報、及び日時情報の少なくとも１つを含むユーザ情報を取得する。そしてユーザの回答結果とユーザ情報とに基づき、ユーザに提示する注文対象の決定処理を行う。例えばユーザが質問に対して回答した場合に、その回答結果と、ユーザの来店回数、課金額、位置情報又は日時情報などのユーザ情報に基づいて、ユーザに提示する注文対象を決定する。即ち、メニューの中から、ユーザに提示する注文対象を決定する際に、ユーザの来店回数、課金額、位置情報又は日時情報などのユーザ情報を反映させて、ユーザに提示する注文対象を決定する。例えば来店回数が多いか少ないか、課金額が多いか、少ないか、ユーザがどの場所にいるか、或いは、ユーザがゲームをプレイしている時刻や日にちなどに応じて、メニューの中から選択するユーザに提示する注文対象を変化させる。
【００７９】
また提示処理部１１４は、ユーザの回答結果とユーザ情報に基づき決定される注文対象がメニューの中になかった場合に、注文対象の非存在用の処理を行う。例えばユーザの回答結果とユーザ情報に応じた最適な商品等の注文対象がなかった場合には、特別な処理を行う。例えば注文対象の決定処理において、メニューのリストにある第１〜第Ｍの注文対象の各注文対象に対して、ユーザの回答結果やユーザ情報に応じたポイントを付与する。例えば上記したような重み付けポイントのようなポイントを付与する。そしてキャラクタによる第１〜第Ｎの質問が終了した際に、当該ポイントが所定のしきい値に達していなかった場合には、決定すべき注文対象（最適な注文対象）がメニュー（第１、第２のキャラクタの少なくとも一方のメニュー）の中になかったと判定する。そして提示処理部１１４は、注文対象の非存在用の処理を行う。注文対象の非存在用の処理としては、上述のような種々の処理が考えられる。
【００８０】
また本実施形態のゲームシステムは、図１に示すように、仮想空間の設定処理を行う仮想空間設定部１１６と、仮想空間に登場するキャラクタの処理を行うキャラクタ処理部１１２と、注文対象のリストであるメニューの情報を記憶する記憶部１７０と、提示処理部１１４と表示処理部１２０を含む。そして提示処理部１１４は、キャラクタが行った質問に対するユーザの回答を受け付け、ユーザの回答結果に基づき決定された注文対象を、キャラクタを用いてユーザに対して提示する処理を行う。また表示処理部１２０は、仮想空間において仮想カメラから見える画像として、ユーザが視界を覆うように装着するＨＭＤ２００（図２）の表示画像を生成する。
【００８１】
例えば仮想カメラ制御部１１７は、ユーザの視点情報のトラッキング情報に基づいて、ユーザの視点変化に追従するように仮想カメラを制御する。具体的には入力処理部１０２（入力受け付け部）は、ＨＭＤ２００を装着するユーザの視点情報のトラッキング情報を取得する。例えばユーザの視点位置、視線方向の少なくとも１つである視点情報のトラッキング情報（視点トラッキング情報）を取得する。このトラッキング情報は、例えばＨＭＤ２００のトラッキング処理を行うことで取得できる。なおトラッキング処理によりユーザの視点位置、視線方向を直接に取得するようにしてもよい。一例としては、トラッキング情報は、ユーザの初期視点位置からの視点位置の変化情報（視点位置の座標の変化値）、及び、ユーザの初期視線方向からの視線方向の変化情報（視線方向の回転軸回りでの回転角度の変化値）の少なくとも一方を含むことができる。このようなトラッキング情報が含む視点情報の変化情報に基づいて、ユーザの視点位置や視線方向（ユーザの頭部の位置、姿勢の情報）を特定できる。
【００８２】
そして仮想カメラ制御部１１７は、取得されたトラッキング情報（ユーザの視点位置及び視線方向の少なくとも一方の情報）に基づいて仮想カメラの視点位置、視線方向を変化させる。例えば、仮想カメラ制御部１１７は、実空間でのユーザの視点位置、視線方向の変化に応じて、仮想空間での仮想カメラの視点位置、視線方向（位置、姿勢）が変化するように、仮想カメラを設定する。このようにすることで、ユーザの視点情報のトラッキング情報に基づいて、ユーザの視点変化に追従するように仮想カメラを制御できる。
【００８３】
このようにすれば、いわゆるＶＲのシステムにおいて、例えば３次元オブジェクトで表されるキャラクタが仮想空間に登場して、当該キャラクタがユーザに対して質問を行うようになる。そして、キャラクタの質問に対してユーザが回答すると、回答結果に基づき決定された注文対象を、３次元オブジェクトで表されるキャラクタが、例えばお勧めの注文対象としてユーザに提示するようになる。このようにすることで、ユーザは、あたかも本物の人物から質問を受けて、その質問の回答結果に応じた注文対象を、当該人物が勧めてくるような仮想現実を体験できるようになる。これによりユーザの仮想現実感の向上を図れる。
【００８４】
またこの場合に提示処理部１１４は、キャラクタに対するユーザの注視情報に応じて、ユーザに対して行う質問、ユーザに提示するメニュー、メニューに含まれる注文対象、及びキャラクタの対話内容の少なくとも１つを設定してもよい。例えばキャラクタに対する注視情報に応じて、質問、メニュー、注文対象又は対話内容を変化させる。ここでユーザの注視情報は、前述したようなＨＭＤ２００等を利用して取得されたトラッキング情報に基づいて判断できる。そしてユーザが注視しているキャラクタ、注視時間又は注視場所に応じて、質問、メニュー、注文対象又は対話内容を変化させる。例えばユーザが複数のキャラクタ（第１、第２のキャラクタ）のうちのいずれのキャラクタを注視しているかに応じて、質問、メニュー、注文対象又は対話内容を変化させる。或いは、ユーザが注視している時間を注視時間として測定したり、ユーザがキャラクタのどの場所（部位）を注視しているのかを検出し、注視時間や注視している場所（部位）に応じて、質問、メニュー、注文対象又は対話内容を変化させる。
【００８５】
なお図１の本実施形態のゲームシステムの処理は、店舗等の施設に設置されるＰＣ等の処理装置、ユーザが所持するスマートフォン等の携帯通信端末、家庭用ゲーム装置、或いは業務用ゲーム装置などの種々の端末装置により実現できる。或いは本実施形態のゲームシステムの処理を、ネットワークを介して端末装置と通信接続されるサーバシステムにより実現したり、サーバシステムと端末装置の分散処理により実現してもよい。
【００８６】
２．ＨＭＤ、トラッキング処理
次に本実施形態の手法をＶＲのシステムに適用した場合に用いられるＨＭＤ２００や、ＨＭＤ２００を用いたトラッキング処理について説明する。
【００８７】
図２にＨＭＤ２００の一例を示す。図２に示すように、ユーザＵＳは、視界を覆うようにＨＭＤ２００を装着して、ＶＲの世界を楽しむ。図２ではユーザはヘッドフォン２７０を装着しており、これによりキャラクタの質問等の会話を聞くことができる。また不図示のマイク等を設けて、ユーザが音声入力をできるようにしてもよい。
【００８８】
ＨＭＤ２００は、センサ部や表示部や処理部を含むことができる。なおＨＭＤ２００に発光素子を設ける変形実施も可能である。センサ部は、例えばヘッドトラッキングなどのトラッキング処理を実現するためものである。例えばセンサ部を用いたトラッキング処理により、ＨＭＤ２００の位置、方向を特定する。ＨＭＤ２００の位置、方向が特定されることで、ユーザの視点位置、視線方向を特定できる。
【００８９】
トラッキング方式としては種々の方式を採用できる。トラッキング方式の一例である第１のトラッキング方式では、ＨＭＤ２００に設けられるセンサ部として複数の受光素子（フォトダイオード等）を設ける。そして外部に設けられた発光素子（ＬＥＤ等）からの光（レーザー等）をこれらの複数の受光素子により受光することで、現実世界の３次元空間でのＨＭＤ２００（ユーザの頭部）の位置、方向を特定する。第２のトラッキング方式では、複数の発光素子（ＬＥＤ）をＨＭＤ２００に設ける。そして、これらの複数の発光素子からの光を、外部に設けられた撮像部で撮像することで、ＨＭＤ２００の位置、方向を特定する。第３のトラッキング方式では、センサ部としてモーションセンサを設け、このモーションセンサを用いてＨＭＤ２００の位置、方向を特定する。モーションセンサは例えば加速度センサやジャイロセンサなどにより実現できる。例えば３軸の加速度センサと３軸のジャイロセンサを用いた６軸のモーションセンサを用いることで、現実世界の３次元空間でのＨＭＤ２００の位置、方向を特定できる。なお、第１のトラッキング方式と第２のトラッキング方式の組合わせ、或いは第１のトラッキング方式と第３のトラッキング方式の組合わせなどにより、ＨＭＤ２００の位置、方向を特定してもよい。またＨＭＤ２００の位置、方向を特定することでユーザの視点位置、視線方向を特定するのではなく、ユーザの視点位置、視線方向を直接に特定するトラッキング処理を採用してもよい。
【００９０】
ＨＭＤ２００の表示部は例えば有機ＥＬディスプレイ（ＯＥＬ）や液晶ディスプレイ（ＬＣＤ）などにより実現できる。例えばＨＭＤ２００の表示部には、ユーザの左眼の前に設定される第１のディスプレイ又は第１の表示領域と、右眼の前に設定される第２のディスプレイ又は第２の表示領域が設けられており、立体視表示が可能になっている。立体視表示を行う場合には、例えば視差が異なる左眼用画像と右眼用画像を生成し、第１のディスプレイに左眼用画像を表示し、第２のディスプレイに右眼用画像を表示する。或いは１つのディスプレイの第１の表示領域に左眼用画像を表示し、第２の表示領域に右眼用画像を表示する。またＨＭＤ２００には左眼用、右眼用の２つの接眼レンズ（魚眼レンズ）が設けられており、これによりユーザの視界の全周囲に亘って広がるＶＲ空間が表現される。そして接眼レンズ等の光学系で生じる歪みを補正するための補正処理が、左眼用画像、右眼用画像に対して行われる。
【００９１】
またＨＭＤ２００として、いわゆるスマートフォンＶＲ又はＶＲゴーグルと呼ばれるタイプのものを用いてもよい。このタイプのＨＭＤ２００では、スマートフォンの表示部がユーザの目に対向するように、図２のゴーグル部の中にスマートフォンを収納する。ゴーグル部（ＶＲゴーグル）の内側には、左眼用接眼レンズ、右眼用接眼レンズが内蔵されている。ユーザは、スマートフォンの表示部に表示された左眼用画像、右眼用画像を、各々、左眼用接眼レンズ、右眼用接眼レンズを介して見ることで、ＶＲの立体視画像を鑑賞することができる。そしてユーザの視点位置、視線方向を特定するトラッキング処理は、スマートフォンに内蔵されるモーションセンサ（加速度センサ、ジャイロセンサ）などに基づいて実現できる。そしてこの場合には本実施形態のゲームシステムは、スマートフォンにインストールされるアプリケーションのプログラムとスマートフォンのハードウェアとにより実現されることになる。
【００９２】
３．本実施形態の手法
次に本実施形態の手法について詳細に説明する。なお、以下では、注文対象が、食べ物などの商品である場合について主に説明するが、本実施形態の注文対象は、現実世界の商品以外にも、現実世界のサービスや、仮想空間での仮想的な商品やサービスであってもよい。また以下では、ＨＭＤに画像が表示されるゲームシステムに本実施形態の手法を適用した場合を主に例にとり説明するが、ＨＭＤ以外の表示部にゲーム画像が表示されるゲームシステムに対しても本実施形態の手法は適用可能である。
【００９３】
３．１  ＶＲカフェ
本実施形態ではユーザは、ＶＲのカフェ（カフェバー）に訪れ、そのカフェにいるキャラクタとのインタラクティブなコミュニケーションを楽しむ。キャラクタは、例えばゲームメーカなどが販売する有名なゲームソフトに登場するキャラクタであり、ユーザは、ＶＲカフェにおいて、このゲームのキャラクタとの会話などを楽しむことができる。
【００９４】
図３は、ユーザが訪れる仮想的なカフェであるＶＲカフェを示す図である。ユーザが図２のＨＭＤ２００を装着すると、図３に示すようなＶＲカフェの画像がユーザに表示される。ユーザがＨＭＤ２００を装着することで、ユーザの全周囲の方向に亘って、仮想空間（ＶＲ空間）の世界が広がっている。例えばＨＭＤ２００を装着したユーザが前方向を向けば、仮想空間において前方向に見える画像がＨＭＤ２００に表示され、ユーザが右方向を向けば、仮想空間において右方向に見える画像がＨＭＤ２００に表示される。これにより、あたかも本当に仮想空間の中に入り込んだかのような仮想現実感をユーザに与えることができる。また本実施形態では、例えば現実世界の店舗と提携して、このＶＲカフェのシステムを実現してもよい。例えば現実世界の店舗を模擬したＶＲカフェを仮想空間に構築する。そしてユーザは、その店舗に訪れて、ＨＭＤ２００を装着することで、その店舗に対応するＶＲカフェの様子をＨＭＤ２００を介して見ることができる。
【００９５】
ユーザが図３のＶＲカフェを訪れると、店長である女性のキャラクタや、ゲームに登場するキャラクタがユーザを迎えてくれる。ユーザは図３のＡ１に示すカウンターの椅子に腰掛けて、キャラクタとの会話を楽しむ。例えば図４では、ユーザＵＳの両サイドに、キャラクタＣＨＡ、ＣＨＢが訪れており、ユーザＵＳはキャラクタＣＨＡ、ＣＨＢに挟まれる形でカウンターの椅子に座っている。そしてユーザＵＳは、ＶＲ空間のキャラクタＣＨＡ、ＣＨＢとのインタラクティブなコミュニケーションを楽しむ。
【００９６】
本実施形態では、ＶＲ空間のキャラクタがユーザに向かってコミュニケーションをしてくれる。例えばユーザの推しキャラクタなどが、おもむろに自分の隣に座ってくれる。そして、キャラクタが、ユーザの気分をくんで、ＶＲカフェのメニューの中から、お勧めの商品（食べ物）を選んでくれる。例えばユーザが、キャラクタに差し入れをすれば（課金アイテムを購入すれば）、キャラクタからお礼のファンサービスを受けることができる。
【００９７】
例えば図５（Ａ）では、キャラクタＣＨＡがユーザＵＳの隣にやって来て、ユーザＵＳの代わりにメニューの商品を決めることを提案している。具体的には図５（Ｂ）に示すようにキャラクタＣＨＡがユーザＵＳに対して質問する。キャラクタＣＨＡは、有名なゲームであるＲＰＧに登場するキャラクタであるため、ゲームに関連する質問を行っている。具体的には、ＲＰＧのマップにおいて街に訪れた時の宝箱の集め方について質問している。具体的には、キャラクタＣＨＡは、質問に対する回答の選択肢を提示し、ユーザＵＳはその選択肢の中から選ぶことで、質問に対して回答する。ユーザＵＳが回答すると、図６（Ａ）に示すようにキャラクタＣＨＡは次の質問をする。具体的には、戦闘前に行う準備について質問している。この場合も回答として３つの選択肢が提示されており、ユーザＵＳは、その選択肢の中から選ぶことで、質問に対して回答する。
【００９８】
このようにして、キャラクタＣＨＡがユーザＵＳに対して次々と質問をして行く。この質問は、ユーザＵＳがメニューの中から選ぶ商品とは直接的な関係は無く、キャラクタＣＨＡが登場するゲームに関連する質問が行われる。そして全ての質問が終わると、図６（Ｂ）に示すように、キャラクタＣＨＡに対応するメニューの中から、ユーザＵＳにお勧めの商品（食べ物）をキャラクタＣＨＡが提示する。キャラクタＣＨＡのメニューは、スイーツに関するメニューであり、そのメニューの中から、図６（Ｂ）では特製デザートプレートをお勧め商品としてユーザＵＳに提示している。ユーザＵＳは、自身が愛着しているキャラクタＣＨＡ（推しキャラクタ）からのお勧めであるため、喜んでその商品を注文する。具体的には、例えばユーザＵＳは、ＶＲカフェに対応する現実世界の店舗において、キャラクタＣＨＡから勧められた商品（特製デザートプレート）を注文する。
【００９９】
また本実施形態ではユーザＵＳとインタラクティブなコミュニケーションを行うキャラクタとして、複数のキャラクタが登場する。例えば図７（Ａ）では、二人のキャラクタＣＨＡ、ＣＨＢがユーザＵＳの席に来て、ユーザＵＳを挟むように話しかけている。これらのキャラクタＣＨＡ、ＣＨＢは、同じゲーム（ＲＰＧ）に登場するキャラクタである。ユーザＵＳは、例えばキャラクタＣＨＡ、ＣＨＢのいずれか一方を、自身の推しキャラクタとして選択することができる。
【０１００】
図７（Ａ）では、キャラクタＣＨＡがケーキ派であり、キャラクタＣＨＢがプリン派であることを、ユーザＵＳに伝えている。従って、キャラクタＣＨＡは、例えばケーキのメニューの中からお勧め商品を選び、キャラクタＣＨＢは、例えばプリンのメニューの中からお勧め商品を選ぶことになる。
【０１０１】
図７（Ｂ）ではキャラクタＣＨＡが、ゲームにおいて欲しい装備がある時にユーザＵＳがとる行動について、質問している。具体的には、回答となる３つの選択肢が提示され、ユーザＵＳは、その中から、欲しい装備があるときには資金集めを行うという選択肢を選択している。この時、もう一方のキャラクタＣＨＢは、ユーザＵＳの回答に対応するような会話（「やっぱり世の中はお金だよな」）を行う。このようにユーザＵＳの回答に対してキャラクタＣＨＢの会話が連動することで、インタラクティブなコミュニケーションとしての会話の楽しみをユーザＵＳに与えることができる。
【０１０２】
このようにして、本実施形態では、キャラクタＣＨＡ、ＣＨＢがユーザＵＳに対して次々と質問をする。この場合にキャラクタＣＨＡ、ＣＨＢの両方のキャラクタがユーザＵＳに対して質問をするようにしてもよいし、一方のキャラクタだけがユーザＵＳに対して質問をするようにしてもよい。一方のキャラクタだけが質問をする場合には、例えば図７（Ｂ）に示すように、他方のキャラクタはユーザＵＳの回答に相槌を打つなどして、会話を盛り上げる立場となる。
【０１０３】
そして全ての質問が終わると、図８に示すようにキャラクタＣＨＡ、ＣＨＢは、自身のメニューの中からお勧め商品を選択してユーザＵＳに提示する。例えばケーキ派のキャラクタＣＨＡは、自身のケーキのメニューの中から特製フルーツタルトを、お勧め商品としてユーザＵＳに提示している。またプリン派のキャラクタＣＨＢは、自身のプリンのメニューの中からチョコバナナプリンを、お勧め商品としてユーザＵＳに提示している。例えばユーザＵＳにとっては、キャラクタＣＨＢが推しキャラクタであるため、キャラクタＣＨＢが勧めた商品を注文することを決める。そしてユーザＵＳは、現実世界の店舗において、キャラクタＣＨＢから勧められた商品（チョコバナナプリン）を注文する。なお、キャラクタＣＨＡ、ＣＨＢの両方のキャラクタが、自身のメニューの中からお勧め商品を提示してもよいし、一方のキャラクタ（例えばユーザの推しキャラクタ）のみが、自身のメニューの中からお勧め商品を提示してもよい。またキャラクタＣＨＡ、ＣＨＢが、一部又は全部が共通のメニューの中からお勧め商品を選択して提示するようにしてもよい。
【０１０４】
３．２  メニューの中からの注文対象の提示
以上のように本実施形態は、ＶＲカフェでユーザが注文をする際に、単純に紙のメニューから選ぶのではなく、複数のキャラクタとの会話を楽しんでいる間に、キャラクタがメニューの中から、お勧めの注文対象である商品を決めてくれるシステムとなっている。具体的には、ユーザがキャラクタの質問に回答しながら、注文する商品を決めるイベントにおいて、キャラクタはお勧め商品が登録されているメニューのテーブルを持っている。そしてキャラクタとして第１のキャラクタと第２のキャラクタが登場し、キャラクタからユーザに質問の内容が提示される。そしてユーザの回答結果に応じて、キャラクタはメニューテーブルの中から、お勧め商品となる最適な商品を選んでユーザに提示する。
【０１０５】
具体的には本実施形態では、図５（Ａ）〜図６（Ｂ）に示すように仮想空間（ゲーム空間）でキャラクタＣＨＡを動作させる。例えば仮想空間においてキャラクタＣＨＡはユーザＵＳの位置に移動し、ユーザＵＳに対して会話するなどの動作を行う。またキャラクタＣＨＡが提示する商品（広義には注文対象）のリストであるメニューの情報は、記憶部１７０に記憶されている。そして図５（Ｂ）、図６（Ａ）に示すように、キャラクタＣＨＡが一連の質問を行う。ユーザＵＳがこれに回答すると、図６（Ｂ）に示すようにキャラクタＣＨＡは、回答結果に基づき決定された商品をお勧め商品として、ユーザＵＳに提示する。例えば、注文する商品をなかなか決められないユーザＵＳの代わりに、注文する商品をキャラクタＣＨＡが選んであげる。
【０１０６】
この場合にキャラクタＣＨＡが行う質問は、例えば心理テストのような質問であり、一例としてはキャラクタＣＨＡが登場するゲームに関連する質問である。例えば前述の特許文献１の従来技術では、ユーザが購入したい商品を的確に把握するための商品説明を、店員キャラクタが行っている。しかしながらこの従来技術の手法では、店員キャラクタは単なる説明者に過ぎず、ユーザの思い入れや愛着の対象となるものではない。
【０１０７】
これに対して本実施形態では、ゲームにも登場するキャラクタＣＨＡは、ユーザＵＳの思い入れや愛着の対象である。そしてキャラクタＣＨＡが、商品とは直接的には関係ない心理テストのような質問を行うため、あたかもキャラクタＣＨＡがユーザＵＳの事を知りたいために質問を行っているような感覚を、ユーザＵＳに与えることができる。またキャラクタＣＨＡが質問し、ユーザＵＳが回答すると、その回答内容に基づいてキャラクタＣＨＡがユーザＵＳの事を理解したかのように、ユーザＵＳに感じさせることができる。そして、このようにユーザＵＳの事を理解したキャラクタＣＨＡが、メニューの中からユーザＵＳにお勧め商品を選んでくれる。従って、ユーザＵＳは、自身が愛着を持っているキャラクタＣＨＡが、質問を通じて自分の事を理解して、お勧め商品を選んでくれているように感じることができる。このため、ユーザＵＳは、例えば勧められた商品が自分の好みではなかったとしても、愛着のあるキャラクタＣＨＡが勧めてくれたのだから、注文してみようと思うようになる。従来技術では、ユーザ自身が好む商品しか選ばれないが、本実施形態では、ユーザＵＳとキャラクタＣＨＡとのコミュニケーションを通じて、注文する商品が選択される。従って、キャラクタＣＨＡとのインタラクティブなコミュニケーションを介した注文商品の選択が可能になり、従来技術では実現できないシステムの提供が可能になる。
【０１０８】
また本実施形態では、図７（Ａ）に示すように複数のキャラクタＣＨＡ、ＣＨＢが登場する。そしてキャラクタＣＨＡ（第１のキャラクタ）が行った質問に対するユーザＵＳの回答結果及びキャラクタＣＨＢ（第２のキャラクタ）が行った質問に対するユーザＵＳの回答結果の少なくとも一方に基づいて、ユーザに提示する商品が決定される。例えばキャラクタＣＨＡに対応するメニューとキャラクタＣＨＢに対応するメニューの少なくとも一方のメニューの中から、ユーザに提示されるお勧め商品が決定される。例えば図７（Ａ）では、キャラクタＣＨＡはプリン派であるため、キャラクタＣＨＡに対応するメニューはプリンのメニューになる。一方、キャラクタＣＨＢはケーキ派であるため、キャラクタＣＨＢに対応するメニューはケーキのメニューになる。そして図７（Ｂ）では、キャラクタＣＨＡがユーザＵＳに対して心理テストのような質問をしており、ユーザＵＳが質問に回答している。キャラクタＣＨＢは、例えばユーザＵＳの回答に相槌を打つような会話をしており、ユーザＵＳとキャラクタＣＨＡ、ＣＨＢとの対話処理が実行されている。また図７（Ｂ）のキャラクタＣＨＡの質問に続いて、例えばキャラクタＣＨＢがユーザＵＳに対して質問し、ユーザＵＳが回答する。このように図７（Ａ）、図７（Ｂ）では、キャラクタＣＨＡ、ＣＨＢの少なくとも一方のキャラクタの質問に対してユーザＵＳが回答するというように、ユーザＵＳとキャラクタＣＨＡ、ＣＨＢとのインタラクティブな会話が行われる。そして全ての質問が終了すると、図８に示すように、キャラクタＣＨＡが、自身のメニューの中からお勧め商品をユーザＵＳに提示し、キャラクタＣＨＢも自身のメニューの中からお勧め商品をユーザＵＳに提示する。なお、一方のキャラクタのメニューの中からお勧め商品を提示してもよい。
【０１０９】
このようにすれば、ユーザＵＳと複数のキャラクタＣＨＡ、ＣＨＢとのインタラクティブな質問と回答のやり取りの中から、ユーザＵＳへのお勧め商品が選択されて提示されるようになる。例えばユーザＵＳが複数のキャラクタＣＨＡ、ＣＨＢとの会話を楽しんでいる間に、その会話での質問に対する回答に応じたお勧め商品が選択されて、ユーザＵＳに提示されるようになる。従ってユーザＵＳは、会話を楽しむだけで、その会話の中からお勧め商品が選択されるようになるため、ユーザＵＳにとって飽きが来にくいゲームシステムの実現が可能になる。即ち、ユーザＵＳとキャラクタＣＨＡ、ＣＨＢとのインタラクティブなコミュニケーションを実現しながらユーザに提示する注文対象を決定できるゲームシステムの実現が可能になる。
【０１１０】
次に、メニューの中からユーザに提示する商品を決定する処理の具体例について説明する。図９（Ａ）はメニュー情報の例である。メニューＭＡは図７（Ａ）のキャラクタＣＨＡに対応するメニューであり、メニューＭＢはキャラクタＣＨＢに対応するメニューである。キャラクタＣＨＡはプリンを好むプリン派であるため、メニューＭＡの商品ＩＡ１〜ＩＡ５は、種類が異なる複数のプリンのリストになる。キャラクタＣＨＢはケーキを好むケーキ派であるため、メニューＭＢの商品ＩＢ１〜ＩＢ５は、種類が異なる複数のケーキのリストになる。これらのメニューＭＡ、ＭＢの情報は図１のメニュー情報記憶部１７６に記憶されている。
【０１１１】
図９（Ｂ）はユーザに提示する商品の決定処理に使用される演算テーブルの例である。演算テーブルＴＢＡはキャラクタＣＨＡ用のテーブルであり、演算テーブルＴＢＢはキャラクタＣＨＢ用のテーブルである。ＡＣ１、ＡＣ２、ＡＣ３は図７（Ｂ）で説明した回答の選択肢である。演算テーブルＴＢＡのＩＡ１〜ＩＡ５は、図９（Ａ）のメニューＭＡにリストされる商品である。演算テーブルＴＢＢのＩＢ１〜ＩＢ５は、メニューＭＢにリストされる商品である。そして演算テーブルＴＢＡでは、ＩＡ１〜ＩＡ５の各商品に対して、ユーザがＡＣ１、ＡＣ２、ＡＣ３の各選択肢を選択したときの重み付けポイントが設定されている。演算テーブルＴＢＢでは、ＩＢ１〜ＩＢ５の各商品に対して、ユーザがＡＣ１、ＡＣ２、ＡＣ３の各選択肢を選択したときの重み付けポイントが設定されている。
【０１１２】
例えばキャラクタＣＨＡの質問に対する回答として、ユーザが選択肢ＡＣ１を選択すると、演算テーブルＴＢＡに基づいて、メニューＭＡの商品ＩＡ１、ＩＡ２、ＩＡ３、ＩＡ４、ＩＡ５に対して、各々、重み付けポイント３、１、３、１、２が付与される。ユーザが選択肢ＡＣ２を選択すると、商品ＩＡ１、ＩＡ２、ＩＡ３、ＩＡ４、ＩＡ５に対して、各々、重み付けポイント１、４、２、２、１が付与される。ユーザが選択肢ＡＣ３を選択した場合も同様である。またキャラクタＣＨＢの質問に対する回答として、ユーザが選択肢ＡＣ１を選択すると、演算テーブルＴＢＢに基づいて、メニューＭＢの商品ＩＢ１、ＩＢ２、ＩＢ３、ＩＢ４、ＩＢ５に対して、各々、重み付けポイント２、２、３、２、１が付与される。ユーザが選択肢ＡＣ２、ＡＣ３を選択した場合も同様である。
【０１１３】
このように、キャラクタＣＨＡ、ＣＨＢが行う各質問に対して、図９（Ｂ）に示すような演算テーブルＴＢＡ、ＴＢＢが用意される。そして、キャラクタＣＨＡ、ＣＨＢからの各質問に対して、ユーザが選択肢を選んで回答すると、上述したように選択した選択肢に応じて、各商品に対して重み付けポイントが付与される。このようにして各質問が行われ、全ての質問が終了すると、各商品に付与された重み付けポイントの合計値が求められる。そして重み付けポイントの合計値が最も大きい商品が、ユーザに提示するお勧め商品として決定される。
【０１１４】
このようにすれば、一連の質問の回答としてユーザが選択肢を選択した場合に、選択された選択肢に応じた重み付けポイントを求め、その重み付けポイントの合計値を求めることで、ユーザに提示するお勧め商品を決定できるようになる。この場合に図９（Ｂ）の手法によれば、複数の質問に対するユーザの回答が同じであれば、同じ商品が一意に決定されるようになるため、お勧め商品の適正な決定処理を実現できるようになる。
【０１１５】
なお図９（Ｂ）の演算テーブルＴＢＡ、ＴＢＢでは、各商品の縦列での重み付けポイントの合計値は同じ値（例えば６）になっている。このようにすれば、各商品が同じ確率でお勧め商品として選ばれるようになる。
【０１１６】
一方、図９（Ｃ）の演算テーブルＴＢＡでは、商品ＩＡ１の縦列での重み付けポイントの合計値は１０であり、他の商品ＩＡ２〜ＩＡ５の縦列での重み付けポイントの合計値よりも大きくなっている。このような演算テーブルＴＢＡの設定にすれば、商品ＩＡ１が、商品ＩＡ２〜ＩＡ５に比べてより高い確率で選ばれるようになる。例えばＶＲカフェに対応する現実世界の店舗において、ユーザに対してより注文して欲しいが商品がＩＡ１である場合には、演算テーブルＴＢＡの重み付けポイントを図９（Ｃ）に示すような設定にすればよい。
【０１１７】
３．３  種々の処理例
次に本実施形態の種々の処理例について説明する。例えば本実施形態ではキャラクタに対して愛着度（広義には愛着度情報。以下、同様）が設定されている。そしてユーザの回答結果と、キャラクタに対するユーザの愛着度とに基づき、ユーザに提示する商品（注文対象）を決定する処理を行う。即ち、回答結果と愛着度に基づいて、メニューの中からお勧め商品を選択して提示する。
【０１１８】
例えば図１０にキャラクタ情報の例を示す。このキャラクタ情報は図１のキャラクタ情報記憶部１７４に記憶されている。図１０のキャラクタ情報では、各キャラクタに対応づけて、メニューＩＤ、愛着度、属性、相性度が設定されている。メニューＩＤは、図９（Ａ）に示す各キャラクタに対応するメニューを指定するＩＤである。このようなメニューＩＤを設けることで、各キャラクタに対してそのキャラクタが使用するメニューを対応づけることができる。
【０１１９】
愛着度（愛着度情報）は、キャラクタに対するユーザの愛着度の度合いを表すパラメータである。例えば図１０では、キャラクタＣＨＡに対するユーザの愛着度はＡＦＡに設定されており、キャラクタＣＨＢに対するユーザの愛着度はＡＦＢに設定されている。このように愛着度は各キャラクタ毎に設定される。属性は、キャラクタの属性パラメータであり、例えばキャラクタに備わっている固有の性質や特徴を表すものである。相性度は、例えばユーザとそのキャラクタとの相性度や、キャラクタ間での相性度である。例えばユーザとキャラクタとの相性度が高いほど、後述する愛着度の増加処理における愛着度の増加度合いが大きくなる。また互いの相性度が高い複数のキャラクタが登場して、会話を行うと、愛着度の増加度合が大きくなるなどして、ユーザにとってより有利な展開になる。
【０１２０】
図１１（Ａ）にユーザの推しキャラクタの選択画面の例を示す。ユーザは図１１（Ａ）の選択画面において、ユーザは、複数のキャラクタの中から推しキャラクタを選択する。すると、推しキャラクタとして選択されたキャラクタの愛着度が増加する。推しキャラクタは、ユーザが愛着を感じており、好意を抱いているキャラクタである。例えば推しキャラクタはユーザが応援しているキャラクタである。例えば推しキャラクタは、当該キャラクタが登場するゲームにおいてユーザの使用頻度が高いキャラクタである。
【０１２１】
また本実施形態では、ユーザの注視情報に応じてキャラクタの愛着度を変化させる。注視情報は、ユーザがキャラクタを注視しているか否かを表す情報、注視時間、或いは注視場所についての情報である。例えば図１１（Ｂ）では、ユーザＵＳは複数のキャラクタＣＨＡ、ＣＨＢのうちのキャラクタＣＨＡの方を注視している。即ち視線方向ＶＬをキャラクタＣＨＡの方に向けている。この場合にはキャラクタＣＨＡに対するユーザＵＳの愛着度が増加する。このとき、注視していない方のキャラクタＣＨＢに対する愛着度を減少させてもよい。ユーザＵＳがキャラクタを注視しているかどうかは、例えば前述したＨＭＤのトラッキング処理に基づき取得されるユーザＵＳの視線方向ＶＬなどに基づき判断できる。或いはタッチパネルディスプレイにおいて、ユーザＵＳがキャラクタにタッチしているか否かに応じて、当該キャラクタを注視しているか否かを判断してもよい。例えばユーザＵＳがキャラクタＣＨＡを注視している注視時間に応じてキャラクタに対する愛着度を変化させる。例えば注視時間が長いほど愛着度の増加値を大きくする。また注視時間が所与の時間を越えたことを条件に愛着度を段階的に変化させてもよい。例えば注視時間は注視カウンターなどに基づき判断できる。具体的には注視時間は、例えばユーザＵＳの視線方向がキャラクタの方を向いている時間を測定したり、ユーザＵＳがタッチパネルディスプレイにおいてキャラクタをタッチしている時間を測定することで、求めることができる。またユーザＵＳの注視場所に応じて愛着度を変化させたもよい。例えばユーザＵＳがキャラクタの第１の部位（例えば顔、頭部）を注視している場合には、愛着度を増加させ、第２の部位（例えば胸、臀部）を注視している場合には、愛着度の増加率を小さくしたり、愛着度を減少させてもよい。
【０１２２】
そして本実施形態では、このようにして設定されたキャラクタに対する愛着度と、ユーザの回答結果に基づいて、ユーザに提示する商品の決定処理を行う。例えばキャラクタＣＨＡの方がキャラクタＣＨＢよりもユーザの愛着度が高かった場合には、キャラクタＣＨＡのメニューの中から、ユーザに提示するお勧め商品を決定する。或いはキャラクタＣＨＡ、ＣＨＢのいずれがお勧め商品を提示するかを、愛着度に応じた確率情報などに基づいて決定する。或いは図９（Ｂ）で説明した演算テーブルに基づく演算処理において愛着度を用いる。例えば、ユーザの選択肢の選択により各商品に重み付けポイントを付与する際に、キャラクタに対する愛着度が大きいほど、付与する重み付けポイントを大きくする。例えば愛着度が高いキャラクタのメニューの商品の方が、愛着度が低いキャラクタのメニューの商品に比べて、お勧め商品として、より選ばれるようにする。
【０１２３】
このようにすれば、例えばキャラクタに対する愛着度が高いか低いかに応じて、ユーザに提示されるお勧め商品が変化するようになり、ユーザに提示するお勧め商品の決定処理に対して、キャラクタに対するユーザの愛着度を反映させることが可能になる。
【０１２４】
また本実施形態では、ユーザの回答結果と愛着度（愛着度情報）に基づき決定される商品（注文対象）がメニューの中になかった場合に、注文対象の非存在用の処理を行う。図１２に、この場合の処理例のフローチャートを示す。まずユーザとキャラクタの対話処理を行う（ステップＳ１）。例えばキャラクタがユーザに質問し、ユーザが質問に回答するための対話処理を行う。そしてユーザの回答結果とキャラクタに対するユーザの愛着度とに基づいて、メニューの中からお勧め商品を選択する処理を実行する（ステップＳ２）。例えば図９（Ｂ）で説明した演算テーブル等を用いて当該処理を実行する。
【０１２５】
次にメニューの中にお勧め商品があるか否かを判断する（ステップＳ３）。例えば重み付けポイント等のポイントを演算して、お勧め商品の選択処理を行う場合に、当該ポイントが所与のしきい値を超えたか否かなどに応じて、メニューの中にお勧め商品があるか否かを判断する。そして、メニューの中にお勧め商品があった場合には、そのお勧め商品をユーザに提示する（ステップＳ４）。例えば重み付けポイント等のポイントが所与のしきい値を超えた商品があった場合には、当該商品をお勧め商品としてユーザに提示する。一方、メニューの中にお勧め商品がなかった場合には、お勧め商品の非存在用の処理を実行する（ステップＳ５）。例えば重み付けポイント等のポイントが所与のしきい値を超えた商品がなかった場合には、お勧め商品の非存在用の特別な処理を実行する。
【０１２６】
このような特別な処理（お勧め商品の非存在用の処理）としては、以下のような処理が考えられる。例えば図１３（Ａ）に示すようにキャラクタＣＨＡが、キャラクタＣＨＢのメニューの中から商品を勧めて貰うように誘導する会話処理を、上記の特別な処理として行う。即ち図１３（Ａ）では、キャラクタＣＨＡのメニューの中にはお勧め商品が存在しないと判断されている。このためキャラクタＣＨＡが、キャラクタＣＨＢのメニューの中にお勧め商品がないかを聞くように、ユーザに話している。すると、キャラクタＣＨＢが、自身のメニューの中からお勧め商品を選択してユーザに提示する。例えば前述のように、愛着度に基づくお勧め商品の決定処理として、推しキャラクタと、推しキャラクタではない別のキャラクタがいる場合に、愛着度の高い推しキャラクタのメニューの方から優先してお勧め商品を選択するようにする。そして、この推しキャラクタのメニューの中にお勧め商品がないと判断された場合には、推しキャラクタではない別のキャラクタのメニューの中からお勧め商品を選択する。
【０１２７】
或いは、基本のメニューとは別に、裏メニュー（隠しメニュー）を用意しておき、基本のメニューの中にお勧め商品がなかった場合には、上記の特別な処理として、裏メニューの中からお勧め商品を選択する処理を行う。例えば図１３（Ｂ）では、キャラクタＣＨＡは、基本のメニューの中にはお勧め商品がなかったため、裏メニューの中からお勧め商品を選択することを、ユーザＵＳに対して話している。なお、推しキャラクタが自身のメニューの中からお勧め商品を選択するが、その際にフォロー演出が入るようにしてもよい。例えばユーザがニンジン嫌いであるのに、メニューの中にニンジンを使用した食べ物しかない場合に、「君の嫌いなにんじんが入ってるけど、よけて食べてね」というようなフォロー演出の会話をキャラクタが行う。
【０１２８】
このようにすれば、ユーザの回答結果と愛着度に基づき決定されるお勧めの商品が無いような状況が発生した場合にも、注文対象の非存在用の特別な処理を行うことで、これに対処できるようになる。
【０１２９】
また本実施形態では、愛着度に応じて、ユーザに対して行う質問を変化させる処理を行う。例えばキャラクタに対する愛着度が増加すると、それに応じて、回答の選択肢が増えるようにする。例えば初めは、選択肢が３つであり、三択だったのが、愛着度の増加に伴い、選択肢が３つから４つ、４つから５つというように増えて行く。即ち、選択肢が、三択から四択、四択から五択に変化する。或いは、愛着度が増加すると、質問回数が増えるようする。例えば通常は、全体でキャラクタが１０回の質問を行うが、愛着度が増加して所与のしきい値を超えると、質問回数が増加して、例えば１２回になる。或いは、愛着度が増加すると、それに応じて、質問の分岐が追加されるようにしてもよい。例えば会話のシナリオの分岐を増やして、異なるシナリオによる質問が行われるようにする。或いは、キャラクタＣＨＡ、ＣＨＢが登場する場合に、キャラクタＣＨＡ、ＣＨＢの愛着度に応じて、各キャラクタの質問回数を異ならせる。例えばキャラクタＣＨＡの方かＣＨＢよりも愛着度が高い場合には、キャラクタＣＨＡの方の質問回数をＣＨＢよりも多くする。例えば、初期状態では、キャラクタＣＨＡ、ＣＨＢの質問回数が、各々、５回、５回であったのを、キャラクタＣＨＡの愛着度が増加すると、質問回数を、各々、７回、３回に変化させる。
【０１３０】
図１４は、愛着度に応じて質問を変化させる処理のフローチャートである。まず愛着度の増加イベントが発生したか否かを判断し、増加イベントが発生した場合にはキャラクタの愛着度の増加処理を実行する（ステップＳ１１、Ｓ１２）。例えば前述したようにキャラクタが推しキャラクタとして選択されたり、ユーザがキャラクタを注視すると、そのキャラクタの愛着度が増加するイベントが発生し、当該キャラクタの愛着度が増加する。次に、キャラクタの愛着度がしきい値ＶＴＡを越えたか否かを判断する（ステップＳ１３）。そして愛着度がしきい値ＶＴＡを越えた場合には、回答の選択肢の増加処理、質問回数の増加処理、又は会話のシナリオ分岐の追加処理を実行する（ステップＳ１４）。例えば前述したように、ユーザの質問に対する選択肢の数を増やしたり、キャラクタがユーザにする質問の回数を増やしたり、新たなシナオリ分岐を発生する。
【０１３１】
このようにすれば、キャラクタに対する愛着度に応じて、キャラクタがユーザに対して行う質問が多様に変化するようになり、ユーザにとって、より飽きが来にくいゲームシステムの実現が可能になる。
【０１３２】
また本実施形態では愛着度に応じて、ユーザに提示する注文対象又はメニューを変化させる処理を行う。例えば愛着度が所与のしきい値を越えたことを条件に出現するような商品やメニューを用意する。例えば特定の商品は、愛着度が所与のしきい値が越えないと、メニューの中に入らないようにする。或いは、愛着度が所与のしきい値を超えると、特別なメニューが発生するようにする。或いは、特定の商品については、愛着度が所与のしきい値を超えないと、キャラクタがユーザに対して勧めないようにする。
【０１３３】
図１５は、愛着度に応じて商品又はメニューを変化させる処理のフローチャートである。まず愛着度の増加イベントが発生したか否かを判断し、増加イベントが発生した場合にはキャラクタの愛着度の増加処理を実行する（ステップＳ２１、Ｓ２２）。次に、キャラクタの愛着度がしきい値ＶＴＢを越えたか否かを判断する（ステップＳ２３）。そして愛着度がしきい値ＶＴＢを越えた場合には、新商品、新メニューの発生処理を実行する（ステップＳ２４）。例えば、メニューの中に新製品を追加したり、特別なメニューを出現させて、その特別なメニューの中からお勧め商品を選択して、ユーザに提示する。
【０１３４】
このようにすれば、キャラクタに対する愛着度に応じて、新たな商品や新たなメニューが出現するようになり、新たな商品をお勧め商品としてユーザに提示したり、新たなメニューの中から選択されたお勧め商品をユーザに提示できるようになる。
【０１３５】
また本実施形態では、実店舗又は仮想店舗へのユーザの来店回数に応じて、愛着度を増加させる処理を行う。例えば前述のＶＲカフェのように、ＶＲカフェに対応する現実世界の実店舗がある場合には、その実店舗への来店回数に応じて、ＶＲカフェのキャラクタに対する愛着度を増加させる。またインターネットのショッピングサイトなどにおける仮想店舗の場合には、そのサイトの仮想店舗にアクセスすることによる来店回数に応じて、その仮想店舗のキャラクタに対する愛着度を増加させる。ユーザの来店回数は、ユーザが所持する携帯型情報記憶媒体１９５（図１）に記録することで、管理してもよい。或いは、ユーザの来店回数をユーザ情報として、サーバシステムのデータベースに記録し、サーバシステムと通信接続される実店舗の来店回数や、ネットワーク上の仮想店舗の来店回数を管理してもよい。一例としては、図１６に示すように、実店舗や仮想店舗への初来店時には、愛着度の初期値を０に設定し、キャラクタに対する愛着度が０から開始するようにする。そして例えば２回目〜３回目の来店時には、愛着度の初期値を１０に設定し、キャラクタに対する愛着度が例えば１０から開始にするようにする。同様に４回目〜６回目の来店時においては、愛着度の初期値を１５に設定し、７回目以降の来店時においては、愛着度の初期値を２０に設定する。即ち実店舗や仮想店舗への来店回数に応じて、初期値である愛着度を段階的に変化させる。このようにすれば、愛着度の増加が動機づけとなって、実店舗や仮想店舗へのユーザの来店を促すことが可能になる。
【０１３６】
また本実施形態では、ユーザに対する課金に応じて、愛着度を増加させる処理を行う。例えばユーザに対する課金に対してユーザが対価を支払うと、キャラクタに対する愛着度を増加させる。例えば、プレゼント等の課金アイテムを購入して、キャラクタに渡すと、そのキャラクタに値する愛着度が増加する。例えばユーザは、自身がお気に入りの推しキャラクタに対して、プレゼント等の課金アイテムを購入して渡すことで、その推しキャラクタの愛着度を増加させることができる。例えばユーザが課金アイテムを購入した場合に、キャラクタの愛着度の初期値を０ではなく、２０に設定する。また課金アイテムをキャラクタに渡した場合に、キャラクタが、ファンサービスなどをするお礼の演出を行うようにしてもよい。
【０１３７】
例えば図１７（Ａ）では、ユーザＵＳは、課金ポイント（ゲーム内通貨）を消費することで、ハートのプレゼントを購入し、このプレゼントを、推しキャラクタであるキャラクタＣＨＡに渡している。これにより、キャラクタＣＨＡに対するユーザの愛着度が１０だけ上昇している。
【０１３８】
このように、ユーザに対する課金に応じて愛着度が増加することで、前述したように、例えばユーザに提示されるお勧め商品が変化したり、キャラクタの質問が変化したり、或いは新たな商品やメニューが発生するようになる。従って、課金アイテムを購入するなどして課金の対価を支払うことの効果的な動機づけを、ユーザに与えることができる。
【０１３９】
なお、前述のＶＲカフェにおいて、曜日（月曜日〜日曜日）によって、デフォルトで登場するキャラクタを変えるようにしてもよい。例えば月曜日は、キャラクタＣＨＡがデフォルトのキャラクタとして登場し、火曜日は、別のキャラクタＣＨＢがデフォルトのキャラクタとして登場するようにする。そしてユーザが、課金アイテム等を購入して課金の対価を支払えば、例えば月曜日において、キャラクタＣＨＡとは異なる自分の推しキャラクタを、ＶＲカフェに登場させることができるようにする。このようにすることで、課金の対価を支払うことの効果的な動機づけをユーザに与えることができる。
【０１４０】
また本実施形態ではキャラクタに対するユーザの愛着度が、所与のしきい値を越えた場合に、注文対象に対して付加物を付加する処理を行う。例えばキャラクタの愛着度が所与のしきい値を超えると、注文した商品に対して、おまけ商品がついてくるようにする。例えば図１７（Ｂ）では、前述したような愛着度の増加イベントが発生することで、愛着度が、しきい値である３０を越えている。この場合には、キャラクタＣＨＡが、注文したコーヒーに対して、おまけ商品であるクッキーをつけるという会話をする。例えば、ユーザＵＳの回答結果等に応じて、キャラクタＣＨＡは、お勧め商品としてコーヒーを提示している。そしてこのときに、愛着度がしきい値を超えているため、ユーザＵＳがコーヒーを注文すると、おまけとしてクッキーがついてくるようになる。
【０１４１】
このようにすれば、愛着度がしきい値を超えることで、ユーザは、お勧め商品のみならず、おまけ商品も得ることができるため、愛着度を高めることの効果的な動機づけをユーザに与えることができる。
【０１４２】
また本実施形態では、ユーザ及びキャラクタに関連する外部情報に基づいて、愛着度（パラメータ）を変化させる。例えばユーザ及びキャラクタに関連する外部情報を、外部から取得する。具体的には、ユーザ情報に関連して、連動するゲームの情報や、商品の購入情報を呼び出す。例えばキャラクタが登場するゲームの情報や、キャラクタに関連する商品についてのユーザの購入情報を、外部情報として呼び出す。そして、これらのゲームの情報や商品の購入情報を、キャラクタについての愛着度（パラメータ）に反映させる。例えば、ゲームにおいてメインに使用しているキャラクタ（使用頻度が高いキャラクタ）が、ＶＲカフェに登場するキャラクタであった場合には、ゲームの情報（ゲーム成績、ゲームでの取得ポイント、ゲームの進行度合い、又はゲームでのキャラクタやユーザのステータス情報等）を、ＶＲカフェに登場するキャラクタに反映させて、愛着度を変化させる。例えばゲーム成績が良いほど、或いは取得ポイントが高いほど、或いはゲームの進行度合いが進んでいるほど、愛着度を増加させる。或いは、そのキャラクタに関連する商品の過去の購入履歴情報を取得する。そして、キャラクタに関連する商品の購入の度合いに応じて、愛着度を変化させる。例えば商品の購入回数が多いほど、或いは購入頻度が高いほど、愛着度を増加させる。こうすることで、ユーザ及びキャラクタに関連する外部情報を反映させた愛着度の設定処理が可能になる。
【０１４３】
また本実施形態では、実店舗又は仮想店舗へのユーザの来店回数、ユーザに対する課金、ユーザの位置情報、及び日時情報の少なくとも１つに応じて、ユーザに対して行う質問、ユーザに提示するメニュー、メニューに含まれる注文対象、及びキャラクタの対話内容の少なくとも１つを設定する。例えば、来店回数、課金、位置情報、又は日時情報に応じて、質問、メニュー、注文対象、又は対話内容を変化させる処理を行う。図１８に、この処理の詳細を説明するフローチャートである。
【０１４４】
まず、ユーザの来店回数、ユーザの課金額、ユーザの位置情報、又は日時情報を含むユーザ情報を取得する（ステップＳ３１）。ユーザの来店回数は、前述したように実店舗又は仮想店舗への来店回数である。ユーザの課金額は、ユーザが課金に対して支払った対価の額である。ユーザの位置情報は、例えばＶＲカフェに対応する実店舗の位置情報や、ユーザの所持する携帯通信端末等により検出される位置情報である。日時情報は、日にちや時間についての情報である。
【０１４５】
次に、取得されたユーザ情報に応じて、キャラクタに対するユーザの愛着度を設定する（ステップＳ３２）。例えば来店回数が多いほど、愛着度を高くしたり、課金額が多いほど、愛着度を高くする。或いは、ユーザの位置情報や日時情報に応じて、愛着度を増減する。例えばユーザが、イベント会場などの特定の場所に来た場合には、愛着度を増加させる。また、イベント期間などの特別な期間、クリスマス、バレンタインデーなどの特別な日にち、或いは、特定の時間帯などにおいて、愛着度を増加させる。また、取得されたユーザ情報に応じて、ユーザに対して行う質問、ユーザに提示するメニュー、メニューに含まれる商品、或いはキャラクタの対話内容を変化させる（ステップＳ３３）。例えば、ユーザの来店回数や課金額に応じて、ユーザに対して行う質問の回数や内容を変化させたり、メニュー自体を変化させたり、メニューに含まれる商品の種類や個数を変化させたり、キャラクタの対話内容を変化させる。或いは、ユーザの位置情報や日時情報に応じて、質問の回数や内容を変化させたり、メニューや商品の種類や個数を変化させたり、キャラクタの対話内容を変化させる。また、ユーザの回答結果と、取得されたユーザ情報に応じて、ユーザに提示する商品の決定処理を行い、ユーザの回答結果とユーザ情報に基づき決定される商品（お勧め商品）がメニューの中になかった場合には、お勧め商品非存在用の処理を実行する（ステップＳ３４）例えば、質問に対するユーザの回答結果に加えて、ユーザの来店回数、ユーザの課金額、ユーザの位置情報、又は日時情報などのユーザ情報を加味して、お勧め商品としてユーザに提示する商品の決定処理を行う。そして、そのような商品がメニューの中になかった場合には、図１２〜図１３（Ｂ）で説明したように、お勧め商品非存在用の処理を実行する。
【０１４６】
以上のようにすれば、ユーザの来店回数、課金額、位置情報又は日時情報などのユーザ情報に応じて、キャラクタの愛着度を様々に変化させたり、質問、メニュー、商品又は対話内容を様々に変化させることが可能になる。またユーザ情報を反映させたお勧め商品の決定処理を実現できるようになる。
【０１４７】
４．詳細な処理
次に本実施形態の詳細な処理例について図１９、図２０のフローチャートを用いて説明する。
【０１４８】
図１９では、まず、キャラクタＣＨＡ、ＣＨＢがユーザに対して質問する対話処理を実行する（ステップＳ４１）。そしてキャラクタＣＨＡ、ＣＨＢが行った質問に対するユーザの回答を受け付ける（ステップＳ４２）。これにより図７（Ａ）、図７（Ｂ）に示すように、キャラクタＣＨＡやキャラクタＣＨＢがユーザＵＳに対して様々な質問を行い、これに対してユーザが応えるというような一連の対話が実現される。
【０１４９】
そして全ての質問が終了したか否かを判断する（ステップＳ４３）。そしてキャラクタＣＨＡ、ＣＨＢによる全ての質問が終了した場合には、キャラクタＣＨＡ、ＣＨＢが行った質問に対するユーザの回答結果に基づいて、キャラクタＣＨＡ、ＣＨＢに対応するメニューの中から、ユーザに提示する商品を選択する（ステップＳ４４）。例えば図９（Ａ）に示すようなメニューＭＡ、ＭＢの中から、図９（Ｂ）で説明したような選択処理を行うことで、ユーザに提示する商品を選択する。そして選択した商品をお勧め商品としてユーザに提示する（ステップＳ４５）。これにより図８に示すように、キャラクタＣＨＡ、ＣＨＢのお勧め商品をユーザＵＳに提示できるようになり、ユーザＵＳによるお勧め商品の注文が可能になる。
【０１５０】
図２０では、まず仮想空間の設定処理を行う（ステップＳ５１）。例えば図３に示すようなＶＲカフェが構築される仮想空間の設定処理を行う。そして、設定された仮想空間においてキャラクタを移動、動作させる処理を行う（ステップＳ５２）。例えば図５（Ａ）、図５（Ｂ）等に示すように、キャラクタＣＨＡをユーザＵＳのいる場所に移動させたり、キャラクタＣＨＡに会話動作を行わせる。
【０１５１】
次にキャラクタに対するユーザの注視情報を取得する（ステップＳ５３）。例えば図１１（Ｂ）で説明したように、ユーザＵＳがキャラクタＣＨＡ等を注視しているか否かの情報、注視時間の情報又は注視場所の情報を、注視情報として取得する。そして、取得された注視情報に応じて、ユーザに対して行う質問、ユーザに提示するメニュー、メニューに含まれる商品、或いはキャラクタの対話内容を設定する（ステップＳ５４）。例えば、注視情報に応じて、質問、メニュー、商品又は対話内容を変化させる。
【０１５２】
このように図２０の処理を行うことで、ＶＲカフェのような仮想空間を設定し、この仮想空間において仮想カメラから見える画像として、ユーザＵＳが視界を覆うように装着するＨＭＤ２００の表示画像を生成できる。そしてこの仮想空間にキャラクタを登場させ、このキャラクタの質問に対するユーザの回答結果に基づき決定された商品を、キャラクタを用いてユーザに提示できる。また、ユーザが、キャラクタを注視したか否か、或いはユーザが複数のキャラクタのうちのどのキャラクタを注視したか、或いはユーザの注視時間や注視場所に応じて、キャラクタの質問の回数や内容が変化したり、メニューが変化したり、メニューに含まれる商品の種類や個数が変化したり、キャラクタの対話内容が変化するようになる。これによりユーザの注視状況を反映させた多様な処理を実現できるようになる。
【０１５３】
なお、上記のように本実施形態について詳細に説明したが、本発明の新規事項および効果から実体的に逸脱しない多くの変形が可能であることは当業者には容易に理解できるであろう。従って、このような変形例はすべて本発明の範囲に含まれるものとする。例えば、明細書又は図面において、少なくとも一度、より広義または同義な異なる用語（注文対象、愛着度情報等）と共に記載された用語（商品、愛着度等）は、明細書又は図面のいかなる箇所においても、その異なる用語に置き換えることができる。またキャラクタ処理、注文対象の決定処理、提示処理、愛着度の設定処理、仮想空間の設定処理、仮想カメラの背魚処理、ゲーム処理、Ｌ表示処理等も、本実施形態で説明したものに限定されず、これらと均等な手法・処理・構成も本発明の範囲に含まれる。また本発明は種々のゲームに適用できる。また本発明は、業務用ゲーム装置、家庭用ゲーム装置、又は多数のユーザが参加する大型アトラクションシステム等の種々のゲームシステムに適用できる。
【符号の説明】
【０１５４】
ＣＨＡ、ＣＨＢ  キャラクタ（第１、第２のキャラクタ）、ＵＳ  ユーザ、
１００  処理部、１０２  入力処理部、１１０  演算処理部、
１１２  キャラクタ処理部、１１４  提示処理部、１１５  注文対象決定部、
１１６  仮想空間設定部、１１７  仮想カメラ制御部、１１８  ゲーム処理部、
１２０  表示処理部、１３０  音処理部、１４０  出力処理部、
１６０  操作部、１７０  記憶部、１７２  オブジェクト情報記憶部、
１７４  キャラクタ情報記憶部、１７５  会話情報記憶部、
１７６  メニュー情報記憶部、１７８  描画バッファ、
１８０  情報記憶媒体、１９０  表示部、１９２  音出力部、１９４  Ｉ／Ｆ部、
１９５  携帯型情報記憶媒体、１９６  通信部、
２００  ＨＭＤ（頭部装着型表示装置）、２７０  ヘッドフォン
【図１】
2019107081.tif 000003
【図２】
2019107081.tif 000004
【図３】
2019107081.tif 000005
【図４】
2019107081.tif 000006
【図５】
2019107081.tif 000007
【図６】
2019107081.tif 000008
【図７】
2019107081.tif 000009
【図８】
2019107081.tif 000010
【図９】
2019107081.tif 000011
【図１０】
2019107081.tif 000012
【図１１】
2019107081.tif 000013
【図１２】
2019107081.tif 000014
【図１３】
2019107081.tif 000015
【図１４】
2019107081.tif 000016
【図１５】
2019107081.tif 000017
【図１６】
2019107081.tif 000018
【図１７】
2019107081.tif 000019
【図１８】
2019107081.tif 000020
【図１９】
2019107081.tif 000021
【図２０】
2019107081.tif 000022