(57)【要約】【課題】ゲーム機の稼動状況もしくはプレイ希望者からの入札状況に応じて料金設定を適切に変化させる。【解決手段】ゲーム機のプレイ料金を決定して決済を行うシステムであって、上記ゲーム機の稼動時間を示すデータを取得し、稼動履歴として記憶する手段と、記憶された稼動履歴に基づいて稼動率を計算する手段と、計算された稼動率に基づいて所定の演算処理によりプレイ料金を計算する手段と、計算されたプレイ料金を表示する手段と、表示されたプレイ料金の支払を受け付けて決済を行い、上記ゲーム機をプレイ可能状態にする手段とを備える。また、上記ゲーム機の利用に対する入札を受け付け、入札内容を入札履歴として記憶する手段と、記憶された入札履歴を表示する手段と、上記ゲーム機が空き状態になった際に、入札履歴を参照して有効な入札の中から仮落札者を決定する手段と、決定された仮落札者を呼び出す手段と、仮落札者の認証を行って落札を確定し、上記ゲーム機をプレイ可能状態にする手段とを備える。【選択図】図１
2008250946.tif 000002
【特許請求の範囲】
【請求項１】
ゲーム機のプレイ料金を決定して決済を行うシステムであって、
上記ゲーム機の稼動時間を示すデータを取得し、稼動履歴として記憶する手段と、
記憶された稼動履歴に基づいて稼動率を計算する手段と、
計算された稼動率に基づいて所定の演算処理によりプレイ料金を計算する手段と、
計算されたプレイ料金を表示する手段と、
表示されたプレイ料金の支払を受け付けて決済を行い、上記ゲーム機をプレイ可能状態にする手段とを備えたことを特徴とするゲーム機プレイ料金設定システム。
【請求項２】
請求項１に記載のゲーム機プレイ料金設定システムにおいて、
単一の上記ゲーム機について、当該ゲーム機に直接接続された決済端末により上記各手段の処理を行うことを特徴とするゲーム機プレイ料金設定システム。
【請求項３】
請求項１に記載のゲーム機プレイ料金設定システムにおいて、
複数の上記ゲーム機について、当該ゲーム機毎に直接接続された複数の決済端末およびネットワークを介して接続されたサーバにより上記各手段の処理を行うことを特徴とするゲーム機プレイ料金設定システム。
【請求項４】
請求項１に記載のゲーム機プレイ料金設定システムにおいて、
単一の上記ゲーム機について、当該ゲーム機に接続された複数の決済端末およびネットワークを介して接続されたサーバにより上記各手段の処理を行うことを特徴とするゲーム機プレイ料金設定システム。
【請求項５】
請求項１乃至４のいずれか一項に記載のゲーム機プレイ料金設定システムにおいて、
ゲーム時間が一定でない場合に、ゲーム開始時刻とゲーム終了時刻を上記ゲーム機の稼動時間を示すデータとして稼動履歴に含めることを特徴とするゲーム機プレイ料金設定システム。
【請求項６】
請求項１乃至４のいずれか一項に記載のゲーム機プレイ料金設定システムにおいて、
ゲーム時間が一定とみなせる場合に、上記ゲーム機をプレイ可能状態にする支払通知時刻を上記ゲーム機の稼動時間を示すデータとして稼動履歴に含めることを特徴とするゲーム機プレイ料金設定システム。
【請求項７】
ゲーム機のプレイ料金を決定して決済を行うシステムであって、
上記ゲーム機の利用に対する入札を受け付け、入札内容を入札履歴として記憶する手段と、
記憶された入札履歴を表示する手段と、
上記ゲーム機が空き状態になった際に、入札履歴を参照して有効な入札の中から仮落札者を決定する手段と、
決定された仮落札者を呼び出す手段と、
仮落札者の認証を行って落札を確定し、上記ゲーム機をプレイ可能状態にする手段とを備えたことを特徴とするゲーム機プレイ料金設定システム。
【請求項８】
請求項７に記載のゲーム機プレイ料金設定システムにおいて、
単一の上記ゲーム機について、当該ゲーム機に直接接続された決済端末により上記各手段の処理を行うことを特徴とするゲーム機プレイ料金設定システム。
【請求項９】
請求項７に記載のゲーム機プレイ料金設定システムにおいて、
複数の上記ゲーム機について、当該ゲーム機毎に直接接続された複数の決済端末およびネットワークを介して接続されたサーバにより上記各手段の処理を行うことを特徴とするゲーム機プレイ料金設定システム。
【請求項１０】
請求項７に記載のゲーム機プレイ料金設定システムにおいて、
単一の上記ゲーム機について、当該ゲーム機毎に接続された複数の決済端末およびネットワークを介して接続されたサーバにより上記各手段の処理を行うことを特徴とするゲーム機プレイ料金設定システム。
【請求項１１】
ゲーム機のプレイ料金を決定して決済を行うシステムであって、
当該システムが提示する金額による上記ゲーム機の利用に対する入札を受け付け、入札内容を入札履歴として記憶する手段と、
記憶された入札履歴を表示する手段と、
上記ゲーム機が空き状態になった際に、入札履歴を参照して有効な入札の中から入札した順に仮落札者を決定する手段と、
決定された仮落札者を呼び出す手段と、
仮落札者の認証を行って落札を確定し、上記ゲーム機をプレイ可能状態にする手段とを備えたことを特徴とするゲーム機遊戯順序設定システム。
【請求項１２】
ゲーム機のプレイ料金を決定して決済を行うシステムであって、
上記ゲーム機の稼動時間を示すデータを取得し、稼動履歴として記憶する手段と、
記憶された稼動履歴に基づいて稼動率を計算する手段と、
計算された稼動率に基づいて所定の演算処理によりプレイ料金を計算する手段と、
計算されたプレイ料金を表示する手段と、
表示されたプレイ料金の支払を受け付けて決済を行い、上記ゲーム機をプレイ可能状態にする手段と、
上記ゲーム機の利用に対する入札を受け付け、入札内容を入札履歴として記憶する手段と、
記憶された入札履歴を表示する手段と、
上記ゲーム機が空き状態になった際に、入札履歴を参照して有効な入札の中から仮落札者を決定する手段と、
決定された仮落札者を呼び出す手段と、
仮落札者の認証を行って落札を確定し、上記ゲーム機をプレイ可能状態にする手段とを備えたことを特徴とするゲーム機プレイ料金設定システム。
【請求項１３】
ゲーム機のプレイ料金を決定して決済を行うシステムの制御方法であって、
上記ゲーム機の稼動時間を示すデータを取得し、稼動履歴として記憶する工程と、
記憶された稼動履歴に基づいて稼動率を計算する工程と、
計算された稼動率に基づいて所定の演算処理によりプレイ料金を計算する工程と、
計算されたプレイ料金を表示する工程と、
表示されたプレイ料金の支払を受け付けて決済を行い、上記ゲーム機をプレイ可能状態にする工程とを備えたことを特徴とするゲーム機プレイ料金設定制御方法。
【請求項１４】
ゲーム機のプレイ料金を決定して決済を行うシステムの制御方法であって、
上記ゲーム機の利用に対する入札を受け付け、入札内容を入札履歴として記憶する工程と、
記憶された入札履歴を表示する工程と、
上記ゲーム機が空き状態になった際に、入札履歴を参照して有効な入札の中から仮落札者を決定する工程と、
決定された仮落札者を呼び出す工程と、
仮落札者の認証を行って落札を確定し、上記ゲーム機をプレイ可能状態にする工程とを備えたことを特徴とするゲーム機プレイ料金設定制御方法。
【請求項１５】
ゲーム機のプレイ料金を決定して決済を行うシステムの制御方法であって、
当該システムが提示する金額による上記ゲーム機の利用に対する入札を受け付け、入札内容を入札履歴として記憶する工程と、
記憶された入札履歴を表示する工程と、
上記ゲーム機が空き状態になった際に、入札履歴を参照して有効な入札の中から入札した順に仮落札者を決定する工程と、
決定された仮落札者を呼び出す工程と、
仮落札者の認証を行って落札を確定し、上記ゲーム機をプレイ可能状態にする工程とを備えたことを特徴とするゲーム機遊戯順序設定制御方法。
【請求項１６】
ゲーム機のプレイ料金を決定して決済を行うシステムの制御方法であって、
上記ゲーム機の稼動時間を示すデータを取得し、稼動履歴として記憶する工程と、
記憶された稼動履歴に基づいて稼動率を計算する工程と、
計算された稼動率に基づいて所定の演算処理によりプレイ料金を計算する工程と、
計算されたプレイ料金を表示する工程と、
表示されたプレイ料金の支払を受け付けて決済を行い、上記ゲーム機をプレイ可能状態にする工程と、
上記ゲーム機の利用に対する入札を受け付け、入札内容を入札履歴として記憶する工程と、
記憶された入札履歴を表示する工程と、
上記ゲーム機が空き状態になった際に、入札履歴を参照して有効な入札の中から仮落札者を決定する工程と、
決定された仮落札者を呼び出す工程と、
仮落札者の認証を行って落札を確定し、上記ゲーム機をプレイ可能状態にする工程とを備えたことを特徴とするゲーム機プレイ料金設定制御方法。
【請求項１７】
ゲーム機のプレイ料金を決定して決済を行うシステムの制御プログラムであって、
コンピュータを、
上記ゲーム機の稼動時間を示すデータを取得し、稼動履歴として記憶する手段、
記憶された稼動履歴に基づいて稼動率を計算する手段、
計算された稼動率に基づいて所定の演算処理によりプレイ料金を計算する手段、
計算されたプレイ料金を表示する手段、
表示されたプレイ料金の支払を受け付けて決済を行い、上記ゲーム機をプレイ可能状態にする手段、
として機能させることを特徴とするゲーム機プレイ料金設定制御プログラム。
【請求項１８】
ゲーム機のプレイ料金を決定して決済を行うシステムの制御プログラムであって、
コンピュータを、
上記ゲーム機の利用に対する入札を受け付け、入札内容を入札履歴として記憶する手段、
記憶された入札履歴を表示する手段、
上記ゲーム機が空き状態になった際に、入札履歴を参照して有効な入札の中から仮落札者を決定する手段、
決定された仮落札者を呼び出す手段、
仮落札者の認証を行って落札を確定し、上記ゲーム機をプレイ可能状態にする手段、
として機能させることを特徴とするゲーム機プレイ料金設定制御プログラム。
【請求項１９】
ゲーム機のプレイ料金を決定して決済を行うシステムの制御プログラムであって、
コンピュータを、
当該システムが提示する金額による上記ゲーム機の利用に対する入札を受け付け、入札内容を入札履歴として記憶する手段、
記憶された入札履歴を表示する手段、
上記ゲーム機が空き状態になった際に、入札履歴を参照して有効な入札の中から入札した順に仮落札者を決定する手段、
決定された仮落札者を呼び出す手段、
仮落札者の認証を行って落札を確定し、上記ゲーム機をプレイ可能状態にする手段、
として機能させることを特徴とするゲーム機遊戯順序設定制御プログラム。
【請求項２０】
ゲーム機のプレイ料金を決定して決済を行うシステムの制御プログラムであって、
コンピュータを、
上記ゲーム機の稼動時間を示すデータを取得し、稼動履歴として記憶する手段、
記憶された稼動履歴に基づいて稼動率を計算する手段、
計算された稼動率に基づいて所定の演算処理によりプレイ料金を計算する手段、
計算されたプレイ料金を表示する手段、
表示されたプレイ料金の支払を受け付けて決済を行い、上記ゲーム機をプレイ可能状態にする手段、
上記ゲーム機の利用に対する入札を受け付け、入札内容を入札履歴として記憶する手段、
記憶された入札履歴を表示する手段、
上記ゲーム機が空き状態になった際に、入札履歴を参照して有効な入札の中から仮落札者を決定する手段、
決定された仮落札者を呼び出す手段、
仮落札者の認証を行って落札を確定し、上記ゲーム機をプレイ可能状態にする手段、
として機能させることを特徴とするゲーム機プレイ料金設定制御プログラム。
【請求項２１】
請求項１７に記載のゲーム機プレイ料金設定制御プログラムを記録したコンピュータ読み取り可能のゲーム機プレイ料金設定制御プログラム記録媒体。
【請求項２２】
請求項１８に記載のゲーム機プレイ料金設定制御プログラムを記録したコンピュータ読み取り可能のゲーム機プレイ料金設定制御プログラム記録媒体。
【請求項２３】
請求項１９に記載のゲーム機遊戯順序設定制御プログラムを記録したコンピュータ読み取り可能のゲーム機遊戯順序設定制御プログラム記録媒体。
【請求項２４】
請求項２０に記載のゲーム機プレイ料金設定制御プログラムを記録したコンピュータ読み取り可能のゲーム機プレイ料金設定制御プログラム記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ゲーム機の利用時におけるプレイ料金の決済技術に関する。
【背景技術】
【０００２】
アミューズメント施設に設置される各種のゲーム機は、払い出しが行われるもの（法規制により現金の払い出しが行えないため、換金不能のメダル等を使用）を除き、プレイ料金の支払は硬貨で行うのが一般的である。プレイ料金は、例えば「１プレイ  １００円」といったように固定となっている。
【０００３】
昨今では、決済手段多様化のニーズに応えるべく、電子マネーにより決済が行えるゲーム機も存在する（例えば、特許文献１参照。）。特許文献１には、ゲームプレイ成績等の遊戯履歴によって決済内容（引き落とし額、返還額等）を変更する技術が開示されているが、遊戯履歴がないか、あっても同等のプレイヤ間についていえば、プレイ料金は固定となっている。
【特許文献１】特開２００５−８５１６２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
上述したように、従来のゲーム機ではプレイ料金が固定となっていたため、次のような問題点が指摘されていた。
（１）人気の高いゲーム機は常に使用状態となっており、プレイしたいと思ってもプレイすることができず、プレイヤの期待に応えられない。
（２）反対に、リリースして時間が経ったゲーム機は人気が落ち、空き状態であることが多く、収益が上がらない。また、空いていることでプレイをしようとしても、設定金額が高く設定されていると、プレイヤがプレイすることを躊躇することが考えられる。
（３）ゲーム機毎に料金設定を変えることでプレイヤを誘導することができるが、適当なタイミングに手動で料金設定を変える作業はアミューズメント施設の担当者に負担がかかる。
（４）延いては、個々のゲーム機の稼働率にアンバランスが生じ、アミューズメント施設全体の収益率の低下につながる。
【０００５】
本発明は上記の従来の問題点に鑑み提案されたものであり、その目的とするところは、ゲーム機の稼動状況もしくはプレイ希望者からの入札状況に応じて料金設定を適切に変化させることのできるゲーム機プレイ料金設定システムおよびゲーム機遊戯順序設定システムを提供することにある。
【課題を解決するための手段】
【０００６】
上記の課題を解決するため、本発明にあっては、請求項１に記載されるように、ゲーム機のプレイ料金を決定して決済を行うシステムであって、上記ゲーム機の稼動時間を示すデータを取得し、稼動履歴として記憶する手段と、記憶された稼動履歴に基づいて稼動率を計算する手段と、計算された稼動率に基づいて所定の演算処理によりプレイ料金を計算する手段と、計算されたプレイ料金を表示する手段と、表示されたプレイ料金の支払を受け付けて決済を行い、上記ゲーム機をプレイ可能状態にする手段とを備えるゲーム機プレイ料金設定システムを要旨としている。
【０００７】
また、請求項２に記載されるように、請求項１に記載のゲーム機プレイ料金設定システムにおいて、単一の上記ゲーム機について、当該ゲーム機に直接接続された決済端末により上記各手段の処理を行うようにすることができる。
【０００８】
また、請求項３に記載されるように、請求項１に記載のゲーム機プレイ料金設定システムにおいて、複数の上記ゲーム機について、当該ゲーム機毎に直接接続された複数の決済端末およびネットワークを介して接続されたサーバにより上記各手段の処理を行うようにすることができる。
【０００９】
また、請求項４に記載されるように、請求項１に記載のゲーム機プレイ料金設定システムにおいて、単一の上記ゲーム機について、当該ゲーム機に接続された複数の決済端末およびネットワークを介して接続されたサーバにより上記各手段の処理を行うようにすることができる。
【００１０】
また、請求項５に記載されるように、請求項１乃至４のいずれか一項に記載のゲーム機プレイ料金設定システムにおいて、ゲーム時間が一定でない場合に、ゲーム開始時刻とゲーム終了時刻を上記ゲーム機の稼動時間を示すデータとして稼動履歴に含めるようにすることができる。
【００１１】
また、請求項６に記載されるように、請求項１乃至４のいずれか一項に記載のゲーム機プレイ料金設定システムにおいて、ゲーム時間が一定とみなせる場合に、上記ゲーム機をプレイ可能状態にする支払通知時刻を上記ゲーム機の稼動時間を示すデータとして稼動履歴に含めるようにすることができる。
【００１２】
また、請求項７に記載されるように、ゲーム機のプレイ料金を決定して決済を行うシステムであって、上記ゲーム機の利用に対する入札を受け付け、入札内容を入札履歴として記憶する手段と、記憶された入札履歴を表示する手段と、上記ゲーム機が空き状態になった際に、入札履歴を参照して有効な入札の中から仮落札者を決定する手段と、決定された仮落札者を呼び出す手段と、仮落札者の認証を行って落札を確定し、上記ゲーム機をプレイ可能状態にする手段とを備えるゲーム機プレイ料金設定システムとして構成することができる。
【００１３】
また、請求項８に記載されるように、請求項７に記載のゲーム機プレイ料金設定システムにおいて、単一の上記ゲーム機について、当該ゲーム機に直接接続された決済端末により上記各手段の処理を行うようにすることができる。
【００１４】
また、請求項９に記載されるように、請求項７に記載のゲーム機プレイ料金設定システムにおいて、複数の上記ゲーム機について、当該ゲーム機毎に直接接続された複数の決済端末およびネットワークを介して接続されたサーバにより上記各手段の処理を行うようにすることができる。
【００１５】
また、請求項１０に記載されるように、請求項７に記載のゲーム機プレイ料金設定システムにおいて、単一の上記ゲーム機について、当該ゲーム機毎に接続された複数の決済端末およびネットワークを介して接続されたサーバにより上記各手段の処理を行うようにすることができる。
【００１６】
また、請求項１１に記載されるように、ゲーム機のプレイ料金を決定して決済を行うシステムであって、当該システムが提示する金額による上記ゲーム機の利用に対する入札を受け付け、入札内容を入札履歴として記憶する手段と、記憶された入札履歴を表示する手段と、上記ゲーム機が空き状態になった際に、入札履歴を参照して有効な入札の中から入札した順に仮落札者を決定する手段と、決定された仮落札者を呼び出す手段と、仮落札者の認証を行って落札を確定し、上記ゲーム機をプレイ可能状態にする手段とを備えるゲーム機遊戯順序設定システムとして構成することができる。
【００１７】
また、請求項１２に記載されるように、ゲーム機のプレイ料金を決定して決済を行うシステムであって、上記ゲーム機の稼動時間を示すデータを取得し、稼動履歴として記憶する手段と、記憶された稼動履歴に基づいて稼動率を計算する手段と、計算された稼動率に基づいて所定の演算処理によりプレイ料金を計算する手段と、計算されたプレイ料金を表示する手段と、表示されたプレイ料金の支払を受け付けて決済を行い、上記ゲーム機をプレイ可能状態にする手段と、上記ゲーム機の利用に対する入札を受け付け、入札内容を入札履歴として記憶する手段と、記憶された入札履歴を表示する手段と、上記ゲーム機が空き状態になった際に、入札履歴を参照して有効な入札の中から仮落札者を決定する手段と、決定された仮落札者を呼び出す手段と、仮落札者の認証を行って落札を確定し、上記ゲーム機をプレイ可能状態にする手段とを備えるゲーム機プレイ料金設定システムとして構成することができる。
【００１８】
また、請求項１３〜１６に記載されるように、ゲーム機プレイ料金設定制御方法もしくはゲーム機遊戯順序設定制御方法として構成することができる。
【００１９】
また、請求項１７〜２０に記載されるように、ゲーム機プレイ料金設定制御プログラムもしくはゲーム機遊戯順序設定制御プログラムとして構成することができる。
【００２０】
また、請求項２１〜２４に記載されるように、ゲーム機プレイ料金設定制御プログラム記録媒体もしくはゲーム機遊戯順序設定制御プログラム記録媒体として構成することができる。
【発明の効果】
【００２１】
本発明にあっては、ゲーム機の稼動状況もしくはプレイ希望者からの入札状況に応じて料金設定を適切に変化させることができ、ゲーム機の稼働率を向上させてアミューズメント施設全体の収益率の改善に寄与することができる。
【発明を実施するための最良の形態】
【００２２】
以下、本発明の好適な実施形態につき説明する。
【００２３】
＜システム構成＞
図１は本発明の一実施形態にかかるゲーム機および決済端末の構成例を示す図である。
【００２４】
図１において、ゲーム機１には支払通知ケーブル２１および状態通信ケーブル２２を介して決済端末３が接続されている。スタンドアロン構成の場合は、このゲーム機１と決済端末３で処理が完結される。
【００２５】
ゲーム機１にはゲーム利用時に支払を受け付けコインの投入を監視する支払部１１とゲームを実行するゲーム制御部１２が存在し、従来は、この支払部１１に支払があったときに、支払部１１より支払通知の信号がゲーム制御部１２に送信され、支払通知を受けたゲーム制御部１２はゲームプログラムを実行し、プレイヤの操作入力に応じてゲームの進行を制御する。本願の決済端末３は、支払部３２３に支払があったときには、支払通知ケーブル２１からゲーム機１の支払部１１を介してゲーム制御部１２に支払通知を送信し、支払通知を受けたゲーム制御部１２はゲームプログラムを実行し、プレイヤの操作入力に応じてゲームの進行を制御する。また、支払部１１にコインの投入枚数を数えるカウンタが付いている場合、支払通知ケーブル２１を介して送信された支払通知があった際に投入されたコイン相当分、カウンタが進むステップを設けてもよい。
【００２６】
支払通知ケーブル２１は、決済端末３で支払があったときに、そのことをゲーム機１に通知するために使用される。支払通知ケーブル２１はゲーム機１の既存の支払部１１に接続され、支払部１１に支払があったことを通知する。状態通信ケーブル２２は、ゲーム機１と決済端末３とが互いの情報を送受信し、両者が協調して動作するために使用される。状態通信ケーブル２２はゲーム機１のゲーム制御部１２に接続されている。ゲーム機１から決済端末３に通知される主な情報には、ゲーム開始、ゲーム終了、ゲーム終了見込み等がある。なお、有線の支払通知ケーブル２１に代えて無線により支払通知信号を決済端末３からゲーム機１に送信するようにしてもよく、同様に有線の状態通信ケーブル２２に変えて無線により状態通信信号をゲーム機１と決済端末３とでやり取りするようにしてもよい。
【００２７】
また、決済端末３の支払部３２３に対して支払があり、支払通知ポート３２４から送信される支払通知は、支払通知ケーブル２１からゲーム機１の支払部１１を介してゲーム制御部１２に支払通知を行なってもよいし、支払部１１に支払通信を送信するステップを省略して、支払通知ケーブル２１からゲーム制御部１２に対して直接支払通知を送信してもよい。
【００２８】
ゲーム機１については、決済端末３との処理に関係する支払部１１とゲーム制御部１２のみを図示し、他の構成については省略してあるが、ゲーム機の種類に応じた様々な構成要素が存在する。
【００２９】
決済端末３は、決済端末３の全体的な制御を行う制御部３１と、外部とのデータ入出力を行う入出力部３２とを備えている。制御部３１は、コンピュータプログラムに従って演算処理等を行うＣＰＵ（Central Processing Unit）３１１と、作業中のデータを記憶するＲＡＭ（Random Access Memory）３１２と、固定的なプログラムやデータを記憶するＲＯＭ（Read Only Memory）３１３と、決済端末３の各種の設定情報（後述する料金テーブルを含む）や履歴情報（支払履歴や後述する稼動履歴、入札履歴を含む）等を記憶する不揮発メモリ３１４と、現在時刻を取得するためのタイマ３１５とを備えている。ＣＰＵ３１１はＲＯＭ３１３に保存されているプログラムを実行することにより決済端末３全体の制御を行う。
【００３０】
入出力部３２は、ゲーム機１でのプレイ料金や支払操作の説明等を表示するディスプレイ３２１と、支払を行う電子マネーの種類選択、残高照会、支払などの操作を行うためのボタン３２２と、ＩＣカードリーダライタ（電子マネーの場合）、磁気カードリーダライタ（磁気式プリペイドカードの場合）、コインシュータ（メダル・硬貨の場合）等により支払を受け付ける支払部３２３とを備えている。なお、ボタン３２２は汎用的にそのときどきに応じて押されたときの機能を割り当てることができ、機能の割り当て状態はディスプレイ３２１等に表示される。また、このシステムでは細かい金額での取引が増加することが予想されるため、電子マネーでの支払とするのが好ましい。しかし、電子マネーを持たないプレイヤの利便性を考えた場合、硬貨や、店内において硬貨と同様の価値を持つメダル、プリペイドカード等で決済を行えることが望ましいため、特に電子マネーに限定されるものではない。
【００３１】
また、入出力部３２は、支払通知ケーブル２１を介してゲーム機１に支払通知を出力するための支払通知ポート３２４と、状態通信ケーブル２２を介してゲーム機１と通信を行うための状態通信ポート３２５と、ネットワーク接続する場合（電子マネーの種類によってはその取引履歴を電子マネー業者のサーバへ送信するために必須となる場合があるほか、後述するネットワーク型の場合に使用）にネットワークを介して通信を行うためのネットワーク通信ポート３２６とを備えている。
【００３２】
図２は決済端末３のパネル外観の例を示す図であり、上部にディスプレイ３２１が配置され、その下に複数のボタン３２２が配置され、その下に支払部３２３が配置されている。なお、支払部３２３はＩＣカードリーダライタを想定して図示してあるが、形状は図示のものに限られない。コインシュータの場合はコインの投入口やコイン返却ボタン等が支払部３２３に付加される。
【００３３】
図３はネットワーク型の場合におけるサーバの構成例を示す図である。
【００３４】
図３において、ゲーム機１および決済端末３の構成と相互の接続状態は図１に示したものと同様であり、このゲーム機１と決済端末３を１セットとして、複数のセットから各決済端末３のネットワーク通信ポート３２６（図１）を介してネットワーク４に接続されている。なお、決済端末３に接続されているゲーム機１の種類はすべて同じでもよいし、それぞれ異なっていてもよい。また、ゲーム機１と接続されない単独の決済端末３がネットワーク４に接続されていてもよい。
【００３５】
一方、ネットワーク４には料金設定ならびに遊戯順序設定の処理の主たる制御を行うサーバ５が接続されている。サーバ５は、サーバ５の全体的な制御を行う制御部５１と、ハードディスク等からなる補助記憶装置５２と、ネットワーク４を介した通信を行うためのネットワーク通信ポート５３とを備えている。制御部５１は、コンピュータプログラムに従って演算処理等を行うＣＰＵ５１１と、作業中のデータを記憶するＲＡＭ５１２と、固定的なプログラムやデータを記憶するＲＯＭ５１３と、各種の設定情報（後述する料金テーブルを含む）や支払履歴、入札履歴等を記憶する不揮発メモリ５１４と、現在時刻を取得するためのタイマ５１５とを備えている。
【００３６】
＜処理パターン＞
本願に関連する料金設定ならびに遊戯順序設定の処理を「オークション」という表現に置き換えて説明する。
【００３７】
本発明の実施形態における処理パターンは、
（１）パッシブオークション
（２）アクティブオークション
に大別される。
【００３８】
パッシブオークションは、ゲーム機１の稼働率に応じてゲーム機１のプレイ料金を決定するものである。プレイヤがゲーム機１を選別して利用する行為を一種の入札ととらえ、パッシブオークションと命名している。アクティブオークションは、ゲーム機１のプレイ料金をプレイヤ主導のオークション方式で決定するものである。積極的なオークションであるため、アクティブオークションと命名している。
【００３９】
また、パッシブオークションとアクティブオークションのいずれも、スタンドアロン型とネットワーク型に大別される。更に、パッシブオークションはゲーム時間不定の場合とゲーム時間一定（厳密な一定という意味ではなく、ほぼ一定とみなせるということ）の場合に大別される。
【００４０】
以下、個々のパターンにつき動作を説明する。
【００４１】
＜動作：パッシブオークション／スタンドアロン型／ゲーム時間不定＞
システム構成としては、図１に示したものが前提となる。
【００４２】
図４はパッシブオークションのスタンドアロン型でゲーム時間が一定でない場合における処理例を示すフローチャートである。
【００４３】
図４において、決済端末３の制御部３１は電源投入もしくは電源投入後のゲーム機１からのプレイ可能状態（状態通信ポート３２５を介してゲーム機１より取得）の確認により処理を開始すると（ステップＳ１０１）、ディスプレイ３２１にプレイ料金を表示する（ステップＳ１０２）。初期状態では稼働率に基づくプレイ料金が計算されていないため、不揮発メモリ３１４に設定情報として予め記憶された初期プレイ料金を表示する。この料金表示を見た上で、ゲーム機１でプレイしたいプレイヤ（現在の料金を了承したプレイヤ）は決済端末３を操作して支払を行うことになる。支払に際し、制御部３１はボタン３２２からの入力に応じてディスプレイ３２１や支払部３２３を制御し、支払操作を制御する。
【００４４】
次いで、決済端末３の制御部３１は支払部３２３によりプレイ料金の支払操作が行われたか否か判断し（ステップＳ１０３）、支払われたと判断した場合（ステップＳ１０３のＹｅｓ）は支払通知ポート３２４から支払通知ケーブル２１を介してゲーム機１に支払通知を行う（ステップＳ１０４）。ゲーム機１に支払通知が行われることで、プレイヤはゲーム機１でゲームをプレイすることができるようになる。支払われたと判断しなかった場合（ステップＳ１０３のＮｏ）は特に処理をせずに次の処理に移行する。
【００４５】
次いで、決済端末３の制御部３１はゲーム機１から状態通信ポート３２５を介してゲーム開始もしくはゲーム終了の通知を受けたか否か判断し（ステップＳ１０５）、受けたと判断した場合（ステップＳ１０５のＹｅｓ）は不揮発メモリ３１４に稼動履歴としてゲーム開始時刻もしくはゲーム終了時刻を記憶する（ステップＳ１０６）。ゲーム開始もしくはゲーム終了の通知を受けたと判断しなかった場合（ステップＳ１０５のＮｏ）は特に処理をせずに次の処理に移行する。
【００４６】
稼動履歴は、不揮発メモリ３１４を無駄にしないために、全ての稼動履歴を保存するのではなく、ある一定期間を経た過去の記録は削除される。たとえば、現在時刻より３時間前の稼動履歴のみを記憶する方法、あるいは装置の起動開始時刻以降の稼動履歴のみを記録し、日々装置が起動されるたびに記憶を刷新する方法などが考えられる。また、経過時間に対応した全てのデータを記憶することは不揮発メモリ３１４が無駄になるため、稼動していない時間についてはリングメモリとして随時上書きして記録するなどの対応を取ってもよい。
【００４７】
次いで、決済端末３の制御部３１は不揮発メモリ３１４に記憶された稼動履歴に基づいて稼働率を計算する（ステップＳ１０７）。稼働率の計算の詳細については後述する。
【００４８】
次いで、決済端末３の制御部３１は計算された稼働率に基づいて不揮発メモリ３１４に記憶された料金テーブルを参照してプレイ料金を取得する（ステップＳ１０８）。そして、現在のプレイ料金を取得したプレイ料金に変更し（ステップＳ１０９）、料金表示（ステップＳ１０２）に移行する。その後も、ゲーム機１および決済端末３が動作している間は同様の処理を繰り返す。
【００４９】
図５は上記の処理におけるデータの流れの例を示す図であり、図４と対応する処理には同じ符号（ステップ番号）を付してある。
【００５０】
決済端末３では、ゲーム機１からのゲーム開始もしくはゲーム終了の状態通知に基づき、稼動履歴を記憶する（ステップＳ１０５、Ｓ１０６）。ゲーム開始の状態通知の場合は、その時点の時刻をタイマ３１５から取得してゲーム開始時刻として記憶する。ゲーム終了の状態通知の場合は、その時点の時刻をタイマ３１５から取得してゲーム終了時刻として記憶する。このゲーム開始時刻とゲーム終了時刻の稼動履歴の組み合わせから稼働率を計算する際には、現在の時刻から一定時間さかのぼった時刻Ｔ0から現在の時刻Ｔまでに含まれる０件以上ｎ件の稼働率の組み合せを参照し、Ｔ0またはＴが稼動履歴のゲーム開始とゲーム終了の間にかかる場合、稼動履歴は適切にＴ0またはＴでクリップして使用するものとする。時間が経った古い稼動履歴を稼働率の計算に含めた場合、必ずしも現在の稼働率を適切に表しているとは言い難くなるため、記憶してから時間が経った古い稼動履歴は稼働率の計算から適度に除外する。Ｔ0は稼働率があまりめまぐるしく変化しないように選ぶことが望ましく、ゲーム機１を営業に使用する者が設定できるようにしてもよい。また、Ｔ0が定められた一定時間に満たない場合は、稼働率の変動が激しくなるため、別途設定された料金設定するステップ（「新たな料金設定テーブルを呼び出すステップ」あるいは「定額を提示するステップ」等）を用意し、その代わりとして用いてもよい。
【００５１】
稼働率の計算（ステップＳ１０７）にあっては、ｎ件の稼動履歴から、ゲーム開始時刻をＴｓ、ゲーム終了時刻をＴｅ、現在の時刻をＴ、現時の時刻から一定時間さかのぼった時刻をＴ0としたとき、稼働率Ａは、
Ａ＝（（Ｔｅ(０)−Ｔｓ(０)）＋（Ｔｅ(１)−Ｔｓ(１)）
＋・・・＋（Ｔｅ(ｎ−１)−Ｔｓ(ｎ−１)））／（Ｔ−Ｔ0）
により求めることができる。ここで、括弧内は稼動履歴のインデックスを示しており、Ｔｓ(０)、Ｔｅ(０)が稼働率の計算に使う最も新しい稼動履歴であり、Ｔｓ(ｎ−１)、Ｔｅ(ｎ−１)が稼働率の計算に使う最も古い稼動履歴である。現在の時刻Ｔは計算時点においてタイマ３１５から取得し、Ｔ0はＴから一定時間を減算して決定する。
【００５２】
料金テーブルの参照（ステップＳ１０８）にあっては、図示のような、稼働率を一定の範囲で区切り、その範囲ごとに料金を設定した料金テーブルの場合、上で求めた稼動率Ａがどの範囲に入るか調べ、対応する料金を取得する。なお、簡単で実用的な例として図示の構造の料金テーブルとしたが、料金テーブルの構造は図示のものに限られない。料金テーブルは決済端末３を使用して営業を行う者の都合で任意に設定してよいが、一般的には、稼働率が低い場合は料金が定価よりも安くなるように、稼働率が高い場合は料金が定価になるように、稼働率が極めて高い場合は料金が定価より少し高くなるように設定すると、稼働率に応じた適正な収入を得られることが期待できる。
【００５３】
また、上記の稼働率から料金テーブルを参照して料金を決定する方法はあくまでも一例であり、種々の例外的処理を行うことができる。例えば、コンティニューにより継続してゲームをプレイできる場合、ゲーム機からコンティニュー待ちの状態通知を受けた場合は、営業を行う者の設定により次のいずれかの料金を選択することができる。
・常に定価
・一旦ゲーム終了とみなし現在の稼働率により料金を再決定
・ゲームがまだ終了していないとみなしゲーム開始時の料金を適用
また、最初にコンティニュー回数を入力して継続してゲームを実施できる場合や、２人同時プレイなどゲーム開始時に複数回分のプレイ料金の支払を一度に行うケースがある場合は、営業を行うものが設定しておいた支払数毎の料金テーブルを参照することもできるなど、稼働率の計算方法や料金決定の方法は適宜変更することが可能である。
【００５４】
ゲーム機１でプレイしているプレイヤがいるときに料金が変動するのが好ましくない場合は、ゲーム中は稼働率の計算を休止して料金が変動しないようにし、支払の先払いも受付けないようにするなどの対策を採るようにする。
【００５５】
また、稼働率の計算時点でゲーム機１が空き状態である場合、上記の式で求めた稼働率とは別に、あと一定の時間ゲーム機が稼動しない状態が続くと仮定して稼働率を計算し、この稼働率による料金テーブルの参照の結果、現在の稼働率での料金と異なる場合には、まもなく料金が変更になることをディスプレイ３２１に表示するようにしてもよい。
【００５６】
図６は決済端末３におけるユーザインタフェースの例を示す図であり、（ａ）はディスプレイ３２１に「１プレイ￥９０（定価￥１００）」と表示された状態を示している。また、ディスプレイ３２１の下部には、ボタン３２２の機能の割り当てが表示されている。この表示を見てプレイしてみようと思ったプレイヤは、ボタン３２２の左端の「支払」ボタンを押し、ディスプレイ３２１への所定の説明等の表示（図示せず）に続いて、支払部３２３に電子マネーカードを近づける等により、支払が完了する。
【００５７】
（ｂ）は現在の料金表示「１プレイ￥９０（定価￥１００）」に加え、「あと１分で￥８０」との予告をディスプレイ３２１に表示するようにしたものである。値下げ予告をすることで施設運営者側の収益は減益となるため不利に作用するとも思えるが、値下げがあれば、新規のゲームをプレイしようとしているプレイヤに対しては歓迎され、全体的には稼働率向上に寄与するものと期待される。また、このような予告の方法としては、常に予告を表示するとゲームをプレイすることなく着席だけをしてゲーム機を占有するプレイヤが出てくると予想され、この値段であればプレイしてもかまわないと思っているプレイヤの阻害に当たる行為を行なう者がいる可能性があるため、予告は値段が変更になる直前(例えば1分前よりカウントダウンを開始する等)に表示してもよい。
【００５８】
＜動作：パッシブオークション／スタンドアロン型／ゲーム時間一定＞
ゲームの種類により１回のゲーム時間がだいたい一定であるとみなせる場合は、ゲーム開始時刻がわかればゲーム終了時刻がわかる。更に、ゲーム開始時刻は支払通知のタイミング（支払時刻）と同等とみなせるため、支払時刻をもって稼動履歴とすることができる。従って、ゲーム機１からのゲーム開始とゲーム終了の通知についての処理を省略し、処理の簡略化を図ることができる。
【００５９】
システム構成としては、図１に示したものが前提となる。
【００６０】
図７はパッシブオークションのスタンドアロン型でゲーム時間が一定とみなせる場合における処理例を示すフローチャートである。
【００６１】
図７において、決済端末３の制御部３１は電源投入もしくは電源投入後のゲーム機１からのプレイ可能状態（状態通信ポート３２５を介してゲーム機１より取得）の確認により処理を開始すると（ステップＳ１１１）、ディスプレイ３２１にプレイ料金を表示する（ステップＳ１１２）。初期状態では稼働率に基づくプレイ料金が計算されていないため、不揮発メモリ３１４に設定情報として予め記憶された初期プレイ料金を表示する。この料金表示を見た上で、ゲーム機１でプレイしたいプレイヤ（現在の料金を了承したプレイヤ）は決済端末３を操作して支払を行うことになる。支払に際し、制御部３１はボタン３２２からの入力に応じてディスプレイ３２１や支払部３２３を制御し、支払操作を制御する。
【００６２】
次いで、決済端末３の制御部３１は支払部３２３によりプレイ料金の支払操作が行われたか否か判断し（ステップＳ１１３）、支払われたと判断した場合（ステップＳ１１３のＹｅｓ）は支払通知ポート３２４から支払通知ケーブル２１を介してゲーム機１に支払通知を行う（ステップＳ１１４）。ゲーム機１に支払通知が行われることで、プレイヤはゲーム機１でゲームをプレイすることができるようになる。支払通知（ステップＳ１１４）を行った後、決済端末３の制御部３１は不揮発メモリ３１４に稼動履歴として支払時刻を記憶する（ステップＳ１１５）。支払われたと判断しなかった場合（ステップＳ１１３のＮｏ）は特に処理をせずに次の処理に移行する。
【００６３】
次いで、決済端末３の制御部３１は不揮発メモリ３１４に記憶された稼動履歴に基づいて稼働率を計算する（ステップＳ１１６）。稼働率の計算の詳細については後述する。
【００６４】
次いで、決済端末３の制御部３１は計算された稼働率に基づいて不揮発メモリ３１４に記憶された料金テーブルを参照してプレイ料金を取得する（ステップＳ１１７）。そして、現在のプレイ料金を取得したプレイ料金に変更し（ステップＳ１１８）、料金表示（ステップＳ１１２）に移行する。その後も、ゲーム機１および決済端末３が動作している間は同様の処理を繰り返す。
【００６５】
図８は上記の処理におけるデータの流れの例を示す図であり、図７と対応する処理には同じ符号（ステップ番号）を付してある。
【００６６】
決済端末３では、当該決済端末３での支払操作に基づき、支払通知を行う時点の時刻をタイマ３１５から取得し、稼動履歴として支払時刻を記憶する（ステップＳ１１５）。
【００６７】
稼働率の計算（ステップＳ１１６）にあっては、現在の時刻から一定時間さかのぼった時刻Ｔ0から現在の時刻Ｔまでに含まれる０件以上ｎ件の稼動履歴（Ｔ0またはＴが稼動履歴のゲーム開始とゲーム終了の間にかかる場合、稼動履歴は適切にＴ0またはＴでクリップして使用）から、支払時刻をＴｐ、ゲーム１回の平均的な時間をＧとしたとき、稼働率Ａは、「パッシブオークション／スタンドアロン型／ゲーム時間不定」の動作における稼働率Ａを求める式において、
Ｔｓ()＝Ｔｐ()
Ｔｅ()＝Ｔｐ()＋Ｇ
とすることで計算できる。
【００６８】
すなわち、稼働率Ａは、
Ａ＝（（Ｔｐ(０)＋Ｇ−Ｔｐ(０)）＋（Ｔｐ(１)＋Ｇ−Ｔｐ(１)）
＋・・・＋（Ｔｐ(ｎ−１)＋Ｇ−Ｔｐ(ｎ−１)））／（Ｔ−Ｔ0）
＝（Ｇ×ｎ）／（Ｔ−Ｔ0）
により求めることができる。ここで、括弧内は稼動履歴のインデックスを示しており、Ｔｐ(０)が稼働率の計算に使う最も新しい稼動履歴で、Ｔｐ(ｎ−１)が稼働率の計算に使う最も古い稼動履歴である。
【００６９】
料金テーブルの参照（ステップＳ１１７）にあっては、図示のような、稼働率を一定の範囲で区切り、その範囲ごとに料金を設定した料金テーブルの場合、上で求めた稼動率Ａがどの範囲に入るか調べ、対応する料金を取得する。なお、簡単で実用的な例として図示の構造の料金テーブルとしたが、料金テーブルの構造は図示のものに限られない。
【００７０】
＜動作：パッシブオークション／ネットワーク型／ゲーム時間不定＞
ネットワーク型の場合、個々のゲーム機単位ではなく、複数のゲーム機の稼動履歴から総合的な稼働率を求めることができる。例えば、１つのゲーム機で同時に複数人のプレイヤがプレイすることができる場合、プレイヤ毎に決済端末があることが望ましいが、スタンドアロン型の場合は決済端末ごとに稼働率を計算するため、同じゲーム機でプレイするにもかかわらず料金が異なるというケースが起こり得る。しかし、このネットワーク型の場合その問題を解決することができる。また、同じアミューズメント施設内のゲーム機をすべてサーバに接続すれば、ゲーム機ごとに稼働率が異なって全体として料金設定がバラバラになるのを防止することもできる。
【００７１】
システム構成としては、図３（ゲーム機１および決済端末３の構成については図１）に示したものが前提となる。
【００７２】
図９はパッシブオークションのネットワーク型でゲーム時間が一定でない場合における処理例を示すフローチャートである。
【００７３】
図９において、決済端末３の制御部３１は電源投入もしくは電源投入後のゲーム機１からのプレイ可能状態（状態通信ポート３２５を介してゲーム機１より取得）の確認により処理を開始すると（ステップＳ２０１）、ディスプレイ３２１にプレイ料金を表示する（ステップＳ２０２）。初期状態では稼働率に基づくプレイ料金が計算されていないため、不揮発メモリ３１４に設定情報として予め記憶された初期プレイ料金を表示する。この料金表示を見た上で、ゲーム機１でプレイしたいプレイヤ（現在の料金を了承したプレイヤ）は決済端末３を操作して支払を行うことになる。支払に際し、制御部３１はボタン３２２からの入力に応じてディスプレイ３２１や支払部３２３を制御し、支払操作を制御する。
【００７４】
次いで、決済端末３の制御部３１は支払部３２３によりプレイ料金の支払操作が行われたか否か判断し（ステップＳ２０３）、支払われたと判断した場合（ステップＳ２０３のＹｅｓ）は支払通知ポート３２４から支払通知ケーブル２１を介してゲーム機１に支払通知を行う（ステップＳ２０４）。ゲーム機１に支払通知が行われることで、プレイヤはゲーム機１でゲームをプレイすることができるようになる。支払われたと判断しなかった場合（ステップＳ２０３のＮｏ）は特に処理をせずに次の処理に移行する。
【００７５】
次いで、決済端末３の制御部３１はゲーム機１から状態通信ポート３２５を介してゲーム開始もしくはゲーム終了の通知を受けたか否か判断し（ステップＳ２０５）、受けたと判断した場合（ステップＳ２０５のＹｅｓ）は稼動履歴としてゲーム開始時刻もしくはゲーム終了時刻を決済端末３を特定する決済端末ＩＤとともにサーバ５に送信（アップロード）し（ステップＳ２０６）、サーバ５では不揮発メモリ５１４もしくは補助記憶装置５２にこれを記憶する（ステップＳ２０７）。このように、稼動履歴を逐次にサーバ５に送信して記憶させる場合には、決済端末３側に稼動履歴を記憶しておく必要はない。ゲーム開始もしくはゲーム終了の通知を受けたと判断しなかった場合（ステップＳ２０５のＮｏ）は特に処理をせずに次の処理に移行する。
【００７６】
次いで、決済端末３の制御部３１はサーバ５に対して決済端末ＩＤを伴ってプレイ料金の取得要求を送信する（ステップＳ２０８）。これを受けたサーバ５は、不揮発メモリ５１４もしくは補助記憶装置５２に記憶された稼動履歴に基づいて全体での稼働率を計算し（ステップＳ２０９）、その決済端末ＩＤと全体での稼働率とから不揮発メモリ５１４もしくは補助記憶装置５２に記憶された決済端末ＩＤに対応する料金テーブルを参照して要求があった決済端末のプレイ料金を取得し（ステップＳ２１０）、決済端末３に送信する（ステップＳ２１１）。なお、決済端末ＩＤ毎に対応する料金テーブルが異なる場合と、複数の決済端末ＩＤが共通の料金テーブルに対応する場合（同じ種類のゲーム機の場合等）とがある。
【００７７】
決済端末３はサーバ５からプレイ料金を受信すると（ステップＳ２１２）、現在のプレイ料金を取得したプレイ料金に変更し（ステップＳ２１３）、料金表示（ステップＳ２０２）に移行する。その後も、ゲーム機１、決済端末３およびサーバ５が動作している間は同様の処理を繰り返す。
【００７８】
図１０は上記の処理におけるデータの流れの例を示す図であり、図９と対応する処理には同じ符号（ステップ番号）を付してある。
【００７９】
決済端末３では、ゲーム機１からのゲーム開始もしくはゲーム終了の状態通知に基づき、稼動履歴をサーバ５に送信し（ステップＳ２０６）、サーバ５はこれを記憶する（ステップＳ２０７）。稼動履歴は、決済端末ＩＤ、ゲーム開始時刻、ゲーム終了時刻からなる。
【００８０】
稼働率の計算（ステップＳ２０９）にあっては、「パッシブオークション／スタンドアロン型／ゲーム時間不定」の動作において説明したのと同様の式により稼働率を計算する。この際、決済端末ＩＤ毎に稼働率を計算し、この決済端末毎の稼働率の合計を決済端末の数で割ったものを全体での稼働率とする。
【００８１】
料金テーブルの参照（ステップＳ２１０）にあっては、図示のような、稼働率を一定の範囲で区切り、その範囲ごとに料金を設定した料金テーブルの場合、上で求めた稼動率Ａがどの範囲に入るか調べ、対応する料金を取得する。なお、簡単で実用的な例として図示の構造の料金テーブルとしたが、料金テーブルの構造は図示のものに限られない。
【００８２】
なお、ネットワーク負荷等の制約によりサーバ５に稼動履歴をアップロードする頻度を下げたい場合は、稼動履歴がある程度溜まるまではスタンドアロン型のときと同様に決済端末３で稼動履歴を記憶しておき、ある程度稼動履歴が溜まってからまとめてサーバ５にアップロードするようにすることができる。
【００８３】
この際、図１１に示すように、最も新しいゲーム開始時刻をＴｓ(０)、ゲーム終了時刻をＴｅ(０)、計算に使う最も古いゲーム開始時刻をＴｓ(ｎ−１)、ゲーム終了時刻をＴｅ(ｎ−１)、サーバ５にアップロードした時刻をＴｕ、サーバ５にアップロード済の最も新しいゲーム開始時刻をＴｓ(ｉ)、ゲーム終了時刻をＴｅ(ｉ)、サーバ５から取得した稼働率をＡｓ、現在の時刻をＴ、現在の時刻から一定時間さかのぼった時刻をＴ0とすると、決済端末３がまだサーバ５にアップロードしていない稼動履歴による稼動率Ａｐは、
Ａｐ＝｛（Ｔｅ(０)−Ｔｓ(０)）＋・・・＋（Ｔｅ(ｉ＋１)−Ｔｓ(ｉ＋１)）｝
／（Ｔ−Ｔｕ）
となり、これに稼働率Ａｓを加味した全体の稼働率Ａは、
Ａ＝Ａｓ×｛（Ｔｕ−Ｔ0）／（Ｔ−Ｔ0）｝
＋Ａｐ×｛（Ｔ−Ｔｕ）／（Ｔ−Ｔ0）｝
となる。なお、サーバ５と決済端末３とで稼働率を計算するときに現在の時刻から過去のどの時刻まで稼動履歴を遡って計算に使用するかが決まっているものとする。
【００８４】
上記の稼働率Ａの式の右辺の第１項はサーバ５で計算した稼働率Ａｓを全計算時間下に換算したものであり、第２項は決済端末３で保持する稼動履歴から全計算時間下の稼働率への寄与分を示したものである。
【００８５】
＜動作：パッシブオークション／ネットワーク型／ゲーム時間一定＞
ゲームの種類により１回のゲーム時間がだいたい一定であるとみなせる場合は、ゲーム開始時刻がわかればゲーム終了時刻がわかる。更に、ゲーム開始時刻は支払通知のタイミング（支払時刻）と同等とみなせるため、支払時刻をもって稼動履歴とすることができる。従って、ゲーム機１からのゲーム開始とゲーム終了の通知についての処理を省略し、処理の簡略化を図ることができる。
【００８６】
システム構成としては、図３（ゲーム機１および決済端末３の構成については図１）に示したものが前提となる。
【００８７】
図１２はパッシブオークションのネットワーク型でゲーム時間が一定とみなせる場合における処理例を示すフローチャートである。
【００８８】
図１２において、決済端末３の制御部３１は電源投入もしくは電源投入後のゲーム機１からのプレイ可能状態（状態通信ポート３２５を介してゲーム機１より取得）の確認により処理を開始すると（ステップＳ２２１）、ディスプレイ３２１にプレイ料金を表示する（ステップＳ２２２）。初期状態では稼働率に基づくプレイ料金が計算されていないため、不揮発メモリ３１４に設定情報として予め記憶された初期プレイ料金を表示する。この料金表示を見た上で、ゲーム機１でプレイしたいプレイヤ（現在の料金を了承したプレイヤ）は決済端末３を操作して支払を行うことになる。支払に際し、制御部３１はボタン３２２からの入力に応じてディスプレイ３２１や支払部３２３を制御し、支払操作を制御する。
【００８９】
次いで、決済端末３の制御部３１は支払部３２３によりプレイ料金の支払操作が行われたか否か判断し（ステップＳ２２３）、支払われたと判断した場合（ステップＳ２２３のＹｅｓ）は支払通知ポート３２４から支払通知ケーブル２１を介してゲーム機１に支払通知を行う（ステップＳ２２４）。ゲーム機１に支払通知が行われることで、プレイヤはゲーム機１でゲームをプレイすることができるようになる。支払通知（ステップＳ２２４）を行った後、決済端末３の制御部３１は稼動履歴として支払時刻を決済端末３を特定する決済端末ＩＤとともにサーバ５に送信（アップロード）し（ステップＳ２２５）、サーバ５では不揮発メモリ５１４もしくは補助記憶装置５２にこれを記憶する（ステップＳ２２６）。このように、稼動履歴を逐次にサーバ５に送信して記憶させる場合には、決済端末３側に稼動履歴を記憶しておく必要はない。支払われたと判断しなかった場合（ステップＳ２２３のＮｏ）は特に処理をせずに次の処理に移行する。
【００９０】
次いで、決済端末３の制御部３１はサーバ５に対して決済端末ＩＤを伴ってプレイ料金の取得要求を送信する（ステップＳ２２７）。これを受けたサーバ５は、不揮発メモリ５１４もしくは補助記憶装置５２に記憶された稼動履歴に基づいて全体での稼働率を計算し（ステップＳ２２８）、その決済端末ＩＤと全体での稼働率とから不揮発メモリ５１４もしくは補助記憶装置５２に記憶された決済端末ＩＤに対応する料金テーブルを参照して要求があった決済端末のプレイ料金を取得し（ステップＳ２２９）、決済端末３に送信する（ステップＳ２３０）。なお、決済端末ＩＤ毎に対応する料金テーブルが異なる場合と、複数の決済端末ＩＤが共通の料金テーブルに対応する場合（同じ種類のゲーム機の場合等）とがある。
【００９１】
決済端末３はサーバ５からプレイ料金を受信すると（ステップＳ２３１）、現在のプレイ料金を取得したプレイ料金に変更し（ステップＳ２３２）、料金表示（ステップＳ２２２）に移行する。その後も、ゲーム機１、決済端末３およびサーバ５が動作している間は同様の処理を繰り返す。
【００９２】
図１３は上記の処理におけるデータの流れの例を示す図であり、図１２と対応する処理には同じ符号（ステップ番号）を付してある。
【００９３】
決済端末３では、当該決済端末３での支払操作に基づき、支払通知を行う時点の時刻をタイマ３１５から取得し、これに決済端末ＩＤを加え、稼動履歴としてサーバ５に送信し（ステップＳ２２５）、サーバ５はこれを記憶する（ステップＳ２２６）。稼動履歴は、決済端末ＩＤ、支払時刻からなる。
【００９４】
稼働率の計算（ステップＳ２２８）にあっては、「パッシブオークション／スタンドアロン型／ゲーム時間一定」の動作において説明したのと同様の式により稼働率を計算する。この際、決済端末ＩＤ毎に稼働率を計算し、この決済端末毎の稼働率の合計を決済端末の数で割ったものを全体での稼働率とする。
【００９５】
料金テーブルの参照（ステップＳ２２９）にあっては、図示のような、稼働率を一定の範囲で区切り、その範囲ごとに料金を設定した料金テーブルの場合、上で求めた稼動率Ａがどの範囲に入るか調べ、対応する料金を取得する。なお、簡単で実用的な例として図示の構造の料金テーブルとしたが、料金テーブルの構造は図示のものに限られない。
【００９６】
＜動作：アクティブオークション／スタンドアロン型＞
プレイヤがプレイしたい金額をオークション方式で入札することにより、より積極的に適正価格を決定できるようにしたものである。
【００９７】
システム構成としては、図１に示したものが前提となる。
【００９８】
図１４はアクティブオークションのスタンドアロン型における処理例を示すフローチャートであり、図１５はその際のデータの流れの例を示す図である。
【００９９】
図１４および図１５において、決済端末３の制御部３１は電源投入もしくは電源投入後のゲーム機１からのプレイ可能状態（状態通信ポート３２５を介してゲーム機１より取得）の確認により処理を開始すると（ステップＳ３０１）、ディスプレイ３２１に入札の条件となる最低料金と現在の入札状況を表示する（ステップＳ３０２）。初期状態では入札はなく、最低料金のみを表示する。なお、周期的に行われる処理であるため、入札が行われた後には入札状況が表示される。最低料金は不揮発メモリ３１４に予め設定情報として記憶させておく。入札状況の表示は決済端末３でプレイヤが操作を行っていないときに行われ、現在の入札状況を落札になる可能性が高い入札履歴から順にリストとしてディスプレイ３２１に表示することで、プレイヤが入札する場合の判断材料としてもらう。
【０１００】
プレイヤはゲーム機１でプレイするために決済端末３にプレイしてもよいと思う金額（最低料金以上の金額）とプレイヤを特定するためのプレイヤＩＤを入力して支払（事前決済）を行う。この一連の操作が入札である。なお、入札時に入力するプレイヤＩＤには電子マネーやプリペイドカードで支払を行える場合は、電子マネーやプリペイドカード毎に割り振られているユニークなシリアル番号を支払時に決済端末３が読み取り、プレイヤＩＤとする。この場合プレイヤは支払を行った媒体を所有していることが後に支払を行った証になる。また、支払があったときに決済端末３がユニークなプレイヤＩＤを発行し、プレイヤにそのプレイヤＩＤをなんらかの手段で記憶してもらう方法もある。この場合、プレイヤが所持する媒体に発行したプレイヤＩＤを書き込むような場合は問題ないが、直接目で見て頭に記憶する場合等、プレイヤＩＤを第三者に盗用される恐れがある場合は、プレイヤがプレイヤＩＤを受け取るときにプレイヤが後で認証時に使用するパスワードを入力させ、決済端末３はプレイヤＩＤとパスワードをセットで記憶しておく。
【０１０１】
決済端末３の制御部３１はプレイヤにより入札が行われたか否か判断し（ステップＳ３０３）、入札が行われたと判断した場合（ステップＳ３０３のＹｅｓ）、入札金額およびプレイヤＩＤの入力（ステップＳ３０４）と入札金額の支払（ステップＳ３０５）を受け付け、これらの入札内容に加えて入札時刻としてそのときの時刻と入札状態（初期値は「入札有効」）を表すデータをセットにし、１件の入札履歴として不揮発メモリ３１４に記憶する（ステップＳ３０６）。入札が行われたと判断しなかった場合（ステップＳ３０３のＮｏ）は特に処理をせずに次の処理に移行する。
【０１０２】
次いで、決済端末３の制御部３１はゲーム機１からのゲーム終了通知やゲーム終了見込み通知により、ゲーム機１が空き状態（現時点で空き状態である場合と、事前に設定されているゲーム１回あたりの時間によりまもなく空き状態になる場合とを含む）であるか否か判断し（ステップＳ３０７）、空き状態であると判断しなかった場合（ステップＳ３０７のＮｏ）は入札状況の表示（ステップＳ３０２）に移行する。
【０１０３】
ゲーム機１が空き状態であると判断した場合（ステップＳ３０７のＹｅｓ）は、不揮発メモリ３１４に記憶されている入札履歴の中に有効な入札があるか否か判断し（ステップＳ３０８）、有効な入札があると判断しなかった場合（ステップＳ３０８のＮｏ）は入札状況の表示（ステップＳ３０２）に移行する。
【０１０４】
有効な入札があると判断した場合（ステップＳ３０８のＹｅｓ）は、不揮発メモリ３１４に記憶されている入札履歴の中から仮落札者を決定する（ステップＳ３０９）。このとき、決済端末３の制御部３１は入札状態が有効である入札履歴の中から最低料金以上で最も高い値段をつけている入札履歴を検索し、その入札を行ったプレイヤを仮落札者とする。この最も高い値段をつけた入札履歴が複数ある場合は、その中で最も早い時刻に入札を行ったプレイヤを仮落札者とする。
【０１０５】
仮落札者が決まると、決済端末３の制御部３１はその仮落札者のプレイヤＩＤをディスプレイ３２１に表示して仮落札者となったプレイヤを呼び出す（ステップＳ３１０）。呼び出されたプレイヤは、所定時間内に決済端末３に対して、入札を行ったときのプレイヤＩＤを入力して認証を行うことで、落札を確定することができる。この認証の方法は、プレイヤＩＤに電子マネーやプリペイドカードのユニークなシリアル番号を使用している場合は、そのシリアル番号を決済端末３に読み取らせ、決済端末３が記憶している仮落札者のプレイヤＩＤと一致した場合に認証できたとする。プレイヤＩＤとパスワードがセットになっている場合は、パスワードも一緒に入力し、両方とも決済端末３で記憶しているものと一致した場合に認証できたとする。
【０１０６】
次いで、決済端末３の制御部３１は仮落札者による認証が完了したか否か判断し（ステップＳ３１１）、完了したと判断しなかった場合（ステップＳ３１１のＮｏ）は所定時間の経過をウオッチし（ステップＳ３１２）、所定時間が経過した場合（ステップＳ３１２のＹｅｓ）は不揮発メモリ３１４に記憶されている該当する入札履歴の入札状態を「入札休止」に変更し（ステップＳ３１３）、残る入札履歴の中から落札者を再検索するため、有効な入札があるか否かの判断（ステップＳ３０８）に移行する。入札休止状態になった入札履歴は、プレイヤが入札休止取消処理を行うまで入札休止状態のままとなり、落札の対象から除外される。なお、入札休止状態になっているプレイヤＩＤで新規に入札を行うことはできない。また、入札休止状態になっているプレイヤＩＤは仮落札者の認証待ち以外のときに認証を行うことで入札有効状態に戻すことができる。
【０１０７】
仮落札者による認証が完了したと判断した場合（ステップＳ３１１のＹｅｓ）は、不揮発メモリ３１４に記憶されている該当する入札履歴の入札状態を「落札済」に変更し（ステップＳ３１４）、支払通知ポート３２４から支払通知ケーブル２１を介してゲーム機１に支払通知を行い（ステップＳ３１５）、入札状況の表示（ステップＳ３０２）に移行する。ゲーム機１に支払通知が行われることで、プレイヤはゲーム機１でゲームをプレイすることができるようになる。入札状態が落札済に変更された入札は、次回から落札の対象から除外される。今回落札とならなかった入札履歴は引き続き次回以降の仮落札者を決める際の対象となる。その後も、ゲーム機１および決済端末３が動作している間は同様の処理を繰り返す。
【０１０８】
また、プレイヤは入札を取り消したい場合、決済端末３で入札取消処理を行うことができる。このときプレイヤは支払を行ったときのプレイヤＩＤと、もしパスワードがセットになっている場合はパスワードを入力する。決済端末３の入札履歴に該当する入札が存在した場合、その入札履歴を入札取消とし、以後、仮落札の対象に含めないようにする。また、これと同時にプレイヤに対して返金を行う。返金はプレイヤが支払った方法と同じ方法で行うのが望ましいが、電子マネー等で返金が決済端末３のみで容易に行えない場合は、支払の段階で決済端末３が自由に残高を変更することのできる現金相当のプリペイドカードや電子的なポイント等を購入してもらうようなシステムにすべきである。同様に、いたずら目的の入札を防ぐため、一定割合あるいは一定金額を差し引いた残りを返金するシステムとすることもできる。
【０１０９】
図１６〜図１８は決済端末３におけるユーザインタフェースの例を示す図である。
【０１１０】
図１６はディスプレイ３２１に入札の条件となる最低料金と入札状況が表示された状態を示しており、この例では、最低料金「￥１００」と最高の「￥１１２」を入札したプレイヤＩＤ（１件）と２番の「￥１１１」を入札したプレイヤＩＤ（２件）とが表示された状態を示している。
【０１１１】
図１７（ａ）は入札金額を入力し、支払を行う直前の状態のディスプレイ３２１の表示例を示したものであり、その後、支払部３２３に電子マネーカードを近づける等の操作により支払が行われる。（ｂ）は支払の完了により入札が受け付けられた状態のディスプレイ３２１の表示例を示したものである。
【０１１２】
図１８（ａ）は仮落札者の呼び出しを行っている状態のディスプレイ３２１の表示例を示したものであり、その後、支払部３２３に電子マネーカードを近づける等の操作により落札が確定する。（ｂ）はゲーム中のため入札のみを受け付ける状態におけるディスプレイ３２１の表示例を示したものである。
【０１１３】
また、入札金額を常に決済端末３が定める金額でしか行えないようにすると、入札した時刻だけで落札者が決まることになり、単なるゲーム機でプレイするための順番予約管理としても使用することができる。
【０１１４】
＜動作：アクティブオークション／ネットワーク型＞
同時に複数人がプレイできるゲームやネットワークゲームでプレイするためにその一部として複数のゲーム機が用意されている場合、または同じ種類のゲームが稼動しているゲーム機が複数ある場合等、どのゲーム機でプレイしても本質的に同じである場合、個々のゲーム機をスタンドアロン型にするとゲーム機ごとに最高入札価格が変わってしまう可能性があり好ましくない。また、実際に入札操作を行う場合、１台のゲーム機に対して複数の決済端末が接続されていると、例えばゲーム機のそばにある１台を仮落札の認証に、その他を入札用に使用するような使い分けができて便利である。ネットワーク型はこのような場合に有効となる。
【０１１５】
システム構成としては、図３（ゲーム機１および決済端末３の構成については図１）に示したものが前提となる。
【０１１６】
図１９はアクティブオークションのネットワーク型における処理例を示すフローチャートであり、図２０はその際のデータの流れの例を示す図である。
【０１１７】
説明のために前提条件として、サーバ５に接続している決済端末３はどれも本質的に同じゲームでプレイするためのゲーム機１に対応しているとする。しかしながら、本質的に異なるゲームでプレイするためのゲーム機１に対応する決済端末３が同じサーバ５に接続していても、以下の説明を応用することができる。
【０１１８】
図１９および図２０において、決済端末３の制御部３１は電源投入もしくは電源投入後のゲーム機１からのプレイ可能状態（状態通信ポート３２５を介してゲーム機１より取得）の確認により処理を開始すると（ステップＳ４０１）、サーバ５から入札の条件となる最低料金と入札履歴を取得してディスプレイ３２１に最低料金と現在の入札状況を表示する（ステップＳ４０２）。最低料金は不揮発メモリ５１４に予め設定情報として記憶させておく。入札状況の表示は決済端末３でプレイヤが操作を行っていないときに行われ、現在の入札状況を落札になる可能性が高い入札履歴から順にリストとしてディスプレイ３２１に表示することで、プレイヤが入札する場合の判断材料としてもらう。
【０１１９】
プレイヤはゲーム機１でプレイするために決済端末３にプレイしてもよいと思う金額（最低料金以上の金額）とプレイヤを特定するためのプレイヤＩＤを入力して支払（事前決済）を行う。この一連の操作が入札である。なお、入札時に入力するプレイヤＩＤには電子マネーやプリペイドカードで支払を行える場合は、電子マネーやプリペイドカード毎に割り振られているユニークなシリアル番号を支払時に決済端末３が読み取り、プレイヤＩＤとする。この場合プレイヤは支払を行った媒体を所有していることが後に支払を行った証になる。また、支払があったときに決済端末３がユニークなプレイヤＩＤを発行し、プレイヤにそのプレイヤＩＤをなんらかの手段で記憶してもらう方法もある。この場合、プレイヤが所持する媒体に発行したプレイヤＩＤを書き込むような場合は問題ないが、直接目で見て頭に記憶する場合等、プレイヤＩＤを第三者に盗用される恐れがある場合は、プレイヤがプレイヤＩＤを受け取るときにプレイヤが後で認証時に使用するパスワードを入力させ、サーバ５はプレイヤＩＤとパスワードをセットで記憶しておく。更に、ネットワーク型では、入札のときに入力するプレイヤＩＤとしてプレイヤが事前にサーバ５に登録しておいたプレイヤＩＤを何らかの手段で入力する方法を併用することができる。このときプレイヤＩＤはサーバ５上でユニークであり、登録したプレイヤしか知らないパスワードとセットでサーバ５に記憶されている。この場合、電子マネーやプリペイドカードのようなユニークなシリアル番号をもったものをプレイヤが所持している必要がなくなる。
【０１２０】
決済端末３の制御部３１はプレイヤにより入札が行われたか否か判断し（ステップＳ４０３）、入札が行われたと判断した場合（ステップＳ４０３のＹｅｓ）、入札金額およびプレイヤＩＤの入力（ステップＳ４０４）と入札金額の支払（ステップＳ４０５）を受け付け、これらの入札内容に加えて入札時刻としてそのときの時刻と入札状態（初期値は「入札有効」）を表すデータをセットにし、１件の入札履歴としてサーバ５に送信する（ステップＳ４０６）。サーバ５では不揮発メモリ５１４もしくは補助記憶装置５２にこれを記憶する（ステップＳ４０７）。入札が行われたと判断しなかった場合（ステップＳ４０３のＮｏ）は特に処理をせずに次の処理に移行する。
【０１２１】
次いで、決済端末３の制御部３１はゲーム機１からのゲーム終了通知やゲーム終了見込み通知により、ゲーム機１が空き状態（現時点で空き状態である場合と、事前に設定されているゲーム１回あたりの時間によりまもなく空き状態になる場合とを含む）であるか否か判断し（ステップＳ４０８）、空き状態であると判断しなかった場合（ステップＳ４０８のＮｏ）は入札状況の表示（ステップＳ４０２）に移行する。
【０１２２】
ゲーム機１が空き状態であると判断した場合（ステップＳ４０８のＹｅｓ）は、仮落札者取得の要求をサーバ５に送信する（ステップＳ４０９）。サーバ５は不揮発メモリ５１４もしくは補助記憶装置５２に記憶されている入札履歴の中に有効な入札があるか否か判断し（ステップＳ４１０）、有効な入札があると判断した場合（ステップＳ４１０のＹｅｓ）は、仮落札者を決定する（ステップＳ４１１）。このとき、サーバ５は有効な入札履歴の中から最低料金以上で最も高い値段をつけている入札履歴を検索し、その入札を行ったプレイヤを仮落札者とする。この最も高い値段をつけた入札履歴が複数ある場合は、その中で最も早い時刻に入札を行ったプレイヤを仮落札者とする。有効な入札があると判断しなかった場合（ステップＳ４１０のＮｏ）は特に処理を行わず、仮落札者は「なし」とする。そして、決定した仮落札者（決定しなかった場合は仮落札者は「なし」）を決済端末３に送信する（ステップＳ４１２）。
【０１２３】
決済端末３はサーバ５から仮落札者を受信し（ステップＳ４１３）、仮落札者があるか否か判断し（ステップＳ４１４）、仮落札者があると判断しなかった場合（ステップＳ４１４のＮｏ）は入札状況の表示（ステップＳ４０２）に移行する。仮落札者があると判断した場合（ステップＳ４１４のＹｅｓ）、決済端末３の制御部３１はその仮落札者のプレイヤＩＤをディスプレイ３２１に表示して仮落札者となったプレイヤを呼び出す（ステップＳ４１５）。この際、サーバ５でプレイヤＩＤとプレイヤが所持する携帯電話等の電子メールアドレスが対応付けられて記憶されている場合は、仮落札となった時点でサーバ５から電子メールを送信してプレイヤを呼び出すようにしてもよい。呼び出されたプレイヤは、所定時間内に決済端末３に対して、入札を行ったときのプレイヤＩＤを入力して認証を行うことで、落札を確定することができる。この認証の方法は、プレイヤＩＤに電子マネーやプリペイドカードのユニークなシリアル番号を使用している場合は、そのシリアル番号を決済端末３に読み取らせ、決済端末３が記憶している仮落札者のプレイヤＩＤと一致した場合に認証できたとする。プレイヤＩＤとパスワードがセットになっている場合は、パスワードも一緒に入力し、両方とも決済端末３で記憶しているものと一致した場合に認証できたとする。
【０１２４】
次いで、決済端末３の制御部３１は仮落札者による認証が完了したか否か判断し（ステップＳ４１６）、完了したと判断しなかった場合（ステップＳ４１６のＮｏ）は所定時間の経過をウオッチし（ステップＳ４１７）、所定時間が経過した場合（ステップＳ４１７のＹｅｓ）はサーバ５に対して該当する入札履歴の入札状態を「入札休止」に変更する要求を送信する（ステップＳ４１８）。これを受け、サーバ５は不揮発メモリ５１４もしくは補助記憶装置５２に記憶されている該当する入札履歴の入札状態を「入札休止」に変更する（ステップＳ４１９）。入札休止状態になった入札履歴は、プレイヤが入札休止取消処理を行うまで入札休止状態のままとなり、落札の対象から除外される。なお、入札休止状態になっているプレイヤＩＤで新規に入札を行うことはできない。また、入札休止状態になっているプレイヤＩＤは仮落札者の認証待ち以外のときに認証を行うことで入札有効状態に戻すことができる。そして、決済端末３の制御部３１は、残る入札履歴の中から落札者を再検索するため、仮落札者取得要求送信（ステップＳ４０９）に移行する。
【０１２５】
仮落札者による認証が完了したと判断した場合（ステップＳ４１６のＹｅｓ）は、サーバ５に対して該当する入札履歴の入札状態を「落札済」に変更する要求を送信する（ステップＳ４２０）。これを受け、サーバ５は不揮発メモリ５１４もしくは補助記憶装置５２に記憶されている該当する入札履歴の入札状態を「落札済」に変更する（ステップＳ４２１）。そして、決済端末３の制御部３１は支払通知ポート３２４から支払通知ケーブル２１を介してゲーム機１に支払通知を行い（ステップＳ４２２）、入札状況の表示（ステップＳ４０２）に移行する。ゲーム機１に支払通知が行われることで、プレイヤはゲーム機１でゲームをプレイすることができるようになる。入札状態が落札済に変更された入札は、次回から落札の対象から除外される。今回落札とならなかった入札履歴は引き続き次回以降の仮落札者を決める際の対象となる。その後も、ゲーム機１および決済端末３が動作している間は同様の処理を繰り返す。
【０１２６】
また、入札金額を常に決済端末３もしくはサーバ５が定める金額でしか行えないようにすると、入札した時刻だけで落札者が決まることになり、単なるゲーム機でプレイするための順番予約管理としても使用することができる。
【０１２７】
＜アクティブオークションとパッシブオークションの組み合わせ＞
上述したアクティブオークションとパッシブオークションを組み合わせることで、より付加価値の高いものとすることができる。すなわち、アクティブオークションの最低料金をゲーム機の稼働率に応じて変化する現在の料金とすることで、現在の料金以上で最も高い金額で入札したプレイヤが落札されることとなり、入札が少ない状態では最低で現在の料金でプレイさせ、入札が多い状態ではプレイヤの欲する度合に応じた料金でプレイさせることができ、リーズナブルな料金設定とすることができる。なお、この場合、現在の料金はその時々で変化するものであるため、入札の金額による制限は行わず、任意の金額による入札を許容するものとする。
【０１２８】
＜総括＞
以上説明したように、本発明の実施形態によれば次のような利点がある。
（１）ゲーム機の稼動状況もしくはプレイ希望者からの入札状況に応じて料金設定を適切に変化させることができ、ゲーム機の稼働率を向上させてアミューズメント施設全体の収益率の改善に寄与することができる。
（２）電子マネー等によるプレイ料金支払方法の多様化により、従来のように１００円単位ではなく、細かい金額での支払が可能になるメリットを活かすことができ、新たな収益の確保に結び付けることができる。
（３）アクティブオークションとパッシブオークションを兼ね備えたシステム構成とすることにより、安い金額でしかプレイしたくないのであれば安い金額で入札しておいてプレイ料金が下がるのを待つことができるし、高い金額を払ってでもすぐにプレイしたいと思えば高い料金で入札し優先的にプレイすることもできるようになり、プレイヤにとってリーズナブルなものとなるとともに、ゲーム機を営業に使用する者にとってもより適正な収入が得られるようになる。
【０１２９】
以上、本発明の好適な実施の形態により本発明を説明した。ここでは特定の具体例を示して本発明を説明したが、特許請求の範囲に定義された本発明の広範な趣旨および範囲から逸脱することなく、これら具体例に様々な修正および変更を加えることができることは明らかである。すなわち、具体例の詳細および添付の図面により本発明が限定されるものと解釈してはならない。
【図面の簡単な説明】
【０１３０】
【図１】本発明の一実施形態にかかるゲーム機および決済端末の構成例を示す図である。
【図２】決済端末のパネル外観の例を示す図である。
【図３】ネットワーク型の場合におけるサーバの構成例を示す図である。
【図４】パッシブオークションのスタンドアロン型でゲーム時間が一定でない場合における処理例を示すフローチャートである。
【図５】データの流れの例を示す図である。
【図６】決済端末におけるユーザインタフェースの例を示す図である。
【図７】パッシブオークションのスタンドアロン型でゲーム時間が一定とみなせる場合における処理例を示すフローチャートである。
【図８】データの流れの例を示す図である。
【図９】パッシブオークションのネットワーク型でゲーム時間が一定でない場合における処理例を示すフローチャートである。
【図１０】データの流れの例を示す図である。
【図１１】稼動履歴を逐次にサーバに送信しない場合に稼動率を計算する際の説明図である。
【図１２】パッシブオークションのネットワーク型でゲーム時間が一定とみなせる場合における処理例を示すフローチャートである。
【図１３】データの流れの例を示す図である。
【図１４】アクティブオークションのスタンドアロン型における処理例を示すフローチャートである。
【図１５】データの流れの例を示す図である。
【図１６】決済端末におけるユーザインタフェースの例を示す図（その１）である。
【図１７】決済端末におけるユーザインタフェースの例を示す図（その２）である。
【図１８】決済端末におけるユーザインタフェースの例を示す図（その３）である。
【図１９】アクティブオークションのネットワーク型における処理例を示すフローチャートである。
【図２０】データの流れの例を示す図である。
【符号の説明】
【０１３１】
１        ゲーム機
１１      支払部
１２      ゲーム制御部
２１      支払通知ケーブル
２２      状態通信ケーブル
３        決済端末
３１      制御部
３１１    ＣＰＵ
３１２    ＲＡＭ
３１３    ＲＯＭ
３１４    不揮発メモリ
３１５    タイマ
３２      入出力部
３２１    ディスプレイ
３２２    ボタン
３２３    支払部
３２４    支払通知ポート
３２５    状態通信ポート
３２６    ネットワーク通信ポート
４        ネットワーク
５        サーバ
５１      制御部
５１１    ＣＰＵ
５１２    ＲＡＭ
５１３    ＲＯＭ
５１４    不揮発メモリ
５１５    タイマ
５２      補助記憶装置
５３      ネットワーク通信ポート
【図１】
2008250946.tif 000003
【図２】
2008250946.tif 000004
【図３】
2008250946.tif 000005
【図４】
2008250946.tif 000006
【図５】
2008250946.tif 000007
【図６】
2008250946.tif 000008
【図７】
2008250946.tif 000009
【図８】
2008250946.tif 000010
【図９】
2008250946.tif 000011
【図１０】
2008250946.tif 000012
【図１１】
2008250946.tif 000013
【図１２】
2008250946.tif 000014
【図１３】
2008250946.tif 000015
【図１４】
2008250946.tif 000016
【図１５】
2008250946.tif 000017
【図１６】
2008250946.tif 000018
【図１７】
2008250946.tif 000019
【図１８】
2008250946.tif 000020
【図１９】
2008250946.tif 000021
【図２０】
2008250946.tif 000022