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