JP3953283B2

JP3953283B2 - 遊技機の管理システム

Info

Publication number: JP3953283B2
Application number: JP2001052874A
Authority: JP
Inventors: 啓二塚原
Original assignee: 株式会社藤商事
Priority date: 2001-02-27
Filing date: 2001-02-27
Publication date: 2007-08-08
Anticipated expiration: 2021-02-27
Also published as: JP2002253817A

Description

【０００１】
【発明の属する技術分野】
本発明は、販売後の遊技機を適切に管理する管理システムに関し、特に、パチンコ機、回胴式遊技機、アレンジボール機、雀球遊技機などの管理に活用されるものである。
【０００２】
【従来の技術】
遊技機ホールでは、一般に、多数の遊技機を比較的短期間のうちに入れ換えて営業しているため、稼動中の遊技機について、定期的な保守サービスを求めることはない。そのため、各遊技ホールにおいて遊技機に不具合が生じた場合、ホールの従業員がトラブル対処のためのマニュアル冊子を参照しつつ対処するか、不具合の連絡を受けたメーカ側の営業マンがホールに出向いてマニュアル冊子を参照するなどして不具合の原因を調べ修理していた。
【０００３】
【発明が解決しようとする課題】
しかしながら、営業マンは、一般に技術的内容に疎いので、電話等で技術者の指示を一々仰ぎつつ対処せざるを得ず、場当たり的な対処に終始してしまう恐れもあった。また、仮に適切な処理ができたとしても、生じていたトラブルについての情報は、その場限りのものとなり、次期製品の設計に反映されることは多くなかった。
【０００４】
本発明は、このような実情に鑑みなされたものであって、販売後の遊技機のトラブルについても適切に管理把握して、次期製品の開発にも寄与させることのできる遊技機の管理システムを提供することを課題とする。
【０００５】
【課題を解決するための手段】
上記課題を解決するため、本発明に係る遊技機の管理システムでは、インターネット回線に接続されたサーバ機器と、リンク情報によって結合された一群のファイルに故障診断の方法を記憶するＷＥＢデータベースとを有する故障診断システムに接続されて構成され、社内ＬＡＮに接続された複数の端末装置に対してデータベースサーバとして機能するデータ管理装置と、前記データ管理装置を介して、前記複数の端末装置からアクセス可能に構成され、客先遊技機の故障発生状況や遊技機の販売実績などを記憶した管理データベースと、を有する管理システムであって、前記サーバ機器は、ログインユーザに新規のエントリー番号を自動付与する初期処理プログラムと、前記エントリー番号と当該ファイルにリンクされている別のファイルのページ番号とが付加された各ログインユーザ固有のファイルを返送する診断処理プログラムとを有して、インターネット回線に接続されたコンピュータ機器からの要求に応じて、該当する故障診断方法を示す前記ファイルを配信する一方、その配信内容を特定する前記ページ番号を、配信日時と共に、前記エントリー番号に対応するログテーブルに逐次記憶する配信手段と、その後、前記コンピュータ機器から修理完了の通知を受けると、最終処理プログラムが前記ログテーブルを参照して、前記コンピュータ機器によって特定された故障回復に要した交換部材の情報と、前記逐次記憶した前記ログテーブルの記憶内容とに基づいて故障状況を特定し、これを故障診断結果テーブルに記憶する解析手段とを有し、前記データ管理装置は、前記故障診断結果テーブルを情報に基づいて、個々の遊技ホールの遊技機毎に故障発生状況を把握して前記管理データベースの内容を更新する更新手段と、前記端末装置からの要求に応じて必要な情報を返送し、遊技機の機種毎に、遊技ホール名と故障症状と同一症状を示す故障台数とを示す一覧表を前記端末装置に出力させる返送手段とを有し、前記コンピュータ機器が、配信を受けた前記ファイルに基づき、前記エントリー番号と前記ページ番号を前記サーバ機器に送信する構成を採ることで、前記エントリー番号と前記ページ番号を記憶する前記ログテーブルによって、個々の遊技ホールの遊技機毎に不具合解消に至る対処経路を含め把握可能とされ、前記ログテーブルに基づいて生成される前記故障診断結果テーブルには、同一機種について同一症状の台数と、その遊技ホールとが対応して記憶されることにより、特定の遊技ホールの電気設備上の不備が、前記一覧表から検出可能となっている。コンピュータ機器ＰＣは、特に限定されないが、携帯可能なものが好適である（以下、同じ）。
【０００７】
管理データベースＤＢ２には、好ましくは、顧客コードと機種コードと症状コードをフィールド欄に有する診断結果テーブルＴＢＬ１と、顧客コードと機種コードと販売台数をフィールド欄に有する販売実績テーブルＴＢＬ２とが存在する。また、前記販売実績テーブルＴＢＬ２の内容は、通信回線を通して前記データベースＤＢ２を呼び出し可能に構成されたコンピュータ機器を用いて、特定の操作者によって入力されている一方、前記診断結果テーブルＴＢＬ１の内容は、インターネット回線を通して収集されるのが好ましい。
【０００８】
【発明の実施の形態】
以下、本発明に係る管理システムについて、実施例に基づいて発明の実施の形態を説明する。図１に示すように、本実施例の遊技機管理システムは、データベースサーバとして機能するデータ管理装置Ｍ１と、社内ＬＡＮを通してデータ管理装置Ｍ１に接続されている複数の端末装置Ｍｎ…Ｍｎとで構成されている。データ管理装置Ｍ１は、遊技機の製造・販売・修理を一括して集中的に管理するもので、客先遊技機の故障発生状況や遊技機の販売実績などを記録したデータベースＤＢ２が設けられている。
【０００９】
図２（ａ）は、客先遊技機の故障発生状況を蓄積する故障診断結果テーブルＴＢＬ１を図示したものであり、故障診断結果に関する各レコードは、顧客コード、機種コード、日付コード、症状コード、故障台数の各フィールドで構成されている。また、図２（ｂ）は、遊技機の販売実績を蓄積する販売結果テーブルＴＢＬ２を図示したものであり、販売結果に関する各レコードは、顧客コード、機種コード、日付コード、販売台数の各フィールドで構成されている。なお、図３（ａ）（ｂ）（ｃ）に示すように、データベースＤＢ２には、機種コード、顧客コード、症状コードに関するコードテーブルＴＢＬ３〜ＴＢＬ５も設けられている。
【００１０】
データ管理装置Ｍ１は、ポーリング処理によってサーバ機器ＳＶ側から必要なデータを取得して、診断結果テーブルＴＢＬ１（図２（ａ））の内容を更新している。なお、サーバ機器ＳＶでは、インターネット回線を通して客先遊技機の故障診断をし、その故障診断結果を図２（ａ）のフォーマットで蓄積しているが、この点については後に詳述する。
【００１１】
データ管理装置Ｍ１は、また、端末装置Ｍｎからの操作によって販売実績データを受け、そのデータに基づいて販売結果テーブルＴＢＬ２（図２（ｂ））の内容を更新している。端末装置Ｍｎの操作は、認証された特定の社員によって行われ、どの遊技ホール（顧客）に、どの機種の遊技機が、いつ何台販売されたかの情報が、順次、販売結果テーブルＴＢＬ２に蓄積されていく。なお、遊技機の流通においては、新機種の遊技機が売れた場合には、旧機種の遊技機が撤去される場合も多いが、撤去された台数はマイナスの数値で登録される。そのため、例えば、顧客コードと機種コードとをキーにして販売台数を集計すると、特定の遊技ホールにおいて、特定の遊技機がいま何台稼動中であるか設置台数を知ることができる。
【００１２】
各端末装置Ｍｎ…Ｍｎには、故障状況照会用のプログラムがインストールされており、前記データベースＤＢ２の蓄積データを読み出すことによって、故障状況についての必要な情報が取得できるようになっている。以下、故障状況照会用プログラムの動作内容を概略的に説明する。
【００１３】
このプログラムが立ち上がると、最初に、端末装置Ｍｎには処理選択用の初期メニュー画面が現れる。この初期メニュー画面には、機器別故障集計リストに関する操作COMMANDボタンと、顧客別故障集計リストに関する操作COMMANDボタンとが含まれているが、ここでは、機器別故障集計のCOMMANDボタンがマウス操作によって押下されたことにする。
【００１４】
すると、端末装置Ｍｎからデータ管理装置Ｍ１に対して、適宜なＳＱＬ(Structured Query Language)文が送られて、機器テーブルＴＢＬ３（図３（ａ））が読み出され、端末装置Ｍｎには機器一覧表が表示される。そこで、操作者がこの機器一覧表の中で該当の機種を選択すると、その操作に応答して適宜なＳＱＬ文がデータ管理装置Ｍ１に送られて、診断結果テーブルＴＢＬ１と販売結果テーブルＴＢＬ２の中から、特定の機種コードのものだけが選択されて端末装置Ｍｎに送られてくる。なお、この場合のＳＱＬ文は、特定機種コードをキーとして抽出されるレコードであって、診断結果テーブルＴＢＬ１に、顧客コードと症状コードと故障台数の各データを要求するものである。また、販売結果テーブルＴＢＬ２には、顧客コードと販売台数の各データを要求する。
【００１５】
次に、端末装置Ｍｎでは、データ管理装置Ｍ１から取得した診断結果テーブルＴＢＬ１のデータについて、同一顧客における同一の症状の故障台数Ｓ１を集計する。また、同一症状の故障の総数Ｓ２や、同一顧客における故障総数Ｓ３も算出する。図４は、その集計結果を概念的に図示したものである。また、端末装置Ｍｎでは、データ管理装置Ｍ１から取得した販売結果テーブルＴＢＬ２のデータを集計して、各顧客毎の当該機種の設置台数Ｓ４、顧客の総数Ｓ５、全顧客における当該機種の設置台数Ｓ６を算出する。
【００１６】
続いて、端末装置Ｍｎでは、特定ホールにおける特定のトラブルの発生件数Ｓ１を、当該ホールの当該遊技機の設置台数Ｓ４と比較して、極端に発生頻度の高いトラブルがないかチェックする。このチェックによって、特定のトラブルが一般的に、全ての遊技ホールで生じているのか、それとも、特定の遊技ホールでのみ顕著に発生しているかを知ることができる。
【００１７】
例えば、症状（ｊ）のトラブルが、全ての遊技ホールで一般的に顕著に生じているのであれば、当該機種の遊技機には、症状（ｊ）に至る設計上の問題がある可能性が高いことになる。また、症状（ｉ）のトラブルが、特定の遊技ホールでのみ顕著に生じているのであれば、その遊技ホール固有の問題であり、典型的には、受電／配電設備などに問題がある可能性があることになる。そこで、特定顧客・特定症状の発生合計Ｓ１、全顧客・特定症状の発生合計Ｓ２、特定顧客・全症状の発生合計Ｓ３、特定顧客への設置総数Ｓ４、全顧客数Ｓ５、全顧客に対する設置総数Ｓ６をパラメータとした統計的処理を行い、上記のような判定結果についての正確性を高めている。
【００１８】
以上のような処理を終えた端末装置Ｍｎでは、例えば、図５のような画面を構築して端末装置Ｍｎに表示する。この例では、高頻度で生じている症状ｉと症状ｊについて該当文字を強調し、発生割合（Ｓ２／Ｓ６）を棒グラムで表示すると共に、統計的処理に基づいた判定結果を示している。トラブル原因には各種の要因があり、生産管理上のトラブルによって特定の製造ロットだけにトラブルが生じる恐れもあるが、通常は、特定ホールの配電設備が貧弱であり、電源電圧が常に不足気味であるような場合が多いので図５のような表示としている。
【００１９】
いずれにしても、社内の担当者は、症状ｉや症状ｊの具体的内容を加味しながら、他の症状の発生頻度なども参酌することによってトラブルの真の原因を究明することができる。例えば、図示の遊技機（ＹＨ１２３５）の場合には、症状ｊの故障が生じやすいと言わざるを得ないので、次期製品を開発する上で設計の見直しなどが必要となる。
【００２０】
続いて、端末装置Ｍｎの初期メニュー画面で、顧客別故障集計リストに関するCOMMANDボタンが押された場合を説明する。この場合もCOMMANDボタンの押下に対応して、データ管理装置Ｍ１に適宜なＳＱＬ文が送られて、機器テーブルＴＢＬ３が読み出されて機器一覧表が表示される。そこで、この機器一覧表の中で該当の機種を選択すると、その操作に応答して適宜なＳＱＬ文がデータ管理装置Ｍ１に送られて、診断結果テーブルＴＢＬ１（図２（ａ））と販売結果テーブルＴＢＬ２（図２（ｂ））の中から、特定の機種コードのものだけが選択されて端末装置Ｍｎに送られてくる。なお、この場合のＳＱＬ文は、特定顧客コードと特定機種コードとをキーとして抽出されるレコードであって、診断結果テーブルＴＢＬ１に、日付と症状コードと故障台数の各データを要求するものである。また、販売結果テーブルＴＢＬ２には、販売台数を要求する。
【００２１】
次に、端末装置Ｍｎでは、データ管理装置Ｍ１から取得した販売結果テーブルＴＢＬ２のデータを集計して、当該顧客に対する当該機種の設置数量Ｓ４を算出する。また、データ管理装置Ｍ１から取得した診断結果テーブルＴＢＬ１を症状別に集計する。同様に、当該顧客・当該機種における同一症状の故障件数Ｓ１、当該顧客・当該機種における故障総数Ｓ３も算出する。
【００２２】
またデータ管理装置Ｍ１は、特定のトラブルの発生件数Ｓ１を当該ホールに設置した当該機種の台数Ｓ４と対比して（Ｓ１／Ｓ４）、トラブル発生割合を算出する。その後、端末装置Ｍｎには、例えば、図６のような故障集計リストが表示される。したがって、社内の担当者は、症状ｉや症状ｊの発生頻度やその他の情報を検討してトラブルの真の原因を究明することが可能となる。
【００２３】
続いて、データ管理装置Ｍ１が取得する故障診断結果データを生成する診断システムについて説明する。図７に示すように、実施例の診断システムは、インターネット回線ＮＥＴに接続されたサーバ機器ＳＶと、サーバ機器ＳＶからアクセスされるＷＥＢデータベースＤＢ１と、ＷＥＢデータベースＤＢ１を定期的にポーリングして新規登録の会員データや故障診断結果データを取得し、管理データベースＤＢ２の内容を更新する管理装置Ｍ１とで構成されている。なお、ここでサーバ機器ＳＶとは、外部記憶装置を除いた概念であり、ＷＥＢデータベースＤＢ１などをアクセスする本体部分を意味している。
【００２４】
この実施例の診断システムは、故障状態のパチンコ機の故障診断に使用されるので、インターネット回線ＮＥＴには、ＰＨＳなどの移動体通信機器を通してクライアント機器ＰＣを接続するようになっている。ここで、クライアント機器は、具体的には、パチンコ機の故障に対処するメーカ側の営業マンやホール側の係員が所持するノート型パソコンであり、WWWブラウザが搭載されたものである。また、管理装置Ｍ１は、社内ＬＡＮによって他の端末機器Ｍｎ…Ｍｎとも接続されており、任意の端末装置Ｍｎからの要求に応じて、管理データベースＤＢ２の内容を読み出して適宜な集計リストを構築するようになっている。
【００２５】
サーバ機器ＳＶは、クライアント機器ＰＣからの要求に応じて該当するＨＴＭＬファイルを送信するだけでなく、クライアント機器ＰＣからの要求に応じて該当するＣＧＩプログラムが起動し、ログインユーザの照合処理や、各ユーザ向けのＨＴＭＬファイルの作成処理や、各ユーザの処理手順を解析する故障解析処理などを行っている。
【００２６】
図８に示すように、サーバ機器ＳＶで動作するＣＧＩプログラムは、大略、ユーザ認証処理プログラムと、ユーザ認証後に機能する初期処理プログラムＴＯＰ．ＣＧＩと、その後の各ＨＴＭＬファイルの送信時に機能する診断処理プログラムＳＨＩＮＤＡＮ．ＣＧＩと、故障修理の完了後に機能する最終処理プログラムＥＮＤ．ＣＧＩとで構成されている。
【００２７】
ユーザ認証処理は、クライアント機器ＰＣから送信されてきたユーザＩＤとパスワードとをＷＥＢデータベースＤＢ１内の登録データと照合する公知の処理である。そして、照合データと不一致なら正しいデータの再入力を要求するＨＴＭＬファイルをクライアント機器ＰＣに送信し、照合データと一致すれば、その後の処理を初期処理プログラムＴＯＰ．ＣＧＩに移管するようにしている。
【００２８】
初期処理プログラム（ＴＯＰ．ＣＧＩ）
初期処理プログラムは、認証を受けたユーザに対して、ログイン後の一連の処理に対応する固有のエントリー番号を付与すると共に、このエントリー番号とユーザＩＤとに関連させて会話ログテーブルの領域を確保する。エントリー番号は、順次インクリメント処理されるカウンタによって決定され、現在、未使用の状態になっている番号が付与される。なお、初期処理プログラムは、この処理に先だって各会話ログテーブル（図９）の最終日時データと現在日時とを比較し、所定値以上の時間（例えば４時間）が経過している場合には、当該会話ログテーブルを削除し、当該エントリー番号の使用を他のユーザに開放している。このような処理をするのは、ログインしたユーザが故障診断処理の途中でその後の処理を放棄することもあるからである。
【００２９】
初期処理プログラムは、また、送信ページ用の基礎データをＷＥＢデータベースＤＢ１から読み出してエントリー番号を付与し、ログインユーザ固有のＨＴＭＬファイルを生成して、ＷＷＷサーバを通して該当するクライアント機器ＰＣに送付する。そしてこの時に、送付したＨＴＭＬファイルを特定するページ番号及び送信した日時データを、エントリー番号に対応する会話ログテーブルに記憶する（図９）。
【００３０】
図９は、会話ログテーブルを例示したものであり、クライアント機器ＰＣｉに送付したＨＴＭＬファイルのページ番号と送信日時とが関連して記憶されている。図示の例では、エントリー番号０２００を付与されたユーザに対して、００００ページ→０００１ページ→０００３ページ→…の順番に、２００１年１月４日２３時３０分４５秒→同３１分２０秒→同３１分５０秒→…の時間にＨＴＭＬファイルを送付されたことを示している。
【００３１】
また、会話ログテーブルには、交換部材情報の欄が設けられている。この欄は、診断処理プログラムが記入する欄であって、当該ユーザに対して提示した直前のＨＴＭＬファイル（画面）からの応答に応じて、交換部材の使用があった場合にはその情報が記述される。この交換部材の情報も含め、会話ログテーブルの内容は、ユーザが一連の処理を終えた後、最終処理プログラム（ＥＮＤ．ＣＧＩ）によって参照され、当該ユーザの故障修理手順を解析する際の処理対象となる。
【００３２】
先に説明したように、初期処理プログラムでは、送信ページ用の基礎データをＷＥＢデータベースＤＢ１から読み出してエントリー番号を付与し、ログインユーザ固有のＨＴＭＬファイルを生成するが、図１０は、送信ページ用の基礎データを概念的に例示したものである。ＣＧＩプログラム（ＴＯＰ．ＣＧＩ、ＳＨＩＮＤＡＮ．ＣＧＩ、ＥＮＤ．ＣＧＩ）は、図示のような基礎データを読み出し、空白部（□）にエントリー番号を挿入してＨＴＭＬファイルを完成させる。例えば、初期処理ＣＧＩプログラム（ＴＯＰ．ＣＧＩ）が００００ページの基礎データに基づいて完成させるＨＴＭＬファイルは、図１１（ａ）のような内容となり、この例では、エントリー番号２００が付与されたＴＯＰページが完成されている。
【００３３】
なお、エントリー番号に続く番号は、当該ＨＴＭＬファイルにリンクされているＨＴＭＬファイルのページ番号を意味しており、図１１（ａ）の例では、ＴＯＰページ（００００ページ目）のＨＴＭＬファイルを受信したクライアント機器ＰＣがｙｅｓボタンを押すと０００２ページにリンクされ、ｎｏボタンを押すと０００１ページにリンクされることになる。より詳細には、クライアント機器ＰＣで操作したボタンに応じて、０２０００００２又は０２０００００１というデータが診断処理プログラムＳＨＩＮＤＡＮ．ＣＧＩに渡されるので、診断処理プログラムでは、エントリー番号２００のユーザから０００２ページ又は０００１ページの要求があったことを知ることができる。
【００３４】
診断処理プログラム（ＳＨＩＮＤＡＮ．ＣＧＩ）
上記したように、診断処理プログラムは、クライアント機器ＰＣからユーザのエントリー番号と、要求ページの情報を受けるので、先ず、エントリー番号に対応する会話ログテーブルが存在するか否かを判定する。そして、該当する会話ログテーブルが存在しなければ、認証データを入力するためのＨＴＭＬファイルをクライアント機器に送付する。会話ログテーブルが存在しない場合とは、典型的には、クライアント機器ＰＣに残存している処理途中の過去のＨＴＭＬファイルに基づき、ユーザ認証処理を受けることなく、直接その後のページを要求してきた場合である。この実施例では、このような場合には、その後の処理をユーザ認証処理に戻すことによって会話ログテーブルを再構築するようにしている。
【００３５】
一方、エントリー番号に対応する会話ログテーブルが存在する場合には、エントリー番号に続く要求ページ番号に基づいて、図１０の基礎データを読み出し、エントリー番号を付与して送信用のＨＴＭＬファイルを生成する。図１１（ｂ）は、エントリー番号２００のユーザからの要求に応じて、診断処理プログラムが生成したＨＴＭＬファイルの内容を例示したものである。このＨＴＭＬファイルは、クライアント機器ＰＣでｎｏのボタンが押されると、診断処理プログラム（ＳＨＩＮＤＡＮ．ＣＧＩ）に００１１ページの送信を要求するが、ｙｅｓのボタンが押されると、最終処理プログラムに（ＥＮＤ．ＣＧＩ）に修理完了を示すデータ（＝９９９９）を送るように構成されている。
【００３６】
最終処理プログラム（ＥＮＤ．ＣＧＩ）
例えば、０２００９９９９のデータを受けた最終処理プログラムは、エントリー番号２００のユーザの修理処理が完了したことを、受信データ９９９９から認識することができる。そこで、最終処理プログラムは、最初に、当該ユーザの会話ログテーブルを解析する。先に説明したように、会話ログテーブルには、交換部材の情報と共に、当該ユーザに送付したＨＴＭＬファイルのページ番号が時間順次に記憶されているので、修理完了までの手順を解析することによって、どの機種のどこ箇所にどのような故障が生じており、どのように対処して修理が完了したかを把握することができる。
【００３７】
以上の解析を終えた最終処理プログラムは、その解析結果を簡略に整理すると共に、「上記のような故障でしたね。これで良いですか？」のような表示を実現するＨＴＭＬファイルを生成する。なお、このＨＴＭＬファイルは、修理し終えたパチンコ機と同じ症状であると確信できる機器台数なども、パチンコホールのホールＩＤと共に入力してもらう画面としておく。そして、図１１の場合と同様にエントリー番号を付与して、該当するクライアント機器ＰＣに送信する。
【００３８】
その後のクライアント機器からの返信は、最終処理プログラムの終了ルーチンに渡されるようになっているので、終了ルーチンでは処理完了のメッセージを表示したＨＴＭＬファイルを送り返すと共に、先に解析したデータを故障診断結果テーブルに格納する。図１２は、故障診断結果テーブルを例示したものであり、ホールＩＤ、機種ＩＤ、日付、症状ＩＤ、故障台数、交換部材ＩＤ、ユーザＩＤなどが記入されるようになっている。故障診断結果テーブルは、作成段階では未処理フラグがセットされているが、この未処理フラグは、管理装置Ｍ１によるポーリング処理によって検索され、必要なデータが管理データベースＤＢ２に登録された後、未処理フラグがリセットされる。
【００３９】
続いて、以上の内容を踏まえて、パチンコ機の故障診断の具体的内容を説明する。まず、故障機器を前にした営業マンやホールの係員は、クライアント機器ＰＣのWWWブラウザーを立ち上げ、故障診断のホームページのＵＲＬを入力する。その後、画面上の誘導にしたがってリンクを辿っていくと、パチンコ機種の一覧表を表示する画面が現れる。そこで、不具合が生じている機種を選択すると、図１３のようなページに進み、当該パチンコ機器の画像が表示される。
【００４０】
この画面をＷＷＷブラウザに表示させているＨＴＭＬファイルには、ＪＡＶＡアプレットが書き込まれており、クリック操作された瞬間のマウスポインタの座標位置を検出できるようになっている。そして、ユーザのクリック操作に対応して、不良部材に関する対処ページにリンクされるようになっている。例えば、遊技球の発射に異常がある場合には画面上の発射ハンドル部分にポインタをあててマウスをクリックすると、遊技球の発射に関する不具合対処ページへ進むことになる。同様に、遊技球の払出に異常がある場合には画面上の下皿部分にポインターをあててマウスをクリックすると、払出に関する不具合対処ページへ進むことになる。
【００４１】
一方、不具合箇所が明確に特定できない場合や不具合箇所が画面表示の部材に該当しない場合は、図１３の右欄に表示された不具合症状一覧表の該当箇所をマウスで選択して、不具合対処ページへ進むことになる。なお、ここまでの処理は、専らＷＷＷサーバとＷＷＷブラウザとによって実現されるが、上記したような通常の処理によって、故障機種についての不具合箇所に対応したページに辿りつくと、サーバ機器ＳＶは、この段階で初めてユーザＩＤとパスワードを要求する。
【００４２】
具体的には、ＷＷＷサーバはユーザＩＤとパスワードを入力させるための認証画面を送信するが、入力されたユーザIDとパスワードは、ユーザ認証処理プログラムに渡されて認証処理が実行される。そして、ＷＥＢデータベースＤＢ１の照合データと合致した場合には、トップページのログインを許可して、WWWサーバを通じて図１１（ａ）に例示したような内容のＨＴＭＬファイルが送信される。なお、この処理は、処理プログラムＴＯＰ．ＣＧＩによって実現され、この段階において、エントリー番号は付与され、会話ログテーブルも構築されるのは前述した通りである。
【００４３】
以降の説明では、便宜上、遊技球の払出に異常があった場合を例にして説明する。その後の処理は、主として、診断処理プログラムＳＨＩＮＤＡＮ．ＣＧＩの制御によって図１４及び図１５のフローチャートで示す手順で行われ、ページ番号００００〜００２７のＨＴＭＬファイルがユーザの操作に応じて送信される。例えば、００００のページは、クライアント機器ＰＣには図１６のように表示されるが、ここで、ＹＥＳのボタンを押せば、０００２ページが要求され、ＮＯのボタンを押せば、０００１ページが診断処理プログラムに要求されることになる。
【００４４】
図１４、図１５のフローチャートについて補足すると、０００７ページは、
「タンク、払出カセットの確認又は対処をして下さい。」
「今回初めて対処する場合には、対処後に［完了］ボタンを押して下さい。」
「既に対処を完了している場合には、［先ほど対処した］のボタンを押して下さい。」
のような画面となる。
【００４５】
０１１、０１２、０１３、０１４、０２１、０２４、０２５、０２６、０２７のページも同様であり、クライアント機器ＰＣに表示される措置を今回行って［完了］ボタンを押すか、表示される措置を完了しており［先ほど対処した］のボタンを押すかによってリンク先を変えている。このように、パチンコ機の修理においては、何らかの処理を行うと電源投入に戻る必要があり、同じページが複数回送信されるが、この実施例ではユーザの操作履歴を保存されているので、最終的に、どのように対処した結果、或いは、何を交換した結果、故障が修理できたかを最終処理プログラムにおいて把握することができる。また、交換した部材や個数も把握できる。なお、問題の部材をチェックしただけなのか、当該部材を実際に交換したのかまで把握するため、必要に応じて、回答データを送信させるのは勿論である。
【００４６】
このように、サーバ機器からの誘導にしたがって図１４及び図１５のようにパチンコ機の各部材を点検していく上で、部材の交換を要求されるが、営業マンやホール係員は交換部材を持っていないのが常である。そこで、このような場合には、正常に動作している隣りのパチンコ機の同一部材を外して、故障しているパチンコ機に取り付ける。
【００４７】
このようにして図１４の手順で処理を進めていくと、やがて、図１７に例示するような０１０ページの画像がクライアント機器ＰＣに表示される。この０１０ページのＨＴＭＬファイルは、例えば、図１１（ｂ）のような構成であり、ｙｅｓのボタンが押されると、その後の処理は、終了処理プログラムＥＮＤ．ＣＧＩに渡され、会話ログテーブルのデータに基づいて故障修理内容が解析され、解析内容や交換部材についてユーザに確認を求めた後、故障診断結果データが構築される。
【００４８】
そして、必要な交換部材を自動的に発注し、その後、故障内容と故障修理方法を添付して営業マンやホール係員に渡すことが可能となる。なお、この実施例の場合には、早い段階でユーザＩＤとパスワードの入力をさせたが、故障修理内容を解析して、その解析内容や交換部材についてユーザに確認を求める段階までユーザＩＤなどのチェックを保留しても良い。このようなシステムでは、最後の回答(YES/NO)とユーザＩＤ及びパスワードが入力されない場合には、管理情報を確定できないことになるが、本システムの試用を認めるという意味では大きな意義がある。
【００４９】
いずれにしても本システムでは、パチンコ機の不具合の症状を、各部材の状況を確認しながら処理を進めることができ、適切な対処法を提示することが可能となる。また、どのような対処経路を経て最終的に不具合の解消に至ったのか、把握することが可能となる。
【００５０】
なお、以上の説明では、サーバ機器ＳＶは、自ら付与したエントリー番号に基づいて同一人の手続き過程を把握したが、特にこの方法に限定されるものではなく、例えば、クライアント機器のＩＰアドレスやＭＡＣアドレス、その他の方法によって管理しても良い。
【００５１】
また、上記の実施例では、診断処理処理の途中からＣＧＩプログラムの処理によって手続き履歴を把握したが、この方法に限定される必要はなく、当初からＣＧＩプログラムの制御によって進行させても良い。なお、ＣＧＩに限らず、類似のあらゆる仕組みを利用できるのは勿論である。
【００５２】
なお、簡易性の観点からは、全てのＨＴＭＬファイルを固定的にＷＥＢデータベースＤＢ１に用意しておき、殆どの処理をＷＷＷサーバに負担させ、修理完了後に、総括的な情報をユーザＩＤなどと共に入力させるようにしても良い。この場合には、ユーザＩＤやパスワードの確認の後、入力された情報を編集するだけで図６のような故障診断データを作成することが可能となる。ただし、このような構成は、本発明の範囲ではない。この点は以下の発明についても同様である。
【００５３】
また、このような実施態様を採る場合には、故障機種や故障内容が特定できた段階で必要なデータ及びプログラムをクライアント機器にダウンロードさせ、その後はオフライン状態で作業させても良い。そして、修理完了後に、総括的な情報をユーザＩＤなどと共に入力させた段階で、インターネット回線に接続して情報を回収すれば良い。
【００５４】
更にまた、一連の処理を実現するデータ及びプログラムをインストール済みのノートパソコンを営業マンなどが持ち歩き、修理完了後、総括的な情報をユーザＩＤなどと共に入力させた段階で、インターネット回線に接続して情報を回収することもできる。また、クライアント機器としては、携帯可能なコンピュータ以外にも、デスクトップ型コンピュータ等の固定的に配置されるコンピュータを用いても良い。
【００５５】
【発明の効果】
以上説明したように、本発明によれば、販売後の遊技機のトラブルについても適切に管理把握して、次期製品の開発にも寄与させることのできる遊技機の管理システムを実現できる。
【図面の簡単な説明】
【図１】本発明の遊技機管理システムの一実施例を図示した概略構成図である。
【図２】診断結果テーブルと販売結果テーブルの内容を例示したものである。
【図３】機器テーブルと顧客テーブルと症状テーブルを例示したものである。
【図４】故障状況照会プログラムの動作内容を説明する図面である。
【図５】故障状況照会プログラムの出力結果を例示した図面である。
【図６】故障状況照会プログラムの出力結果を例示した図面である。
【図７】故障診断システムの一実施例を図示した概略構成図である。
【図８】ＣＧＩプログラムの処理手順を説明する図面である。
【図９】ＣＧＩプログラムが登録していく会話ログテーブルの概念図である。
【図１０】ＣＧＩプログラムが読み出す基礎データを示す概念図である。
【図１１】ＣＧＩプログラムが生成するＨＴＭＬファイルの内容を示す概念図である。
【図１２】ＣＧＩプログラムが生成する故障診断結果テーブルを示す概念図である。
【図１３】クライアント機器の表示画面の一例である。
【図１４】サーバ機器の動作内容の一例を示すフローチャートである。
【図１５】サーバ機器の動作内容の一例を示すフローチャートである。
【図１６】クライアント機器の表示画面の一例である。
【図１７】クライアント機器の表示画面の一例である。
【符号の説明】
ＮＥＴインターネット回線
ＳＶサーバ機器
ＰＣクライアント機器（コンピュータ機器）

