JP5802633B2 - ゲーム制御装置、プログラム、ゲームシステム - Google Patents

Description

本発明は、複数のユーザの各々の操作に応じて、各ユーザによるゲームの進行を制御する技術に関する。

近年、特定のサービス提供者によるソーシャルネットワーキングサービス（ＳＮＳ）においてウェブブラウザ上で動作するＡＰＩ(Application Programming Interface)などの動作環境を基に作成されるゲーム用アプリケーションによって実行される、いわゆるソーシャルゲーム（Social Game）が普及している。ソーシャルゲームは、不特定多数のユーザ間でコミュニケーションをとりながらプレイするオンラインゲームの一種であると言える。ユーザは、インターネットに接続可能であって、かつウェブブラウザが搭載された通信端末を備えていれば、時間と場所を問わずソーシャルゲームを楽しむことができる。

上述したソーシャルゲームでは、従来のオンラインゲームよりも、ユーザ間の交流を図るためのコミュニケーション機能が充実している点が特徴の１つとなっている。ソーシャルゲームでは、例えば、関係付けられたユーザ（仲間）間で協力したゲームの実行のほか、仲間との挨拶や連絡など仲間とコミュニケーションを取ることによる情報交換、仲間との間のゲーム上のアイテムのプレゼントあるいはアイテムの交換が行なわれている。このようなソーシャルゲームの一例として、下記の非特許文献１に記載されたデジタルカードゲーム（ドラゴンコレクション（登録商標））が知られている。

アプリＳＴＹＬＥ Vol.5（株式会社イースト・プレス、平成23年11月15日発行）、7-8頁

従来のソーシャルゲームでは、例えば、ユーザが保持することによって所定のゲーム上の効果（例えば、ゲームの進行度合いを高められる等の効果）を生じさせるアイテムを用意し、このアイテムを関係付けられたユーザ（仲間）間で順次移転する（リレーする）ことを可能とする仕組みが設けられていたものがあった。また、アイテムの移転回数に応じてリレーに関与したユーザに対してインセンティブを付与することも行われてきた。これらの仕組みは、共通のアイテムを介して複数のユーザを互いに関連付け、協力ゲームを実行している感覚を醸成させる点で好ましいが、例えばアイテムを移転されたユーザが長時間ゲームにアクセスしない場合や、アイテムが移転されてきたことに気付かない場合には、そのユーザにおいてアイテムが滞留してしまい、アイテムの移転が滞ってしまうという状況が生じていた。このような状況は、協力ゲームにおいてユーザ間の円滑なコミュニケーションを阻害する要因にもなりうる。

本発明は上述した観点に鑑みてなされたもので、ユーザ間でアイテム情報を移転する場合に、アイテム情報の移転が滞ってしまう状況を防止することができるゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステムを提供することを目的とする。

本発明の第１の観点は、ゲーム制御装置であって、
所定のアイテム情報をユーザに対応付ける対応付け手段（５３）と、
ユーザの入力情報に基づいて、当該ユーザに対する前記アイテム情報の対応付けを解除し、かつ前記アイテム情報を当該ユーザとは異なるユーザへ対応付けることで、ユーザ間で前記アイテム情報を移転する第１移転手段（５５）と、
前記第１移転手段（５５）によるアイテム情報の移転から所定の第１期間の間、移転先のユーザがゲームにアクセスしない場合、又はアイテム情報に関するゲームを実行しない場合、移転先のユーザ以外のユーザの入力情報に基づいて、当該ユーザにアイテム情報を移転する第２移転手段（５７）と、
を備える。

このゲーム制御装置において「アイテム情報」は、ゲームにおいてユーザと対応付けることが可能な情報であれば如何なる情報であってもよい。アイテム情報は、例えば、ゲーム上のオブジェクトや、ゲーム上の道具や効果を示す情報であってもよく、その情報の形式は、画像情報、音声情報、あるいはテキスト情報であってもよい。
このゲーム制御装置において「ユーザの入力」は、ユーザの通信端末に対する所定の操作釦の押下操作の入力や、タッチパネル機能を備えた通信端末に対する表示画面上のタッチ操作の入力のほか、音声入力、加速度センサを備えた通信端末を振ることによる操作入力、あるいはジェスチャによる操作入力（ジェスチャ入力）であってもよい。ジェスチャ入力では、撮像機能を備えた通信端末に対する所定のジェスチャを行うことで通信端末がそのジェスチャを画像認識し、予めジェスチャに対応付けられた操作入力を認識する。

このゲーム制御装置では、第１移転手段（５５）によって、１番目のユーザに対応付けられたアイテム情報が、１番目のユーザから２番目のユーザへ、２番目のユーザから３番目のユーザへ、といった具合に順次移転される。このとき、アイテム情報の移転から所定の第１期間の間、移転先のユーザがゲームにアクセスしない場合、又はアイテム情報に関するゲームを実行しない場合など、移転先のユーザが、アイテム情報が移転されてきたことを知らずに放置したままとなっていると考えられる場合には、第２移転手段（５７）によって、移転先のユーザ以外の他のユーザの入力情報に基づいて、当該ユーザにアイテム情報が移転される。すなわち、当該ユーザは放置されていたアイテム情報を自分のものとすることができる。他のユーザが複数いる場合には、早い者勝ちとすることができ、この場合、放置したままになっているアイテム情報があれば、複数のユーザが互いに競争してそれを入手しようとすることになる。そのため、アイテム情報の移転が滞ってしまう状況が防止される。
また、上述したように、このゲーム制御装置では、移転先のユーザがゲームにアクセスしない場合、又はアイテム情報に関するゲームを実行しない場合にアイテム情報が他のユーザにさらに移転される。つまり、自身にアイテム情報が移転されてきたことを移転先のユーザが知らないうちにそのアイテム情報がさらに他のユーザに移転されることになるため、アイテム情報が言わば奪われたことになる移転先のユーザは、アイテム情報が得られなかったことを残念に感じたり、アイテム情報を奪ったユーザに対して快くない感情を抱くこともない。
なお、移転先のユーザがゲームにアクセスして、移転されたアイテム情報の存在も認識していたが、後で実行しようと考えていたり、何らかの用事により直ちに実行できなかった場合、その未実行の間に、他のユーザにアイテム情報が奪われてしまうと、そのユーザには不快感が残ってしまう。そこで、移転先のユーザによってアイテム情報の存在が認識された場合には（例えばアイテム情報に関連する画面にアクセスした履歴がある場合等）、他のユーザによるアイテム情報の移転（奪取）を禁止するようにしてもよい。

上記ゲーム制御装置において、前記第１移転手段（５５）は、前記アイテム情報が最初にユーザに対応付けられた後の所定の第２期間を経過した後の、又は前記アイテム情報の移転回数が所定回数に達した後の前記アイテム情報のユーザ間の移転を禁止してもよい。
上記のように、例えばアイテム情報のユーザ間の移転が行われる期間が制限されている場合、アイテム情報が滞留すればするほど、アイテム情報の移転可能時間が低減することになるので、折角、アイテム情報を入手する機会がありながら、迅速に行動しないでいると、その機会を失ってしまうことになる。従って、ユーザはアイテム情報が滞留している事実を知れば、迅速にそれを入手しようと行動することになる。また、アイテム情報の移転回数について制限がされている場合、例えば移転回数が制限回数に近づく程、そのアイテム情報を入手する機会が少なくなり、特に制限回数の上限になれば、それがそのアイテム情報入手の最後の機会になるので、各ユーザは、より迅速に行動してそれを入手しようとすることになる。このように、上記ゲーム制御装置によれば、アイテム情報の移転が滞ってしまう状況を防止することができる。そのため、このゲーム制御装置は、上記制限がなされているゲームに適用される場合に特に好ましいものとなる。

上記ゲーム制御装置において、ユーザ間を関係付ける関係付け手段（５１）、を備え、前記第１移転手段（５５）及び前記第２移転手段（５７）は、前記関係付け手段（５１）によって関係付けられたユーザ間で前記アイテム情報を移転してもよい。
アイテム情報の移転の対象となるユーザを、関係付けられたユーザ、言わば仲間同士とすることで、仲間と協力してゲームを進行させている実感を得ることができる。また、例えば仲間同士のコミュニケーションの活性化が図れ、ソーシャル性を高めることができる。

上記ゲーム制御装置において、前記第１移転手段（５５）によって前記アイテム情報がユーザに移転されてから前記第１期間が経過した後、当該ユーザと関係付けられたユーザに対して、前記アイテム情報が移転可能であることを通知する通知手段（５６）、を備えてもよい。
この構成では、アイテム情報が移転されたユーザの下でアイテム情報が滞留していることが他のユーザに通知されるため、通知されたユーザによる入力によって、その通知されたユーザにアイテム情報が移転される可能性を高くすることができる。そのため、アイテム情報の移転が滞ってしまう状況がより効果的に防止される。また、通知されたユーザは、同じ通知が行われている仲間内のなかでも、アイテム情報を得ようと我先に入力を行うようになるため、アイテム情報をユーザ間で移転するときに早い者勝ちの要素が加わることになり、ゲームの興趣性を高めることができる。

上記ゲーム制御装置において、ユーザ間の関係の程度に応じた親密度を、前記関係付け手段（５１）によって関係付けられたユーザ間に設定する親密度設定手段（５８）、を備え、前記第２移転手段（５７）は、アイテム情報の移転元のユーザと移転先のユーザの親密度が高いほど、前記第１期間を長くしてもよい。
この構成において「親密度」とは、関係付けられた仲間のユーザ間の関係性の高さを一定の基準で数値化したものである。例えば、ユーザ間のメッセージの送信あるいは受信の頻度や、ゲーム上で使用可能なアイテムなどのプレゼントを仲間に送信、あるいは仲間から受信した回数が大きいほど、親密度が高く設定されるようにしてもよい。
この構成では、移転元のユーザと移転先のユーザの親密度が高い場合には、移転先のユーザの下でアイテム情報を滞留させた場合でも、知らない内にアイテム情報が他のユーザに移転される（つまり、アイテム情報を奪われる）ことが可能となるタイミングをより長く先延ばしさせることができる。つまり、ユーザ間の親密度が高いほどアイテム情報を奪われ難くすることができるため、ユーザは仲間との関係を強化するように動機付けられる。

前記親密度設定手段（５８）を備えた場合には、前記通知手段（５６）は、前記第１移転手段（５５）によって前記アイテム情報がユーザに移転されてから前記第１期間が経過した後、当該ユーザとの親密度が所定値よりも高いユーザに対して、前記アイテム情報が移転可能であることを通知してもよい。
この構成では、アイテム情報が移転可能であることの通知は、アイテム情報を滞留させているユーザとの間で親密度が高い仲間に対して行われる。つまり、多くの仲間との間で親密度が高いユーザは、アイテム情報が移転可能であることの通知をより多く受け取ることができ、適時の入力によるアイテム情報の移転によってアイテム情報を得る機会が高くなる。そのため、この構成では、ユーザは仲間との関係を強化するように動機付けられる。

上記ゲーム制御装置において、前記アイテム情報は、所定数の選択肢を含み、
前記アイテム情報が対応付けられているユーザの入力情報に基づいて、前記アイテム情報に含まれる選択肢の中からいずれかの選択肢を選択する選択手段（５４）、を備え、
前記第１移転手段（５５）は、前記選択手段（５４）により選択肢が選択された場合、当該選択肢を前記アイテム情報から除いた状態で前記アイテム情報を移転してもよい。
この構成において「選択肢」は、ゲーム上で設定可能な選択肢であれば任意に設定することができ、例えば、ゲーム上のカード等のオブジェクトや、ゲーム上のポイントを付与することや、ゲームの進捗を高めるためのパラメータの変更等、ゲーム上の有利な効果をユーザに付与することであってもよい。選択肢は、例えば「ハズレ」等、実質的にユーザに何ら付与されない内容であってもよい。
この構成では、アイテム情報が所定数の選択肢を含んでおり、アイテム情報が移転される度にユーザの入力によって選択肢が選択されて除かれていく。そのため、ユーザは、アイテム情報に含まれるすべての選択肢が除かれる前にアイテム情報を得て、自ら選択肢を選択することが動機付けられる。このアイテム情報がユーザの下で滞留しているときには、他のユーザが選択肢を得ようと我先にアイテム情報の移転のための入力を行うようになり、アイテム情報の移転が滞ってしまう状況がさらに効果的に防止される。

上記ゲーム制御装置において、前記第１移転手段（５５）は、前記選択手段（５４）により選択された選択肢が所定の条件を満たす場合、それ以降の前記アイテム情報のユーザ間の移転を禁止してもよい。
この構成において選択肢についての「所定の条件」は、選択肢に設定可能な条件であれば如何なる条件でもよいが、アイテム情報に含まれる所定数の選択肢のうち「アタリ」に相当する条件であることが好ましい。例えば、アイテム情報に、カードやアイテムをユーザに付与する選択肢が複数含まれている場合、パラメータの値が所定値より大きいカードやアイテム、あるいは最もレア度（希少価値）が所定レベルより高いカードやアイテムを付与する選択肢である場合に、その選択肢が所定の条件を満たすとしてもよい。
この構成では、アイテム情報が順次ユーザ間を移転されている間に、「アタリ」の選択肢等、所定の条件を満たす選択肢が選択された場合には、それ以降のアイテム情報の移転ができなくなる。そのため、ユーザは早くアイテム情報を得て「アタリ」の選択肢を選択したいと考えるため、アイテム情報の移転が滞ってしまう状況がさらに効果的に防止される。また、この構成では、アイテム情報が移転される度に「アタリ」の選択肢を選択する確率が高くなり、移転の度にアイテム情報の価値が高くなるため、アイテム情報がユーザの下で滞留しているときには、他のユーザがアイテム情報の移転のための入力を我先に行うようになり、アイテム情報の移転が滞ってしまう状況がさらに効果的に防止される。

