知財求人 - 知財ポータルサイト「IP Force」
特開2025-22492情報処理装置、情報処理方法、プログラム及び情報処理システム
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2025022492
(43)【公開日】2025-02-14
(54)【発明の名称】情報処理装置、情報処理方法、プログラム及び情報処理システム
(51)【国際特許分類】
A63F 13/795 20140101AFI20250206BHJP
A63F 13/533 20140101ALI20250206BHJP
A63F 13/35 20140101ALI20250206BHJP
【ＦＩ】
A63F13/795
A63F13/533
A63F13/35
【審査請求】未請求
【請求項の数】16
【出願形態】ＯＬ
(21)【出願番号】P 2023127126
(22)【出願日】2023-08-03
(71)【出願人】
【識別番号】500033117
【氏名又は名称】株式会社ＭＩＸＩ
(74)【代理人】
【識別番号】100104880
【弁理士】
【氏名又は名称】古部 次郎
(74)【代理人】
【識別番号】100114546
【弁理士】
【氏名又は名称】頭師 教文
(72)【発明者】
【氏名】深谷 心
(57)【要約】
【課題】マルチプレイへの参加の可否を早期に確認可能にする。
【解決手段】情報処理装置に、マルチプレイに応募した複数のユーザのうち、第１条件を満たす第１ユーザに優先権を付与する付与部と、第１ユーザが操作する端末に、所定操作を受け付けるための第１画面を表示させる第１出力部と、第１ユーザによる所定操作が第２条件を満たす場合、第１ユーザを前記マルチプレイのプレイヤに設定する設定部と、複数のユーザのうち、第１条件を満たさない第２ユーザが操作する端末に、マルチプレイへの参加不可を通知する第２画面を表示させる第２出力部とを設ける。
【選択図】図５
【解決手段】情報処理装置に、マルチプレイに応募した複数のユーザのうち、第１条件を満たす第１ユーザに優先権を付与する付与部と、第１ユーザが操作する端末に、所定操作を受け付けるための第１画面を表示させる第１出力部と、第１ユーザによる所定操作が第２条件を満たす場合、第１ユーザを前記マルチプレイのプレイヤに設定する設定部と、複数のユーザのうち、第１条件を満たさない第２ユーザが操作する端末に、マルチプレイへの参加不可を通知する第２画面を表示させる第２出力部とを設ける。
【選択図】図５
【特許請求の範囲】
【請求項1】
マルチプレイに応募した複数のユーザのうち、第１条件を満たす第１ユーザに優先権を付与する付与部と、
前記第１ユーザが操作する端末に、所定操作を受け付けるための第１画面を表示させる第１出力部と、
前記第１ユーザによる前記所定操作が第２条件を満たす場合、前記第１ユーザを前記マルチプレイのプレイヤに設定する設定部と、
前記複数のユーザのうち、前記第１条件を満たさない第２ユーザが操作する端末に、前記マルチプレイへの参加不可を通知する第２画面を表示させる第２出力部と、
を有する情報処理装置。
前記第１ユーザが操作する端末に、所定操作を受け付けるための第１画面を表示させる第１出力部と、
前記第１ユーザによる前記所定操作が第２条件を満たす場合、前記第１ユーザを前記マルチプレイのプレイヤに設定する設定部と、
前記複数のユーザのうち、前記第１条件を満たさない第２ユーザが操作する端末に、前記マルチプレイへの参加不可を通知する第２画面を表示させる第２出力部と、
を有する情報処理装置。
【請求項2】
前記付与部は、前記第２条件を満たさなかった前記第１ユーザに付与されていた優先権を解除する、
請求項１に記載の情報処理装置。
請求項１に記載の情報処理装置。
【請求項3】
前記付与部は、前記第２条件を満たさなかった前記第１ユーザに付与されていた優先権を、前記マルチプレイへの応募のタイミングが早い他のユーザに付与する、
請求項２に記載の情報処理装置。
請求項２に記載の情報処理装置。
【請求項4】
前記付与部は、前記第２ユーザのうち所定条件を満たすユーザの端末に、前記マルチプレイにおけるプレイヤの再募集を通知する、
請求項２に記載の情報処理装置。
請求項２に記載の情報処理装置。
【請求項5】
前記第１条件は、前記マルチプレイに対する応募の受付順位が募集人数以内であることである、
請求項１に記載の情報処理装置。
請求項１に記載の情報処理装置。
【請求項6】
前記第２条件は、前記第１画面の表示から所定時間内に前記所定操作を行うことである、
請求項１に記載の情報処理装置。
請求項１に記載の情報処理装置。
【請求項7】
前記設定部は、ゲーム媒体の選択中に前記ゲーム媒体の変更に関する操作を受け付けた場合、前記所定時間を延長する、
請求項６に記載の情報処理装置。
請求項６に記載の情報処理装置。
【請求項8】
前記設定部は、前記第１ユーザの属性に応じ、前記第１ユーザに適用する前記所定時間を個別に設定する、
請求項６に記載の情報処理装置。
請求項６に記載の情報処理装置。
【請求項9】
前記設定部は、前記所定時間内に前記第２条件を満たさなかった回数が多い前記第１ユーザのための第１所定時間を、前記回数が少ない前記第１ユーザのための第２所定時間よりも長く設定する、
請求項８に記載の情報処理装置。
請求項８に記載の情報処理装置。
【請求項10】
前記設定部は、ログインの回数が少ない前記第１ユーザのための第１所定時間を、前記回数が多い前記第１ユーザのための第２所定時間よりも長く設定する、
請求項８に記載の情報処理装置。
請求項８に記載の情報処理装置。
【請求項11】
前記第１出力部は、前記第１画面に、前記マルチプレイを募集したユーザが選択したゲーム媒体及び他の前記第１ユーザが選択したゲーム媒体の少なくともいずれかの情報を提示する、
請求項１に記載の情報処理装置。
請求項１に記載の情報処理装置。
【請求項12】
前記第２出力部は、前記第２ユーザが操作する端末に表示させる前記第２ユーザが応募可能な１又は複数のマルチプレイのリストにおいて、前記マルチプレイに基づく条件を満たす第２マルチプレイと、前記条件を満たさない第３マルチプレイを互いに識別可能に表現する、
請求項１に記載の情報処理装置。
請求項１に記載の情報処理装置。
【請求項13】
前記第２出力部は、出現するゲーム媒体が前記マルチプレイと同じ又は類似するクエストをプレイ対象とするマルチプレイを前記第２マルチプレイとする、
請求項１２に記載の情報処理装置。
請求項１２に記載の情報処理装置。
【請求項14】
プロセッサが、マルチプレイに応募した複数のユーザのうち、第１条件を満たす第１ユーザに優先権を付与する処理と、
プロセッサが、前記第１ユーザが操作する端末に、所定操作を受け付けるための第１画面を表示させる処理と、
プロセッサが、前記第１ユーザによる前記所定操作が第２条件を満たす場合、前記第１ユーザを前記マルチプレイのプレイヤに設定させる処理と、
プロセッサが、前記複数のユーザのうち、前記第１条件を満たさない第２ユーザが操作する端末に、前記マルチプレイへの参加不可を通知する第２画面を表示させる処理と、
を実行する情報処理方法。
プロセッサが、前記第１ユーザが操作する端末に、所定操作を受け付けるための第１画面を表示させる処理と、
プロセッサが、前記第１ユーザによる前記所定操作が第２条件を満たす場合、前記第１ユーザを前記マルチプレイのプレイヤに設定させる処理と、
プロセッサが、前記複数のユーザのうち、前記第１条件を満たさない第２ユーザが操作する端末に、前記マルチプレイへの参加不可を通知する第２画面を表示させる処理と、
を実行する情報処理方法。
【請求項15】
プロセッサに、マルチプレイに応募した複数のユーザのうち、第１条件を満たす第１ユーザに優先権を付与させ、
プロセッサに、前記第１ユーザが操作する端末に、所定操作を受け付けるための第１画面を表示させ、
前記第１ユーザによる前記所定操作が第２条件を満たす場合、プロセッサに、前記第１ユーザを前記マルチプレイのプレイヤに設定させ、
プロセッサに、前記複数のユーザのうち、前記第１条件を満たさない第２ユーザが操作する端末に、前記マルチプレイへの参加不可を通知する第２画面を表示させる、
処理を実行させるプログラム。
プロセッサに、前記第１ユーザが操作する端末に、所定操作を受け付けるための第１画面を表示させ、
前記第１ユーザによる前記所定操作が第２条件を満たす場合、プロセッサに、前記第１ユーザを前記マルチプレイのプレイヤに設定させ、
プロセッサに、前記複数のユーザのうち、前記第１条件を満たさない第２ユーザが操作する端末に、前記マルチプレイへの参加不可を通知する第２画面を表示させる、
処理を実行させるプログラム。
【請求項16】
マルチプレイに応募した複数のユーザのうち、第１条件を満たす第１ユーザに優先権を付与する付与部と、
前記第１ユーザが操作する端末に、所定操作を受け付けるための第１画面を表示させる第１出力部と、
前記第１ユーザによる前記所定操作が第２条件を満たす場合、前記第１ユーザを前記マルチプレイのプレイヤに設定する設定部と、
前記複数のユーザのうち、前記第１条件を満たさない第２ユーザが操作する端末に、前記マルチプレイへの参加不可を通知する第２画面を表示させる第２出力部と、
を有する情報処理システム。
前記第１ユーザが操作する端末に、所定操作を受け付けるための第１画面を表示させる第１出力部と、
前記第１ユーザによる前記所定操作が第２条件を満たす場合、前記第１ユーザを前記マルチプレイのプレイヤに設定する設定部と、
前記複数のユーザのうち、前記第１条件を満たさない第２ユーザが操作する端末に、前記マルチプレイへの参加不可を通知する第２画面を表示させる第２出力部と、
を有する情報処理システム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、情報処理装置、情報処理方法、プログラム及び情報処理システムに関する。
【背景技術】
【0002】
複数のプレイヤが協同で１つのクエストをプレイすることがある。このプレイの形式は「マルチプレイ」と呼ばれる。マルチプレイでは、ホストとなるプレイヤが他のプレイヤを募集し、他のプレイヤが揃うことでプレイが開始される。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】特開２０２３－６８３１８号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
マルチプレイへの参加は、募集人数に達するまで、応募順に認められる。ところが、マルチプレイの開始前に参加が認められた応募者の一部に欠員が生じることがある。このため、参加が認められた応募者だけでなく、参加が認められない応募者にも、マルチプレイで使用するゲーム媒体を選択するための画面が提示されている。その結果、ゲーム媒体を選択する操作の後に参加が認められない旨が判明する事態が生じている。
【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】ホストユーザが選択したゲーム媒体の情報が表示されるデッキ選択画面の表示例を説明する図である。
【図29】第２協同プレイ用の表示欄と第３協同プレイ用の表示欄を別に設ける例を説明する図である。
【図30】第２協同プレイ用の表示欄と第３協同プレイ用の表示欄を別に設ける他の例を説明する図である。
【発明を実施するための形態】
【0009】
以下、図面を参照して、本発明の実施の形態を説明する。
後述する実施の形態は、本発明を実施するための形態の一例にすぎず、本発明の実施の形態は、後述する形態例に限定されない。
従って、本発明の技術的範囲は、後述する実施の形態に記載された範囲に限定されない。例えば実施の形態に記載された内容に種々の変更又は改良を加えたものも、本発明の技術的範囲に含まれる。
なお、後述する各種の機能部は、例えばＣＰＵ（＝Central Processing Unit）、ＭＰＵ（＝Micro Processing Unit）、ＧＰＵ（＝Graphics Processing Unit）、ＤＳＰ（＝Digital Signal Processor）その他のプロセッサによるプログラムの実行を通じて実現される。
後述する実施の形態は、本発明を実施するための形態の一例にすぎず、本発明の実施の形態は、後述する形態例に限定されない。
従って、本発明の技術的範囲は、後述する実施の形態に記載された範囲に限定されない。例えば実施の形態に記載された内容に種々の変更又は改良を加えたものも、本発明の技術的範囲に含まれる。
なお、後述する各種の機能部は、例えばＣＰＵ（＝Central Processing Unit）、ＭＰＵ（＝Micro Processing Unit）、ＧＰＵ（＝Graphics Processing Unit）、ＤＳＰ（＝Digital Signal Processor）その他のプロセッサによるプログラムの実行を通じて実現される。
【0010】
＜用語＞
まず、実施の形態で使用する用語について説明する。
「プログラム」は、ＯＳ（＝Operating System）やアプリケーションプログラムの総称として使用する。
「ゲーム」は、コンピュータゲームをいう。ゲームの舞台となる仮想の空間を「ゲーム空間」という。ゲーム空間の舞台には、例えば仮想の街や仮想の国がある。
まず、実施の形態で使用する用語について説明する。
「プログラム」は、ＯＳ（＝Operating System）やアプリケーションプログラムの総称として使用する。
「ゲーム」は、コンピュータゲームをいう。ゲームの舞台となる仮想の空間を「ゲーム空間」という。ゲーム空間の舞台には、例えば仮想の街や仮想の国がある。
【0011】
ゲームは、インゲームとアウトゲームに分類される。
「インゲーム」は、ゲームの本体部分であり、「クエスト」と呼ばれるサブゲームで構成される。多くの場合、クエストの難易度やクエストに出現する敵キャラクタ（すなわちボスキャラ）は、クエスト毎に異なっている。クエストには、例えば達成条件が定められており、達成条件を達成したプレイヤには特典が付与される。
「アウトゲーム」は、インゲーム以外のゲーム部分である。アウトゲームでは、例えばプレイに使用するゲーム媒体の取得、育成、選択等が実行される。アウトゲームも、１又は複数のクエストで構成されることがある。
「インゲーム」は、ゲームの本体部分であり、「クエスト」と呼ばれるサブゲームで構成される。多くの場合、クエストの難易度やクエストに出現する敵キャラクタ（すなわちボスキャラ）は、クエスト毎に異なっている。クエストには、例えば達成条件が定められており、達成条件を達成したプレイヤには特典が付与される。
「アウトゲーム」は、インゲーム以外のゲーム部分である。アウトゲームでは、例えばプレイに使用するゲーム媒体の取得、育成、選択等が実行される。アウトゲームも、１又は複数のクエストで構成されることがある。
【0012】
「達成条件」には、例えばクエスト内の全ての敵キャラを倒すこと、特定の敵キャラを倒すこと、特定の場所や地点に到着すること、特定のアイテムを取得することがある。
特定の敵キャラには、例えばボスキャラがある。特定のアイテムには、例えばコイン、装備、武器、宝箱等がある。
達成条件の達成は、「ゲームのクリア」とも「ゲームの攻略」とも呼ばれる。
「プレイヤ」は、端末の操作を通じてゲームをプレイするユーザをいう。
特定の敵キャラには、例えばボスキャラがある。特定のアイテムには、例えばコイン、装備、武器、宝箱等がある。
達成条件の達成は、「ゲームのクリア」とも「ゲームの攻略」とも呼ばれる。
「プレイヤ」は、端末の操作を通じてゲームをプレイするユーザをいう。
【0013】
「端末」には、ユーザが操作する端末（以下「ユーザ端末」ともいう。）の他、インターネットその他のネットワーク上に配置されるサーバがある。なお、ユーザとプレイヤを明確に区別する場合、プレイヤが操作する端末を「プレイヤ端末」という。
サーバでゲームを実行する場合、ユーザ端末は、いわゆる入出力装置として使用される。すなわち、ユーザ端末は、ゲームに関連する画像の表示と操作の入力に使用される。画像は、一般には動画像である。
サーバでゲームを実行する場合、ユーザ端末は、いわゆる入出力装置として使用される。すなわち、ユーザ端末は、ゲームに関連する画像の表示と操作の入力に使用される。画像は、一般には動画像である。
【0014】
「ソーシャルゲーム」は、例えばＳＮＳ（＝Social Networking Service）の要素を取り入れた複数人でプレイが可能なゲームである。例えばオンラインゲームがある。
「プレイの形態」には、１人のプレイヤによる単独プレイ（以下「シングルプレイ」ともいう。）と、所定関係にある複数のプレイヤによるプレイ（以下「マルチプレイ」ともいう。）がある。
「プレイの形態」には、１人のプレイヤによる単独プレイ（以下「シングルプレイ」ともいう。）と、所定関係にある複数のプレイヤによるプレイ（以下「マルチプレイ」ともいう。）がある。
【0015】
ゲームにより、シングルプレイのみが可能な場合、マルチプレイのみが可能な場合、シングルプレイとマルチプレイの選択が可能な場合がある。
なお、ゲームには、プレイヤが操作するオブジェクト（例えばプレイヤキャラ）のゲーム空間（仮想空間）内における位置情報を利用するゲームもあれば、これらの位置情報を利用しないゲームもある。
なお、ゲームには、プレイヤが操作するオブジェクト（例えばプレイヤキャラ）のゲーム空間（仮想空間）内における位置情報を利用するゲームもあれば、これらの位置情報を利用しないゲームもある。
【0016】
「マルチプレイ型のゲーム」には、例えば他のプレイヤと対戦するゲーム（以下「対戦型ゲーム」という。）と、ゲームの結果を他のプレイヤと競うゲーム（以下「競争型ゲーム」ともいう。）、協同して共通の目的（例えばゲームのクリア）の達成を目指すゲーム（以下「協同型ゲーム」ともいう。）がある。
対戦型ゲームをプレイすることを対戦プレイといい、競争型ゲームをプレイすることを競争プレイといい、協同型ゲームをプレイすることを協同プレイという。
対戦型ゲームをプレイすることを対戦プレイといい、競争型ゲームをプレイすることを競争プレイといい、協同型ゲームをプレイすることを協同プレイという。
【0017】
協同型ゲームをプレイする他のユーザを募集するユーザを「ホスト」又は「ホストユーザ」といい、募集に応じるユーザを「ゲスト」又は「ゲストユーザ」という。
「デッキ」は、クエストのプレイに使用する１体以上のゲーム媒体（以下「オブジェクト」ともいう。）の組み合わせをいう。
デッキを構成するゲーム媒体の数には上限がある。例えば４体である。デッキの選択により、又は、新たなデッキの編成により、ゲームのプレイが可能になる。
「デッキ」は、クエストのプレイに使用する１体以上のゲーム媒体（以下「オブジェクト」ともいう。）の組み合わせをいう。
デッキを構成するゲーム媒体の数には上限がある。例えば４体である。デッキの選択により、又は、新たなデッキの編成により、ゲームのプレイが可能になる。
【0018】
協同プレイの場合、各プレイヤが使用する１又は複数体のゲーム媒体の組み合わせにより、協同プレイのためのデッキが編成される。
協同プレイに使用するゲーム媒体の選択は、デッキの選択により実現される。例えばゲストの募集人数が３人の場合、選択されたデッキの先頭に位置するゲーム媒体が、各ゲストが使用するゲーム媒体となる。
ゲストの募集人数が１人の場合、選択されたデッキの先頭と２番目に位置する２体のゲーム媒体が、ゲストが使用するゲーム媒体に選択される。
協同プレイに使用するゲーム媒体の選択は、デッキの選択により実現される。例えばゲストの募集人数が３人の場合、選択されたデッキの先頭に位置するゲーム媒体が、各ゲストが使用するゲーム媒体となる。
ゲストの募集人数が１人の場合、選択されたデッキの先頭と２番目に位置する２体のゲーム媒体が、ゲストが使用するゲーム媒体に選択される。
【0019】
因みに、ゲストが２人の場合、２人のゲストが選択したデッキの先頭に位置するゲーム媒体がそれぞれ提供される。なお、残りの２体は、ホストが選択したデッキの先頭と２番目に位置する２体のゲーム媒体が使用される。
協同プレイに参加する全てのプレイヤについてゲーム媒体の選択が完了すると、協同プレイが開始される。各プレイヤは、各自が選択したゲーム媒体を順番に、又は、同時に操作することにより協同プレイを進行する。
「所定価値」は、電子マネー、暗号資産、ゲーム内通貨、法定通貨、ポイント等のネットワーク上で交換が可能な情報をいう。
協同プレイに参加する全てのプレイヤについてゲーム媒体の選択が完了すると、協同プレイが開始される。各プレイヤは、各自が選択したゲーム媒体を順番に、又は、同時に操作することにより協同プレイを進行する。
「所定価値」は、電子マネー、暗号資産、ゲーム内通貨、法定通貨、ポイント等のネットワーク上で交換が可能な情報をいう。
【0020】
＜実施の形態１＞
＜システム構成＞
図１は、実施の形態１で想定する情報処理システム１の構成例を示す図である。
図１に示す情報処理システム１は、ソーシャルゲームの進行を管理するサーバ１０と、各ユーザが操作するユーザ端末２０Ａ、２０Ｂ、２０Ｃ、２０Ｄ、２０Ｅと、これらを通信可能に接続するネットワークＮとで構成される。
ユーザ端末２０Ａ、２０Ｂ、２０Ｃ、２０Ｄ、２０Ｅを区別しない場合、ユーザ端末２０と表記する。一方で、ユーザ端末２０に対応するユーザを区別する場合、ユーザを表す記号と組み合わせて表記する。なお、以下の説明では、ユーザ端末２０を「端末２０」と呼ぶこともある。
＜システム構成＞
図１は、実施の形態１で想定する情報処理システム１の構成例を示す図である。
図１に示す情報処理システム１は、ソーシャルゲームの進行を管理するサーバ１０と、各ユーザが操作するユーザ端末２０Ａ、２０Ｂ、２０Ｃ、２０Ｄ、２０Ｅと、これらを通信可能に接続するネットワークＮとで構成される。
ユーザ端末２０Ａ、２０Ｂ、２０Ｃ、２０Ｄ、２０Ｅを区別しない場合、ユーザ端末２０と表記する。一方で、ユーザ端末２０に対応するユーザを区別する場合、ユーザを表す記号と組み合わせて表記する。なお、以下の説明では、ユーザ端末２０を「端末２０」と呼ぶこともある。
【0021】
図１の場合、ユーザ端末２０は５台であるが、実際には２台以上であればよい。もっとも、実施の形態で想定する協同プレイでは、ゲストが３人の場合を想定する。
１台のユーザ端末２０には、１名のユーザが対応付けられている。換言すると、１台のユーザ端末２０には、１つのユーザアカウントが対応付けられている。図１では、ユーザ端末２０Ａに対応するユーザをユーザＡ、ユーザ端末２０Ｂに対応するユーザをユーザＢ等と表記する。なお、クエストをプレイするユーザは、前述の通り、プレイヤと呼ぶ。
ネットワークＮには、例えばインターネット、ＬＡＮ（＝Local Area Network）、４Ｇや５Ｇ等の移動通信システムを想定する。
ネットワークＮは、有線ネットワークでも無線ネットワークでもよく、有線ネットワークと無線ネットワークの混在型でもよい。
１台のユーザ端末２０には、１名のユーザが対応付けられている。換言すると、１台のユーザ端末２０には、１つのユーザアカウントが対応付けられている。図１では、ユーザ端末２０Ａに対応するユーザをユーザＡ、ユーザ端末２０Ｂに対応するユーザをユーザＢ等と表記する。なお、クエストをプレイするユーザは、前述の通り、プレイヤと呼ぶ。
ネットワークＮには、例えばインターネット、ＬＡＮ（＝Local Area Network）、４Ｇや５Ｇ等の移動通信システムを想定する。
ネットワークＮは、有線ネットワークでも無線ネットワークでもよく、有線ネットワークと無線ネットワークの混在型でもよい。
【0022】
サーバ１０は、ソーシャルゲームの提供に使用される１又は複数台のコンピュータである。サーバ１０が複数台のコンピュータで構成される場合、複数台のコンピュータがネットワークＮ経由で連携し、プレイヤによるソーシャルゲームのプレイを可能とする。
サーバ１０は、オンプレミス型のサーバでもよいし、クラウド型のサーバでもよい。クラウド型のサーバには、例えばIaaS（＝Infrastructure as a Service）、PaaS（＝Platform as a Service）、SaaS（＝Software as a Service）がある。サーバ１０は、情報処理装置の一例である。
サーバ１０は、オンプレミス型のサーバでもよいし、クラウド型のサーバでもよい。クラウド型のサーバには、例えばIaaS（＝Infrastructure as a Service）、PaaS（＝Platform as a Service）、SaaS（＝Software as a Service）がある。サーバ１０は、情報処理装置の一例である。
【0023】
ユーザ端末２０は、ソーシャルゲームをプレイするユーザが操作する端末である。ユーザ端末２０は、例えばスマートフォン、タブレット型のコンピュータ、ノート型やデスクトップ型のコンピュータ、ゲーム端末、ヘッドマウント型の端末（いわゆるヘッドセット）、メガネ型の端末（いわゆるスマートグラス）である。因みに、スマートグラスは、小型のディスプレイと、ディスプレイに表示された画像を網膜上に結像する導光部品とを備える眼鏡型のデバイスである。
ユーザ端末２０は、ネットワークＮとの通信機能を備えている。本実施の形態におけるユーザ端末２０は、サーバ１０に対する入出力装置として使用される。もっとも、ユーザ端末２０上で、ソーシャルゲームのアプリケーションプログラムの一部が実行される場合、ユーザ端末２０は、情報処理装置の一例として扱う。
ユーザ端末２０は、ネットワークＮとの通信機能を備えている。本実施の形態におけるユーザ端末２０は、サーバ１０に対する入出力装置として使用される。もっとも、ユーザ端末２０上で、ソーシャルゲームのアプリケーションプログラムの一部が実行される場合、ユーザ端末２０は、情報処理装置の一例として扱う。
【0024】
＜サーバのハードウェア構成＞
サーバ１０は、端末全体の動作を制御するプロセッサ１１と、メモリ１２と、補助記憶装置１３と、通信インタフェース１４とで構成される。
プロセッサ１１は、例えばＣＰＵである。メモリ１２は、ＢＩＯＳ（＝Basic Input Output System）等が記憶されたＲＯＭ（＝Read Only Memory）やプロセッサ１１のワークエリアとして用いられるＲＡＭ（＝Random Access Memory）で構成される。
サーバ１０は、端末全体の動作を制御するプロセッサ１１と、メモリ１２と、補助記憶装置１３と、通信インタフェース１４とで構成される。
プロセッサ１１は、例えばＣＰＵである。メモリ１２は、ＢＩＯＳ（＝Basic Input Output System）等が記憶されたＲＯＭ（＝Read Only Memory）やプロセッサ１１のワークエリアとして用いられるＲＡＭ（＝Random Access Memory）で構成される。
【0025】
補助記憶装置１３は、例えばハードディスク装置や半導体ストレージである。補助記憶装置１３には、プレイの対象であるソーシャルゲームのアプリケーションプログラムやゲームの進行等に関連する各種の情報が記憶される。
通信インタフェース１４は、ユーザ端末２０等の外部の端末との通信を可能にするデバイスである。通信インタフェース１４には、通信に使用するネットワークＮに適合した通信機能が求められる。
通信インタフェース１４は、ユーザ端末２０等の外部の端末との通信を可能にするデバイスである。通信インタフェース１４には、通信に使用するネットワークＮに適合した通信機能が求められる。
【0026】
＜ユーザ端末のハードウェア構成＞
ユーザ端末２０は、端末全体の動作を制御するプロセッサ２１と、メモリ２２と、補助記憶装置２３と、通信インタフェース２４と、ディスプレイ２５とで構成される。
プロセッサ２１は、例えばＣＰＵである。メモリ２２は、ＢＩＯＳ等が記憶されたＲＯＭやプロセッサ２１のワークエリアとして用いられるＲＡＭで構成される。
補助記憶装置２３は、例えばハードディスク装置や半導体ストレージである。
通信インタフェース２４は、サーバ１０等の外部の端末との通信を可能にするデバイスである。通信インタフェース２４には、通信に使用するネットワークＮに適合した通信機能が求められる。
ディスプレイ２５は、例えば液晶ディスプレイや有機ＥＬ（＝Electro Luminescence）ディスプレイである。
ユーザ端末２０は、端末全体の動作を制御するプロセッサ２１と、メモリ２２と、補助記憶装置２３と、通信インタフェース２４と、ディスプレイ２５とで構成される。
プロセッサ２１は、例えばＣＰＵである。メモリ２２は、ＢＩＯＳ等が記憶されたＲＯＭやプロセッサ２１のワークエリアとして用いられるＲＡＭで構成される。
補助記憶装置２３は、例えばハードディスク装置や半導体ストレージである。
通信インタフェース２４は、サーバ１０等の外部の端末との通信を可能にするデバイスである。通信インタフェース２４には、通信に使用するネットワークＮに適合した通信機能が求められる。
ディスプレイ２５は、例えば液晶ディスプレイや有機ＥＬ（＝Electro Luminescence）ディスプレイである。
【0027】
＜サーバの機能構成＞
図２は、サーバ１０の機能上の構成例を説明する図である。なお、図２に示す機能構成は、プログラムの実行を通じて実現される機能部の一例である。
サーバ１０は、付与部１０１と、第１出力部１０２と、設定部１０３と、第２出力部１０４と、記憶部１１０とを有している。
このうち、記憶部１１０は、メモリ１２（図１参照）と補助記憶装置１３（図１参照）により実現される。
図２は、サーバ１０の機能上の構成例を説明する図である。なお、図２に示す機能構成は、プログラムの実行を通じて実現される機能部の一例である。
サーバ１０は、付与部１０１と、第１出力部１０２と、設定部１０３と、第２出力部１０４と、記憶部１１０とを有している。
このうち、記憶部１１０は、メモリ１２（図１参照）と補助記憶装置１３（図１参照）により実現される。
【0028】
＜記憶部に記憶される情報＞
まず、記憶部１１０に記憶される情報の一例を説明する。
図２に示す記憶部１１０には、プレイヤ情報１１１が記憶されている。
なお、記憶部１１０には、クエスト情報、ゲーム媒体情報、デッキ情報なども記憶される。クエスト情報には、管理の対象であるクエストに関する各種の情報が記憶される。ゲーム媒体情報には、ゲーム媒体の属性と属性値、能力ポイント等が記憶される。デッキ情報には、プレイに使用中のデッキやユーザが登録しているデッキの情報等が記憶される。
まず、記憶部１１０に記憶される情報の一例を説明する。
図２に示す記憶部１１０には、プレイヤ情報１１１が記憶されている。
なお、記憶部１１０には、クエスト情報、ゲーム媒体情報、デッキ情報なども記憶される。クエスト情報には、管理の対象であるクエストに関する各種の情報が記憶される。ゲーム媒体情報には、ゲーム媒体の属性と属性値、能力ポイント等が記憶される。デッキ情報には、プレイに使用中のデッキやユーザが登録しているデッキの情報等が記憶される。
【0029】
＜プレイヤ情報＞
プレイヤ情報１１１には、クエストをプレイするプレイヤに関する各種の情報が記憶される。
図３は、プレイヤ情報１１１の一例を説明する図表である。図３の場合、プレイヤ情報１１１として、ユーザアカウント１１１Ａ、アカウント作成日時１１１Ｂ、プレイ履歴１１１Ｃ、ログイン履歴１１１Ｄ、協同プレイのデッキ選択画面における時間切れの回数１１１Ｅが記憶されている。なお、図３に示す情報は、プレイヤ情報１１１の一例である。
プレイヤ情報１１１には、クエストをプレイするプレイヤに関する各種の情報が記憶される。
図３は、プレイヤ情報１１１の一例を説明する図表である。図３の場合、プレイヤ情報１１１として、ユーザアカウント１１１Ａ、アカウント作成日時１１１Ｂ、プレイ履歴１１１Ｃ、ログイン履歴１１１Ｄ、協同プレイのデッキ選択画面における時間切れの回数１１１Ｅが記憶されている。なお、図３に示す情報は、プレイヤ情報１１１の一例である。
【0030】
ユーザアカウント１１１Ａは、ユーザが登録したアカウントであり、新規登録のたびに追加される。新規登録の際には、ログインパスワードも登録される。図３の場合、ユーザＡ～Ｅに対応するＵ１００～Ｕ１０４が登録されている。
アカウント作成日時１１１Ｂは、アカウントが作成された日時である。図３の場合、Ｕ１０３の作成日時が最も古く、Ｕ１００の作成日時が最も新しい。
プレイ履歴１１１Ｃは、ユーザがゲーム（又はクエスト）をプレイした回数、プレイ回毎のプレイ時間、総プレイ時間、プレイの結果、プレイの種類等である。図３では、協同プレイをプレイした回数を例示している。図３の場合、Ｕ１０３のプレイ回数が最も多く、Ｕ１００のプレイ回数が最も少ない。
アカウント作成日時１１１Ｂは、アカウントが作成された日時である。図３の場合、Ｕ１０３の作成日時が最も古く、Ｕ１００の作成日時が最も新しい。
プレイ履歴１１１Ｃは、ユーザがゲーム（又はクエスト）をプレイした回数、プレイ回毎のプレイ時間、総プレイ時間、プレイの結果、プレイの種類等である。図３では、協同プレイをプレイした回数を例示している。図３の場合、Ｕ１０３のプレイ回数が最も多く、Ｕ１００のプレイ回数が最も少ない。
【0031】
ログイン履歴１１１Ｄは、各ユーザがログインした回数、ログインした日時、ログインしていた時間長等である。図３では、ログインの回数が例示されている。図３の場合、Ｕ１０３のログイン回数が最も多く、Ｕ１００のログイン回数が最も少ない。
協同プレイのデッキ選択画面における時間切れの回数１１１Ｅは、応募した協同プレイで使用するデッキの選択中に時間切れになった回数である。本実施の形態の場合、デッキの選択画面が表示されるのは、応募人数が募集人数に達するまでに応募したユーザだけである。ただし、デッキを選択しないユーザが含まれていると、協同プレイを開始できない。そこで、早期のデッキの選択を促す仕組みとして制限時間が設けられている。ここでの制限時間は、所定時間の一例である。
協同プレイのデッキ選択画面における時間切れの回数１１１Ｅは、この制限時間内にデッキを選択できなかった回数を表している。図３の場合、Ｕ１００の回数が最も多く、Ｕ１０３の回数が最も少ない。
協同プレイのデッキ選択画面における時間切れの回数１１１Ｅは、応募した協同プレイで使用するデッキの選択中に時間切れになった回数である。本実施の形態の場合、デッキの選択画面が表示されるのは、応募人数が募集人数に達するまでに応募したユーザだけである。ただし、デッキを選択しないユーザが含まれていると、協同プレイを開始できない。そこで、早期のデッキの選択を促す仕組みとして制限時間が設けられている。ここでの制限時間は、所定時間の一例である。
協同プレイのデッキ選択画面における時間切れの回数１１１Ｅは、この制限時間内にデッキを選択できなかった回数を表している。図３の場合、Ｕ１００の回数が最も多く、Ｕ１０３の回数が最も少ない。
【0032】
＜機能部で実行される処理＞
以下では、付与部１０１（図２参照）、第１出力部１０２（図２参照）、設定部１０３（図２参照）、第２出力部１０４（図２参照）で実行される基本的な処理機能について説明する。
各機能部に用意されている詳細な処理機能については、想定される処理動作例と関連付けて適時説明する。
以下では、付与部１０１（図２参照）、第１出力部１０２（図２参照）、設定部１０３（図２参照）、第２出力部１０４（図２参照）で実行される基本的な処理機能について説明する。
各機能部に用意されている詳細な処理機能については、想定される処理動作例と関連付けて適時説明する。
【0033】
付与部１０１は、マルチプレイの一形態である協同プレイに応募した複数のユーザのうち、第１条件を満たすユーザ（以下「第１ユーザ」という。）に優先権を付与する機能部である。
ここでの「第１条件」は、優先権を付与するための前提条件であり、例えば「応募の受け付け順番が上限以内である」ことをいう。ここでの上限は、募集人数とする。従って募集人数が３人であれば、応募を受け付けた順番が３位以内のユーザのみが第１条件を満たすことになる。
ここでの「第１条件」は、優先権を付与するための前提条件であり、例えば「応募の受け付け順番が上限以内である」ことをいう。ここでの上限は、募集人数とする。従って募集人数が３人であれば、応募を受け付けた順番が３位以内のユーザのみが第１条件を満たすことになる。
【0034】
このように、第１条件を満たすユーザにのみ優先権を付与することにより、協同プレイへの参加を許可するユーザと協同プレイへの参加を許可しないユーザとを早期に区分することができる。
なお、第１条件は、協同プレイに参加するユーザ（すなわちプレイヤ候補）を募集している１以上のクエストからなるリスト（以下「募集リスト」という。）の中からプレイするクエストの選択を受け付けたタイミング（すなわち選択を受け付けた順番）が他ユーザよりも早いことと規定してもよい。
なお、第１条件は、協同プレイに参加するユーザ（すなわちプレイヤ候補）を募集している１以上のクエストからなるリスト（以下「募集リスト」という。）の中からプレイするクエストの選択を受け付けたタイミング（すなわち選択を受け付けた順番）が他ユーザよりも早いことと規定してもよい。
【0035】
もっとも、第１条件は、応募を受け付けた順番やクエストの選択を受け付けた順番だけでなく、募集条件その他の条件も満たすことを含めてもよい。
募集条件その他の条件には、例えばユーザの能力やレベル、プレイ履歴、ユーザが所持するゲーム媒体のレベル、ホストユーザと友達であること、ホストユーザの近く（例えば４００ｍ以内）にいることがある。
募集条件その他の条件には、例えばユーザの能力やレベル、プレイ履歴、ユーザが所持するゲーム媒体のレベル、ホストユーザと友達であること、ホストユーザの近く（例えば４００ｍ以内）にいることがある。
【0036】
第１条件が「応募を受け付けた順番が上限以内であること」と「募集条件」とで規定される場合、付与部１０１は、募集条件を満たす応募ユーザであって応募を受け付けた順番が上限以内であるユーザに優先権を付与する。
第１条件は、ホストユーザが募集のたびに指定又は編集可能でもよい。
本実施の形態では、ホストユーザが第１条件を指定しない限り、「応募の受け付け順番が上限以内」であることが第１条件として使用される。
第１条件は、ホストユーザが募集のたびに指定又は編集可能でもよい。
本実施の形態では、ホストユーザが第１条件を指定しない限り、「応募の受け付け順番が上限以内」であることが第１条件として使用される。
【0037】
ここでの「優先権」は、協同プレイへの参加が他のユーザよりも優先される権利をいう。優先権を付与されたユーザは、協同プレイへの参加が仮予約された状態となる。ここでのユーザは、プレイヤ候補である。ただし、仮予約であるので、優先権が付与された段階のユーザは、応募した協同プレイへの参加が確定していない。
【0038】
第１出力部１０２は、第１ユーザ（すなわち優先権が付与されたユーザ）が操作する端末２０に、所定操作を受け付けるための画面（以下「第１画面」という。）を表示させる機能部である。
ここでの所定操作は、協同プレイへの参加を確定するための操作をいう。
ここでの所定操作は、協同プレイへの参加を確定するための操作をいう。
【0039】
所定操作は、例えば協同プレイで使用するデッキを選択する操作である。デッキを選択する操作は、例えば画面内の「選択」ボタンのタップ、「決定」ボタンのタップ、「実行」ボタンのタップ、「出撃」ボタンのタップでもよいし、画面内に表示されている特定のデッキのタップ、ダブルタップ、スワイプ、第１画面のタップその他の特定の操作でもよい。
この他、所定操作は、例えばパスワード、合言葉、暗号の入力、ホストユーザが要求する参加条件への同意でもよい。
これらの操作の組み合わせを「所定操作」として用いてもよい。
この他、所定操作は、例えばパスワード、合言葉、暗号の入力、ホストユーザが要求する参加条件への同意でもよい。
これらの操作の組み合わせを「所定操作」として用いてもよい。
【0040】
第１画面には、所定操作の内容に応じ、所定操作の受け付けに使用する画像、アイコン、操作ボタン、説明文などが表示される。
例えば所定操作がデッキの選択である場合、第１画面では、例えば協同プレイで使用するデッキの選択だけでなく、デッキを構成するゲーム媒体の確認の他、デッキを構成する１又は複数体のゲーム媒体の変更も可能である。
なお、事前の設定や選択に基づいて、協同プレイで使用するデッキが自動的に選択されるユーザの場合には、第１画面の表示は、協同プレイで使用するデッキを構成するゲーム媒体の確認に使用される。
例えば所定操作がデッキの選択である場合、第１画面では、例えば協同プレイで使用するデッキの選択だけでなく、デッキを構成するゲーム媒体の確認の他、デッキを構成する１又は複数体のゲーム媒体の変更も可能である。
なお、事前の設定や選択に基づいて、協同プレイで使用するデッキが自動的に選択されるユーザの場合には、第１画面の表示は、協同プレイで使用するデッキを構成するゲーム媒体の確認に使用される。
【0041】
設定部１０３は、第１ユーザ（すなわち優先権が付与されたユーザ）による所定操作が第２条件を満たす場合、第１ユーザを共同プレイのプレイヤに設定する機能部である。
本実施の形態の場合、優先権が付与されたユーザの所定操作が第２条件を更に満たすことで共同プレイのプレイヤに設定される。すなわち、協同プレイへの参加が確定する。
ここでの「第２条件」は、協同プレイへの参加を確定するための条件であり、例えば「第１画面の表示から制限時間内に所定操作を受け付ける」こと、「募集中の協同プレイへの応募から制限時間内に所定操作を受け付ける」こと、「所定操作が正しい内容である」ことのいずれか又は複数をいう。
本実施の形態の場合、優先権が付与されたユーザの所定操作が第２条件を更に満たすことで共同プレイのプレイヤに設定される。すなわち、協同プレイへの参加が確定する。
ここでの「第２条件」は、協同プレイへの参加を確定するための条件であり、例えば「第１画面の表示から制限時間内に所定操作を受け付ける」こと、「募集中の協同プレイへの応募から制限時間内に所定操作を受け付ける」こと、「所定操作が正しい内容である」ことのいずれか又は複数をいう。
【0042】
本実施の形態では、第２条件として、「所定操作を制限時間内に受け付けること」を使用する。ここでの制限時間は、参加の可否を早期に確定するために定められている。本実施の形態では、制限時間として５秒を使用する。もっとも、制限時間は７秒でも１０秒でもよい。また、ホストユーザが、制限時間を指定又は変更できるようにしてもよい。この場合、ホストユーザは、制限時間の調整を通じ、プレイヤとして参加するユーザの確定に介在することが可能になる。
【0043】
なお、付与部１０１には、第２条件を満たさない第１ユーザ（すなわち優先権が付与されたユーザ）が現れた場合、第２条件を満たさなかった第１ユーザに付与されていた優先権を解除する機能も用意される。優先権の解除は、協同プレイを参加する第１ユーザに欠員が発生したことを意味する。
優先権が解除された第１ユーザは、協同プレイに応募したが優先権が付与されなかった他のユーザの一人として扱われる。
なお、解除された優先権は、再付与が可能な状態になる。
優先権が解除された第１ユーザは、協同プレイに応募したが優先権が付与されなかった他のユーザの一人として扱われる。
なお、解除された優先権は、再付与が可能な状態になる。
【0044】
協同プレイは、募集人数分のプレイヤが揃うことでプレイが開始される。このため、第１ユーザの欠員を早期に埋める必要がある。
そこで、付与部１０１には、第２条件を満たさなかった第１ユーザに付与されていた優先権を、協同プレイに応募したタイミングが早い他のユーザに付与する機能も用意されている。なお、応募のタイミングは、第２条件を満たさないことが確定した時点以降に受け付けた順位で特定してもよいし、優先権が実際に解除された以降に受け付けた順位で特定してもよい。
この機能により、第２条件を満たした第１ユーザ以外の他のユーザには、協同プレイへの参加の機会が付与される。
そこで、付与部１０１には、第２条件を満たさなかった第１ユーザに付与されていた優先権を、協同プレイに応募したタイミングが早い他のユーザに付与する機能も用意されている。なお、応募のタイミングは、第２条件を満たさないことが確定した時点以降に受け付けた順位で特定してもよいし、優先権が実際に解除された以降に受け付けた順位で特定してもよい。
この機能により、第２条件を満たした第１ユーザ以外の他のユーザには、協同プレイへの参加の機会が付与される。
【0045】
もっとも、募集に応募した他のユーザに優先権が付与される前に、優先権が解除されたユーザが所定操作を行った場合（例えば制限時間の経過直後に所定操作を行った場合）、同ユーザによるプレイヤとしての協同プレイへの参加が認められる。制限時間外であるが、所定操作が第２条件を満たすことで、協同プレイへの参加が確定するためである。
そもそも、優先権が解除されたユーザは、応募のタイミングが他のユーザよりも早かったユーザであるし、新たに他のプレイヤに優先権を付与してデッキの選択を待つよりも、協同プレイを早く開始できるためである。
そもそも、優先権が解除されたユーザは、応募のタイミングが他のユーザよりも早かったユーザであるし、新たに他のプレイヤに優先権を付与してデッキの選択を待つよりも、協同プレイを早く開始できるためである。
【0046】
ところで、優先権が解除されたユーザが他のユーザよりも先に所定操作を行った後も、他のユーザに解除された優先権が付与されると、前述した課題が生じる。すなわち、所定操作を受け付けるための第１画面が表示されてデッキを選択したのに協同プレイには参加できない旨が通知される事態である。
そこで、優先権が解除されたユーザが他のユーザに優先権が付与されるより先に所定操作を行った場合には、解除された優先権を他のユーザに付与できない状態に制御する。例えば解除された優先権は、優先権の解除後に所定操作を行ったユーザに再度付与されたものとみなす。
そこで、優先権が解除されたユーザが他のユーザに優先権が付与されるより先に所定操作を行った場合には、解除された優先権を他のユーザに付与できない状態に制御する。例えば解除された優先権は、優先権の解除後に所定操作を行ったユーザに再度付与されたものとみなす。
【0047】
第２出力部１０４は、複数のユーザのうち、第１条件を満たさない第２ユーザ（すなわち優先権が付与されていないユーザ）が操作する端末２０に、協同プレイへの参加不可を通知する画面（以下「第２画面」という。）を表示させる機能部である。
第２画面には、協同プレイに参加できないことをユーザに通知するための画像、アイコン、説明文などが表示される。
なお、優先権が解除されたユーザが制限時間後に所定操作を行った時点で他のユーザに優先権が付与されていた場合、優先権が解除されたユーザにも第２画面が表示される。
第２画面には、協同プレイに参加できないことをユーザに通知するための画像、アイコン、説明文などが表示される。
なお、優先権が解除されたユーザが制限時間後に所定操作を行った時点で他のユーザに優先権が付与されていた場合、優先権が解除されたユーザにも第２画面が表示される。
【0048】
【0049】
＜協同プレイの募集リスト＞
図４は、協同プレイの募集リスト２００の一例を説明する図である。
図４に示す募集リスト２００には、４つの募集掲示板２０１と「再検索」ボタン２０２が配置されている。
４つの募集掲示板２０１は、いずれも共通のレイアウトを有している。
図４の場合、募集掲示板２０１は、ホストキャラアイコン２１１と、ホスト名２１２と、クエスト名２１３と、クエストのボスキャラ名２１４と、クエストアイコン２１５と、ホスト勲章２１６とで構成される。
図４は、協同プレイの募集リスト２００の一例を説明する図である。
図４に示す募集リスト２００には、４つの募集掲示板２０１と「再検索」ボタン２０２が配置されている。
４つの募集掲示板２０１は、いずれも共通のレイアウトを有している。
図４の場合、募集掲示板２０１は、ホストキャラアイコン２１１と、ホスト名２１２と、クエスト名２１３と、クエストのボスキャラ名２１４と、クエストアイコン２１５と、ホスト勲章２１６とで構成される。
【0050】
ホストキャラアイコン２１１には、ホストユーザが協同プレイで使用するゲーム媒体のアイコンが表示される。ここでのゲーム媒体は、ホストユーザが選択したデッキの先頭に位置するゲーム媒体である。従って、ホストユーザが同じでもデッキの先頭に位置するゲーム媒体が異なれば、異なるアイコンが表示される。また、ホストユーザが異なっても、デッキの先頭に位置するゲーム媒体が同じ場合、同じアイコンが表示される。
【0051】
ホスト名２１２は、ホストユーザのユーザ名である。ホスト名２１２には、ホストユーザが登録したニックネーム等が表示される。ホスト名２１２は、テキストで表示される。ホスト名２１２を通じ、ユーザは、ホストユーザの識別が可能になる。
クエスト名２１３は、協同プレイの対象であるクエストの名前である。クエスト名２１３はテキストで表示される。クエスト名２１３を通じ、ユーザは、クエストの識別が可能である。
クエスト名２１３は、協同プレイの対象であるクエストの名前である。クエスト名２１３はテキストで表示される。クエスト名２１３を通じ、ユーザは、クエストの識別が可能である。
【0052】
クエストのボスキャラ名２１４は、協同プレイの対象であるクエストに出現するボスキャラの名前である。ボスキャラ名２１４は、テキストで表示される。ボスキャラ名２１４を通じ、ユーザは、クエストのクリアにより取得されるボスキャラの識別が可能になる。
クエストアイコン２１５は、協同プレイの対象であるクエストについて登録されているアイコンである。
クエストアイコン２１５は、協同プレイの対象であるクエストについて登録されているアイコンである。
【0053】
ホスト勲章２１６は、ホストユーザが所持している勲章のアイコンである。ホスト勲章２１６は、ホストユーザのプレイヤとしての能力を表している。ホスト勲章２１６は、勲章の表示を設定したホストユーザについてのみ表示される。従って、上から２つ目と３つ目の募集掲示板２０１にはホスト勲章２１６が表示されていない。
なお、プレイヤの募集は、適時終了するので「再検索」ボタン２０２を操作すると、募集リスト２００の表示内容は、操作時点で募集されている協同プレイに関する募集掲示板２０１に切り替わる。
なお、プレイヤの募集は、適時終了するので「再検索」ボタン２０２を操作すると、募集リスト２００の表示内容は、操作時点で募集されている協同プレイに関する募集掲示板２０１に切り替わる。
【0054】
＜処理動作例＞
図５は、協同プレイのプレイヤが募集される場合の処理動作例を説明するフローチャートである。なお、図中に示す記号のＳはステップを意味している。
図５に示す処理動作は、サーバ１０（図１参照）のプロセッサ１１（図１参照）が、付与部１０１、第１出力部１０２、設定部１０３、第２出力部１０４の連携により実行する。
図５は、協同プレイのプレイヤが募集される場合の処理動作例を説明するフローチャートである。なお、図中に示す記号のＳはステップを意味している。
図５に示す処理動作は、サーバ１０（図１参照）のプロセッサ１１（図１参照）が、付与部１０１、第１出力部１０２、設定部１０３、第２出力部１０４の連携により実行する。
【0055】
図５に示す処理動作は、協同プレイに参加するプレイヤの募集が開始されると同時に開始される。
なお、図５に示す処理動作は、協同プレイが開始されていない募集掲示板２０１（図４参照）が終了するまで、ユーザ単位で繰り返し実行される。従って、一度に複数の応募が検出された場合、図５に示す処理動作が複数並列に実行される。
なお、図５に示す処理動作は、協同プレイが開始されていない募集掲示板２０１（図４参照）が終了するまで、ユーザ単位で繰り返し実行される。従って、一度に複数の応募が検出された場合、図５に示す処理動作が複数並列に実行される。
【0056】
まず、プロセッサ１１は、応募の受け付けか否かを判定する（ステップ１）。応募は、協同プレイへの参加を希望するユーザが、募集リスト２００に表示されている募集掲示板２０１の中から１つを選択することにより実行される。
対象とする募集掲示板２０１に対する応募が検出されない場合、ステップ１で否定結果が得られる。この場合、プロセッサ１１は、ステップ１の判定を繰り返す。
対象とする募集掲示板２０１に対する応募が検出された場合、ステップ１で肯定結果が得られる。この場合、プロセッサ１１は、募集人数に空きがあるか否かを判定する（ステップ２）。本実施の形態の場合、募集人数は３人である。
対象とする募集掲示板２０１に対する応募が検出されない場合、ステップ１で否定結果が得られる。この場合、プロセッサ１１は、ステップ１の判定を繰り返す。
対象とする募集掲示板２０１に対する応募が検出された場合、ステップ１で肯定結果が得られる。この場合、プロセッサ１１は、募集人数に空きがあるか否かを判定する（ステップ２）。本実施の形態の場合、募集人数は３人である。
【0057】
募集人数の空きが１人以上の場合（すなわち第１条件を満たす場合）、ステップ２で肯定結果が得られる。この場合、プロセッサ１１は、応募者であるユーザ（すなわち第１ユーザ）に優先権を付与する（ステップ３）。
続いて、プロセッサ１１は、優先権を付与したユーザが操作するユーザ端末にデッキ選択画面を表示する（ステップ４）。
続いて、プロセッサ１１は、優先権を付与したユーザが操作するユーザ端末にデッキ選択画面を表示する（ステップ４）。
【0058】
図６は、実施の形態１におけるデッキ選択画面２２０の表示例を説明する図である。ここでのデッキ選択画面２２０は、第１画面の一例である。本実施の形態の場合、デッキ選択画面２２０には、例えば対象とするクエストで前回のプレイ時に使用したデッキや前回のクリア時で使用したデッキが初期画面として表示される。
図６に示すデッキ選択画面２２０は、デッキ名２２１と、デッキを構成するゲーム媒体のアイコン一覧２２２と、「詳細」ボタン２２３と、「一括編成」ボタン２２４と、「出撃」ボタン２２５と、残り時間表示２２６とで構成されている。
図６に示すデッキ選択画面２２０は、デッキ名２２１と、デッキを構成するゲーム媒体のアイコン一覧２２２と、「詳細」ボタン２２３と、「一括編成」ボタン２２４と、「出撃」ボタン２２５と、残り時間表示２２６とで構成されている。
【0059】
図６の場合、アイコン一覧２２２には、３体のゲーム媒体に対応するアイコンが表示されている。アイコン一覧２２２の左端が先頭位置である。従って、このデッキが選択された場合、アイコン一覧２２２の左端に位置するアイコン（ハートマークのアイコン）に対応するゲーム媒体が協同プレイで使用される。
「詳細」ボタン２２３を操作すると、アイコン一覧２２２に表示された３体のゲーム媒体の詳細情報が画面上に表示される。
「詳細」ボタン２２３を操作すると、アイコン一覧２２２に表示された３体のゲーム媒体の詳細情報が画面上に表示される。
【0060】
「一括編成」ボタン２２４を操作すると、デッキを構成する３体のゲーム媒体をまとめて変更するための画面に遷移する。
「出撃」ボタン２２５は、協同プレイで使用するデッキの選択に使用されるボタンであり、「出撃」ボタン２２５の操作により協同プレイで使用するデッキが確定する。すなわち、共同プレイで使用するゲーム媒体が確定する。この「出撃」ボタン２２５の操作は、所定操作に該当する。
「出撃」ボタン２２５は、協同プレイで使用するデッキの選択に使用されるボタンであり、「出撃」ボタン２２５の操作により協同プレイで使用するデッキが確定する。すなわち、共同プレイで使用するゲーム媒体が確定する。この「出撃」ボタン２２５の操作は、所定操作に該当する。
【0061】
残り時間表示２２６は、「出撃」ボタン２２５の操作が求められる残り時間の通知に用いられる。残りゲージ２２６Ｂは、残り時間の長さをゲージの長さで表示する表示欄である。
協同プレイへの参加を希望するユーザには、残り時間２２６Ａの表示が「０秒」になるまでに「出撃」ボタン２２５の操作が求められる。残り時間２２６Ａが「０秒」になるまでは、優先権が付与された状態が維持される。一方、残り時間２２６Ａが「０秒」になるまでに「出撃」ボタン２２５の操作がない場合、付与された優先権が解除される。
協同プレイへの参加を希望するユーザには、残り時間２２６Ａの表示が「０秒」になるまでに「出撃」ボタン２２５の操作が求められる。残り時間２２６Ａが「０秒」になるまでは、優先権が付与された状態が維持される。一方、残り時間２２６Ａが「０秒」になるまでに「出撃」ボタン２２５の操作がない場合、付与された優先権が解除される。
【0062】
図５の説明に戻る。
ステップ２において否定結果が得られた場合（すなわち、応募の受け付け時に募集人数に空きがなかった場合）、プロセッサ１１は、該当するユーザの端末２０に、応募した協同プレイへの参加不可を通知するダイアログボックスを出力する（ステップ５）。
図７は、ダイアログボックス２３０の表示例を説明する図である。図７には、図４との対応部分に対応する符号を付して示している。
ステップ２において否定結果が得られた場合（すなわち、応募の受け付け時に募集人数に空きがなかった場合）、プロセッサ１１は、該当するユーザの端末２０に、応募した協同プレイへの参加不可を通知するダイアログボックスを出力する（ステップ５）。
図７は、ダイアログボックス２３０の表示例を説明する図である。図７には、図４との対応部分に対応する符号を付して示している。
【0063】
図７の場合、ダイアログボックス２３０は、募集リスト２００の画面に重ねて表示され、選択した募集掲示板２０１に参加できないことがユーザに通知されている。このダイアログボックス２３０は、第２画面の一例である。
図７の場合、ダイアログボックス２３０には「ダイアログ」、「部屋に入れませんでした」と表示されている。因みに、「部屋」は、協同プレイの対象であるクエストや協同プレイに参加するプレイヤが集まる仮想の部屋を表している。
なお、ダイアログボックス２３０の表現は一例であり、プレイに参加できないことが伝われば、「クエストにうまく接続できませんでした」等の別の表現を用いてもよい。
図７の場合、ダイアログボックス２３０には「ダイアログ」、「部屋に入れませんでした」と表示されている。因みに、「部屋」は、協同プレイの対象であるクエストや協同プレイに参加するプレイヤが集まる仮想の部屋を表している。
なお、ダイアログボックス２３０の表現は一例であり、プレイに参加できないことが伝われば、「クエストにうまく接続できませんでした」等の別の表現を用いてもよい。
【0064】
図５の説明に戻る。具体的には、デッキ選択画面２２０（図６参照）が表示された場面に戻る。
優先権が付与されたユーザの端末２０にデッキ選択画面２２０が表示されると、プロセッサ１１は、制限時間内か否かを判定する（ステップ６）。
制限時間は、予め定められている。前述したように、本実施の形態の場合、制限時間は５秒である。
計測の開始時は５秒であるので、ステップ６で肯定結果が得られる。この場合、プロセッサ１１は、所定操作を受け付けたか否かを判定する（ステップ７）。
優先権が付与されたユーザの端末２０にデッキ選択画面２２０が表示されると、プロセッサ１１は、制限時間内か否かを判定する（ステップ６）。
制限時間は、予め定められている。前述したように、本実施の形態の場合、制限時間は５秒である。
計測の開始時は５秒であるので、ステップ６で肯定結果が得られる。この場合、プロセッサ１１は、所定操作を受け付けたか否かを判定する（ステップ７）。
【0065】
所定操作は、デッキの選択等の協同プレイへの参加を確定するための操作である。
所定操作が検出されない場合、ステップ７で否定結果が得られる。この場合、プロセッサ１１は、ステップ６に戻る。
所定操作が検出されない状態が継続すると、計測の開始からの時間が制限時間を経過し、ステップ６で否定結果が得られる。
この場合、プロセッサ１１は、デッキ選択画面２２０の表示後も制限時間内に所定操作を行わなかったユーザの優先権を解除する（ステップ８）。
所定操作が検出されない場合、ステップ７で否定結果が得られる。この場合、プロセッサ１１は、ステップ６に戻る。
所定操作が検出されない状態が継続すると、計測の開始からの時間が制限時間を経過し、ステップ６で否定結果が得られる。
この場合、プロセッサ１１は、デッキ選択画面２２０の表示後も制限時間内に所定操作を行わなかったユーザの優先権を解除する（ステップ８）。
【0066】
図８は、制限時間が経過した後のデッキ選択画面２２０の表示例を説明する図である。図８には、図６との対応部分に対応する符号を付して示している。
図８の場合、残り時間２２６Ａの表示が「０秒」となり、残りゲージ２２６Ｂの表示も消えている。
残り時間２２６Ａの表示が「０」秒でも各種ボタンの操作は可能である。なお、図８では不図示であるが、優先権が解除された旨をポップアップで表示してもよい。例えば「あなたの優先権は解除されました。デッキを選択しても協同プレイに参加できない可能性があります。」と表示してもよい。
図８の場合、残り時間２２６Ａの表示が「０秒」となり、残りゲージ２２６Ｂの表示も消えている。
残り時間２２６Ａの表示が「０」秒でも各種ボタンの操作は可能である。なお、図８では不図示であるが、優先権が解除された旨をポップアップで表示してもよい。例えば「あなたの優先権は解除されました。デッキを選択しても協同プレイに参加できない可能性があります。」と表示してもよい。
【0067】
優先権の解除により募集人数に空きが生じる。このため、優先権の解除後に別のユーザから応募があると、ステップ２で肯定結果が得られ、優先権が付与される（ステップ３）。
優先権が新たに付与された別のユーザには、ステップ４以降の処理が実行される。
図５の説明に戻る。
ステップ８で優先権が解除されると、プロセッサ１１は、他のユーザに優先権が付与される前に所定操作を受け付けたか否かを判定する（ステップ９）。
優先権が解除されたユーザによる所定操作を受け付ける前に他のユーザに対して優先権が付与されていた場合、ステップ９で否定結果が得られる。この場合、プロセッサ１１は、ステップ５に戻り、ユーザの操作画面にダイアログボックス２３０を表示する。
優先権が新たに付与された別のユーザには、ステップ４以降の処理が実行される。
図５の説明に戻る。
ステップ８で優先権が解除されると、プロセッサ１１は、他のユーザに優先権が付与される前に所定操作を受け付けたか否かを判定する（ステップ９）。
優先権が解除されたユーザによる所定操作を受け付ける前に他のユーザに対して優先権が付与されていた場合、ステップ９で否定結果が得られる。この場合、プロセッサ１１は、ステップ５に戻り、ユーザの操作画面にダイアログボックス２３０を表示する。
【0068】
図９は、優先権の解除後に所定操作を行ったユーザに表示されるダイアログボックス２３０の表示例を説明する図である。図９には、図７及び図８との対応部分に対応する符号を付して示している。
図９に示すダイアログボックス２３０は、デッキを選択したユーザに表示されるので、デッキ選択画面２２０に重ねて表示されている。この点が、協同プレイに応募した時点で参加の不可が通知されるユーザに表示されるダイアログボックス２３０（図７参照）と異なっている。
図９に示すダイアログボックス２３０は、デッキを選択したユーザに表示されるので、デッキ選択画面２２０に重ねて表示されている。この点が、協同プレイに応募した時点で参加の不可が通知されるユーザに表示されるダイアログボックス２３０（図７参照）と異なっている。
【0069】
図５の説明に戻る。
他のユーザに優先権が付与される前に、優先権が解除されたユーザ本人の所定操作があった場合、ステップ９で肯定結果が得られる。
ステップ７で肯定結果が得られた場合、又は、ステップ９で肯定結果が得られた場合、プロセッサ１１は、該当するユーザを協同プレイのプレイヤに設定する（ステップ１０）。
ステップ５の実行後、又は、ステップ１０の実行後、プロセッサ１１は、全てのプレイヤが確定したか否かを判定する（ステップ１１）。
他のユーザに優先権が付与される前に、優先権が解除されたユーザ本人の所定操作があった場合、ステップ９で肯定結果が得られる。
ステップ７で肯定結果が得られた場合、又は、ステップ９で肯定結果が得られた場合、プロセッサ１１は、該当するユーザを協同プレイのプレイヤに設定する（ステップ１０）。
ステップ５の実行後、又は、ステップ１０の実行後、プロセッサ１１は、全てのプレイヤが確定したか否かを判定する（ステップ１１）。
【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】
変更の操作を受け付けた場合、ステップ３１で肯定結果が得られる。この場合、プロセッサ１１は、制限時間を延長する（ステップ３２）。この後、プロセッサ１１は、ステップ７に進む。
一方、変更の操作を受け付けていない場合、ステップ３１で否定結果が得られる。この場合、プロセッサ１１は、ステップ３２をスキップし、ステップ７に直接移行する。
この後の処理動作は図５と同じである。すなわち、所定操作を受け付けたか否かが判定され、判定結果に応じてステップ６又はステップ１０が実行される。
一方、変更の操作を受け付けていない場合、ステップ３１で否定結果が得られる。この場合、プロセッサ１１は、ステップ３２をスキップし、ステップ７に直接移行する。
この後の処理動作は図５と同じである。すなわち、所定操作を受け付けたか否かが判定され、判定結果に応じてステップ６又はステップ１０が実行される。
【0097】
＜小括＞
以上説明したように、本実施の形態におけるサーバ１０（図１参照）には、デッキの選択中（すなわちゲーム媒体の選択中）にデッキの変更（すなわちゲーム媒体の変更）に関する操作を受け付けた場合に制限時間を延長する機能が設けられる。
この機能により、参加の蓋然性が高いユーザが時間切れで協同プレイに参加できない事態を回避できる。
以上説明したように、本実施の形態におけるサーバ１０（図１参照）には、デッキの選択中（すなわちゲーム媒体の選択中）にデッキの変更（すなわちゲーム媒体の変更）に関する操作を受け付けた場合に制限時間を延長する機能が設けられる。
この機能により、参加の蓋然性が高いユーザが時間切れで協同プレイに参加できない事態を回避できる。
【0098】
＜実施の形態４＞
本実施の形態も、実施の形態１で説明した情報処理システム１（図１参照）のシステム構成及び処理動作を前提とする。なお、本実施の形態で説明する処理動作は、前述した各実施の形態との組み合わせも可能である。
前述の実施の形態３では、制限期間中におけるゲーム媒体の変更に連動して制限時間を延長する機能について説明したが、本実施の形態では、第１ユーザ（優先権が付与されたユーザ）の属性に基づいて第１ユーザに適用する制限時間を個別に設定する場合について説明する。
ここでの属性には、例えばユーザのプレイ履歴、第２条件を満たさなかった回数（すなわち時間切れの回数）、ログイン回数、アカウントの作成日時、所定価値の消費履歴の有無や消費額を使用する。もっとも、これらは一例である。以下では、これらの属性例別に具体例を説明する。
本実施の形態も、実施の形態１で説明した情報処理システム１（図１参照）のシステム構成及び処理動作を前提とする。なお、本実施の形態で説明する処理動作は、前述した各実施の形態との組み合わせも可能である。
前述の実施の形態３では、制限期間中におけるゲーム媒体の変更に連動して制限時間を延長する機能について説明したが、本実施の形態では、第１ユーザ（優先権が付与されたユーザ）の属性に基づいて第１ユーザに適用する制限時間を個別に設定する場合について説明する。
ここでの属性には、例えばユーザのプレイ履歴、第２条件を満たさなかった回数（すなわち時間切れの回数）、ログイン回数、アカウントの作成日時、所定価値の消費履歴の有無や消費額を使用する。もっとも、これらは一例である。以下では、これらの属性例別に具体例を説明する。
【0099】
＜具体例１：プレイ履歴による設定＞
具体例１の設定部１０３（図２参照）には、第１ユーザ（優先権が付与されたユーザ）のプレイ履歴に応じ、第１ユーザに適用する制限時間を個別に設定する機能を設ける。
図１８は、実施の形態４の具体例１に係る処理動作例を説明するフローチャートである。図１８に示す処理動作は、例えば図５に示す処理動作や図１７に示す処理動作と並列に実行される。
具体例１の設定部１０３（図２参照）には、第１ユーザ（優先権が付与されたユーザ）のプレイ履歴に応じ、第１ユーザに適用する制限時間を個別に設定する機能を設ける。
図１８は、実施の形態４の具体例１に係る処理動作例を説明するフローチャートである。図１８に示す処理動作は、例えば図５に示す処理動作や図１７に示す処理動作と並列に実行される。
【0100】
まず、プロセッサ１１は、優先権が付与されたユーザのプレイ履歴を取得する（ステップ４１）。この具体例では、プレイ履歴として、ユーザがゲーム（クエスト）をプレイした回数を使用する。もっとも、プレイ履歴として、プレイ回毎のプレイ時間、総プレイ時間、プレイの結果、プレイの種類等を取得してもよい。
次に、プロセッサ１１は、取得されたプレイ履歴に応じ、ユーザ毎に制限時間を設定する（ステップ４２）。例えば募集人数が３名の場合、３名の制限時間がいずれも異なることも起こり得る。
次に、プロセッサ１１は、取得されたプレイ履歴に応じ、ユーザ毎に制限時間を設定する（ステップ４２）。例えば募集人数が３名の場合、３名の制限時間がいずれも異なることも起こり得る。
【0101】
プロセッサ１１は、基本的に、プレイに慣れていないユーザの制限時間を長く設定し、プレイに慣れているユーザの制限時間を短く設定する。
もっとも、制限時間には最小値（例えば５秒）を設け、制限時間が短くなり過ぎないようにする。プレイに慣れているユーザであっても、制限時間を短くし過ぎたのでは時間切れが多発する懸念があるためである。
もっとも、制限時間には最小値（例えば５秒）を設け、制限時間が短くなり過ぎないようにする。プレイに慣れているユーザであっても、制限時間を短くし過ぎたのでは時間切れが多発する懸念があるためである。
【0102】
なお、プレイに慣れていないユーザをプレイに参加し易くする目的とは言え、制限時間を長くし過ぎると、他のプレイヤの不満を招く可能性も高くなる。従って、設定可能な制限時間には上限を設けることが望ましい。
また、基本的に、各ユーザは、他のユーザの制限時間を知り得ない。そこで、最もプレイに慣れていないユーザの制限時間を、他のユーザにも一律に適用してもよい。この場合、他のユーザには制限時間の延長という利益が付与されることになる。また、他のユーザは、残り時間表示２２６（図６参照）に示される初期値の違いからプレイに慣れていないユーザの存在に気付くことも可能になる。また、協同プレイが開始するおおよその時期を予測することも可能になる。
また、基本的に、各ユーザは、他のユーザの制限時間を知り得ない。そこで、最もプレイに慣れていないユーザの制限時間を、他のユーザにも一律に適用してもよい。この場合、他のユーザには制限時間の延長という利益が付与されることになる。また、他のユーザは、残り時間表示２２６（図６参照）に示される初期値の違いからプレイに慣れていないユーザの存在に気付くことも可能になる。また、協同プレイが開始するおおよその時期を予測することも可能になる。
【0103】
図１９は、プレイヤ情報１１１のプレイ履歴１１１Ｃと制限時間との関係を説明する図である。図１９には、図３との対応部分に対応する符号を付して示している。図１９の場合、プレイ履歴１１１Ｃとしてプレイ回数を例示している。
図１９では、Ｕ１００～Ｕ１０２の３名に優先権が付与された場合を仮定する。図１９の場合、プレイ回数が１回のＵ１００には、制限時間として２０秒が設定されている。また、プレイ回数が１０２回のＵ１０１には、制限時間として５秒が設定されている。また、プレイ回数が６５回のＵ１０２には、制限時間として７秒が設定されている。
図１９では、Ｕ１００～Ｕ１０２の３名に優先権が付与された場合を仮定する。図１９の場合、プレイ回数が１回のＵ１００には、制限時間として２０秒が設定されている。また、プレイ回数が１０２回のＵ１０１には、制限時間として５秒が設定されている。また、プレイ回数が６５回のＵ１０２には、制限時間として７秒が設定されている。
【0104】
＜具体例２：時間切れの回数による設定＞
具体例２の設定部１０３（図２参照）には、第１ユーザ（優先権が付与されたユーザ）が制限時間内に第２条件を満たさなかった回数に応じ、第１ユーザに適用する制限時間を個別に設定する機能を設ける。より具体的には、設定部１０３には、制限時間内に第２条件を満たさなかった回数が多い第１ユーザのための制限時間（以下「第１所定時間」ともいう。）を、制限時間内に第２条件を満たさなかった回数が少ない第１ユーザのための制限時間（以下「第２所定時間」ともいう。）よりも長く設定する機能を設ける。
具体例２の設定部１０３（図２参照）には、第１ユーザ（優先権が付与されたユーザ）が制限時間内に第２条件を満たさなかった回数に応じ、第１ユーザに適用する制限時間を個別に設定する機能を設ける。より具体的には、設定部１０３には、制限時間内に第２条件を満たさなかった回数が多い第１ユーザのための制限時間（以下「第１所定時間」ともいう。）を、制限時間内に第２条件を満たさなかった回数が少ない第１ユーザのための制限時間（以下「第２所定時間」ともいう。）よりも長く設定する機能を設ける。
【0105】
【0106】
まず、プロセッサ１１は、優先権が付与されたユーザの協同プレイのデッキ選択画面における時間切れの回数を取得する（ステップ５１）。
なお、時間切れの回数は、直近の所定期間（例えば６ヵ月）に出現した回数に限定することが好ましい。所定期間の制限がないと、現在ではプレイに慣れているユーザを、不慣れな時期の回数で評価することになるからである。
次に、プロセッサ１１は、取得された時間切れの回数に応じ、ユーザ毎に制限時間を設定する（ステップ５２）。この具体例では、時間切れの回数は、プレイへの慣れを表す指標として使用する。
なお、時間切れの回数は、直近の所定期間（例えば６ヵ月）に出現した回数に限定することが好ましい。所定期間の制限がないと、現在ではプレイに慣れているユーザを、不慣れな時期の回数で評価することになるからである。
次に、プロセッサ１１は、取得された時間切れの回数に応じ、ユーザ毎に制限時間を設定する（ステップ５２）。この具体例では、時間切れの回数は、プレイへの慣れを表す指標として使用する。
【0107】
従って、プロセッサ１１は、時間切れの回数が多いユーザの制限時間（すなわち第１所定期間）を長く設定し、時間切れの回数が少ないユーザの制限時間（すなわち第２所定期間）を短く設定する。
なお、具体例１と同様、制限時間には最小値（例えば５秒）を設け、制限時間が短くなり過ぎないようにする。
なお、具体例１と同様、制限時間には最小値（例えば５秒）を設け、制限時間が短くなり過ぎないようにする。
【0108】
図２１は、協同プレイのデッキ選択画面２２０（図６参照）における時間切れの回数１１１Ｅと制限時間との関係を説明する図である。図２１には、図３との対応部分に対応する符号を付して示している。
図２１の場合も、Ｕ１００～Ｕ１０２の３名に優先権が付与された場合を仮定する。図２１の場合、時間切れの回数が５回のＵ１００には、制限時間として２０秒が設定されている。また、時間切れの回数が０回のＵ１０１には、制限時間として５秒が設定されている。また、時間切れの回数が１回のＵ１０２には、制限時間として７秒が設定されている。
図２１の場合も、Ｕ１００～Ｕ１０２の３名に優先権が付与された場合を仮定する。図２１の場合、時間切れの回数が５回のＵ１００には、制限時間として２０秒が設定されている。また、時間切れの回数が０回のＵ１０１には、制限時間として５秒が設定されている。また、時間切れの回数が１回のＵ１０２には、制限時間として７秒が設定されている。
【0109】
＜具体例３：ログイン履歴による設定＞
具体例３の設定部１０３（図２参照）には、第１ユーザ（優先権が付与されたユーザ）のログイン履歴に応じ、第１ユーザに適用する制限時間を個別に設定する機能を設ける。より具体的には、設定部１０３には、ログインの回数が少ない第１ユーザのための制限時間（すなわち「第１所定時間」）を、ログインの回数が多い第１ユーザのための制限時間（すなわち第２所定時間）よりも長く設定する機能を設ける。
具体例３の設定部１０３（図２参照）には、第１ユーザ（優先権が付与されたユーザ）のログイン履歴に応じ、第１ユーザに適用する制限時間を個別に設定する機能を設ける。より具体的には、設定部１０３には、ログインの回数が少ない第１ユーザのための制限時間（すなわち「第１所定時間」）を、ログインの回数が多い第１ユーザのための制限時間（すなわち第２所定時間）よりも長く設定する機能を設ける。
【0110】
【0111】
まず、プロセッサ１１は、優先権が付与されたユーザのログイン履歴を取得する（ステップ６１）。この具体例では、ログイン履歴として各ユーザがログインした回数を取得する。もっとも、ログイン履歴として、ログインの日時、ログインしていた時間長等を取得してもよい。
次に、プロセッサ１１は、取得されたログイン履歴に応じ、ユーザ毎に制限時間を設定する（ステップ６２）。
次に、プロセッサ１１は、取得されたログイン履歴に応じ、ユーザ毎に制限時間を設定する（ステップ６２）。
【0112】
この具体例では、ログインの回数が多いユーザほどプレイに慣れていると評価する。従って、プロセッサ１１は、ログイン回数が少ないユーザの制限時間（すなわち第１所定期間）を長く設定し、ログイン回数が多いユーザの制限時間（すなわち第２所定期間）を短く設定する。
他の具体例と同様、制限時間には最小値（例えば５秒）を設け、制限時間が短くなり過ぎないようにする。
他の具体例と同様、制限時間には最小値（例えば５秒）を設け、制限時間が短くなり過ぎないようにする。
【0113】
図２３は、ログイン履歴１１１Ｄと制限時間との関係を説明する図である。図２３には、図３との対応部分に対応する符号を付して示している。
図２３の場合も、Ｕ１００～Ｕ１０２の３名に優先権が付与された場合を仮定する。図２３の場合、ログイン回数が１回のＵ１００には、制限時間として２０秒が設定されている。また、ログイン回数が５６回のＵ１０１には、制限時間として５秒が設定されている。また、ログイン回数が３６回のＵ１０２には、制限時間として７秒が設定されている。
図２３の場合も、Ｕ１００～Ｕ１０２の３名に優先権が付与された場合を仮定する。図２３の場合、ログイン回数が１回のＵ１００には、制限時間として２０秒が設定されている。また、ログイン回数が５６回のＵ１０１には、制限時間として５秒が設定されている。また、ログイン回数が３６回のＵ１０２には、制限時間として７秒が設定されている。
【0114】
＜具体例４：アカウントの作成日時による設定＞
具体例４の設定部１０３（図２参照）には、第１ユーザ（優先権が付与されたユーザ）のアカウントの作成日時に応じ、第１ユーザに適用する制限時間を個別に設定する機能を設ける。より具体的には、設定部１０３には、アカウントの作成からの日数が短い第１ユーザのための制限時間（すなわち「第１所定時間」）を、アカウントの作成からの日数が長い第１ユーザのための制限時間（すなわち第２所定時間）よりも長く設定する機能を設ける。
具体例４の設定部１０３（図２参照）には、第１ユーザ（優先権が付与されたユーザ）のアカウントの作成日時に応じ、第１ユーザに適用する制限時間を個別に設定する機能を設ける。より具体的には、設定部１０３には、アカウントの作成からの日数が短い第１ユーザのための制限時間（すなわち「第１所定時間」）を、アカウントの作成からの日数が長い第１ユーザのための制限時間（すなわち第２所定時間）よりも長く設定する機能を設ける。
【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】
１…情報処理システム、１０…サーバ、１１、２１…プロセッサ、１２、２２…メモリ、１３、２３…補助記憶装置、１４、２４…通信インタフェース、２５…ディスプレイ、２０、２０Ａ、２０Ｂ、２０Ｃ、２０Ｄ、２０Ｅ、２０Ｗ…ユーザ端末、１０１…付与部、１０１…通知部、１０２…第１出力部、１０３…設定部、１０４…第２出力部、１１０…記憶部
【図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】
【図29】
【図30】
