JP2020150988A - 予約管理サーバおよび予約管理プログラム - Google Patents

Abstract

【課題】ゲーム装置の予約プレイに関連する代金の受け取りを、より確実にする。【解決手段】ゲームサーバ１０２は、ユーザ端末１０４およびゲーム装置１１０とインターネット１０６を介して接続され、ユーザ端末１０４を使用するユーザを認証し（Ｓ１２）、ユーザ端末１０４から、予約対象のゲーム装置１１０と予約期間を特定する予約要求を受け付け（Ｓ１８）、予約対象のゲーム装置１１０と予約期間に、ユーザを予約者として対応づけて設定し（Ｓ２０）、予約者の電子決済手段から、予約プレイに関連する代金を受け取る。【選択図】図４

Description

本発明は、ゲーム装置におけるプレイの予約に関する。

ワンプレイごとに料金を徴収するアーケードゲーム装置（業務用ゲーム装置）は、４０年以上の歴史を誇る。アーケードゲーム市場は、近年は縮小傾向にあるともいわれるが、２０１４年で約４０００億円もの規模を有する。

人気のあるアーケードゲームは、順番待ちになることがある。特に人気の高いゲームタイトルの場合には、ゲームセンターの店員が整理券を配ることでプレイ順位を管理することも多い。しかし、このようなやり方はゲームセンターの運営会社にとって非常に負担が大きい。

特許文献１は、ユーザから遊戯施設内各設備の利用予約を受け付けて利用計画を立てるシステムを開示する。このシステムによれば、予め人気のあるゲーム装置やアトラクションについて、ユーザの携帯端末を用いて利用時間を予約することで、人気のあるゲーム装置などであっても、並ばずにプレイすることができる。

特開２００３−１０８６９９号公報

しかし、特許文献１のシステムでは、無断キャンセルされた場合に、予約されたゲーム装置などが無稼働となり、店舗運営者の収益機会を逸失することを防げない。他にも、予約者がキャンセルを申し出た場合の対応なども面倒であり、ときに正当な代金を受け取り損ねることもある。

本発明は、上記課題認識に基づいて完成された発明であり、その主たる目的は、ゲーム装置の予約プレイに関連する代金の受け取りを、より確実にする予約管理システムを提案することにある。

本発明のある態様における情報処理装置は、通信端末およびゲーム装置と通信ネットワークを介して接続され、通信端末を使用するユーザを認証する認証部と、通信端末から、予約対象のゲーム装置と予約期間を特定する予約要求を受け付ける受付部と、予約対象のゲーム装置と予約期間に、ユーザを予約者として対応づけて記憶する記憶部と、予約者の電子決済手段から、予約プレイに関連する代金を受け取る決済部と、を備える。

本発明によれば、ゲーム装置の予約プレイに関連する代金の受け取りを、より確実にできる。

予約管理システムのハードウェア構成図である。 ユーザ端末の機能ブロック図である。 ゲームサーバの機能ブロック図である。 ゲーム装置を予約するときの処理過程を示すフローチャートである。 予約画面の画面図である。 予約情報格納部のデータ構造図である。 課金情報格納部のデータ構造図である。 ゲーム装置の予約をキャンセルするときの処理過程を示すフローチャートである。 ゲーム装置の機能ブロック図である。 予約期間が始まるときの処理過程を示すフローチャートである。 予約期間中の処理過程を示すフローチャートである。 予約期間が終わるときの処理過程を示すフローチャートである。 無断キャンセルされた場合の処理過程を示すフローチャートである。 予約者の地位を他のユーザに譲る場合の処理過程を示すフローチャートである。 仮予約したゲーム装置を同伴者に使用させるときの処理過程を示すフローチャートである。

あるゲームタイトルのゲーム装置でプレイしたいユーザは、そのゲームタイトルのゲーム装置を備える店舗を調べてからそこに訪れる。しかし、そのゲームタイトルのゲーム装置が他のプレイヤに占有されている場合には、結局プレイをあきらめざるを得ないこともある。ユーザに、このような残念な思いをさせることは、店舗の運営者にとって本意ではない。

本実施形態のゲームサーバでゲーム装置の予約を管理するシステムでは、店舗におけるゲーム装置の予約状況を公開する。ユーザは、自らのユーザ端末で予約状況を確認して、所望店舗で好みのゲーム装置が空いている時間帯を指定して予約できる。ユーザが予約できれば、その期間においてゲーム装置を独占できる。

ユーザは、電子決済手段（たとえば、クレジットカードや預金口座からの引き落とし）を利用しており、後述する課金方法（料金体系）や料金の電子決済などについて定めた契約に同意しているものとする。契約の内容は、たとえばゲームサーバ１０２に設けられるＷＥＢサイトで開示される。ゲーム装置のプレイに関する課金状況は、ゲームサーバで管理される。

また、ユーザは、ユーザＩＤが記録された既知のゲームカードを保持しているものとする。ゲームカードを利用すれば、ユーザのプレイデータをゲームサーバに保持させ、プレイの都度これをゲーム装置にダウンロードして前回と同じ状況を再現できる。さらに、ゲームカードと併せて電子決済手段を使用すれば、硬貨を投入しなくても、ゲームカードをゲーム装置の読み取り部にかざすだけでプレイできる。つまり、ゲームサーバにおいてゲーム装置で読み取ったユーザＩＤと紐付けられている電子決済手段を特定できるので、クレジットカードの番号入力のような操作をしなくてもよい。

予約されている期間中、ユーザは繰り返しプレイを楽しむことができる。予約期間が過ぎると、予約のときに課金された予約代とプレイ代が、電子決済される。

ユーザが店舗へ行けなくなったときには、事前に予約をキャンセルできる。ユーザ端末からゲームサーバにアクセスして解約を要求する。この場合には、解約代（キャンセル料）が課金される。事前キャンセルした場合には、その時点で電子決済される。

もしも、事前キャンセルをせずに店舗へ行かなかった場合には、いわゆる無断キャンセル、つまり違約（予約の不履行）と判断され、違約料が課金される。無断キャンセルと判断された場合には、その時点で電子決済される。

ゲーム装置の外側にはランプ（たとえば、ＬＥＤ（Light Emitting Diode）ランプ）が備えられており、ランプを点灯させることによって予約による独占状態であることを、周りのプレイヤに知らせるようにする。また、予約による独占が始まる前には、ランプを点滅させることによって間もなく独占されることを予告する。さらに、独占が終わる前にも、ランプを点滅させることによって間もなく独占状態が終わることを予告する。これによって、周りのプレイヤに加えて、予約者本人にも独占の開始と終了を意識させることができ、予約プレイの運用が円滑になる。

図１は、予約管理システム１００のハードウェア構成図である。
予約管理システム１００においては、ゲームサーバ１０２に対して、複数の店舗１０８ａ、１０８ｂ・・・１０８ｎ（以下、まとめて言うときや特に区別しないときには「店舗１０８」と総称する）と、複数のユーザ端末１０４ａ、１０４ｂ・・・１０４ｎ（以下、まとめて言うときや特に区別しないときには「ユーザ端末１０４」と総称する）がインターネット１０６を介して接続される。また、ゲームサーバ１０２は決済装置１１４とも接続される。決済装置１１４は、クレジットカード会社または銀行が運営するサーバである。

本実施形態におけるユーザ端末１０４は、スマートフォンを想定している。ユーザ端末１０４は、タブレット端末やラップトップＰＣであってもよい。ユーザ端末１０４とインターネット１０６は無線接続されるが、有線接続されてもよい。

店舗１０８は、遊園地やゲームセンターなどが想定される。店舗１０８においては、複数のゲーム装置１１０ａ〜１１０ｆ（以下、まとめて言うときや特に区別しないときには「ゲーム装置１１０」と総称する）と中継装置１１２がＬＡＮ（Local Area Network）などにより接続される。ゲーム装置１１０は「サテライト」とよばれる業務用ゲーム装置、いわゆる、アーケードゲーム装置である。ゲーム装置１１０は、ＮＦＣ規格（Near Field Communication）などの既知の近距離通信技術による読み取り部を備えている。中継装置１１２は「ターミナル」とよばれ、１以上のゲーム装置１１０のゲームプレイの支援・補助を行うための装置である。中継装置１１２とインターネット１０６は有線接続されるが、無線接続されてもよい。

中継装置１１２は、ゲーム装置１１０におけるゲームプレイ結果をリプレイ（動画再生）する、複数のゲームプレイの結果からランキングを作成する、ゲームにおいて使用可能なカード（アイテム）を提供する、などの既知の支援機能を有する。一般的には、中継装置１１２は、ゲームの演出や分析などゲーム装置１１０におけるゲームプレイの興趣をいっそう高めるための処理として支援処理を実行する。

ユーザには、ユーザＩＤが割り当てられる。ユーザＩＤはゲームカードおよびユーザ端末１０４に記録されている。ユーザＩＤは、必ずしもユーザが視認可能である必要はなく、ゲームカードおよびユーザ端末１０４に登録される秘密コードであってもよい。なお、ゲームカードにカードＩＤを付与し、ゲームサーバ１０２においてカードＩＤとユーザＩＤを対応づけてもよい。この場合には、カードＩＤが実質的にユーザＩＤとして機能する。