本発明の第２の観点は、
所定のアイテム情報をユーザに対応付ける対応付けステップと、
ユーザの入力情報に基づいて、当該ユーザに対する前記アイテム情報の対応付けを解除し、かつ前記アイテム情報を当該ユーザとは異なるユーザへ対応付けることで、ユーザ間で前記アイテム情報を移転する第１移転ステップと、
前記第１移転ステップにおけるアイテム情報の移転から所定の第１期間の間、移転先のユーザがゲームにアクセスしない場合、又はアイテム情報に関するゲームを実行しない場合、移転先のユーザ以外のユーザの入力情報に基づいて、当該ユーザにアイテム情報を移転する第２移転ステップと、
を備えた、ゲーム制御方法である。

本発明の第３の観点は、ゲームの実行を制御するために、コンピュータに、
所定のアイテム情報をユーザに対応付ける対応付け機能、
ユーザの入力情報に基づいて、当該ユーザに対する前記アイテム情報の対応付けを解除し、かつ前記アイテム情報を当該ユーザとは異なるユーザへ対応付けることで、ユーザ間で前記アイテム情報を移転する第１移転機能、及び、
前記第１移転機能によるアイテム情報の移転から所定の第１期間の間、移転先のユーザがゲームにアクセスしない場合、又はアイテム情報に関するゲームを実行しない場合、移転先のユーザ以外のユーザの入力情報に基づいて、当該ユーザにアイテム情報を移転する第２移転機能、
を実現させるためのプログラムである。

コンピュータは、例えばネットワークサーバ、大型計算機等であってよい。また、このプログラムは、ＤＶＤ−ＲＯＭやＣＤ−ＲＯＭ等のコンピュータが読み取り可能な情報記憶媒体に格納されてもよい。

本発明の第４の観点は、通信端末（１０）と、当該通信端末からアクセスされるサーバ（２０）とを含むゲームシステムであって、
通信端末と、当該通信端末からアクセスされるサーバとを含むゲームシステムであって、
所定のアイテム情報をユーザに対応付ける対応付け手段（５３）、
ユーザの入力情報に基づいて、当該ユーザに対する前記アイテム情報の対応付けを解除し、かつ前記アイテム情報を当該ユーザとは異なるユーザへ対応付けることで、ユーザ間で前記アイテム情報を移転する第１移転手段（５５）、及び、
前記第１移転手段（５５）によるアイテム情報の移転から所定の第１期間の間、移転先のユーザがゲームにアクセスしない場合、又はアイテム情報に関するゲームを実行しない場合、移転先のユーザ以外のユーザの入力情報に基づいて、当該ユーザにアイテム情報を移転する第２移転手段（５７）、
を備える。

なお、上記では、本発明の理解を容易にするため、適宜図面に記載された符号を括弧書きで記載しているが、これにより本発明に係るゲーム制御装置等が図示の態様に限定されるものではない。

本発明のゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステムによれば、ユーザ間でアイテム情報を移転する場合に、アイテム情報の移転が滞ってしまう状況を防止することができる。

実施形態のゲームシステムの基本構成を示す図。 実施形態の通信端末の外観の例を示す図。 実施形態の通信端末の構成を示すブロック図。 実施形態のゲームサーバの構成を示すブロック図。 実施形態のデータベースサーバの構成を示すブロック図。 ユーザデータベースの構成例を示す図。 リレー管理データの構成例を示す図。 リレーアイテムデータベースの構成例を示す図。 ユーザの通信端末において表示される一連のウェブページを例示する図。 ユーザの通信端末において表示される一連のウェブページを例示する図。 ユーザの通信端末において表示される一連のウェブページを例示する図。 ユーザの通信端末において表示される一連のウェブページを例示する図。 複数のユーザ間でのリレーアイテムのリレーの一例を説明するための図。 実施形態のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図。 実施形態のゲームサーバの主要な処理を示すフローチャート。 実施形態のゲームサーバの主要な処理を示すフローチャート。 実施形態のゲームサーバの主要な処理を示すフローチャート。 実施形態のゲームサーバの主要な処理を示すフローチャート。 実施形態のゲームサーバの主要な処理を示すフローチャート。 実施形態のゲームサーバの主要な処理を示すフローチャート。 複数のユーザ間でのリレーアイテムのリレーの一例における各種フラグの変化を示すタイミングチャート。 実施形態の変形例のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図。 親密度データの構成例を示す図。 ゲーム制御装置の各機能について、通信端末と、ゲームサーバ及びデータベースサーバとの間の分担例を示す図。

以下、本発明の実施形態について説明する。

（１）ゲームシステムの構成
図１は、実施形態のゲームシステムのシステム構成例を示している。図１に示すように、このゲームシステムは、例えばインターネットなどの通信網ＮＷ（ネットワーク）に接続可能な通信端末１０ａ，１０ｂ，１０ｃ，…と、通信網ＮＷに接続されているゲームサーバ２０と、データベースサーバ３０とによって構成されている。各通信端末１０ａ，１０ｂ，１０ｃ，…はそれぞれ、個々のユーザによって操作される端末であり、例えば、携帯端末、スマートフォン、ＰＤＡ(Personal Digital Assistant)、パーソナルコンピュータ、双方向の通信機能を備えたテレビジョン受像機（いわゆる多機能型のスマートテレビも含む。）などの通信端末である。なお、以下の説明において、各通信端末１０ａ，１０ｂ，１０ｃ，…に共通して言及するときには、通信端末１０と表記する。
このゲームシステムにおいて、ゲームサーバ２０は、クライアントである通信端末１０と通信可能に構成されており、通信端末１０に対してゲーミングサービスを提供する。ゲームサーバ２０には、ゲーム用アプリケーションとしてウェブブラウザ上で動作可能なアプリケーションが実装されている。データベースサーバ３０は、ゲームを実行する上での後述する様々な情報を格納しており、それらの情報の読み書きのためにゲームサーバ２０と例えば有線で接続される。
通信端末１０は、ゲームサーバ２０によって提供されるウェブページを表示可能なウェブブラウザを備えており、ユーザは、通信端末１０でウェブページに対する操作をしてゲームを実行する。

また、図１には図示していないが、ゲームサーバ２０とは別に各通信端末１０のユーザを認証するための認証サーバを設けてもよい。また、多くの通信端末１０からのアクセスを受け入れるために複数のゲームサーバ２０を設ける場合は、その複数のゲームサーバ２０間の負荷を調整するためのロードバランサを設けてもよい。また、ゲームサーバ２０は単一のサーバ装置として構成してもよいが、機能を分散させた複数のサーバ装置として構成してもよい。

（２）通信端末の構成
図２及び図３を参照して通信端末１０について説明する。
図２は、通信端末１０の外観の例を示す図であって、（ａ）は、例えば折り畳み式の携帯端末（携帯電話機）などの釦入力方式の通信端末を例示したものであり、（ｂ）は、例えばスマートフォンなどのタッチパネル入力方式の通信端末を例示したものである。図３は、通信端末１０の内部構成を示すブロック図である。
図３に示すように、通信端末１０は、ＣＰＵ（Central Processing Unit）１１、ＲＯＭ(Read Only Memory)１２、ＲＡＭ(Random Access Memory)１３、画像処理部１４、指示入力部１５、表示部１６、及び、信号送受信部としての通信インタフェース部１７を備えており、各部間の制御信号あるいはデータ信号を伝送するためのバス１８が設けられている。

ＣＰＵ１１は、ＲＯＭ１２内のウェブブラウザをＲＡＭ１３にロードして実行する。そして、ＣＰＵ１１は、指示入力部１５等によってユーザに入力されるＵＲＬ(Uniform Resource Locator)の適切な指定に基づき、通信インタフェース部１７を介して、ゲームサーバ２０からウェブページを表示するためのデータ、すなわち、ＨＴＭＬ(HyperText Markup Language)文書や当該文書と関連付けられた画像などのオブジェクトのデータ（以下、総称して適宜「ＨＴＭＬデータ」と表記する。）を通信インタフェース部１７を介して取得し、そのＨＴＭＬデータを解釈する。なお、通信端末１０には、ウェブブラウザのブラウザ機能を拡張するための様々なプラグインが実装されていてよい。
なお、ＨＴＭＬデータの取得に当たって、ＣＰＵ１１は、予め登録されたユーザＩＤ（ユーザ識別情報）、あるいは指示入力部１５を介して入力されるユーザＩＤを含むアクセス要求メッセージを、通信インタフェース部１７を介してゲームサーバ２０へ通知する。

ウェブブラウザは、画像処理部１４を介して、取得したＨＴＭＬデータに基づき、ゲームサーバ２０から提供されるウェブページを表示部１６に表示する。また、ウェブブラウザは、ユーザが指示入力部１５の操作によってウェブページ上のハイパーリンク(Hyperlink)またはメニューが選択されると、その選択に応じたウェブページを表示するための新たなＨＴＭＬデータの送信（つまり、ウェブページの更新）をゲームサーバ２０へ要求する。

画像処理部１４は、ＨＴＭＬデータの解析結果としてＣＰＵ１１から与えられる表示用画像データに基づいて、表示部１６にウェブページを表示する。表示部１６は、例えば、マトリクス状に画素単位で配置された薄膜トランジスタを含むＬＣＤ(Liquid Cristal Display)モニタであり、表示用画像データに基づいて薄膜トランジスタを駆動することでウェブページの画像を表示画面１６ａに表示する。

通信端末１０が釦入力方式の通信端末（図２（ａ））である場合、指示入力部１５は、ユーザの操作入力を受け入れるための方向指示釦と決定釦などの複数の指示入力釦を含む釦群１５ａ、及び、テンキーなどの複数の指示入力釦を含む釦群１５ｂを備え、各釦の押下（操作）入力を認識してＣＰＵ１１へ出力するためのインタフェース回路を含む。例えば、方向指示釦は、表示部１６に表示されているウェブページをスクロールして表示することをＣＰＵ１１へ指示するために設けられる。また、決定釦は、例えばウェブページ上で複数のハイパーリンクまたはメニューが表示されるときに、アクティブ表示（例えば強調表示）されている１つのハイパーリンクまたはメニューをユーザが選択することをＣＰＵ１１へ指示するために設けられる。なお、通信端末１０を小型の携帯端末によって構成する場合には、これらの釦は、ユーザが通信端末１０を片手で保持したままその親指で操作（クリック）しやすいように、通信端末１０の前面に配置されていることが好ましい。図２（ａ）に示す例では、釦群１５ｂは、釦群１５ａの下方に配置され、「０」〜「９」、「＊」、「＃」（テンキー）が表記された複数の指示入力釦を含む。

通信端末１０がタッチパネル入力方式の通信端末（図２（ｂ））である場合、指示入力部１５は、主として表示画面１６ａに指先あるいはペンで触れることによるタッチパネル方式の入力を受け付ける。タッチパネル入力方式は、静電容量方式などの公知の方式でよい。なお、図２（ｂ）に示すように、通信端末１０がタッチパネル入力方式の場合であっても釦群１５ａが設けられる場合もある。

通信端末１０に表示されるウェブページ上のメニューの選択操作は、例えば通信端末１０が携帯端末である場合には、方向指示釦の押下操作によってメニューを選択し、決定釦の押下操作によって、選択したメニューを確定することによって行われる。また、選択操作は、例えば通信端末１０がタッチパネル入力方式の場合には、ウェブページが表示されている表示画面１６ａ上のメニューの位置を指あるいはペンで指示（タッチ操作）することによって行われる。

（３）ゲームサーバの構成
図４を参照してゲームサーバ２０の構成について説明する。
ゲームサーバ２０は、例えば階層構造の複数のウェブページからなるゲームのウェブサイトを管理しており、通信端末１０に対してゲームのウェブサービスを提供する。図３に示すように、ゲームサーバ２０は、ＣＰＵ２１、ＲＯＭ２２、ＲＡＭ２３、データベース（ＤＢ）アクセス部２４、及び、通信インタフェース部２５を備えており、各部間の制御信号あるいはデータ信号を伝送するためのバス２６が設けられている。なお、ゲームサーバ２０は、ハードウエアに関しては汎用のウェブサーバと同一の構成をとることができる。

ＲＯＭ２２には、クライアントである通信端末１０のウェブブラウザに対してＨＴＭＬ文書や画像などのオブジェクトの表示（ウェブページの表示）のサービスを提供するアプリケーションプログラムが格納されている。ＲＯＭ２２には、アプリケーションプログラム以外にもＣＰＵ２１によって参照される各種データが格納されている。
ＣＰＵ２１は、ＲＯＭ２２内のゲームプログラムをＲＡＭ２３にロードして実行し、通信インタフェース部２５を介して、各種の処理を行う。

