(57)【要約】【課題】本発明は、修理審査を自動的に行って、スピーディーに、より均一で正確な修理審査結果を得ることができる修理審査システムを提供する。【解決手段】本発明の修理審査システムは、予め定められた製品種類毎の修理の妥当性を規定する修理審査条件に基づいて、第２の記憶手段から読み出したチェック済み修理請求データと前記製品情報との修理請求内容の実体が妥当であるか否かを審査し、妥当である場合には妥当であるコードを、妥当でない場合には不適の種類を表すコードを示す審査結果を添付した審査済み修理請求データを出力する審査手段を備え、オペレーティング・システムは、端末装置からのアプリケーション・プログラムの実行要求に基づいて、第１の記憶手段のプログラム領域に記憶されている複数のアプリケーション・プログラムの中から要求に対応するアプリケーション・プログラムを第２の記憶手段にロードするように構成されている。【選択図】図３
2006190340.tif 000002
【特許請求の範囲】
【請求項１】
延長保証契約における家電製品に関する修理請求データの修理請求内容が妥当であるか否かの修理審査を行う修理審査システムであって、サーバと、前記サーバにネットワークを介して接続された端末装置とを備え、前記サーバは、オペレーティング・システムと、顧客企業から通信回線を通して転送された修理請求データを受信する受信手段と、前記受信手段により受信した前記修理請求データを記憶するデータ領域、及び複数のアプリケーション・プログラムを記憶するプログラム領域を有する第１の記憶手段と、前記端末装置からの実行要求に応答して、前記第１の記憶手段から読み出した前記修理請求データの修理請求内容の形式が妥当であるか否かをチェックするチェック手段と、前記チェック手段によりチェックしたチェック済み修理請求データと当該チェック済み修理請求データに対応する保証製品テーブルの製品情報とを記憶する第２の記憶手段と、予め定められた製品種類毎の修理の妥当性を規定する修理審査条件に基づいて、前記第２の記憶手段から読み出した前記チェック済み修理請求データと前記製品情報との修理請求内容の実体が妥当であるか否かを審査し、妥当である場合には妥当であるコードを、妥当でない場合には不適の種類を表すコードを示す審査結果を添付した審査済み修理請求データを出力する審査手段とを備え、前記オペレーティング・システムは、前記端末装置からの前記アプリケーション・プログラムの実行要求に基づいて、前記第１の記憶手段の前記プログラム領域に記憶されている前記複数のアプリケーション・プログラムの中から前記要求に対応するアプリケーション・プログラムを前記第２の記憶手段にロードするように構成されていることを特徴とする修理審査システム。
【請求項２】
前記受信手段は、前記端末装置からの修理請求データ処理要求に応答して、顧客企業から通信回線を通して転送された修理請求データを受信して、前記第１の記憶手段の前記データ領域に記憶するように構成された、前記第１の記憶手段の前記プログラム領域に記憶されているアプリケーション・プログラムの一つである日次請求データ記録プログラムにより実現されることを特徴とする請求項１に記載の修理審査システム。
【請求項３】
前記チェック手段は、前記端末装置からの修理請求データ処理要求に応答して、前記サーバの前記第１の記憶手段から修理請求データを読み出して修理請求内容の形式が妥当か否かをチェックする月次請求データ記録プログラムにより実現されることを特徴とする請求項１に記載の修理審査システム。
【請求項４】
前記月次請求データ記録プログラムは、チェック済み修理請求データと対応する保証製品テーブルの保証製品データとを、前記サーバの前記第２の記憶手段に記憶する機能を更に備えていることを特徴とする請求項３に記載の修理審査システム。
【請求項５】
前記審査手段は、予め定められた製品種類毎の修理の妥当性を規定する前記修理審査条件に基づいて、チェック済み修理請求データと対応する保証製品テーブルの保証製品データとの修理請求内容の実体が妥当であるか否かを審査し、妥当である場合には妥当であるコードを示す審査結果を、妥当でない場合には不適の種類を表すコードを示す審査結果を添付した審査済み修理請求データを出力するように構成された、前記第１の記憶手段の前記プログラム領域に記憶されているアプリケーション・プログラムの一つである修理審査プログラムにより実現されることを特徴とする請求項１に記載の修理審査システム。
【請求項６】
前記第１の記憶手段は、審査済み修理請求データに付加された審査結果を記録した情報を集計し、製品種類別に集計した結果を前記端末装置の表示装置に表示するように構成された、前記第１の記憶手段の前記プログラム領域に記憶されているアプリケーション・プログラムの一つである審査結果モニタ・プログラムを更に記憶していることを特徴する請求項１に記載の修理審査システム。
【請求項７】
前記端末装置からの修理審査条件登録要求に応答して、修理請求データの項目と修理請求額の分析によって決定された前記修理審査条件を登録する登録手段を更に備えていることを特徴とする請求項１に記載の修理審査システム。
【請求項８】
前記登録手段は、前記第１の記憶手段の前記プログラム領域に記憶されているアプリケーション・プログラムの一つである修理審査条件登録プログラムによって実現されることを特徴とする請求項７に記載の修理審査システム。
【請求項９】
前記修理審査条件は、修理審査条件テーブルとして前記第１の記憶手段の前記データ領域に格納されることを特徴とする請求項８に記載の修理審査システム。
【請求項１０】
前記オペレーティング・システムは、前記第１の記憶手段の前記プログラム領域に記憶されている特定の前記プログラムの実行順に必要なハードウェア装置を割り当てて命令を実行し、全ての命令が実行されると、前記端末装置にプログラム実行の終了を伝えて、前記アプリケーション・プログラムを実行するために確保していた前記ハードウェア装置を開放するように構成されていることを特徴とする請求項１から９のいずれか一項に記載の修理審査システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、延長保証契約における家電製品に関する修理請求データの修理請求内容が妥当であるか否かの修理審査を行う修理審査システムに関する。
【背景技術】
【０００２】
本明細書中において、「延長保証契約」とは、被保証者に対しメーカ保証期間終了後、引き続き、または一定期間経過後、一定期間内に発生する製品の故障もしくは不具合の修理を保証する契約をいう。また、「修理請求データ」とは、上記延長保証契約において、当該製品に故障が生じた場合に顧客企業または修理業者等から報告される故障修理または製品の交換に関する故障発生日、故障症状、故障原因、処置、修理請求額などを含むデータをいう。さらに、「修理審査」とは、上記修理請求データで表される修理請求内容が妥当であるか否かを判断（審査）することをいう。具体的には、修理審査では、修理請求内容を次の観点から審査する。（１）故障した製品は、延長保証契約の対象製品であること。（２）故障発生日が、延長保証契約の保証期間内であること。（３）故障原因、処置等が延長保証契約規定の保証規約に照らして、対象となる故障原因、処置であること。（４）修理請求額が妥当であること。
【０００３】
家電製品が故障した場合、その故障の修理は、延長保証契約を締結した顧客企業の修理技術者が１件、１件当該家電製品の故障症状から原因を調査し、当該家電製品に対して必要な処置を施していく。そして、当該家電製品の修理が完了したら、顧客企業は、上記した故障修理または製品の交換に関する故障発生日、故障症状、故障原因、処置、修理請求額等を記載した入力修理請求データを、通信回線を通じて保証会社に転送する。
【０００４】
これに対して、保証会社では、上記入力修理請求データを受信修理請求データとして受信した後、人手により、すなわち修理審査担当者がその受信修理請求データで表される修理請求内容が妥当であるか否かを判定することによって、修理審査を行っている。
【０００５】
具体的には、修理審査担当者は、この受信修理請求データで報告されている家電製品の修理が保証対象の修理か否か、修理請求内容および修理請求額が妥当かどうかを判定する。
【０００６】
このような修理審査を行うためには、修理審査担当者は、修理技術者と同等のノウハウが必要である。例えば、電気機器についていえば、モータの原理、制御回路の実際の回路、電気的・機構的な動作原理、そして電気機器を構成する構成部品などの知識が必要である。しかしながら、修理審査担当者は、故障症状や修理を完了した製品そのものをチェックすることができない。すなわち、修理審査担当者は、上記修理請求データにより表された修理請求として報告された情報の各項目の内容と項目間の関連性から、当該家電製品に係る修理請求に対する修理審査を行っている。
【０００７】
とにかく、従来においては、修理審査担当者が、１件１件、家電製品に係る修理請求の修理審査を修理請求データのみから判断して行っている。そして、修理審査担当者は、その修理請求の修理審査をした結果、その修理請求内容が妥当であれば、修理審査結果として修理請求を受理し、妥当でない場合には、修理審査結果として請求を却下する。
【発明の開示】
【発明が解決しようとする課題】
【０００８】
上述したように、従来の修理請求データの修理審査は、修理審査担当者により、１件１件人の目で判断して行っている。したがって、修理審査の件数の増加に比例して、人手を増加しなければならない。また、家電製品の故障症状から原因を調査し、必要な処置が施されているかどうかを判断するためには、修理審査担当者に高度な専門知識が要求される。また、修理審査担当者の専門知識の深浅により、修理審査結果にばらつきが生じる虞がある。
【０００９】
上述したように、従来の技術では、（１）修理請求の件数に比例して作業量が増加し、また（２）修理審査結果にばらつきが生じる虞があり、均一で正確な修理審査結果が得られないという問題がある。
【００１０】
したがって、本発明の解決課題は、修理審査を自動的に行って、スピーディーに、より均一で正確な修理審査結果を得ることができる修理審査システムを提供することにある。
【課題を解決するための手段】
【００１１】
本発明の上記課題は、延長保証契約における家電製品に関する修理請求データの修理請求内容が妥当であるか否かの修理審査を行う修理審査システムであって、サーバと、前記サーバにネットワークを介して接続された端末装置とを備え、前記サーバは、オペレーティング・システムと、顧客企業から通信回線を通して転送された修理請求データを受信する受信手段と、前記受信手段により受信した前記修理請求データを記憶するデータ領域、及び複数のアプリケーション・プログラムを記憶するプログラム領域を有する第１の記憶手段と、前記端末装置からの実行要求に応答して、前記第１の記憶手段から読み出した前記修理請求データの修理請求内容の形式が妥当であるか否かをチェックするチェック手段と、前記チェック手段によりチェックしたチェック済み修理請求データと当該チェック済み修理請求データに対応する保証製品テーブルの製品情報とを記憶する第２の記憶手段と、予め定められた製品種類毎の修理の妥当性を規定する修理審査条件に基づいて、前記第２の記憶手段から読み出した前記チェック済み修理請求データと前記製品情報との修理請求内容の実体が妥当であるか否かを審査し、妥当である場合には妥当であるコードを、妥当でない場合には不適の種類を表すコードを示す審査結果を添付した審査済み修理請求データを出力する審査手段とを備え、前記オペレーティング・システムは、前記端末装置からの前記アプリケーション・プログラムの実行要求に基づいて、前記第１の記憶手段の前記プログラム領域に記憶されている前記複数のアプリケーション・プログラムの中から前記要求に対応するアプリケーション・プログラムを前記第２の記憶手段にロードするように構成されている修理審査システムによって達成される。
【発明の効果】
【００１２】
本出願人は、事業開始当初より、より適正なサービスを提供するために、認定資格取得も踏まえて修理審査担当者を育成してきた。また、当システムを開発することを目標として、修理審査に必要な事象を分析し、システム設計を行い、審査済み修理請求データを蓄積してきた。その結果、本出願人には、現在、約６０万件の審査済み修理請求データが本出願人のデータベースに蓄積されている。
このデータベースに蓄積された審査済み修理請求データは、１件、１件専門性を有した修理審査担当者の修理審査による修理審査結果を反映したデータである。そこで、本発明者は、このデータベースに蓄積された審査済み修理請求データを分析して、新規な修理審査ルールを発見し、この修理審査ルールに従って自動的に修理審査を実行する修理審査システムを開発することによって、上記課題を解決した。
【００１３】
ここで、「修理審査ルール」とは、同じような家電製品の同じような故障原因による故障修理に対しては同じような処置がとられて、同じような修理費用が必要になる、という経験則である。換言すれば、修理審査ルールは、予め定められた製品種類毎の修理の妥当性を規定するものである。したがって、この修理審査ルールに従って、修理請求データの修理審査を自動的に行えば、人手を介するよりも、短時間に修理請求データの修理請求内容が妥当であるか否かを容易に判断することができ、均一で正確な修理審査結果を得ることができる。
この修理審査ルールを発見するために、本発明者は、実際に、データベースに蓄積されている審査済み修理請求データの中から特定の家電製品を選び、その選択した家電製品における、故障原因、故障修理、処置、および修理費用を比較してみた。その結果、経験則から予想される通り、本発明者は、同じような家電製品の同じような故障原因による故障修理に対しては同じような処置がとられており、ほぼ同じ修理費用が必要になっていたことを、確認（発見）した。そこで、本発明者は、この修理審査ルールを自動修理審査に適用することに想到した。
【００１４】
尚、この修理審査ルールに基づいて、修理請求データの修理請求内容の実体が妥当でないと判断された場合、その不適の種類を表すコードを示す審査結果が審査済み修理請求データに添付される。これにより、修理審査ルールから除外された審査済み修理請求データに対しては、従来同様、人手により修理審査を行うことになるが、不適の種類を表すコードが添付されているので、従来よりもより容易かつ正確に修理審査を行えるようになった。
本発明は、過去から蓄積された審査済み修理請求データを分析することによって得られる修理請求の修理審査ルールを、コンピュータ・システムで処理することにより、上述した従来の技術の上記（１）、（２）の問題を解決し、コストの削減および顧客サービスの向上を図るようにした。
ここで、「修理請求内容の形式」とは、修理請求データに必要な項目のことである。一方、「修理請求内容の実体」とは、修理請求データに含まれる項目の実体的な内容、すなわち、故障原因、処置、修理請求額等のことをいう。
【００１５】
このように、本発明によれば、システム化を実現することによって、従来修理審査担当者が、１件、１件修理審査していた修理請求を、コンピュータで修理審査ルールに基づいて実体審査を実行し、修理請求データの修理請求内容が妥当であるか否かの修理審査を自動的に行う。修理審査の結果、妥当である場合には妥当であるコード、妥当でない場合には不適の種類を表すコードを審査済み修理請求データに付加する。
尚、上記コードとしては、実際には、セグメント・コードとExitモジュール・コードが使用され、審査済み修理請求データに付加される。ここで、「セグメント・コード」は、受信修理請求データの内容の形式をコンピュータでチェックした結果のエラーの有無により、次の２つの区分に分かれる。（１）エラーがあれば、エラーの種類、（２）エラーがなければ、修理請求額の修理審査ルールの対象となる修理請求額範囲の下限以下、範囲内、または上限以上という修理請求額帯の区分。また、「Exitモジュール・コード」は、チェック済み修理請求データを修理審査ルールにしたがって実体審査を実行したときに、修理審査ルールのどの条件で不適と判断され審査対象から除外されたのかを区分する。
【００１６】
修理審査担当者は、端末装置から製品種類、セグメント・コード、Exitモジュール・コードを指定して審査済み修理請求データを特定することができる。このようにして、従来受付順に行っていた人手による修理審査を、製品種類別にセグメント化された類似する審査済み修理請求データを端末画面から連続して修理審査の操作ができる。このため、修理審査の正確性と効率が向上する。
結果としてもたらされる生産性の向上は、コストの削減につながる。また、精度の向上は、均一な審査をスピーディーに行うことにより、顧客サービスの向上を期待できる。
【発明を実施するための最良の形態】
【００１７】
本発明の修理審査システムでは、前記受信手段は、前記端末装置からの修理請求データ処理要求に応答して、顧客企業から通信回線を通して転送された修理請求データを受信して、前記第１の記憶手段の前記データ領域に記憶するように構成された、前記第１の記憶手段の前記プログラム領域に記憶されているアプリケーション・プログラムの一つである日次請求データ記録プログラムにより実現されるように構成してもよい。
【００１８】
本発明の修理審査システムでは、前記チェック手段は、前記端末装置からの修理請求データ処理要求に応答して、前記サーバの前記第１の記憶手段から修理請求データを読み出して修理請求内容の形式が妥当か否かをチェックする月次請求データ記録プログラムにより実現されるように構成してもよい。
【００１９】
本発明の修理審査システムでは、前記月次請求データ記録プログラムは、チェック済み修理請求データと対応する保証製品テーブルの保証製品データとを、前記サーバの前記第２の記憶手段に記憶する機能を更に備えて構成してもよい。
【００２０】
本発明の修理審査システムでは、前記審査手段は、予め定められた製品種類毎の修理の妥当性を規定する前記修理審査条件に基づいて、チェック済み修理請求データと対応する保証製品テーブルの保証製品データとの修理請求内容の実体が妥当であるか否かを審査し、妥当である場合には妥当であるコードを示す審査結果を、妥当でない場合には不適の種類を表すコードを示す審査結果を添付した審査済み修理請求データを出力するように構成された、前記第１の記憶手段の前記プログラム領域に記憶されているアプリケーション・プログラムの一つである修理審査プログラムにより実現されるように構成してもよい。
【００２１】
本発明の修理審査システムでは、前記第１の記憶手段は、審査済み修理請求データに付加された審査結果を記録した情報を集計し、製品種類別に集計した結果を前記端末装置の表示装置に表示するように構成された、前記第１の記憶手段の前記プログラム領域に記憶されているアプリケーション・プログラムの一つである審査結果モニタ・プログラムを更に記憶しているように構成してもよい。
【００２２】
本発明の修理審査システムでは、前記端末装置からの修理審査条件登録要求に応答して、修理請求データの項目と修理請求額の分析によって決定された前記修理審査条件を登録する登録手段を更に備えて構成してもよい。
【００２３】
本発明の修理審査システムでは、前記登録手段は、前記第１の記憶手段の前記プログラム領域に記憶されているアプリケーション・プログラムの一つである修理審査条件登録プログラムによって実現されるように構成してもよい。
【００２４】
本発明の修理審査システムでは、前記修理審査条件は、修理審査条件テーブルとして前記第１の記憶手段の前記データ領域に格納されるように構成してもよい。
【００２５】
本発明の修理審査システムでは、前記オペレーティング・システムは、前記第１の記憶手段の前記プログラム領域に記憶されている特定の前記プログラムの実行順に必要なハードウェア装置を割り当てて命令を実行し、全ての命令が実行されると、前記端末装置にプログラム実行の終了を伝えて、前記アプリケーション・プログラムを実行するために確保していた前記ハードウェア装置を開放するように構成してもよい。
【実施例】
【００２６】
以下、本発明の実施の形態について図面を参照して詳細に説明する。
図１は、本発明の一実施の形態に係る修理審査システムのハードウェアの構成図である。
図示の修理審査システムは、サーバ装置１０と、端末装置２０とを備え、これらはローカル・エリア・ネットワーク（ＬＡＮ）３０を介して接続されている。尚、図示の例では、サーバ装置１０と端末装置２０とは、ＬＡＮ３０を介して接続されているが、他のネットワークを使用しても良い。また、図示の例では、１台の端末装置２０のみを図示しているが、多数の端末装置を備えていても良いのは勿論である。
【００２７】
サーバ装置１０は、第１の通信制御装置１１を介して公衆回線（通信回線）に接続されており、第２の通信制御装置１２を介してＬＡＮ３０に接続されている。一方、端末装置２０は、第３の通信制御装置２１を介してＬＡＮ３０に接続されている。また、サーバ装置１０はディスク装置４０を備えている。
【００２８】
サーバ装置１０は、ＣＰＵ５１と、第１のシステム・バス５２と、データベース・マネージメント・システム５３と、オペレーティング・システム（ＯＳ）５４と、実記憶域（メモリ）５５と、第２のシステム・バス５６とを有する。第１のシステム・バス５２は第１の通信制御装置１１に接続され、第２のシステム・バス５６は第２の通信制御装置１２に接続されている。
【００２９】
端末装置２０は、後述するように、日次修理請求データ処理要求、月次修理請求データ処理要求、修理審査条件登録要求、および修理審査結果モニタ要求をサーバ装置１０へ送出する。
【００３０】
ディスク装置４０は、データやテーブルを格納するデータ領域と、アプリケーション・プログラムを格納するプログラム領域とを持つ。データ領域には、後述するような、入力修理請求データＴ１、受信修理請求データＴ２、審査済み修理請求データＴ３、修理審査条件テーブルＴ４、保証製品テーブルＴ５、各種コード・テーブルＴ６、および審査対象製品テーブルＴ７が格納される。一方、プログラム領域には、後述するような、請求データ記録（日次）プログラムＰ１、請求データ記録（月次）プログラムＰ２、修理審査条件登録プログラムＰ３、修理審査プログラムＰ４、および審査結果モニタ・プログラムＰ５が格納されている。
【００３１】
第１の通信制御装置１１は通信制御プログラムに従って動作する。すなわち、その通信制御プログラムは、顧客企業（図示せず）から通信回線を通して転送されてきたテキスト形式の入力修理請求データを、ディスク装置４０のデータ領域に入力修理請求データＴ１として格納する。この転送には、本例では、ファイル・トランスファー・プロトコルを利用している。
【００３２】
図２に入力修理請求データＴ１の構成を示す。入力修理請求データＴ１には項目名として唯一の製品伝票番号が付されている。すなわち、この製品伝票番号は、入力修理請求データＴ１毎に異なる番号が付される。製品伝票番号は、製品販売時にＰＯＳシステムで採番された番号を示している。
【００３３】
入力修理請求データＴ１は、項目名として、さらに、勘定年月、製品ＣＤ、メーカ保証期間、製品型式、製造番号、製品交換フラグ、修理受付日、修理完了日、故障状況１、故障状況２、故障状況３、故障原因、故障処置１、故障処置２、修理部品１、修理部品２、修理部品３、修理実施店舗、請求部品代、請求工料、請求出張費、および請求消費税がある。勘定年月は修理請求データの報告月（１日−月末日）を示している。製品ＣＤは製品タイプコードを意味し、そのうち上４桁は製品種類を示している。メーカ保証期間はメーカの修理保証期間を示し、通常１年間である。製品型式は製品型式を示し、製造番号は製造番号を示している。製品交換フラグは修理請求に対して、製品を交換したか否かを区分している。修理受付日はユーザから修理報告を受け付けた日を示している。修理完了日は修理が完了した日を示している。故障状況１〜３は故障状況コードを示している。故障原因は故障原因コードを示している。故障処置１、２は故障に対して施した処置のコードを示している。修理部品１〜３は修理に対して交換した部品のコードを示している。修理実施店舗は修理を実施した店舗コードを示している。請求部品は部品請求額を示している。請求工料は工料請求額を示している。請求出張費は出張費請求額を示している。請求消費税は各請求額の合計に対する消費税を示している。ここで、請求部品代、請求工料、請求出張費、および請求消費税の合計が修理請求額である。
【００３４】
入力修理請求データＴ１は、項目名として、さらに、部品代、工料、出張費、および消費税がある。部品代は審査後の確定した部品代を示している。工料は審査後の確定した工料を示している。出張費は審査後の確定した出張費を示している。消費税は部品代、工料、出張費の合計に対する消費税を示している。尚、これら部品代、工料、出張費、および消費税は、後述する請求データ記録（月次）プログラムＰ２による形式チェックおよび修理審査プログラムＰ４による実体審査の自動修理審査が確定するまでは、空欄である。尚、部品代、工料、出張費、および消費税の合計が修理額である。
【００３５】
図１に戻って、オペレーティング・システム５４は、端末装置２０からのプログラムの実行要求に基づいて、ディスク装置４０に登録されているアプリケーション・プログラムを第２のシステム・バス５６を経由して実記憶域５５にロードする。オペレーティング・システム５４は、プログラムの実行順に必要な各装置を割り当てて命令を実行する。
【００３６】
第２のシステム・バス５６は、命令の実行に必要な各装置間とデータの交換を行う。オペレーティング・システム５４は、全ての命令が実行されると、端末装置２０にプログラム実行の終了を伝え、プログラム実行のために確保していた各装置を開放する。
【００３７】
尚、図１に図示した修理審査システムは、汎用コンピュータとオンライン端末、或いは、パーソナル・コンピュータ等の他の機器構成でも実現可能である。
【００３８】
図３は、図１に図示した修理審査システムのディスク装置４０に格納されているプログラムとデータおよびテーブルの関連を示すシステム概要図である。
【００３９】
請求データ記録（日次）プログラムＰ１は、端末装置２０からの日次修理請求データ処理要求に応答して、顧客企業から通信回線を通して転送された入力修理請求データを受信して、サーバ装置１０のディスク装置４０に受信修理請求データＴ２として格納する受信手段を実現するプログラムである。ここで、ディスク装置４０は第１の記憶手段として働く。
【００４０】
図４に受信修理請求データＴ２の構成を示す。受信修理請求データＴ２は、項目名として、エラー１〜５、回答入力日、問合せ状況、状況コード（ステータス）、セグメント・コード、およびExitモジュール・コードが付加されている点を除いて、図２に示された入力修理請求データＴ１と同様の構成を有する。
【００４１】
エラー１〜５はデータチェックによって検出されたエラーのコードを示す。回答入力日は内容紹介に対して回答を入力した日を示す。問合せ状況は問合せに対する回答状況（回答待、再度照会等）を示す。状況コード（ステータス）は修理請求データの扱状況（保留、支払確定、請求取下）を示す。セグメント・コードはエラーの種類、修理請求額の金額帯を表すコードである。Exitモジュール・コードは修理審査の結果を表すコードである。
【００４２】
すなわち、受信修理請求データＴ２は、入力修理請求データＴ１をサーバ装置１０のディスク装置４０に日々累積したデータである。尚、受信修理請求データＴ２における項目名の中で、エラー１〜５、回答入力日、セグメント・コード、およびExitモジュール・コードは空白になっている。
【００４３】
図３に戻って、請求データ記録（月次）プログラムＰ２は、端末装置２０からの月次修理請求データ処理要求（実行要求）に応答して、サーバ装置１０のディスク装置４０から受信修理請求データＴ２の修理請求内容の形式が妥当か否かをチェックして、チェック済み修理請求データと対応する保証製品テーブルＴ５の保証製品データとをサーバ装置１０の実記憶域５５に格納する手段を実現するプログラムである。ここで、実記憶域５５は第２の記憶手段として働く。
【００４４】
修理審査プログラムＰ４は、予め定められた製品種類毎の修理の妥当性を規定する修理審査ルールに基づいて、チェック済み修理請求データと対応する保証製品テーブルＴ５の保証製品データとの修理請求内容の実体が妥当であるか否かを審査し、妥当である場合には妥当であるコードを、妥当でない場合には不適の種類を表すコードを示す審査結果を添付した審査済み修理請求データＴ３を出力する審査手段を実現するプログラムである。
【００４５】
図５に審査済み修理請求データＴ３の構成を示す。審査済み修理請求データＴ３は、図４に図示した受信修理請求データＴ２と同一の構成を有する。
【００４６】
すなわち、審査済み修理請求データＴ３は、受信修理請求データＴ２に対して、請求データ記録（月次）プログラムＰ２による形式チェックと修理審査プログラムＰ４による実体審査とを施し、その結果としてエラー・コード、セグメント・コード、およびExitモジュール・コードを付加したデータである。
【００４７】
修理審査条件登録プログラムＰ３は、端末装置２０からの修理審査条件登録要求に応答して、後述するように、修理請求データの項目と修理請求額の分析によって決定された修理審査条件（修理審査ルール）を登録するプログラムである。この修理審査条件登録プログラムＰ３で登録された修理審査条件は、修理審査条件テーブルＴ４としてディスク装置４０に格納される。
【００４８】
図６に修理審査条件テーブルＴ４の構成を示し、図７に修理審査条件テーブルＴ４の具体例を示す。
【００４９】
図６に示されるように、修理審査条件テーブルＴ４は、項目名として、審査条件番号、製品種類、条件項目、条件、および登録日がある。審査条件番号はテーブル登録のキーを示している。製品種類は製品種類を示している。条件項目は条件を指定する項目名を示している。条件は各項目毎に、修理請求の妥当性を判定する条件の値や範囲を示している。登録日は条件テーブルの更新日を示している。
【００５０】
図７に示されるように、修理審査条件テーブルＴ４は、製品種類毎に、修理請求データの修理請求内容の実体が妥当であるか否かを判定するための条件を、製品タイプ、メーカ、原因、処置をコードで、購入価格（金額）、修理請求額を数値範囲で特定しその内容を記録したデータである。
【００５１】
図７では、審査条件が“Ａ００２”の場合で、製品種類がカラーテレビの例を図示している。修理審査をしようとしている製品種類がカラーテレビの修理請求データであれば、製品タイプが、１４型ＶＴＲ内蔵、２０型ＶＴＲ内蔵、あるいは２８ワイドのいずれかであるかを判定する。次に、修理請求データに対応する保証製品データのメーカが、Ａ社、Ｂ社、Ｃ社、あるいはＤ社のいずれかであるかを判定する。同様にして修理請求データの原因、処置についても修理審査条件テーブルＴ４の条件で与えられた値と比較する。そして、修理請求データに対応する保証製品データの購入価格と修理請求データの修理請求額が、修理審査条件の購入価格と修理請求額の下限と上限の範囲に含まれるかどうかを比較する。このようにして、修理請求データと対応する保証製品テーブルＴ５の保証製品データの項目が修理審査条件テーブルＴ４の各項目を満たせば、その修理請求が妥当な修理請求であると判定される。
【００５２】
尚、修理審査条件テーブルＴ４の各項目を比較するときに、修理請求データで特定する製品に関する情報を保証製品データを参照することによって得ている。例えば、メーカについていえば、この項目は修理請求データには存在しないので、保証製品データを参照してメーカ情報を得ている。
【００５３】
図３に戻って、審査結果モニタ・プログラムＰ５は、修理審査結果をモニタするプログラムであって、後述するように、審査済み修理請求データＴ３に付加された審査結果を記録した情報を集計し、製品種類別に集計した結果を端末装置２０に表示するプログラムである。
【００５４】
図８に請求データ記録（月次）プログラムＰ２において用いられる保証製品テーブルＴ５の構成を示す。保証製品テーブルＴ５には、項目名として唯一の製品伝票番号が付されている。この製品伝票番号は、上述した入力修理請求データＴ１、受信修理請求データＴ２、審査済み修理請求データＴ３に付されるものと同一である。
【００５５】
保証製品テーブルＴ５は、項目名として、勘定年月、販売店舗、販売日、購入価格、購入者、製品ＣＤ、製品型式、メーカコード、メーカ保証期間、メーカ保証完了日、延長保証開始日、延長保証完了日、登録日、更新日、メモ、および状態がある。
【００５６】
勘定年月は保証製品データの報告月（１日−月末日）を示している。販売店舗は製品を販売した店舗コードを示している。販売日は製品販売日を示している。購入価格は製品の購入価格を示している。購入者は製品購入者（顧客番号、顧客名等）を示している。製品ＣＤは製品タイプコードを意味し、そのうち上４桁は製品種類を示している。製品型式は製品型式を示している。メーカコードは製品製造メーカのコードを示している。メーカ保証期間はメーカの修理保証期間（通常１年間）を示している。メーカ保証完了日はメーカの修理保証期間の終了日を示している。延長保証開始日はメーカの修理保証期間の終了日の翌日を示している。延長保証完了日は延長保証期間の終了日を示している。登録日は製品データをテーブルに登録した日を示している。更新日は製品データを更新した日を示している。メモは特記事項を示している。状態はデータの有効性（有効／無効）を示している。
【００５７】
すなわち、保証製品テーブルＴ５は、延長保証契約の対象になった製品情報を示している。この保証製品テーブルＴ５には、製品購入時に、購入者、製品購入日、保証期間、製品種類、購入価格等の情報が記録される。
【００５８】
図９に請求データ記録（月次）プログラムＰ２において用いられる各種コード・テーブルＴ６の構成を示す。各種コード・テーブルＴ６は、項目名として、コード種類、コード、コード名、登録日、および状況（ステータス）がある。コード種類はコード種類を示す。コードはコードを示す。コード名はコード名（コードが表す内容）を示す。登録日はコード登録日を示す。状況（ステータス）はコードの有効性（有効／無効）を示す。
【００５９】
すなわち、各種コード・テーブルＴ６は、修理請求データのコードをチェックするためと修理審査条件の登録時に端末画面にコードとコード名を表示するために各種コードを記録したテーブルである。コード種類には、故障状況、故障原因、故障処置、部品、製品タイプ、メーカの６種類がある。
【００６０】
図１０に各種コード・テーブルＴ６のコードとして使用されるコードの例を示す。
【００６１】
図１０（１）に示されるように、コード種類が故障状況のときのコードである故障状況コードとしては、例えば、“１１１００１”がコード名「電源はいらず」を、“１１１００２”がコード名「映像、音声が出ない（光ってはいるが表示されない）」を、“１１１００４”がコード名「映像が全く表示されない」を、“１１１０１１”がコード名「リモコンが効かない」を、“１１１０２６”がコード名「電源が切れない」を、それぞれ表している。
【００６２】
図１０（２）に示されるように、コード種類が故障原因のときのコードである故障原因コードとしては、例えば、“０２”がコード名「劣化」を、“０３”がコード名「電気的な特性ずれ（半導体部品の故障）」を、“０４”がコード名「接触不良」を、“１０”がコード名「ショート」を、“１１”がコード名「断線」を、それぞれ表している。
【００６３】
図１０（３）に示されるように、コード種類が故障処置のときのコードである故障処置コードとしては、例えば、“０１”がコード名「部品交換」を、“０２”がコード名「調整」を、“０５”がコード名「注油」を、“１６”がコード名「半田付け」を、“３１”がコード名「ユニット交換」を、それぞれ表している。
【００６４】
図１０（４）に示されるように、コード種類が部品のときのコードである部品コードとしては、例えば、“１０２１”がコード名「アンテナ部品」を、“１０３０”がコード名「エアーフィルター」を、“１０３７”がコード名「タンクキャップ」を、“１０５８”がコード名「グローランプ」を、“１１０５”がコード名「タイマー」を、それぞれ表している。
【００６５】
図１０（５）に示されるように、コード種類が製品タイプのときのコードである製品タイプコードとしては、例えば、“１１１０１２”がコード名「カラーテレビ  ３０以上ワイド」を、“１１１０２２”がコード名「カラーテレビ  ２８ワイド」を、“１１１０５０”がコード名「カラーテレビ  ２０，２１型４：３」を、“１１１０５４”がコード名「カラーテレビ  ２０型ＶＴＲ内蔵」を、“１１１０７４”がコード名「カラーテレビ  １４型ＶＴＲ内蔵」を、それぞれ表している。
【００６６】
図１０（６）に示されるように、コード種類がメーカのときのコードであるメーカコードとしては、例えば、“０１１１０”がコード名「Ｃ社」を、“０１３１０”がコード名「Ｅ社」を、“０２１１０”がコード名「Ｄ社」を、“０２２１０”がコード名「Ａ社」を、“０３９２０”がコード名「Ｂ社」を、それぞれ表している。
【００６７】
尚、本実施の形態では、各種コード・テーブルＴ６を１つのデータファイルとして構成しているが、６種類のコード種類毎に６個のコード・テーブルで構成しても良いのは勿論である。
【００６８】
図１１に修理審査プログラムＰ４において用いられる審査対象製品テーブルＴ７の構成を示す。審査対象テーブルＴ７は、項目名として、製品種類、自動審査対象オン／オフ、切替登録日、および初期登録日がある。製品種類は製品を示している。自動審査対象オン／オフは、オンが審査対象を、オフが審査対象外を示している。切替登録日はオン／オフの切替を行った日を示している。初期登録日は製品種類を登録した日を示している。
【００６９】
すなわち、審査対象製品テーブルＴ７は、審査方法切替プログラム（図示せず）によって指定された修理審査条件の対象となる製品種類を記録している。
【００７０】
次に、図１２を参照して、サーバ装置１０において実行される請求データ記録（日次）プログラムＰ１について説明する。
【００７１】
請求データ記録（日次）プログラムＰ１は、端末装置２０からの日次修理請求データ処理要求に基づいて、サーバ装置１０のオペレーティング・システム５４によって実行される。オペレーティング・システム５４は、ディスク装置４０に登録されているアプリケーション・プログラムから要求された請求データ記録（日次）プログラムＰ１を第２のシステム・バス５６を経由して、実記憶域５５にロードする。オペレーティング・システム５４は、図１２に図示するフローチャートに従って、次に述べるように、請求データ記録（日次）プログラムＰ１の命令を実行する。
【００７２】
オペレーティング・システム５４は、先ず、顧客企業システムから通信回線を通してディスク装置４０に転送された入力修理請求データＴ１をディスク装置４０から読み込み（ステップＳ１０１）、第２のシステム・バス５６を経由して、その読み込んだ入力修理請求データＴ１を実記憶域５５に移す（ステップＳ１０２）。
【００７３】
引き続いて、オペレーティング・システム５４は、実記憶域５５から読み込んだ入力修理請求データＴ１を、第２のシステム・バス５６を経由してディスク装置４０に、上述したようにエラー１〜５、セグメント・コード、およびExitモジュール・コード等の項目を追加した状態で受信修理請求データＴ２として書き込む（ステップＳ１０３）。
【００７４】
ここで、入力修理請求データＴ１は、媒体、記録形式を限定しない。また、日次、月次といった処理サイクルも特に限定しない。
【００７５】
次に、図１３を参照して、サーバ装置１０において実行される請求データ記録（月次）プログラムＰ２について説明する。
【００７６】
請求データ記録（月次）プログラムＰ２は、端末装置２０からの月次修理請求データ処理要求に基づいて、サーバ装置１０のオペレーティング・システム５４によって実行される。オペレーティング・システム５４は、ディスク装置４０に登録されているアプリケーション・プログラムから要求された請求データ記録（月次）プログラムＰ２を第２のシステム・バス５６を経由して、実記憶域５５にロードする。オペレーティング・システム５４は、図１３に図示するフローチャートに従って、次に述べるように、請求データ記録（月次）プログラムＰ２の命令を実行する。
【００７７】
オペレーティング・システム５４は、ディスク装置４０から受信修理請求データＴ２を読み込み、それを第２のシステム・バス５６を経由して、実記憶域５５のチェック済み修理請求データ格納域（図示せず）に移す（ステップＳ２０１）。
【００７８】
引き続いて、オペレーティング・システム５４は、実記憶域５５に移された受信修理請求データＴ２の製品伝票番号をキーにして、保証製品テーブルＴ５に同一の製品伝票番号を持った保証製品データが存在するかどうかを検索する。存在する場合には、当該製品データを実記憶域５５の保証製品データ格納域（図示せず）に移す（ステップＳ２０２）。上述のキー項目は、製品伝票番号に限定されず、製品を特定することが可能な項目であれば良い。
【００７９】
次に、オペレーティング・システム５４は、保証製品テーブルＴ５に当該製品データが存在しないと判断した場合（ステップＳ２０３のＹｅｓ）、実記憶域５５上のチェック済み修理請求データにエラー・コードとして「製品データが未登録」を示す‘３０５２’をセットし（ステップＳ２０４）、ステップＳ２０７へ進む。
【００８０】
一方、オペレーティング・システム５４は、当該製品データが保証製品テーブルＴ５に存在するが（ステップＳ２０３のＮｏ）、その故障発生日が保証製品データの保証期間内にないとき（ステップＳ２０５のＮｏ）、実記憶域５５上のチェック済み修理請求データにエラー・コードとして「修理受付日が保証期間外」を示す‘３１３２’をセットし（ステップＳ２０６）、ステップＳ２０７へ進む。
【００８１】
尚、当該製品データが保証製品テーブルＴ５に存在し（ステップＳ２０３のＮｏ）、かつ、その故障発生日が保証製品データの保証期間内にあるとき（ステップＳ２０５のＹｅｓ）、オペレーティング・システム５４は、直接、ステップＳ２０７へ進む。
【００８２】
ステップＳ２０７では、オペレーティング・システム５４は、受信修理請求データＴ２の故障状況、故障原因、故障処置、修理部品のコード類をチェックする。すなわち、オペレーティング・システム５４は、実記憶域５５に記録されているチェック済み修理請求データの各コードをディスク装置４０の各種コード・テーブルＴ６と照合する。
【００８３】
ここで、受信修理請求データＴ２の故障状況コードが各種コード・テーブルＴ６に存在しない場合（ステップＳ２０８のＹｅｓ）、オペレーティング・システム５４は、実記憶域５５上のチェック済み修理請求データにエラー・コードとして「故障状況コード・エラー」を示す‘３１６２’をセットする（ステップＳ２０９）。受信修理請求データＴ２の故障原因コードが各種コード・テーブルＴ６に存在しない場合（ステップＳ２１０のＹｅｓ）、オペレーティング・システム５４は、実記憶域５５上のチェック済み修理請求データにエラー・コードとして「故障原因コード・エラー」を示す‘３２１２’をセットする（ステップＳ２１１）。受信修理請求データＴ２の故障処置コードが各種コード・テーブルＴ６に存在しない場合（ステップＳ２１２のＹｅｓ）、オペレーティング・システム５４は、実記憶域５５上のチェック済み修理請求データにエラー・コードとして「故障処置コード・エラー」を示す‘３２２２’をセットする（ステップＳ２１３）。受信修理請求データＴ２の故障部品コードが各種コード・テーブルＴ６に存在しない場合（ステップＳ２１４のＹｅｓ）、オペレーティング・システム５４は、実記憶域５５上のチェック済み修理請求データにエラー・コードとして「故障部品コード・エラー」を示す‘３２８２’をセットする（ステップＳ２１５）。
【００８４】
次に、オペレーティング・システム５４は、修理請求額の限度額をチェックする（ステップＳ２１６）。すなわち、オペレーティング・システム５４は、受信修理請求データＴ２のその他の項目をチェックする。尚、その他の項目としては、例えば、同一製品に対する修理請求の既歴について、有無を確認する。ここで、エラーがあった場合（ステップＳ２１６のＹｅｓ）、オペレーティング・システム５４は、実記憶域５５上のチェック済み修理請求データのエラー・コードをセットする（ステップＳ２１７）。
【００８５】
このようにして、エラーが検出されると、実記憶域５５のチェック済み修理請求データにエラーの内容を示すエラー・コードが編集される。チェックが終了すると、オペレーティング・システム５４は、修理審査プログラムＰ４を起動させる（ステップＳ２１８）。この修理審査プログラムＰ４については、後で図１７に示すフローチャートを参照して詳述する。
【００８６】
修理審査プログラムＰ４の実行が終了すると、オペレーティング・システム５４は、審査済み修理請求データＴ３の書込み命令を実行する（ステップＳ２１９）。すなわち、オペレーティング・システム５４は、実記憶域５５のチェック済み修理請求データを第２のシステム・バス５６を経由してディスク装置４０に審査済み修理請求データＴ３として書き込む。
【００８７】
次に、図１４を参照して、サーバ装置１０において実行される修理審査条件登録プログラムＰ３について説明する。
【００８８】
修理審査条件登録プログラムＰ３は、端末装置２０からの修理審査条件登録要求に基づいて、サーバ装置１０のオペレーティング・システム５４によって実行される。オペレーティング・システム５４は、ディスク装置４０に登録されているアプリケーション・プログラムから要求された修理審査条件登録プログラムＰ３を第２のシステム・バス５６を経由して、実記憶域５５にロードする。オペレーティング・システム５４は、図１４に図示するフローチャートに従って、次に述べるように、修理審査条件登録プログラムＰ３の命令を実行する。
【００８９】
オペレーティング・システム５４は、端末装置２０に修理審査条件入力画面を表示する（ステップＳ３０１）。引き続いて、オペレーティング・システム５４は、端末装置２０の修理審査条件入力画面で指定された製品種類コードを読み込む（ステップＳ３０２）。端末装置２０から入力された製品種類コードは、通信制御装置２１、ＬＡＮ３０、通信制御装置１２、第２のシステム・バス５６を経由して、実記憶域５５に記録される。
【００９０】
オペレーティング・システム５４は、記録された製品種類に必要な各種テーブルをディスク装置４０の各種コード・テーブルＴ６から、製品タイプ、メーカコード、故障原因コード、処置コードを抽出して、実記憶域５５に記録する（ステップＳ３０３）。実記憶域５５に記録されたその製品種類に関する各種コード類は、第２のシステム・バス５６、通信制御装置１２、ＬＡＮ３０、通信制御装置２１を経由して、端末装置２０の修理審査条件入力画面上に表示される。
【００９１】
図１５に修理審査条件入力画面の一例を示す。図１５から明らかなように、審査条件として、（１）製品、（２）メーカ、（３）購入価格、（４）原因、（５）処置、（６）全損、（７）修理請求額の７つの項目がある。図１５に示す例では、製品種類コードが“１１１０”で、これは製品種類がカラーテレビであることを示している。審査条件の（１）製品としては、製品タイプコード“１１１０７４”が１４型ＶＴＲ内蔵を、製品タイプコード“１１１０５４”が２０型ＶＴＲ内蔵を、製品タイプコード“１１１０２２”が２８ワイドを、製品タイプコード“１１１０１２”が３０以上ワイドを、製品タイプコード“１１１０５０”が２０．２１型４：３を、製品タイプコード“１１１０４０”が２５型４−３を、製品タイプコード“１１１０７０”が１４型を示している。
【００９２】
審査条件の（２）メーカとしては、メーカコード“０２２１０”がＡ社を、メーカコード“０３９２０”がＢ社を、メーカコード“０１１１０”がＣ社を、メーカコード“０２１１０”がＤ社を、メーカコード“０１３１０”がＥ社を、メーカコード“０１４１０”がＦ社を、メーカコード“０１２１０”がＧ社を示している。
【００９３】
審査条件の（３）購入価格としては、１００００円〜２３００００円の範囲が設定されている。審査条件の（４）原因としては、故障原因コード“０３”が電気的な特性ずれを、故障原因コード“０２”が劣化を、故障原因コード“０４”が接触不良を、故障原因コード“１１”が断線を、故障原因コード“２９”がメカ動作不良を、故障原因コード“１０”がショートを、故障原因コード“１２”が容量抜けを示している。
【００９４】
審査条件の（５）処置としては、処置コード“０１”が部品交換を、処置コード“１６”が半田付けを示している。審査条件の（６）全損としては、分損が設定されている。審査条件の（７）修理請求額としては、３５００円〜２００００円の範囲が設定されている。
【００９５】
オペレーティング・システム５４は、図１５に図示する修理審査条件入力画面から、上記（１）から（５）および（７）の審査条件を読み込む（ステップＳ３０４）。読み込まれた（１）から（５）および（７）の審査条件は、通信制御装置２１、ＬＡＮ３０、通信制御装置１２、第２のシステム・バス５６を経由して、実記憶域５５に送られ、修理審査条件テーブルＴ４のフォーマットに編集される。引き続いて、オペレーティング・システム５４は、実記憶域５５に編集された修理審査条件テーブルＴ４を、ディスク装置４０に修理審査条件テーブルＴ４として書き込む（ステップＳ３０５）。
【００９６】
次に、審査済み修理請求データを蓄積したデータベースを活用した修理審査条件の分析手法ついて説明する。
【００９７】
上述した従来の技術において述べた運用において、１件、１件修理審査された結果は、原因および処置等が細分化されたコード体系でデータベースに整理・記録されている。そして、これらデータベースに蓄積されたデータが、大数の法則が働く量になれば、統計的な手法から一定の修理審査ルールを発見できるだろうというのが、本発明の発想の原点である。
【００９８】
データベースに蓄積された審査済み修理請求データの持つ各項目と修理請求額との間にどのような関連が存在するのかを、本発明者は、データ・マイニング手法を用いて関連性を分析した。ここで、「データ・マイニング手法」とは、大量のデータのなかに埋もれた規則性、関連性など意味あるパターン等を発見する技法をいう。その結果、本発明者は、修理請求額のばらつきが少ない修理請求データを、項目の値や範囲で特定することができた。
【００９９】
修理審査ルールとは、項目の値や範囲で特定することができる、同じような製品の同じような故障原因による故障修理に対しては同じような処置がとられて、同じような修理費用が必要になる、ということが成り立つ条件である。
【０１００】
例として、修理審査件数が最も多い製品種類であるビデオデッキの分析結果について説明する。本発明者は、ビデオデッキの修理請求データを製品タイプ別に故障修理１件あたりの平均修理額を算出した。その結果、ハイファイ、ＢＳ内蔵ハイファイ、ＳＶＨＳ、そしてＢＳ内蔵ＳＶＨＳの平均修理額は、ほぼ同額になり、同時にビデオデッキ全体の平均修理額とほぼ同額になった。
【０１０１】
また、本発明者は、審査済み修理請求データを故障修理の処置別に故障修理１件あたりの平均修理額を算出した。その結果、処置にばらつきがあったが、部品交換で処置された修理は、ビデオデッキ全体の平均修理額とほぼ同額になった。
【０１０２】
同様にして、本発明者は、製品購入価格、製造メーカ、故障症状、故障原因等の項目についても、故障修理１件あたりの平均修理額を算出して、ビデオデッキ全体の平均修理額に近くなるような項目の値や範囲を特定することができた。
【０１０３】
本発明者は、製品タイプ、製造メーカ、故障処置等の各項目が、ビデオデッキ全体の平均修理額に近くなるようなコードの値や範囲を満たす審査済み修理請求データは、審査後に確定した修理額の標準偏差が少なく、ばらつきが少なくなることを発見した。このコードの値や範囲を満たす修理請求データを抽出する条件を、本発明者は修理審査ルールとして規定した。本発明に係る修理審査システムは、この修理審査ルールをプログラム化した、コンピュータ・システムで自動的に修理審査を実行するものである。
【０１０４】
図１６に、ビデオデッキを例にしたディシジョン・ツリーとシミュレーション結果を示す。
【０１０５】
ディシジョン・ツリーにおいて、先ず、保証契約の対象ビデオデッキの中から製品タイプを特定した（ステップＢ１）。ここでは、モノラル、ＷＶＨＳ、デジタル、８ミリを除外した。次に、製造メーカとして、例えば、Ａ社、Ｂ社、Ｆ社を特定した（ステップＢ２）。引き続いて、製品購入価格の範囲として、１３０，０００円未満の範囲を特定し（ステップＢ３）、故障原因として、濡れによる故障を除外し（ステップＢ４）、故障に対してとられた処置として、部品交換のみを特定し（ステップＢ５）、修理請求額の範囲として、８，０００円以上１５，０００円未満の範囲を特定した（ステップＢ６）。そして、修理請求金額を基準にセグメント化した（ステップＢ７）。
【０１０６】
シミュレーション結果は次の通りであった。ある期間に報告されたビデオデッキの修理請求データの総件数は３，５３５件であった。そして、上記ディシジョン・ツリーを適用して修理審査を行った結果、２，３４０件が、条件を全てパスしてその修理請求内容が妥当であることが確認された。図１６には、修理請求額帯の件数を示す２つの線グラフが表示されている。この線グラフにおいて、白塗四角は修理請求件数を表す。そして、黒塗菱形によって限定された範囲が修理確定された修理請求を表している。
【０１０７】
次に、図１７を参照して、サーバ装置１０において実行される修理審査プログラムＰ４について説明する。
【０１０８】
修理審査プログラムＰ４は、請求データ記録（月次）プログラムＰ２の実行要求に基づいて（図１３のステップＳ２１８）、オペレーティング・システム５４によって実行される。オペレーティング・システム５４は、ディスク装置４０に登録されているアプリケーション・プログラムから要求された修理審査プログラムＰ４を第２のシステム・バス５６を経由して、実記憶域５５にロードする。オペレーティング・システム５４は、図１７に図示するフローチャートに従って、修理審査プログラムＰ４の命令を実行する。
【０１０９】
オペレーティング・システム５４は、ディスク装置４０から審査対象製品テーブルＴ７を読み込んで、第２のシステム・バス５６を経由して、実記憶域５５に記録する。そして、オペレーティング・システム５４は、請求データ記録（月次）プログラムＰ２の処理過程で実記憶域５５に記録されているチェック済み修理請求データを、実記憶域５５に記録されている審査対象製品テーブルＴ７の製品種類と比較する。
【０１１０】
オペレーティング・システム５４は、チェック済み修理請求データの製品種類が審査対象製品テーブル（修理審査の対象となる製品種類を記録したテーブル）Ｔ７で指定されている製品種類かどうかを照合し、修理審査を行う製品かどうかを判定する（ステップＳ４０１）。チェック済み修理請求データの製品種類が対象外であれば（ステップＳ４０１のＮｏ）、オペレーティング・システム５４は、チェック済み修理請求データのエラーの有無を確認する（ステップＳ４０２）。チェック済み修理請求データにエラーがなければ（ステップＳ４０２のＮｏ）、オペレーティング・システム５４は、Exitモジュール・コードに「審査対象外でエラーなし」を示す‘１９’をセットし（ステップＳ４０３）、モジュールの出口に進む。
【０１１１】
チェック済み修理請求データにエラーが存在すれば（ステップＳ４０２のＹｅｓ）、オペレーティング・システム５４は、Exitモジュール・コードに「審査対象外でエラーあり」を示す‘１１’をセットする（ステップＳ４０４）。そして、オペレーティング・システム５４は、エラー・コードにより、セグメント・コードをセットし（ステップＳ４０５）、モジュールの出口に進む。
【０１１２】
一方、チェック済み修理請求データの製品種類が請求審査対象製品である場合（ステップＳ４０１のＹｅｓ）、オペレーティング・システム５４は、修理審査条件登録画面（図１５）から指定された条件（製品タイプの特定、故障原因の特定、製造メーカの特定、処置の特定等）を規定する修理審査条件テーブルＴ４を読み込み、第２のシステム・バス５６を経由して実記憶域５５に必要データを記録する（ステップＳ４０６）。ここから、オペレーティング・システム５４は、チェック済み修理請求データと対応する保証製品テーブルＴ５の保証製品データの各項目をステップＳ４０６で記録された修理審査条件と比較しながら、条件に合致するかどうかを判断していく。
【０１１３】
オペレーティング・システム５４は、最初にチェック済み修理請求データの製品タイプが、修理審査条件テーブルＴ４の登録された製品コードに存在するかどうかを判定する（ステップＳ４０７）。チェック済み修理請求データの製品タイプが修理審査条件テーブルＴ４に存在しない場合には（ステップＳ４０７のＮｏ）、オペレーティング・システム５４は、Exitモジュール・コードに「製品で審査対象から除外」を示す‘３１’をセットし（ステップＳ４０８）、ステップＳ４２４に進む。
【０１１４】
チェック済み修理請求データの製品タイプが修理審査条件テーブルＴ４に存在する場合（ステップＳ４０７のＹｅｓ）、オペレーティング・システム５４は、チェック済み修理請求データと対応する保証製品テーブルＴ５の保証製品データのメーカコードが、修理審査条件テーブルＴ４の登録されたメーカに存在するかどうかを判定する（ステップＳ４０９）。チェック済み修理請求データと対応する保証製品テーブルＴ５の保証製品データのメーカコードが修理審査条件テーブルＴ４に存在しない場合には（ステップＳ４０９のＮｏ）、オペレーティング・システム５４は、Exitモジュール・コードに「メーカで審査対象から除外」を示す‘３２’をセットし（ステップＳ４１０）、ステップＳ４２４に進む。
【０１１５】
チェック済み修理請求データと対応する保証製品テーブルＴ５の保証製品データのメーカコードが修理審査条件テーブルＴ４に存在する場合（ステップＳ４０９のＹｅｓ）、オペレーティング・システム５４は、チェック済み修理請求データと対応する保証製品テーブルＴ５の保証製品データの購入価格が、修理審査条件テーブルＴ４の登録された範囲内の価格であるかどうかを判定する（ステップＳ４１１）。チェック済み修理請求データと対応する保証製品テーブルＴ５の保証製品データの購入価格が修理審査条件テーブルＴ４の登録された範囲内に含まれない場合には（ステップＳ４１１のＮｏ）、オペレーティング・システム５４は、Exitモジュール・コードに「購入価格で審査対象から除外」を示す‘３３’をセットし（ステップＳ４１２）、ステップＳ４２４に進む。
【０１１６】
チェック済み修理請求データと対応する保証製品テーブルＴ５の保証製品データの購入価格が修理審査条件テーブルＴ４の登録された範囲内に含まれる場合には（ステップＳ４１１のＹｅｓ）、オペレーティング・システム５４は、チェック済み修理請求データの故障原因が、修理審査条件テーブルＴ４の登録された故障原因コードに存在するかどうかを判定する（ステップＳ４１３）。チェック済み修理請求データの故障原因が修理審査条件テーブルＴ４に存在しない場合には（ステップＳ４１３のＮｏ）、オペレーティング・システム５４は、Exitモジュール・コードに「故障原因で審査対象から除外」を示す‘３４’をセットし（ステップＳ４１４）、ステップＳ４２４に進む。
【０１１７】
チェック済み修理請求データの故障原因が修理審査条件テーブルＴ４に存在する場合には（ステップＳ４１３のＹｅｓ）、オペレーティング・システム５４は、チェック済み修理請求データの故障処置が、修理審査条件テーブルＴ４の登録された故障処置コードに存在するかどうかを判定する（ステップＳ４１５）。チェック済み修理請求データの故障処置が修理審査条件テーブルＴ４に存在しない場合には（ステップＳ４１５のＮｏ）、オペレーティング・システム５４は、Exitモジュール・コードに「故障処置で審査対象から除外」を示す‘３５’をセットし（ステップＳ４１６）、ステップＳ４２４に進む。
【０１１８】
チェック済み修理請求データの故障処置が修理審査条件テーブルＴ４に存在する場合には（ステップＳ４１５のＹｅｓ）、オペレーティング・システム５４は、チェック済み修理請求データの故障処置が製品交換で対応したかどうかを確認する（ステップＳ４１７）。製品交換の場合には（ステップＳ４１７のＹｅｓ）、オペレーティング・システム５４は、Exitモジュール・コードに「製品交換で審査対象から除外」を示す‘３６’をセットし（ステップＳ４１８）、ステップＳ４２４に進む。
【０１１９】
製品交換でない場合には（ステップＳ４１７のＮｏ）、オペレーティング・システム５４は、チェック済み修理請求データの請求金額が、修理審査条件テーブルＴ４の登録された範囲内がどうかを判定する（ステップＳ４１９）。修理請求額が範囲内に入らない場合には（ステップＳ４１９のＮｏ）、オペレーティング・システム５４は、Exitモジュール・コードに「修理請求額で審査対象から除外」を示す‘３７’をセットし（ステップＳ４２０）、ステップＳ４２４に進む。
【０１２０】
修理請求額が範囲内に含まれる場合には（ステップＳ４１９のＹｅｓ）、オペレーティング・システム５４は、修理審査条件を全てパスしたチェック済み修理請求データにエラーが存在するか否かをチェックする（ステップＳ４２１）。エラーが存在すれば（ステップＳ４２１のＹｅｓ）、オペレーティング・システム５４は、Exitモジュール・コードに「修理確定できたが、エラーが存在する」を示す‘９８’をセットし（ステップＳ４２２）、ステップＳ４２５に進む。
【０１２１】
チェック済み修理請求データにエラーもなく、全ての審査条件をパスした場合（ステップＳ４２１のＮｏ）、オペレーティング・システム５４は、Exitモジュール・コードに「修理確定」を示す‘９９’をセットし（ステップＳ４２３）、出口に進む。
【０１２２】
ステップＳ４２４では、オペレーティング・システム５４は、修理審査過程の途中で不適と判断され審査対象から除外されたチェック済み修理請求データのエラーの有無を確認する。エラーが存在すれば、オペレーティング・システム５４は、エラー・コードにより、セグメント・コードをセットし（ステップＳ４２５）、モジュールの出口に進む。
【０１２３】
一方、ステップＳ４２４でエラーが存在しなければ（ステップＳ４２４のＮｏ）、オペレーティング・システム５４は、チェック済み修理請求データが修理審査条件テーブルＴ４の修理請求額範囲内であれば、セグメント・コードに‘０１’をセットし、下限の額より小額であれば、セグメント・コードに‘０２’をセットし、そして上限の額より高額であれば、セグメント・コードに‘０３’をセットし（ステップＳ４２６）て、モジュールの出口に進む。
【０１２４】
このようにして、実記憶域５５のチェック済み修理請求データのセグメント・コードおよびExitモジュール・コードが編集される。
【０１２５】
次に、図１８を参照して、サーバ装置１０において実行される審査結果モニタ・プログラムＰ５について説明する。
【０１２６】
審査結果モニタ・プログラムＰ５は、端末装置２０からの修理審査結果モニタ要求に基づいて、オペレーティング・システム５４によって実行される。オペレーティング・システム５４は、ディスク装置４０に登録されているアプリケーション・プログラムから要求された審査結果モニタ・プログラムＰ５を第２のシステム・バス５６を経由して、実記憶域５５にロードする。オペレーティング・システム５４は、図１８に図示するフローチャートに従って、審査結果モニタ・プログラムＰ５の命令を実行する。
【０１２７】
オペレーティング・システム５４は、端末装置２０に審査結果モニタ用画面を表示する（ステップＳ５０１）。図１９に審査結果モニタ用画面の一例を示す。
【０１２８】
次に、オペレーティング・システム５４は、審査結果モニタ用画面から入力された会計月を、第２のシステム・バス５６を経由して実記憶域５５に記録する（ステップＳ５０２）。引き続いて、オペレーティング・システム５４は、ディスク装置４０から審査済み修理請求データＴ３を読み込み（ステップＳ５０３）、それを第２のシステム・バス５６を経由して実記憶域５５に記録する。
【０１２９】
次に、オペレーティング・システム５４は、指定された会計月の審査済み修理請求データを抽出する（ステップＳ５０４）。換言すれば、オペレーティング・システム５４は、修理請求データの勘定年月が指定された会計月と同じか否かを判断する。
【０１３０】
修理請求データの勘定年月が指定された会計月と同じ場合（ステップＳ５０４のＹｅｓ）、オペレーティング・システム５４は、実記憶域５５に確保された製品種類別の作業域に、修理請求データのExitモジュール・コード別に審査済み修理請求データＴ３の件数を集計する（ステップＳ５０５）。換言すれば、オペレーティング・システム５４は、審査済み修理請求データの製品種類、Exitモジュール・コードと一致する集計テーブルにそれぞれ１を加算する。
【０１３１】
次に、オペレーティング・システム５４は、実記憶域５５に確保された製品種類別の集計用の作業域に、修理請求データのセグメント・コード別に審査済み修理請求データの件数を集計する（ステップＳ５０６）。換言すれば、オペレーティング・システム５４は、審査済み修理請求データの製品種類、セグメント・コードと一致する集計テーブルにそれぞれ１を加算する。
【０１３２】
審査済み修理請求データが全て読み込まれたとき、オペレーティング・システム５４は、製品種類別のExitモジュール・コード別およびセグメント・コード別の集計結果を実記憶域５５から、第２のシステム・バス５６を経由して端末装置２０のモニタ用画面に表示する（ステップＳ５０７）。
【０１３３】
図１９から明らかなように、審査結果モニタ用画面からは、製品種類別に修理審査し妥当であると判定された件数、修理審査条件のどこの審査条件で不適と判断され、自動修理審査の対象から除外されたかを表すExitモジュール・コード別の件数及びセグメント・コード別の件数を確認することができる。
【０１３４】
尚、本発明は、上述した実施の形態に限定されず、本発明の要旨を逸脱しない範囲内で種々の変更が可能なのはいうまでもない。例えば、上述した実施の形態では、受信修理請求データをサーバのディスク装置に格納しているが、他の記憶手段に格納しても良いのは勿論である。また、上述した実施の形態では、チェック済み修理請求データを実記憶域に格納しているが、他の記憶手段に格納しても良いのは勿論である。
【０１３５】
本出願人は、２００２年６月に本発明に係る修理審査システムを導入した。導入後１０ヶ月間の月平均修理請求件数は、約２０，８００件であった。このうち、約６１％に相当する約１２，６００件が、本発明に係る修理審査システムによって自動修理審査された。残りの約３９％の修理請求データのみが、修理審査担当者によって手動修理審査されるように改善され、その結果として修理審査担当者の作業量が激減した。
【０１３６】
図２０に示す表およびグラフは、本修理審査システム導入前６ヶ月と導入後１０ヶ月の修理請求の処理件数と修理審査担当者の処理時間を示している。本修理審査システムを導入する前には、修理審査の審査に月平均１２０時間を要していたが、導入後は月平均６６時間に変化していることが分かる。
【０１３７】
結果として、修理請求の件数に比例して作業量が増加するという問題は解消された。
【０１３８】
コンピュータ（修理審査システム）での修理審査の対象から除外された修理請求データは、セグメント・コードとExitモジュール・コードによって分類される。その為、修理審査担当者は、端末装置から製品種類、Exitモジュール・コード、セグメント・コードを指定して修理請求データを特定することができる。その結果、従来においては受付順に行っていた手動修理審査を、製品種類別にセグメント化された類似する修理請求データを端末画面から連続して手動修理審査ができるため、正確性と効率が向上する。
【０１３９】
結果として、修理審査結果のばらつきが少なくなり、スピーディーに、より均一で正確な修理審査結果が得られるようになる。
【０１４０】
このようにして、従来の手動修理審査における問題を解決し、コストの削減および顧客サービスの向上を図ることができる。
【図面の簡単な説明】
【０１４１】
【図１】本発明の一実施の形態に係る修理審査システムのハードウェア構成を示すブロック図である。
【図２】図１に示される修理審査システムにおいて用いられる入力修理請求データの一構成例を示す図である。
【図３】図１に図示した修理審査システムのシステム概要を示すブロック図である。
【図４】図１に示される修理審査システムにおいて用いられる受信修理請求データの一構成例を示す図である。
【図５】図１に示される修理審査システムにおいて用いられる審査済み修理請求データの一構成例を示す図である。
【図６】図１に示される修理審査システムにおいて用いられる修理審査条件テーブルの一構成例を示す図である。
【図７】図６に示される修理審査条件テーブルの一具体例を示す図である。
【図８】図１に示される修理審査システムにおいて用いられる保証製品テーブルの一構成例を示す図である。
【図９】図１に示される修理審査システムにおいて用いられる各種コード・テーブルの一構成例を示す図である。
【図１０】図９に示される各種コード・テーブルのコードの一具体例を示す図である。
【図１１】図１に示される修理審査システムにおいて用いられる審査対象製品テーブルの一構成例を示す図である。
【図１２】図１に示す修理審査システムを実現するためのアプリケーション・プログラムの一つである請求データ記録（日次）プログラムを示すフローチャートである。
【図１３】図１に示す修理審査システムを実現するためのアプリケーション・プログラムの一つである請求データ記録（月次）プログラムを示すフローチャートである。
【図１４】図１に示す修理審査システムを実現するためのアプリケーション・プログラムの一つである修理審査条件登録プログラムを示すフローチャートである。
【図１５】図１４に示す修理審査条件登録プログラムにおける、製品種類ごとの修理請求データの修理審査条件を登録する端末画面の一例を示す図である。
【図１６】ビデオデッキを例にしたディシジョン・ツリーとそのシミュレーション結果を示す図である。
【図１７】図１に示す修理審査システムを実現するためのアプリケーション・プログラムの一つである修理審査プログラムを示すフローチャートである。
【図１８】図１に示す修理審査システムを実現するためのアプリケーション・プログラムの一つである審査結果モニタ・プログラムを示すフローチャートである。
【図１９】図１８に示す審査結果モニタ・プログラムにおける、審査結果モニタ用画面の一例を示す図である。
【図２０】図１に示す修理審査システムの導入前後の修理請求の処理件数と修理審査担当者の処理時間を示す表およびグラフである。
【符号の説明】
【０１４２】
１０    サーバ装置
１１，１２    通信制御装置
２０    端末装置
２１    通信制御装置
３０    ＬＡＮ
４０    ディスク装置
５１    ＣＰＵ
５２    システム・バス
５３    データベース・マネージメント・システム
５４    オペレーティング・システム（ＯＳ）
５５    実記憶域（メモリ）
５６    システム・バス
Ｔ１    入力修理請求データ
Ｔ２    受信修理請求データ
Ｔ３    審査済み修理請求データ
Ｔ４    修理審査条件テーブル
Ｔ５    保証製品テーブル
Ｔ６    各種コード・テーブル
Ｔ７    審査対象製品テーブル
Ｐ１    請求データ記録（日次）プログラム
Ｐ２    請求データ記録（月次）プログラム
Ｐ３    修理審査条件登録プログラム
Ｐ４    修理審査プログラム
Ｐ５    審査結果モニタ・プログラム
【図１】
2006190340.tif 000003
【図２】
2006190340.tif 000004
【図３】
2006190340.tif 000005
【図４】
2006190340.tif 000006
【図５】
2006190340.tif 000007
【図６】
2006190340.tif 000008
【図７】
2006190340.tif 000009
【図８】
2006190340.tif 000010
【図９】
2006190340.tif 000011
【図１０】
2006190340.tif 000012
【図１１】
2006190340.tif 000013
【図１２】
2006190340.tif 000014
【図１３】
2006190340.tif 000015
【図１４】
2006190340.tif 000016
【図１５】
2006190340.tif 000017
【図１６】
2006190340.tif 000018
【図１７】
2006190340.tif 000019
【図１８】
2006190340.tif 000020
【図１９】
2006190340.tif 000021
【図２０】
2006190340.tif 000022