図２は、ユーザ端末１０４の機能ブロック図である。
予約管理システム１００に含まれるユーザ端末１０４、ゲームサーバ１０２およびゲーム装置１１０の各構成要素は、ＣＰＵ（Central Processing Unit）および各種コプロセッサなどの演算器、メモリやストレージといった記憶装置、それらを連結する有線または無線の通信線を含むハードウェアと、記憶装置に格納され、演算器に処理命令を供給するソフトウェアによって実現される。コンピュータプログラムは、デバイスドライバ、オペレーティングシステム、それらの上位層に位置する各種アプリケーションプログラム、また、これらのプログラムに共通機能を提供するライブラリによって構成されてもよい。以下に説明する各ブロックは、ハードウェア単位の構成ではなく、機能単位のブロックを示している。

ユーザ端末１０４は、ユーザインターフェース処理部２０２、データ処理部２０６、通信部２０４およびデータ格納部２０８を含む。
ユーザインターフェース処理部２０２は、タッチパネルなどの入力デバイスを介してユーザからの操作を受け付けるほか、画像表示や音声出力など、ユーザインターフェースに関する処理を担当する。通信部２０４は、インターネット１０６を介してゲームサーバ１０２および中継サーバ１１２との通信処理を担当する。データ格納部２０８は各種データを格納する。データ処理部２０６は、通信部２０４により取得されたデータ、ユーザインターフェース処理部２０２を介して入力された操作指示およびデータ格納部２０８に格納されているデータに基づいて各種処理を実行する。データ処理部２０６は、通信部２０４、ユーザインターフェース処理部２０２およびデータ格納部２０８のインタフェースとしても機能する。データ格納部２０８は、スマホアプリなどの各種情報を格納する。

ユーザインターフェース処理部２０２は、ユーザからの入力を受け付ける入力部２１０と、ユーザに対して画像や音声などの各種情報を出力する出力部２２０を含む。
出力部２２０は、予約画面表示部２２２を含む。予約画面表示部２２２は、予約画面をディスプレイに表示させる。

通信部２０４は、データを送信する送信部２３０とデータを受信する受信部２５０を含む。
送信部２３０は、ＩＤ送信部２３２、予約要求送信部２３４、解約要求送信部２３６、変更要求送信部２３８および応答送信部２４０を含む。
ＩＤ送信部２３２は、ユーザ端末１０４に記憶されているユーザＩＤをゲームサーバ１０２へ送信する。予約要求送信部２３４は、予約要求をゲームサーバ１０２へ送信する。解約要求送信部２３６は、解約要求をゲームサーバ１０２へ送信する。変更要求送信部２３８は、予約者の変更要求をゲームサーバ１０２へ送信する。予約者の変更については、後述する。応答送信部２４０は、予約者の地位の譲り受けの確認に対する応答をゲームサーバ１０２へ送信する。予約者の地位の譲り受けについては、後述する。

受信部２５０は、予約画面受信部２５２および報知受信部２５４を含む。
予約画面受信部２５２は、ゲームサーバ１０２から予約画面のデータを受信する。報知受信部２５４は、ゲームサーバ１０２から予約者の地位の譲り受けの確認に関する報知メールを受信する。

ユーザ端末１０４の機能モジュールは、たとえばゲームサーバ１０２からダウンロードされたスマホアプリを実行することによって実現される。あるいは、ゲームサーバ１０２に設けられるＷＥＢサイトから提供されるデータ（プログラムを含む。）とブラウザによって実現されてもよい。

図３は、ゲームサーバ１０２の機能ブロック図である。
ゲームサーバ１０２は、通信部３０２、データ処理部３０４およびデータ格納部３０６を含む。
通信部３０２は、インターネット１０６または専用回線を介してユーザ端末１０４、ゲーム装置１１０および決済装置１１４との通信処理を担当する。データ格納部３０６は各種データを格納する。データ処理部３０４は、通信部３０２により取得されたデータ、データ格納部３０６に格納されているデータに基づいて各種処理を実行する。データ処理部３０４は、通信部３０２およびデータ格納部３０６のインタフェースとしても機能する。

通信部３０２は、データを送信する送信部３１０と、データを受信する受信部３３０を含む。
送信部３１０は、予約画面送信部３１２、通知送信部３１４、プレイデータ送信部３１６および報知部３１８を含む。
予約画面送信部３１２は、予約画面のデータをユーザ端末１０４へ送信する。通知送信部３１４は、各種の通知をゲーム装置１１０へ送信する。プレイデータ送信部３１６は、プレイデータをゲーム装置１１０へ送信する。報知部３１８は、報知メールをユーザ端末１０４へ送信する。

受信部３３０は、ＩＤ受信部３３２、予約要求受信部３３４、解約要求受信部３３６、確認要求受信部３３８、プレイデータ受信部３４０、変更要求受信部３４２および応答受信部３４４を含む。
ＩＤ受信部３３２は、ユーザ端末１０４から送られるユーザＩＤを受信する。予約要求受信部３３４は、ユーザ端末１０４から送られる予約要求を受信する。解約要求受信部３３６は、ユーザ端末１０４から送られる解約要求を受信する。確認要求受信部３３８は、ゲーム装置１１０から送られる予約の確認要求を受信する。プレイデータ受信部３４０は、ゲーム装置１１０から送られるプレイデータを受信する。変更要求受信部３４２は、ユーザ端末１０４またはゲーム装置１１０から送られる予約者の変更要求を受信する。応答受信部３４４は、ユーザ端末１０４から送られる予約者の地位の譲り受けの確認に関する応答を受信する。

データ処理部３０４は、ユーザ認証部３５０、予約管理部３５２、課金処理部３５４、電子決済部３５６、プレイデータ更新部３５８、違約判定部３６０およびチェックイン判定部３６２を含む。
ユーザ認証部３５０は、ユーザの認証を行なう。予約管理部３５２は、予約情報を管理する。予約情報については、図６に関連して後述する。課金処理部３５４は、課金情報を管理する。課金情報については、図７に関連して後述する。電子決済部３５６は、決済装置１１４との通信による電子決済（自動引き落とし）を行なう。プレイデータ更新部３５８は、プレイデータ格納部３７２のデータを更新する。違約判定部３６０は、違約（いわゆる無断キャンセル）を判定する。チェックイン判定部３６２は、店舗１０８へのチェックインを判定する。

データ格納部３０６は、アカウント情報格納部３７０、プレイデータ格納部３７２、予約情報格納部３７４、電子決済情報格納部３７６、店舗情報格納部３７８および課金情報格納部３８０を含む。
アカウント情報格納部３７０は、アカウント情報を格納する。アカウント情報は、ユーザＩＤの他、ユーザ名、アカウント名やパスワードなどを含む。プレイデータ格納部３７２は、ユーザＩＤとプレイデータを対応づけて保存する。プレイデータは、ユーザごとに設けられ、各種ゲームに関するゲームデータと履歴データを含む。ゲームデータは、そのゲームに関してプレイヤが設定した内容（プレイヤ名や使用するキャラクタなど）の他、プレイによって獲得したアイテム、経験値や能力値などを含む進捗状態を示すセーブデータである。

予約情報格納部３７４は、予約情報を格納する。電子決済情報格納部３７６は、ユーザ毎の電子決済情報を格納する。電子決済情報は、自動引き落とし元を識別する情報である。ポストペイ方式による支払機能としてクレジットカードを利用する場合には、ユーザＩＤに紐付けてクレジットカード番号とパスワードを格納する。預金口座から引き落とす場合には、銀行名、店名と預金口座番号を格納する。店舗情報格納部３７８は、店舗情報を格納する。店舗情報は、店舗１０８毎に保有するゲーム装置１１０の情報を含む。課金情報格納部３８０は、課金情報を格納する。

図４は、ゲーム装置１１０を予約するときの処理過程を示すフローチャートである。
ユーザがユーザ端末１０４のスマホアプリを起動させると、ＩＤ送信部２３２がユーザ端末１０４に記憶されているユーザＩＤをゲームサーバ１０２へ送信する（Ｓ１０）。

ゲームサーバ１０２のユーザ認証部３５０は、受信したユーザＩＤに基づいてユーザ認証を行なう（Ｓ１２）。ユーザ認証が成功すると、予約画面送信部３１２は、予約画面のデータをユーザ端末１０４へ送信する（Ｓ１４）。ユーザ端末１０４の予約画面表示部２２２は、このデータを用いて、予約画面をディスプレイに表示させる（Ｓ１６）。

図５は、予約画面の画面図である。
予約画面には、プルダウンリストで選択された店舗１０８および日付で特定される予約スケジュールが表示される。１５分間の各時間帯における各ゲーム装置１１０の予約状況が示される。予約状況には、時間帯とゲーム装置１１０の組に対応する時間枠が展開される。この時間枠が、最小の予約単位となる。

ユーザは、１または２以上の連続する時間枠について、いずれかのゲーム装置１１０を予約できる。新たに予約を入れられるのは、予約された時間枠（以下、「予約枠」という）およびユーザの交代のための時間枠（以下、「交代枠」という。）以外の空いている時間枠（以下、「空き枠」という。）である。ユーザが空き枠を選択して、予約申込ボタンにタッチすれば、予約枠に切り替わって予約したユーザの名前が表示される。予約をキャンセルする場合には、自らの予約枠を選択して予約申込ボタンにタッチする。この操作によって、予約枠は空き枠に切り替わる。

この例では、Ｘ１号機が１９：００から１９：３０までユーザ「toshi」によって予約され、１９：４５から２０：１５までユーザ「ken」によって予約されている。この場合、ユーザ「toshi」からユーザ「ken」へプレイヤが交代するための交代枠が設けられる。このように、前後に予約枠がある交代枠には、誰も予約を入れられない。