例えば、ＣＰＵ２１は、通信インタフェース部２５を介して、ＨＴＭＬデータを通信端末１０宛に送信する。なお、ゲームサーバ２０が通信端末１０のユーザの認証処理を行う場合には、ＣＰＵ２１はその認証処理を行う。
ＣＰＵ２１は、通信インタフェース部を介して、通信端末１０で表示されるウェブページ上でユーザにより選択されたハイパーリンクまたはメニューに応じた処理を行う。その処理は、例えば、新たなＨＴＭＬデータの送信、または、ゲームサーバ２０内の演算処理あるいはデータ処理などを含む。
データベースアクセス部２４は、ＣＰＵ２１がデータベースサーバ３０に対してデータの読み書きを行うときのインタフェースである。

（４）データベースサーバの構成
データベースサーバ３０（記憶装置）は、大容量のハードディスク装置やＲＡＩＤ（Redundant Arrays of Inexpensive Disks）等の形態の装置等、汎用ストレージで実現できる。データベースサーバ３０内の各データベースは、ゲームサーバ２０のデータベースアクセス部２４を介してＣＰＵ２１からのデータの読み書きが可能となるように構成されている。
図５に、データベースサーバ３０の構成の一例を示す。図５に示すように、データベースサーバ３０は、ユーザデータベース３１と、ゲームデータベース３２とを備える。

本実施形態のゲームシステムによって実現されるゲームのタイプは特に限定されるものではないが、以下では、本実施形態のゲームの一例として、ユーザの通信端末１０に対する操作に応じて、ゲーム上のアイテムを探索しながらエリアを進行させるクエストをユーザが実行するゲーム（以下、適宜「本実施形態のゲーム」という。）を採り上げる。
このゲームにおいてユーザは、クエストを実行中に特別なアイテムとしてリレーアイテムを取得する場合がある。本実施形態の一例では、リレーアイテムには所定数の選択肢が含まれており、リレーアイテムを保持しているユーザは、各選択肢に対応するいずれかのマスを選択する。マスを選択したときに得られる選択肢として、カード等のアイテムのユーザへの付与や、所定量の体力ポイント（後述する）の増加等のゲーム上の効果等が含まれている。また、マスを選択したときの選択肢として、「ハズレ」や「アタリ」（例えば、レア度が高いカードの付与）も含まれる。ユーザは、リレーアイテムに含まれるいずれかのマスを選択した後、ユーザを指定してリレーアイテムを移転させる。リレーアイテムは、既に選択されたマスを再び選択することができない状態で移転させられる。リレーアイテムを受け取ったユーザは、同様にしてマスを選択した後、リレーアイテムを他のユーザに移転させる。このように、本実施形態のゲームでは、リレーアイテムがユーザ間で移転させられる仕組みとなっている。
なお、後述するが、本実施形態のゲームシステムでは、リレーアイテムが特定のユーザで滞留することでリレーアイテムの移転が円滑に行われないことを防止するために、リレーアイテムを受け取ったユーザが所定期間の間、例えばクエストを実行しないこと等によりリレーアイテムを放置した場合には、リレーアイテムを他のユーザが奪取できるように構成されている。

以下では、リレーアイテムをクエスト中で手に入れたユーザを「取得ユーザ」といい、リレーアイテムを移転させるユーザを「移転元ユーザ」といい、リレーアイテムの移転対象のユーザを「移転先ユーザ」という。
例えば、取得ユーザはリレーの１番目のユーザであり、取得ユーザからのリレーアイテムの移転先ユーザはリレーの２番目のユーザである。２番目のユーザがリレーの３番目のユーザにリレーアイテムを移転させるときには、２番目のユーザが移転元ユーザとなり、３番目のユーザが移転先ユーザとなる。
また、移転先ユーザのリレーアイテムを奪取するユーザを「奪取ユーザ」ともいう。

図６に、本実施形態のゲームにおいて適用されるユーザデータベース３１の一例を示す。この例では、ユーザデータベース３１は、ユーザＩＤ（ユーザ識別情報）ごとに、ユーザ名、ユーザ画像、進行レベル、経験値、体力ポイント、エリア、現在地点、特典ポイント、仲間のユーザＩＤ、保有アイテムの各項目についての情報を含む。ユーザデータベース３１に含まれる情報は、ゲームサーバ２０によって逐次更新されうる。
以下の説明では、ユーザデータベース３１に含まれるユーザＩＤ、あるいはユーザを特定するユーザ名（後述する）ごとのデータを総称してユーザデータという。ユーザデータを構成する各項目の情報は、以下のとおりである。

・ユーザ名
ゲームの実行時に通信端末１０のユーザを特定するために表示されるユーザ名である。ユーザ名はユーザによって予め指定される所定長以下のテキストである。ユーザ名は、ゲームサーバ２０によって提供されるネットワーク環境（あるいはゲームコミュニティ）上でユーザを特定する名称である。
・ユーザ画像
ユーザ画像は例えばユーザによって予め選択されるアバタ画像である。
・進行レベル
ゲーム上のユーザの進行レベルを示すデータである。例えばＬｖ１（レベル１）からＬｖ１００（レベル１００）までの範囲のレベル値である。
・経験値
本実施形態のゲームにおいて、クエストを実行する度に上昇する値である。経験値が一定量に達すると、進行レベルが１つ増加するとともに経験値はリセットされる（つまり、ゼロになる）。
・体力ポイント
本実施形態のゲームにおいて、クエストを実行する上で必要となるポイントである。体力ポイントは、１回のクエストの実行により所定量低減し、所定の時間が経過する毎に所定量回復（増加）する値である。体力ポイントは、リレーアイテムに含まれるいずれかの選択肢を選択することによって一定量増加する場合があってもよい。
・エリア
本実施形態のゲームにおいて、対象となるユーザが、クエストを実行中のエリアを特定する値である。実行対象のエリアの値は、エリア１、エリア２、…というように順に増加する。図６の例では、ユーザの実行中のエリアがエリア１５であることを示している。
・現在地点（ｍ）
本実施形態のゲームにおいて、対象となるユーザが実行中のエリアにおけるユーザのゲーム上の現在地点をメートル（ｍ）単位で示している。本実施形態のゲームでは、エリア毎にエリアの初期地点から最終地点までの距離が決まっており、現在地点は、実行中のエリアの初期地点からの距離を示している。
・特典ポイント
ユーザがゲーム上で得られる特典である。特典ポイントは、リレーアイテムに含まれるいずれかの選択肢を選択することによって得られる場合があってもよい。
・仲間のユーザＩＤ
対象となるユーザＩＤと関係付けられた他のユーザＩＤのデータである。
・保有アイテム
ユーザがクエストを実行することによって取得したアイテムに関するデータである。ここでは、アイテムを識別するためのアイテムＩＤ（Ｑ３等）が記述される。アイテムは、リレーアイテムに含まれるいずれかの選択肢を選択することによって得られる場合があってもよい。

図５に戻り、ゲームデータベース３２は、ゲームサーバ２０からのアクセスに基づき、ゲームサーバ２０によって実行されたゲームの進行に関する情報、リレー管理データ、及びリレーアイテムデータベースを記憶する。ゲームの進行に関する情報は、ゲームの性質によって多様な情報を含みうる。本実施形態のゲームの場合を例に挙げれば、ゲームの進行に関する情報は、各ユーザのエリア毎のクエストについての詳細結果などを含んでもよい。

リレー管理データは、リレーアイテムの移転に関与する複数のユーザをリレー毎に管理するために設けられているデータであり、そのデータ構成例を図７に示す。
図７に示すリレー管理データは、リレーを特定するためのリレーＩＤ毎に、リレー管理フラグ、リレーアイテム、リレー終了時刻、リレーについてのユーザ履歴（ユーザＩＤ、保持フラグ、アクセスフラグ）、移転基準時刻、及び奪取可否フラグの各項目のデータを含む。
リレー管理データの各項目のデータは以下のとおりである。

・リレー管理フラグ
リレー管理フラグは、リレーが現在進行中であるのか、終了済みであるのかを特定するためのフラグである。本実施形態の例では、リレー管理フラグは、リレーが進行中であるときに「０」であり、リレーが終了済みであるときに「１」である。リレーは、例えば、リレーアイテムをユーザが取得してから所定期間（第２期間）を経過した後、又はリレーアイテムの移転回数が所定回数に達した後に、リレーが終了となってリレー管理フラグが「１」となる。
・リレーアイテム
移転対象となるリレーアイテムを識別するためのアイテムＩＤ（Ｑ１等）が記述される。
・リレー終了時刻
リレー終了時刻は、対象となるリレーＩＤのリレーが終了する時刻であり、例えば、リレーアイテムを１番目のユーザが取得した時刻から所定時間後の時刻に設定される。なお、リレーアイテムの移転回数によってリレーの終了が規定される場合には、リレーの終了時刻は設定されない。
・ユーザ履歴（ユーザＩＤ、保持フラグ、アクセスフラグ）
ユーザ履歴は、リレーが行われる順に、リレーの１番目のユーザ、２番目のユーザ、…の各ユーザについて、ユーザＩＤと、リレーアイテムをユーザが保持しているか否かを示す保持フラグ（「１」：保持している、「０」：保持していない）と、ユーザがクエストページ（後述する）にアクセス済みか否かを示すアクセスフラグ（「１」：アクセス済、「０」：未アクセス）とを含む。
・移転基準時刻
移転基準時刻は、移転元ユーザが移転先ユーザを指定してリレーアイテムを移転させた時刻である。移転基準時刻において移転先ユーザがゲームにログインしていない場合もあるが、移転基準時刻は、移転先ユーザのログインの有無とは無関係に設定される。
・奪取可否フラグ
奪取可否フラグは、対象となるユーザＩＤのユーザからリレーアイテムを奪取することが可能であるか否かを示すフラグ（「１」：奪取可能、「０」：奪取不可）である。

リレーアイテムデータベースには、リレーアイテム毎に、リレーアイテムに含まれる複数のマスの各々選択肢と、各マスがユーザに既に選択されたか否かを示す選択フラグ（「１」：選択済、「０」：未選択）とが記憶されている。図８にリレーアイテムデータベースの一例を示す。図８に示すリレーアイテムデータベースの例では、４−１〜４−４の１６個のマスに対応する選択肢が記述されている。

（５）本実施形態のゲーム
以下、本実施形態のゲームの内容について、図９〜１２を参照しながら説明する。図９及び図１０はそれぞれ、本実施形態のゲームにおいて、リレーアイテムを複数のユーザ間でリレーする場合に、リレーの１番目のユーザ（つまり、取得ユーザ）の通信端末１０上に表示される一連のウェブページを示す図である。図１１は、本実施形態のゲームにおいて、リレーの２番目のユーザ（つまり、１番目のユーザにとっての移転先ユーザ）の通信端末１０上に表示される一連のウェブページを示す図である。図１２は、本実施形態のゲームにおいて、リレーアイテムを奪取する場合の一連のウェブページを示す図である。図１３は、複数のユーザ間でのリレーアイテムのリレーの態様の一例を説明するための図である。
なお、以下の説明において、通信端末１０に表示されるウェブページ上で表示されるメニュー、マーク等はウェブページ上で所望の位置に配置されるものであって、通信端末１０で視認されるメニュー、マーク等の表示画面上の位置は、ユーザの方向指示釦あるいはタッチパネル操作によるウェブページのスクロール操作によって変化しうる。

（５−１）１番目のユーザによるクエスト処理
図９に例示する本実施形態のゲームのトップページＰ０は、個々のユーザＩＤに応じたウェブページで構成される。図９の例では、ユーザ画像とともに、ユーザデータ表示領域、及びメニュー表示領域を含む。図９では、一例としてユーザＫＮＭ（ユーザ名；ＫＮＭ）の通信端末１０に表示されるウェブページの例を示している。
ユーザデータ表示領域は、対象となるユーザＩＤのユーザデータに含まれる、進行レベル、体力ポイントの各項目のデータ（図６参照）が表示される領域である。メニュー表示領域は、本実施形態のゲームにおいて、アイテムを取得するためにエリアを探索しながら進行する処理であるクエスト処理の実行を開始するためのメニューｍ１（「クエスト」）を含む複数のメニュー（メニューｍ１以外は図示せず）が表示される領域である。

図９のゲームのトップページＰ０上でメニューｍ１（「クエスト」）が選択操作されると、Ｐ１に示すようにウェブページが更新される。メニューｍ１（「クエスト」）に対する選択操作の結果として表示されるウェブページを、以下の説明では「クエストページ」ということがある。
このウェブページＰ１には、ユーザＫＮＭのクエストの対象エリア（この例では、エリア１５）の画像を表示する表示領域１０１と、クエストの進行状況を示す表示領域１０２と、ユーザデータ表示領域１０３とが含まれる。表示領域１０２には、ユーザがクエストとしてエリアを探索するためのメニューｍ５（「探索する」）と、ユーザの対象エリアにおける現在地点（図９に示す例では、６００ｍ）と、対象エリアに設定されている最終地点（図９に示す例では、１１００ｍ）とが表示される。表示領域１０２には、１回のメニューｍ５の選択操作によって消費される体力ポイント（図９の例では、−５）と、１回のメニューｍ５の選択操作によって得られる経験値（図９の例では、＋８）とが表示される。

