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