また、Ｙ１号機には１９：１５から１９：４５までユーザ「hana」の予約が入っており、Ｙ２号機には１９：３０から２０：００までユーザ「saki」の予約が入っている。そして、これらの予約枠の前後にも、交代枠が設けられる。未だ交代が必要な状況にはなっていないが、たとえばＹ１号機の２０：００から２０：１５までの時間帯やＹ２号機の１９：００から１９：１５までの時間枠に他のユーザの予約が入れられる場合に備え、予め交代枠を確保しておく。尚、Ｙ１号機の１９：４５から２０：００の交代枠に対してユーザ「hana」だけは予約を入れることができる。その場合、２０：００から２０：１５の時間帯へ交代枠がずれる。Ｙ１号機の１９：４５から２０：００の交代枠に対する「hana」の予約と、２０：００から２０：１５の空き枠に対する他のユーザの予約が重なった場合は、先に予約を（予約枠を確保）している「hana」の予約を優先してもよいし、様々なユーザにプレイしてもらうという観点では他のユーザによる予約を優先してもよい。また、過去にキャンセル（事前キャンセルや無断キャンセル）したことがあるか否か（キャンセルした回数を含む）を判断し、優先するユーザを決定してもよい。Ｙ２号機の１９：１５から１９：３０までの交代枠についても、同様にユーザ「saki」のみが予約を入れることができる。

図６は、予約情報格納部３７４のデータ構造図である。
予約情報は、各店舗１０８における予約スケジュールを含んでいる。この例は、図５の予約画面に示した店舗１０８「××駅前店」（店舗ＩＤ：Ｓ０１）の１月１０日における予約スケジュールの一部を示している。

予約スケジュールは、日付と時間帯からなる予約期間に区分けされる。各予約期間には、その店舗１０８で予約可能なゲーム装置１１０のエントリが設けられる。ゲーム装置１１０のエントリは、ゲームタイトルごとにまとめられ、それぞれ予約者と入店状況が設定される。予約者のフィールドには、予約のタイミングでユーザＩＤが設定される。入店状況の初期値は、「未確認」であり、予約期間に近づいた段階で予約者が入店していると確認されれば、「確認済み」と改められる。その店舗１０８にあるいずれかのゲーム装置１１０で、予約者のゲームカードを読み取った段階で入店を確認できる。

この例は、１月１０日の１８：５０頃の状態を示しており、１９：００から１９：３０までＸ１号機を予約しているユーザ「toshi」（ユーザＩＤ：Ｕ０１）が既に入店し、１９：００から１９：４５までＹ１号機を予約しているユーザ「hana」（ユーザＩＤ：Ｕ０２）が未だ入店していないことを示している。

図４の説明に戻る。ユーザ端末１０４の入力部２１０は、ユーザ操作によって予約条件を受け付ける。予約条件は、店舗ＩＤ、日付、時間帯およびゲーム装置ＩＤを含む。予約要求送信部２３４は、予約条件を含む予約要求をゲームサーバ１０２へ送信する（Ｓ１８）。

ゲームサーバ１０２の予約管理部３５２は、受信した予約要求に従って予約の設定を行なう（Ｓ２０）。予約情報で、店舗ＩＤ、日付、時間帯およびゲーム装置ＩＤの組み合わせに対応する予約者のフィールドに、ユーザ認証されたユーザＩＤが設定される。

課金処理部３５４は、予約代の課金を行なう（Ｓ２２）。予約代は、予約管理システムの利用料およびゲーム装置１１０の独占サービス料に相当する。たとえば予約管理システムの利用料が１００円であり、独占サービス料が２００円であれば、予約代は３００円になる。具体的には、ユーザＩＤに対応する課金情報に予約代のエントリを設けて、日付と、項目の種別（予約代）と、予約代の金額を設定する。利用料は予約管理システムを利用することに対する対価であり、独占サービス料はゲーム装置１１０を一時的に占有する利便を得られることに対する対価である。なお、予約代の内訳としては、上記のほか、ゲームのプレイ料金（クレジット）が含まれる金額を予約代として徴収するようにし、予約した時間にゲームプレイをした場合は、この予約代をプレイ料金に充当するようにしてもよい。このようにすることで、プレイヤに対して予約プレイに関連する代金の負担を軽減させることができる。更に、各ゲームコンテンツの所定期間におけるインカムの集計結果等に応じて、どのように予約代を徴収するか、またはどのような金額を設定するか決定するようにしてもよい。

図７は、課金情報格納部３８０のデータ構造図である。
１回の予約に関連する課金をまとめて管理する。そのため、予約を受け付ける都度、課金テーブルが設けられる。課金テーブルには、予約の段階で予約者を特定するユーザＩＤと予約代のエントリが設定される。予約プレイが行なわれると、プレイ代のエントリが追加される。予約期間を終えると、合計額が算出され、まとめて電子決済される。

予約者が事前にキャンセルした場合には、予約代のエントリに解約代のエントリが追加され、合計額がまとめて電子決済される。また、予約者が無断キャンセルした場合には、予約代のエントリに違約金のエントリが追加され、合計額がまとめて電子決済される。これらの場合における課金額については、後述する。

図８は、ゲーム装置１１０の予約をキャンセルするときの処理過程を示すフローチャートである。
Ｓ３０からＳ３６までの処理は、図４に示したＳ１０からＳ１６の場合と同様である。ユーザは予約画面でキャンセルさせたい予約枠を選択して、キャンセルを指示する操作を行なう。このユーザ操作によって、ユーザ端末１０４の入力部２１０は予約の解約を受け付ける。当然ながら、ユーザ本人が行なった予約以外は解約できない。解約要求送信部２３６は、キャンセル対象の予約を特定した解約要求をゲームサーバ１０２へ送信する（Ｓ３８）。キャンセル対象は、店舗ＩＤ、日付、時間帯およびゲーム装置ＩＤで特定され、あるいは予約ごとに割り振られる予約ＩＤで特定される。

ゲームサーバ１０２の予約管理部３５２は、受信した解約要求にしたがって予約を解消させる（Ｓ４０）。具体的には、予約者のフィールドに設定されているユーザＩＤが消去される。

課金処理部３５４は、予約の解約による清算を行なう（Ｓ４２）。予約が解約された場合には、予約代のうち予約管理システムの利用料を残して、独占サービス料の全部または一部を減らす。取り消された予約期間については、独占サービスを行なわないからである。たとえば、予約代が３００円であって、利用料が１００円、独占サービス料が２００円であれば、予約代を１００円（利用料のみ）に減額する。そして、ユーザＩＤに対応する課金情報に、解約代のエントリを設けて、日付と、項目の種別（解約代）と、解約代の金額を設定する。解約代は、解約に伴う補償に相当する。解約代は、解約の手続きを行なったタイミングによって異なる。たとえば前日までに解約した場合の解約代を３００円とし、当日に解約した場合の解約代を６００円とする。

電子決済部３５６は、減額された予約代と解約代の合計金額を求めて、電子決済を行なう（Ｓ４４）。前日までに解約すれば、課金額の合計は１００円＋３００円＝４００円である。当日に解約した場合、課金額の合計は１００円＋６００円＝７００円である。

図９は、ゲーム装置１１０の機能ブロック図である。
ゲーム装置１１０は、ユーザインターフェース処理部４０２、データ処理部４０６、通信部４０４およびデータ格納部４０８を含む。
ユーザインターフェース処理部４０２は、ジョイスティック（操縦桿）およびボタンを介してプレイヤからの操作を受け付けるほか、画像表示や音声出力など、ユーザインターフェースに関する処理を担当する。通信部４０４は、インターネット１０６を介してゲームサーバ１０２などとの通信処理を担当する。データ格納部４０８は各種データを格納する。データ処理部４０６は、ユーザインターフェース処理部４０２や通信部４０４により取得されたデータ、データ格納部４０８に格納されているデータに基づいて各種処理を実行する。データ処理部４０６は、ユーザインターフェース処理部４０２、通信部４０４およびデータ格納部４０８のインタフェースとしても機能する。

ユーザインターフェース処理部４０２は、プレイヤからの入力を受け付ける入力部４１０と、プレイヤに対して画像や音声などの各種情報を出力する出力部４２０を含む。
入力部４１０は、ＩＤ検出部４１２およびプレイ受付部４１４を含む。ＩＤ検出部４１２は、ゲーム装置１１０のカード読み取り装置にかざされたゲームカードからユーザＩＤを検出する。プレイ受付部４１４は、開始ボタンのタッチや硬貨投入によるプレイ要求を受け付ける。

通信部４０４は、データを送信する送信部４３０とデータを受信する受信部４４０を含む。
送信部４３０は、確認要求送信部４３２、プレイデータ送信部４３４および変更要求送信部４３６を含む。
確認要求送信部４３２は、予約の確認要求をゲームサーバ１０２へ送信する。プレイデータ送信部４３４は、今回のプレイによって更新されたプレイデータをアップロードする。変更要求送信部４３６は、予約者の変更要求をゲームサーバ１０２へ送信する。

受信部４４０は、通知受信部４４２およびプレイデータ受信部４４４を含む。
通知受信部４４２は、ゲームサーバ１０２から送られる各種の通知を受信する。プレイデータ受信部４４４は、ゲームサーバ１０２のプレイデータ送信部３１６へアクセスし、ユーザＩＤに対応づけられるプレイデータをゲームサーバ１０２からダウンロードする。

データ処理部４０６は、ランプ制御部４５０およびゲーム実行部４５２を含む。ランプ制御部４５０は、ランプを制御する。ゲーム実行部４５２は、ゲームプログラムを実行する。