メニューｍ５が選択操作される度に、所定の、あるいはランダムな確率で、ゲーム上で用意されている様々なアイテムのいずれかをユーザが入手できるように構成されている。メニューｍ５が選択操作される度に一定の、あるいはランダムな増加量で現在地点の値が増加し、エリア毎に設定されている最終地点（ここでは、１１００ｍ）まで達するとエリア１５の探索が終了する。メニューｍ５が選択操作される度に、ユーザＫＮＭの体力ポイントが所定量だけ消費され、ユーザＫＮＭの経験値が所定量だけ増加するが、それによって、表示領域１０３に表示される体力ポイントと経験値の値が変動する。なお、例えば、表示領域１０３において、体力ポイントが「１１３／１５０」と表示されているのは、ユーザＫＮＭの現在の体力ポイントが１１３であり、体力ポイントの最大値が１５０であることを意味している。また、表示領域１０３において、経験値が「１９０／１０００」と表示されているのは、ユーザＫＮＭの現在の経験値が１９０であり、経験値が１０００に達するとユーザの進行レベルが１つ増加することを意味している。体力ポイントが上記所定量未満になった場合にはクエスト処理を実行することはできない。その場合には、体力ポイントが回復するまでユーザＫＮＭは待機する必要がある。
図９の例では、ユーザＫＮＭの探索対象のエリアはエリア１５であるが、このエリア１５の最終地点に達すると次のエリアであるエリア１６を進むことができるように構成されている。

（５−２）１番目のユーザによるリレーアイテムの取得
ウェブページＰ１においてメニューｍ５（「探索する」）に対する選択操作を１又は複数回繰り返すことで、Ｐ２に示すようにウェブページが更新され、ユーザＫＮＭがリレーアイテムＱ１を手に入れた場合が想定される。この場合、ユーザＫＮＭは、リレーアイテムの取得ユーザであるとともに、リレーにおける１番目のユーザとなる。
リレーアイテムを入手すると、メニューｍ１０（「次へ」）の選択操作に応じて、Ｐ３に示すようにウェブページが更新される。ウェブページＰ３には、リレーアイテムＱ１に含まれる１６個の選択肢の各々に対応した、４×４の１６個のマス（マス１−１〜マス４−４）が表示される。１６個のマスの中からいずれかのマスをユーザが選択することによって、ユーザは選択したマスに対応した選択肢を得ることができる。図９のウェブページＰ３において、ユーザが例えばマス３−３を選択操作すると、例えば図１０のＰ４に示すようにウェブページが更新される。この例では、マス３−３にアイテムとしてカードＤ３の選択肢が対応しており、ユーザがカードＤ３を入手した場合を示している。ウェブページＰ４に例示するように、ユーザが入手したカードのレア度（例えば、ノーマル）や、カードに表示されているキャラクタ（例えば、恐竜キャラクタ）の属性（例えば、体長や体重）が表示されてもよい。
なお、前述したように、選択肢は、Ｐ４に例示したカード等のアイテムに限らず、所定量の体力ポイントの増加等のゲーム上の効果や、「ハズレ」や「アタリ」（例えば、レア度が高いカードの付与）も含まれてもよい。レア度は、カード等のアイテムの希少価値のレベルを示し、例えば、ノーマル、レア、レア＋、Ｓレアの順に、希少価値が高い。レア度が高い「アタリ」のカードは、例えば最も希少価値が高いＳレアのカードであってもよい。

（５−３）１番目のユーザによるリレーアイテムの移転
ウェブページＰ４において、メニューｍ１５（「リレーアイテムを渡す」）が選択操作されると、例えばＰ５に示すようにウェブページが更新される。ウェブページＰ５では、ユーザＫＮＭの仲間のうち、無作為に選択された所定数（この例では、５）のユーザが、例えば進行レベル、及び現在実行中のエリアと対応付けて表示される。選択された各ユーザは、メニューｍ２０（「渡す」）が対応付けられて表示され、いずれかのユーザを移転先ユーザとして選択できるようになっている。以下では、移転先ユーザとしてユーザＡＢＣが選択された場合を想定する。
なお、ウェブページＰ５には、例えば、リレーの残り時間（Ｐ５の例では、２３時間５４分）や、リレーアイテムＱ１が移転された人数（図９の例では、０人）が表示されてもよい。

（５−４）２番目のユーザによるリレーアイテムの移転
ユーザＫＮＭと同様に、リレーアイテムＱ１の移転先ユーザであるユーザＡＢＣによって、図１１のゲームのトップページＰ１０上でメニューｍ１（「クエスト」）が選択操作されると、Ｐ１１に示すように、ユーザＡＢＣ向けのクエストページが表示される。ここでは、ユーザＡＢＣがリレーアイテムＱ１の移転先ユーザとして選択済みであるため、リレーアイテムＱ１がユーザＫＮＭから移転されたことを示すテキストを含むクエストページが最初に表示される。
ウェブページＰ１１において、メニューｍ１０（「次へ」）の選択操作に応じて、Ｐ１２に示すようにウェブページが更新される。ウェブページＰ１２には、Ｐ３と同様に、４×４の１６個のマス（マス１−１〜マス４−４）が表示される。このとき、マス３−３については、既にリレーの１番目のユーザであるユーザＫＮＭが選択済みであるため、ユーザＡＢＣが再度選択することはできない。例えば、仮に、選択済のマスを指で指定、あるいはカーソル等で指定しても反応しないようにしてもよい。好ましくは、選択できないマスは、選択できないことがユーザに認識しやすいように、選択可能なマスとは異なる態様で表示される。例えば、該当のマス全面が灰色、黒色等となるよう表示してもよい。

（５−５）リレーアイテムの奪取
上述したように、本実施形態のゲームでは、リレーアイテムＱ１をユーザが入手し、そのリレーアイテムＱ１を順次仲間の間で移転していくことによって、リレーに関与する各ユーザが、リレーアイテムＱ１に含まれる複数の選択肢のうちいずれかを得る仕組みとなっている。しかし、リレーアイテムＱ１が移転されたユーザが、クエストページにアクセスしない状態が長時間継続した場合、そのユーザの下でリレーアイテムＱ１が滞留してしまい、リレーアイテムＱ１の移転が滞ってしまう状態になる。そこで、本実施形態のゲームでは、リレーアイテムＱ１が移転されたユーザが、クエストページにアクセスしない状態が所定時間継続した場合に、リレーアイテムＱ１を他の仲間のユーザが奪取できる仕組みとなっている。

図１２では一例として、ユーザＦＧＨに対して、リレーアイテムＱ１が移転されたものの、ユーザＦＧＨがクエストページにアクセスしない状態が所定期間（第１期間；以下、「放置可能期間」ともいう。）継続し、例えばユーザＦＧＨの仲間のユーザＸＹＺが、ユーザＦＧＨの放置可能期間の後に、リレーアイテムＱ１をユーザＦＧＨから奪取する場合が想定されている。
ユーザＸＹＺによって、図１２のゲームのトップページＰ２０上でメニューｍ１（「クエスト」）が選択操作されると、Ｐ２１に示すように、ユーザＸＹＺ向けのクエストページが表示される。ウェブページＰ２１が表示される時点では、ユーザＦＧＨの放置可能期間が経過しており、ウェブページＰ２１の表示領域１０４には、ユーザＦＧＨがリレーアイテムＱ１を放置中であることを示すテキストと、リレーアイテムＱ１を奪取するためのメニューｍ２５（「奪う」）とが表示される。ここで、メニューｍ２５が選択操作されると、Ｐ２２に示すようにウェブページが更新される。つまり、リレーアイテムＱ１がユーザＦＧＨからユーザＸＹＺに移転される。Ｐ２２以降のウェブページの遷移は、ユーザＫＮＭのＰ２以降のウェブページ（図９、図１０参照）と同様である。
なお、図示しないが、ユーザＦＧＨは、放置可能期間が経過した後に自らのクエストページにアクセスした場合、リレーアイテムＱ１が移転されたことが表示されず（例えば、Ｐ２２に示すウェブページは表示されず）、リレーアイテムＱ１が他のユーザに奪取されたことを認識することはない。

（５−６）ユーザ間におけるリレーアイテムの移転
（５−１）〜（５−５）では、リレーアイテムＱ１の移転について、ウェブページの遷移に沿って具体的に説明したが、以下では、図１３のタイミングチャートを参照して、複数のユーザ間で移転を行う場合の移転の態様を時間の経過に沿って説明する。

図１３において、リレーの１番目のユーザがリレーアイテムを入手し、リレーアイテムの移転先ユーザを選択した時刻が、リレーの２番目のユーザ（１番目のユーザからみた移転先ユーザ）の移転基準時刻となる。この移転基準時刻から所定時間（例えば、１０時間）の期間が、２番目のユーザについての放置可能期間となる。この放置可能期間内に２番目のユーザがクエストページにアクセスすると、２番目のユーザはリレーアイテムを受け取ることができ、リレーアイテムに含まれるいずれかの選択肢を得ることができる。なお、放置可能期間内にクエストページにアクセスした場合には、放置可能期間を経過した後もユーザはリレーアイテムを保持し、他のユーザに移転することができる。

図１３に示すように、例えばリレーのＮ番目のユーザが、自らの移転基準時刻を起点とする放置可能期間内にクエストページにアクセスしない場合を想定する。この場合、放置可能期間を経過すると、Ｎ番目のユーザ以外の他の仲間のユーザが、リレーアイテムをＮ番目のユーザから奪取することが可能となる。図１３では、Ｎ＋１番目のユーザがリレーアイテムをＮ番目のユーザから奪取する場合が示されている。なお、Ｎ番目のユーザが自らの放置可能期間の経過後にクエストページにアクセスした場合には、自身にリレーアイテムが移転されたことが通知されないため、Ｎ番目のユーザがＮ＋１番目のユーザにリレーアイテムを奪取されたことを認識することはない。
図１３に示したように、本実施形態のゲームでは、リレーアイテムが特定のユーザ（図１３では、Ｎ番目のユーザ）の下で滞留することでリレーアイテムの移転が円滑に行われないことが防止されるとともに、Ｎ番目のユーザがリレーアイテムを奪取されたことを認識することはないため、Ｎ番目のユーザに不満が生ずるといった事態が避けられる。

（６）ゲーム制御装置における各処理の概要
次に、上述した本実施形態のゲームを実現するためゲーム制御装置における各処理について説明する。
本実施形態では、ゲームサーバ２０及びデータベースサーバ３０によってゲーム制御装置が構成されている。以下では、上述したゲームが適用される場合を例として、本実施形態のゲーム制御装置で実現される機能について、図１４を参照して説明する。図１４は、本実施形態のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図である。なお、この機能ブロック図において、関係付け手段５１、ゲーム実行手段５２、選択手段５４、及び、通知手段５６は、本発明に必ずしも必須の要素ではない。

関係付け手段５１は、ユーザ間を関係付ける機能を備える。例えば、関係付け手段５１は、ユーザＩＤに基づく申請を契機として、当該ユーザＩＤと他のユーザＩＤとを仲間として関係付ける機能を備える。
関係付け手段５１の機能は例えば、以下のとおり実現される。ゲームサーバ２０のＣＰＵ２１は、無線通信インタフェース部２５を介して、あるユーザＩＤに対応するユーザの通信端末１０から、仲間になりたいユーザＩＤ（あるいは、対応するユーザ名）を指定した申請メッセージ（申請）を受け付ける。この申請メッセージの送信は、ユーザの通信端末１０に提供されるウェブページの機能として予め設定されている。ＣＰＵ２１は、申請メッセージを受け付けると、申請メッセージに含まれるユーザＩＤに基づくアクセスがあったタイミングで、そのユーザＩＤに対応する通信端末１０宛に、他のユーザＩＤに基づく申請を承認するか否かを返信することを要求するためのウェブページを表示させるＨＴＭＬデータを送信する。その申請を承認することが返信されれば、ＣＰＵ２１は、両者を仲間として登録する。具体的には、ＣＰＵ２１は、ユーザデータベース３１内の対応する２つのユーザＩＤのユーザデータの「仲間のユーザＩＤ」の箇所（図６参照）にデータを書き込む。
なお、ユーザ同士を関係付ける条件は、上記のような申請と承認を必要とする形式に限らず、ゲーム上の同一のエリアのクエストを実行するユーザ同士を、ゲーム内で関係付けられたユーザ同士と位置付け、仲間として登録してもよい。あるいは、所定回数の挨拶メッセージを送信するユーザ同士を自動的に仲間として登録してもよいし、ユーザ間でバトルを行うゲーム上のモードが存在する場合には、所定回数以上バトルを行ったユーザ同士を自動的に仲間として登録してもよい。

