JP6487509B2 - プログラム、及びシステム - Google Patents

Description

本発明の実施形態の少なくとも１つは、抽選により仮想的なゲーム内要素をユーザに付与するシステム（以下「ガチャシステム」という。）を実行する機能をユーザ端末に実現させるためのプログラムに関する。また、本発明の実施形態の少なくとも１つは、通信ネットワークと、サーバと、ユーザ端末とを備え、ガチャシステムを実行する機能を制御するシステムに関する。また、本発明の実施形態の少なくとも１つは、ガチャシステムを実行する機能をサーバに実現させるためのプログラムに関する。

従来、抽選により仮想的なゲーム内要素（例えば、アイテム）をユーザに付与するシステムを実行する場合など、ビデオゲームの進行に基づいてユーザにゲーム内要素を付与するビデオゲームシステムがある。

このようなビデオゲームシステムでは、付与する際に所有可能な数の上限数を超えてしまいそうな場合その付与に制限が課せられ、所有するゲーム内要素が整理（例えば、アイテムを売却など）されたことを条件として制限が解除される（非特許文献１参照）。

ぼくらの甲子園！ポケット 公式攻略wiki(URL:https://xn--y8jve2gtg319wnjua.gamematome.jp/game/980/wiki/%E3%81%AF%E3%81%98%E3%82%81%E3%81%AB_%E3%83%98%E3%83%AB%E3%83%97_%E3%82%A2%E3%82%A4%E3%83%86%E3%83%A0_%E3%82%A2%E3%82%A4%E3%83%86%E3%83%A0%E3%81%AE%E6%89%80%E6%8C%81%E4%B8%8A%E9%99%90)

しかしながら、熟練者であればあるほど所持品は多くなるため、所有するゲーム内要素の数が多くなったユーザにとっては、ゲーム内要素の取得と、所有するゲーム内要素の整理と、がセットになっているという課題があった。すなわち、このようなビデオゲームシステムにおけるゲーム内要素の管理は、ユーザにとって非常に手間のかかるものになっているという課題があった。

本発明の少なくとも１つの実施形態の目的は、ゲーム内要素の管理に関する利便性を向上させることにある。

非限定的な観点によると、本発明の一実施形態に係るプログラムは、抽選により仮想的なゲーム内要素をユーザに付与するシステム（以下「ガチャシステム」という）を実行する機能をユーザ端末に実現させるためのプログラムであって、前記ユーザ端末に、ユーザが変更できる格納先設定に基づいて、前記ガチャシステムの実行に基づいて付与されるゲーム内要素の格納先を決定する決定機能と、前記ガチャシステムが実行された場合に、付与されるゲーム内要素が前記決定機能により決定された格納先に格納されるように、当該ゲーム内要素を管理する管理機能と、を実現させ、前記決定機能にて、格納先を、前記ガチャシステムの実行に基づいて付与されるゲーム内要素のみが格納される特定格納先にするか、または当該特定格納先とは異なる通常格納先にするかを決定する機能を実現させるためのものである。

非限定的な観点によると、本発明の一実施形態に係るシステムは、通信ネットワークと、サーバと、ユーザ端末とを備え、抽選により仮想的なゲーム内要素をユーザに付与するシステム（以下「ガチャシステム」という）を実行するシステムであって、ユーザが設定可能な格納先設定に基づいて、前記ガチャシステムの実行に基づいて付与されるゲーム内要素の格納先を決定する決定手段と、前記ガチャシステムが実行された場合に、付与されるゲーム内要素が前記決定手段により決定された格納先に格納されるように、当該ゲーム内要素を管理する管理手段と、を含み、前記決定手段は、格納先を、前記ガチャシステムの実行に基づいて付与されるゲーム内要素のみが格納される特定格納先にするか、または当該特定格納先とは異なる通常格納先にするかを決定することを特徴とする。

非限定的な観点によると、本発明の一実施形態に係るプログラムは、抽選により仮想的なゲーム内要素をユーザに付与するシステム（以下「ガチャシステム」という）を実行する機能をサーバに実現させるためのプログラムであって、前記サーバに、ユーザが設定可能な格納先設定に基づいて、前記ガチャシステムの実行に基づいて付与されるゲーム内要素の格納先を決定する決定機能と、前記ガチャシステムが実行された場合に、付与されるゲーム内要素が前記決定機能により決定された格納先に格納されるように、当該ゲーム内要素を管理する管理機能と、を実現させ、前記決定機能にて、格納先を、前記ガチャシステムの実行に基づいて付与されるゲーム内要素のみが格納される特定格納先にするか、または当該特定格納先とは異なる通常格納先にするかを決定する機能を実現させるためのものである。

本願の各実施形態により１又は２以上の不足が解決される。

本発明の実施形態の少なくとも一つに対応するシステムの構成の例を示すブロック図である。 本発明の実施形態の少なくとも一つに対応するサーバの構成を示すブロック図である。 本発明の実施形態の少なくとも一つに対応するゲーム関連処理の例を示すフローチャートである。 本発明の実施形態の少なくとも一つに対応するゲーム関連処理におけるサーバ側の動作の例を示すフローチャートである。 本発明の実施形態の少なくとも一つに対応するゲーム関連処理における端末の動作の例を示すフローチャートである。 本発明の実施形態の少なくとも一つに対応するサーバの構成を示すブロック図である。 本発明の実施形態の少なくとも一つに対応する表示処理の例を示すフローチャートである。 本発明の実施形態の少なくとも一つに対応するサーバの構成を示すブロック図である。 本発明の実施形態の少なくとも一つに対応する変更処理の例を示すフローチャートである。 本発明の実施形態の少なくとも一つに対応するサーバの構成を示すブロック図である。 本発明の実施形態の少なくとも一つに対応する制限処理の例を示すフローチャートである。 本発明の実施形態の少なくとも一つに対応するサーバの構成を示すブロック図である。 本発明の実施形態の少なくとも一つに対応する情報の格納状態の例について説明するための説明図である。 本発明の実施形態の少なくとも一つに対応する情報の格納状態の例について説明するための説明図である。 本発明の実施形態の少なくとも一つに対応する表示画面の例について説明するための説明図である。 本発明の実施形態の少なくとも一つに対応するゲーム関連処理の例を示すフローチャートである。 本発明の実施形態の少なくとも一つに対応する表示画面の例について説明するための説明図である。 本発明の実施形態の少なくとも一つに対応する表示画面の例について説明するための説明図である。 本発明の実施形態の少なくとも一つに対応するゲーム関連処理の例を示すフローチャートである。

以下、本発明の実施形態の例について図面を参照して説明する。なお、以下で説明する各実施形態の例における各種構成要素は、矛盾等が生じない範囲で適宜組み合わせ可能である。また、ある実施形態の例として説明した内容については、他の実施形態においてその説明を省略している場合がある。また、各実施形態の特徴部分に関係しない動作や処理については、その内容を省略している場合がある。さらに、以下で説明する各種フローを構成する各種処理の順序は、処理内容に矛盾等が生じない範囲で順不同である。

［第１の実施形態］
図１は、本発明の一実施形態におけるシステム１００の構成の例を示すブロック図である。図１に示すように、システム１００は、サーバ１０と、システム１００のユーザが使用するユーザ端末２０，２０１〜２０Ｎ（Ｎは任意の整数。以下単に「端末２０，２０１〜２０Ｎ」という。）とを含む。なお、システム１００の構成はこれに限定されず、単一の端末を複数のユーザが使用する構成としてもよいし、複数のサーバを備える構成としてもよい。

サーバ１０と複数の端末２０，２０１〜２０Ｎは、それぞれインターネットなどの通信ネットワーク３０に接続されている。なお、図示しないが、複数の端末２０，２０１〜２０Ｎは、通信業者によって管理される基地局と無線通信回線によるデータ通信を行うことによって、通信ネットワーク３０と接続する。

システム１００は、サーバ１０と複数の端末２０，２０１〜２０Ｎとを備えることにより、ガチャシステムを実行するための各種処理を実行する。ここで、ガチャシステムとは、原則的にゲーム内通貨の支払いが対価となって、所定の抽選群から抽選を行い、ユーザにゲーム内要素を付与するシステムを意味する。ガチャシステムを実行するための構成は特に限定されないが、ユーザが希望すれば、対価となるゲーム内要素を有している限り、複数回連続して抽選を実行できる構成が好適である。このような構成の例には、単発で実行可能な単発ガチャシステムがある。他の例として、一度の抽選でｎ個のゲーム内要素を抽選するｎ連ガチャシステム（ｎは２以上の任意の整数）がある。また、ゲーム内要素とは、ビデオゲームにおいてユーザが利用可能な要素を意味する。ゲーム内要素は、ユーザが仮想的に複数所有でき、使用（例えば、装備や設定）できることが好適である。ゲーム内要素の例には、スキルや、アイテムや、キャラクタなどがある。

サーバ１０は、システム１００の管理者によって管理され、複数の端末２０，２０１〜２０Ｎに対して各種処理に関する情報を提供するための各種機能を有する。本例において、サーバ１０は、ＷＷＷサーバなどの情報処理装置によって構成され、各種情報を格納する記憶媒体を備える。なお、サーバ１０は、制御部などコンピュータとして各種処理を行うための一般的な構成を備えるが、ここでの説明は省略する。また、システム１００においては、複数の端末２０，２０１〜２０Ｎそれぞれにかかる処理負荷を軽減させるといった観点から、各種情報はサーバ１０が管理することが好適である。ただし、サーバ１０がアクセス可能な状態で記憶領域が備えられていればよく、例えば専用の記憶領域がサーバ１０の外部に備えられるようにシステム１００が構成されてもよい。

図２は、サーバ１０の構成の例であるサーバ１０Ａの構成を示すブロック図である。図２に示すように、サーバ１０Ａは、決定部１１（決定機能の一例に相当）と、管理部１２（管理機能の一例に相当）と、を少なくとも備える。

決定部１１は、ユーザが変更できる格納先設定に基づいて、ガチャシステムの実行に基づいて付与されるゲーム内要素の格納先を決定する処理を実行する機能を有する。ここで、ユーザが変更できるとは、ユーザが所定操作により設定を変更することができることを意味する。ユーザが変更できる構成は特に限定されないが、初期状態の設定を変更できる構成や、変更された設定を再変更できる構成などが好適である。このような構成の例には、格納先を異なる格納先に変更することがある。また、格納先設定とは、ゲーム内要素がどの格納先に格納されるかを示す設定を意味する。格納先設定の例には、格納先を特定格納先とするものや、格納先を通常格納先とするものがある。また、格納先とは、ビデオゲーム内に設けられたゲーム内要素の仮想的な格納スペースを意味し、情報の記憶領域とは異なる。格納先の例には、所定の機能が制限されない格納先（例えば、インベントリやどうぐぶくろ）や、所定の機能が制限される格納先（例えば、倉庫）がある。また、所定の機能とは、ゲーム内要素を用いた機能を意味する。所定の機能が制限される構成の例には、回復アイテムの使用が制限される構成や、装備アイテムの装備が制限される構成や、装備アイテムの強化が制限される構成がある。

また、決定部１１は、ガチャシステムの実行に基づいて付与されるゲーム内要素のみが格納される特定格納先にするか、または特定格納先とは異なる通常格納先にするかを決定する処理を実行する機能を有する。ここで、特定格納先とは、仮想的な格納スペースの一つを意味する。特定格納先の例には、所定の機能が制限される格納先がある。また、通常格納先とは、仮想的な格納スペースの一つを意味する。通常格納先の例には、所定の機能が制限されない格納先がある。

管理部１２は、ガチャシステムが実行された場合に、付与されるゲーム内要素が決定部１１により決定された格納先に格納されるように、付与されるゲーム内要素を管理する処理を実行する機能を有する。ここで、格納先に格納されるとは、ビデオゲーム内に設けられたゲーム内要素の仮想的な格納スペースに収められている状態になることを意味する。格納先に格納されるように管理する構成は特に限定されないが、格納先に応じた情報形式で記憶領域に記憶する構成が好適である。このような構成の例には、格納先に応じた情報形式を参照して、付与するゲーム内要素の情報形式を決定し、決定した情報形式に応じた情報を対応付けて所定の記憶領域に記憶する構成がある。

複数の端末２０，２０１〜２０Ｎは、それぞれ、ビデオゲームを行うユーザ（又はプレイヤ）によって管理され、例えば携帯電話端末やＰＤＡ（ＰＥＲＳＯＮＡＬ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔｓ）、携帯型ゲーム装置などのネットワーク配信型のゲームを行うことが可能な通信端末によって構成される。なお、システム１００が含み得る端末の構成は上述した例に限定されず、ユーザがビデオゲームを認識できる構成であればよい。端末の構成の他の例には、スマートウォッチなどの所謂ウェアラブルデバイスや、ウェアラブルデバイスと通信端末等との組み合わせがある。

また、複数の端末２０，２０１〜２０Ｎは、それぞれ、通信ネットワーク３０に接続し、サーバ１０との通信を行うことによりビデオゲームを実行するためのハードウェア（例えば、ゲーム画面を表示する表示装置や音声出力装置など）及びソフトウェアを備える。なお、複数の端末２０，２０１〜２０Ｎそれぞれは、サーバ１０を介さずに互いに直接通信を行うこともできる構成とされていてもよい。また、複数の端末２０，２０１〜２０Ｎは、サーバ１０から送信される情報（例えば、ゲーム画像に関する情報）に基づいて自己の表示装置にゲームの画像を出力する。

次に、本例のシステム１００の動作について説明する。

図３は、システム１００が実行するゲーム関連処理の例を示すフローチャートである。以下、サーバ１０Ａと、端末２０とによりビデオゲームに関する情報の送受信を行う場合を例にして説明する。なお、本例のゲーム関連処理は、例えば、ガチャシステムの実行要求を端末２０のユーザから受け付けた場合を例にして説明する。

サーバ１０Ａは、ゲーム関連処理において、先ず、格納先を決定する（ステップＳ１１）。本例においてサーバ１０Ａは、特定格納先にするか、または通常格納先にするかを決定する。

サーバ１０Ａは、決定された格納先に格納されるようにゲーム内要素を管理し（ステップＳ１２）、ここでの処理を終了する。本例においてサーバ１０Ａは、格納先に応じた情報形式でゲーム内要素を記憶するとともに、付与するゲーム内要素に関する情報を端末２０に送信する。

図４は、ゲーム関連処理におけるサーバ１０Ａ側の動作の例を示すフローチャートである。ここでは、システム１００におけるサーバ１０Ａの動作について改めて説明する。

サーバ１０Ａは、ゲーム関連処理において、先ず、格納先を決定し（ステップＳ１０１）、決定された格納先に格納されるようにゲーム内要素を管理し（ステップＳ１０２）、ここでの処理を終了する。

図５は、端末２０がゲーム関連処理を実行する場合の端末２０の動作の例を示すフローチャートである。以下、端末２０が、単体でゲーム関連処理を実行する場合を例にして説明する。なお、端末２０の構成については、サーバ１０Ａの構成と同様の機能を備えるものであるため、重複説明を避ける観点から記載を省略する。

端末２０は、ゲーム関連処理において、先ず、格納先を決定し（ステップＳ１０１）、決定された格納先に格納されるようにゲーム内要素を管理し（ステップＳ１０２）、ここでの処理を終了する。

以上に説明したように、第１の実施形態の一側面として、ガチャシステムを実行するシステム１００が、決定部１１と、管理部１２と、を少なくとも備え、ユーザが変更できる格納先設定に基づいて、ガチャシステムの実行に基づいて付与されるゲーム内要素の格納先を決定し、ガチャシステムが実行された場合に、付与されるゲーム内要素が決定部１１により決定された格納先に格納されるように、ゲーム内要素を管理し、さらに、格納先を、ガチャシステムの実行に基づいて付与されるゲーム内要素のみが格納される特定格納先にするか、または特定格納先とは異なる通常格納先にするかを決定し、ゲーム内要素の管理負担が軽減され、ゲーム内要素の管理に関する利便性を向上させることができる。

すなわち、ユーザは、ガチャシステムの実行に基づいて得られるゲーム内要素を、特別格納先に格納するように設定できる。すなわち、ユーザは、自身の選択に基づいて、ガチャシステムで取得したゲーム内要素を一元管理できる。特にガチャシステムのように、一度に多くのアイテムを連続的に取得させるシステムにおいては、特定格納先を格納先とすることで、第１に、何度も所持品の整理を行うことを避けることができ、第２に、ガチャシステム以外の契機で取得したゲーム内要素と分けて管理できる。したがって、ユーザにとってのゲーム内要素の管理負担が軽減され、ゲーム内要素の管理に関するユーザビリティを向上させることができる。

［第２の実施形態］
図６は、サーバ１０の例であるサーバ１０Ｂの構成を示すブロック図である。本例において、サーバ１０Ｂは、決定部１１と、管理部１２と、表示部１３（第１表示機能の一例に相当）と、を少なくとも備える。

表示部１３は、格納先設定と、通常格納先における現在のゲーム内要素の格納数と、が第１所定条件を満たす場合に、格納先設定に関する情報を表示する処理を実行する機能を有する。ここで、第１所定条件とは、現在の格納先設定に関する条件と、通常格納先の格納状況に関する条件と、を含む条件を意味する。第１所定条件の構成は特に限定されないが、最適な格納先を報知するための条件であることが好適である。第１所定条件の例には、通常格納先が格納先に設定されている状態でガチャシステムを実行する場合に、通常格納先の格納上限を超えるという条件がある。他の例には、特定格納先を格納先に設定してガチャシステムを実行する場合に、通常格納先に所定数以上格納できるという条件がある。また、格納先設定に関する情報の構成は特に限定されないが、格納先設定に関する情報の例には、現在の格納先設定がどのようになっているかを示す情報や、格納先設定を変更することを促す情報がある。格納先設定に関する情報を表示する時機の例には、ガチャシステムを実行する時機や、ガチャシステムを実行するための表示画面を表示する場合がある。

また、情報を表示するとは、通信ネットワーク３０を用いた通信により、ユーザ端末２０、２０１〜２０Ｎが備える表示装置に画像を出力させることを意味する。情報を表示するための構成の例には、サーバ１０側で生成した情報（画像情報）をユーザ端末２０、２０１〜２０Ｎ側に送信する構成がある。なお、画像情報の構成は特に限定されず、例えば画像を圧縮した情報でもよいし、ユーザ端末２０、２０１〜２０Ｎで画像を生成させるための情報であってもよい。画像を圧縮した情報の例には、クラウドゲームで使用されるもの（例えば、ＭＰＥＧ）がある。また、ユーザ端末２０、２０１〜２０Ｎで画像を生成させるための情報には、オンラインゲームで使用されるもの（例えば、位置情報）がある。

図７は、システム１００が実行する表示処理の例を示すフローチャートである。以下、サーバ１０Ｂ側の動作を例にして説明する。なお、端末２０（サーバ１０Ｂの構成と同様の機能を備える端末２０）が単体で表示処理を実行する場合についての説明、及び既に説明している箇所については、重複説明を避ける観点から記載を省略する。なお、本例の表示処理は、例えば、ガチャシステムを実行する場合に実行される。

サーバ１０Ｂは、格納先設定と、通常格納先における現在のゲーム内要素の格納数と、が第１所定条件を満たす場合に、格納先設定に関する情報を表示する（ステップＳ２−１１）。本例においては、サーバ１０Ｂは、格納先設定に関する情報を表示するための画像情報を生成し、端末２０に画像情報を送信する。

以上に説明したように、第２の実施形態の一側面として、システム１００が、決定部１１と、管理部１２と、表示部１３と、を少なくとも備え、格納先設定と、通常格納先における現在のゲーム内要素の格納数と、が第１所定条件を満たす場合に、格納先設定に関する情報を表示し、ゲーム内要素の管理に関する利便性を向上させることができる。

すなわち、例えば、システム１００は、ガチャシステムを実行する場合に、ゲーム内要素の格納状況に応じてゲーム内要素の管理に関する情報をユーザに提供可能になる。特に、現在の格納先設定を参照して格納先設定に関する情報が表示されるため、格納先設定に関する気づきをユーザに提供することができるようになり、格納先を意識したガチャシステムの実行を促すことができ、ゲーム内要素の管理に関する利便性を向上させることができる。

［第３の実施形態］
図８は、サーバ１０の例であるサーバ１０Ｃの構成を示すブロック図である。本例において、サーバ１０Ｃは、決定部１１と、管理部１２と、変更部１４（第１変更機能の一例に相当）と、を少なくとも備える。

変更部１４は、通常格納先における現在のゲーム内要素の格納数に基づいて、格納先設定を変更する処理を実行するための機能を有する。本例では、変更部１４は、格納先設定と、通常格納先における現在のゲーム内要素の格納数と、が第２所定条件を満たす場合に、格納先設定を特定格納先に変更する処理を実行する機能を有する。ここで、第２所定条件とは、現在の格納先設定に関する条件と、通常格納先の格納状況に関する条件と、を含む条件を意味する。第２所定条件の構成は特に限定されないが、格納先設定を自動的に特定格納先に変更するための条件であることが好適である。第２所定条件の例には、設定された格納先が通常格納先であり、かつガチャシステムを実行すると通常格納先で格納できる数の所定の上限を超えるという条件がある。また、格納先設定を特定格納先に変更する時機は特に限定されない。格納先設定を特定格納先に変更する時機の例には、ガチャシステムを実行する時機や、ゲーム内要素に関する情報が更新された場合がある。

図９は、システム１００が実行する変更処理の例を示すフローチャートである。以下、サーバ１０Ｃ側の動作を例にして説明する。なお、端末２０（サーバ１０Ｃの構成と同様の機能を備える端末２０）が単体で変更処理を実行する場合についての説明、及び既に説明している箇所については、重複説明を避ける観点から記載を省略する。なお、本例の変更処理は、例えば、ガチャシステムを実行する場合に実行される。

サーバ１０Ｃは、格納先設定と、通常格納先における現在のゲーム内要素の格納数と、が第２所定条件を満たす場合に、格納先設定を特定格納先に変更する処理を実行する（ステップＳ３−１１）。本例においては、サーバ１０Ｃは、第２所定条件が満たされるかを判定し、第２所定条件を満たす場合に、格納先設定として設定されている情報を更新する。

以上に説明したように、第３の実施形態の一側面として、システム１００が、決定部１１と、管理部１２と、変更部１４と、を少なくとも備え、格納先設定と、通常格納先における現在のゲーム内要素の格納数と、が第２所定条件を満たす場合に、格納先設定を特定格納先に変更し、ゲーム内要素の管理に関する利便性を向上させることができる。

すなわち、例えば、システム１００は、ユーザのゲーム内要素の格納状況を見て、特定格納先に格納先を変更することができる。そのため、ユーザは設定を変更するための操作を行うことなく、状況に応じた格納先にガチャシステムで取得したゲーム内要素を格納することができるようになり、ゲーム内要素の管理に関する利便性を向上させることができる。

［第４の実施形態］
第４の実施形態におけるシステム１００は、設定されている格納先にゲーム内要素を付与した場合、設定されている格納先の格納上限に格納数が達してしまう場合に、ゲーム内要素を付与することを制限する。

図１０は、サーバ１０の例であるサーバ１０Ｄの構成を示すブロック図である。本例において、サーバ１０Ｄは、決定部１１と、管理部１２と、判定部１５（判定機能の一例に相当）と、制限部１６（制限機能の一例に相当）と、を少なくとも備える。

判定部１５は、格納先設定に基づいて、ゲーム内要素の格納数の上限に関する所定の上限条件が満たされているかを判定する処理を実行するための機能を有する。上限条件とは、格納先毎に決められている格納数の上限に関する条件を意味する。格納数の上限とは、どれくらいの数のゲーム内要素を格納できるかを示すものを意味する。格納数の上限は、予め定められており、所定条件が満たされると上限の値が変化する構成であることが好適である。格納数の上限の例には、格納するゲーム内要素の数や、最もスタック数の多いゲーム内要素のスタック数がある。

また、判定部１５は、格納先が通常格納先に設定されている場合、ゲーム内要素の格納数の合計が所定の第１閾値に達していることを上限条件として、上限条件が満たされているかを判定する処理を実行する機能を有する。ここで、第１閾値とは、通常格納先に設定されている閾値を意味する。所定の第１閾値の例には、通常格納先の格納数の上限がある。通常格納先の格納数とは、ゲーム内要素を格納できる数のことを意味する。

さらに、判定部１５は、格納先が特定格納先に設定されている場合、いずれかのゲーム内要素のスタック数の合計が所定の第２閾値に達していることを上限条件として、上限条件が満たされているかを判定する処理を実行する機能を有する。ここで、第２閾値とは、特定格納先に設定されている閾値を意味する。所定の第２閾値の例には、スタック数の上限がある。ここで、スタック数とは、個数のみを示す数を意味する。例えば、アイテムＡのスタック数が５の場合には、アイテムＡが５つあることを意味する。

制限部１６は、上限条件が満たされている場合に、ガチャシステムの実行を制限する処理を実行する機能を有する。実行を制限するとは、実行できないようにすることを意味する。実行を制限する構成は特に限定されないが、ガチャシステムの実行要求を行えない構成とされていることが好適である。このような構成の例には、実行要求を行うためのアイコンを選択できないようにする構成がある。他の例には、ガチャシステムが実行できないことをユーザに報知する構成がある。なお、制限部１６は、ゲーム内要素を付与しない構成とされていてもよい。

図１１は、システム１００が実行する制限処理の例を示すフローチャートである。以下、サーバ１０Ｄ側の動作を例にして説明する。なお、端末２０（サーバ１０Ｄの構成と同様の機能を備える端末２０）が単体で制限処理を実行する場合についての説明、及び既に説明している箇所については、重複説明を避ける観点から記載を省略する。なお、本例の制限処理は、例えば、ガチャシステムを実行する場合に実行される。

サーバ１０Ｄは、制限処理において、先ず、ゲーム内要素の格納数の上限に関する所定の上限条件が満たされているかを判定する（ステップＳ４−１１）。本例においては、サーバ１０Ｄは、格納先が通常格納先に設定されている場合、ゲーム内要素の格納数の合計が所定の第１閾値に達していることを上限条件とし、格納先が特定格納先に設定されている場合、いずれかのゲーム内要素のスタック数の合計が所定の第２閾値に達していることを上限条件として、上限条件が満たされているかを判定する。なお、両方の上限条件を判定する構成とされていてもよい。また、システム１００は、上限条件が満たされていない場合には、ガチャシステムを実行する構成とされていればよい。

サーバ１０Ｄは、上限条件が満たされている場合に、ガチャシステムの実行を制限し（ステップＳ４−１２）、ここでの処理を終了する。本例においては、サーバ１０Ｄは、実行要求を行うためのアイコンを非表示または選択できない状態で表示する。

以上に説明したように、第３の実施形態の一側面として、システム１００が、決定部１１と、管理部１２と、判定部１５と、制限部１６と、を少なくとも備え、格納先設定に基づいて、格納先が通常格納先に設定されている場合、ゲーム内要素の格納数の合計が所定の第１閾値に達していることを上限条件とし、格納先が特定格納先に設定されている場合、いずれかのゲーム内要素のスタック数の合計が所定の第２閾値に達していることを上限条件として、上限条件が満たされているかを判定し、上限条件が満たされている場合に、ガチャシステムの実行を制限し、ゲーム内要素の管理に関する利便性を向上させることができる。

すなわち、例えば、システム１００は、格納先の特性に応じて異なる特性の異なる上限条件を設けることで、上限に至りにくいゲーム内要素の管理システムを提供できる。したがって、ゲーム内要素の管理に関する利便性を向上させることができる。さらに、システム１００は、各格納先の上限を超えないようにゲーム内要素を管理できる。したがって、各格納先に応じたビデオゲームを管理する管理者の管理負担を軽減することができるようになり、ゲーム内要素の管理に関する利便性を向上させることができる。

［第５の実施形態］
本例のシステム１００は、ガチャシステムで獲得するアイテム（ゲーム内要素の一例）をどの格納先に格納するか、について予め設定できるシステムである。そして、システム１００は、ガチャシステムを実行する場合に、どの格納先に設定されているか、及び設定されている格納先に格納されているアイテムの格納状況はどうなっているか、に基づいて、各種処理が実行される。

また、ガチャシステムには、１回のガチャシステムの実行により１のアイテムを抽選する構成や、１回のガチャシステムの実行により１０のアイテムを抽選する構成がある。なお、１回のガチャシステムの実行により抽選されるアイテムの数は、このような構成に限られず、１以上の整数となっていることが好適である。

格納先には、道具袋（通常格納先の一例）と、保管庫（特定格納先の一例）と、が含まれる。道具袋と保管庫との間には次のような差異がある。道具袋は、一般的なアイテムの格納先に相当し、ガチャシステムで排出されるアイテム以外にも、ビデオゲームの進行に応じて付与される報酬などのアイテムが格納できる格納先である。一方で、保管庫は、ガチャシステムで排出されるアイテムのみが格納される格納先である。また、道具袋は、ガチャシステムで排出されるアイテムについて、１のアイテム単位で管理する格納先であり、アイテムの総数が上限数（例えば、３００）を超えると格納できなくなる。一方で、保管庫は、スタック形式でアイテムを管理する管理先であり、いずれかのアイテムのスタック数が上限数（例えば、９９９）を超えるまでアイテムを格納できる。また、道具袋に入っているアイテムについては、アイテムの装備や、アイテムの強化やアイテムが備えるスキルの取り出しや、アイテムの売却などの各種機能を利用できる。一方で、保管庫に入っているアイテムについては、アイテムの装備や、アイテムの強化やアイテムに付与されているスキルの取り出しなどの各種機能を利用できない。すなわち、保管庫では、そのアイテムを用いたキャラクタを成長させるための機能は利用できない。また、保管庫に格納されたアイテムは通常格納先に移動できる。一方で、道具袋に格納されたアイテムは、保管庫に移動できない。なお、格納先は、道具袋及び保管庫のほか、いわゆる倉庫に相当する預かり所を含む。

また、道具袋の上限数は、ユーザごとに異なるように構成されていてもよい。ユーザごとに異なるとは、ユーザのレベルに応じて上限数が異なるように構成される場合や、課金アイテムの使用により拡張可能に構成される場合が含まれる。また、保管庫は、スタック数により上限が管理されることから、ガチャで排出されるすべてのアイテムの種類のアイテムを、アイテムの総数に関係なく格納できる。したがって、保管庫の方が道具袋に比べて多くのアイテムを格納することができる。

図１２は、システム１００の構成を示すブロック図である。本例において、システム１００は、決定部１１Ｚ（決定機能の一例に相当）と、管理部１２Ｚ（管理機能の一例に相当）と、表示部１３Ｚ（表示機能の一例に相当）と、変更部１４Ｚ（変更機能の一例に相当）と、判定部１５Ｚ（判定機能の一例に相当）と、制限部１６Ｚ（制限機能の一例に相当）と、受付部１７Ｚ（受付機能の一例に相当）と、を少なくとも備える。なお、特に図示しないが、本例において、サーバ１０の一例であるサーバ１０Ｚと、端末２０の一例である端末２０Ｚとが、システム１００が備える各部により実行される機能の一部を有する構成とされる。

決定部１１Ｚは、ユーザが変更できる格納先設定に基づいて、ガチャシステムの実行に基づいて付与されるゲーム内要素の格納先を決定する処理を実行する機能を有する。

ここで、格納先設定には、道具袋を格納先とする設定と、保管庫を格納先とする設定とが含まれる。また、保管庫は、ゲーム内要素に対して実行可能な処理の種類が道具袋と比べて少ない格納先である。また、保管庫は、道具袋よりも多くのゲーム内要素を格納できる格納先である。本例においては、決定部１１Ｚは、道具袋に設定されているか、保管庫に設定されているかを判定することで、格納先を決定する。

管理部１２Ｚは、アイテムに関する情報を所定の記憶領域に記憶し、記憶したアイテムに関する情報を管理する処理を実行する機能を有する。特に、管理部１２は、ガチャシステムが実行された場合に、付与されるゲーム内要素が決定部１１により決定された格納先に格納されるように、ゲーム内要素を管理する。

ここで、ゲーム内要素を管理するための構成の例には、格納先が道具袋に設定されている場合に道具袋に格納するための情報形式で記憶領域に記憶する構成がある。また、他の例には、格納先が保管庫に設定されている場合に保管庫に格納するための情報形式で記憶領域に記憶する構成がある。記憶する格納領域は、すべての格納先に共通であってもよいし、格納先毎に異なる記憶領域（別の記憶媒体）であってもよい。情報形式は、道具袋に格納されているアイテムの数が特定可能であることが好適である。また、情報形式は、保管庫に格納されているアイテムのスタック数が特定可能であることが好適である。

図１３は、サーバ１０Ｚが備える記憶部（図示せず）に記憶される情報の格納状態の例について説明するための説明図である。図１３に示すように、サーバ１０Ｚは、通常格納先情報を記憶する。通常格納先情報は、道具袋に格納されるアイテムに関する情報である。通常格納先情報は、各アイテムについて、ユーザＩＤ、アイテムＩＤ、アイテム名、パラメータ、スキル名、スキルレベルなどを含む。

図１４は、サーバ１０Ｚが備える記憶部（図示せず）に記憶される情報の格納状態の例について説明するための説明図である。図１４に示すように、サーバ１０Ｚは、特定格納先情報を記憶する。特定格納先情報は、保管庫に格納されるアイテムに関する情報である。特定格納先情報は、各アイテムについて、ユーザＩＤ、アイテムＩＤ、アイテム名、スタック数などを含む。特定格納先情報は、通常格納先情報とは異なる情報形式で記憶される。換言すれば、本例において、道具袋に格納されるアイテムに関する情報の情報形式と、保管庫に格納されるアイテムに関する情報の情報形式と、が異なる。特定格納先情報における各アイテムの情報は、通常格納先情報における各アイテムの情報に比べて、少ない（簡素な）情報となっている。

表示部１３Ｚは、道具袋に格納されるアイテムの格納数に基づいて、格納先設定に関する情報を表示する処理を実行する機能を有する。特に、表示部１３Ｚは、格納先設定と、道具袋のアイテムの現在の格納数とが、第１所定条件を満たす場合、格納先設定に関する情報を表示する処理を実行する機能を有する。例えば、表示部１３Ｚは、道具袋で格納できるアイテムが多くなってきた場合、格納先設定に関する情報を表示する。ここで、第１所定条件は、最適な格納先を報知するための条件であることが好適である。第１所定条件の例には、設定された格納先が道具袋であり、かつ道具袋における現在の格納可能数（つまり空き枠）が所定数よりも少ないという条件がある。ここでいう所定数の例には、ガチャシステムの実行により付与されるアイテム数がある。他の例には、設定された格納先が保管庫であり、かつ道具袋における現在の格納数が所定数よりも少ないという条件がある。ここでいう所定数の例には、格納上限の半分がある。また、格納先設定に関する情報には、現在の格納先設定がどのようになっているかを示す情報や、格納先設定を変更することを促す情報がある。

また、表示部１３Ｚは、ガチャシステムを実行するためのゲーム画面の一部の領域に格納先設定に関する情報を表示する処理を実行する機能を有する。ここで、ガチャシステムを実行するためのゲーム画面とは、ユーザからガチャシステムの実行要求を受け付けるためのゲーム画面を意味する。ガチャシステムを実行するためのゲーム画面の例には、ガチャページや、ガチャページに遷移させるためのページがある。

変更部１４Ｚは、道具袋のアイテムの格納数に基づいて、格納先設定を変更する処理を実行する機能を有する。特に、変更部１４Ｚは、格納先設定と、道具袋における現在のアイテムの格納数と、が第２所定条件を満たす場合に、格納先設定を保管庫に変更する処理を実行する機能を有する。変更部１４Ｚが実行する処理の例には、道具袋に格納されているアイテムが上限を超えている（または、超えそうな）場合に、自動的に格納先設定を変更することがある。ここで、第２所定条件の例には、設定された格納先が道具袋であり、かつ道具袋における現在の格納可能数（つまり空き枠）が所定数よりも少ないという条件がある。ここでいう所定数の例には、ガチャシステムの実行により付与されるアイテム数がある。

なお、システム１００は、格納先を変更することを推奨する表示に対する入力がなかった場合（例えば、「変更しますがよろしいですか」という質問が表示され、その質問に対する応答がなかった場合など）に、変更部１４Ｚにより変更を行う構成とされていてもよい。また、システム１００は、表示部１３による表示（格納先を変更することを推奨する表示）と、変更部１４Ｚによる変更とを択一的に実行する構成とされていることが好適である。

また、変更部１４Ｚは、格納先設定と、道具袋における現在のアイテムの格納数と、が第３所定条件を満たす場合に、格納先設定を道具袋に変更する処理を実行する機能を有する。変更部１４Ｚが実行する処理の例には、道具袋で格納できるアイテムが多くなってきた場合、自動的に格納先設定を変更することがある。ここで、第３所定条件の例には、設定された格納先が保管庫であり、かつ道具袋における現在の格納数が所定数よりも少ないという条件がある。ここでいう所定数の例には、格納上限の半分がある。

判定部１５Ｚは、格納先設定に基づいて、ゲーム内要素の格納数の上限に関する所定の上限条件が満たされているかを判定する処理を実行するための機能を有する。上限条件とは、格納先に予め定められた格納数の上限に達してしまうかどうかを判定するための条件を意味する。格納先毎に上限条件の判断基準が異なる。道具袋は、アイテムの格納数の合計で判断される。一方で、保管庫は、最もスタック数の多いアイテムのそのスタック数で判断される。上限条件の例には、設定された格納先が道具袋であり、かつ道具袋における現在の格納数が上限を超えているという条件がある。また、他の例には、設定された格納先が保管庫であり、かつ保管庫における現在の最大スタック数が上限を超えているという条件がある。なお、上限条件はこのような例に限られず、上限を超える前に（つまり、ガチャシステムで取得できるアイテムの個数を考慮して）上限条件を満たすと判定可能とするための条件とされていてもよい。また、本例における各種条件（第１所定条件、第２所定条件、第３所定条件、上限条件）は、同一の条件を示す場合がある。すなわち、格納先設定に関する情報を表示する処理を実行するための条件（第１所定条件）と、格納先設定を変更する処理を実行するための条件（第２所定条件）と、ガチャシステムの実行を制限する処理を実行するための条件（上限条件）とが、同一の条件を示す場合がある。

本例において、端末２０Ｚは、ユーザからガチャシステムの実行要求を受け付けると、設定された格納先が道具袋であり、かつ道具袋における現在の格納数が上限を超えているかという条件（端末２０Ｚによる判定に用いられる上限条件）が満たされているかを判定する。さらに、サーバ１０Ｚは、端末からガチャシステムの実行要求を受け付けると、設定された格納先が保管庫であり、かつ保管庫における現在の最大スタック数が上限を超えているかという条件（サーバ１０Ｚによる判定に用いられる上限条件）が満たされているかを判定する。すなわち、本例では、端末２０Ｚ及びサーバ１０Ｚは、それぞれ異なる上限条件に基づいて、それぞれ判定を行う。

制限部１６Ｚは、ガチャシステムを実行すると上限条件が満たされる場合に、ガチャシステムの実行を制限する処理を実行する機能を有する。ガチャシステムの実行を制限する処理の例には、ガチャシステムを実行させるためのアイコンを選択できないようにすることや、アイコンは選択できるものの「ガチャシステムを実行できません」という情報が表示されるものがある。

本例において、端末２０Ｚは、端末２０Ｚによる判定に用いられる上限条件が満たされている場合には、サーバに対して実行要求を送信することなく、ガチャシステムの実行を制限する。さらに、サーバ１０Ｚは、サーバ１０Ｚによる判定に用いられる上限条件が満たされている場合に、端末に対してガチャシステムが実行できなかった旨の報知を行うことでガチャシステムの実行を制限する。すなわち、本例では、ガチャシステムの実行が制限されるタイミングが、複数存在する。

受付部１７Ｚは、各種入力を受け付けるための処理を実行する機能を有する。受付部１７Ｚが受け付ける各種入力の例には、格納先設定を変更するための入力や、ガチャシステムを実行するための入力がある。なお、入力する主体は特に限定されない。

図１５は、表示画面の例を説明するための説明図である。図１５に示すように、格納先設定を行えるゲーム画面１３００が表示画面に表示される。本例において、ゲーム画面１３００には、設定に関する情報１３０１と、保管庫を格納先にするためのオンアイコン１３０２と、道具袋を格納先にするためのオフアイコン１３０３と、が表示される。ユーザは、オンまたはオフに設定しておくことで、ガチャシステムにより取得するアイテムの格納先を決めておくことができる。

次に、本例のシステム１００の動作について説明する。

図１６は、システム１００が実行するゲーム関連処理の例を示すフローチャートである。以下、ゲーム関連処理における端末２０Ｚ側の動作の例にして説明する。本例では、ガチャシステムを実行するための押し下げアイコンを含むガチャページを表示しているものとして説明する。

端末２０Ｚは、ゲーム関連処理において、先ず、ガチャシステムの実行要求をユーザから受け付ける（ステップＳ５−１１）。

端末２０Ｚは、ガチャシステムの実行要求を受信し、現在の格納先設定に基づいて格納先を道具袋にするか、または保管庫にするかを決定する（ステップＳ５−１２）。本例においては、端末２０Ｚは、ユーザに関する情報を格納する記憶領域を参照して、実行要求に含まれるユーザＩＤに対応付けされる格納先設定を特定する。

端末２０Ｚは、端末２０Ｚによる判定に用いられる上限条件が満たされるかを判定する（ステップＳ５−１３）。本例において、サーバ１０Ｚは、アイテムの格納数が上限数を超えているかを判定する。すなわち、システム１００は、道具袋が格納先とされている場合には、道具袋に格納されるアイテムの総数が上限数を超えているかを判定する。この際に、システム１００は、格納先設定が道具袋ではない場合には、格納数が上限であっても上限条件が満たされないと判定する構成とされていてもよい。一方で、システム１００は、格納先設定が道具袋ではない場合であっても、格納数が上限であれば上限条件が満たされると判定する構成とされていてもよい。

端末２０Ｚは、上限条件を満たさないと判定した場合（ステップＳ５−１３のＮ）、ガチャシステムの実行要求をサーバ１０Ｚに送信する（ステップＳ５−１４）。本例の実行要求には、ユーザＩＤや、実行するガチャシステムＩＤや、決定された格納先（または格納先設定）に関する情報などが含まれる。

端末２０Ｚは、実行要求をサーバ１０Ｚに送信すると、結果を受信し（ステップＳ５−１５）、表示し（ステップＳ５−１６）、ここでの処理を終了する。

一方で、端末２０Ｚは、上限条件を満たすと判定した場合（ステップＳ５−１３のＹ）、ガチャシステムの実行を制限し（ステップＳ５−１７）、情報を表示し（ステップＳ５−１８）、ここでの処理を終了する。本例において、端末２０Ｚは、ガチャシステムを実行することができないことを報知するための情報を含むゲーム画面を表示する。

図１７は、表示画面の例を説明するための説明図である。図１７に示すように、ガチャシステムを実行することができないことを報知するための情報を含むゲーム画面１４００が表示画面に表示される。本例において、「ガチャシステムを実行できません」というポップ１４０１を表示する。また、本例においては、さらに、「道具袋の格納数が上限を超えているため」という理由と、現在の格納先を示す情報と、道具袋内の格納数に関する情報と、が表示される。

なお、システム１００は、情報の表示に代えて（または、とともに）、格納先設定を変更する構成とされていてもよい。また、システム１００は、ガチャシステムが実行できるように格納先が変更された場合には、ガチャシステムの実行要求をサーバ１０Ｚに送信する構成とされていてもよい。

図１８は、表示画面の例を説明するための説明図である。図１８に示すように、格納先設定を変更させるための入力領域を含むゲーム画面１５００が表示画面に表示される。本例において、システム１００は、格納先の変更を促すためのメッセージ領域１５０１と、格納先設定を道具袋から保管庫に変更させるためのオンアイコン１５０２と、を表示する。

図１９は、システム１００が実行するゲーム関連処理の例を示すフローチャートである。以下、ゲーム関連処理におけるサーバ１０Ｚ側の動作の例にして説明する。本例では、ステップＳ５−１４にて端末２０Ｚからガチャシステムの実行要求が送信されたことに応じてサーバ１０Ｚ側のゲーム関連処理が始まる。

サーバ１０Ｚは、ゲーム関連処理において、先ず、ガチャシステムの実行要求を端末２０Ｚから受け付ける（ステップＳ６−１１）。

サーバ１０Ｚは、ガチャシステムの実行要求を受信し、格納先を決定する（ステップＳ６−１２）。本例においては、サーバ１０Ｚは、実行要求に含まれる格納先に関する情報を参照して格納先を決定する。

サーバ１０Ｚは、サーバ１０Ｚによる判定に用いられる上限条件が満たされるかを判定する（ステップＳ６−１３）。本例において、サーバ１０Ｚは、いずれかのアイテムのスタック数が上限数を超えているかを判定する。具体的には、システム１００は、保管庫が格納先とされている場合に、保管庫に格納されるアイテムのいずれかのスタック数の総数が上限数を超えているかを判定する。この際に、システム１００は、格納先設定が保管庫ではない場合には、スタック数が上限であっても上限条件が満たされないと判定する構成とされていてもよい。一方で、システム１００は、格納先設定が保管庫ではない場合であっても、スタック数が上限であれば上限条件が満たされると判定する構成とされていてもよい。また、端末２０Ｚから送信されるガチャシステムの実行要求には、サーバ１０Ｚ側で上限条件を判定しなくともよいこと示す指示情報が含まれていてもよい。

サーバ１０Ｚは、上限条件を満たさないと判定した場合（ステップＳ６−１３のＮ）、ガチャシステムを実行し（ステップＳ６−１４）、結果に関する情報を表示するとともに、ガチャシステムで取得することになったアイテムを管理し（ステップＳ６−１５）、ここでの処理を終了する。本例において、サーバ１０Ｚは、結果に関する情報を端末２０Ｚに送信する。また、サーバ１０Ｚは、実行要求に含まれるユーザＩＤを参照して、ユーザに対応付けされたゲーム内要素に関する情報を更新する。

一方で、サーバ１０Ｚ、上限条件を満たすと判定した場合（ステップＳ６−１３のＹ）、ガチャシステムの実行を制限し（ステップＳ６−１６）、情報を表示し（ステップＳ６−１７）、ここでの処理を終了する。本例において、サーバ１０Ｚは、ガチャシステムを実行することができないことを報知するための情報を含むゲーム画面を端末２０Ｚに表示させる。

以上に説明したように、第５の実施形態の一側面として、システム１００が、決定部１１Ｚと、管理部１２Ｚと、を少なくとも備え、ユーザが変更できる格納先設定に基づいて、ガチャシステムの実行に基づいて付与されるアイテムの格納先を決定し、ガチャシステムが実行された場合に、付与されるアイテムが決定部１１により決定された格納先に格納されるように、アイテムを管理し、さらに、格納先を、ガチャシステムの実行に基づいて付与されるアイテムのみが格納される保管庫にするか、または保管庫とは異なる道具袋にするかを決定し、アイテムの管理負担が軽減され、アイテムの管理に関する利便性を向上させることができる。

すなわち、ユーザは、ガチャシステムの実行に基づいて得られるアイテムを、特別な格納先に格納するように設定できる。すなわち、ユーザは、自身の選択に基づいて、ガチャシステムで取得したアイテムを一元管理できる。特にガチャシステムのように、一度に多くのアイテムを連続的に取得させるシステムにおいては、保管庫を格納先とすることで、第１に、何度も所持品の整理を行うことを避けることができ、第２に、ガチャシステム以外の契機で取得したアイテムと分けて管理できる。したがって、ユーザにとってのアイテムの管理負担が軽減され、アイテムの管理に関するユーザビリティを向上させることができる。

また、第５の実施形態の一側面として、システム１００が、決定部１１Ｚと、管理部１２Ｚと、表示部１３Ｚと、を少なくとも備え、格納先設定と、道具袋における現在のアイテムの格納数と、が第１所定条件を満たす場合に、格納先設定に関する情報を表示し、アイテムの管理に関する利便性を向上させることができる。

すなわち、例えば、システム１００は、ガチャシステムを実行する場合に、アイテムの格納状況に応じてアイテムの管理に関する情報をユーザに提供可能になる。特に、現在の格納先設定を参照して格納先設定に関する情報が表示されるため、格納先設定に関する気づきをユーザに提供することができるようになり、格納先を意識したガチャシステムの実行を促すことができ、アイテムの管理に関する利便性を向上させることができる。

また、第５の実施形態の一側面として、システム１００が、システム１００が、決定部１１Ｚと、管理部１２Ｚと、変更部１４Ｚと、を少なくとも備え、格納先設定と、道具袋における現在のアイテムの格納数と、が第２所定条件を満たす場合に、格納先設定を特定格納先に変更し、アイテムの管理に関する利便性を向上させることができる。

すなわち、例えば、システム１００は、アイテムの格納状況を見て、保管庫に格納先を変更することができる。そのため、ユーザは設定を変更するための操作を行うことなく、状況に応じた格納先にガチャシステムで取得したアイテムを格納することができるようになり、アイテムの管理に関する利便性を向上させることができる。

また、第５の実施形態の一側面として、システム１００が、決定部１１Ｚと、管理部１２Ｚと、判定部１５Ｚと、制限部１６Ｚと、を少なくとも備え、格納先設定に基づいて、格納先が道具袋に設定されている場合、アイテムの格納数の合計が所定の第１閾値に達していることを上限条件とし、格納先が保管庫に設定されている場合、いずれかのアイテムのスタック数の合計が所定の第２閾値に達していることを上限条件として、上限条件が満たされているかを判定し、上限条件が満たされている場合に、ガチャシステムの実行を制限し、アイテムの管理に関する利便性を向上させることができる。

すなわち、例えば、システム１００は、通常の格納先におけるゲーム内要素の格納数が上限を超えている場合にガチャシステムを実行できないようなビデオゲームとは異なり、ガチャシステムを実行することができるケースを提供できる。したがって、ユーザにとってゲーム内要素の管理負担を軽減することができるようになり、ゲーム内要素の管理に関する利便性を向上させることができる。

また、システム１００は、各格納先で上限を超えている場合（または、上限を超えてしまう場合）にはガチャシステムを実行できない。したがって、各格納先に応じたビデオゲームを管理する管理者の管理負担を軽減することができるようになり、ゲーム内要素の管理に関する利便性を向上させることができる。

以上に説明したように、本願の各実施形態により１又は２以上の不足が解決される。なお、夫々の実施形態による効果は、非限定的な効果又は効果の一例である。

なお、上述した各実施形態では、複数のユーザ端末２０，２０１〜２０Ｎとサーバ１０は、自己が備える記憶装置に記憶されている各種制御プログラム（例えば、プログラム）に従って、上述した各種の処理を実行する。特に図示しない制御部が、各部を含み、各部で実行される処理を実行する機能を有する構成とされていてもよい。

また、システム１００の構成は上述した各実施形態の例として説明した構成に限定されず、例えばユーザ端末が実行する処理として説明した処理の一部又は全部をサーバ１０が実行する構成としてもよいし、サーバ１０が実行する処理として説明した処理の一部又は全部を複数のユーザ端末２０，２０１〜２０Ｎの何れか（例えば、ユーザ端末２０）が実行する構成としてもよい。また、サーバ１０が備える記憶部の一部又は全部を複数のユーザ端末２０，２０１〜２０Ｎの何れかが備える構成としてもよい。すなわち、システム１００におけるユーザ端末２０とサーバ１０のどちらか一方が備える機能の一部又は全部を、他の一方が備える構成とされていてもよい。

［付記］
抽選により仮想的なゲーム内要素をユーザに付与するシステム（以下「ガチャシステム」という）を実行する機能をユーザ端末に実現させるためのプログラムであって、
前記ユーザ端末に、
ユーザが変更できる格納先設定に基づいて、前記ガチャシステムの実行に基づいて付与されるゲーム内要素の格納先を決定する決定機能と、
前記ガチャシステムが実行された場合に、付与されるゲーム内要素が前記決定機能により決定された格納先に格納されるように、当該ゲーム内要素を管理する管理機能と、を実現させ、
前記決定機能にて、格納先を、前記ガチャシステムの実行に基づいて付与されるゲーム内要素のみが格納される特定格納先にするか、または当該特定格納先とは異なる通常格納先にするかを決定する機能を
実現させるためのプログラム。
［２］
前記ユーザ端末に、
前記格納先設定と、前記通常格納先における現在のゲーム内要素の格納数と、が第１所定条件を満たす場合に、前記格納先設定に関する情報を表示する第１表示機能を
実現させるための［１］記載のプログラム。
［３］
前記ユーザ端末に、
前記格納先設定と、前記通常格納先における現在のゲーム内要素の格納数と、が第２所定条件を満たす場合に、前記格納先設定を前記特定格納先に変更する第１変更機能を
実現させるための［１］または［２］記載のプログラム。
［４］
前記ユーザ端末に、
前記格納先設定に基づいて、ゲーム内要素の格納数の上限に関する所定の上限条件が満たされているかを判定する判定機能と、
前記上限条件が満たされている場合に、前記ガチャシステムの実行を制限する制限機能と、を実現させ、
前記判定機能にて、格納先が前記通常格納先に設定されている場合、ゲーム内要素の格納数の合計が所定の第１閾値に達していることを前記上限条件とし、格納先が前記特定格納先に設定されている場合、いずれかのゲーム内要素のスタック数の合計が所定の第２閾値に達していることを前記上限条件として、前記上限条件が満たされているかを判定する機能を
実現させるための［１］から［３］のうち何れかに記載のプログラム。
［５］
前記ユーザ端末に、
前記格納先設定と、前記通常格納先における現在のゲーム内要素の格納数と、が第３所定条件を満たす場合に、前記格納先設定を前記通常管理先に変更する第２変更機能を
実現させるための［１］から［３］のうちいずれかに記載のプログラム。
［６］
前記特定格納先は、ゲーム内要素に対して実行可能な処理の種類が前記通常格納先と比べて少ない格納先である
［１］から［５］のうちいずれかに記載のプログラム。
［７］
前記特定格納先は、前記通常格納先よりも多くのゲーム内要素を格納できる格納先である
［１］から［６］のうちいずれかに記載のプログラム。
［８］
前記特定格納先に格納されるゲーム内要素に関する情報の情報形式と、前記通常格納先に格納されるゲーム内要素に関する情報の情報形式と、が異なる
［１］から［７］のうちいずれかに記載のプログラム。
［９］
前記ユーザ端末に、
前記格納先設定を変更するための入力をユーザから受け付ける受付機能を
実現させるための［１］から［８］のうちいずれかに記載のプログラム。
［１０］
前記ユーザ端末に、
前記ガチャシステムを実行するためのゲーム画面の一部の領域に前記格納先設定に関する情報を表示する第２表示機能を
実現させるための［１］から［９］のうちいずれかに記載のプログラム。
［１１］
［１］から［１０］のうち何れかに記載のプログラムが前記サーバに実現させる機能のうち少なくとも１つの機能を、当該ユーザ端末と通信可能なサーバに実現させるためのプログラム。
［１２］
［１］から［１１］のうち何れかに記載のプログラムがインストールされたユーザ端末。
［１３］
通信ネットワークと、サーバと、ユーザ端末とを備え、抽選により仮想的なゲーム内要素をユーザに付与するシステム（以下「ガチャシステム」という）を実行するシステムであって、
ユーザが設定可能な格納先設定に基づいて、前記ガチャシステムの実行に基づいて付与されるゲーム内要素の格納先を決定する決定手段と、
前記ガチャシステムが実行された場合に、付与されるゲーム内要素が前記決定手段により決定された格納先に格納されるように、当該ゲーム内要素を管理する管理手段と、を含み、
前記決定手段は、格納先を、前記ガチャシステムの実行に基づいて付与されるゲーム内要素のみが格納される特定格納先にするか、または当該特定格納先とは異なる通常格納先にするかを決定する
ことを特徴とするシステム。
［１４］
前記サーバが、前記決定手段と、前記管理手段と、を含み、
前記ユーザ端末が、前記サーバから送信された前記ビデオゲームの進行を示すゲーム画像を表示するための画像情報に基づいて、表示装置の表示画面にゲーム画像を出力する表示手段と、を含む
［１３］記載のシステム。
［１５］
抽選により仮想的なゲーム内要素をユーザに付与するシステム（以下「ガチャシステム」という。）を実行する機能をユーザ端末に実現させるためのプログラムであって、
ユーザが設定可能な格納先設定に基づいて、前記ガチャシステムの実行に基づいて付与されるゲーム内要素の格納先を決定する決定機能と、前記ガチャシステムが実行された場合に、付与されるゲーム内要素が前記決定機能により決定された格納先に格納されるように、当該ゲーム内要素を管理する管理機能と、を実現させ、前記決定機能にて、格納先を、前記ガチャシステムの実行に基づいて付与されるゲーム内要素のみが格納される特定格納先にするか、または当該特定格納先とは異なる通常格納先にするかを決定する機能を、備えるサーバから送信された前記ビデオゲームの進行を示すゲーム画像を表示するための情報に基づいて、装置の表示画面にゲーム画像を出力する出力機能をユーザ端末に
実現させるためのプログラム。
［１６］
抽選により仮想的なゲーム内要素をユーザに付与するシステム（以下「ガチャシステム」という）を実行する機能をサーバに実現させるためのプログラムであって、
前記サーバに、
ユーザが設定可能な格納先設定に基づいて、前記ガチャシステムの実行に基づいて付与されるゲーム内要素の格納先を決定する決定機能と、
前記ガチャシステムが実行された場合に、付与されるゲーム内要素が前記決定機能により決定された格納先に格納されるように、当該ゲーム内要素を管理する管理機能と、を実現させ、
前記決定機能にて、格納先を、前記ガチャシステムの実行に基づいて付与されるゲーム内要素のみが格納される特定格納先にするか、または当該特定格納先とは異なる通常格納先にするかを決定する機能を
実現させるためのプログラム。
［１７］
抽選により仮想的なゲーム内要素をユーザに付与するシステム（以下「ガチャシステム」という。）を実行する方法であって、
ユーザが設定可能な格納先設定に基づいて、前記ガチャシステムの実行に基づいて付与されるゲーム内要素の格納先を決定する決定処理と、
前記ガチャシステムが実行された場合に、付与されるゲーム内要素が前記決定処理により決定された格納先に格納されるように、当該ゲーム内要素を管理する管理処理と、を含み、
前記決定処理にて、格納先を、前記ガチャシステムの実行に基づいて付与されるゲーム内要素のみが格納される特定格納先にするか、または当該特定格納先とは異なる通常格納先にするかを決定する
ことを特徴とする方法。
［１８］
通信ネットワークと、サーバと、ユーザ端末とを備え、抽選により仮想的なゲーム内要素をユーザに付与するシステム（以下「ガチャシステム」という。）を実行する方法であって、
ユーザが設定可能な格納先設定に基づいて、前記ガチャシステムの実行に基づいて付与されるゲーム内要素の格納先を決定する決定処理と、
前記ガチャシステムが実行された場合に、付与されるゲーム内要素が前記決定処理により決定された格納先に格納されるように、当該ゲーム内要素を管理する管理処理と、を含み、
前記決定処理にて、格納先を、前記ガチャシステムの実行に基づいて付与されるゲーム内要素のみが格納される特定格納先にするか、または当該特定格納先とは異なる通常格納先にするかを決定する
ことを特徴とする方法。

本発明の実施形態の一つによれば、ゲーム内アイテムの管理に有用である。

１０ サーバ
１１ 決定部
１２ 管理部
１３ 表示部
１４ 変更部
１５ 判定部
１６ 制限部
１７ 受付部
２０，２０１〜２０Ｎ ユーザ端末
３０ 通信ネットワーク
１００ システム

Claims (6)

1. 抽選により仮想的なゲーム内要素をユーザに付与するシステム（以下「ガチャシステム」という）を実行する機能をユーザ端末に実現させるためのプログラムであって、
   前記ユーザ端末に、
   ユーザが変更できる格納先設定に基づいて、前記ガチャシステムの実行に基づいて付与されるゲーム内要素の格納先を決定する決定機能と、
   前記ガチャシステムが実行された場合に、付与されるゲーム内要素が前記決定機能により決定された格納先に格納されるように、当該ゲーム内要素を管理する管理機能と、を実現させ、
   前記決定機能にて、格納先を、前記ガチャシステムの実行に基づいて付与されるゲーム内要素のみが格納される特定格納先にするか、または当該特定格納先とは異なる通常格納先にするかを決定する機能を
   実現させるためのプログラム。
2. 前記ユーザ端末に、
   前記格納先設定と、前記通常格納先における現在のゲーム内要素の格納数と、が第１所定条件を満たす場合に、前記格納先設定に関する情報を表示する第１表示機能を
   実現させるための請求項１記載のプログラム。
3. 前記ユーザ端末に、
   前記格納先設定と、前記通常格納先における現在のゲーム内要素の格納数と、が第２所定条件を満たす場合に、前記格納先設定を前記特定格納先に変更する第１変更機能を
   実現させるための請求項１または請求項２記載のプログラム。
4. 前記ユーザ端末に、
   前記格納先設定に基づいて、ゲーム内要素の格納数の上限に関する所定の上限条件が満たされているかを判定する判定機能と、
   前記上限条件が満たされている場合に、前記ガチャシステムの実行を制限する制限機能と、を実現させ、
   前記判定機能にて、格納先が前記通常格納先に設定されている場合、ゲーム内要素の格納数の合計が所定の第１閾値に達していることを前記上限条件とし、格納先が前記特定格納先に設定されている場合、いずれかのゲーム内要素のスタック数の合計が所定の第２閾値に達していることを前記上限条件として、前記上限条件が満たされているかを判定する機能を
   実現させるための請求項１から請求項３のうちいずれかに記載のプログラム。
5. 通信ネットワークと、サーバと、ユーザ端末とを備え、抽選により仮想的なゲーム内要素をユーザに付与するシステム（以下「ガチャシステム」という）を実行するシステムであって、
   ユーザが設定可能な格納先設定に基づいて、前記ガチャシステムの実行に基づいて付与されるゲーム内要素の格納先を決定する決定手段と、
   前記ガチャシステムが実行された場合に、付与されるゲーム内要素が前記決定手段により決定された格納先に格納されるように、当該ゲーム内要素を管理する管理手段と、を含み、
   前記決定手段は、格納先を、前記ガチャシステムの実行に基づいて付与されるゲーム内要素のみが格納される特定格納先にするか、または当該特定格納先とは異なる通常格納先にするかを決定する
   ことを特徴とするシステム。
6. 抽選により仮想的なゲーム内要素をユーザに付与するシステム（以下「ガチャシステム」という）を実行する機能をサーバに実現させるためのプログラムであって、
   前記サーバに、
   ユーザが設定可能な格納先設定に基づいて、前記ガチャシステムの実行に基づいて付与されるゲーム内要素の格納先を決定する決定機能と、
   前記ガチャシステムが実行された場合に、付与されるゲーム内要素が前記決定機能により決定された格納先に格納されるように、当該ゲーム内要素を管理する管理機能と、を実現させ、
   前記決定機能にて、格納先を、前記ガチャシステムの実行に基づいて付与されるゲーム内要素のみが格納される特定格納先にするか、または当該特定格納先とは異なる通常格納先にするかを決定する機能を
   実現させるためのプログラム。

Images