図１０は、予約期間が始まるときの処理過程を示すフローチャートである。
ゲームサーバ１０２の通知送信部３１４は、予約期間開始の第１所定時間（たとえば、１０分）前になると、予約期間の開始予告の通知を予約対象のゲーム装置１１０へ送信する（Ｓ５０）。

ゲーム装置１１０の通知受信部４４２が予約期間の開始予告の通知を受信すると、ランプ制御部４５０は、予約期間の開始予告を示すランプの点滅を開始させる（Ｓ５２）。このとき実行されているゲームは中断せず、プレイは継続される。このとき行なわれているプレイが終了すれば、プレイ受付部４１４は、予約期間になるまでプレイ要求の受付を行なわないようにする（Ｓ５４）。ゲーム装置１１０の出力部４２０は、たとえば「間もなく予約の時間になりますので、只今プレイすることはできません。」というメッセージを表示する。予約期間の前にプレイを受け付けなくする理由は、予約期間が始まるときにプレイが続いていると、予約によるプレイが始められないからである。プレイ時間が５分と想定すると、少なくとも予約期間の５分前までには、プレイが終了することになる。ランプが点滅し始めると、周囲の者は、間もなく予約による独占状態に切り替わることを知る。

予約期間開始のタイミングに至ると、通知送信部３１４は、独占開始の通知を予約対象のゲーム装置１１０へ送信する（Ｓ５６）。

ゲーム装置１１０の通知受信部４４２が独占開始の通知を受信すると、ランプ制御部４５０は、ランプを点灯に切り替える（Ｓ５８）。周囲の者は、予約による独占状態になったことを知る。図１１に示したフローチャートへ移る。

図１１は、予約期間中の処理過程を示すフローチャートである。
プレイしようとするユーザ（プレイヤ）がゲーム装置１１０の読み取り部にゲームカードをかざすと、ゲーム装置１１０のＩＤ検出部４１２はゲームカードからユーザＩＤを検出する（Ｓ６０）。ゲーム装置１１０の確認要求送信部４３２は、予約の確認要求をゲームサーバ１０２へ送信する（Ｓ６２）。予約の確認要求には、店舗ＩＤ、ゲーム装置ＩＤおよびユーザＩＤが含まれる。

ゲームサーバ１０２の予約管理部３５２は、受信した予約の確認要求に基づいて、プレイヤが予約者本人であるか否かの確認を行なう（Ｓ６４）。予約者以外のプレイヤである場合には、通知送信部３１４は他人通知をゲーム装置１１０へ送信する。この場合、ゲーム装置１１０は、たとえば「予約者以外の方は、プレイできません。」というメッセージを表示して、プレイ開始要求を受け付けない。一方、プレイヤが予約者本人である場合には、通知送信部３１４は本人通知をゲーム装置１１０へ送信する（Ｓ６６）。本人通知は予約プレイの許可に相当するので、ゲーム装置１１０はゲーム実行の処理に移る。これにより、ゲームの本編動作が始まり、プレイヤはプレイを楽しむ。

ゲーム実行の処理を終えると、ゲームサーバ１０２の課金処理部３５４は、プレイ代の課金を行なう（Ｓ６８）。具体的には、ユーザＩＤに対応する課金情報に、プレイ代のエントリを設けて、日付と、項目の種別（プレイ代）と、プレイ代の金額を設定する。プレイ代の金額は、通常と同様に１００円である。

ゲーム装置１１０のプレイデータ受信部４４４は、ゲームサーバ１０２へアクセスし、ユーザＩＤに対応するプレイデータをゲームサーバ１０２からダウンロードする（Ｓ７０）。ゲーム実行部４５２は、プレイデータに基づいてゲームの実行を開始する（Ｓ７２）。プレイが終了すると、プレイデータ送信部４３４は、今回のプレイによって更新されたプレイデータをアップロードする（Ｓ７４）。このようにすれば、ゲームカードをかざすだけで、プレイを開始できるので操作が簡単であり便利である。

ゲームサーバ１０２のプレイデータ更新部３５８は、プレイデータ格納部３７２の内容を、受信したプレイデータに従って更新する（Ｓ７６）。

予約期間内であれば、プレイヤは再度ゲームカードを読み取らせることによってプレイを楽しむことができる。つまり、Ｓ６０に示した処理に戻って図１１に示したフローが繰り返される。なお、課金情報には繰り返したプレイ分のプレイ代が追加される。

図１２は、予約期間が終わるときの処理過程を示すフローチャートである。
予約期間終了の第２所定時間（たとえば、５分）前になると、ゲームサーバ１０２の通知送信部３１４は、予約期間の終了予告の通知をゲーム装置１１０へ送信する（Ｓ８０）。

ゲーム装置１１０の通知受信部４４２が予約期間の終了予告の通知を受信すると、ランプ制御部４５０はランプを点滅に切り替える（Ｓ８２）。ランプが点滅しても、図１１のフローが中断されることはなく、プレイは継続できる。ランプが点滅し始めると、予約者自身も周りのユーザも、予約による独占状態が間もなく終わることを知る。プレイ時間が５分であると想定すると、予約に基づいてプレイを行なえるのは残り１回である。

予約期間終了のタイミングに至ると、通知送信部３１４は、独占終了の通知を予約対象のゲーム装置１１０へ送信する（Ｓ８４）。そして、電子決済部３５６は、予約代とプレイ代の合計金額を求めて、電子決済を行なう（Ｓ８６）。

ゲーム装置１１０の通知受信部４４２が独占終了の通知を受信すると、ランプ制御部４５０は、ランプを消灯させる（Ｓ８８）。この時点で行なわれているプレイが終わると、プレイ受付部４１４は、プレイ開始要求を受け付けるようになる（Ｓ９０）。したがって、予約者以外のプレイヤもプレイできる。

図１３は、無断キャンセルされた場合の処理過程を示すフローチャートである。
予約期間開始から第３所定時間（たとえば５分）が経過した時点で、予約者本人がプレイを開始しなければ、無断キャンセルされたと判断する。つまり、予約者本人のユーザＩＤが含まれる確認要求を受信しなければ、ゲームサーバ１０２の違約判定部３６０は、違約を確定させる（Ｓ１００）。違約が確定すると、通知送信部３１４は、独占終了の通知をゲーム装置１１０へ送信する（Ｓ１０２）。また。予約管理部３５２は、違約となった予約を解消させる（Ｓ１０４）。予約情報の予約者のフィールドに設定されているユーザＩＤが消去される。

課金処理部３５４は、予約の違約による清算を行なう（Ｓ１０６）。後述するように予約期間の途中で独占を解除するので、予約代のうち独占サービス料に相当する分の一部を減額してもよい。そして、ユーザＩＤに対応する課金情報に、違約金のエントリを設けて、日付と、項目の種別（違約金）と、違約金の金額を設定する。違約金は、違約に伴う損害賠償に相当する。違約金は、予約期間の長さに応じて定まる。違約が確定した場合には、当該予約に関連する課金額を確定させてよい。電子決済部３５６は、減額された予約代と違約金の合計額を電子決済する（Ｓ１０８）。たとえば１５分の予約期間を無断キャンセルした場合の違約金を６００円とすると、減額された予約代の１００円とあわせて７００円が引き落とされる。より詳細には、予約代３００円のうち、独占サービス料２００円は返金されるが、システムの利用料は返金されない。代わりに違約金６００円が加算される。このため、引き落とされる金額は、３００−２００＋６００＝７００円となる。同様にして、３０分の予約期間を無断キャンセルした場合の違約金を１２００円とすると、減額された予約代の１００円とあわせて１３００円が引き落とされる。このように、無断キャンセルした場合には、事前にキャンセル手続きをした場合に比べて支払額が高くなるので、ユーザは、無断キャンセルせずにきちんと事前キャンセルの手続きをするように心がける。

ゲーム装置１１０では、独占終了の通知を受信すると、ランプ制御部４５０がランプを消灯させる（Ｓ１１０）。そして、プレイ受付部４１４は、プレイ開始要求を受け付ける（Ｓ１１２）。ランプが消灯した時点で誰もプレイしていないので、すぐに通常のプレイが始められる。このように予約による独占を解除すれば、無断キャンセルされてもゲーム装置１１０の稼動機会が増え、収益向上に役立つ。

予約したユーザが予約を守れないと思ったとき、上述した事前キャンセルを行なわずに、他のユーザに予約者の地位を譲ってもよい。この場合、予約代は新たな予約者に振り返られる。また、解約代や違約金は生じない。したがって、当初の予約者は、一切負担する必要がなくなる。

図１４は、予約者の地位を他のユーザに譲る場合の処理過程を示すフローチャートである。
予約者は、たとえば友達であるユーザに電話やメールなどで連絡し、予約者の地位を譲ることに関して合意を得ておくものとする。図１４の例でユーザ端末１０４ａは当初の予約者が使用する端末であり、ユーザ端末１０４ｂは新たに予約者となるユーザが使用する端末である。

Ｓ１２０からＳ１２６までの処理は、図４に示したＳ１０からＳ１６の場合と同様である。当初の予約者であるユーザは予約画面で譲りたい予約を選択し、譲り先となるユーザを指定して、予約者の変更を指示する操作を行なう。友達リストからユーザを指定すれば、新たな予約者のユーザＩＤが特定される。このユーザ操作によって、ユーザ端末１０４ａの入力部２１０は予約者変更を受け付ける。

変更要求送信部２３８は、新たな予約者のユーザＩＤを含み、変更対象となる予約を特定する変更要求をゲームサーバ１０２へ送信する（Ｓ１２８）。変更対象は、店舗ＩＤ、日付、時間帯およびゲーム装置ＩＤで特定され、あるいは予約ごとに割り振られる予約ＩＤで特定される。

