JP2004154248A - 遊技履歴データ管理システム - Google Patents
遊技履歴データ管理システム Download PDFInfo
- Publication number
- JP2004154248A JP2004154248A JP2002321281A JP2002321281A JP2004154248A JP 2004154248 A JP2004154248 A JP 2004154248A JP 2002321281 A JP2002321281 A JP 2002321281A JP 2002321281 A JP2002321281 A JP 2002321281A JP 2004154248 A JP2004154248 A JP 2004154248A
- Authority
- JP
- Japan
- Prior art keywords
- user
- game history
- history data
- same
- data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Pinball Game Machines (AREA)
Abstract
【課題】ユーザー単位の遊技履歴データを、正確に管理できるようにすることである。
【解決手段】記憶部６と、処理部５とからなる遊技履歴データ管理システムであり、上記記憶部６は、ユーザー特定情報に対応した遊技履歴データを記憶する機能を備え、上記処理部５は、上記記憶部の遊技履歴データのうち同一または類似の遊技履歴データを有する類似群のユーザー特定情報を抽出する機能と、上記履歴データから同日同時刻に遊技した履歴の有無を判定する機能と、上記類似群のユーザー特定情報のうち、同日同時刻の遊技履歴を持たないユーザー特定情報を同一ユーザーのユーザー特定情報と判定する機能とを備えた。
【選択図】 図１
【解決手段】記憶部６と、処理部５とからなる遊技履歴データ管理システムであり、上記記憶部６は、ユーザー特定情報に対応した遊技履歴データを記憶する機能を備え、上記処理部５は、上記記憶部の遊技履歴データのうち同一または類似の遊技履歴データを有する類似群のユーザー特定情報を抽出する機能と、上記履歴データから同日同時刻に遊技した履歴の有無を判定する機能と、上記類似群のユーザー特定情報のうち、同日同時刻の遊技履歴を持たないユーザー特定情報を同一ユーザーのユーザー特定情報と判定する機能とを備えた。
【選択図】 図１
Description
【０００１】
【発明の属する技術分野】
この発明は、パチンコ店などの遊技場において、会員ユーザーの遊技履歴データを管理するシステムに関する。
【０００２】
【従来の技術】
遊技場の中には、ユーザーに会員カードを発行し、各会員の遊技履歴データを管理しているところがある。上記会員カードには、会員ＩＤが記憶されていて、ユーザーは、自分が使用する遊技台に対応して設置されているカード読み取り機に、会員カードを挿入して、会員ＩＤを読み取らせてから遊技をする。
このカード読み取り機が読み取った会員ＩＤや、遊技台から出力される遊技データは、ホールコンピュータへ送信され、集計される。ホールコンピュータでは、受信したデータを、遊技台毎の遊技台データとして集計したり、会員ＩＤ毎に、個々の会員の遊技履歴データとして集計したりする。
【０００３】
なお、上記遊技台データとは、その遊技台におけるアウト数、セーフ数、賞球数、特賞回数、スタート回数などのデータである。上記アウト数とは、遊技台から打ち出された玉数で、セーフ数とは、入賞した玉数である。また、上記特賞回数とは、図柄部が回転して、それが特定の図柄パターンで停止したとき、多数の玉が払い出される状況、いわゆる大当たりのことであり、スタート回数とは、特定の入賞口への入賞によって上記図柄部が回転した回数のことである。また、玉貸しが行われる際には、その玉貸し金額も、遊技台データに含むこともある。
【０００４】
また、遊技履歴データとは、会員ＩＤ毎に、その会員が、いつ、どの台で遊技し、そのときの遊技状況がどうであったかということを記憶したデータである。
このような遊技履歴データを、収集するためには、会員が、遊技中にカード読み取り機に会員カードを挿入しなければならない。
ホールコンピュータが収集した遊技履歴データは、各会員の遊技履歴に基づいて、ポイントを付与して、そのポイントに応じたサービスをするために利用されるだけでなく、サービスの参考にするために、上記遊技履歴データに基づいて、ユーザーの遊技傾向を分析することもある。例えば、各ユーザーの遊技時間の合計や、平均遊技時間を算出したり、玉貸し金額に対するユーザー分布を算出したりする。
【０００５】
また、チェーン店などでは、各店舗のホールコンピュータで集計した遊技履歴データをチェーン店本部に送信して、本部のコンピュータで、チェーン全体のデータを管理することもある（特許文献１参照）。
【０００６】
【特許文献１】
特開平９−１７３５９２号公報
【０００７】
【発明が解決しようとする課題】
上記会員カードは、ユーザーの希望に応じて発行し、１ユーザーに一枚のカードを発行するのが通常であるが、同一ユーザーに、複数の会員カード、すなわち複数の会員ＩＤを発行してしまうことがある。例えば、ユーザーが、会員カードを紛失してしまったり、忘れてしまったりしたときに、そのことを店舗側に伝えないで、新規会員として登録してしまった時などに、会員カードの重複発行が起こる。
【０００８】
このように、同一ユーザーに対して、複数の会員ＩＤが発行され、それぞれが利用された場合、ひとりのユーザーの遊技履歴データが複数の会員ＩＤに分散して記憶されることになる。そのため、一人一人の履歴データが、正確に集計できないという問題がある。また、実際のユーザー数よりも会員ＩＤの数の方が多いので、正確な来店者数がわからないなど、遊技データから、正確なユーザーの状況を把握することができないという問題もあった。
この発明の目的は、同一ユーザーが複数会員ＩＤを使用して遊技を行った場合であっても、ユーザー単位の遊技履歴データを、正確に管理できるようにすることである。
【０００９】
【課題を解決するための手段】
第１の発明は、記憶部と、処理部とからなる遊技履歴データ管理システムであり、上記記憶部は、ユーザー特定情報に対応した遊技履歴データを記憶する機能を備え、上記処理部は、上記記憶部の遊技履歴データのうち同一または類似の遊技履歴データを有する類似群のユーザー特定情報を抽出する機能と、上記履歴データから同日同時刻に遊技した履歴の有無を判定する機能と、上記類似群のユーザー特定情報のうち同日同時刻の遊技履歴を持たないユーザー特定情報を同一ユーザーのユーザー特定情報と判定する機能とを備えた点に特徴を有する。
【００１０】
第２の発明は、記憶部と、処理部とからなる遊技履歴データ管理システムで、上記記憶部は、ユーザー特定情報に対応した遊技履歴データを記憶する機能を備え、上記処理部は、上記履歴データから同日同時刻に遊技した履歴の有無を判定し、同日同時刻の遊技履歴を持たない同一候補群のユーザー特定情報を抽出する機能と、上記記憶部の遊技履歴データのうち同一または類似の遊技履歴データを判定する機能と、同日同時刻の遊技履歴を持たない同一候補群のユーザー特定情報群のうち同一または類似の履歴データに対応するユーザー特定情報を同一ユーザーのユーザー特定情報と判定する機能とを備えた点に特徴を有する。
【００１１】
第３の発明は、記憶部と、処理部とからなり、上記記憶部は、遊技台特定情報毎に、ユーザー特定情報毎の遊技履歴データを対応づけた遊技台データと、ユーザー特定情報に対応づけた氏名や住所などのユーザー属性データとを記憶する機能とを備え、上記処理部は、ユーザー特定情報毎に遊技履歴データを集計するとともに、上記複数のユーザー属性データのうち同一属性を有する属性データを判定する機能と、ユーザー属性データが同一である異なるユーザー特定情報を同一のユーザーのユーザー特定情報と判定する機能とを備えた点に特徴を有する。
なお、上記ユーザー属性データの同一とは、属性データの全ての項目が同一であるということではない。例えば、ユーザー属性データのうち、氏名だけが一致した場合、あるいは、氏名と生年月日だけが一致した場合など、部分的に一致した場合でも、同一のユーザーと判定することがある。
【００１２】
第４の発明は、ユーザー特定情報に対応する氏名や住所などのユーザー属性データを記憶した複数のユーザー属性データベースと、これらユーザー属性データベースに対応し、かつ、ユーザー特定情報に対応する遊技履歴データを記憶した遊技履歴データベースと、これらのデータベースと通信手段を介して接続した処理部と、記憶部とからなり、上記処理部は、上記データベースから複数のユーザー属性データベースおよびそれに対応した遊技履歴データを受信してそれを記憶部に記憶させる機能と、上記記憶部が記憶している遊技履歴データに対応したユーザー属性データベースの中から、上記遊技履歴データ内のユーザー特定情報に対応するユーザー属性を特定する機能と、特定したユーザー属性と同一のユーザー属性をユーザー属性データベースから抽出する機能と、抽出された同一の属性データに対応するユーザー特定情報を同一のユーザーのユーザー特定情報と判定する機能とを備えた点に特徴を有する。
【００１３】
第５の発明は、上記第１から第４の発明のいずれか１つの発明を前提とし、処理部が、同一ユーザーのユーザー特定情報と判定したユーザー特定情報に対応した遊技履歴データを統合する機能を備えた点に特徴を有する。
【００１４】
【発明の実施の形態】
図１〜図４に示す第１実施例は、インターネットＮに接続可能にしたホールコンピュータ１と、データセンターサーバー２とを備えたシステムである。
図１に示すように、ホールコンピュータ１は、各店舗に設置され、各ホールコンピュータ１には、複数の遊技台３とそれに対応するカード読み取り機４とが接続されている。
カード読み取り機４は、ユーザー用に発行した会員カードの会員ＩＤを読み取る装置であり、各遊技台３の遊技台データとともに、ホールコンピュータ１へ送信される。
なお、この第１実施例では、複数の店舗は同系列のチェーン店であり、チェーン店間では、同じ会員カードを共通に利用できるようにしている。
【００１５】
また、データセンターサーバー２は、処理部５と、記憶部６とを備えている。これら、処理部５や記憶部６は、ハード的に構成するだけでなく、ソフト的に実現することもできる。
ホールコンピュータ１側では、一定時間ごと、この第１実施例では、閉店後に、遊技履歴データをデータセンターサーバー２に送信する。
ホールコンピュータ１では、図２に示すような遊技履歴データを記憶する。
図２の表７は、会員ＩＤごとに整理された遊技履歴データである。この表７は、会員ＩＤ欄７ａの隣に、来店日欄７ｂ、遊技時間欄７ｃを設け、さらに右側には、台番号欄７ｄ、機種名欄７ｅ、遊技台データ欄７ｄを設けている。この第１実施例では、ホールコンピュータ１が、毎日、閉店後に遊技履歴データをデータセンターサーバー２へ送信するようにしているので、ホールコンピュータ１は、１日分のデータだけを記憶しておけばよい。
【００１６】
つまり、表７のデータは、来店日欄７ｂに対応する日の会員ＩＤ毎の遊技履歴データである。例えば、会員ＩＤ１のユーザーが、「何時から何時まで、どの遊技台で、遊技し、どのような遊技状況であったのか」というデータである。遊技時間欄７ｃのデータが、何時から何時まで遊技したのかというデータであり、台番号欄７ｄおよび機種名欄７ｅが遊技した遊技台を特定するデータで、その他、使用金額、アウト数、セーフ数、…、などの遊技台データ欄７ｆのデータが、遊技状況である。
【００１７】
そして、ユーザーは、来店してから退店するまでに、遊技台を変えることが有る。そのような場合には、遊技台を変える毎に、図２の表７の右側へ、遊技時間欄７ｃ、遊技台欄７ｄ，機種名欄７ｅ、遊技台データ欄７ｆを繰り返し、そこにデータが入力される。例えば、図２からは、会員ＩＤ１のユーザーは、１０時から１２時まで、ある遊技台で遊技し、その後、遊技台を移って、さらに１３時から１９時まで遊技したことがわかる。
また、正確な入店時刻や退店時刻を、遊技履歴データとして収集するためには、入店時や退店時に専用のカード読み取り機に会員ＩＤを読み取らせる必要がある。
【００１８】
このような遊技履歴データをホールコンピュータ１が、データセンターサーバー２へ送信すると、データセンターサーバー２の処理部５は、会員ＩＤ毎に、全ての遊技履歴データを記憶部６に記憶させる。つまり、データセンターサーバー２の記憶部６には、図２に示すような１日分の遊技履歴データが何日分も蓄積されている。
また、この実施例では、データセンターサーバー２に接続可能なホールコンピュータ１は、全て、同一チェーン店のものなので、全ての店舗に来店するユーザーの遊技履歴を、店舗別ではなく、会員ＩＤによって統合することができる。
しかし、実際には、一人のユーザーが、複数の会員カードを持っていることもあるので、処理部５は、そのような会員ＩＤの重複発行を突き止める機能を備えている。
【００１９】
処理部５が、収集した遊技履歴データから、同一ユーザーに重複して割り当てられた会員ＩＤを特定し、ひとりのユーザーの遊技履歴データを統合する手順を、図３のフローチャートに従って説明する。
ステップＳ１で、処理部５は、全ての会員ＩＤの組み合わせで、遊技履歴データの類似性をチェックする。ここでは、ステップＳ１として、１ステップで表現しているが、実際には、次のような多数の処理が含まれる。具体的には、会員ＩＤ１の遊技履歴データと、会員ＩＤ２の遊技履歴データとを対比して、同一または類似であるかを判定し、次に、会員ＩＤ１のデータと、会員ＩＤ３のデータとを対比して類似性を判定し、さらに、会員ＩＤ１と会員ＩＤ４のデータを対比し、というように、全てのデータを対比してゆく。そして、個々の会員ＩＤのデータについて、類似のデータを持つ会員ＩＤを特定する。
例えば、会員ＩＤが１〜１０００まである場合、特定の会員ＩＤの遊技履歴データに対し、残りの９９９の会員ＩＤに対応する遊技履歴データを対比して、それぞれ、類似性を判定する。なお、類似の判定基準については、後で説明する。
【００２０】
このステップＳ１で、類似と判定した場合、ステップＳ２で、類似の遊技履歴データに対応する会員ＩＤを類似群として記憶する。このとき、類似群は、特定の会員ＩＤｎ毎にできるので、複数できることもある。例えば、会員ＩＤ１の遊技履歴データと、会員ＩＤ２の遊技履歴データは類似していないが、それぞれのデータに類似している遊技履歴データがある場合、会員ＩＤ１の類似群と、会員ＩＤ２の類似群とができる。
ステップＳ３で、会員ＩＤｎの類似群に含まれる会員ＩＤに対応する遊技データの中で、上記会員ＩＤｎの遊技履歴と同日同時刻の遊技履歴を持つ会員ＩＤをその類似群から除いて、ステップＳ４で、１つの類似群内の会員ＩＤを同一ユーザーのものとする。上記ステップＳ３で、同日同時刻に遊技履歴を持つ会員ＩＤを除くのは、同日同時刻に、一人のユーザーが、複数の会員ＩＤを用いて遊技することはできないはずだからである。
【００２１】
ステップＳ５では、上記ステップＳ４で同一ユーザーと判定した会員ＩＤに対応する遊技履歴データを、ひとりのユーザーの遊技履歴データとしてまとめる。これにより、同一ユーザーが、複数の会員カードを持っていて、つまり、複数の会員ＩＤを使っていた場合に、そのことを突き止めて、遊技履歴データをまとめることができる。従って、会員ＩＤだけから、別々のユーザーの遊技履歴データと見なしてデータ分析を行う場合に比べて、実際に即した正確なデータ分析ができる。
【００２２】
なお、図３のステップＳ１での、遊技履歴データの類似性の判定基準には、様々なものが利用できるが、例えば、以下のようなものが考えられる。
類似性の判定基準として、利用できる要素には、遊技場への来店時刻や、退店時刻の特徴や、来店曜日の特徴などがある。例えば、開店と同時に来店するとか、夜しか来店しないとか、必ず閉店まで遊技しているというような特徴や、決まった曜日にしか来店しないというようなことである。
また、遊技時間が、いつでも決まっているとか、遊技開始から一定時間内に、特賞が無ければ帰ってしまうとか、ユーザーによっては、決まった行動パターンをとることがある。そのため、平均滞在時間や、遊技時間帯も、類似性の判定要素にすることができる。
【００２３】
そして、各ユーザーの遊技履歴を対比する際には、各遊技履歴データの傾向を図４の表８のように整理することがある。図４では、遊技場の１日の営業時間帯を３時間単位で区切って、入店時刻および退店時刻をその単位時間帯で表している。そして、一定期間、例えば、過去１ヶ月の遊技履歴データから、入店時刻や、退店時刻が、特定の時間帯に限られているか、その時間帯が多い場合、その時間帯を示している。また、来店曜日も、履歴データから、回数の多い曜日を抽出して、それを示している。つまり、この表８から、会員ＩＤ１のユーザーは、水曜日の９時から１２時の間に来店し、１５時から１８時に退店することが多いということである。この表８には、会員ＩＤ１から順に表示しているが、実際には、来店曜日や、来店時間、退店時間に、一定の傾向が見られないユーザーの場合には、その遊技履歴データは、この表８に表示されない。
【００２４】
上記のような、ユーザー個人の特徴となる遊技傾向に関する要素を基準にして、異なる会員ＩＤに対応する遊技履歴データを対比するようにする。具体的には、会員ＩＤ１と、会員ＩＤ３、会員ＩＤ１０のユーザーは、「９時から１２時」の入店時刻と、「１５時から１８時」の退店時刻が一致すると判断する。ただし、来店曜日については、会員ＩＤ１と会員ＩＤ１０は一致しているが、会員ＩＤ１のデータと会員ＩＤ３のデータとは一致していないと判断する。
【００２５】
さらに、ユーザーによって、特定の銘柄のたばこを必ず取るというように、交換する景品の種類が決まっていることがある。このような交換景品の種類も、類似性の判定基準とすることができる。この場合には、景品交換履歴も、遊技履歴データとして、記憶させておく必要がある。
ただし、類似性の判定基準とする要素は、上記のものに限らない。また、遊技傾向や、交換景品の種類などから類似性を判定する際には、１つの要素だけではなく、複数の要素について、同時に一致が有った場合に、遊技履歴データの類似と判定するようにした方が、より正確な判定ができる。
また、遊技履歴データの類似性を判定する基準項目のなかで、それらが一致することが必須である必須項目と、それ以外の選択項目とを設定することができる。上記必須項目とは、異なる会員ＩＤに対応する遊技履歴データ間で、それらを類似と判定するためには、その項目のデータの一致がなければならないという項目である。一方、選択項目とは、必須項目以外の複数の項目で、それらの項目のうち、所定値以上の項目に一致が有った場合に、類似と判断するというような項目である。
【００２６】
そして、遊技履歴データに係わる項目のうち、どの項目を必須項目として、どの項目を選択項目とするのかということは、各店舗や、システムで決めれば良いことである。例えば、その店舗のユーザーの遊技履歴データや、その他の情報から、その店舗のユーザーは、決まった曜日にしか来店しないし、入店時刻や、退店時刻が一定しているということがわかっていた場合には、入店時刻、退店時刻、来店曜日を必須項目とすればよい。
【００２７】
また、ステップＳ３で、上記類似候群の会員ＩＤから除いた会員ＩＤは、全てが、同日同時刻の遊技履歴を持っているということではない。例えば、会員ＩＤ１の類似群に含まれる会員ＩＤ２の遊技履歴データの中に、会員ＩＤ１の遊技履歴と同日同時刻の履歴が含まれていた場合、上記会員ＩＤ１と会員ＩＤ２は、同一ユーザーの可能性が無いので、会員ＩＤ２を類似候補群ＩＤから除く。また、会員ＩＤ１と会員ＩＤ３に同日同時刻の遊技履歴が含まれていた場合、会員ＩＤ１と会員ＩＤ３は、同一ユーザーの可能性が無いので、上記類似群候補ＩＤから会員ＩＤ３を除く。つまり、会員ＩＤ２、会員ＩＤ３が上記会員ＩＤ１の類似候補群ＩＤから除かれることになるが、会員ＩＤ２と会員ＩＤ３とが、同日同時刻の遊技履歴を持っているとは限らない。
【００２８】
次に、データセンターサーバー２の処理部５の、同一ユーザーの判定手順が、上記第１実施例とは異なる、第２実施例を説明する。
ただし、システムの全体構成は、図１に示す第１実施例と同じなので、この第２実施例の説明にも、図１を用いる。また、ホールコンピュータ１からデータセンターサーバー２へ、送信されるデータおよび、データセンターサーバー２の記憶部６で記憶している遊技履歴データは、第１実施例と同様である。
【００２９】
この第２実施例で、データセンターサーバー２の処理部５が、収集した遊技履歴データから、同一ユーザーに重複して割り当てられた会員ＩＤを特定し、ひとりのユーザーの遊技履歴データを統合する手順を、図５のフローチャートに従って説明する。
ステップＳ１１で、処理部５は、個々の会員ＩＤについて、その遊技履歴データの中に、他の会員ＩＤの遊技例歴と同日同時刻の遊技履歴が含まれるかどうかをチェックする。
【００３０】
次にステップＳ１２で、同日同時刻の遊技履歴を持つ会員ＩＤのグループを抽出して、抽出された組み合わせ以外の全ての組み合わせを同一候補群として記憶する。
上記ステップＳ１２の処理を、図６の表９を用いて説明する。簡単のため、ここでは、会員ＩＤは１〜７ということにする。例えば、会員ＩＤ１〜７までの中で、同日同時刻の遊技履歴を持つ会員ＩＤの組が「１，２，３」のグループａと、「５，６」のグループｂの二組あり、会員ＩＤ４は、どの遊技履歴データとも、同日同時刻の遊技履歴を持たなかったとする。
【００３１】
このステップＳ１２では、上記の２つのグループａ、ｂ内の会員ＩＤは、同一ユーザーの可能性が無いということである。反対に、それ以外の組み合わせでは、同一ユーザーの可能性があるということなので、同一の可能性の有る全ての組み合わせを、同一候補群として作成し、記憶する。具体的には、会員ＩＤ１は、会員ＩＤ２や会員ＩＤ３とは同一ユーザーの可能性が無く、会員ＩＤ４、５、６とは同一ユーザーの可能性が有る。ただし、会員ＩＤ５と会員ＩＤ６は、同一ユーザーとなり得ないので、同一ユーザーの可能性のある組み合わせは、図６の右側に示したグループ▲１▼〜▲６▼である。これらのグループ▲１▼〜▲６▼を同一候補群として記憶する。
【００３２】
ステップＳ１３で、全ての同一候補群について、その同一候補群の中の遊技履歴データの類似性をチェックする。そして、ステップＳ１４で、同一候補群内で、類似性があると判定した遊技履歴データに対応する会員ＩＤを同一ユーザーのものと判断する。例えば、図６のグループ▲１▼については、会員ＩＤ１、４、５の遊技履歴データの類似性をチェックする。類似性のチェックは、上記第１実施例で説明したような基準に従う。ただし、各グループは、その中の会員ＩＤが全て同一ユーザーのものである可能性も有るが、その中の一部が、同一ユーザーのものである可能性も含んでいる。例えば、グループ▲１▼の会員ＩＤ１，会員ＩＤ４，会員ＩＤ５のうち、会員ＩＤ１と会員ＩＤ５とが同一ユーザーのものであり、会員ＩＤ４は、別ユーザーのものであるということもある。
【００３３】
その結果、会員ＩＤ１と、会員ＩＤ４のデータが類似ならば、会員ＩＤ１と会員ＩＤ４とは同一ユーザーと判断するし、会員ＩＤ１と、会員ＩＤ５のデータが、類似なら、会員ＩＤ１と会員ＩＤ５が同一ユーザーと判断する。また、会員ＩＤ１，４、５が同一ユーザーのものと判断されることもある。
そして、上記同一候補群の１つのグループにおいて、同一ユーザーの複数の会員ＩＤを特定した場合には、その会員ＩＤを他の同一候補群の各グループから除いて、類似性のチェックを行う。
【００３４】
例えば、会員ＩＤ１と会員ＩＤ４が、同一ユーザーのものと判断された場合には、会員ＩＤ１と会員ＩＤ４は、これ以外の会員ＩＤと、ユーザーの同一性を判定する必要がないからである。
ステップＳ１５では、上記ステップＳ１４で同一ユーザーのものと判断した会員ＩＤの遊技履歴データをまとめる。
以上により、同一ユーザーが、複数の会員ＩＤを利用していた場合でも、それを見つけ出して、遊技履歴データを統合することができる。
【００３５】
上記第１，第２実施例では、遊技履歴データから、個人の遊技傾向を解析して、その傾向から、同一ユーザーを判定するようにしているが、会員ＩＤに対応づけて、氏名、生年月日、住所、電話番号、メールアドレス等の、基本属性データを記憶しておけば、この基本属性データに基づいて、同一ユーザーを特定することができる。会員ＩＤ発行時に登録した基本属性データに間違いが無ければ、遊技履歴データから同一性を推定するよりも、正確な判断ができる。
【００３６】
さらに、上記第１、第２実施例では、データセンターサーバー２の処理部５で、複数の店舗から送信されたデータを処理して、管理する例を説明したが、店舗を越えたデータの集計を必要としない場合には、上記データセンターサーバー２の機能を、各店舗に設けて、例えば、ホールコンピュータ１が行うようにすることもできる。
【００３７】
さらに、各店舗のホールコンピュータ１からデータセンターサーバー２へ送信するデータが、図２に示すように、会員ＩＤ毎にまとめた遊技履歴データではなく、遊技台毎の遊技台データである第３実施例を説明する。
ただし、上記遊技台データは、図７に示す表１０のように、遊技台ＩＤなどの遊技台特定情報毎に、遊技した会員ＩＤごとの遊技履歴を対応づけたデータである。１つの遊技台で複数のユーザーが遊技することがあるので、遊技台ＩＤ毎に、複数の会員の、その遊技台に限った遊技履歴が対応づけられている。
【００３８】
例えば、表１０では、遊技台ＩＤＧ１に対応するデータとして、この遊技台で、会員ＩＤ１のユーザーが９時から１５時まで遊技し、会員ＩＤ５のユーザーが１５時から２０時まで遊技したことが示されている。そして、それぞれの会員ＩＤには、そのユーザーの使用金額やアウト数、セーフ数などのデータが対応づけられている。
なお、この第３実施例でも、システムの全体構成は、図１に示す第１実施例と同じなので、第３実施例の説明にも図１を用いる。
【００３９】
そして、データセンターサーバー２の処理部５は、ホールコンピュータ１から受信した、図７に示す遊技台ＩＤ毎のデータを、会員ＩＤ毎にまとめる機能を備えている。処理部５は、遊技履歴データを会員ＩＤ毎にまとめたら、その後は、図３に示す第１実施例の処理手順と同様にして、同一ユーザーの会員ＩＤの重複を特定し、同一ユーザーの遊技履歴データを統合する。
また、図５に示す第２実施例と同様の手順によって、同一ユーザーの重複する会員ＩＤを特定し、データを統合することもできる。
【００４０】
これにより、ユーザー毎の履歴データを正確に把握することができる。
なお、この第３実施例では、ホールコンピュータ１が、各遊技台３のデータと会員ＩＤとを対応づけて、遊技台ＩＤ毎にまとめ、そのデータを、データセンターサーバー２へ送信するようにしているが、個々の遊技台３のデータを、直接、データセンターサーバー２へ送信するようにしてもよい。その場合には、個々の遊技台３や、遊技台３に対応して設けた台コンピュータなどに、ＩＰアドレスを割り振って、直接インターネットＮに接続する必要があるが、ホールコンピュータ１は不要になる。
【００４１】
なお、上記第１〜第３実施例では、このシステムを利用する遊技場が、チェーン店であって、ユーザーは、共通の会員カードを用いることを原則としている。ただし、もともと、異なる会員カードを発行する店舗のデータをデータセンターサーバー２が、管理するようにした場合でも、この発明のシステムを用いて、同一ユーザーを特定することができる。同一ユーザーを特定すれば、店舗毎の異なる会員ＩＤの対応テーブルを作成することができ、それに基づいて、同一ユーザーの遊技履歴データを、店舗を越えて統合し、解析することもできる。
【００４２】
図８に示す第４実施例は、複数の遊技場が、遊技履歴データベースと、会員の基本属性を会員ＩＤに対応づけて記憶したユーザー属性データベースとを備えている例である。
図８に示すように、遊技場である店舗Ａ、Ｂ、Ｃは、それぞれ、遊技履歴データベース１１ａ，１１ｂ，１１ｃを備えている。これらの遊技履歴データベース１１ａ，１１ｂ，１１ｃは、それぞれの店舗を利用するユーザーの会員ＩＤにその遊技履歴を対応づけたデータを記憶したものであり、例えば、図２に示す第１実施例の遊技履歴データと同様のデータが記憶されている。
【００４３】
また、店舗Ａには、店舗Ａのユーザー会員の氏名や住所などの基本属性を記憶したユーザー属性データベース１２ａを備え、店舗Ｂ、Ｃには、店舗Ｂ、Ｃのユーザーのユーザー属性データベース１２ｂを備えている。そして、店舗Ｂと店舗Ｃでは、共通の会員カードを利用できるようにしている。
そして、この第４実施例では、店舗Ｂと店舗Ｃは、同系列のチェーン店で、共通のユーザー属性データベース１２ｂを用いている。また、各データベース１１ａ，１１ｂ，１１ｃ，１２ａ，１２ｂは、直接インターネットＮに接続可能にしていても良いし、ホールコンピュータのような別のコンピュータを介してインターネットＮに接続するようにしてもよい。要するに、各データベースのデータをデータセンターサーバー２へ送信できればよい。
【００４４】
各店舗からは、各遊技履歴データベース１１ａ，１１ｂ，１１ｃの遊技履歴データと、ユーザー属性データベース１２ａ、１２ｂを送信し、データセンターサーバー２では、それを記憶部６に記憶させる。
上記遊技履歴データベースは、会員が遊技することによってその内容が更新されるし、ユーザー属性データベースも、新会員の登録によって内容が更新される。従って、定期的あるいは、更新されたときに、更新されたデータのみを、データセンターサーバー２へ送信するようにしている。
なお、各店舗からデータセンターサーバー２へ、データを送信する際には、そのデータがどの店舗のデータなのかということを特定できる信号を付加するようにしている。
【００４５】
データセンターサーバー２の処理部５は、記憶部６に記憶している遊技履歴データに対応している会員ＩＤの中に、同一ユーザーに対して発行された異なる会員ＩＤがあるかどうかを判定する機能を備えている。上記同一ユーザーに対して複数の会員ＩＤが発行される場合としては、すでに会員登録が済んでいるユーザーが、会員カードを忘れて来店したときに、重複発行してしまうような場合と、上記店舗Ａと、店舗Ｂの用に、初めから別々のカードシステムを用いて、同一ユーザーに対して、各店舗用の会員ＩＤを発行する場合とがある。
この第３実施例のシステムは、上記どちらの場合でも、同一ユーザーに発行された複数の会員ＩＤがあれば、それを特定することができる。
【００４６】
以下に、データセンターサーバー２の処理部５が、記憶部６に記憶させている遊技履歴データおよびユーザー属性データベースから、同一ユーザーの会員ＩＤを判定する手順を図９のフローチャートに従って説明する。
ここでは、データセンターサーバー２の記憶部６には、各店舗から送信された遊技履歴データと、ユーザー属性データベース１２ａ，１２ｂのデータがすでに記憶されているものとする。
【００４７】
ステップＳ１０１で、処理部５は、記憶部６に記憶されている遊技履歴データのうち、特定の遊技履歴データ、例えば、遊技履歴データＸ１に対応するユーザー属性データベースを特定する。上記遊技履歴データＸ１が、店舗Ａから受信したデータであれば、この遊技履歴データＸ１に対応するユーザー属性データベース１２ａが特定される。
ステップＳ１０２では、特定したユーザー属性データベース１２ａから、遊技履歴データＸ１に対応するユーザー属性データＹ１を特定する。このユーザー属性データＹ１の特定は、遊技履歴データＸ１に対応する会員ＩＤによって行う。
【００４８】
次に、ステップＳ１０３で、記憶部６に記憶している遊技履歴データに対応するユーザー属性データを特定する。ステップＳ１０４では、上記ステップＳ１０３で特定したユーザー属性データから、上記ユーザー属性データＹ１と同一のユーザー属性データを検索する。
ユーザー属性データＹ１と同一のユーザー属性データが有った場合、ステップＳ１０５で、同一のユーザー属性データを持つ、異なる会員ＩＤを同一ユーザーの会員ＩＤと判定する。この際、ユーザー属性データベース１２ａと１２ｂとで属性データとして、登録されている内容が異なる場合がある。例えば、１２ａには、氏名、生年月日、住所が登録されており、１２ｂには、氏名、生年月日、メールアドレス、電話番号が登録されいる場合、氏名と生年月日から、同一ユーザーであるということを判断する。これにより、店舗によってフォーマットの異なる属性データベースが使用されている場合においても、同一ユーザーの判断ができる。
以上のステップＳ１０１〜Ｓ１０５を、全ての遊技履歴データについて繰り返し、ステップＳ１０６で、同一ユーザーの会員ＩＤに対応する遊技履歴データを統合する。
【００４９】
以上で、同一ユーザーに対して発行した複数の会員ＩＤを特定し、ユーザー毎に遊技履歴データをまとめることができる。
なお、この第４実施例では、各店舗からデータセンターサーバー２へデータを送信する際に、そのデータの発信元を特定するデータを付加しているので、処理部５は、その発信元から、受信した遊技履歴データに対応するユーザー属性データベースを特定することができる。ただし、データセンターサーバー２側で、発信元店舗と、ユーザー属性データベースとの対応関係を記憶している必要がある。あるいは、店舗側が遊技履歴データを送信するたびに、対応するユーザー属性データベースを特定する情報を送るようにしてもよい。
【００５０】
また、上記ステップＳ１０３、Ｓ１０４において、記憶部６に記憶している遊技履歴データに対応するユーザー属性データを特定し、そのユーザー属性データのなかで、特定のユーザー属性データＹ１と同一なユーザー属性データを検索するようにしている。このように、特定のユーザー属性データとの同一を判定する対象を、記憶部６に記憶している遊技履歴データに対応するユーザー属性データに限ったのは、この実施例では、同一ユーザーの遊技履歴データを統合することを目的としているからである。遊技履歴データの統合を目的としていえる場合、遊技履歴データを持たないユーザーの同一性までも判定する必要がないし、同一性を判定するために対比するユーザー属性データ数が少ない方が、処理が速く済むためである。
【００５１】
例えば、遊技履歴データがないユーザーのユーザー属性データについての同一性のチェックを行って、異なる会員ＩＤが同一ユーザーのものであることが判定できても、統合すべき遊技履歴データがなければ、遊技履歴データの統合ができない。ただし、複数の会員ＩＤが同一ユーザーのものであることを判定することを目的とする場合には、ユーザー属性データベースの中の、全てのユーザー属性データ内で、同一性を判定するようにしてもよい。また、異なる会員ＩＤの対応関係を判定して記憶しておけば、遊技履歴データが送信されたときに、改めて、ユーザー属性データの同一性をチェックする必要はない。
【００５２】
以上、第１〜第４実施例のシステムによって、同一ユーザーが、複数の会員ＩＤを持っていたとしても、データセンターサーバー２では、ユーザー単位で、遊技履歴データを管理することができる。
また、上記のような遊技履歴データを管理し、分析することにより、その遊技傾向の変化などから、そのユーザーの生活環境の変化を推定することもできる。例えば、平日の日中、毎日のように遊技していたユーザーが、ある時点から、平日の夜や休日にしか遊技しなくなった場合、定職に就いたと推測できる。また、遊技場からの退店時刻が、以前より早くなったり、遊技時間が短くなったりしている場合、遊技に飽きてきていると推測することもできる。
【００５３】
【発明の効果】
第１〜第４の発明によれば、同一ユーザーに重複して会員ＩＤなどのユーザー特定情報を発行した場合でも、それらが、同一ユーザーのものであることを突き止めることができる。それにより、各ユーザー特定情報に対応した遊技履歴データを、ユーザー毎に管理したり、解析したりすることができる。
第３、第４の発明では、ユーザーの属性データを用いることにより、同一ユーザーをより正確に判定することができる。
【００５４】
特に、第３の発明では、遊技台特定情報毎にデータをまとめて記憶部に記憶させるようにしているので、遊技場から上記記憶部にデータを出力する際にも、ユーザー特定情報毎にデータをまとめる処理は行わないで、遊技台のデータをそのまま出力することもできる。そのため、例えば、ホールコンピュータのように、店舗単位のコンピュータを不要にすることができる。
さらに、第４の発明では、異なる店舗間で、異なるユーザー属性データベースを用いているような場合にでも、それらの間で、同一ユーザーを特定することができる。
第５の発明によれば、ユーザーごとの遊技履歴データの統合が、自動的にできる。
【図面の簡単な説明】
【図１】第１実施例のシステム構成図である。
【図２】第１実施例の遊技履歴データである。
【図３】第１実施例の、同一ユーザーの遊技履歴データを統合する手順を示したフローチャートである。
【図４】第１実施例のユーザーの遊技履歴データをもとにして、遊技傾向を示した表である。
【図５】第２実施例の、同一ユーザーの遊技履歴データを統合する手順を示したフローチャートである。
【図６】第２実施例の、同一候補群を説明するための表である。
【図７】第３実施例の遊技台データを示した表である。
【図８】第４実施例のシステム構成図である。
【図９】第４実施例の、同一ユーザーの遊技履歴データを統合する手順を示したフローチャートである。
【符号の説明】
２ データセンターサーバー
５ 処理部
６ 記憶部
１１ａ，１１ｂ，１１ｃ 遊技履歴データベース
１２ａ，１２ｂ ユーザー属性データベース
【発明の属する技術分野】
この発明は、パチンコ店などの遊技場において、会員ユーザーの遊技履歴データを管理するシステムに関する。
【０００２】
【従来の技術】
遊技場の中には、ユーザーに会員カードを発行し、各会員の遊技履歴データを管理しているところがある。上記会員カードには、会員ＩＤが記憶されていて、ユーザーは、自分が使用する遊技台に対応して設置されているカード読み取り機に、会員カードを挿入して、会員ＩＤを読み取らせてから遊技をする。
このカード読み取り機が読み取った会員ＩＤや、遊技台から出力される遊技データは、ホールコンピュータへ送信され、集計される。ホールコンピュータでは、受信したデータを、遊技台毎の遊技台データとして集計したり、会員ＩＤ毎に、個々の会員の遊技履歴データとして集計したりする。
【０００３】
なお、上記遊技台データとは、その遊技台におけるアウト数、セーフ数、賞球数、特賞回数、スタート回数などのデータである。上記アウト数とは、遊技台から打ち出された玉数で、セーフ数とは、入賞した玉数である。また、上記特賞回数とは、図柄部が回転して、それが特定の図柄パターンで停止したとき、多数の玉が払い出される状況、いわゆる大当たりのことであり、スタート回数とは、特定の入賞口への入賞によって上記図柄部が回転した回数のことである。また、玉貸しが行われる際には、その玉貸し金額も、遊技台データに含むこともある。
【０００４】
また、遊技履歴データとは、会員ＩＤ毎に、その会員が、いつ、どの台で遊技し、そのときの遊技状況がどうであったかということを記憶したデータである。
このような遊技履歴データを、収集するためには、会員が、遊技中にカード読み取り機に会員カードを挿入しなければならない。
ホールコンピュータが収集した遊技履歴データは、各会員の遊技履歴に基づいて、ポイントを付与して、そのポイントに応じたサービスをするために利用されるだけでなく、サービスの参考にするために、上記遊技履歴データに基づいて、ユーザーの遊技傾向を分析することもある。例えば、各ユーザーの遊技時間の合計や、平均遊技時間を算出したり、玉貸し金額に対するユーザー分布を算出したりする。
【０００５】
また、チェーン店などでは、各店舗のホールコンピュータで集計した遊技履歴データをチェーン店本部に送信して、本部のコンピュータで、チェーン全体のデータを管理することもある（特許文献１参照）。
【０００６】
【特許文献１】
特開平９−１７３５９２号公報
【０００７】
【発明が解決しようとする課題】
上記会員カードは、ユーザーの希望に応じて発行し、１ユーザーに一枚のカードを発行するのが通常であるが、同一ユーザーに、複数の会員カード、すなわち複数の会員ＩＤを発行してしまうことがある。例えば、ユーザーが、会員カードを紛失してしまったり、忘れてしまったりしたときに、そのことを店舗側に伝えないで、新規会員として登録してしまった時などに、会員カードの重複発行が起こる。
【０００８】
このように、同一ユーザーに対して、複数の会員ＩＤが発行され、それぞれが利用された場合、ひとりのユーザーの遊技履歴データが複数の会員ＩＤに分散して記憶されることになる。そのため、一人一人の履歴データが、正確に集計できないという問題がある。また、実際のユーザー数よりも会員ＩＤの数の方が多いので、正確な来店者数がわからないなど、遊技データから、正確なユーザーの状況を把握することができないという問題もあった。
この発明の目的は、同一ユーザーが複数会員ＩＤを使用して遊技を行った場合であっても、ユーザー単位の遊技履歴データを、正確に管理できるようにすることである。
【０００９】
【課題を解決するための手段】
第１の発明は、記憶部と、処理部とからなる遊技履歴データ管理システムであり、上記記憶部は、ユーザー特定情報に対応した遊技履歴データを記憶する機能を備え、上記処理部は、上記記憶部の遊技履歴データのうち同一または類似の遊技履歴データを有する類似群のユーザー特定情報を抽出する機能と、上記履歴データから同日同時刻に遊技した履歴の有無を判定する機能と、上記類似群のユーザー特定情報のうち同日同時刻の遊技履歴を持たないユーザー特定情報を同一ユーザーのユーザー特定情報と判定する機能とを備えた点に特徴を有する。
【００１０】
第２の発明は、記憶部と、処理部とからなる遊技履歴データ管理システムで、上記記憶部は、ユーザー特定情報に対応した遊技履歴データを記憶する機能を備え、上記処理部は、上記履歴データから同日同時刻に遊技した履歴の有無を判定し、同日同時刻の遊技履歴を持たない同一候補群のユーザー特定情報を抽出する機能と、上記記憶部の遊技履歴データのうち同一または類似の遊技履歴データを判定する機能と、同日同時刻の遊技履歴を持たない同一候補群のユーザー特定情報群のうち同一または類似の履歴データに対応するユーザー特定情報を同一ユーザーのユーザー特定情報と判定する機能とを備えた点に特徴を有する。
【００１１】
第３の発明は、記憶部と、処理部とからなり、上記記憶部は、遊技台特定情報毎に、ユーザー特定情報毎の遊技履歴データを対応づけた遊技台データと、ユーザー特定情報に対応づけた氏名や住所などのユーザー属性データとを記憶する機能とを備え、上記処理部は、ユーザー特定情報毎に遊技履歴データを集計するとともに、上記複数のユーザー属性データのうち同一属性を有する属性データを判定する機能と、ユーザー属性データが同一である異なるユーザー特定情報を同一のユーザーのユーザー特定情報と判定する機能とを備えた点に特徴を有する。
なお、上記ユーザー属性データの同一とは、属性データの全ての項目が同一であるということではない。例えば、ユーザー属性データのうち、氏名だけが一致した場合、あるいは、氏名と生年月日だけが一致した場合など、部分的に一致した場合でも、同一のユーザーと判定することがある。
【００１２】
第４の発明は、ユーザー特定情報に対応する氏名や住所などのユーザー属性データを記憶した複数のユーザー属性データベースと、これらユーザー属性データベースに対応し、かつ、ユーザー特定情報に対応する遊技履歴データを記憶した遊技履歴データベースと、これらのデータベースと通信手段を介して接続した処理部と、記憶部とからなり、上記処理部は、上記データベースから複数のユーザー属性データベースおよびそれに対応した遊技履歴データを受信してそれを記憶部に記憶させる機能と、上記記憶部が記憶している遊技履歴データに対応したユーザー属性データベースの中から、上記遊技履歴データ内のユーザー特定情報に対応するユーザー属性を特定する機能と、特定したユーザー属性と同一のユーザー属性をユーザー属性データベースから抽出する機能と、抽出された同一の属性データに対応するユーザー特定情報を同一のユーザーのユーザー特定情報と判定する機能とを備えた点に特徴を有する。
【００１３】
第５の発明は、上記第１から第４の発明のいずれか１つの発明を前提とし、処理部が、同一ユーザーのユーザー特定情報と判定したユーザー特定情報に対応した遊技履歴データを統合する機能を備えた点に特徴を有する。
【００１４】
【発明の実施の形態】
図１〜図４に示す第１実施例は、インターネットＮに接続可能にしたホールコンピュータ１と、データセンターサーバー２とを備えたシステムである。
図１に示すように、ホールコンピュータ１は、各店舗に設置され、各ホールコンピュータ１には、複数の遊技台３とそれに対応するカード読み取り機４とが接続されている。
カード読み取り機４は、ユーザー用に発行した会員カードの会員ＩＤを読み取る装置であり、各遊技台３の遊技台データとともに、ホールコンピュータ１へ送信される。
なお、この第１実施例では、複数の店舗は同系列のチェーン店であり、チェーン店間では、同じ会員カードを共通に利用できるようにしている。
【００１５】
また、データセンターサーバー２は、処理部５と、記憶部６とを備えている。これら、処理部５や記憶部６は、ハード的に構成するだけでなく、ソフト的に実現することもできる。
ホールコンピュータ１側では、一定時間ごと、この第１実施例では、閉店後に、遊技履歴データをデータセンターサーバー２に送信する。
ホールコンピュータ１では、図２に示すような遊技履歴データを記憶する。
図２の表７は、会員ＩＤごとに整理された遊技履歴データである。この表７は、会員ＩＤ欄７ａの隣に、来店日欄７ｂ、遊技時間欄７ｃを設け、さらに右側には、台番号欄７ｄ、機種名欄７ｅ、遊技台データ欄７ｄを設けている。この第１実施例では、ホールコンピュータ１が、毎日、閉店後に遊技履歴データをデータセンターサーバー２へ送信するようにしているので、ホールコンピュータ１は、１日分のデータだけを記憶しておけばよい。
【００１６】
つまり、表７のデータは、来店日欄７ｂに対応する日の会員ＩＤ毎の遊技履歴データである。例えば、会員ＩＤ１のユーザーが、「何時から何時まで、どの遊技台で、遊技し、どのような遊技状況であったのか」というデータである。遊技時間欄７ｃのデータが、何時から何時まで遊技したのかというデータであり、台番号欄７ｄおよび機種名欄７ｅが遊技した遊技台を特定するデータで、その他、使用金額、アウト数、セーフ数、…、などの遊技台データ欄７ｆのデータが、遊技状況である。
【００１７】
そして、ユーザーは、来店してから退店するまでに、遊技台を変えることが有る。そのような場合には、遊技台を変える毎に、図２の表７の右側へ、遊技時間欄７ｃ、遊技台欄７ｄ，機種名欄７ｅ、遊技台データ欄７ｆを繰り返し、そこにデータが入力される。例えば、図２からは、会員ＩＤ１のユーザーは、１０時から１２時まで、ある遊技台で遊技し、その後、遊技台を移って、さらに１３時から１９時まで遊技したことがわかる。
また、正確な入店時刻や退店時刻を、遊技履歴データとして収集するためには、入店時や退店時に専用のカード読み取り機に会員ＩＤを読み取らせる必要がある。
【００１８】
このような遊技履歴データをホールコンピュータ１が、データセンターサーバー２へ送信すると、データセンターサーバー２の処理部５は、会員ＩＤ毎に、全ての遊技履歴データを記憶部６に記憶させる。つまり、データセンターサーバー２の記憶部６には、図２に示すような１日分の遊技履歴データが何日分も蓄積されている。
また、この実施例では、データセンターサーバー２に接続可能なホールコンピュータ１は、全て、同一チェーン店のものなので、全ての店舗に来店するユーザーの遊技履歴を、店舗別ではなく、会員ＩＤによって統合することができる。
しかし、実際には、一人のユーザーが、複数の会員カードを持っていることもあるので、処理部５は、そのような会員ＩＤの重複発行を突き止める機能を備えている。
【００１９】
処理部５が、収集した遊技履歴データから、同一ユーザーに重複して割り当てられた会員ＩＤを特定し、ひとりのユーザーの遊技履歴データを統合する手順を、図３のフローチャートに従って説明する。
ステップＳ１で、処理部５は、全ての会員ＩＤの組み合わせで、遊技履歴データの類似性をチェックする。ここでは、ステップＳ１として、１ステップで表現しているが、実際には、次のような多数の処理が含まれる。具体的には、会員ＩＤ１の遊技履歴データと、会員ＩＤ２の遊技履歴データとを対比して、同一または類似であるかを判定し、次に、会員ＩＤ１のデータと、会員ＩＤ３のデータとを対比して類似性を判定し、さらに、会員ＩＤ１と会員ＩＤ４のデータを対比し、というように、全てのデータを対比してゆく。そして、個々の会員ＩＤのデータについて、類似のデータを持つ会員ＩＤを特定する。
例えば、会員ＩＤが１〜１０００まである場合、特定の会員ＩＤの遊技履歴データに対し、残りの９９９の会員ＩＤに対応する遊技履歴データを対比して、それぞれ、類似性を判定する。なお、類似の判定基準については、後で説明する。
【００２０】
このステップＳ１で、類似と判定した場合、ステップＳ２で、類似の遊技履歴データに対応する会員ＩＤを類似群として記憶する。このとき、類似群は、特定の会員ＩＤｎ毎にできるので、複数できることもある。例えば、会員ＩＤ１の遊技履歴データと、会員ＩＤ２の遊技履歴データは類似していないが、それぞれのデータに類似している遊技履歴データがある場合、会員ＩＤ１の類似群と、会員ＩＤ２の類似群とができる。
ステップＳ３で、会員ＩＤｎの類似群に含まれる会員ＩＤに対応する遊技データの中で、上記会員ＩＤｎの遊技履歴と同日同時刻の遊技履歴を持つ会員ＩＤをその類似群から除いて、ステップＳ４で、１つの類似群内の会員ＩＤを同一ユーザーのものとする。上記ステップＳ３で、同日同時刻に遊技履歴を持つ会員ＩＤを除くのは、同日同時刻に、一人のユーザーが、複数の会員ＩＤを用いて遊技することはできないはずだからである。
【００２１】
ステップＳ５では、上記ステップＳ４で同一ユーザーと判定した会員ＩＤに対応する遊技履歴データを、ひとりのユーザーの遊技履歴データとしてまとめる。これにより、同一ユーザーが、複数の会員カードを持っていて、つまり、複数の会員ＩＤを使っていた場合に、そのことを突き止めて、遊技履歴データをまとめることができる。従って、会員ＩＤだけから、別々のユーザーの遊技履歴データと見なしてデータ分析を行う場合に比べて、実際に即した正確なデータ分析ができる。
【００２２】
なお、図３のステップＳ１での、遊技履歴データの類似性の判定基準には、様々なものが利用できるが、例えば、以下のようなものが考えられる。
類似性の判定基準として、利用できる要素には、遊技場への来店時刻や、退店時刻の特徴や、来店曜日の特徴などがある。例えば、開店と同時に来店するとか、夜しか来店しないとか、必ず閉店まで遊技しているというような特徴や、決まった曜日にしか来店しないというようなことである。
また、遊技時間が、いつでも決まっているとか、遊技開始から一定時間内に、特賞が無ければ帰ってしまうとか、ユーザーによっては、決まった行動パターンをとることがある。そのため、平均滞在時間や、遊技時間帯も、類似性の判定要素にすることができる。
【００２３】
そして、各ユーザーの遊技履歴を対比する際には、各遊技履歴データの傾向を図４の表８のように整理することがある。図４では、遊技場の１日の営業時間帯を３時間単位で区切って、入店時刻および退店時刻をその単位時間帯で表している。そして、一定期間、例えば、過去１ヶ月の遊技履歴データから、入店時刻や、退店時刻が、特定の時間帯に限られているか、その時間帯が多い場合、その時間帯を示している。また、来店曜日も、履歴データから、回数の多い曜日を抽出して、それを示している。つまり、この表８から、会員ＩＤ１のユーザーは、水曜日の９時から１２時の間に来店し、１５時から１８時に退店することが多いということである。この表８には、会員ＩＤ１から順に表示しているが、実際には、来店曜日や、来店時間、退店時間に、一定の傾向が見られないユーザーの場合には、その遊技履歴データは、この表８に表示されない。
【００２４】
上記のような、ユーザー個人の特徴となる遊技傾向に関する要素を基準にして、異なる会員ＩＤに対応する遊技履歴データを対比するようにする。具体的には、会員ＩＤ１と、会員ＩＤ３、会員ＩＤ１０のユーザーは、「９時から１２時」の入店時刻と、「１５時から１８時」の退店時刻が一致すると判断する。ただし、来店曜日については、会員ＩＤ１と会員ＩＤ１０は一致しているが、会員ＩＤ１のデータと会員ＩＤ３のデータとは一致していないと判断する。
【００２５】
さらに、ユーザーによって、特定の銘柄のたばこを必ず取るというように、交換する景品の種類が決まっていることがある。このような交換景品の種類も、類似性の判定基準とすることができる。この場合には、景品交換履歴も、遊技履歴データとして、記憶させておく必要がある。
ただし、類似性の判定基準とする要素は、上記のものに限らない。また、遊技傾向や、交換景品の種類などから類似性を判定する際には、１つの要素だけではなく、複数の要素について、同時に一致が有った場合に、遊技履歴データの類似と判定するようにした方が、より正確な判定ができる。
また、遊技履歴データの類似性を判定する基準項目のなかで、それらが一致することが必須である必須項目と、それ以外の選択項目とを設定することができる。上記必須項目とは、異なる会員ＩＤに対応する遊技履歴データ間で、それらを類似と判定するためには、その項目のデータの一致がなければならないという項目である。一方、選択項目とは、必須項目以外の複数の項目で、それらの項目のうち、所定値以上の項目に一致が有った場合に、類似と判断するというような項目である。
【００２６】
そして、遊技履歴データに係わる項目のうち、どの項目を必須項目として、どの項目を選択項目とするのかということは、各店舗や、システムで決めれば良いことである。例えば、その店舗のユーザーの遊技履歴データや、その他の情報から、その店舗のユーザーは、決まった曜日にしか来店しないし、入店時刻や、退店時刻が一定しているということがわかっていた場合には、入店時刻、退店時刻、来店曜日を必須項目とすればよい。
【００２７】
また、ステップＳ３で、上記類似候群の会員ＩＤから除いた会員ＩＤは、全てが、同日同時刻の遊技履歴を持っているということではない。例えば、会員ＩＤ１の類似群に含まれる会員ＩＤ２の遊技履歴データの中に、会員ＩＤ１の遊技履歴と同日同時刻の履歴が含まれていた場合、上記会員ＩＤ１と会員ＩＤ２は、同一ユーザーの可能性が無いので、会員ＩＤ２を類似候補群ＩＤから除く。また、会員ＩＤ１と会員ＩＤ３に同日同時刻の遊技履歴が含まれていた場合、会員ＩＤ１と会員ＩＤ３は、同一ユーザーの可能性が無いので、上記類似群候補ＩＤから会員ＩＤ３を除く。つまり、会員ＩＤ２、会員ＩＤ３が上記会員ＩＤ１の類似候補群ＩＤから除かれることになるが、会員ＩＤ２と会員ＩＤ３とが、同日同時刻の遊技履歴を持っているとは限らない。
【００２８】
次に、データセンターサーバー２の処理部５の、同一ユーザーの判定手順が、上記第１実施例とは異なる、第２実施例を説明する。
ただし、システムの全体構成は、図１に示す第１実施例と同じなので、この第２実施例の説明にも、図１を用いる。また、ホールコンピュータ１からデータセンターサーバー２へ、送信されるデータおよび、データセンターサーバー２の記憶部６で記憶している遊技履歴データは、第１実施例と同様である。
【００２９】
この第２実施例で、データセンターサーバー２の処理部５が、収集した遊技履歴データから、同一ユーザーに重複して割り当てられた会員ＩＤを特定し、ひとりのユーザーの遊技履歴データを統合する手順を、図５のフローチャートに従って説明する。
ステップＳ１１で、処理部５は、個々の会員ＩＤについて、その遊技履歴データの中に、他の会員ＩＤの遊技例歴と同日同時刻の遊技履歴が含まれるかどうかをチェックする。
【００３０】
次にステップＳ１２で、同日同時刻の遊技履歴を持つ会員ＩＤのグループを抽出して、抽出された組み合わせ以外の全ての組み合わせを同一候補群として記憶する。
上記ステップＳ１２の処理を、図６の表９を用いて説明する。簡単のため、ここでは、会員ＩＤは１〜７ということにする。例えば、会員ＩＤ１〜７までの中で、同日同時刻の遊技履歴を持つ会員ＩＤの組が「１，２，３」のグループａと、「５，６」のグループｂの二組あり、会員ＩＤ４は、どの遊技履歴データとも、同日同時刻の遊技履歴を持たなかったとする。
【００３１】
このステップＳ１２では、上記の２つのグループａ、ｂ内の会員ＩＤは、同一ユーザーの可能性が無いということである。反対に、それ以外の組み合わせでは、同一ユーザーの可能性があるということなので、同一の可能性の有る全ての組み合わせを、同一候補群として作成し、記憶する。具体的には、会員ＩＤ１は、会員ＩＤ２や会員ＩＤ３とは同一ユーザーの可能性が無く、会員ＩＤ４、５、６とは同一ユーザーの可能性が有る。ただし、会員ＩＤ５と会員ＩＤ６は、同一ユーザーとなり得ないので、同一ユーザーの可能性のある組み合わせは、図６の右側に示したグループ▲１▼〜▲６▼である。これらのグループ▲１▼〜▲６▼を同一候補群として記憶する。
【００３２】
ステップＳ１３で、全ての同一候補群について、その同一候補群の中の遊技履歴データの類似性をチェックする。そして、ステップＳ１４で、同一候補群内で、類似性があると判定した遊技履歴データに対応する会員ＩＤを同一ユーザーのものと判断する。例えば、図６のグループ▲１▼については、会員ＩＤ１、４、５の遊技履歴データの類似性をチェックする。類似性のチェックは、上記第１実施例で説明したような基準に従う。ただし、各グループは、その中の会員ＩＤが全て同一ユーザーのものである可能性も有るが、その中の一部が、同一ユーザーのものである可能性も含んでいる。例えば、グループ▲１▼の会員ＩＤ１，会員ＩＤ４，会員ＩＤ５のうち、会員ＩＤ１と会員ＩＤ５とが同一ユーザーのものであり、会員ＩＤ４は、別ユーザーのものであるということもある。
【００３３】
その結果、会員ＩＤ１と、会員ＩＤ４のデータが類似ならば、会員ＩＤ１と会員ＩＤ４とは同一ユーザーと判断するし、会員ＩＤ１と、会員ＩＤ５のデータが、類似なら、会員ＩＤ１と会員ＩＤ５が同一ユーザーと判断する。また、会員ＩＤ１，４、５が同一ユーザーのものと判断されることもある。
そして、上記同一候補群の１つのグループにおいて、同一ユーザーの複数の会員ＩＤを特定した場合には、その会員ＩＤを他の同一候補群の各グループから除いて、類似性のチェックを行う。
【００３４】
例えば、会員ＩＤ１と会員ＩＤ４が、同一ユーザーのものと判断された場合には、会員ＩＤ１と会員ＩＤ４は、これ以外の会員ＩＤと、ユーザーの同一性を判定する必要がないからである。
ステップＳ１５では、上記ステップＳ１４で同一ユーザーのものと判断した会員ＩＤの遊技履歴データをまとめる。
以上により、同一ユーザーが、複数の会員ＩＤを利用していた場合でも、それを見つけ出して、遊技履歴データを統合することができる。
【００３５】
上記第１，第２実施例では、遊技履歴データから、個人の遊技傾向を解析して、その傾向から、同一ユーザーを判定するようにしているが、会員ＩＤに対応づけて、氏名、生年月日、住所、電話番号、メールアドレス等の、基本属性データを記憶しておけば、この基本属性データに基づいて、同一ユーザーを特定することができる。会員ＩＤ発行時に登録した基本属性データに間違いが無ければ、遊技履歴データから同一性を推定するよりも、正確な判断ができる。
【００３６】
さらに、上記第１、第２実施例では、データセンターサーバー２の処理部５で、複数の店舗から送信されたデータを処理して、管理する例を説明したが、店舗を越えたデータの集計を必要としない場合には、上記データセンターサーバー２の機能を、各店舗に設けて、例えば、ホールコンピュータ１が行うようにすることもできる。
【００３７】
さらに、各店舗のホールコンピュータ１からデータセンターサーバー２へ送信するデータが、図２に示すように、会員ＩＤ毎にまとめた遊技履歴データではなく、遊技台毎の遊技台データである第３実施例を説明する。
ただし、上記遊技台データは、図７に示す表１０のように、遊技台ＩＤなどの遊技台特定情報毎に、遊技した会員ＩＤごとの遊技履歴を対応づけたデータである。１つの遊技台で複数のユーザーが遊技することがあるので、遊技台ＩＤ毎に、複数の会員の、その遊技台に限った遊技履歴が対応づけられている。
【００３８】
例えば、表１０では、遊技台ＩＤＧ１に対応するデータとして、この遊技台で、会員ＩＤ１のユーザーが９時から１５時まで遊技し、会員ＩＤ５のユーザーが１５時から２０時まで遊技したことが示されている。そして、それぞれの会員ＩＤには、そのユーザーの使用金額やアウト数、セーフ数などのデータが対応づけられている。
なお、この第３実施例でも、システムの全体構成は、図１に示す第１実施例と同じなので、第３実施例の説明にも図１を用いる。
【００３９】
そして、データセンターサーバー２の処理部５は、ホールコンピュータ１から受信した、図７に示す遊技台ＩＤ毎のデータを、会員ＩＤ毎にまとめる機能を備えている。処理部５は、遊技履歴データを会員ＩＤ毎にまとめたら、その後は、図３に示す第１実施例の処理手順と同様にして、同一ユーザーの会員ＩＤの重複を特定し、同一ユーザーの遊技履歴データを統合する。
また、図５に示す第２実施例と同様の手順によって、同一ユーザーの重複する会員ＩＤを特定し、データを統合することもできる。
【００４０】
これにより、ユーザー毎の履歴データを正確に把握することができる。
なお、この第３実施例では、ホールコンピュータ１が、各遊技台３のデータと会員ＩＤとを対応づけて、遊技台ＩＤ毎にまとめ、そのデータを、データセンターサーバー２へ送信するようにしているが、個々の遊技台３のデータを、直接、データセンターサーバー２へ送信するようにしてもよい。その場合には、個々の遊技台３や、遊技台３に対応して設けた台コンピュータなどに、ＩＰアドレスを割り振って、直接インターネットＮに接続する必要があるが、ホールコンピュータ１は不要になる。
【００４１】
なお、上記第１〜第３実施例では、このシステムを利用する遊技場が、チェーン店であって、ユーザーは、共通の会員カードを用いることを原則としている。ただし、もともと、異なる会員カードを発行する店舗のデータをデータセンターサーバー２が、管理するようにした場合でも、この発明のシステムを用いて、同一ユーザーを特定することができる。同一ユーザーを特定すれば、店舗毎の異なる会員ＩＤの対応テーブルを作成することができ、それに基づいて、同一ユーザーの遊技履歴データを、店舗を越えて統合し、解析することもできる。
【００４２】
図８に示す第４実施例は、複数の遊技場が、遊技履歴データベースと、会員の基本属性を会員ＩＤに対応づけて記憶したユーザー属性データベースとを備えている例である。
図８に示すように、遊技場である店舗Ａ、Ｂ、Ｃは、それぞれ、遊技履歴データベース１１ａ，１１ｂ，１１ｃを備えている。これらの遊技履歴データベース１１ａ，１１ｂ，１１ｃは、それぞれの店舗を利用するユーザーの会員ＩＤにその遊技履歴を対応づけたデータを記憶したものであり、例えば、図２に示す第１実施例の遊技履歴データと同様のデータが記憶されている。
【００４３】
また、店舗Ａには、店舗Ａのユーザー会員の氏名や住所などの基本属性を記憶したユーザー属性データベース１２ａを備え、店舗Ｂ、Ｃには、店舗Ｂ、Ｃのユーザーのユーザー属性データベース１２ｂを備えている。そして、店舗Ｂと店舗Ｃでは、共通の会員カードを利用できるようにしている。
そして、この第４実施例では、店舗Ｂと店舗Ｃは、同系列のチェーン店で、共通のユーザー属性データベース１２ｂを用いている。また、各データベース１１ａ，１１ｂ，１１ｃ，１２ａ，１２ｂは、直接インターネットＮに接続可能にしていても良いし、ホールコンピュータのような別のコンピュータを介してインターネットＮに接続するようにしてもよい。要するに、各データベースのデータをデータセンターサーバー２へ送信できればよい。
【００４４】
各店舗からは、各遊技履歴データベース１１ａ，１１ｂ，１１ｃの遊技履歴データと、ユーザー属性データベース１２ａ、１２ｂを送信し、データセンターサーバー２では、それを記憶部６に記憶させる。
上記遊技履歴データベースは、会員が遊技することによってその内容が更新されるし、ユーザー属性データベースも、新会員の登録によって内容が更新される。従って、定期的あるいは、更新されたときに、更新されたデータのみを、データセンターサーバー２へ送信するようにしている。
なお、各店舗からデータセンターサーバー２へ、データを送信する際には、そのデータがどの店舗のデータなのかということを特定できる信号を付加するようにしている。
【００４５】
データセンターサーバー２の処理部５は、記憶部６に記憶している遊技履歴データに対応している会員ＩＤの中に、同一ユーザーに対して発行された異なる会員ＩＤがあるかどうかを判定する機能を備えている。上記同一ユーザーに対して複数の会員ＩＤが発行される場合としては、すでに会員登録が済んでいるユーザーが、会員カードを忘れて来店したときに、重複発行してしまうような場合と、上記店舗Ａと、店舗Ｂの用に、初めから別々のカードシステムを用いて、同一ユーザーに対して、各店舗用の会員ＩＤを発行する場合とがある。
この第３実施例のシステムは、上記どちらの場合でも、同一ユーザーに発行された複数の会員ＩＤがあれば、それを特定することができる。
【００４６】
以下に、データセンターサーバー２の処理部５が、記憶部６に記憶させている遊技履歴データおよびユーザー属性データベースから、同一ユーザーの会員ＩＤを判定する手順を図９のフローチャートに従って説明する。
ここでは、データセンターサーバー２の記憶部６には、各店舗から送信された遊技履歴データと、ユーザー属性データベース１２ａ，１２ｂのデータがすでに記憶されているものとする。
【００４７】
ステップＳ１０１で、処理部５は、記憶部６に記憶されている遊技履歴データのうち、特定の遊技履歴データ、例えば、遊技履歴データＸ１に対応するユーザー属性データベースを特定する。上記遊技履歴データＸ１が、店舗Ａから受信したデータであれば、この遊技履歴データＸ１に対応するユーザー属性データベース１２ａが特定される。
ステップＳ１０２では、特定したユーザー属性データベース１２ａから、遊技履歴データＸ１に対応するユーザー属性データＹ１を特定する。このユーザー属性データＹ１の特定は、遊技履歴データＸ１に対応する会員ＩＤによって行う。
【００４８】
次に、ステップＳ１０３で、記憶部６に記憶している遊技履歴データに対応するユーザー属性データを特定する。ステップＳ１０４では、上記ステップＳ１０３で特定したユーザー属性データから、上記ユーザー属性データＹ１と同一のユーザー属性データを検索する。
ユーザー属性データＹ１と同一のユーザー属性データが有った場合、ステップＳ１０５で、同一のユーザー属性データを持つ、異なる会員ＩＤを同一ユーザーの会員ＩＤと判定する。この際、ユーザー属性データベース１２ａと１２ｂとで属性データとして、登録されている内容が異なる場合がある。例えば、１２ａには、氏名、生年月日、住所が登録されており、１２ｂには、氏名、生年月日、メールアドレス、電話番号が登録されいる場合、氏名と生年月日から、同一ユーザーであるということを判断する。これにより、店舗によってフォーマットの異なる属性データベースが使用されている場合においても、同一ユーザーの判断ができる。
以上のステップＳ１０１〜Ｓ１０５を、全ての遊技履歴データについて繰り返し、ステップＳ１０６で、同一ユーザーの会員ＩＤに対応する遊技履歴データを統合する。
【００４９】
以上で、同一ユーザーに対して発行した複数の会員ＩＤを特定し、ユーザー毎に遊技履歴データをまとめることができる。
なお、この第４実施例では、各店舗からデータセンターサーバー２へデータを送信する際に、そのデータの発信元を特定するデータを付加しているので、処理部５は、その発信元から、受信した遊技履歴データに対応するユーザー属性データベースを特定することができる。ただし、データセンターサーバー２側で、発信元店舗と、ユーザー属性データベースとの対応関係を記憶している必要がある。あるいは、店舗側が遊技履歴データを送信するたびに、対応するユーザー属性データベースを特定する情報を送るようにしてもよい。
【００５０】
また、上記ステップＳ１０３、Ｓ１０４において、記憶部６に記憶している遊技履歴データに対応するユーザー属性データを特定し、そのユーザー属性データのなかで、特定のユーザー属性データＹ１と同一なユーザー属性データを検索するようにしている。このように、特定のユーザー属性データとの同一を判定する対象を、記憶部６に記憶している遊技履歴データに対応するユーザー属性データに限ったのは、この実施例では、同一ユーザーの遊技履歴データを統合することを目的としているからである。遊技履歴データの統合を目的としていえる場合、遊技履歴データを持たないユーザーの同一性までも判定する必要がないし、同一性を判定するために対比するユーザー属性データ数が少ない方が、処理が速く済むためである。
【００５１】
例えば、遊技履歴データがないユーザーのユーザー属性データについての同一性のチェックを行って、異なる会員ＩＤが同一ユーザーのものであることが判定できても、統合すべき遊技履歴データがなければ、遊技履歴データの統合ができない。ただし、複数の会員ＩＤが同一ユーザーのものであることを判定することを目的とする場合には、ユーザー属性データベースの中の、全てのユーザー属性データ内で、同一性を判定するようにしてもよい。また、異なる会員ＩＤの対応関係を判定して記憶しておけば、遊技履歴データが送信されたときに、改めて、ユーザー属性データの同一性をチェックする必要はない。
【００５２】
以上、第１〜第４実施例のシステムによって、同一ユーザーが、複数の会員ＩＤを持っていたとしても、データセンターサーバー２では、ユーザー単位で、遊技履歴データを管理することができる。
また、上記のような遊技履歴データを管理し、分析することにより、その遊技傾向の変化などから、そのユーザーの生活環境の変化を推定することもできる。例えば、平日の日中、毎日のように遊技していたユーザーが、ある時点から、平日の夜や休日にしか遊技しなくなった場合、定職に就いたと推測できる。また、遊技場からの退店時刻が、以前より早くなったり、遊技時間が短くなったりしている場合、遊技に飽きてきていると推測することもできる。
【００５３】
【発明の効果】
第１〜第４の発明によれば、同一ユーザーに重複して会員ＩＤなどのユーザー特定情報を発行した場合でも、それらが、同一ユーザーのものであることを突き止めることができる。それにより、各ユーザー特定情報に対応した遊技履歴データを、ユーザー毎に管理したり、解析したりすることができる。
第３、第４の発明では、ユーザーの属性データを用いることにより、同一ユーザーをより正確に判定することができる。
【００５４】
特に、第３の発明では、遊技台特定情報毎にデータをまとめて記憶部に記憶させるようにしているので、遊技場から上記記憶部にデータを出力する際にも、ユーザー特定情報毎にデータをまとめる処理は行わないで、遊技台のデータをそのまま出力することもできる。そのため、例えば、ホールコンピュータのように、店舗単位のコンピュータを不要にすることができる。
さらに、第４の発明では、異なる店舗間で、異なるユーザー属性データベースを用いているような場合にでも、それらの間で、同一ユーザーを特定することができる。
第５の発明によれば、ユーザーごとの遊技履歴データの統合が、自動的にできる。
【図面の簡単な説明】
【図１】第１実施例のシステム構成図である。
【図２】第１実施例の遊技履歴データである。
【図３】第１実施例の、同一ユーザーの遊技履歴データを統合する手順を示したフローチャートである。
【図４】第１実施例のユーザーの遊技履歴データをもとにして、遊技傾向を示した表である。
【図５】第２実施例の、同一ユーザーの遊技履歴データを統合する手順を示したフローチャートである。
【図６】第２実施例の、同一候補群を説明するための表である。
【図７】第３実施例の遊技台データを示した表である。
【図８】第４実施例のシステム構成図である。
【図９】第４実施例の、同一ユーザーの遊技履歴データを統合する手順を示したフローチャートである。
【符号の説明】
２ データセンターサーバー
５ 処理部
６ 記憶部
１１ａ，１１ｂ，１１ｃ 遊技履歴データベース
１２ａ，１２ｂ ユーザー属性データベース
Claims (5)
- 記憶部と、処理部とからなり、上記記憶部は、ユーザー特定情報に対応した遊技履歴データを記憶する機能を備え、上記処理部は、上記記憶部の遊技履歴データのうち同一または類似の遊技履歴データを有する類似群のユーザー特定情報を抽出する機能と、上記履歴データから同日同時刻に遊技した履歴の有無を判定する機能と、上記類似群のユーザー特定情報のうち同日同時刻の遊技履歴を持たないユーザー特定情報を同一ユーザーのユーザー特定情報と判定する機能とを備えた遊技履歴データ管理システム。
- 記憶部と、処理部とからなり、上記記憶部は、ユーザー特定情報に対応した遊技履歴データを記憶する機能を備え、上記処理部は、上記履歴データから同日同時刻に遊技した履歴の有無を判定し、同日同時刻の遊技履歴を持たない同一候補群のユーザー特定情報を抽出する機能と、上記記憶部の遊技履歴データのうち同一または類似の遊技履歴データを判定する機能と、同日同時刻の遊技履歴を持たない同一候補群のユーザー特定情報群のうち同一または類似の履歴データに対応するユーザー特定情報を同一ユーザーのユーザー特定情報と判定する機能とを備えた遊技履歴データ管理システム。
- 記憶部と、処理部とからなり、上記記憶部は、遊技台特定情報毎に、ユーザー特定情報毎の遊技履歴データを対応づけた遊技台データと、ユーザー特定情報に対応づけた氏名や住所などのユーザー属性データとを記憶する機能を備え、上記処理部は、ユーザー特定情報毎に遊技履歴データを集計するとともに、上記複数のユーザー属性データのうち同一属性を有する属性データを判定する機能と、ユーザー属性データが同一である異なるユーザー特定情報を同一のユーザーのユーザー特定情報と判定する機能とを備えた遊技履歴データ管理システム。
- ユーザー特定情報に対応する氏名や住所などのユーザー属性データを記憶した複数のユーザー属性データベースと、これらユーザー属性データベースに対応し、かつ、ユーザー特定情報に対応する遊技履歴データを記憶した遊技履歴データベースと、これらのデータベースと通信手段を介して接続した処理部と、記憶部とからなり、上記処理部は、上記データベースから複数のユーザー属性データベースおよびそれに対応した遊技履歴データを受信してそれを記憶部に記憶させる機能と、上記記憶部が記憶している遊技履歴データに対応したユーザー属性データベースの中から、上記遊技履歴データ内のユーザー特定情報に対応するユーザー属性を特定する機能と、特定したユーザー属性と同一のユーザー属性をユーザー属性データベースから抽出する機能と、抽出された同一の属性データに対応するユーザー特定情報を同一のユーザーのユーザー特定情報と判定する機能とを備えた遊技履歴データ管理システム。
- 処理部は、同一ユーザーのユーザー特定情報と判定したユーザー特定情報に対応した遊技履歴データを統合する機能を備えた請求項１〜４のいずれか１に記載の遊技履歴データ管理システム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002321281A JP2004154248A (ja) | 2002-11-05 | 2002-11-05 | 遊技履歴データ管理システム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002321281A JP2004154248A (ja) | 2002-11-05 | 2002-11-05 | 遊技履歴データ管理システム |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2004154248A true JP2004154248A (ja) | 2004-06-03 |
Family
ID=32801889
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002321281A Pending JP2004154248A (ja) | 2002-11-05 | 2002-11-05 | 遊技履歴データ管理システム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2004154248A (ja) |
Cited By (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006333931A (ja) * | 2005-05-31 | 2006-12-14 | Sankyo Kk | 会員サービス提供システム |
| JP2006333930A (ja) * | 2005-05-31 | 2006-12-14 | Sankyo Kk | 会員サービス提供システム |
| JP2006334032A (ja) * | 2005-05-31 | 2006-12-14 | Sankyo Kk | 会員サービス提供装置 |
| JP2009233191A (ja) * | 2008-03-27 | 2009-10-15 | Omron Corp | 情報管理装置、情報管理方法、情報管理プログラム、および記録媒体 |
| JP2009233190A (ja) * | 2008-03-27 | 2009-10-15 | Omron Corp | 情報管理装置、情報管理方法、情報管理プログラム、および記録媒体 |
| JP2010201010A (ja) * | 2009-03-04 | 2010-09-16 | Daikoku Denki Co Ltd | 遊技場用システム |
| JP2013056007A (ja) * | 2011-09-07 | 2013-03-28 | Kpe Inc | 遊技機、遊技機監視システム、遊技機監視サーバ、遊技機制御方法、遊技機監視方法 |
| JP2013102808A (ja) * | 2011-11-10 | 2013-05-30 | Glory Ltd | 会員管理装置及び記憶媒体処理装置 |
| JP2013244182A (ja) * | 2012-05-25 | 2013-12-09 | Daikoku Denki Co Ltd | 遊技情報表示装置 |
| US20150149553A1 (en) * | 2013-11-28 | 2015-05-28 | International Business Machines Corporation | Apparatus and method for processing information and program for the same |
| JP2017070585A (ja) * | 2015-10-08 | 2017-04-13 | 株式会社ピーエーネット技術研究所 | 遊技場用管理システム、遊技場用サーバ、及び、遊技情報収集装置 |
| JP2020039463A (ja) * | 2018-09-07 | 2020-03-19 | グローリー株式会社 | 遊技管理システム及び遊技管理方法 |
-
2002
- 2002-11-05 JP JP2002321281A patent/JP2004154248A/ja active Pending
Cited By (21)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006333931A (ja) * | 2005-05-31 | 2006-12-14 | Sankyo Kk | 会員サービス提供システム |
| JP2006333930A (ja) * | 2005-05-31 | 2006-12-14 | Sankyo Kk | 会員サービス提供システム |
| JP2006334032A (ja) * | 2005-05-31 | 2006-12-14 | Sankyo Kk | 会員サービス提供装置 |
| JP2009233191A (ja) * | 2008-03-27 | 2009-10-15 | Omron Corp | 情報管理装置、情報管理方法、情報管理プログラム、および記録媒体 |
| JP2009233190A (ja) * | 2008-03-27 | 2009-10-15 | Omron Corp | 情報管理装置、情報管理方法、情報管理プログラム、および記録媒体 |
| JP2010201010A (ja) * | 2009-03-04 | 2010-09-16 | Daikoku Denki Co Ltd | 遊技場用システム |
| JP2013056007A (ja) * | 2011-09-07 | 2013-03-28 | Kpe Inc | 遊技機、遊技機監視システム、遊技機監視サーバ、遊技機制御方法、遊技機監視方法 |
| JP2013102808A (ja) * | 2011-11-10 | 2013-05-30 | Glory Ltd | 会員管理装置及び記憶媒体処理装置 |
| JP2013244182A (ja) * | 2012-05-25 | 2013-12-09 | Daikoku Denki Co Ltd | 遊技情報表示装置 |
| JP2015106178A (ja) * | 2013-11-28 | 2015-06-08 | インターナショナル・ビジネス・マシーンズ・コーポレーションＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎ | 情報処理装置、情報処理方法、及び、プログラム |
| US20150149553A1 (en) * | 2013-11-28 | 2015-05-28 | International Business Machines Corporation | Apparatus and method for processing information and program for the same |
| US20170085660A1 (en) * | 2013-11-28 | 2017-03-23 | International Business Machines Corporation | Apparatus and method for processing information and program for the same |
| US9800678B2 (en) * | 2013-11-28 | 2017-10-24 | International Business Machines Corporation | Apparatus and method for processing information and program for the same |
| US9819755B2 (en) * | 2013-11-28 | 2017-11-14 | International Business Machines Corporation | Apparatus and method for processing information and program for the same |
| US20170366631A1 (en) * | 2013-11-28 | 2017-12-21 | International Business Machines Corporation | Apparatus and method for processing information and program for the same |
| US20170366632A1 (en) * | 2013-11-28 | 2017-12-21 | International Business Machines Corporation | Apparatus and method for processing information and program for the same |
| US10122811B2 (en) * | 2013-11-28 | 2018-11-06 | International Business Machines Corporation | Method for determining identities between users |
| US10129350B2 (en) * | 2013-11-28 | 2018-11-13 | International Business Machines Corporation | Apparatus for determining identities between users |
| JP2017070585A (ja) * | 2015-10-08 | 2017-04-13 | 株式会社ピーエーネット技術研究所 | 遊技場用管理システム、遊技場用サーバ、及び、遊技情報収集装置 |
| JP2020039463A (ja) * | 2018-09-07 | 2020-03-19 | グローリー株式会社 | 遊技管理システム及び遊技管理方法 |
| JP7202109B2 (ja) | 2018-09-07 | 2023-01-11 | グローリー株式会社 | 遊技管理システム |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4948824B2 (ja) | 遊技管理システム | |
| JP5032007B2 (ja) | 遊技場管理システム | |
| JP5401680B2 (ja) | 遊技場管理システム及び遊技場管理方法 | |
| JP2004154248A (ja) | 遊技履歴データ管理システム | |
| CN102791340A (zh) | 游戏信息整合系统 | |
| JP4343496B2 (ja) | 遊技台の管理システム | |
| JP2007252478A (ja) | 遊技場管理支援システム | |
| JPH10263174A (ja) | 遊技場の会員情報管理システム | |
| JP2018108303A (ja) | 遊技管理システム及び遊技管理方法 | |
| JP4168014B2 (ja) | 整理券データ配信装置および整理券データ配信方法 | |
| JPH10156022A (ja) | 遊技場の会員管理システム | |
| JP4856895B2 (ja) | 会員サービス提供装置 | |
| US20040005925A1 (en) | Machine management system | |
| JP4856894B2 (ja) | 会員サービス提供システム | |
| JP7130390B2 (ja) | 遊技管理システム及び遊技管理方法 | |
| JP4856893B2 (ja) | 会員サービス提供システム | |
| JP2003038834A (ja) | 遊技情報提供装置 | |
| JP4458410B2 (ja) | 遊技用システム | |
| JP4343495B2 (ja) | 遊技台の管理システム | |
| JP3972966B2 (ja) | 遊技玉管理システム | |
| JP2006075528A (ja) | 遊技用サービス提供装置および遊技用サービス提供方法 | |
| JP2005137513A (ja) | 遊技用管理装置及び遊技用システム | |
| JP4353400B2 (ja) | 遊技用システムおよび管理装置 | |
| JP4518308B2 (ja) | 遊技用システム | |
| JP2004105342A (ja) | 遊技システム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20051024 |
|
| A131 | Notification of reasons for refusal |
Effective date: 20081007 Free format text: JAPANESE INTERMEDIATE CODE: A131 |
|
| A02 | Decision of refusal |
Effective date: 20090317 Free format text: JAPANESE INTERMEDIATE CODE: A02 |