ゲーム実行手段５２は、ユーザによるゲームを実行する機能を備える。
ゲーム実行手段５２の機能は、例えば、通信端末１０に表示するウェブページを、通信端末１０からの要求に応じて逐次更新させることによって、ゲームを進行させるようにしてもよい。この場合、ゲーム実行手段５２の機能を実現するために、ゲームサーバ２０のＣＰＵ２１は、通信端末１０からＨＴＴＰリクエストを受信し、そのＨＴＴＰリクエストに応じてゲーム上の所定の処理を行い、ゲームの実行結果としてのＨＴＭＬデータを含むＨＴＴＰレスポンスを通信端末１０へ返信する。

実行対象のゲームの内容が例えば図９に関連付けて説明したクエストである場合、ゲームサーバ２０のＣＰＵ２１は、ユーザによるメニューｍ５（「探索する」）の選択操作結果を含むＨＴＴＰリクエストを受信すると、処理対象のユーザの現在地点、体力ポイント、及び経験値を更新する処理を行う。ＣＰＵ２１は、ユーザの現在地点、体力ポイント、及び経験値のデータを、クエストの実行開始時（メニューｍ１の選択時）にデータベースサーバ３０からＲＡＭ２３に転送し、クエスト中はＲＡＭ２３内のデータに対して更新処理を行い、クエスト終了時に、ＲＡＭ２３内の更新後のデータをデータベースサーバ３０内のデータに上書きするようにしてもよい。
メニューｍ５の選択操作に応じて所定の、若しくはランダムな確率で、あるいは、所定数のエリアのクエストが完了すると、ＣＰＵ２１は、アイテムをユーザに付与することを決定する。ＣＰＵ２１は、複数のアイテムが記述されているデータベース（図示せず）にアクセスして付与対象のアイテムを選択してもよい。複数のアイテムの中には、上述したリレーアイテムが含まれている。

対応付け手段５３は、リレーアイテム（アイテム情報）をユーザに対応付ける機能を備える。本実施形態のゲームでは、リレーアイテムのユーザへの対応付けは、例えば、クエスト中においてユーザがリレーアイテムを取得することに相当する。
対応付け手段５３の機能は、以下のようにして実現することができる。ゲームサーバ２０のＣＰＵ２１は、クエスト中においてユーザにリレーアイテムを付与することを決定すると、リレー管理データにアクセスして、新たなリレーＩＤを発行し、ユーザ履歴の欄に、付与対象のユーザのユーザＩＤと保持フラグ（「１」）を書き込む。これによって、リレーアイテムが取得ユーザ（１番目のユーザ）に対応付けられ、取得ユーザが、発行されたリレーＩＤに対応付けられる。なお、ＣＰＵ２１は、リレーの１番目のユーザについては、リレー管理データにおいて移転基準時刻を書き込まなくてもよい。

選択手段５４は、リレーアイテム（アイテム情報）を保持しているユーザ（つまり、リレーアイテムに対応付けられているユーザ）の入力情報に基づいて、リレーアイテムに含まれる所定数の選択肢の中からいずれかの選択肢を選択する機能を備える。本実施形態の例では、リレーアイテムには、所定数のマスが表示され、各マスに選択肢が対応付けられており、ユーザによるいずれかのマスを選択操作に基づいて、マスに対応する選択肢が選択される。なお、本実施形態のゲームでは、ユーザがリレーアイテムを保持している間の選択肢に対する選択は１度のみ可能である場合を想定する。

選択手段５４の機能は、以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、ユーザが選択肢の選択を行うためのＨＴＭＬデータを生成するに当たって、リレーアイテムデータベースにアクセスして、対象となるリレーアイテムの選択フラグに基づいて、ユーザが選択可能なマスを決定する。ＣＰＵ２１は、ユーザの通信端末１０から、マスの選択結果を含むＨＴＴＰリクエストを取得すると、リレーアイテムデータベース（図８参照）にアクセスして、選択されたマスに対応する選択肢を読み出し、読み出した選択肢を含むＨＴＭＬデータを生成してユーザの通信端末１０へ送信する。ＣＰＵ２１は、読み出した選択肢に対応する選択フラグを「０」（未選択）から「１」（選択済）に書き換える。次いでＣＰＵ２１は、選択肢に応じた処理を実行する。選択肢に応じた処理の実行内容は、選択肢によって異なる。例えば、選択肢が「特定のカードの付与」である場合には、ユーザのユーザデータにアクセスして、付与対象のカードをユーザの保有アイテムとして書き込む。選択肢が「所定量の体力ポイントの増加」である場合には、ユーザのユーザデータにアクセスして、ユーザの体力ポイントを所定量だけ加算して書き換える処理を行う。なお、選択肢が「ハズレ」である場合には、選択肢に応じた処理は実質的に行われない。
なお、ユーザがリレーアイテムを保持している間の選択肢に対する選択は１度のみ可能である場合、ＣＰＵ２１は、リレー管理データに、ユーザが選択肢に対する選択を行ったか否かを示すフラグ（図示せず）を記憶させてもよい。

第１移転手段５５は、ユーザの入力情報に基づいて、当該ユーザに対するリレーアイテム（アイテム情報）の対応付けを解除し、かつリレーアイテムを当該ユーザとは異なるユーザへ対応付けることで、ユーザ間でリレーアイテムを移転（リレー）する機能を備える。本実施形態のゲームでは、リレーアイテムのユーザ間の移転は、移転元ユーザが他のユーザを移転先ユーザとして選択したことに相当する。
第１移転手段５５の機能は、以下のようにして実現することができる。ゲームサーバ２０のＣＰＵ２１は、リレーアイテムの移転要求を含むＨＴＴＰリクエストを受信すると、移転元ユーザに関係付けられた仲間のユーザの中からランダムに所定数のユーザを選択して、移転元ユーザに提示するためのＨＴＭＬデータを生成する。移転元ユーザが仲間のユーザの中からいずれかのユーザを移転先ユーザとして選択したことを認識すると、リレー管理データにアクセスして、対象となるリレーＩＤにおけるユーザ履歴の欄において、移転元ユーザのユーザＩＤに対応する保持フラグを「１」から「０」に変更する。ＣＰＵ２１はさらに、そのユーザ履歴の欄において、移転元ユーザに選択された移転先ユーザのユーザＩＤを書き込み、保持フラグとして「１」を書き込む。これによって、移転元ユーザに対するリレーアイテム（アイテム情報）の対応付けが解除され、かつリレーアイテムが当該ユーザとは異なる移転先ユーザに対応付けられたことになる。また、新たな移転先ユーザが、対象となるリレーＩＤに対応付けられることになる。

通知手段５６は、第１移転手段５５によってリレーアイテム（アイテム情報）がユーザに移転されてから放置可能期間（第１期間）が経過した後、当該ユーザの仲間（関係付けられたユーザ）に対して、リレーアイテムが移転可能（つまり、奪取可能）であることを通知する機能を備える。
通知手段５６の機能は、以下のようにして実現することができる。ゲームサーバ２０のＣＰＵ２１は、ユーザからクエストページへのアクセス要求（例えば、メニューｍ１（「クエスト」）やメニューｍ５（「探索する」）等の選択操作に基づくＨＴＴＰリクエスト）を認識すると、リレー管理データにアクセスし、現在実行中（つまり、リレー管理フラグが「０」）のリレーＩＤに対応するリレーの中で、奪取可否フラグが「１」（奪取可能）となっている仲間のユーザが存在するか否か検索する。ＣＰＵ２１は、検索の結果、該当するユーザが存在する場合には、アクセス要求に対して送信するＨＴＭＬデータに、リレーアイテムを奪取可能な（つまり、リレーアイテムが移転可能な）仲間のユーザが存在することを示すテキストを含ませるようにする。

第２移転手段５７は、第１移転手段５５によるリレーアイテム（アイテム情報）の移転から放置可能期間（第１期間）の間、移転先ユーザがクエストページにアクセスしない（つまり、リレーアイテムに関するゲームを実行しない）場合、移転先ユーザ以外のユーザの入力情報に基づいて、当該ユーザにリレーアイテムを移転する機能を備える。
第２移転手段５７の機能は、以下のようにして実現することができる。ゲームサーバ２０のＣＰＵ２１は、保持フラグが「１」（保持している）となっているユーザについて、放置可能期間の終了時点（つまり、移転基準時刻から所定時間後の時刻）において、保持フラグが「１」であって、かつアクセスフラグが「０」（未アクセス）である場合に、そのユーザの奪取可否フラグを「０」（奪取不可）から「１」（奪取可能）に書き換え、保持フラグを「１」から「０」（保持していない）に書き換える。すなわち、ＣＰＵ２１は、「リレーアイテムの移転から放置可能期間の間に移転先ユーザがクエストページにアクセスしない」という条件を満足するか否かについては、奪取可否フラグをチェックすることによって判断することができる。

ＣＰＵ２１は、ユーザ（奪取ユーザ）によるリレーアイテムの奪取要求（例えばメニューｍ２５（「奪う」）の選択操作結果（図１２参照））を含むＨＴＴＰリクエストを取得すると、リレー管理データにアクセスして、対象となるリレーＩＤにおけるユーザ履歴の欄において、奪取可否フラグが「１」（奪取可能）となっているユーザのユーザＩＤに対応する保持フラグを「１」（保持している）から「０」（保持していない）に変更する。ＣＰＵ２１はさらに、そのユーザ履歴の欄において、奪取ユーザのユーザＩＤを書き込み、保持フラグとして「１」を書き込む。これによって、奪取ユーザへのリレーアイテムの移転が行われたことになる。

（７）本実施形態のゲーム制御装置の主要な処理のフロー
次に、本実施形態のゲーム制御装置により行われる主要な処理のフローの一例について、図１５〜２０のフローチャートを参照して説明する。図１５は、本実施形態のゲームにおいて、リレーアイテムに関連する全体処理のフローチャートである。図１５に示すフローチャートの処理は、ユーザ単位及び／又はリレーＩＤ単位で行われる。図１６は、リレーアイテム付与処理についてのフローチャートである。図１７は、リレーアイテム移転処理についてのフローチャートである。図１８は、リレーアイテム放置監視処理についてのフローチャートである。図１９は、クエストのアクセス処理についてのフローチャートである。図２０は、リレーアイテム奪取処理についてのフローチャートである。
図１５に示すように、リレーアイテムに関連して行われる処理は、リレーアイテム付与処理（ステップＳ１０）、リレーアイテム移転処理（ステップＳ２０）、リレーアイテム放置監視処理（ステップＳ３０）、クエストへのアクセス処理（ステップＳ４０）、及びリレーアイテム奪取処理（ステップＳ５０）を含む。

（７−１）リレーアイテム付与処理（ステップＳ１０；図１６）
ゲームサーバ２０のＣＰＵ２１は、任意のユーザによるクエストページにおいてメニューｍ５（「探索する」）の選択操作結果を含むＨＴＴＰリクエストを取得すると、例えば、所定の、若しくはランダムな確率で、アイテムをユーザに付与することを決定する。このとき、ユーザに付与することを決定したアイテムがリレーアイテムである場合には（ステップＳ１００：ＹＥＳ）、ステップＳ１１０へ進む。ユーザに付与することを決定したアイテムがリレーアイテムでない場合には（ステップＳ１００：ＮＯ）、全体処理へ戻る。

ＣＰＵ２１は、リレーアイテムを特定のユーザに付与することを決定すると、新たなリレーが開始されることになるため、新たなリレーＩＤを発行する（ステップＳ１１０）。ＣＰＵ２１は、例えば、新たなリレーＩＤを発行した時刻から所定期間（第２期間；例えば、５日後までの期間）後の時刻をリレー終了時刻として書き込む。次にＣＰＵ２１は、リレー管理データにおいて、ステップＳ１１０で発行したリレーＩＤに対応付けて、リレーアイテムの付与対象のユーザ（取得ユーザ；１番目のユーザ）のデータを書き込む（ステップＳ１２０）。具体的には、ＣＰＵ２１は、付与対象のユーザのユーザＩＤと保持フラグ（「１」）をユーザ履歴の欄に書き込む。ＣＰＵ２１は、付与対象のユーザのアクセスフラグとして「１」（アクセス済）を書き込み、奪取可否フラグとして「０」（奪取不可）を書き込む。

次いでＣＰＵ２１は、リレーアイテムに含まれる所定数の選択肢に対応するマスの選択結果を含むＨＴＴＰリクエストを通信端末１０から取得すると、リレーアイテムデータベースにアクセスして、マスの選択結果（例えば、マス３−３等）に対応する選択肢の内容を読み出し、読み出した選択肢を含むＨＴＭＬデータを生成してユーザの通信端末１０へ送信する処理（選択処理）を実行する（ステップＳ１３０）。ＣＰＵ２１は、読み出した選択肢に対応する選択フラグを「０」（未選択）から「１」（選択済）に書き換える。ＣＰＵ２１はさらに、読み出した選択肢に応じた処理を実行する（ステップＳ１４０）。この処理の実行内容は、選択肢によって異なる。例えば、選択肢が「特定のカードの付与」である場合には、ユーザのユーザデータにアクセスして、付与対象のカードをユーザの保有アイテムとして書き込む。