ゲームサーバ１０２の報知部３１８は、受信した変更要求で指定されている譲り先のユーザ宛に報知メールを送信する（Ｓ１３０）。報知メールの本文には、店舗名、日付、ゲーム装置名および時間帯を含む予約内容と当初予約したユーザの名前を含み、新たな予約者になることの承認を求めるメッセージが含まれる。さらに、本文には、承認の意思を示すためのＵＲＬ（Uniform Resource Locator）アドレスも含まれている。このＵＲＬアドレスは、ゲームサーバ１０２の変更要求受信部３４２を指し、承認を示すパラメータが付加されている。

ユーザ端末１０４ｂの報知受信部２５４で報知メールを受信すると、出力部４２０がメールの本文を表示し、新たに予約者となるユーザはその内容を確認する。承認の意思を示すためのＵＲＬアドレスへのアクセスが指示されると、応答送信部２４０は、ゲームサーバ１０２の変更要求受信部３４２へ承認を示すパラメータを送信する（Ｓ１３２）。

ゲームサーバ１０２の応答受信部３４４が承認を示すデータを受信すると、予約管理部３５２は、予約者を変更する（Ｓ１３４）。具体的には、予約情報に設定されている当初の予約者のユーザＩＤが、新たな予約者のユーザＩＤに書き換えられる。応答期限までに承認を示すデータを受信しなかった場合には、承認されなかったとみなして予約者の変更を行なわない。

課金処理部３５４は、予約代の清算を行なう（Ｓ１３６）。当初の予約者の課金情報を消去し、新たな予約者の課金情報に予約代のエントリを設定する。以上の処理によって、新たな予約者は、自ら予約した場合と同じ状態で登録される。一方、当初の予約者については予約をしなかった場合と同じ状態になる。

以上、自分がプレイするためにゲーム装置１１０を予約する例について説明した。しかし、このように一人で遊ぶだけでなく、友人といっしょに店舗１０８を訪れ、二人でゲームを楽しむことも考えられる。たとえば、対戦型のゲームであれば、２台のゲーム装置１１０を確保する必要がある。

そのため、一人のユーザが２台のゲーム装置１１０を予約してもよい。この場合、予約操作において、予約者本人のための予約（以下、「本予約」という。）と、同伴者のための予約（以下、「仮予約」という。）を区別する。たとえば、予約画面に本予約のボタンと仮予約のボタンを設ける。あるいは、仕様として、１回目の予約を本予約とし、２回目の予約を仮予約としてもよい。本予約の予約情報については、ここまで述べた予約と同様である。

仮予約の予約情報は、通常の予約情報と区別できる。仮予約の予約情報については、暫定的に予約者のユーザＩＤを登録しておく。そして、プレイ当日にゲーム装置１１０に対した時点で、同伴者のユーザＩＤを登録し直す。これにより、通常の予約情報となり、同伴者は、操作や課金に関して通常の予約者と同等に扱われるようになる。具体的な操作手順としては、先に予約者のゲームカードを読み取り、その次に同伴者のゲームカードを読み取る。このようにすれば、予約者がいる状況で同伴者を認定することになるので、他人による同伴者への成りすましを防げる。なお、同伴者もゲームカードを保持し、電子決済に対応しているものとする。

図１５は、仮予約したゲーム装置１１０を同伴者に使用させるときの処理過程を示すフローチャートである。
仮予約されているゲーム装置１１０が予約期間に入ると、出力部４２０は、予約者のゲームカードをかざすように指示するメッセージ（たとえば「まず、予約者のゲームカードを読み込ませてください。」）を表示し、ゲーム装置１１０のＩＤ検出部４１２はゲームカードからユーザＩＤを検出する（Ｓ１５０）。そして、ゲームサーバ１０２へ予約の確認要求が送信される（Ｓ１５２）。

ゲームサーバ１０２の予約管理部３５２は、受信した予約の確認要求に基づいて仮予約であると判定し、ユーザＩＤが予約者に該当するか否かの確認を行なう（Ｓ１５４）。予約者以外のユーザＩＤである場合には、通知送信部３１４は他人通知をゲーム装置１１０へ送信する。この場合、ゲーム装置１１０はエラーメッセージ（たとえば、「予約者のゲームカードではありません。」）を表示して、Ｓ１５０の処理に戻る。一方、予約者のユーザＩＤである場合には、通知送信部３１４は仮予約の通知をゲーム装置１１０へ送信する（Ｓ１５６）。

ゲーム装置１１０が仮予約の通知を受信した場合に、出力部４２０は、同伴者のゲームカードをかざすように指示するメッセージ（たとえば「次に、プレイヤのゲームカードを読み込ませてください。」）を表示する。ＩＤ検出部４１２は、再びゲームカードからユーザＩＤを検出し（Ｓ１５８）、変更要求送信部４３６は、読み取ったユーザＩＤを含む変更要求をゲームサーバ１０２へ送信する（Ｓ１６０）。

ゲームサーバ１０２の変更要求受信部３４２が変更要求を受信すると、予約管理部３５２は、予約者の変更を行なう（Ｓ１６２）。具体的には、予約情報に設定されている予約者のユーザＩＤを同伴者のユーザＩＤに書き換える。課金処理部３５４は、予約代の清算を行なう（Ｓ１６４）。予約者の課金情報から仮予約の予約代を消去し、同伴者の課金情報に予約代のエントリを設定する。以上の処理によって、同伴者は、自ら予約した場合と同じ状態で登録される。一方、予約者は、自分の本予約に関してのみ課金された状態になる。Ｓ１６６からからＳ１７６の処理は、図１１に示したＳ６６からＳ７６の場合と同様である。また、２回目以降のプレイについては、図１１のフローに従って処理される。

［変形例］
予約によって利用できるゲーム装置１１０は、予約プレイと通常プレイの両方に対応してもよいし、予約プレイ専用でもよい。予約プレイと通常プレイの両方に対応する場合には、当日の予約を受け付けずに、空き枠を通常プレイに提供してもよい。

ゲームサーバ１０２が、店舗１０８毎に個別的な予約サービスを提供してもよいし、ゲームサーバ１０２が、複数の店舗１０８が加入する統括的な予約サービスを提供してもよい。これらのケースでは、ゲームサーバ１０２の運営者が各店舗１０８に代わって受け取った代金（独占サービス料、プレイ代、解約代および違約金）は、各店舗１０８に還元される。尚、予約管理システムの利用料は、ゲームサーバ１０２の運営者の収入になる。これとは別に、各店舗１０８が自ら予約管理サーバを設けて、代金を徴収してもよい。

図３に示した電子決済部３５６における電子決済のタイミングは、１回の予約に関連する課金額が確定した段階でなくてもよい。予約代、プレイ代、解約代または違約金を課金したタイミングで決済してもよい。あるいは、週や月など所定の期間に確定した課金額をまとめて電子決済してもよい。また、通常プレイの代金と予約プレイの代金を合算して引き落としてもよい。

予約代について回数券方式で複数回分を前払いして、予約のたびに残余回数を減ずるようにしてもよい。また、予約代の内訳として、予約管理システムの利用料を省き、独占サービス料だけにしてもよい。この場合には、店舗１０８の運営者が別途ゲームサーバ１０２の運営者に予約管理システムの利用料を支払えばよい。

ユーザが、同種あるいは別種の複数の電子決済手段（たとえば、複数のクレジットカード、クレジットカードと預金口座、あるいは複数の預金口座）を登録しておいて、ユーザ端末１０４に表示させる選択画面で電子決済手段を選択できるようにしてもよい。この場合、ゲームサーバ１０２の電子決済部３５６は、選択されている電子決済手段を用いる。

電子決済手段は、クレジットカードや預金口座に限られず、デビットカード、電子マネーや仮想通貨でもよい。また、電子決済手段を用いて前払い方式で決済してもよい。前払い方式の場合には、予め電子決済によって所定のチャージ金額を確保し、課金額をそこから減ずる。そして、チャージ金額が不足すれば、改めて電子決済で補充する。

また、ポストペイ方式の電子決済手段を有していないユーザにも配慮して、現金またはプリペイドカード（たとえば、交通系ＩＣカード）によるチャージを受け付けてもよい。そのために、店舗１０８内にチャージ用装置を設けてもよい。そうすれば、ユーザが予約日に店舗に訪れた段階で現金やプリペイドカードでチャージしてから、予約プレイを行なうことができる。ゲームサーバ１０２は、いわばユーザのチャージ金額を預り金としておき、予約等がなされるごとにチャージ金額（預り金）から課金額を差し引けばよい。

この場合、ゲームサーバ１０２は、ユーザごとのチャージ金額を記憶するチャージ金額記憶部（図示せず）と、電子決済部３５６またはチャージ用装置から入金情報（ユーザＩＤと入金額）を受け付ける入金情報受信部（図示せず）と、ユーザのチャージ金額に入金額を加算するとともに、チャージ金額から課金額を差し引くチャージ管理部（図示せず）を備えてもよい。チャージ管理部は、本実施形態で示した電子決済処理のタイミングで、合計課金額を算出して差し引いてもよいし、各課金処理のタイミングで、その課金額を差し引いてもよい。