Claims

インターネット回線に接続されたサーバ機器と、リンク情報によって結合された一群のファイルに故障診断の方法を記憶するＷＥＢデータベースとを有する故障診断システムに接続されて構成され、
社内ＬＡＮに接続された複数の端末装置に対してデータベースサーバとして機能するデータ管理装置と、前記データ管理装置を介して、前記複数の端末装置からアクセス可能に構成され、客先遊技機の故障発生状況や遊技機の販売実績などを記憶した管理データベースと、を有する管理システムであって、
前記サーバ機器は、ログインユーザに新規のエントリー番号を自動付与する初期処理プログラムと、前記エントリー番号と当該ファイルにリンクされている別のファイルのページ番号とが付加された各ログインユーザ固有のファイルを返送する診断処理プログラムとを有して、インターネット回線に接続されたコンピュータ機器からの要求に応じて、該当する故障診断方法を示す前記ファイルを配信する一方、その配信内容を特定する前記ページ番号を、配信日時と共に、前記エントリー番号に対応するログテーブルに逐次記憶する配信手段と、
その後、前記コンピュータ機器から修理完了の通知を受けると、最終処理プログラムが前記ログテーブルを参照して、前記コンピュータ機器によって特定された故障回復に要した交換部材の情報と、前記逐次記憶した前記ログテーブルの記憶内容とに基づいて故障状況を特定し、これを故障診断結果テーブルに記憶する解析手段とを有し、
前記データ管理装置は、前記故障診断結果テーブルを情報に基づいて、個々の遊技ホールの遊技機毎に故障発生状況を把握して前記管理データベースの内容を更新する更新手段と、前記端末装置からの要求に応じて必要な情報を返送し、遊技機の機種毎に、遊技ホール名と故障症状と同一症状を示す故障台数とを示す一覧表を前記端末装置に出力させる返送手段とを有し、
前記コンピュータ機器が、配信を受けた前記ファイルに基づき、前記エントリー番号と前記ページ番号を前記サーバ機器に送信する構成を採ることで、前記エントリー番号と前記ページ番号を記憶する前記ログテーブルによって、個々の遊技ホールの遊技機毎に不具合解消に至る対処経路を含め把握可能とされ、
前記ログテーブルに基づいて生成される前記故障診断結果テーブルには、同一機種について同一症状の台数と、その遊技ホールとが対応して記憶されることにより、特定の遊技ホールの電気設備上の不備が、前記一覧表から検出可能となっている
ことを特徴とする遊技機の管理システム。
前記管理データベースには、顧客コードと機種コードと症状コードをフィールド欄に有する診断結果テーブルＴＢＬ１と、顧客コードと機種コードと販売台数をフィールド欄に有する販売実績テーブルＴＢＬ２とが存在する請求項１に記載の管理システム。
前記販売実績テーブルＴＢＬ２の内容は、通信回線を通して前記データベースＤＢ２を呼び出し可能に構成されたコンピュータ機器を用いて、特定の操作者によって入力されている一方、前記診断結果テーブルＴＢＬ１の内容は、インターネット回線を通して収集されている請求項２に記載の管理システム。
前記診断結果テーブルＴＢＬ１の情報に基づいて、特定の機種について同一顧客コードで且つ同一症状コード毎の故障発生数Ｓ１を算出する第１手段と、前記故障発生数Ｓ１を判定要素に含む統計的処理によって故障原因を推理する第２手段と、を備えている請求項２又は３に記載の管理システム。
前記診断結果テーブルＴＢＬ１の情報に基づいて、特定の機種について同一顧客コードで且つ同一症状コード毎の故障発生数Ｓ１を算出する第１手段と、前記診断結果テーブルＴＢＬ１の情報に基づいて、特定の機種について各症状コード毎の故障発生総数Ｓ２を算出する第２手段と、前記販売実績テーブルＴＢＬ２の情報に基づいて、前記特定の機種についての全顧客に対する設置総数Ｓ６を算出する第３手段と、前記故障発生数Ｓ１、前記故障発生総数Ｓ２、前記設置総数Ｓ６を判定要素に含む統計的処理によって故障原因を推理する第４手段と、を備えている請求項２又は３に記載の管理システム。