（７−２）リレーアイテム移転処理（ステップＳ２０；図１７）
ユーザからリレーアイテムの移転要求が行われた場合（ステップＳ２００：ＹＥＳ）、つまりＣＰＵ２１が、ユーザの通信端末１０から例えばメニューｍ１５（「リレーアイテムを渡す」；図１０参照）の選択操作結果を含むＨＴＴＰリクエストを取得した場合には、ステップＳ２１０へ進む。次いでＣＰＵ２１は、ユーザの通信端末１０から移転先ユーザの選択結果（いずれかのメニューｍ２０（「渡す」）の選択操作結果；図１０参照）を含むＨＴＴＰリクエストを取得した場合には（ステップＳ２１０：ＹＥＳ）、リレー管理データにおいて、対象となるリレーＩＤに対応付けて、移転元ユーザと移転先ユーザのデータを書き込み、又は更新する（ステップＳ２２０）。具体的には、ＣＰＵ２１は、対象となるリレーＩＤの移転元ユーザのユーザＩＤに対応する保持フラグを「１」（保持している）から「０」（保持していない）に変更する。ＣＰＵ２１は、ステップＳ２１０において選択された移転先ユーザのユーザＩＤと保持フラグ（「１」）をユーザ履歴の欄に書き込み、移転先ユーザのユーザＩＤに対応する移転基準時刻として、ステップＳ２１０によるＨＴＴＰリクエストを取得した時刻を書き込む。ＣＰＵ２１は、移転先ユーザのアクセスフラグとして「０」（未アクセス）を書き込み、奪取可否フラグとして「０」（奪取不可）を書き込む。

（７−３）リレーアイテム放置監視処理（ステップＳ３０；図１８）
リレーアイテム放置監視処理は、リレーアイテムの移転先ユーザが、クエストページにアクセスせずに、リレーアイテムが移転されたことを知らずに放置している時間が放置可能期間を越えたか否かを監視するための処理である。
ゲームサーバ２０のＣＰＵ２１は、リレー管理データにアクセスして、保持フラグが「１」（保持している）となっているユーザについて、放置可能期間の終了時点（つまり、移転基準時刻から所定時間後の時刻）において、保持フラグが「１」（保持している）であって、かつアクセスフラグが「０」（未アクセス）であるか否かを判断する（ステップＳ３００）。ステップＳ３００の判断がＹＥＳである場合には、対象となるユーザからリレーアイテムを移転させることを可能にするため、ＣＰＵ２１は、そのユーザの奪取可否フラグを「０」（奪取不可）から「１」（奪取可能）に書き換え、保持フラグを「１」（保持している）から「０」（保持していない）に書き換える（ステップＳ３１０）。

（７−４）クエストへのアクセス処理（ステップＳ４０；図１９）
クエストへのアクセス処理は、リレーアイテムを保持しているユーザがクエストページへアクセスしたときに行われる処理である。
ゲームサーバ２０のＣＰＵ２１は、ユーザからクエストページへのアクセス要求（例えば、メニューｍ１（「クエスト」）やメニューｍ５（「探索する」）等の選択操作に基づくＨＴＴＰリクエスト）を認識すると（ステップＳ４００：ＹＥＳ）、リレー管理データにアクセスして、そのユーザがリレーアイテムを保持しているか、つまり保持フラグが「１」であるか否かを判断する（ステップＳ４１０）。ＣＰＵ２１は、処理対象のユーザの保持フラグが「１」（保持している）である場合に（ステップＳ４１０：ＹＥＳ）、ステップＳ４２０以降の処理を行う。なお、リレーアイテムが移転されたことを知らずに放置している時間が放置可能期間を越えた場合には、保持フラグが既に「０」に書き換えられているため（図１８のステップＳ３１０を参照）、ステップＳ４２０以降の処理は行われない。
本実施形態のゲームでは、ユーザがリレーアイテムを保持している間の選択肢に対する選択は１度のみ可能であるため、対象となるリレーアイテムについてマスを選択済みでない場合に（ステップＳ４２０：ＮＯ）、ＣＰＵ２１は、ステップＳ４３０及びＳ４４０の処理を行う。ステップＳ４３０及びＳ４４０の処理はそれぞれ、リレーアイテム付与処理におけるステップＳ１３０及びＳ１４０（図１６参照）と同一であり、マスの選択処理と選択肢に応じた処理が行われる。

（７−５）リレーアイテム奪取処理（ステップＳ５０；図２０）
リレーアイテム奪取処理は、リレーアイテムの移転先ユーザがクエストページにアクセスせずにリレーアイテムを放置している時間が放置可能期間を越えた場合に、そのユーザからリレーアイテムを他のユーザに移転させる（他のユーザからみればリレーアイテムを奪取する）処理である。
ゲームサーバ２０のＣＰＵ２１は、ユーザからクエストページへのアクセス要求（例えば、メニューｍ１（「クエスト」）やメニューｍ５（「探索する」）等の選択操作に基づくＨＴＴＰリクエスト）を認識すると（ステップＳ５００：ＹＥＳ）、リレー管理データにアクセスして、そのユーザのいずれかの仲間について奪取可否フラグが「１」（奪取可能）であるか否か判断する（ステップＳ５１０）。このときＣＰＵ２１は、処理対象のユーザのユーザデータにアクセスしてそのユーザの仲間のユーザＩＤを読み出す。ステップＳ５１０の判断がＹＥＳである場合には、ＣＰＵ２１は、ステップＳ５００のＨＴＴＰリクエストに対するレスポンスとしてのＨＴＭＬデータに、奪取可否フラグが「１」である仲間のユーザが保持するリレーアイテムが奪取可能であることを通知するメッセージを含ませる（ステップＳ５２０）。このＨＴＭＬデータの送信により、処理対象のユーザには例えば図１２のＰ２１に例示したウェブページが表示される。

次いでＣＰＵ２１は、処理対象のユーザからリレーアイテムの奪取要求（例えば、図１２のメニューｍ２５（「奪う」）の選択操作に基づくＨＴＴＰリクエスト）を認識すると（ステップＳ５３０：ＹＥＳ）、リレー管理データにアクセスして、対象となるリレーＩＤに対応付けて、移転元ユーザと移転先ユーザのデータの書き込み、又は更新を行う（ステップＳ５４０）。具体的には、ＣＰＵ２１は、対象となるリレーＩＤにおけるユーザ履歴の欄において、奪取可否フラグが「１」（奪取可能）となっている仲間のユーザのユーザＩＤに対応する保持フラグを「１」（保持している）から「０」（保持していない）に変更する。ＣＰＵ２１はさらに、そのユーザ履歴の欄において、処理対象のユーザ、つまり奪取ユーザのユーザＩＤを書き込み、保持フラグとして「１」（保持している）を書き込む。

（７−６）各種フラグのデータ変化の例（図２１）
図２１は、リレー管理データで管理する各種フラグ（アクセスフラグ、保持フラグ、奪取可否フラグ）について、特定のリレーアイテムの移転におけるデータの変化の例を示すタイミングチャートである。図２１の例では、リレーアイテムの取得ユーザがユーザＫＮＭであり、ユーザＫＮＭからユーザＡＢＣへリレーアイテムが移転され、ユーザＡＢＣからユーザＦＧＨへリレーアイテムが移転され、ユーザＦＧＨに移転されたリレーアイテムがユーザＸＹＺに奪取された場合を示している。

時刻ｔ１において、ユーザＫＮＭは、クエストを実行中にリレーアイテムを取得し、それによって新たなリレーＩＤが発行され、ユーザＫＮＭの保持フラグが「１」となる。
時刻ｔ２において、ユーザＫＮＭからユーザＡＢＣへリレーアイテムの移転が行われ、それによって移転元ユーザであるユーザＫＮＭの保持フラグが「１」→「０」に変化し、移転先ユーザであるユーザＡＢＣの保持フラグとして「１」が設定される。
時刻ｔ３において、ユーザＡＢＣからユーザＦＧＨへリレーアイテムの移転が行われ、それによって移転元ユーザであるユーザＡＢＣの保持フラグが「１」→「０」に変化し、移転先ユーザであるユーザＦＧＨの保持フラグとして「１」が設定される。
時刻ｔ４は、ユーザＦＧＨの移転基準時刻ｔ３を起点とした放置可能期間の終了時刻であるが、時刻ｔ３から時刻ｔ４までの間にユーザＦＧＨがクエストページに一度もアクセスしていないために、ユーザＦＧＨのアクセスフラグは「０」のままである。そのため、時刻ｔ４において、ユーザＦＧＨの保持フラグが「１」→「０」に変化し、奪取可否フラグが「０」→「１」に変化する。
時刻ｔ５において、ユーザＸＹＺによってリレーアイテムを移転するための所定の入力が行われ、それによって移転先ユーザであるユーザＸＹＺの保持フラグとして「１」が設定され、ユーザＦＧＨの奪取可否フラグが「１」→「０」に変化する。時刻ｔ５にユーザＦＧＨの奪取可否フラグが「０」に変化したため、時刻ｔ５以降、ユーザＸＹＺ以外の他のユーザは、ユーザＦＧＨからリレーアイテムを奪取することはできない。

以上詳述したように、本実施形態のゲーム制御装置によって実現されるゲームでは、１番目のユーザに付与されたリレーアイテム（アイテム情報）が、１番目のユーザから２番目のユーザへ、２番目のユーザから３番目のユーザへ、といった具合に順次移転される。このとき、リレーアイテムの移転のタイミング（移転基準時刻）から放置可能期間中に（第１期間の間に）、移転先のユーザがクエストページにアクセスしない（リレーアイテムに関するゲームを実行しない）場合など、移転先のユーザが、リレーアイテムが移転されてきたことを知らずに放置したままとなっていると考えられる場合には、移転先のユーザの仲間のユーザ（他のユーザ）の入力情報に基づいて、当該ユーザにリレーアイテムが移転される。すなわち、当該ユーザは放置されていたリレーアイテムを自分のものとすることができる。他のユーザが複数いる場合には、早い者勝ちとすることができ、この場合、放置したままになっているリレーアイテムがあれば、複数のユーザが互いに競争してそれを入手しようとすることになる。そのため、アイテム情報の移転が滞ってしまう状況が防止される。
また、上述したように、このゲームでは、移転先のユーザがクエストページにアクセスしない場合にリレーアイテムが他のユーザにさらに移転される（つまり、奪取される）。つまり、自身にリレーアイテムが移転されてきたことを移転先のユーザが知らないうちにそのリレーアイテムがさらに他のユーザ（奪取ユーザ）に移転されることになるため、リレーアイテムが奪取された移転先のユーザは、リレーアイテムが得られなかったことを残念に感じたり、リレーアイテムを奪ったユーザに対して快くない感情を抱くことがない。
なお、移転先ユーザがゲームにアクセスして、移転されたリレーアイテムの存在も認識していたが、後で実行しようと考えていたり、何らかの用事により直ちに実行できなかった場合、その未実行の間に、他のユーザにリレーアイテムが奪われてしまうと、そのユーザには不快感が残ってしまう。そこで、移転先ユーザによってリレーアイテムの存在が認識された場合には、他のユーザによるリレーアイテムの奪取を禁止するようにしてもよい。

上述した実施形態では、第１移転手段５５が、リレーアイテム（アイテム情報）が取得ユーザに付与されてから（最初にユーザに対応付けられてから）所定期間（第２期間）を経過した後に、又はリレーアイテムの移転回数が所定回数に達した後にリレーが終了し、それ以降のリレーアイテムのユーザ間の移転が禁止される場合について説明した。このとき、例えばリレーアイテムのユーザ間の移転が行われる期間が制限されている場合、リレーアイテムが滞留すればするほど、リレーアイテムの移転可能時間が低減することになるので、折角、リレーアイテムを入手する機会がありながら、迅速に行動しないでいると、その機会を失ってしまうことになる。従って、ユーザはリレーアイテムが滞留している事実を知れば、迅速にそれを入手しようと行動することになる。また、リレーアイテムの移転回数について制限がされている場合、例えば移転回数が制限回数に近づく程、そのリレーアイテムを入手する機会が少なくなり、特に制限回数の上限になれば、それがそのリレーアイテムの入手の最後の機会になるので、各ユーザは、より迅速に行動してそれを入手しようとすることになる。このように、このように、上記ゲーム制御装置によれば、アイテム情報の移転が滞ってしまう状況を防止することができる。そのため、このゲーム制御装置は、上記制限がなされているゲームに適用される場合に特に好ましいものとなる。
リレーアイテムの移転は、リレーの期間及び／又はリレーアイテムの移転回数が制限される場合に限られない。例えばリレーの期間が限定されない場合、仲間の間のリレーにおいて、移転先ユーザとなる回数が各ユーザで２回以上であってもよい（つまり、２回以上マスを選択できるようにしてもよい）。