チャージ不足が生じたときのペナルティとして、チャージ金額が所定の最低限度額に満たない場合に、ゲームサーバ１０２の制裁部（図示せず）が、そのユーザのＩＤによる予約を受け付けないように制御してもよい。また、チャージ金額が足りずに決済できない場合に、制裁部が、各ゲーム装置１１０へ無効なユーザＩＤを通知して、ユーザのゲームカードを一時的に利用できないようにしてもよい。あるいは、制裁部が、ユーザのプレイデータで保持されているアイテムや能力を一時的に利用できないようにしてもよい。このようなペナルティが課せられると、ユーザは安易なチャージ不足を起こさないようになる。また、一時的にペナルティによる制限が課せられても、再チャージすればその制限は解除されるので、ユーザと店舗の信頼関係に傷がつくようなことはない。
なお、予約段階では決済を行わず、ユーザは入店時に予約代等を現金またはプリペイドカードで後支払いするとしてもよい。

図４のＳ１６およびＳ１８に関連して、予約を申し込む際に、ゲームに関する設定を指示してもよい。たとえば、対戦型ゲームにおいて「ソロ」、「店舗内対戦」あるいは「オンライン対戦」のモード設定を指示する。図１１のＳ７０においてゲーム装置１１０が、プレイデータと共に設定指示を受け取って、その指示に従ってゲーム実行をスタートさせる。たとえば、ユーザが予約時に「店舗内対戦」の設定を指示すれば、すぐに「店舗内対戦」モードでプレイできる。

図４のＳ１０およびＳ１２に関連して、ユーザ端末１０４の入力部２１０で受け付けたアカウント名とパスワードを送信して、ユーザ認証を行なってもよい。あるいは、顔画像や指紋データになどの生体情報に基づいてユーザ認証を行なってもよい。

図５に関連して説明したように、本実施形態では空き枠に対する最初の予約申し込みを行なったユーザが予約者となる。これに限らず、抽選によって予約者を決めるようにしてもよい。この場合、プレイ日を基準とする申込受付期間（たとえば、プレイ日の２週間前から３日前まで）において、予約要求受信部３３４が、プレイ日の予約候補の時間帯（以下、「候補枠」という。）の予約を希望するユーザから予約要求を受け付けて、申込受付期間が過ぎた時点で、予約管理部３５２が、各候補枠について抽選によって予約者を決定してもよい。ゲームサーバ１０２の報知部３１８は、当選者のユーザ端末１０４に候補枠を予約できたことを伝える当選メールを送信し、落選したユーザ端末１０４に候補枠を予約できなかったことを伝える落選メールを送信してもよい。

図７に示した予約代およびプレイ代の金額は、一例である。プレイ代を前払いさせる場合には、予約時の課金を高くし、プレイ時の課金を安くしてもよい。たとえば、定額プレイ代を予約代に含めて予約時に課金して、１回ごとのプレイ代を無料にする定額制としてもよい。あるいは、予約時の定額プレイ代の他に、プレイ回数が限度を超えた場合に安価なプレイ代を課す準定額制としてもよい。このように定額プレイ代を前払いさせる料金体系にすれば、１回の予約当たりの収益が安定しやすい。また、たとえばプレイ中にいろいろなチャレンジをして、沢山のプレイを楽しみたいプレイヤにとっては、プレイ回数にとらわれずにすむので、このような料金体系が適している。

他方、独占サービス料を予約代に含めず、独占の対価をプレイ代に含めて後払いさせる場合には、予約代を無料あるいは安価にして、プレイ代を通常よりも高くする料金体系としてもよい。このように割増の従量プレイ代を支払わせる料金体系では、１回の予約当たりの収益が安定しにくい面がある。一方、使用するキャラクタやアイテムの選択などの本編以外の準備時間が長い、対戦相手とのマッチングに時間がかかる、あるいは熟達していて１回のプレイ時間が長いなどの理由で予約期間内のプレイ回数が少ないと見込まれるプレイヤの場合は、このような料金体系が適している。

上述した料金体系の中間的な設定も考えられる。以下に、料金体系の具体例を示す。
・完全定額制・・・予約代（３０分）８００円、１回のプレイ代：無料
・準定額制・・・・予約代（３０分）７００円、１回のプレイ代（４回目〜）：５０円
・標準従量制・・・予約代（３０分）３００円、１回のプレイ代：１００円
・割増従量制・・・予約代（３０分） ５０円、１回のプレイ代：１５０円

課金処理部３５４が複数の料金体系に対応し、店舗１０８の運営者に適用したい料金体系を選択させてもよい。あるいは、これらの複数の料金体系を公開して、ユーザが選択できるようにしてもよい。この場合、ゲームサーバ１０２は、ユーザ端末１０４に複数種類の料金体系を提示する料金体系画面のデータを送信する料金体系画面送信部（図示せず）を備える。ユーザ端末１０４は、受信したデータに基づいて料金体系画面を表示させ、適用する料金体系をユーザに選択させる料金体系選択部（図示せず）と、選択された料金体系の種別をゲームサーバ１０２へ送信する料金体系送信部（図示せず）を備える。ゲームサーバ１０２は、料金体系の種別を受信する料金体系受信部（図示せず）と、受信した料金体系の種別をユーザに対応づけて記憶する料金体系記憶部（図示せず）と、を更に備える。また、課金処理部３５４は、ユーザに対応する料金体系の種別に応じて課金を行なう。

ユーザが選択した料金体系の種別によって、予約手続きに差を持たせてもよい。一例として、完全定額制を利用するユーザであれば、早い時期（たとえば、プレイ日の４週間前）から予約を受け付け、割増従量制を利用するユーザの場合には、遅い時期（たとえば、プレイ日の２週間前）から予約を受け付ける。このようにすれば、完全定額制を促進する効果がある。逆の扱いにすれば、割増従量制の利用を促進することになる。いずれの料金体系を推奨するかは、任意である。また、推奨される料金体系を選択するユーザへの特典の内容は、予約回数券の付与のようにこの例以外のものであってもよい。

図８のＳ３８に示した解約要求に関して、解約を受け付ける期限を設けてもよい。たとえば、前日までは解約を受け付け、当日は解約を受け付けなくてもよい。

図８のＳ４２に示した解約による清算に関して、予約代を基準として解約代を決めてもよい。たとえば、前日までに解約すれば、予約代の３割を課金し、当日に解約すれば、予約代の５割を課金する。このようにすれば、早めに解約が行なわれ、改めて予約される機会が増す。また、予約期間が長いほど解約代を高くしてもよい。このようにすれば、解約による損失リスクに応じた補償がなされる。

連続する複数の予約枠を一括キャンセルする場合には、図８に示したフローのとおり処理する。他方、一部の予約枠のみをキャンセルする場合には、予約画面でユーザによって選択された予約枠の時間帯に関してのみ、Ｓ４０の予約の解消およびＳ４２の解約による清算を行ない、Ｓ４４の電子決済を行なわなくてもよい。残した時間帯については予約プレイを行なえるので、その時間帯が過ぎた時点で図１２に示したＳ８６の電子決済が行なわれる。

予約日の前日や予約期間開始の数時間前に、ゲームサーバ１０２のリマインダー送信部（図示せず）が、予約者のユーザ端末１０４へリマインダーメールを送ってもよい。リマインダーメールには、店舗名、日付、ゲーム装置名および時間帯を含む予約内容を含み、来店を促すメッセージが本文に含まれる。本文には、キャンセルの意思を示すためのＵＲＬアドレスを含めてもよい。このＵＲＬアドレスは、ゲームサーバ１０２の解約要求受信部３３６を指す。一括キャンセルのほかに、時間帯毎のキャンセルをできるようにしてもよい。たとえば、キャンセルする時間帯毎に、その時間帯を示すパラメータが付加されたＵＲＬアドレスを、その時間帯のキャンセル要求であることを示すメッセージとともに列挙する。ユーザ端末１０４でこのＵＲＬアドレスへのアクセスが指示されると、ユーザ端末１０４の応答送信部２４０は、ゲームサーバ１０２の解約要求受信部３３６へキャンセル対象の時間帯を示すパラメータを送信する。受信した時間帯について、ゲームサーバ１０２の予約管理部３５２は予約の解消を行い（図８のＳ４０と同様）、課金処理部３５４は予約の解約による清算を行なう（図８のＳ４２と同様）。このようにすれば、少し遅刻しそうな場合に、初めの方の時間帯だけキャンセルして、残りの時間帯で予約プレイを楽しむことができる。無断キャンセルにならずにすむので、ユーザの状況に応じた円滑な運用の促進に役立つ。

少し早めに入店した予約者が、予約期間の前に他のゲーム装置１１０をプレイしながら待つこともある。その点を考慮して、ゲームサーバ１０２の報知部３１８は、予約期間が始まる前に、予約期間の予告を予約者のユーザ端末１０４やプレイ中のゲーム装置１１０へ送信し、予約期間の予告メッセージを音声出力や表示させてもよい。また、予約期間の直前に予約者が他のゲーム装置１１０でプレイしようとしたときに、ゲームサーバ１０２の報知部３１８は、今プレイをはじめれば予約期間の開始に間に合わないことを注意する通知を、予約者のユーザ端末１０４やプレイ中のゲーム装置１１０へ送信し、注意メッセージを音声出力や表示させてもよい。

図１０のＳ５２に示した予約期間の開始予告を示すランプの点滅は、省いてもよい。ランプの点滅に代えて、予約期間中と異なる色のランプを点灯させてもよい。予約期間の開始予告を示す音声ガイダンスや音楽を出力してもよい。

図１０のＳ５４に示したプレイ要求受付の停止に関して、間もなく始まる予約期間の予約者に限ってプレイ要求を受け付けてもよい。実質的に前倒しで独占状態が始まることになるので、このタイミングでランプを点灯に切り替えてもよいし、前倒し分の独占サービス料を課金してもよい。Ｓ５０に示した開始予告の通知において予約者のユーザＩＤを送信しておけば、ゲーム装置１１０で予約者を判別できる。

