(57)【要約】【課題】ユーザーが入手するカードについて、ユーザーの希望を反映させる新たな方法を実現させるオンラインゲームサーバーを提供する。【解決手段】サーバー１０（オンラインゲームサーバー）は、複数の仮想的なカードを用いたゲームを、少なくとも１人のユーザーに対して、通信ネットワーク２０を介して提供する。サーバー１０は、ユーザーからのレンタル指示（第１の指示）に応じて、レンタルの対象となるカードをユーザーに仮想的に所持させる機能と、レンタル期限（有効期間）が満了している場合にそのカードの返却処理を行う機能とを備える。【選択図】図５
2014117354.tif 000002
【特許請求の範囲】
【請求項１】
複数の仮想的なカードを用いたゲームを、少なくとも１人のユーザーに対して、通信ネットワークを介して提供するオンラインゲームサーバーであって、
前記カードのうち少なくとも１つは、所持期間限定カードであり、
前記オンラインゲームサーバーは、
前記ユーザーからの第１の指示に応じて、所持期間限定カードのいずれかを当該ユーザーに仮想的に所持させる機能と、
いずれかのユーザーが仮想的に所持するいずれかの所持期間限定カードに関連付けられた有効期間が満了している場合、当該ユーザーが当該所持期間限定カードを仮想的に所持しないものとする機能と
を備える、オンラインゲームサーバー。
【請求項２】
前記第１の指示は、所持期間限定カードのいずれか１つを特定する情報を含む、請求項１に記載のオンラインゲームサーバー。
【請求項３】
前記オンラインゲームサーバーは、さらに、
前記第１の指示に関連して、前記ユーザーに対する所定の決済を実行する機能と、
前記所定の決済が正常に完了した場合に、当該第１の指示を実行する機能と
を備える、請求項１または２に記載のオンラインゲームサーバー。
【請求項４】
前記ユーザーからの第２の指示に応じて、ランダムに選択されたカードを当該ユーザーに仮想的に所持させる機能をさらに備える、請求項１〜３のいずれか一項に記載のオンラインゲームサーバー。
【請求項５】
前記ユーザーにいかなる決済も要求せず前記第２の指示を実行する機能を備える、請求項４に記載のオンラインゲームサーバー。
【請求項６】
前記ゲームサーバーは、さらに、
各前記カードを識別するカードＩＤを記憶する機能と、
各前記ユーザーに対して、各ユーザーが仮想的に所持するカードに係るカードＩＤを関連付けて記憶する機能と、
各ユーザーが仮想的に所持する各所持期間限定カードに対して、前記有効期間を関連付けて記憶する機能と、
通信ネットワークを介して、前記ユーザーから前記第１の指示を受信する機能と、
通信ネットワークを介して、前記ユーザーに前記所持期間限定カードを表す情報を送信する機能と、
前記所持期間限定カードを当該ユーザーに仮想的に所持させる場合に、当該所持期間限定カードに有効期間を設定する機能と、
いずれかのユーザーが仮想的に所持するいずれかの所持期間限定カードに関連付けられた有効期間が満了している場合、当該ユーザーと当該所持期間限定カードに係るカードＩＤとの関連付けを解消する機能と
を備える、請求項１〜５のいずれか一項に記載のオンラインゲームサーバー。
【請求項７】
コンピュータを、請求項１〜６のいずれか一項に記載のオンラインゲームサーバーとして機能させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、オンラインゲームサーバーに関し、とくに仮想的なカードを用いるものに関する。
【背景技術】
【０００２】
通信ネットワークを介し、クライアントコンピュータに対してオンラインゲームを提供するオンラインゲームサーバーが知られている。オンラインゲームの中には、コンピュータ上で表現される仮想のカードを各ユーザーが所持し、各ユーザーがカードを操作することによりゲームを進行するものがある。特許文献１や非特許文献１にはこのようなオンラインゲームの例が記載されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１２−２１０３９８号公報
【非特許文献】
【０００４】
【非特許文献１】株式会社マーベラスＡＱＬ、「はじめに｜ブラウザ三国志とは？｜ブラウザ三国志」、［平成２４年１１月９日検索］、インターネット＜URL:http://www.3gokushi.jp/about/＞
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、従来のシステムでは、ユーザーが入手するカードについて、ユーザーの希望を反映させる方法が限られるという問題があった。
たとえば、多数のカードの中からランダムに選択して配布する方式（いわゆる「ガチャ」）では、ユーザーの希望が実現されるかどうかが不明であり、予測可能性が低く戦略立案が困難になる場合がある。一方、ユーザーの希望通りのカードを無条件に与える方式では、ゲームとしての興趣が低下する場合がある。
【０００６】
この発明は、このような問題点を解決するためになされたものであり、ユーザーが入手するカードについて、ユーザーの希望を反映させる新たな方法を実現させるオンラインゲームサーバーを提供することを目的とする。
【課題を解決するための手段】
【０００７】
上述の問題点を解決するため、この発明に係るオンラインゲームサーバーは、複数の仮想的なカードを用いたゲームを、少なくとも１人のユーザーに対して、通信ネットワークを介して提供するオンラインゲームサーバーであって、前記カードのうち少なくとも１つは、所持期間限定カードであり、前記オンラインゲームサーバーは、前記ユーザーからの第１の指示に応じて、所持期間限定カードのいずれかを当該ユーザーに仮想的に所持させる機能と、いずれかのユーザーが仮想的に所持するいずれかの所持期間限定カードに関連付けられた有効期間が満了している場合、当該ユーザーが当該所持期間限定カードを仮想的に所持しないものとする機能とを備える。
【０００８】
前記第１の指示は、所持期間限定カードのいずれか１つを特定する情報を含んでもよい。
前記オンラインゲームサーバーは、さらに、前記第１の指示に関連して、前記ユーザーに対する所定の決済を実行する機能と、前記所定の決済が正常に完了した場合に、当該第１の指示を実行する機能とを備えてもよい。
前記ユーザーからの第２の指示に応じて、ランダムに選択されたカードを当該ユーザーに仮想的に所持させる機能をさらに備えてもよい。
前記ユーザーにいかなる決済も要求せず前記第２の指示を実行する機能を備えてもよい。
前記ゲームサーバーは、さらに、各前記カードを識別するカードＩＤを記憶する機能と、各前記ユーザーに対して、各ユーザーが仮想的に所持するカードに係るカードＩＤを関連付けて記憶する機能と、各ユーザーが仮想的に所持する各所持期間限定カードに対して、前記有効期間を関連付けて記憶する機能と、通信ネットワークを介して、前記ユーザーから前記第１の指示を受信する機能と、通信ネットワークを介して、前記ユーザーに前記所持期間限定カードを表す情報を送信する機能と、前記所持期間限定カードを当該ユーザーに仮想的に所持させる場合に、当該所持期間限定カードに有効期間を設定する機能と、いずれかのユーザーが仮想的に所持するいずれかの所持期間限定カードに関連付けられた有効期間が満了している場合、当該ユーザーと当該所持期間限定カードに係るカードＩＤとの関連付けを解消する機能とを備えてもよい。
【０００９】
また、この発明に係るプログラムは、コンピュータを上述のオンラインゲームサーバーとして機能させる。
【発明の効果】
【００１０】
この発明に係るオンラインゲームサーバーによれば、ユーザーは、ランダムに配布されるカードだけでなく、所持期間は限定されるがある程度任意に指定可能なカードも用いることができるので、よりユーザーの希望を反映したカードを使用させることができる。
【図面の簡単な説明】
【００１１】
【図１】本発明の実施の形態１に係るサーバーおよび関連する構成を示す図である。
【図２】図１のカードＤＢの構成の例を示す図である。
【図３】図１のユーザーＤＢの構成の例を示す図である。
【図４】図１のサーバーの処理の流れを表すフローチャートである。
【図５】カードの所持状況をユーザーの視点で説明する図である。
【発明を実施するための形態】
【００１２】
以下、この発明の実施の形態を添付図面に基づいて説明する。
実施の形態１．
図１に、本発明の実施の形態１に係るサーバー１０およびこれに関連する構成を示す。サーバー１０は、オンラインゲームサーバーとして、複数の仮想的なカードを用いたゲームを、少なくとも１人のユーザーに対して、通信ネットワークを介して提供する。
【００１３】
サーバー１０は公知のコンピュータとしての構成を有し、演算を行う演算手段１１と、情報を格納する記憶手段１２とを備える。演算手段１１はＣＰＵ（中央処理装置）を含み、記憶手段１２は半導体メモリおよびＨＤＤ（ハードディスクドライブ）等の記憶媒体を含む。また、図示しないが、サーバー１０は、入力手段（キーボードおよびマウス等）および出力手段（ディスプレイおよびプリンタ等）を備えてもよい。
【００１４】
サーバー１０は、図示しないネットワークカード等の通信手段を備え、このネットワークカードを介して通信ネットワーク２０に対して情報の入出力を行う機能を有する。通信ネットワーク２０はたとえばインターネットであるが、ＬＡＮ等であってもよく、複数種類の通信ネットワークを組み合わせて用いてもよい。
【００１５】
また、図示しないが、サーバー１０は公知の構成によって決済処理を実行する機能を有する。決済処理は、必ずしもサーバー１０の権限内で完結する処理に限らず、他のコンピュータ等に決済を依頼する処理を含んでもよい。たとえば、決済機関のコンピュータとの通信に基づく通貨の引き落とし依頼等を含む処理であってもよい。ここで、「通貨」とは必ずしも現金や汎用性のある電子マネーに限らず、現金や電子マネーの支払いに基づいて得られる仮想通貨であってもよい。仮想通貨は、たとえば特定のオンラインゲーム内でのみ有効なポイントとして表現されてもよい。
【００１６】
通信ネットワーク２０には１台または複数のクライアント３０が接続されている。クライアント３０は、オンラインゲームにプレイヤーとして参加するユーザーが操作するコンピュータであり、公知のＰＣや携帯端末によって構成される。クライアント３０から通信ネットワーク２０を介してサーバー１０に送信される情報のうち一部は、ユーザーがクライアント３０に入力する指示に対応する。
【００１７】
サーバー１０およびクライアント３０は、所定の通信プロトコル、たとえばＨＴＴＰプロトコルを介して互いに通信可能である。たとえばサーバー１０は公知のＷｅｂサーバーとして機能し、クライアント３０は公知のＷｅｂブラウザとして機能する。
【００１８】
サーバー１０の記憶手段１２は、カードＤＢおよびユーザーＤＢを格納する。カードＤＢは、ゲーム内で使用される仮想的なカードに関する情報を含む。ユーザーＤＢは、ゲームに参加するユーザーに関する情報を含む。また、サーバー１０の記憶手段１２は、図示しないオンラインゲームプログラムを記憶し、演算手段１１がこのオンラインゲームプログラムを実行することにより、サーバー１０は本明細書に記載される機能を実現する。
【００１９】
図２にカードＤＢの構成の例を示す。カードＤＢは、ゲームにおいて用いられる複数のカードをそれぞれ互いに識別する情報としてのカードＩＤを含む。また、カードＤＢは、カードＩＤのそれぞれについて、そのカードに関する情報を関連付ける。カードに関連する情報は、ランダム配布フラグ、レンタル可否フラグ、およびステータス情報を含む。
【００２０】
本実施形態に係るゲームでは、ユーザーがカードを仮想的に所持してゲームを進行するが、この所持に２種類の形態がある。一方はランダム配布（いわゆる「ガチャ」）による所持であり、サーバー１０が乱数に基づいて選択したカードをユーザーに配布することにより実現される。したがって、ランダム配布ではユーザーは望むカードを入手できるとは限らない。他方はレンタル（貸与）であり、サーバー１０がユーザーから任意の指定を受け付け、指定されたカードを所定期間だけレンタルすることにより実現される。
【００２１】
カードＤＢのランダム配布フラグは、そのカードがランダム配布の対象となるか否かを表す。すなわち、サーバー１０がランダム配布を実行する際には、ランダム配布フラグが「有」となっているカードすべての中から、乱数に基づいて１枚のカードを選択し、選択されたカードをユーザーに配布する。
また、レンタル可否フラグは、そのカードがレンタルの対象となるか否かを表す。なお、すべてのカードのうち、少なくとも１枚のカードがレンタルの対象となるよう設定されるものとする。
【００２２】
ステータス情報は、カードに関するその他の情報を含む。ステータス情報は、公知のオンラインカードゲームにおいて用いられるカード固有の情報であればいかなるものを含んでもよい。たとえば、カード名（またはカードに関連付けられているキャラクターの名称等）、画像、レア度（ランダム配布における確率分布を表す情報）、レベル、ＨＰ（ヒットポイントまたは体力）、攻撃力、防御力、特殊スキル（ゲームの進行に影響を及ぼすカード固有の機能）、等を含んでもよい。
【００２３】
レンタルの対象となるカードは、比較的強力なカードとしてデザインされてもよい。すなわち、１つ以上のパラメータが比較的高い（たとえばランダム配布されるカードの期待値より高い）、ランダム配布されるカードのいずれにも与えられていない特殊スキルを持っている、等のようにデザインされてもよい。
【００２４】
図３にユーザーＤＢの構成の例を示す。ユーザーＤＢは、ゲームに参加する１人または複数のプレイヤーをそれぞれ互いに識別する情報としてのユーザーＩＤを含む。また、ユーザーＤＢは、ユーザーＩＤのそれぞれについて、そのユーザーが仮想的に所持するカードに関する情報を関連付ける。ここで、ユーザーが仮想的に所持するカードとは、ランダム配布によるものと、レンタルによるものとの双方を含む。
【００２５】
ユーザーが仮想的に所持するカードに関する情報は、所持カード番号、カードＩＤ、レンタル期限およびステータス情報を含む。
所持カード番号は、そのユーザーが所持するカードをそれぞれ互いに識別する情報である。あるユーザーが、同一のカードＩＤを持つカードを複数枚所持している場合でも、所持カード番号に基づいて各カードを区別することができる。カードＩＤはカードＤＢに記憶されるものと対応する。
【００２６】
レンタル期限は、レンタルによってユーザーに貸与されているカードに対して関連付けられる情報であり、そのカードのレンタルの有効期間を表す。すなわち、レンタル期限が経過する前であれば、ユーザーはそのカードを所持しているが、レンタル期限が経過した後では、そのユーザーはそのカードをもはや所持していない。このように、レンタルの対象となるカードは、所持期間限定カードであるということができる。なお図３ではレンタル期限は日付のみで表されているが、時刻まで含めてもよい。
【００２７】
ステータス情報は、カードＤＢのステータス情報と同じ情報を含む。また、ユーザーが所持する各カードのステータス情報は、ゲームの進行に応じて変化してもよい。たとえばカードの使用状況に応じてレベルや他のパラメータが変動してもよい。
【００２８】
なお、とくに図示しないが、ユーザーＤＢは、ユーザーのゲーム進行状況（所有している資源の量、領土の座標、等）を表す情報を含んでもよい。また、ユーザーＤＢは、ユーザーに関するその他の情報（ユーザー名、認証に用いるパスワード、決済に用いるアカウント情報、等）を含んでもよい。
【００２９】
以上のように構成されるサーバー１０の処理の流れを以下に説明する。
図４は、本実施形態に係るサーバー１０の処理の流れを表すフローチャートである。このフローチャートは、とくにユーザーからの指示に応じて実行される処理の一部を説明するものである。また、図５は、サーバー１０の処理の進行に応じて変動するカードの所持状況を、ユーザーの視点で説明する図である。
【００３０】
まず、サーバー１０の演算手段１１は、ゲームへのアクセス要求をユーザーから受信する（ステップＳ１）。このアクセス要求は、たとえばユーザーの操作によりクライアント３０から送信される。なお、以下同様に、ユーザーとの間の通信はクライアント３０を介して行われるものとする。
【００３１】
演算手段１１は、当該ユーザーに対して認証処理を行う（ステップＳ２）。たとえばユーザーＩＤおよびパスワードの入力を求め、ユーザーＤＢまたは他の場所に記憶されている情報と一致するか否かを判定する。認証に失敗した場合にはサーバー１０は処理を終了してもよい。
【００３２】
ここで、例として、ステップＳ２においてユーザーＩＤ「Ｕ０３」を持つユーザーが認証されたとする。図３に示すように、このユーザーはカードＩＤ「Ｃ０４」および「Ｃ０５」に対応する２枚のカードを所持している。このような状態は、たとえば図５（ａ）の所持カードリスト５１のような形式でユーザーに提示される。なお、これら２枚のカードにはレンタル期限が設定されていない。
【００３３】
ステップＳ２において認証に成功すると、演算手段１１は、ゲームの進行に関するユーザーの指示を受け付けるまで待機し（ステップＳ３）、指示に応じて異なる処理を実行する。ステップＳ３で受け付ける指示は、新たなカードの所持に関する指示と、その他の指示とを含む。この「その他」の指示は、公知のオンラインカードゲームにおける様々な指示を含み、たとえばカードの機能を発揮させることによりゲームを進行する指示や、カードに無関係な指示が該当するが、この詳細については当業者が適宜設計し得るので説明を省略する。たとえば非特許文献１に記載される指示を含んでもよい。このような指示の実行が終了すると、処理はステップＳ３に戻る。
【００３４】
ステップＳ３において、新たなカードの所持に関する処理は２種類の指示を含み、これらの一方は第１の指示であり、他方は第２の指示である。以下、本実施形態では、第１の指示を「レンタル指示」と呼び、第２の指示を「ランダム配布指示」と呼ぶ。
【００３５】
レンタル指示は、レンタルに関する処理を開始するようサーバー１０に要求する指示を含む。ユーザーがレンタル指示を送信すると、演算手段１１は通信ネットワーク２０を介してこの指示を受信し、これに応じてレンタルカードの一覧を送信する（ステップＳ４）。一覧の送信は、たとえば、レンタルの対象となるカード（すなわちレンタル可否フラグが「可能」に設定されているカード）を表す情報をクライアント３０に送信することによって実現される。レンタルの対象となるカードを表す情報は、図２に示すカードＩＤであってもよく、またカードＩＤに関連付けられたカード名やその他の情報であってもよく、画像であってもよい。また、カードを表す情報に加えて、各カードのレンタルに必要なコスト（金額、ポイント、等）を表示してもよい。
【００３６】
ここで、例として、図２に示すように、カードＩＤ「Ｒ０１」および「Ｒ０２」に対応する２枚のカードがレンタルの対象となっているものとする。このような状態は、たとえば図５（ａ）のショーウィンドウ５２のような形式でユーザーに提示される。
【００３７】
ステップＳ４の後、演算手段１１は、ユーザーがレンタルを希望するカードを特定する（ステップＳ５）。この特定処理は、たとえば、レンタルの対象となるカードのうちいずれか１つを特定する情報を、レンタル指示の一部としてユーザーから受信することにより実行される。ユーザーは、たとえばレンタルの対象となるカードの一覧がクライアント３０の画面に表示された状態で、希望するカードの画像をクリックすることにより、カードを特定することができる。
【００３８】
次に、演算手段１１は、レンタル指示に関連して、そのユーザーに対する決済処理を実行する（ステップＳ６）。決済処理の具体的な構成は、当業者であれば公知技術に基づいて適宜設計可能である。たとえば、決済機関のコンピュータとの通信に基づく通貨の引き落とし処理であってもよい。または、事前の決済に基づいて取得された当該オンラインゲーム内でのみ有効な仮想通貨（ポイント）を消費する処理であってもよい。
【００３９】
ステップＳ６の決済処理が正常に実行され完了した場合（たとえば引き落とし処理が正常に完了した場合）、サーバー１０はレンタル指示を実行する（ステップＳ７）。すなわち、レンタル指示に応じて、レンタルの対象となるカードのうちユーザーが希望したものを、そのユーザーに仮想的に所持させるとともに、そのカードにレンタル期限を設定する。具体的な動作としては、たとえば、ユーザーＤＢにおいて、そのユーザーのユーザーＩＤに新たな所持カード番号を関連付けるとともに、その所持カード番号に、希望されたカードのカードＩＤおよびレンタル期限を関連付ける。ここで設定されるレンタル期限は、カードＤＢに予め指定されている値を用いてもよく、他のなんらかの処理によって算出または決定されてもよい。
このような処理により、ユーザーに対してカードが有効化される。
【００４０】
この時点のカード所持状況は、たとえば図５（ｂ）のようになる。この例は、カードＩＤ「Ｒ０２」のカードに対するレンタル指示が実行された時点のものである。この時点でユーザーはこのカードをレンタル中カードとして所持しており、このカードの機能を発揮させてゲームを進行に影響を及ぼすことができる。たとえば、このカードの特殊スキルを使用し、戦闘において特殊な効果を発動させることができる。
ステップＳ７の後、処理はステップＳ３に戻り、演算手段１１はユーザーからの指示を待ち受ける。
【００４１】
なお、図４のフローチャートには示さないが、レンタル期限が満了したカードについては返却処理が行われる。たとえば、演算手段１１は適切なタイミングでユーザーＤＢのレンタル期限を監視し、いずれかのユーザーが所持するいずれかのレンタル中カードに関連付けられたレンタル期限が満了している場合、当該ユーザーが当該レンタル中カードを所持しないものとする。「所持しないものとする」という処理は、たとえばユーザーＤＢにおいてそのユーザーとそのカードに係るカードＩＤとの関連付けを解消することにより実行される。
【００４２】
返却処理が行われた時点のカード所持状況は、たとえば図５（ｃ）のようになる。カードＩＤ「Ｒ０２」のカードが返却され、ユーザーはもはやこのカードを所持していない。
【００４３】
ステップＳ６の決済処理が実行されていない場合（または正常に完了しなかった場合。たとえば残高不足等の原因により引き落とし処理が失敗した場合）、サーバー１０はレンタル指示の実行を拒否する（ステップＳ８）。すなわち、ステップＳ７の処理は実行されない。この場合、レンタル指示が実行されないという通知や、その理由（ポイント残高不足のため決済処理が実行できなかった等）を、ユーザーに提示してもよい。
ステップＳ８の後、処理はステップＳ３に戻り、演算手段１１はユーザーからの指示を待ち受ける。
以上は、ユーザーがレンタル指示を送信した場合の動作である。
【００４４】
ユーザーがランダム配布指示を送信すると、ステップＳ３において演算手段１１は通信ネットワーク２０を介してこの指示を受信し、これに応じてランダムにカードを配布する（ステップＳ９）。すなわち、カードＤＢにおいてランダム配布フラグが「有」に設定されているカードのうちからランダムに選択されたカードを、当該ユーザーに所持させる。
【００４５】
なお、ここで「ランダム」とは、必ずしもすべてのカードが等確率で選択されることを意味しない。また、複数のランダム配布指示が任意に可能であってもよい。たとえば、ある出現確率分布に従うランダム配布を行う指示と、これとは異なる出現確率分布に従うランダム配布を行う指示とが選択可能であってもよい。また、それぞれのランダム配布を実行するために、ユーザーに対して異なる条件が課せられてもよい。
【００４６】
ユーザーにカードを所持させる際の具体的な動作としては、たとえば、ユーザーＤＢにおいて、そのユーザーのユーザーＩＤに新たな所持カード番号を関連付けるとともに、その所持カード番号に、選択されたカードのカードＩＤを関連付ける。ここで、ステップＳ７とはことなり、レンタル期限は設定されない。したがって、そのカードについては、レンタルに対する返却処理が実行されることがない。
【００４７】
以上から明らかなように、ランダム配布指示は、ユーザーにいかなる決済も要求せずに実行される。ただし、決済以外の制限（ゲームの進行状況に関する条件等）は課されてもよく、その制限に抵触する場合にはランダム配布指示の実行を拒否してもよい。また、ステップＳ９のようにいかなる決済も要求せずランダム配布を実行するという第１のランダム配布処理が選択可能であれば、これに加えて、なんらかの決済を要求したうえでランダム配布を実行するという第２のランダム配布処理が選択可能であってもよい。
ステップＳ９の後、処理はステップＳ３に戻り、演算手段１１はユーザーからの指示を待ち受ける。
【００４８】
以上説明するように、本実施形態に係るサーバー１０によれば、ユーザーは、従来のランダム配布方式に加え、新たにレンタル方式によりカードを入手することができるので、ユーザーの希望を反映させる新たな方法を実現することができる。
【００４９】
また、レンタル指示は希望のカードを指定して実行することができるので、ユーザー側で予測可能性が高まり、高度な戦略立案が可能になる。
ただし、レンタルに課金することにより、希望のカードを無制限に使用するという行動が困難になるので、ゲームバランスが維持される。また、レンタルに期限を設けたことにより、希望のカードを無制限に使用するという行動が困難になり、ゲームバランスが維持される。
また、ランダム配布を無課金とし、レンタルを課金制とすることにより、投資に応じて希望のカードを入手する機会が増え、ゲームとしての興趣が高まる。
【００５０】
実施の形態１において、次のような変形を施すことができる。
実施の形態１では、図２に示すようにランダム配布の対象となるカードとレンタルの対象となるカードは互いに排反であるが、これらは重複してもよい。すなわち、ランダム配布の対象となり、かつレンタルの対象としても指定可能なカードが存在してもよい。
【００５１】
各ステップが実行される順序は、図４に示すものに限られない。たとえばステップＳ４をステップＳ３より前に実行してもよい。この場合、ユーザーはレンタルカードの一覧を確認した後にレンタル指示を送信することができる。
【００５２】
ランダム配布やレンタルの対象は、仮想的に「カード」という用語で表されるものに限らず、カード以外の表現によってキャラクターを表したものであってもよく、カード以外のなんらかのオブジェクトであってもよい。
【符号の説明】
【００５３】
１０  サーバー（オンラインゲームサーバー）、２０  通信ネットワーク、３０  クライアント（ユーザー）、５１  所持カードリスト、５２  ショーウィンドウ。
【図１】
2014117354.tif 000003
【図２】
2014117354.tif 000004
【図３】
2014117354.tif 000005
【図４】
2014117354.tif 000006
【図５】
2014117354.tif 000007