上述した実施形態では、ゲーム制御装置がユーザ間を仲間として関係付ける関係付け手段５１を備え、第１移転手段５５及び第２移転手段５７が関係付けられたユーザ間（つまり、仲間の間）でリレーアイテム（アイテム情報）を移転する場合について説明した。この場合には、仲間と協力してゲームを進行させている実感を得ることができる。また、例えば仲間同士のコミュニケーションの活性化が図れ、ソーシャル性を高めることができる。なお、リレーアイテムの移転は、仲間のユーザ間で行われる場合に限られない。その場合には、ゲームサーバ２０のＣＰＵ２１は、ユーザの通信端末１０からメニューｍ１５（「リレーアイテムを渡す」；図１０参照）の選択操作結果を含むＨＴＴＰリクエストを取得すると、移転先ユーザの選択を促すウェブページ（例えば、図１０のＰ５）を表示するためのＨＴＭＬデータを生成するために、ランダムに所定数のユーザを移転先ユーザの候補として選択する。このとき、移転先ユーザの候補として、処理対象のユーザと同程度の進行レベルの所定数のユーザを選択してもよいし、ＨＴＴＰリクエストを取得した時刻を基準として過去の所定時間以内にクエストページにアクセスを行った所定数のユーザを選択してもよい。後者の場合には、移転先ユーザがクエストを実行中の可能性が高いため、リレーが円滑に促進されやすいという利点がある。

上述した実施形態では、第１移転手段５５によってリレーアイテム（アイテム情報）がユーザに移転されてから放置可能期間（第１期間）が経過した後、当該ユーザの仲間に対して、リレーアイテムが移転可能（つまり、奪取可能）であることを通知する通知手段５６を備える場合について説明した。この場合には、リレーアイテムが移転されたユーザの下でリレーアイテムが滞留していることが他の仲間のユーザに通知されるため、通知されたユーザによる入力によって、その通知されたユーザにリレーアイテムが移転される（奪われる）可能性を高くすることができる。そのため、リレーアイテムの移転が滞ってしまう状況がより効果的に防止される。また、通知されたユーザは、同じ通知が行われている仲間内のなかでも、リレーアイテムを得ようと我先に入力を行うようになるため、リレーアイテムを奪取するときに早い者勝ちの要素が加わることになり、ゲームの興趣性を高めることができる。
リレーアイテムが奪取可能であることを通知することは必須ではない。リレーアイテムが奪取可能であることは、通知等によって仲間のユーザが受動的に知る場合に限られず、ユーザが能動的に知ることができるように構成してもよい。例えば、ユーザが仲間のトップページにアクセス可能である場合には、仲間のトップページに任意のタイミングでアクセスすることによって、その仲間のリレーアイテムが移転可能であることを知ることができるように構成されていてもよい。

上述した実施形態では、リレーアイテム（アイテム情報）が所定数の選択肢を含み、選択手段５４は、リレーアイテムを保持しているユーザの入力情報に基づいて、リレーアイテムに含まれる選択肢の中からいずれかの選択肢を選択し、第１移転手段５５は、選択手段５４により選択肢が選択された場合、当該選択肢をリレーアイテムから除いた状態でリレーアイテムを移転する場合について説明した。この場合には、リレーアイテムが移転される度にユーザの入力によって選択肢が選択されて除かれていく。そのため、ユーザは、リレーアイテムに含まれるすべての選択肢が除かれる前にリレーアイテムを得て、自ら選択肢を選択することが動機付けられる。このような特徴をもったリレーアイテムがユーザの下で滞留しているときには、他のユーザが選択肢を得ようと我先にリレーアイテムを奪取するための入力を行うようになり、リレーアイテムの移転が滞ってしまう状況がさらに効果的に防止される。

また、第１移転手段５５は、選択手段５４により選択された選択肢が所定の条件を満たす場合、それ以降のリレーアイテムのユーザ間の移転を禁止してもよい。
「所定の条件」は、選択肢に設定可能な条件であれば如何なる条件でもよいが、リレーアイテムに含まれる所定数の選択肢のうち「アタリ」に相当する条件であることが好ましい。例えば、リレーアイテムに、カードやアイテムをユーザに付与する選択肢が複数含まれている場合、パラメータの値が所定値より大きいカードやアイテム、あるいは最もレア度（希少価値）が所定レベルより高いカードやアイテムを付与する選択肢である場合に、その選択肢が所定の条件を満たすとしてもよい。
リレーアイテムが順次ユーザ間を移転されている間に、「アタリ」の選択肢等、所定の条件を満たす選択肢が選択された場合には、それ以降のリレーアイテムの移転ができなくなる。そのため、ユーザは早くリレーアイテムを得て「アタリ」の選択肢を選択したいと考えるため、リレーアイテムの移転が滞ってしまう状況がさらに効果的に防止される。
また、リレーアイテムが移転される度に「アタリ」の選択肢を選択する確率が高くなり、移転の度にリレーアイテムの価値が高くなるため、リレーアイテムがユーザの下で滞留しているときには、他のユーザがリレーアイテムの移転のための入力を我先に行うようになり、リレーアイテムの移転が滞ってしまう状況がさらに効果的に防止される。
上述したリレーアイテムのユーザ間の移転の禁止を実現するためには、ゲームサーバ２０のＣＰＵ２１は、ユーザの通信端末１０から、マスの選択結果を含むＨＴＴＰリクエストを取得すると、リレーアイテムデータベース（図８参照）にアクセスして、選択されたマスに対応する選択肢を読み出す。ＣＰＵ２１は、読み出した選択肢が既知の「アタリ」に相当する選択肢である場合には、リレー管理データにアクセスして、対象となるリレーＩＤのリレー管理フラグを「０」（進行中）から「１」（終了済み）に書き換える。これによって、リレーが終了する。

（８）変形例
以下において、上述した実施形態の変形例について説明する。
（８−１）変形例１
先ずリレーアイテムの変形例について説明する。上述した実施形態では、リレーアイテムが所定数の選択肢を含み、リレーアイテムが移転される度にユーザの入力によって選択肢が選択されて除かれていく場合について説明したが、本発明のアイテム情報は、上述した実施形態で述べたリレーアイテムに限られない。
このゲーム制御装置において「アイテム情報」は、ゲームにおいてユーザと対応付けることが可能な情報であれば如何なる情報であってもよい。アイテム情報は、例えば、ゲーム上のオブジェクトや、ゲーム上の道具や効果を示す情報であってもよく、その情報の形式は、画像情報、音声情報、あるいはテキスト情報であってもよい。
例えば、上述した実施形態において、リレーアイテムが選択肢を含まず、移転先ユーザがクエストページにアクセスしたときに、当該ユーザにゲーム上のポイントを付与する、あるいはゲームの進捗を高めるためのパラメータの一定時間の変更等、ゲーム上の特典や有利な効果をユーザに付与するようにしてもよい。

リレーアイテムがユーザに移転されてきたときに当該ユーザに何らかのゲーム上の特典や有利な効果をユーザに付与するのではなく、例えば、リレーアイテムが１番目のユーザに付与されてから一定期間の間にリレーアイテムが移転された回数、あるいは移転されたユーザ数に基づいて、リレーに関与したすべてのユーザに対して所定の特典を付与するように構成してもよい。この場合には、ユーザの下でリレーアイテムが滞留している時間が長いほど、他の仲間のユーザにとって最終的に得られる特典が少なくなるため、他の仲間のユーザは、リレーアイテムを滞留させているユーザから積極的にリレーアイテムを奪取してリレーアイテムを円滑に移転させるように動機付けられる。

（８−２）変形例２
上述した実施形態では、リレーアイテムの移転先ユーザが放置可能期間の間にクエストページにアクセスしない場合に、リレーアイテムを移転先ユーザから奪取することができる構成とした。このような構成とした理由は、上述した実施形態では、移転先ユーザは、クエストページにアクセスしない場合に自身の下にリレーアイテムが移転されてきたことを知り得ないため、そのリレーアイテムを他のユーザが奪取したとしても、リレーアイテムが得られなかったことを残念に感じたり、リレーアイテムを奪ったユーザに対して快くない感情を抱くことがないと考えられるためである。しかし、例えばトップページ上でリレーアイテムが移転されてきたことがメッセージとして表示される場合等のように、移転先ユーザがクエストページ（リレーアイテムに関するゲーム）にアクセスせずともゲームにアクセスすることで自身にリレーアイテムが移転されてきたことを認識可能となっている場合には、他のユーザが奪取するための条件として、リレーアイテムの移転先ユーザが放置可能期間の間にクエストページにアクセスしないことを条件とすることが適切でないこともある。

そこで、上述した実施形態の変形例として、リレーアイテムの移転先ユーザが放置可能期間の間にゲームにアクセスしない場合に、リレーアイテムを移転先ユーザから奪取することができる構成としてもよい。すなわち、変形例に係る第２移転手段５７は、第１移転手段５５によるリレーアイテムの移転から放置可能期間（第１期間）の間、移転先ユーザがゲームにアクセスしない場合、移転先ユーザ以外のユーザの入力情報に基づいて、当該ユーザにリレーアイテムを移転する機能を備えてもよい。
本変形例を実現するためにゲームサーバ２０のＣＰＵ２１は、ユーザからトップページへのアクセス要求（例えば、ゲームのＵＲＬを指定したＨＴＴＰリクエスト）を認識すると、リレー管理データにアクセスして、処理対象となる移転先ユーザのアクセスフラグを「０」（未アクセス）から「１」（アクセス済）に書き換える。

（８−３）変形例３
本変形例に係るゲーム制御装置の機能ブロック図を図２２に示す。図２２の機能ブロック図は、図１４に示したものと比較して、親密度設定手段５８が追加された点が異なる。
親密度設定手段５８は、ユーザ間の関係の程度に応じた親密度を、関係付け手段５１によって関係付けられた仲間のユーザ間に設定する機能を備える。「親密度」とは、関係付けられた仲間のユーザ間の関係性の高さを一定の基準で数値化したものである。
また、本変形例では、第２移転手段５７は、リレーアイテムの移転元ユーザと移転先ユーザの親密度が高いほど、放置可能期間（第１期間）を長くする機能を備える。
本変形例では、移転元ユーザと移転先ユーザの親密度が高い場合には、移転先ユーザの下でリレーアイテムを滞留させた場合でも、知らない内にリレーアイテムが他のユーザにリレーアイテムを奪われることが可能となるタイミングをより長く先延ばしさせることができる。つまり、ユーザ間の親密度が高いほどリレーアイテムを奪われ難くすることができるため、ユーザは仲間との関係を強化するように動機付けられる。

本変形例は、以下のようにして実現することができる。
親密度のデータ（親密度データ）の一例を図２３に示す。図２３に示す親密度データの例では、各ユーザの仲間のユーザ（ユーザＩＤ）と対応付けて、ユーザ間の応援メッセージの送信あるいは受信の頻度（応援頻度）、ゲーム上で使用可能なアイテムなどのプレゼントを送信あるいは受信した回数（プレゼント回数）などが記録され、これらの頻度や回数に基づいて一定の基準で親密度の値が設定される。応援頻度やプレゼント回数が多いほど親密度が高く設定される。また、一定の基準では、親密度の設定の基礎となる項目（図２３では、応援頻度やプレゼント回数など）ごとに、重み付けを考慮したものであってもよい。例えば、応援頻度が少なくてもプレゼント回数が多い場合に親密度を高く設定してもよい。このような親密度データは、例えば、ユーザデータベース３１内に記録される。

本変形例では、ゲームサーバ２０のＣＰＵ２１は、移転元ユーザが仲間のユーザの中からいずれかのユーザを移転先ユーザとして選択したことを認識すると、親密度データにアクセスして、移転元ユーザと移転先ユーザの間で設定されている親密度を読み出し、読み出した親密度に基づいて放置可能期間を決定する。放置可能期間の決定方法は、リレーアイテムの移転元ユーザと移転先ユーザの親密度が高いほど放置可能期間を長くする限り、如何なる方法であってもよい。親密度と放置可能期間の長さとの関係を記述するテーブルを参照して放置可能期間を決定してもよいし、親密度に対して所定の演算式を当てはめることで放置可能期間を算出してもよい。前者の場合、例えば、
・親密度：１の場合、放置可能期間の長さ：１０時間
・親密度：２の場合、放置可能期間の長さ：１１時間
・親密度：３の場合、放置可能期間の長さ：１２時間
といった具合に設定されてもよい。

ＣＰＵ２１は、決定あるいは算出した放置可能期間を、移転先ユーザに対応付けてリレー管理データに記憶しておく。ＣＰＵ２１が移転先ユーザの奪取可否フラグを「０」（奪取不可）から「１」（奪取可能）に書き換えるタイミングは、移転先ユーザの放置可能期間を参照して決定される。

（８−４）変形例４
上述した実施形態では、移転先ユーザのリレーアイテムが奪取可能であることの通知は、移転先ユーザのすべての仲間に対して行われる場合について説明したが、このような場合に限られない。本変形例では、通知対象のユーザは、移転先ユーザとの間の親密度が高い仲間に限定される。すなわち、本変形例に係る通知手段５６は、第１移転手段５５によってリレーアイテムがユーザに移転されてから放置可能期間（第１期間）が経過した後、その移転先ユーザとの親密度が所定値よりも高いユーザに対して、リレーアイテムが移転可能（つまり、奪取可能）であることを通知する機能を備える。
本変形例では、多くの仲間との間で親密度が高いユーザは、リレーアイテムが奪取可能であることの通知をより多く受け取ることができ、リレーアイテムを適時に奪取できる機会が高くなるため、ユーザは仲間との関係を強化するように動機付けられる。