図１０のＳ５８に示したランプ点灯以外の方法で、予約プレイであることを周囲に知らせてもよい。ゲーム装置１１０の表示装置の縁に枠状の発光部を設けて点灯させてもよい。同じく枠状の表示部を設けて、予約プレイを示すメッセージや装飾を表示してもよい。店舗１０８内に設けられた電子掲示板に予約プレイ中のゲーム装置１１０の名前を表示してもよい。

図１１に関連して、ゲーム装置１１０において予約確認を行なってもよい。図１０のＳ５０に示した開始予告の通知またはＳ５６に示した独占開始の通知で予約者のユーザＩＤをゲーム装置１１０に送信しておけば、図１１に示したＳ６０の処理で、ゲームカードから読み取ったユーザＩＤが予約者を示すか否か判定できる。

図１１に関連して、予約期間中における２回目以降のプレイについて、プレイヤがスタートボタンにタッチするだけでスタートしてもよい。その場合、ゲーム装置１１０の送信部４３０からゲームサーバ１０２の受信部３３０へプレイ開始の通知を送信してもよい。そして、Ｓ６０〜Ｓ６６の処理を省いてもよい。

図１３に関連して説明した無断キャンセルに関して、所定期限までに予約者が入店しない場合に違約と判断してもよい。入店期限は、予約期間開始を基準として定められる。店舗１０８内の移動や準備に要する時間を考慮して、予約期間開始から第４所定時間（たとえば、１０分）さかのぼった時点を入店期限としてもよい。いずれかのゲーム装置１１０で予約者のゲームカードを読み取った場合にチェックインとしてもよいし、ゲーム装置１１０以外にチェックインを受け付ける装置を設けて、その装置でチェックインを確認してもよい。あるいは、ユーザ端末１０４の位置情報によってチェックインを確認してもよい。

図１３に関連して説明した無断キャンセルに関して、予約者のユーザ端末１０４から遅刻の連絡を受信している場合には違約として扱わなくてもよい。但し、予約者のプレイ回数が想定よりも少なくなるので、遅刻時間に応じた補償代を課金してもよい。

予約期間の終了まで待って予約者がプレイしない場合に、違約を確定させてもよい。この場合には、誰もプレイできない状態が続き、店舗１０８にとって収益の機会を逸したことになるので、高めの違約金を求めてもよい。

段階的に無断キャンセルの対応を行なってもよい。つまり、連続する複数の時間帯が予約されている場合には、時間帯毎に図１３に示したＳ１００の違約の判定を行なってもよい。このようにすれば、予約期間の開始に間に合わなくても、途中から予約プレイをできる。この場合、違約判定部３６０は、各時間帯の終了時点で、予約者本人がプレイを開始しなければ、その時間帯について違約を確定させる。最後の時間帯以外については、図１３に示したＳ１０２の独占終了の通知を省く。したがって、ランプは点灯したままであり、プレイ要求受付も再開されない。ゲームサーバ１０２は、違約となった時間帯についてＳ１０６の違約の清算を行なう。つまり、課金処理部３５４は、１つの時間帯分の違約による清算を行なう。ユーザＩＤに対応する課金情報に、違約金のエントリを設けて、日付と、項目の種別（違約金）と、１つの時間帯分の違約金の金額を設定する。最後の時間帯以外の場合、Ｓ１０８の電子決済を行なわなくてもよい。遅刻してきたユーザが予約プレイを始めた場合は、予約期間の終了時点で図１２に示したＳ８６の電子決済を行なう。最後の時間帯についても違約が確定した場合には、Ｓ１０２に示した独占終了の通知が送信され、ゲーム装置１１０は、Ｓ１１０でランプを消灯し、Ｓ１１２でプレイ要求の受け付けを再開させる。ゲームサーバ１０２は、最後の時間帯についてＳ１０４の予約の解消とＳ１０６の違約の清算を行ない、さらにＳ１０８で各時間帯の分の違約金をまとめて電子決済する。

違約が発生したときに、ゲームサーバ１０２の制裁部が、違約金以外のペナルティを課してもよい。プレイデータに含まれるポイント、アイテムや能力値を所定期間（たとえば、無断キャンセルした日から所定日数が経過するまでの間）だけ無効にし、または減少させてもよい。上述した予約の回数券方式で、ペナルティとして残余回数を減らしてもよい。あるいは、一定期間だけ予約申し込みを禁じてもよい。

違約のペナルティと逆に、遅刻せずに予約プレイした場合に、ゲームサーバ１０２の優遇部（図示せず）がインセンティブを与えて予約の履行を促してもよい。予約プレイの特典としてゲームのポイント、アイテムや能力値を付与し、あるいはプレイ時間を延長してもよい。また、一般のユーザよりも予約開始時期を早めて優先的に予約できるようにし、あるいは次の予約代を減額あるいは無償にしてもよい。予約プレイの前の待ち時間に行なうプレイの代金を減額あるいは無償にしてもよい。抽選によって予約者を決める方式において、当選しやすくする特典を与えてもよい。この場合に優遇部は、予約管理部３５２に特典を得たユーザの当選確率を高めるように指示する。予約プレイの回数が所定数に達したときに、これらの特典を与えてもよい。

図１３に関連して説明した違約金の額は、予約期間の長さにかかわらず一律でもよい。また、課金処理部３５４は、無断キャンセルした回数に応じて、違約金を増やしてもよい。無断キャンセルした回数が限度に達した場合に、ゲームサーバ１０２の制裁部が、無断キャンセルを重ねたユーザに対する予約サービスを停止してもよい。

無断キャンセルされた場合に予約金の全部又は一部を没収し、改めて違約金を求めないという形式をとった場合でも、実質的には予約金の全部又は一部を違約金に振り替えて、違約金を課金していると考えられる。違約が生じたときには別途課金すれば、必ずしも予約代を高額にしてリスク回避を図らなくてもよい。

図１４に関連して説明したように、他のユーザに予約者の地位を譲った場合に、ゲームサーバ１０２の優遇部が、元の予約者あるいは新たな予約者に特典を付与してもよい。店舗１０８にとって収益の機会を維持できるので、ユーザ間で予約者の地位を譲り合うことを推奨する意味がある。但し、限られた仲間同士だけで専有し、あるいは転売を目的とすることは好ましくないので、たとえばゲームのポイント、アイテムや能力値の付与やプレイ時間の延長など、ゲームプレイを楽しむための特典にとどめる。過剰な地位譲渡を防ぐために、課金処理部３５４は、当初の予約者に予約代の一部または全部を負担させてもよい。予約管理部３５２が、予約者の地位を１つの予約枠に関して譲れる回数を制限してもよい。１回限りにしてもよいし、２回以上の所定回数までにしてもよい。

図１５に関連して説明した仮予約を複数台に対して行なってもよい。過度な仮予約を防ぐために、仮予約できる台数を限定してもよい。あるいは、本予約と同じゲームタイトルに限って仮予約できるようにしてもよい。

同伴者がそのゲームの初心者である場合に、需要拡大に寄与した報酬として、ゲームサーバ１０２の優遇部が、同伴者を連れてきた予約者に特典を付与してもよい。優遇部は、同伴者に対応するプレイデータに含まれる履歴データを参照して、初心者であると判断してもよい。たとえば、予約されたゲーム装置１１０のゲームタイトルに関して、同伴者のプレイ回数が基準に満たないとき、同じく累計プレイ時間が基準に満たないとき、あるいは最後にプレイした時から所定日数以上経過しているときなどに、初心者であると判断される。あるいは、ゲームタイトルを限定せずに、プレイ回数、累計プレイ時間または経過日数の判定を行なってもよい。特典の内容は、これまで述べたゲームに関するいずれのものであってもよいし、同じく予約サービスに関するいずれのものであってもよい。

予約管理サーバは、ゲームサーバ１０２と一体でなく別に設けられてもよい。また、中継装置１１２が、店舗１０８における予約管理サーバとして機能してもよい。あるいは、店舗１０８に専用の予約管理サーバを設けてもよい。

なお、本発明は上記実施形態や変形例に限定されるものではなく、要旨を逸脱しない範囲で構成要素を変形して具体化することができる。上記実施形態や変形例に開示されている複数の構成要素を適宜組み合わせることにより種々の発明を形成してもよい。また、上記実施形態や変形例に示される全構成要素からいくつかの構成要素を削除してもよい。

本実施形態においては、予約者の電子決済手段を利用するので、予約プレイに関連する代金を確実に受け取れる。

また、予約期間内あるいは予約期間の開始から所定期限までの間に、予約対象のゲーム装置１１０における予約者のプレイを確認できない場合に、無断キャンセルされたと判定し、違約金を課金するので、無断キャンセルの補償が確実になる。

また、予約要求を受け付けたときにゲーム装置１１０の予約代を課金するので、予約代の受け取りが確実になる。

また、無断キャンセルされたと判定した場合に、予約代の少なくとも一部を無断キャンセルに応じた清算に当てるので、無断キャンセルの補償が確実になる。

また、予約期間内のプレイ代を安くすれば、ユーザは予約プレイをしに行くのが楽しみになる。店舗１０８の運営者にとっては、プレイ代を安くして予約代の比重を高めれば、収益を安定させやすい。

また、予約対象のゲーム装置１１０でゲームカードから読み取ったユーザＩＤを受信し、予約者であるか確認して通知する。さらに、予約者本人である場合には当人のプレイデータをゲーム装置１１０へ送信する。したがって、ゲーム装置１１０で予約者の認証に関するユーザ操作を省き、ゲームカードを読み取るだけで、すぐにプレイを開始させられる。

