(57)【要約】      （修正有）【課題】利用実績に関する情報の端末装置からサーバへの適切な送信を管理できる情報管理システムを提供する。【解決手段】ネットワークを介して互いに通信可能に接続された複数のゲーム機及びサーバを有し、ゲーム機は、ゲーム機の利用実績に関するイベントを所定の送信タイミングでサーバへ送信し、サーバは、イベントに基づいてゲーム機に課金すべき額を算出する情報管理システムであって、ゲーム機には、イベントの送信状況を監視して、所定の送信タイミングで送信されるべきイベントが正常に送信されているか否かを所定条件に基づいて判別し（Ｓ１１）と、所定条件が満たされたときにイベントが正常に送信されていないとして、当該ゲーム機の動作を制限する（Ｓ１４）。【選択図】図５
2012173802.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介して互いに通信可能に接続された複数の端末装置及びサーバを有し、前記端末装置は、前記端末装置の利用実績に関する情報を所定の送信タイミングで前記サーバへ送信し、前記サーバは、前記利用実績に関する情報に基づいて前記端末装置に課金すべき額を算出する情報管理システムであって、
前記端末装置には、
前記利用実績に関する情報の送信状況を監視して、前記送信タイミングで送信されるべき前記情報が正常に送信されているか否かを所定条件に基づいて判別する条件判別手段と、
前記所定条件が満たされたときに前記情報が正常に送信されていないとして、当該端末装置の動作を制限する動作制限手段と、
が設けられている情報管理システム。
【請求項２】
前記端末装置には、前記利用実績に関する情報を記憶する記憶装置が設けられ、
前記所定条件が、前記記憶装置における前記情報の蓄積量が所定量に達することである請求項１に記載の情報管理システム。
【請求項３】
前記所定条件が、前記利用実績に関する情報を未送信の状態で一定期間経過したことである請求項１に記載の情報管理システム。
【請求項４】
前記動作制限手段は、前記所定条件が満たされるとその端末装置の動作を停止させる請求項１〜３のいずれか一項に記載の情報管理システム。
【請求項５】
前記動作制限手段は、前記所定条件が満たされたときにその端末装置が利用されている場合には、前記利用が終了した後に前記端末装置の動作を制限する請求項１〜４のいずれか一項に記載の情報管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、業務用のゲーム機のような端末装置から利用実績に関する情報をサーバに送信し、その情報に基づいて課金額を算出する情報管理システムに関する。
【背景技術】
【０００２】
業務用のゲーム機は、プレイ料金の徴収と引き換えにユーザにゲームプレイを提供している。ゲーム機はサーバと接続され、徴収したプレイ料金は利用実績に関する情報としてサーバに送信される。一方、サーバ等を管理するサービス管理者がその情報に基づいて課金額を算出し、ゲーム機を設置しているゲーム施設の運営者に請求している（例えば特許文献１参照）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１０−２６２３８９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
サーバでは、利用実績に関する情報に基づいて各運営者への課金すべき額を算出し請求しているが、ゲーム機等の端末装置から当該情報が適切に送信されていない場合、放置していると不正な利用を助長するおそれがある。
【０００５】
そこで、本発明は利用実績に関する情報の端末装置からサーバへの適切な送信を管理できる情報管理システムを提供することを目的とする。
【課題を解決するための手段】
【０００６】
本発明の情報管理システムは、ネットワーク（６）を介して互いに通信可能に接続された複数の端末装置（３）及びサーバ（５）を有し、前記端末装置は、前記端末装置の利用実績に関する情報（１４）を所定の送信タイミングで前記サーバへ送信し、前記サーバは、前記利用実績に関する情報に基づいて前記端末装置に課金すべき額を算出する情報管理システム（１）であって、前記端末装置には、前記利用実績に関する情報の送信状況を監視して、前記送信タイミングで送信されるべき前記情報が正常に送信されているか否かを所定条件に基づいて判別する条件判別手段（１０）と、前記所定条件が満たされたときに前記情報が正常に送信されていないとして、当該端末装置の動作を制限する動作制限手段（１０）と、が設けられていることにより上記課題を解決する。
【０００７】
本発明の情報管理システムによれば、端末装置の利用実績に関する情報は、所定の送信タイミングで端末装置からサーバに送信される。何らかの不具合が生じて利用実績に関する情報の送信がされないときに所定条件が満たされると、その端末装置の動作が制限される。サーバに利用実績に関する情報が送信されない場合は、サーバ側で端末装置の利用実績が正確に把握できないため、その端末装置の動作を制限することにより、把握できない利用を防止する。従って、端末装置からサーバへの利用実績に関する情報の送信を監視し、所定条件を満たせば端末装置の動作を制限することで、適切に利用実績に関する情報の送信を管理することができる。
【０００８】
本発明の情報管理システムの一形態において、前記端末装置には、前記利用実績に関する情報を記憶する記憶装置（１２）が設けられ、前記所定条件が、前記記憶装置における前記情報の蓄積量が所定量に達することであってもよい。この形態によれば、記憶装置に蓄積された利用実績に関する情報が送信されず、蓄積され続けて所定量に達することが条件となって端末装置の動作を制限する。従って、送信状況を適切に管理できる。
【０００９】
本発明の情報管理システムの一形態において、前記所定条件が、前記利用実績に関する情報を未送信の状態で一定期間経過したことであってもよい。この形態によれば、送信されるべき情報が何らかの不具合で一定期間未送信の状態にあることを条件とすることで、送信状況を適切に管理できる。
【００１０】
本発明の情報管理システムの一形態において、前記動作制限手段は、前記所定条件が満たされるとその端末装置の動作を停止させてもよい。この形態によれば、所定条件が満たされた端末装置の動作は停止するので、以降の利用ができない状態となる。これにより、サーバ側で把握できない端末装置の利用を防止でき、送信できない状況での利用実績に関する情報の発生を防止することができる。
【００１１】
本発明の送信管理システムの一形態において、前記動作制限手段は、前記所定条件が満たされたときにその端末装置が利用されている場合には、前記利用が終了した後に前記端末装置の動作を制限してもよい。この形態によれば、端末装置がユーザにより利用されている場合、利用の終了を待って、以降の動作を制限するので、ユーザに不都合のない状態で適切な情報送信管理ができる。
【００１２】
なお、以上の説明では本発明の理解を容易にするために添付図面の参照符号を括弧書きにて付記したが、それにより本発明が図示の形態に限定されるものではない。
【発明の効果】
【００１３】
以上、説明したように、本発明の情報管理システムにおいては、端末装置の利用実績に関する情報は、所定の送信タイミングで端末装置からサーバに送信される。何らかの不具合が生じて利用実績に関する情報の送信がされないときに所定条件が満たされると、その端末装置の動作が制限される。サーバに利用実績に関する情報が送信されない場合は、サーバ側で端末装置の利用実績が正確に把握できないため、その端末装置の動作を制限することにより、把握できない利用を防止する。従って、端末装置からサーバへの利用実績に関する情報の送信を監視し、所定条件を満たせば端末装置の動作を制限することで、適切に利用実績に関する情報の送信を管理することができる。
【図面の簡単な説明】
【００１４】
【図１】本発明の一形態に係る情報管理システムが適用されたゲームシステムの全体構成の概要を示す図。
【図２】ゲームシステムのブロック図。
【図３】制御ユニットが実行するイベント処理ルーチンを示すフローチャート。
【図４】イベント蓄積部におけるイベントの蓄積を説明する図。
【図５】制御ユニットが実行する停止処理ルーチンを示すフローチャート。
【発明を実施するための形態】
【００１５】
本発明の一形態に係る情報管理システムが適用されたゲームシステムの全体構成の概要を示している。ゲームシステム１は、オペレータ２がアミューズメント施設等の商業施設（以下、店舗と呼ぶ。）に設置した一台又は複数台の端末装置としてのゲーム機３と、サービス管理者４が管理又は運営している複数台のサーバ５とがインターネット等のネットワーク６を介して相互に通信可能に接続されている。ゲーム機３は、ユーザに対して所定額の貨幣価値の消費と引き換えにゲームのプレイを許可する業務用のゲーム機である。ゲーム機３では、ユーザは、現金あるいは電子通貨を利用してプレイ料金を支払うことができる。電子通貨によるプレイ料金の徴収には、ユーザに供与されているカード７を利用する。
【００１６】
カード７には、ＩＣチップが組み込まれ、そのＩＣチップには、カードごとにユニークなカードＩＤが記録されている。各ゲーム機３には、カード７からカードＩＤを読み取るカードリーダ（不図示）と、そのカードリーダが読み取ったカードＩＤを指定して、サーバ５に所定の処理を要求し、その要求に対するサーバ５の応答を処理するソフトウエアとが組み込まれている。サーバ５は、ゲーム機３からの要求を受け取った場合、カードＩＤに対応付けてプレイデータを保存し、あるいは、カードＩＤに対応付けて保存されているプレイデータをそのゲーム機３に送信する、といった処理を実行する。なお、サーバ５におけるプレイデータは、カードＩＤと１対１で対応付けられていてもよいし、カードＩＤと１対１又は多対１で対応付けられた別のＩＤ（一例としてユーザＩＤ）と対応付けられていてもよい。
【００１７】
また、サーバ５は、電子通貨の口座データを管理する。口座データは、カードＩＤ、又はそのカードＩＤと１対１又は多対１で対応付けられた別のＩＤ（一例としてユーザＩＤ）と、ユーザが預け入れた電子通貨の残高とを対応付けて記録したデータである。ユーザがゲーム機３のゲーム体するプレイ料金を電子通貨にて支払うことを希望する場合、ゲーム機３からサーバ５に対してカードＩＤと電子通貨の消費量（引き落とし額）とを指定して引き落としが要求される。その要求に対応して、サーバ５はユーザの口座データを特定し、口座データ上の残高から消費量相当の電子通貨の引き落としを試みる。サーバ５は、残高が消費量以上であれば、その消費量を減算し、引き落としに成功したことをゲーム機３に通知し、一方、残高が消費量未満であれば、残高を減算することなく、引き落としに失敗したことをゲーム機３に通知する。ゲーム機３では、サーバ５からの通知に応じて、ゲームのプレイを許可するか否かを制御する。各ゲーム機３には、サーバ５と協働してプレイ料金を電子通貨で徴収するために必要なプログラムやデータも予め実装されている。なお、電子通貨の単位は適宜に設定されてよい。一例として、通貨の１円が電子通貨の１ポイントに相当するように電子通貨の単位が設定される。
【００１８】
図２に上述したゲームシステム１のブロック図を示す。ゲーム機３は、制御ユニット１０を備えている。制御ユニット１０は、マイクロプロセッサと、そのマイクロプロセッサにて実行されるべきオペレーティングシステム等のプログラムが記録されたＲＯＭ、及びマイクロプロセッサに対する作業領域を提供するＲＡＭ等の内部記憶装置とを備えたコンピュータユニットである。制御ユニット１０は図示しない外部記憶装置に記録されたゲーム機用プログラムを読み取って実行することにより、制御ユニット１０の内部には論理的装置としてのゲーム管理部１１、イベント蓄積部１２、及びイベント処理部１３が設けられる。ゲーム管理部１１は、ゲーム機３で実行されるゲームの環境設定や進行の管理をし、ユーザの操作に応じたイベント１４（図４参照）を発生させる。イベント蓄積部１２は、発生するイベント１４を記憶する。発生するイベント１４には、ゲーム進行中に発生するゲーム内容に応じた様々なイベント１４の他、ゲーム機３の利用実績に関する情報としての課金イベント１４がある。利用実績に関する情報として、ユーザからのプレイ料金の徴収により発生する課金情報がある。イベント蓄積部１２は、制御ユニット１０内の内部記憶装置に設けられる。このため、イベント蓄積部１２で蓄積したイベント１４はゲーム機３の電源をオフにすると記録が消失する。イベント蓄積部１２が記憶装置として機能する。イベント処理部１３は、イベント蓄積部１２にて蓄積されたイベント１４を所定のタイミングでサーバ５に送信する。サーバ５は、端末管理部２１を備えている。端末管理部２１は、各ゲーム機３のイベント処理部１３から送信されたイベント１４を受信し、各ゲーム機３のイベント内容を管理する。
【００１９】
図３は制御ユニット１０が実行するイベント処理ルーチンを示すフローチャートである。イベント処理ルーチンは、ゲーム機３で実行されているゲームの進行中に適宜発生するイベント１４を処理するものでイベント処理部１３が実行する。イベント１４は、ユーザの操作やゲーム変化に応じて発生する。まず、制御ユニット１０は、ステップＳ１でイベント１４が発生したか否かを判断する。イベント１４が発生している場合、制御ユニット１０は、次のステップＳ２で発生したイベント１４をイベント蓄積部１２に蓄積する。図４にイベント１４の蓄積を説明する図を示す。イベント蓄積部１２は、ゲーム管理部１１でユーザの操作等に応じて発生するイベント１４を蓄積する。イベント蓄積部１２は、制御ユニット１０内のメモリ等の内部記憶装置で構成され、一例として２５６段のメモリ空間を有し、１段にひとつのイベント１４を記録できる。発生するイベント１４は適宜イベント蓄積部１２に蓄積されていく。一方、イベント１４が発生していない場合には、ステップＳ２をスキップしてステップＳ３に進む。
【００２０】
ステップＳ３にて制御ユニット１０は、イベント蓄積部１２で蓄積されているイベント１４をサーバ５へ送信すべきタイミングか否かを判断する。サーバ５への送信タイミングは、イベント蓄積部１２にある程度のイベント１４が蓄積されてから送信するように設定される。例えば、発生したイベント１４を蓄積してから所定期間経過後に送信するように設定される。この待機している期間に他のイベント１４がさらに発生してイベント蓄積部１２に蓄積されると後から蓄積されたイベント１４とともにサーバ５へ送信する。これにより、通信量を低減している。制御ユニット１０は、ステップＳ３で送信タイミングであると判断するとステップＳ４に進んでイベント蓄積部１２に蓄積されたイベント１４をサーバ５に送信する。一方、ステップＳ３で送信タイミングでないと判断すると、制御ユニット１０は今回の処理を終了する。
【００２１】
制御ユニット１０は次のステップＳ５に進み、イベント１４の送信が成功したか否かを判断する。サーバ５の端末管理部２１からのイベント受信通知を受け取ることで判断する。送信が成功している場合には、制御ユニット１０は今回の処理を終了する。一方、端末管理部２１からのイベント受信通知を受け取っていない場合、制御ユニット１０はイベント１４の送信が失敗したとの判断をし、ステップＳ４に戻ってイベント１４を再送信する。なお、イベント１４の再送信には所定の期間、回数が設定され、ステップＳ６でタイムアウトと判断された場合には、制御ユニット１０は今回の処理を終了する。
【００２２】
上述したイベント処理では、制御ユニット１０のイベント処理部１３が、ゲーム管理部１１のゲーム進行中に適宜発生するイベント１４に対してイベント蓄積部１２に蓄積させ（ステップＳ２）、所定の送信タイミングにてサーバ５にイベント１４を送信する（ステップＳ４）。
【００２３】
次に、図５のフローチャートを参照して制御ユニット１０が実行する停止処理ルーチンを説明する。停止処理ルーチンは、上述したイベント処理ルーチンのステップＳ４のイベント送信を監視して送信が成功しなかった場合の処理である。まず制御ユニット１０は、ステップＳ１１でイベント送信状況が所定条件としての停止条件を満たすか否かを判断する。停止条件として、蓄積されたイベント１４がイベント蓄積部１２の蓄積可能なイベント数のうち所定量としての停止レベル１５に達することが条件として設定される。停止レベル１５は、イベント蓄積部１２の蓄積可能なイベント数、例えば２５６段であれば、１６０段で停止レベル１５を設定する。イベント１４の蓄積数が１６０以上となれば停止条件を満たすことになる。イベントの中でもユーザからのプレイ料金徴収のために発生する課金イベントがサーバ５へ送信されないと、そのゲーム機３で徴収したプレイ料金をサービス管理者４が正確に把握できず、オペレータ２へ利用料金の請求ができない。このため停止条件を設定して送信されていないイベント１４が停止レベル１５に達すると適切な送信がされていないとみなしている。
【００２４】
停止条件が満たされた場合には、制御ユニット１０は、次のステップＳ１２に進んで、ユーザによるゲームプレイ中か否かを判断する。ユーザがゲームプレイ中であれば、制御ユニット１０は次のステップＳ１３に進みユーザがゲームプレイを終了するまで待機する。これにより、正当なプレイ料金を支払ってゲームプレイに興じているユーザに対してはゲームプレイ機会を確保できる。停止条件が満たされた時点で支払われているプレイ料金内のゲームプレイを確保できればよく、停止条件が満たされた以降はプレイ料金の徴収をできないようにしてもよいし、あるいは、コンティニュー可能なゲームであればプレイ料金を徴収可能としてユーザの希望通りにゲームプレイを続行させるようにしてもよい。
【００２５】
ユーザによるゲームプレイが終了した場合、あるいは、ステップＳ１２にてゲームプレイ中でない場合には、制御ユニット１０は、次のステップＳ１４に進んで、ゲーム機３のサービスを停止する。サービスの停止として、ゲーム機３の電源供給を停止してオペレータ２による操作ができない状態とし、ゲーム機３の動作を制限する他、ゲームプレイのみを禁止してデモ画面の表示は可能にするといった一定の利用制限を設けることがあげられる。サービス停止対象となるゲーム機３によるゲームプレイ機会の提供ができないようにすることでイベント１４の送信、特に課金イベントの送信がされない状態でのオペレータ２によるゲーム機３の利用を防止する。また、不具合等でイベント１４の送信がされないような状態であっても、オペレータ２側でのプレイ料金の徴収と、サービス管理者４側での課金情報との整合性を保つことができる。サービス停止後、あるいはステップＳ１１で停止条件を満たさなかった場合、制御ユニット１０は今回の処理を終了する。
【００２６】
上述の処理によれば、停止条件が満たされる（ステップＳ１１）と、ゲーム機３がサービスを停止する（ステップＳ１４）。これにより、課金イベントを含むイベント１４が適切にサーバ５に送信されているか否かを管理することができ、何らかの不具合で送信がされていない状況にあれば、ゲーム機３のサービスを停止して、オペレータ２とサービス管理者４間での利用料金請求に関する整合性を保つことができる。ステップＳ１１の処理はイベント処理部１３で実行され、ステップＳ１２〜Ｓ１４の処理はイベント処理部１３からの指示を受けたゲーム管理部１１が実行する。これにより、ステップＳ１１が条件判別手段として、ステップＳ１４が動作制限手段としてそれぞれ機能する。
【００２７】
本発明は、上述した形態に限定されることなく、種々の形態にて実施することができる。例えば、本形態では、停止条件として蓄積されたイベント１４がイベント蓄積部１２の蓄積可能なイベント数のうち停止レベル１５に達することを条件としているがこれに限られない。例えば、イベント処理ルーチンのステップＳ６でタイムアウトして処理が終了した状態が続いたことによる、直前の処理でイベント１４の送信が成功してから一定期間が経過したことを停止条件としてもよい。一定期間、サーバ５へイベント１４が送信されなければ、何らかの不具合が生じているとみなしてゲーム機３によるサービスの提供を停止できる。停止条件としては、課金イベントを含むイベント１４が適切にサーバ５に送信されていないことを条件とすればよく、イベント１４の送信に関する様々なパラメータを停止条件として設定してよい。また、本形態では、課金イベントを含むイベントの送信管理について説明したが、これに限られず、課金イベントのみを対象としてもよい。
【００２８】
また、本形態では、停止処理ルーチンのステップＳ１４でゲーム機３のサービスの停止をすることで端末装置の利用を制限したがこれに限られない。例えば、停止条件を満たした場合に、オペレータ２に対して何らかのペナルティを科すようにしてもよい。イベント１４の送信復帰時に送信が途絶えていたことを示す情報をゲーム機３がサーバ５に送信し、サービス管理者４からの請求額にペナルティ分を上乗せするような対応としてもよい。停止処理を実行するイベント処理部１３及びイベント蓄積部１２はゲーム機１の制御ユニット１０で機能している形態で説明したが、これに限られず例えば、ゲーム機１と別個に設けられた装置を端末装置としてイベント処理部１３の機能を割り当てるようにしてもよい。ゲームシステム１内で、ゲーム機１のイベント１４の蓄積状況及び送信状況を監視して、停止条件が満たされた場合にゲーム機１の利用を制限するような構成となっていればよい。
【符号の説明】
【００２９】
１  ゲームシステム
２  オペレータ
３  ゲーム機（端末装置）
４  サービス管理者
５  サーバ
６  ネットワーク
１０  制御ユニット（条件判別手段、動作制限手段）
１１  ゲーム管理部
１２  イベント蓄積部
１３  イベント処理部
１４  イベント（利用実績に関する情報）
１５  停止レベル
【図１】
2012173802.tif 000003
【図２】
2012173802.tif 000004
【図３】
2012173802.tif 000005
【図４】
2012173802.tif 000006
【図５】
2012173802.tif 000007