本変形例を実現するためにゲームサーバ２０のＣＰＵ２１は、ユーザからクエストページへのアクセス要求（例えば、メニューｍ１（「クエスト」）やメニューｍ５（「探索する」）等の選択操作に基づくＨＴＴＰリクエスト）を認識すると、リレー管理データにアクセスし、現在実行中（つまり、リレー管理フラグが「０」）のリレーＩＤに対応するリレーの中で、奪取可否フラグが「１」（奪取可能）となっている仲間のユーザが存在するか否か検索する。ＣＰＵ２１は、検索の結果、該当する仲間のユーザが存在する場合には、親密度データにアクセスして、その仲間のユーザと処理対象のユーザの親密度が所定値よりも高いか否かを判断する。ＣＰＵ２１は、その親密度が所定値よりも高い場合に、アクセス要求に対して送信するＨＴＭＬデータに、リレーアイテムを奪取可能な（つまり、リレーアイテムが移転可能な）仲間のユーザが存在することを示すテキストを含ませるようにする。

以上、本発明の実施形態について詳細に説明したが、本発明は上記実施形態に限定されない。また、上記実施形態は、本発明の主旨を逸脱しない範囲において、種々の改良や変更をしてもよいのは勿論である。例えば、上記実施形態及び各変形例に記載された特徴は適宜組み合せて適用してもよい。

上述した実施形態では、本発明の実行対象のゲームがエリアを擬似的に探索するクエストを実行するゲームである場合の例について説明したが、本発明のゲームはこれに限られず、任意のゲームに適用することができる。ユーザ間で順次移転させる対象であるリレーアイテムは、クエスト等の具体的なゲームの内容とは無関係に設定されうるものである。

上述した実施形態では、本発明の「ユーザの入力」の一例として、ユーザの通信端末に対する所定の操作釦の押下操作の入力や、タッチパネル機能を備えた通信端末に対する表示画面上のタッチ操作の入力の場合を採り上げたが、ユーザの入力はこれらの入力方法に限られない。ユーザの入力は、音声入力、加速度センサを備えた通信端末を振ることによる操作入力、あるいはジェスチャによる操作入力（ジェスチャ入力）であってもよい。ジェスチャ入力では、撮像機能を備えた通信端末に対する所定のジェスチャを行うことで通信端末がそのジェスチャを画像認識し、予めジェスチャに対応付けられた操作入力を認識する。

上述した実施形態では、ソーシャルゲームに適用される場合を例として説明したが、これに限られない。例えば、ネットワーク上に置かれたサーバ装置と家庭用オンラインゲーム機とを接続した、いわゆるオンラインゲームシステムにおいても、上述した実施形態と同様に、ユーザ間のアイテム情報の移転を実現できることは言うまでもない。

上述した実施形態では、ネットワーク上のゲームサーバ２０及びデータベースサーバ３０によって、図１４に示した各手段の機能を実現する構成としたが、この構成に限られない。これらのすべての手段を通信端末１０によって実現する構成としてもよいし、少なくとも一部の手段を通信端末１０によって実現する構成としてもよい。通信端末１０とゲームサーバ２０とでは実質的に同一のハードウエア構成を採るため、上記実施形態に記載したようにして通信端末１０によっても各機能を実現できる。図２４（ａ），（ｂ）には、本実施形態のゲーム制御装置の各機能（図１４に示す各機能）について、通信端末１０と、ゲームサーバ２０及びデータベースサーバ３０との間の分担例を示す。

１０…通信端末
１１…ＣＰＵ
１２…ＲＯＭ
１３…ＲＡＭ
１４…画像処理部
１５…指示入力部
１６…表示部
１７…無線通信インタフェース部
１８…バス
２０…ゲームサーバ
２１…ＣＰＵ
２２…ＲＯＭ
２３…ＲＡＭ
２４…データベースアクセス部
２５…通信インタフェース部
２６…バス
３０…データベースサーバ
３１…ユーザデータベース
３２…ゲームデータベース
５１…関係付け手段
５２…ゲーム実行手段
５３…対応付け手段
５４…選択手段
５５…第１移転手段
５６…通知手段
５７…第２移転手段
５８…親密度設定手段

Claims (11)

1. ユーザを識別するユーザ識別情報毎に対応付けられたアイテム情報を記憶する記憶装置にアクセス可能なゲーム制御装置であって、
   第１ユーザの入力情報に基づいて、前記第１ユーザを識別する第１ユーザ識別情報に対応付けられた第１アイテム情報と前記第１ユーザ識別情報との対応付けを解除し、かつ、前記第１ユーザとは異なるユーザである第２ユーザを識別する第２ユーザ識別情報に前記第１アイテム情報を対応付けることで、前記第１ユーザから前記第２ユーザに前記第１アイテム情報を移転する第１移転手段と、
   前記第１移転手段による前記第１アイテム情報の移転から所定の第１期間の間、前記第２ユーザがゲームにアクセスしない場合、又は、前記第２ユーザが前記第１アイテム情報に関するゲームを実行しない場合、前記第２ユーザとは異なるユーザである第３ユーザの入力情報に基づいて、前記第２ユーザ識別情報に対応付けられた第１アイテム情報と前記第２ユーザ識別情報との対応付けを解除し、かつ、前記第３ユーザを識別する第３ユーザ識別情報に前記第１アイテム情報を対応付けることで、前記第２ユーザから前記第３ユーザに前記第１アイテム情報を移転する第２移転手段と、を備え、
   前記第１移転手段は、前記第１アイテム情報が前記第１ユーザ識別情報に対応付けられた後の所定の第２期間を経過した後の前記第１アイテム情報の移転、又は、前記第１アイテム情報の移転回数が所定回数に達した後の前記第１アイテム情報の移転を禁止することを特徴とする、
   ゲーム制御装置。
2. ユーザを識別するユーザ識別情報毎に対応付けられたアイテム情報であって、かつ、所定数の選択肢を含むアイテム情報を記憶する記憶装置にアクセス可能なゲーム制御装置であって、
   第１ユーザの入力情報に基づいて、前記第１ユーザを識別する第１ユーザ識別情報に対応付けられた第１アイテム情報と前記第１ユーザ識別情報との対応付けを解除し、かつ、前記第１ユーザとは異なるユーザである第２ユーザを識別する第２ユーザ識別情報に前記第１アイテム情報を対応付けることで、前記第１ユーザから前記第２ユーザに前記第１アイテム情報を移転する第１移転手段と、
   前記第１移転手段による前記第１アイテム情報の移転から所定の第１期間の間、前記第２ユーザがゲームにアクセスしない場合、又は、前記第２ユーザが前記第１アイテム情報に関するゲームを実行しない場合、前記第２ユーザとは異なるユーザである第３ユーザの入力情報に基づいて、前記第２ユーザ識別情報に対応付けられた第１アイテム情報と前記第２ユーザ識別情報との対応付けを解除し、かつ、前記第３ユーザを識別する第３ユーザ識別情報に前記第１アイテム情報を対応付けることで、前記第２ユーザから前記第３ユーザに前記第１アイテム情報を移転する第２移転手段と、
   前記第１アイテム情報が対応付けられているユーザ識別情報によって識別されるユーザの入力情報に基づいて、前記第１アイテム情報に含まれる選択肢の中からいずれかの選択肢を選択する選択手段と、を備え、
   前記第１移転手段は、前記選択手段により選択された選択肢を前記第１アイテム情報から除いて、前記第１アイテム情報を移転することを特徴とする、
   ゲーム制御装置。
3. 前記第１移転手段は、前記選択手段により選択された選択肢が所定の条件を満たす場合、前記選択肢が選択された以降の前記第１アイテム情報のユーザ間の移転を禁止することを特徴とする、
   請求項２に記載されたゲーム制御装置。
4. ユーザ識別情報間を関係付ける関係付け手段、を備え、
   前記第１移転手段及び前記第２移転手段は、前記関係付け手段によって関係付けられたユーザ識別情報によって識別されるユーザ間で前記第１アイテム情報を移転することを特徴とする、
   請求項１〜３のいずれかに記載されたゲーム制御装置。
5. 前記第１移転手段によって前記第１アイテム情報が前記第２ユーザに移転されてから前記第１期間が経過した後、前記第２ユーザ識別情報と関係付けられたユーザ識別情報によって識別されるユーザに対して、前記第１アイテム情報が移転可能であることを通知する通知手段、を備えたことを特徴とする、
   請求項４に記載されたゲーム制御装置。
6. ユーザ間の関係の程度に応じた親密度を、前記関係付け手段によって関係付けられたユーザ識別情報間に設定する親密度設定手段、を備え、
   前記第２移転手段は、前記第２ユーザと前記第３ユーザの親密度が高いほど、前記第１期間を長くすることを特徴とする、
   請求項４または５に記載されたゲーム制御装置。
7. ユーザ間の関係の程度に応じた親密度を、前記関係付け手段によって関係付けられたユーザ識別情報間に設定する親密度設定手段、を備え、
   前記通知手段は、前記第１移転手段によって前記第１アイテム情報が前記第２ユーザに移転されてから前記第１期間が経過した後、前記第２ユーザとの親密度が所定値よりも高いユーザに対して、前記第１アイテム情報が移転可能であることを通知することを特徴とする、
   請求項５に記載されたゲーム制御装置。
8. ユーザを識別するユーザ識別情報毎に対応付けられたアイテム情報を記憶する記憶装置にアクセス可能なゲーム制御装置であって、
   ユーザ識別情報間を関係付ける関係付け手段と、
   第１ユーザの入力情報に基づいて、前記第１ユーザを識別する第１ユーザ識別情報に対応付けられた第１アイテム情報と前記第１ユーザ識別情報との対応付けを解除し、かつ、前記第１ユーザ識別情報に関係付けられた第２ユーザ識別情報に前記第１アイテム情報を対応付けることで、前記第１ユーザから、前記第２ユーザ識別情報によって識別される第２ユーザに前記第１アイテム情報を移転する第１移転手段と、
   前記第１移転手段による前記第１アイテム情報の移転から所定の第１期間の間、前記第２ユーザがゲームにアクセスしない場合、又は、前記第２ユーザが前記第１アイテム情報に関するゲームを実行しない場合、前記第２ユーザ識別情報に関係付けられた第３ユーザ識別情報によって識別される第３ユーザの入力情報に基づいて、前記第２ユーザ識別情報に対応付けられた第１アイテム情報と前記第２ユーザ識別情報との対応付けを解除し、かつ、前記第３ユーザ識別情報に前記第１アイテム情報を対応付けることで、前記第２ユーザから前記第３ユーザに前記第１アイテム情報を移転する第２移転手段と、
   前記第１移転手段によって前記第１アイテム情報が前記第２ユーザに移転されてから前記第１期間が経過した後、前記第２ユーザ識別情報と関係付けられたユーザ識別情報によって識別されるユーザに対して、前記第１アイテム情報が移転可能であることを通知する通知手段と、を備えたことを特徴とする、
   ゲーム制御装置。
9. ユーザを識別するユーザ識別情報毎に対応付けられたアイテム情報を記憶する記憶装置にアクセス可能なゲーム制御装置であって、
   第１ユーザの入力情報に基づいて、前記第１ユーザを識別する第１ユーザ識別情報に対応付けられた第１アイテム情報と前記第１ユーザ識別情報との対応付けを解除し、かつ、前記第１ユーザとは異なるユーザである第２ユーザを識別する第２ユーザ識別情報に前記第１アイテム情報を対応付けることで、前記第１ユーザから前記第２ユーザに前記第１アイテム情報を移転する第１移転手段と、
   前記第１移転手段による前記第１アイテム情報の移転から所定の第１期間の間、前記第２ユーザがゲームにアクセスしない場合、又は、前記第２ユーザが前記第１アイテム情報に関するゲームを実行しない場合、前記第２ユーザとは異なるユーザである第３ユーザの入力情報に基づいて、前記第２ユーザ識別情報に対応付けられた第１アイテム情報と前記第２ユーザ識別情報との対応付けを解除し、かつ、前記第３ユーザを識別する第３ユーザ識別情報に前記第１アイテム情報を対応付けることで、前記第２ユーザから前記第３ユーザに前記第１アイテム情報を移転する第２移転手段と、
   ユーザ識別情報間を関係付ける関係付け手段と、
   ユーザ間の関係の程度に応じた親密度を、前記関係付け手段によって関係付けられたユーザ識別情報間に設定する親密度設定手段と、を備え、
   前記第１移転手段及び前記第２移転手段は、前記関係付け手段によって関係付けられたユーザ識別情報によって識別されるユーザ間で前記第１アイテム情報を移転し、
   前記第２移転手段は、前記第２ユーザと前記第３ユーザの親密度が高いほど、前記第１期間を長くすることを特徴とする、
   ゲーム制御装置。
10. コンピュータを、請求項１〜９に記載されたゲーム制御装置の各手段として機能させるためのプログラム。
11. 通信端末と、前記通信端末からアクセスされるサーバと、ユーザに対応付けられたアイテム情報を記憶する記憶装置と、を含むゲームシステムであって、
    請求項１〜９に記載されたゲーム制御装置の各手段を、前記通信端末又は前記サーバのいずれか一方が備えた、
    ゲームシステム。
    
    

Images