また、ゲームカードから読み取ったユーザＩＤを受信して予約者であると確認した場合に、プレイ代を課金するので、プレイ代の徴収が簡便になる。

また、予約期間から遡った所定期限までに、予約者のチェックインを確認できた場合に予約代を課金する。つまり、予約プレイが確実に行なわれる状況に限って予約代を課すので、事前に予約代を課すよりもユーザの負担感が減る。

また、予約期間から遡った所定期限までに、予約者のチェックインを確認できない場合に予約を解消させる。したがって、早めに予約を解消して、通常プレイによる収益の機会を増やせる。

また、予約要求を受け付けたときに、定額のプレイ代を課金すれば、ユーザはプレイ回数を気にせずにプレイを楽しむことができ、店舗１０８の運営者は収益の安定化を見込める。

また、複数の料金体系からユーザが好みの料金体系を選択できるので、予約管理システム１００の柔軟な運用が図られる。たとえば、プレイ回数を気にせずにたくさんプレイを楽しみたいと思うユーザは、予約代が高くても、１回のプレイ代が安い料金体系を選んだ方がよい。反対に、あまりプレイ回数が多くならないと思うユーザは、１回のプレイ代が多少高くても、予約代が安い料金体系を選んだ方がよい。同じゲームタイトルであっても、ユーザによって考え方は異なるので、自由に料金体系を選べると予約制の利用態様が広がり、利便性が高まる。たとえば、対戦型のゲーム装置を初心者が予約するときに、コンピュータ対戦モードでたくさん練習したいと思えば、完全定額制や準定額制の料金体系を選ぶと利用料が少なくなる。他方、同じ対戦型のゲーム装置を予約する場合でも、他のプレイヤとの対戦にこだわる熟達者であれば、マッチングが成立するまでプレイせずに待つことも考えられるので、割増従量制や標準従量制の料金体系を選ぶと利用料が少なくなる。このように、同じゲームタイトルであっても、個々のユーザの遊び方によって適した料金体系が異なることも想定できる。

予約時においては、課金しない、または、課金情報としてエントリに登録しないとしてもよい。そして、予約期間が近づいたとき、たとえば、予約期間開始の１５分前に実際に課金をするとしてもよい。

予約時間よりも早めに来店した予約者に対しては、上述しや優遇部はこの予約者に特典を付与してもよい。たとえば、ユーザＡが予約時間よりも１５分以上前に来店し、店舗の入店確認装置（不図示）においてユーザＩＤを入力したとする。このとき、優遇部は、該当するユーザＩＤに対して優遇フラグを設定する。ユーザＡが予約時間前に任意のゲームＸをプレイするとき、優遇部はユーザＡについて優遇フラグがオンになっているときには、ゲームＸのプレイ料金を無料または低額に設定してもよい。このような制御方法によれば、プレイヤに予約時間を守らせるインセンティブを与えることができる。また、予約対象となったゲームだけでなく、新しく導入したゲームＸを認知させる上でも有効と考えられる。

１００ 予約管理システム、１０２ ゲームサーバ、１０４ ユーザ端末、１０６ インターネット、１０８ 店舗、１１０ ゲーム装置、１１２ 中継装置、２０２ ユーザインターフェース処理部、２０４ 通信部、２０６ データ処理部、２０８ データ格納部、２１０ 入力部、２２０ 出力部、２２２ 予約画面表示部、２３０ 送信部、２３２ ＩＤ送信部、２３４ 予約要求送信部、２３６ 解約要求送信部、２３８ 変更要求送信部、２４０ 応答送信部、２５０ 受信部、２５２ 予約画面受信部、２５４ 報知受信部、３０２ 通信部、３０４ データ処理部、３０６ データ格納部、３１０ 送信部、３１２ 予約画面送信部、３１４ 通知送信部、３１６ プレイデータ送信部、３１８ 報知部、３３０ 受信部、３３２ ＩＤ受信部、３３４ 予約要求受信部、３３６ 解約要求受信部、３３８ 確認要求受信部、３４０ プレイデータ受信部、３４２ 変更要求受信部、３４４ 応答受信部、３５０ ユーザ認証部、３５２ 予約管理部、３５４ 課金処理部、３５６ 電子決済部、３５８ プレイデータ更新部、３６０ 違約判定部、３６２ チェックイン判定部、３７０ アカウント情報格納部、３７２ プレイデータ格納部、３７４ 予約情報格納部、３７６ 電子決済情報格納部、３７８ 店舗情報格納部、３８０ 課金情報格納部、４０２ ユーザインターフェース処理部、４０４ 通信部、４０６ データ処理部、４０８ データ格納部、４１０ 入力部、４１２ ＩＤ検出部、４１４ プレイ受付部、４２０ 出力部、４３０ 送信部、４３２ 確認要求送信部、４３４ プレイデータ送信部、４３６ 変更要求送信部、４４０ 受信部、４４２ 通知受信部、４４４ プレイデータ受信部、４５０ ランプ制御部、４５２ ゲーム実行部

Claims (15)

1. 通信端末およびゲーム装置と通信ネットワークを介して接続され、
   前記通信端末を使用するユーザを認証する認証部と、
   前記通信端末から、予約対象のゲーム装置と予約期間を特定する予約要求を受け付ける受付部と、
   前記予約対象のゲーム装置と前記予約期間に、前記ユーザを予約者として対応づけて記憶する記憶部と、
   前記予約者の電子決済手段から、予約プレイに関連する代金を受け取る決済部と、を備えることを特徴とする予約管理サーバ。
2. 前記予約期間内または前記予約期間の開始から所定期限までの間に、前記予約対象のゲーム装置における前記予約者のプレイを確認できない場合に、無断キャンセルされたと判定する判定部と、
   無断キャンセルされたと判定したときに、前記代金として違約金を課す課金部、を更に備えることを特徴とする請求項１に記載の予約管理サーバ。
3. 予約要求を受け付けたときに、前記代金として予約代を課す課金部、を更に備えることを特徴とする請求項１に記載の予約管理サーバ。
4. 前記予約期間内または前記予約期間の開始から所定期限までの間に、前記予約対象のゲーム装置における前記予約者のプレイを確認できない場合に、無断キャンセルされたと判定する判定部、を更に備え、
   前記課金部は、前記予約代の少なくとも一部を、無断キャンセルに応じた清算に当てることを特徴とする請求項３に記載の予約管理サーバ。
5. 前記課金部は、前記予約期間内のプレイに対して、前記代金として通常のプレイ代よりも安いプレイ代を課すことを特徴とする請求項３に記載の予約管理サーバ。
6. 前記予約対象のゲーム装置で、プレイヤが保有する記憶媒体から読み取ったユーザＩＤを受信する受信部と、
   前記予約期間内において受信した前記ユーザＩＤが前記予約者を示すと判定した場合に、プレイ許可の通知を前記予約対象のゲーム装置へ送信する通知部と、を更に備えることを特徴とする請求項１に記載の予約管理サーバ。
7. 前記予約期間内において受信した前記ユーザＩＤが前記予約者を示すと判定した場合に、前記代金としてプレイ代を課す課金部、を更に備えることを特徴とする請求項６に記載の予約管理サーバ。
8. 前記予約期間内において受信した前記ユーザＩＤが前記予約者を示すと判定した場合に、前記ユーザＩＤに対応するプレイデータを前記予約対象のゲーム装置へ送信する送信部、を更に備えることを特徴とする請求項７に記載の予約管理サーバ。
9. 前記予約対象のゲーム装置で、プレイヤが保有する記憶媒体から読み取ったユーザＩＤを受信する受信部と、
   前記予約期間内において受信した前記ユーザＩＤが前記予約者を示すと判定した場合に、前記代金としてプレイ代を課す課金部、を更に備えることを特徴とする請求項１に記載の予約管理サーバ。
10. 前記予約期間から遡った所定期限までに、前記予約者のチェックインを確認できた場合に、前記代金として予約代を課す課金部、を更に備えることを特徴とする請求項１に記載の予約管理サーバ。
11. 前記所定期限までに前記チェックインを確認できない場合に、予約を解消させる解消部、を更に備えることを特徴とする請求項１０に記載の予約管理サーバ。
12. 前記予約要求を受け付けたときに、前記代金として定額のプレイ代を課す課金部、を更に備えることを特徴とする請求項１に記載の予約管理サーバ。
13. 前記代金に関する複数の料金体系のうち、ユーザに選択された料金体系を適用して、前記代金に関する課金を行なう課金部、を更に備えることを特徴とする請求項１に記載の予約管理サーバ。
14. 前記複数の料金体系は、第１料金体系と第２料金体系を含み、
    前記第１料金体系における予約代は、前記第２料金体系における予約代よりも高く、前記第２料金体系における従量プレイ代は、前記第１料金体系における従量プレイ代よりも高いことを特徴する請求項１３に記載の予約管理サーバ。
15. 通信端末およびゲーム装置と通信ネットワークを介して接続可能なコンピュータに、
    前記通信端末を使用するユーザを認証する機能と、
    前記通信端末から、予約対象のゲーム装置と予約期間を特定する予約要求を受け付ける機能と、
    前記予約対象のゲーム装置と前記予約期間に、前記ユーザを予約者として対応づけて記憶する機能と、
    前記予約者の電子決済手段から、予約プレイに関連する代金を受け取る機能と、を発揮させることを特徴とする予約管理プログラム。

Images