JP2005227883A

JP2005227883A - 整備情報提供システム

Info

Publication number: JP2005227883A
Application number: JP2004033778A
Authority: JP
Inventors: Minoru Morikawa; 稔森川
Original assignee: Mazda Motor Corp
Current assignee: Mazda Motor Corp
Priority date: 2004-02-10
Filing date: 2004-02-10
Publication date: 2005-08-25

Abstract

【課題】ネットワークを介して、商品の故障に関する情報を共有するとともに、故障情報の信頼性を向上させる。
【解決手段】例えば、サービス工場などに設置されたクライアント端末１００ａ−１００ｄは、それぞれ、商品の故障情報を整備情報と関連付けて整備情報提供サーバー１５０に投稿する。整備情報提供サーバー１５０は、投稿された故障情報を整備情報とともに各クライアント端末１００ａ−１００ｄに提供する。これにより、複数のクライアント端末１００ａ−１００ｄは、故障情報を相互に共有できるようになる。故障情報提供サーバー１５０は、故障情報管理データベース１７１に登録されている故障情報については、所定の公開条件を満たしたものから公開する。
【選択図】図１

Description

本発明は、商品の整備情報を提供するシステムに係り、とりわけ、当該整備情報と関連して当該商品の故障情報を提供するシステムに関する。

従来、自動車などの整備マニュアルは、紙を媒体として提供されてきた。しかしながら、紙の整備マニュアルは、必要なページにたどり着くまでに時間がかかるなど、不便であった。

そこで、整備マニュアルを電子化し、ネットワークを介して一般消費者に配信する技術が提案されている（特許文献１）。
特開平２００２−１１７０３８号公報。

ところで、商品についての整備が必要となるタイミングは、定期点検時や商品の故障時であるが、とりわけ、故障の場合は、サービスエンジニアが整備マニュアルを参照しつつ、どの部品がどのような原因で故障しているかを検討しなければならない。

整備を担当するサービス工場において、過去に同様な故障事例について対処していれば、そのときの経験に基づいて今回の故障事例についてもスムーズに対処することができるだろう。しかしながら、初めて経験するような故障事例であれば、サービスエンジニアは、自己の能力だけを頼りに事故原因を調査したり、対処方法を探求したりしなければならず、負担が大きい。この場合は、故障の解決までに必要以上に時間を要することになろう。

一方で、全国または全世界を規模として販売されるグローバルな商品であれば、どこかのサービス工場で、問題となっている故障についての解消策が確立している可能性もある。もし、その解消策を異なる複数のサービス工場間で共有できれば、故障整備の効率が大幅に改善されよう。

しかしながら、従来は、商品の故障についての情報は、重大な故障を除き、故障した商品が搬入されたサービス工場で累積されるだけであった。そのため、異なる複数のサービス工場間で故障情報を共有することができなかった。

このように、従来は、整備マニュアルを電子化しただけでは解決できない課題が存在した。

ところで、本発明では、整備情報とともに故障情報を提供するようにするが、整備情報とともに提供される故障情報を、登録後すぐに公開したのでは、未成熟な故障情報が氾濫することになりかねない。これでは、故障情報の信頼性が低くなってしまう恐れがある。

そこで、本発明は、これらの課題および他の課題の少なくとも一つを解決することを目的とする。他の課題については以下で説明する。

上記課題のうち少なくとも一つを解決すべく、本発明は、例えば、ネットワークを介して接続された複数のクライアント端末に所定の商品の整備情報を提供する整備情報提供システムであって、それぞれ種類の異なる複数の商品について、該商品を構成する複数の機能部位ごとの整備情報を記憶する整備情報記憶手段と、何れかの前記機能部位について、何れかの前記クライアント端末から入力された故障情報を、該機能部位と対応付けて記憶する故障情報記憶手段と、何れかの前記クライアント端末から、何れかの前記機能部位に関する前記整備情報の送信要求を受信する受信手段と、受信された前記送信要求に応じて、対応する前記機能部位の整備情報を前記整備情報記憶手段から読み出すとともに、該機能部位に関する故障情報を前記故障情報記憶手段から読み出し、該故障情報が所定の公開条件を満たしている場合には、該整備情報とともに該故障情報の内容または有無を前記クライアント端末において表示させるための画面情報を作成し、該故障情報が所定の公開条件を満たしていない場合には、該整備情報を前記クライアント端末において表示させるための画面情報を、前記送信要求を送信してきた前記クライアント端末に送信する送信手段とを含むことを特徴とする。

本発明によれば、登録された故障情報のうち公開条件を満たしているものから公開することで、例えば、情報として成熟したものを公開できるようになる。また、未成熟な故障情報であっても登録を可能としているので、故障情報の登録がおろそかになる問題を低減できよう。

例えば、公開条件を、所定期間を経過していることとすることで、一定期間を経過した後は、登録された故障情報を公開するようにできる。一定期間を過ぎれば、自動的に公開されるので、公開し忘れることを回避できよう。

また、公開条件を、故障情報を入力したクライアント端末から公開許可を得ることとすれば、故障情報の登録者の判断に基づいて公開できるようになる。なお、公開許可を取得するには、例えば、故障情報を入力したクライアント端末に対し公開許可要求を送信して、公開許可を受信するようにすればよい。

公開条件を、故障情報の入力日から所定期間が経過する前に、同一の商品について同一の故障情報が再度登録されていないことと設定してもよい。たとえば、一度故障対策をしたものの、その後故障観察において同一の故障が再発し、同一の故障情報が再度登録される場合もあろう。そのような場合には、前回登録された故障情報のうち故障対策に関する部分は信頼性が低いことになる。よって、公開条件をこのように設定することで、信頼性の低い故障情報の公開を低減することができよう。

なお、故障種別ごとに、所定期間などの公開条件を設定してもよい。故障の種別によっては、すぐに故障情報を公開してもよい軽微な故障もあれば、十分に時間をかけて調査をしてから故障情報を公開すべき重大な故障もあるからである。なお、所定期間は、クライアント端末を介してユーザが設定してもよい。

また、公開条件を変更して、例えば、無条件で故障情報を公開してもよい。すなわち、広く伝播させたい重要な故障情報と判明した場合には、公開条件を変更することで、所定期間の経過前であっても公開できるようになる。

以下、図面を用いて本発明の実施形態を説明する。

図１は、実施形態に係る整備情報提供システムの一例を示す図である。１００ａないし１００ｄは、パーソナルコンピュータなどのクライアント端末である。各クライアント端末は、ディーラー、サービス工場、メーカー、サプライヤーなどに配置されている。また、クライアント端末１００ａ〜１００ｄは、インターネットなどのネットワークを介して、整備情報提供サーバー１５０に接続される。なお、クライアント端末は、以下で説明する本発明を実現可能なコンピュータプログラムを実行できるものであれば、一般的なデスクトップコンピュータやモバイルコンピュータなどあってもよい。もちろん、以下で説明する処理を実行するための専用端末であってもよい。要するに、本実施形態にかかる各機能を実現できるものであれば、どのようなコンピュータであってもよい。

また、整備情報提供サーバー１５０は、整備情報を記憶する整備情報管理データベース１７０と、何れかのクライアント端末から登録された故障情報を記憶する故障情報管理データベース１７１と、クライアント端末を使用するユーザの認証情報などを管理するためのユーザ管理データベース１７２と、部品の発注データを管理するための発注管理データベース１７３などを備えている。なお、これらのデータベースは、整備情報提供サーバー１５０とは、物理的に異なるコンピュータ上のデータベースサーバーによって実現されてもよい。

図２は、実施形態に係る各装置のハードウエア構成例を示す図である。クライアント端末１００ａ〜１００ｄは、中央演算処理装置（ＣＰＵ）２０１を備えている。ＣＰＵ２０１は、ＲＯＭ２０２やハードディスクドライブ（ＨＤＤ）２０４に格納されているコンピュータプログラムに基づいて様々な処理及び制御を実行する。これらの制御プログラムとしては、後述するフローチャートにそって適宜の処理を実行するための、ＷＥＢクライアント（いわゆるブラウザ）プログラム、電子メールクライアントプログラムなどがある。一時的なデータは、作業エリアとして機能するＲＡＭ２０３に格納される。表示装置２０５は、液晶ディスプレイやＣＲＴなどである。操作部２０６は、キーボードおよびポインティングデバイスなどの入出力装置である。ネットワークインタフェース２０７は、インターネットなどのネットワークと接続するための通信回路である。自動車インタフェース２０８は、自動車に搭載されるコンピュータと通信するための通信回路である。

一方、サーバー１５０は、ＲＯＭ２２２やハードディスクドライブ２２４に格納されているコンピュータプログラムに基づいて様々な処理及び制御を実行する中央演算処理装置（ＣＰＵ）２２１を備えている。制御プログラムとしては、例えば、ＷＥＢサーバプログラム、ＣＧＩプログラム、電子メールサーバプログラム、ＨＴＭＬファイルやＪａｖａ（登録商標）スクリプトなどの種々のスクリプトがある。サーバー１５０には、表示装置２２５も備えられており、処理内容、処理結果などを表示する。また、タッチパネルデバイスやテンキー及びポインティングデバイスなどの操作部２２６装置も備えられている。またＣＰＵ２２１は、通信インタフェース回路２２７を介して、クライアント端末１００などの他の装置とデータの送受信を行なう。

図３は、実施形態に係る故障情報の登録処理を示したフローチャートである。
ステップＳ３００において、クライアント端末１００ａ〜１００ｄの何れかから、故障情報を入力する。例えば、クライアント端末のＣＰＵ２０１は、ＷＥＢブラウザクライアントプログラムを起動し、操作部２０６からの入力されたサーバー１５０のアドレスにしたがって、サーバー１５０にアクセスする。サーバー１５０のＣＰＵ２２１は、クライアント端末から要求されたページを送信する。ここでは、故障情報の入力ページが要求されたものとする。ＣＰＵ２０１は、当該入力ページを受信し、表示装置２０５に表示する。

図４は、実施形態に係る故障情報入力ページの一例を示す図である。この例では、種々の車名が予め登録されたプルダウンメニューを使用して車名が選択されると、対応する機種コードが機種コードの欄に入力される。なお、プルダウメニューは、Ｊａｖａ（登録商標）ＳｃｒｉｐｔやＣＧＩによって実現することができる。
製造番号は、操作部２０６からテキストボックス内に手で入力される。ＳＣＴは、最上位の機能部位（例：エンジン、サスペンションなど）を表す。ＳＣは、中間の機能部位（例：始動装置、潤滑装置、燃料装置など）を表す。部品名は、最下位の機能部位（例：スタータなど）を表している。いずれも既知の情報なので、プルダウメニューにより選択できるようにしている。
故障形態は、例えば、「内部不良」、「接触不良」、「断線」など、故障の内容を示す情報で、プルダウンメニューにより選択できる。対処方法は、故障に対してどのような処置を施したかを示す情報で、例えば「部品交換」、「修理」などである。
走行距離は、故障した自動車の走行距離を示す情報である。不具合現象は、「エンジン始動不良」など、故障により発生している現象を示す情報である。発生状況は、故障が発生したときや不具合が生じるときを特定するための情報である。提供可否のラジオボックスは、登録した故障情報をいつ公開するかを指定するためのものである。この例では、即日提供、所定期間後に提供、登録者の許可が必要（問い合せ要）などを選択できる。なお、これらは単なる一例に過ぎず、適宜情報の内容や入力手法を変更してもよい。

ステップＳ３０２において、ＣＰＵ２０１は、入力された故障情報を、ネットワークインタフェース２０７を介して整備情報提供サーバー１５０に送信する。例えば、図４の入力ページにおいて、必要な情報がすべて入力され、送信ボタンが押し下げられると、ＣＰＵ２０１は、ネットワークインタフェース２０７を介して、入力された情報をサーバー１５０に送信する。

ステップＳ３０４において、サーバー１５０のＣＰＵ２２１は、ネットワークインタフェース２２７を介して、故障情報を受信する。ステップＳ３０６において、ＣＰＵ２２１は、故障情報を故障情報管理データベース１７１に登録する。

図５は、実施形態に係る故障情報管理データベースの一例を示す図である。図４で説明した情報に加え、入力日、ユーザＩＤ、連絡先電子メールアドレス、所属会社などの情報が追加されている。ユーザＩＤは、例えば、クライアント端末１００ａ〜１００ｄがサーバー１５０に接続する際の認証処理において取得されたものを利用してもよい。なお、認証に必要なユーザＩＤやパスワード等の情報は、ユーザ管理データベース１７２に記憶されている。入力日は、例えば、故障情報を受信したときの日時データを、ＣＰＵ２２１が内部タイマーから取得して設定することができる。

図６は、実施形態に係る整備情報及び故障情報の提供処理に関するフローチャートである。ステップＳ６００において、何れかのクライアント端末１００ａ〜１００ｄのＣＰＵ２０１は、整備情報の送信要求を操作部２０６から指示されると、ネットワークインタフェース２０７を介して、当該整備情報の送信要求をサーバー１５０に送信する。

例えば、サーバー１５０のメインページ（例えば、図１９のメニュー画面など）に記載されている整備情報表示ページへのハイパーリンクがクリックされると、当該整備情報表示ページの要求がクライアント端末から送信される。ここでは、整備情報を表示する前に、検索条件の入力ページを表示する物とする。サーバー１５０は、整備情報を検索するための検索条件を入力するためのページを送信する。クライアント端末は、検索条件の入力ページを受信して表示装置２０５に表示する。さらに、クライアント端末は、操作部２０６から入力された検索条件をサーバー１５０に送信する。

図７は、整備情報の検索条件を入力する際に利用される入力ページの一例を示す図である。図７に示した検索条件は、図５で説明したような各種情報の少なくとも一つを設定するようになっている。また、初めから故障形態など故障情報に関する検索条件を入力してもよい。

ステップＳ６０２において、サーバー１５０は、ネットワークインタフェース２２７を介して、整備情報の送信要求（例えば、検索条件を含む検索要求など）を受信する。ステップＳ６０４において、サーバー１５０のＣＰＵ２２１は、受信した検索条件にしたがって、整備情報を検索する。

図８は、整備情報管理データベースの一例を示す図である。車名、機種コード、ＳＣＴ、ＳＣ、部品名及び部品コードと対応付けて、整備書ファイル番号（ファイル名）と電気配線図ファイル番号（ファイル名）などが記憶されている。整備書ファイルや、電気配線図ファイルは、ＨＤＤ２２４に予め記憶されているものとする。

ステップＳ６０６において、サーバー１５０のＣＰＵ２２１は、検索により抽出された整備情報に対応する故障情報を故障情報管理データベース１７１から検索抽出する。例えば、整備情報に関する機種コード、ＳＣＴ、ＳＣ、部品名、部品番号などと一致する情報を含んだ故障情報を抽出する。

ステップＳ６０８において、ＣＰＵ２２１は、抽出した整備情報と故障情報とを重畳させて画面の表示情報を作成する。画面の表示情報は、以下で詳しく説明するように、ＨＴＭＬ、画像データ、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔ、マクロメディア社のフラッシュ（登録商標）、ＸＭＬ、ＳＧＭＬ、ＳＶＧ（スケーラブル・ベクター・グラフィックス）やＰＤＦなど種々の形式で作成することができる。なお、これらは例示に過ぎず、本発明の機能を実現できるものであれば、どのようなファイル形式を採用してもよい。ステップＳ６１０において、ＣＰＵ２２１は、送信要求を送信してきたクライアント端末に対して、作成した画面の表示情報を送信する。

ステップＳ６１２において、クライアント端末のＣＰＵ２０１は、画面の表示情報を受信する。ステップＳ６１４において、ＣＰＵ２０１は、受信した画面の表示情報を表示装置２０５に表示させる。

図９は、実施形態に係る整備情報と故障情報とを表示するための画面の一例を示す図である。この画面の表示情報によれば、検索抽出された整備情報（整備書図面）と、故障形態などの故障情報が一つのページ内に重畳して表示されている。なお、本明細書では特に断わらない限り、重畳表示とは、同一画面内において複数の情報を同時に表示することをいうものとする。そのため、複数の情報が重なりあって表示されるだけでなく、何らかの関連性をもって複数の情報が表示されることも意味する。すなわち、構成部品（または機能部位）の整備情報と故障情報との対応関係がわかり易く表示されるものであれば、いずれも重畳表示されているものとする。

図１０は、画面の表示情報の作成サブルーチンについての例示的なフローチャートである。ステップＳ１０００において、サーバー１５０のＣＰＵ２２１は、画面の表示情報のテンプレートファイルをＨＤＤ２２４から読み出す。テンプレートファイルは、例えば、整備情報と故障情報を提供するための基本的なＨＴＭＬファイルである。もちろん上述したように他の形式のファイルでもよい。

ステップＳ１００２において、ＣＰＵ２２１は、整備書ファイルのファイル名およびファイルパスに関する情報をテンプレートファイルに書き込む。ステップＳ１００４において、ＣＰＵ２２１は、検索により抽出された整備情報に対応する故障情報が検索により抽出されているかどうかを判定する。抽出されなかった場合は、画面の表示情報作成サブルーチンを終了する。

一方、抽出済みであれば、ステップＳ１００６に進み、ＣＰＵ２２１は、抽出された故障情報へのファイルパスまたはリンク情報をテンプレートファイルに書き込む。ここでは、故障情報を記述したファイルまたはＷＥＢページがあることを前提として説明したが、図９のように、故障情報の内容（テキスト文字列）を直接テンプレートファイルに書き込んでもよい。なお、テンプレートファイルについては記載が省略されているが、もちろんテンプレートファイルを用いてもよいことはいうまでもない。

図１１は、画面の表示情報の作成サブルーチンについての他の例示的なフローチャートである。ステップＳ１１００において、サーバー１５０のＣＰＵ２２１は、検索により抽出されたファイル名にしたがって、整備情報の画像ファイル（整備解説図または配線図など）をＲＡＭ２０３に読み出す。

ステップＳ１１０２において、故障情報が抽出されたかどうかを判定する。抽出失敗であれば、元の処理に戻る。一方、抽出済みであれば、ＣＰＵ２２１は、故障形態、対処方法などの故障情報もＲＡＭ２０３に読み出す。さらに、例えば、マクロメディア社のフラッシュを用い、第１レイヤーに整備情報を配置し、第２レイヤーに故障情報を配置させることで、両者を重畳させる。もちろん、両者を重畳させることができるのであれば、他の画像形式や画像処理ソフトを使用してもよい。

図１２は、画面の表示情報作成サブルーチンのさらに他の例を示すフローチャートである。この例では、機能部位を構成する各構成部品について故障情報が登録されているかどうか、すなわち故障情報の登録の有無を機能部位のページにおいて表示する。そして、下位の構成部品のページにおいて具体的な故障情報を表示するようにしたものである。つまり、階層的に整備情報や故障情報を表示するようにしている。

ステップＳ１２００において、サーバー１５０のＣＰＵ２２１は、機能部位用表示画面の表示情報のテンプレートファイルをＨＤＤ２２４から読み出す。ステップＳ１２０２において、ＣＰＵ２２１は、機能部位用の整備書ファイルのファイル名およびファイルパスに関する情報をテンプレートファイルに書き込む。これにより、機能部位に関する整備情報を表示するためのページが作成される。

ステップＳ１２０４において、ＣＰＵ２２１は、検索により抽出された整備情報に対応する故障情報が抽出されているかどうかを判定する。抽出されていなかった場合は、ステップＳ１２０８に進み、構成部品ページへのリンク情報を書き込む。このリンク情報には、故障情報「有り」を表す画像は付されない。しかしながら、故障情報「無し」を意味する画像を付してもよいことはいうまでもない。

一方、抽出済みであれば、ステップＳ１２０６に進み、ＣＰＵ２２１は、「故障情報の登録あり」を表すアイコンと、アイコンをクリックしたときに呼び出されるリンク先の情報（構成部品ページ、ＣＧＩなど）をテンプレートファイルに書き込む。

ステップＳ１２１０において、サーバー１５０のＣＰＵ２２１は、上記機能部位に含まれる各構成部品用のテンプレートファイルをＨＤＤ２２４から読み出す。ステップＳ１２１２において、ＣＰＵ２２１は、各構成部品の整備書ファイルのファイル名およびファイルパスに関する情報をテンプレートファイルに書き込む。

ステップＳ１２１４において、ＣＰＵ２２１は、検索により抽出された整備情報に対応する故障情報が検索により抽出されているかどうかを判定する。抽出されなかった場合は、画面の表示情報作成サブルーチンを終了する。一方、抽出済みであればステップＳ１２１６に進み、ＣＰＵ２２１は、抽出された故障情報へのファイルパスまたはリンク情報をテンプレートファイルに書き込む。

このようにして、上位のページにおいて故障情報の有無を表示し、下位のページにおいて故障情報を表示するようにしたので、ユーザは、故障情報の有無の確認が容易となり、故障情報の登録されている構成部品のページへと段階的にアクセスしやすくなろう。なお、故障情報が登録されていない場合は、「無し」であることを表示しても表示しなくてもよい。

図１３は、整備情報と故障情報の段階的表示の一例を示す図である。とりわけ、図１３では、機能部位に関連するページを示している。故障情報が登録されている構成部品を有する機能部位については、星型の画像を機能部位と関連付けて表示することで、どの機能部位に関連して故障情報が登録されているかを視覚的にわかりやすくしている。クライアント端末は、図１３の機能部位の表示ページにおいて、構成部品ページへのリンク（図中の「始動装置」の部分）がクリックされると、図９のような構成部品のページを表示させることができる。

図１４は、新規故障通知のサブルーチンを示すフローチャートである。故障情報が登録されたときにこのサブルーチンを実行することで、例えば、注意を払う必要があるような新しい故障が発生したときは、メーカーや部品のサプライヤー等に通知がなされる。これにより、新規故障についての対処方法の確立が従来よりも早くなろう。

ステップＳ１４００において、サーバー１５０のＣＰＵ２２１は、任意の構成部品についてクライアント端末から登録された故障情報が、その構成部品について過去に登録された故障情報と同一の内容か否かを判定する。新規故障でなければ、元の処理に戻る。一方、新規故障であれば、ステップＳ１４０２へと進み、ＣＰＵ２２１は、当該構成部品についての通知先を検索抽出する。通知先の情報は、例えば、整備情報管理データベース１７０において、部品番号にごとに記憶しておいてもよい。通知先は、電子メールアドレスやファクシミリ番号などである。

ステップＳ１４０４において、ＣＰＵ２２１は、新規故障メールを作成する。新規故障メールには、例えば、新規の故障と判定された故障情報の内容が記述されるか、当該故障情報へのハイパーリンクが記述される。また、通知先の電子メールアドレスも宛先として記述される。

ステップＳ１４０６において、ＣＰＵ２２１は、作成した電子メールを不図示のＳＭＴＰサーバーを介して送信する。

以上のようにして、新規故障が発生した場合には、メーカーやサプライヤーに通知を行なうことが可能となる。これにより、故障の対処方法や、改良部品の設計、新規部品の設計に役立つことになろう。

図１５は、頻発故障通知に関する例示的なフローチャートである。頻発故障通知とは、例えば、同内容の故障が、あるしきい値を超えて発生した場合に、メーカーやサプライヤー等に注意を喚起すべく送信される通知などである。これにより、多数発生している重要度の高い故障については、即座に対処方法が検討されるようになろう。なお、このサブルーチンは、例えば、故障情報の登録時だけでなく任意のタイミングで実行することができる。

ステップＳ１５００において、サーバー１５０のＣＰＵ２２１は、登録された故障情報と同内容の故障情報が、既に故障情報管理データベース１７１に登録済みか否かを検索して判定する。同内容の故障情報が見つからなければ、例えば、上述の新規故障サブルーチンを実行してもよい。同内容の故障情報が検索により見つかれば、ステップＳ１５０２へと進み、当該故障情報の種別ごとに管理されるカウンタをインクリメントする。ステップＳ１５０４において、ＣＰＵ２２１は、カウンタの値が、所定のしきい値を超えているかどうかを判定する。なお、このしきい値は故障の種別ごとに異ならしめてもよく、この場合は、ＨＤＤ２２４に故障種別ごとのカウンタ値としきい値とが対応付けて記憶されることになろう。しきい値以下であれば、当該サブリーチンを抜けてもとの処理に戻る。

しきい値を超えていればステップＳ１５０６に進み、ＣＰＵ２２１は、頻発故障メールの宛先を抽出する。この宛先は、故障の種別と対応付けて、ＨＤＤ２２４などに記憶管理されている。このようにすれば、故障の種別ごとに頻発故障通知の宛先を変えることができる。ステップＳ１５０８において、ＣＰＵ２２１は、故障情報の内容を含む頻発故障メールを作成する。ステップＳ１５１０において、ＣＰＵ２２１は、作成した頻発故障メールを、ＳＭＴＰサーバーを介して宛先に送信する。

以上説明したように、所定の閾値を超えて故障が発生している場合に、頻発故障通知を送信することで、警告を行なうことができるため、早期に根本的な対策を確立できるようになろう。

なお、頻発故障通知は、一度通知されれば概ね十分と考えられるため、一度通知された後は、頻発故障通知を送信しないように制御してもよい。例えば、しきい値を大きな値に設定すれば実質的に通知を禁止できよう。あるいは、通知可否フラグを故障種別ごとに管理し、当該フラグを「否」に変更することで、ある種別の故障が頻発しても当該フラグが否となっている限り、ＣＰＵ２２１は、頻発故障通知を送信しないように制御できる。

また、頻発故障通知の閾値は故障種別ごとに設定できるが、もちろん、通知の可否も、故障種別ごとに設定することができることはいうまでもない。これらの設定情報は、上述したようにＨＤＤ２２４に記憶しておくことができる。

図１６は、整備情報と故障情報との表示画面についてのカスタマイズ処理に関するサブルーチンのフローチャートである。すなわち、見やすいと感じる表示形態はユーザごとに異なる場合があるため、故障情報等の表示画面についてのカスタマイズ機能を提供する。

ステップＳ１６００において、クライアント端末のＣＰＵ２０１は、設定画面の要求をサーバー１５０に送信する。ステップＳ１６０２において、サーバー１５０のＣＰＵ２２１は、設定画面要求を受信する。

ステップＳ１６０４において、ＣＰＵ２２１は、設定画面を表示するための情報をクライアント端末に送信する。ステップＳ１６０６において、クライアント端末のＣＰＵ２０１は、設定画面を表示するための情報を受信する。

ステップＳ１６０８において、ＣＰＵ２０１は、設定画面を表示装置２０５に表示させる。ステップＳ１６１０において、ＣＰＵ２０１は、操作部２０６からの指示に応じて、何れかの表示形態を選択する。

図１７は、表示形態の設定画面の一例を示す図である。この例では、ラジオボックスを用いて、複数の表示形態のうち何れか一つを排他的に選択できるようになっている。

ステップＳ１６１２において、ＣＰＵ２０１は、設定変更ボタンの押し下げを検出すると、選択された表示形態を識別するための識別コードを含む設定変更要求を送信する。

ステップＳ１６１４において、サーバー１５０のＣＰＵ２２１は、受信した設定変更要求に含まれる表示形態識別コードに基づいて、当該ユーザについてテンプレートファイルを変更する。例えば、ユーザごとの設定情報をユーザ管理データベース１７２において記憶している場合は、当該設定情報を設定変更要求にしたがって変更する。

以上のようにして、ユーザは、自己の好みに応じて整備情報と故障情報の表示形態を変更できるようになる。

図１８は、故障情報登録処理に関する他の例を示したフローチャートである。この例では、故障情報の登録対象となる構成部品または機能部位についての整備情報を参照しながら、故障情報を登録するものである。登録対象部品等を視覚的に確認できるため、ユーザに安心感を与えることができよう。

図１９は、整備情報および故障情報の提供に関するメニュー画面の一例を示す図である。このメニュー画面は、ユーザＩＤとパスワードを入力した後に表示される画面である。この例では、整備情報の表示、故障情報の表示、部品の発注、設定変更などを選択できるようになっている。

ステップＳ１８００において、クライアント端末のＣＰＵ２０１は、整備情報の送信要求を行なう。例えば、図１９に示した例示的なメニュー画面において、「整備情報の表示」が選択され、実行ボタンが操作されると、整備情報の送信要求が送信される。

ステップＳ１８０２において、サーバー１５０のＣＰＵ２２１は、図７に示したような整備条件に関する検索条件入力画面の表示情報を送信する。クライアント端末のＣＰＵ２０１は、入力画面の表示情報を受信すると、表示装置２０５に表示させる。操作部２０６から検索条件が入力されると、ＣＰＵ２０１は、検索条件をサーバー１５０に送信する。ステップＳ１８０４において、サーバー１５０のＣＰＵ２２１は、検索条件にしたがって、整備情報を検索する。ステップＳ１８０６において、ＣＰＵ２２１は、整備情報を表示するための画面の表示情報を作成する。上述したように、ＨＴＭＬファイルなどを作成する。ステップＳ１８０８において、ＣＰＵ２２１は、画面の表示情報をクライアント端末に送信する。

ステップＳ１８１０において、クライアント端末のＣＰＵ２０１は、画面の表示情報を受信する。ステップＳ１８１２において、ＣＰＵ２０１は、受信した画面の表示情報を表示装置２０５に表示する。整備情報の表示画面の一例は、図９や図１３に表示したとおりである。ステップＳ１８１４において、整備情報の一部である構成部品の画像部分がポインティングデバイスによって選択されると、ＣＰＵ２０１は、故障情報を登録するか否かのメッセージを表示する。

図２０は、故障情報を登録するか否かを選択するための画面の一例を示す図である。この画面は、例えば、構成部品を選択し、ダブルクリックまたは右クリックすると表示される。ここで、故障情報を登録することを意味する「ハイ」ボタンがクリックされると、図３に関連して説明した故障情報登録処理が実行される。

以上説明したように、本実施形態によれば、整備情報を表示して、故障情報の登録対象となる構成部品を視覚的に確認しながら選択できるため、故障情報を登録しやすくなる利点がある。

図２１は、故障情報の検索サブルーチンに関する例示的なフローチャートである。ある整備情報について多数の故障情報が登録されると、表示画面ないの情報が煩雑となり、使い勝手が低下するおそれがある。そこで、すべての故障情報するのではなく、一部の故障情報を提供することで、ユーザの使い勝手を向上させる。

ステップＳ２１００において、ＣＰＵ２２１は、故障情報の選別について、クライアント端末から指示されたか否かを判定する。例えば、図７に示した整備情報の検索条件の入力画面において、「故障情報を選別する」のチェックボックスがチェックされていれば、選別指示ありと判定する。

ステップＳ２１０２において、ＣＰＵ２２１は、選別ルールを設定する。選別ルールは、予めユーザごとに設定登録されているものをユーザ管理データベース１７２から読み出して設定してもよいし、動的にクライアント端末に問い合せて設定してもよい。

図２２は、選別ルールの問い合せ画面の一例を示した図である。この例では、商品の製造番号、製造日、グレード、付属品の有無、使用状況、使用環境、同一内容の故障の発生数などが選別ルールとして示されている。

製造番号が指定されると、ユーザにより指定された商品の製造番号と所定の関連性を有する製造番号の商品に係る故障情報が選別される。所定の関連性とは、例えば、指定された製造番号の前後１０００台の如くである。なお、クライアント端末から製造番号の範囲を指定してもよい。

製造日が指定されると、整備情報送信要求に係る商品の製造日と所定の関連性を有する製造日の商品に係る故障情報のみを選別することになる。所定の関連性とは、例えば、指定された製造日の前後９０日の如くである。なお、クライアント端末から製造日の範囲を指定してもよい。

グレードが指定されると、整備情報送信要求に係る商品のグレードが一致した商品の故障情報のみを選別することになる。例えば、ある商品についてグレードが異なれば、装備品やエンジンの仕様等が異なることがある。そのため、目的となる商品に近い商品の故障情報を得る際には、グレードに基づいて故障情報を選別することが有効だろう。図２２の例では、プルダウンメニューによってグレードを選択する。

なお、同一グレードの商品であって、ディーラーオプションの有無などにより装備品が異なる場合がある。そこで、付属品を指定することで、同一の付属部品を備えている商品の故障情報のみを選別することができる。図２２の例では、付属品の名称または部品番号を入力することで、付属品を指定することができる。

使用状況が指定されると、整備情報の送信要求に係る商品の使用状況と同一又は類似した使用状況の商品の故障情報のみを選別することになる。使用状況とは、故障が発生したときの走行距離、車速、登坂勾配などをいう。なお、走行距離等のデータは、異なる車両間で完全に一致することは稀なので、一定の範囲内にあるものを類似するとして選別してもよい。図２２の例では、テキストボックス内に使用状況を入力することができる。

使用環境が指定されると、送信要求に係る商品の使用環境と同一又は類似した使用環境の商品の故障情報のみを選別することになる。使用環境とは、寒冷地、非寒冷地、海岸部、都市部など、地理的または気候的な環境を意味する。図２２の例では、プルダウンメニューによって使用環境を選択することができる。

発生数が指定されると、同内容の故障の発生数に基づいて故障情報が選別される。例えば、「１０件以上」の如く件数を指定すれば、マイナーな故障情報については排除することができるだろう。

図２２において、実行ボタンがクリックされるとクライアント端末のＣＰＵ２０１は、指定された選別ルールと、入力された具体的な条件とをサーバー１５０に送信する。

ステップＳ２１０４において、ＣＰＵ２２１は、受信した選別ルールを故障情報の検索条件に追加する。なお、この検索条件には、最初にクライアント端末から指定された機種コードなどの情報が予め設定されているものとする。ステップＳ２１０６において、ＣＰＵ２２１は、設定された検索条件にしたがって、故障情報を詳細に検索する。

なお、故障情報の選別処理は、図９に示した整備情報の表示画面から実行されてもよい。例えば、整備情報の表示画面上で右クリック等によって故障情報の選別が指定されると、クライアント端末のＣＰＵ２０１は、選別指示を送信する。この選別指示を受信すると、ＣＰＵ２２１は、整備情報の選別指示があったものと判定し、図２２の入力画面を送信する。以降の処理は上述したとおりである。

以上説明したように、故障情報の選別処理を導入することで、ユーザは、希望するものにより近い故障情報のみを選別して表示することができるようになる。

上述した選別ルールの設定次第では、表示されるべき故障情報が予想外に少なくなってしまうこともあろう。そこで、選別から漏れた他の故障情報を追加的に表示できれば便利であろう。以下では、この追加表示処理について説明する。

図２３は、故障情報の追加表示処理についての例示的なフローチャートである。なお、既に説明した処理と同様の処理については同一の参照符号を付すことにより説明を省略する。

ステップＳ２３００において、クライアント端末のＣＰＵ２０１は、故障情報の追加表示要求を送信する。例えば、故障情報の表示画面に設けられた追加表示ボタンが操作されたことを検出すると、当該追加表示要求を送信する。

ステップＳ２３０２において、サーバー１５０のＣＰＵ２２１は、追加表示要求を受信する。ステップＳ２３０４において、ＣＰＵ２２１は、再検索用の検索条件を決定する。例えば、直前の検索条件から、選別ルールによる検索条件の一部又は全部を削除する。どの検索条件を削除すべきかを、クライアント端末に問い合せてもよい。

ステップＳ２３０６において、ＣＰＵ２２１は、新しい検索条件に基づいて再検索を実行する。以降は、図６で説明したとおりである。

このように、クライアント端末に送信された故障情報以外の故障情報の表示要求をクライアント端末から受信すると、サーバー１５０は、表示要求に応じて、機能部位や構成部品に関する複数の故障情報のうち、残りの故障情報を読み出して画面の表示情報を作成し提供することができる。すなわち、追加表示処理を起動することで、選別から漏れてしまった故障情報を表示することが可能となる。

同一の商品について故障情報を検索した場合に、十分な故障情報が得られない場合もある。しかしながら、自動車のような商品であれば、異なる車種間で共通の部品が使用されることはよくある。そのため、他の車種についてはその部品の故障情報が十分に登録されている可能性がある。そこで、共通の部品を採用している類似の商品の故障情報も併せて提供できるようにする。

図２４は、類似商品についての故障情報も含めた検索処理に関する例示的なフローチャートである。この故障情報の検索サブルーチンは、図６のステップ６０６に相当する。

ステップＳ２４００において、ＣＰＵ２２１は、クライアント端末から受信した整備情報または故障情報の検索条件に含まれている商品コード（例えば、機種コードなど）に基づいて類似商品の商品コードを検索抽出する。例えば、予め類似する商品群について識別番号を割り当て、当該識別番号と対応付けて当該類似商品群に属する商品コードをデータベース化してＨＤＤ２２４に記憶しておけば、容易に類似商品の商品コードを検索できる。

ステップＳ２４０２において、ＣＰＵ２２１は、クライアント端末から指定された商品コードと、類似商品の商品コードとを検索条件として設定する。

ステップＳ２４０４において、ＣＰＵ２２１は、必要であれば、追加の検索条件を設定する（オプション）。例えば、同一サプライヤーから提供された機能部位または構成部品、製造日、製造番号、商品分類（例えば、セダン、ワンボックスなど）、使用状況、使用環境、グレード、オプション装備などを追加の検索条件としてもよい。これは、クライアント端末に問い合せて設定させてもよいし、あらかじめ設定されたものであってもよい。なお、追加の検索条件を設定することで、必要以上の故障情報が抽出されてしまう事態を回避できよう。

ステップＳ２４０６にいて、ＣＰＵ２２１は、設定された検索条件にしたがって故障情報を検索する。以上説明したように、類似の商品に検索範囲を広げることで、故障情報を幅広く抽出して表示することが可能となる。

なお、指定商品について故障情報が見つからなかったとＣＰＵ２２１が判定した場合に、類似商品についての故障情報を検索するように制御してもよい。このような拡大検索処理は、指定された機能部位や指定された構成部品単位で適用してもよい。

図２５は、指定された商品・機能部位・構成部品についての故障情報が見つからなかった場合に実行される拡大検索処理の例示的なフローチャートである。図２４と共通の処理については説明を省略する。

ステップＳ２５００において、ＣＰＵ２２１は、クライアント端末から指定された商品の商品コードと、部品コード（例えば、ＳＣＴ、ＳＣ、部品番号など）を検索条件として設定する。ステップＳ２５０２において、ＣＰＵ２２１は、追加条件を設定する。追加条件の設定は、上述のステップＳ２４０４で説明したとおりである。

ステップＳ２５０４において、ＣＰＵ２２１は、故障情報を検索する。ステップＳ２５０６において、ＣＰＵ２２１は、指定商品等についての故障情報が抽出されたか否かを判定する。抽出されていれば、元の処理に復帰する。一方、故障情報が抽出されなければ、ステップＳ２４００、Ｓ２４０２、及びＳ２４０６に相当する処理を行ない、類似商品等についての故障情報を検索する。

以上説明したように、所望の商品について故障情報が抽出されなかった場合に、検索範囲を拡大することで、不必要に多くの故障情報が表示されてしまう事態を回避できよう。

なお、故障情報の登録時に、当該故障情報を拡大検索の対象とするか否かをユーザが指定していするようにしてもよい。すなわち、所定の商品または所定の機能部位についての故障情報を、他の商品または他の機能部位についての故障情報が要求されたときにも提供するか否かを指定するための指定情報を、故障情報の登録時にクライアント端末からサーバー１５０に送信する。この指定情報を受信すると、サーバー１５０は、故障情報管理データベース１７１に当該指定情報を登録する。そして、ＣＰＵ２２１は、拡大検索を開始すると、指定情報が「提供可」となっている故障情報のみを検索抽出する。

ところで、指定した商品だけでなく、類似の商品について故障情報を表示させた場合に、両者を区別したい場合もある。なぜなら、指定した商品についての故障情報の方が、よりユーザの検索要求に合致したものだからである。そこで、本実施形態では、指定された商品の故障情報を優先的に表示するようにする。

図２６は、故障情報の優先表示に関するフローチャートである。なお、図１０と共通する処理については、同一の参照符号を付すことで説明を省略する。

ステップＳ１０００からステップＳ１００６の処理を経た後で、ＣＰＵ２２１は、ステップＳ２６００において、優先表示用の画面の表示情報を作成する。例えば、指定された商品の故障情報とそれ以外の故障情報について、それぞれの表示色を異ならしめる。あるいは、指定された故障情報を上位の順序で表示させてもよい。また、通常時は指定された商品についての故障情報だけを表示し、追加表示ボタンが押されると類似商品等についての故障情報を表示するようにしてもよい。このように、両者の差別化を図ることができる。表示色を変える場合は、例えば、ＣＰＵ２２１が、ＨＴＭＬファイル内のｃｏｌｏｒタグを変更すればよい。表示順序の変更も、ＣＰＵ２２１がＨＴＭＬファイル内における故障情報のパスの順序をソートすることで実現できる。また、類似商品の故障情報についての表示／非表示の切り換えは、クライアント端末から送信される表示／非表示の要求に応じて、ＣＰＵ２２１がＨＴＭＬファイルを変更し送信すればよい。

図２７は、発注処理に関する例示的なフローチャートである。一般に、部品を発注する際には、部品が故障した場合が多い。一方で、部品についての故障情報の登録は、掲示板への書込みに似た性質があるため、必ずしも故障情報が有効にデータベースへと登録されるとは限らない。そこで、本実施形態では、部品発注の際に故障情報を入力できるようにしたものである。

ステップＳ２７００において、クライアント端末のＣＰＵ２０１は、操作部２０６から発注要求が入力されたことを検出すると、ネットワークインタフェース２０７を介して発注要求を送信する。例えば、整備情報の表示画面に設けられている発注ボタンが操作されると、発注要求が送信される。

ステップＳ２７０２において、サーバー１５０のＣＰＵ２２１は、発注要求を受信すると、ステップＳ２７０４において、発注情報を入力するための画面の表示情報を送信する。ステップＳ２７０６において、クライアント端末のＣＰＵ２０１は、入力画面の表示情報を受信すると、表示装置２０５に入力画面を表示する。
図２８は、発注情報の入力画面の一例を示す図である。この入力画面において、車名や部品番号など、発注対象となる部品を特定するために必要となる発注情報が入力される。ステップＳ２７０８において、ＣＰＵ２０１は、操作部２０６から入力された発注情報をサーバー１５０に送信する。

ステップＳ２７１０において、ＣＰＵ２２１は、発注情報を受信すると、ステップＳ２７１２において、発注情報に含まれる情報から故障情報の一部を推定する（オプション）。これにより、登録すべき故障情報の少なくとも一部が作成され、ユーザの入力手間を軽減させることができる。

ステップＳ２７１４において、ＣＰＵ２２１は、故障情報の入力画面の表示情報をクライアント端末に送信する。ステップＳ２７１０を実行した場合には、この故障情報の入力画面の表示情報に、推定された故障情報が含まれることになる。

ステップＳ２７１６において、ＣＰＵ２０１は、故障情報の入力画面の表示情報を受信し、表示装置２０５に表示する。故障情報の入力画面としては、例えば、図４に示したものが考えられる。ステップＳ２７１８において、ＣＰＵ２０１は、操作部２０６から入力された故障情報をサーバー１５０に送信する。

故障情報を入力する際に、予め推定された故障情報が入力されていた場合には、ユーザは適宜情報を追加および修正して送信することができる。一部の故障情報が入力済みであるため、ユーザの入力手間が軽減される利点がある。

なお、故障情報の入力画面に登録不要ボタンを設けてもよい。当該ボタンが操作されると、ＣＰＵ２０１は、故障情報の登録不要要求を送信する。このように、ありふれた故障や、故障以外の原因で部品を発注する場合は、故障原因の入力を省略したほうがユーザフレンドリーであろう。

ステップＳ２７２０において、ＣＰＵ２２１は、故障情報を受信すると、故障情報管理データベース１７１へと登録する。そして、ステップＳ２７２２において、発注情報を発注管理データベース１７３に登録することで、発注処理を実行する。なお、ＣＰＵ２２１は、発注情報を含む電子メールを作成して、部品のサプライヤー宛てに送信してもよい。

以上のように、発注処理の際に故障情報を登録できるようにすることで、故障情報が効率よくデータベースに登録されると考えられる。また、故障情報の一部を発注情報から推定することで、ユーザの入力手間を軽減することができる。

図２９は、故障情報推定処理についての例示的なフローチャートである。ステップＳ２９００において、ＣＰＵ２２１は、発注情報に含まれている情報のうち、故障情報の推定に役立つ故障関連情報を読み出す。故障関連情報とは、例えば、車名や部品番号などである。

ステップＳ２９０２において、ＣＰＵ２２１は、故障関連情報に基づいて、商品コード（例えば、機種コードなど）や、発注対象となる部品が採用されている機能部位の識別コードを特定する。機種コードは、車名から特定でき、機能部位の識別コードは、部品番号から特定できる。なぜなら、整備情報管理データベース１７０や故障情報管理データベース１７１など、あるいは不図示の部品管理データベースにおいて、これらのコード間の対応関係が登録されているからである。

ステップＳ２９０４において、ＣＰＵ２２１は、こららの特定された識別コードに基づいて、故障情報管理データベース１７１に登録されている故障情報を検索抽出することで、発注対象部品の故障情報を推定する。以上の処理により、発注対象部品についての故障情報を推定することができる。

次に、故障した部品に関連する他の部品の発注処理について説明する。一般に、部品が故障した場合に、複数の部品を同時に交換する場合が多い。その場合に、熟練したものであれば、修理に必要な部品をすべて発注できるだろうが、そうでない者も存在しよう。そのような場合に、故障内容に応じて関連する他の部品の情報もユーザに案内できれば、発注効率が改善し、修理に要する時間も削減できよう。そこで、本実施形態では、ある部品について故障情報とともに発注情報が登録された場合には、関連部品についても案内するようにする。

図３０は、関連部品についての発注処理の例示的なフローチャートである。この処理は、例えば、発注処理（Ｓ２７２０）内のサブルーチンとして実行される。

ステップＳ３０００において、ＣＰＵ２２１は、関連部品を案内するための案内画面の表示情報を作成する。例えば、ＣＰＵ２２１は、上述の処理で入力された発注部品コードと故障情報とに基づいて、過去に当該故障情報に関連して発注された関連部品の部品コードを、発注管理データベース１７３から検索抽出する。そして、抽出された関連部品の部品コード、部品名等を含む案内画面の表示情報を作成する。ステップＳ３００２において、ＣＰＵ２２１は、作成した案内画面の表示情報をクライアント端末に送信する。

ステップＳ３００４において、クライアント端末のＣＰＵ２０１は、案内画面の表示情報を受信して、表示装置２０５に表示させる。

図３１は、関連部品に係る発注案内画面の一例を示す図である。この例では、発注部品の部品名、部品番号および故障情報に加えて、関連部品の案内情報が含まれている。

ステップＳ３００６において、ＣＰＵ２０１は、関連部品の発注要求ボタン（例えば、図３１の「はい」ボタンなど）の操作を検出すると、関連部品の発注要求を送信する。なお、「いいえ」ボタンの押し下げを検出すると、発注不要を表す情報をサーバー１５０に送信する。この場合、サーバー１５０は、関連部品を発注することなく、発注処理を終了する。

ステップＳ３００８において、サーバー１５０のＣＰＵ２２１は、関連部品の発注要求を受信すると、ステップＳ３０１０において、関連部品をサプライヤーに発注するための電子メールを作成して送信する。

ステップＳ３０１２において、発注管理データベース１７３の発注履歴データを更新する。以上のように、ある部品の発注に際して故障情報が登録されたときに、過去の発注履歴に基づいて関連部品を案内することで、ユーザは、関連部品についても忘れることなく発注できるようになろう。

ところで、部品を発注する際には、故障情報が登録されない場合もある。例えば、十分に対象方法が確立されていれば、あえて同内容の故障情報が登録されることはないだろう。しかしながら、同内容の故障がどの程度発生しているかを把握する必要もある。例えば、故障が頻発しているようであれば、根本的な解決策が必要だからである。なお、部品が発注されるのは、当該部品について故障が発生したときであることは前述したとおりである。そこで、本実施形態では、部品ごとの発注数から概略的な故障の発生数を求め、整備情報や故障情報とともに故障の発生数を提供するようにする。

図３２は、故障発生件数の推定処理に関する例示的なフローチャートである。当該推定処理は、発注処理が終了した後に実行されてもよいが、もちろん任意のタイミングで実行されてもよい。

ステップＳ３２００において、ＣＰＵ２２１は、発注管理データベース１７３に登録されている各部品、または故障情報管理データベース１７１に登録されている各部品について、発注数をカウントする。

ステップＳ３２０２において、ＣＰＵ２２１は、カウントされた発注数に所定の係数を乗算する（オプション）。所定の係数を利用するのは、部品の発注数と故障の発生回数が必ずしも一致しないため、両者を調整して、実際の値に少しでも近づける必要があるからである。所定の係数は、例えば、故障以外の原因で発注されたものや、一つの故障を解消するために複数個の部品があることを経験的に決定してもよい。また、所定の係数は、例えば、各故障ごとに対応付けてＨＤＤ２２４等に記憶されている。

ステップＳ３２０４において、ＣＰＵ２２１は、当該部品に対応する故障情報を抽出し、故障情報内の発生件数の部分に当該カウント値を書き込む。

以上のようにして、概略的な発生件数が求められる。この発生件数は、クライアント端末から故障情報を求められたときに一緒に送信さることになる。

図３０に示した故障情報の登録処理は、部品の発注に際して故障情報を登録するものであった。しかしながら、故障情報を登録する際に、部品の発注が実行されてもよい。そこで、本実施形態では、故障情報の登録の際に部品の発注も実行するようにした。

図３３は、故障情報の登録の際に部品の発注処理に関する例示的なフローチャートである。ステップＳ３３００において、クライアント端末のＣＰＵ２０１は、故障情報の登録要求をサーバー１５０に対して送信する。例えば、図２０に示した故障情報の登録ボタンが操作されると、当該登録要求が送信される。

ステップＳ３３０２において、サーバー１５０のＣＰＵ２２１は、故障情報の登録要求を受信すると、ステップＳ３３０４において、故障情報の入力画面と発注情報の入力画面を作成して、クライアント端末に送信する。

ステップＳ３３０６において、クライアント端末のＣＰＵ２０１は、当該入力画面を受信すると、表示装置２０５に表示させる。

図３４は、故障情報と発注情報の例示的な入力画面を示した図である。図４に示した故障情報に加え、発注部品の発注数を入力できるようになっている。ステップＳ３３０８において、ＣＰＵ２０１は、操作部２０６から入力された故障情報と発注情報とを、サーバー１５０に送信する。

ステップＳ３３１０において、ＣＰＵ２２１は、クライアント端末から故障情報と発注情報を受信すると、上述したステップＳ３０４に従い故障情報を登録する。そして、上述したステップＳ２７２２に従い発注処理を実行する。

このように、故障情報を登録する際に、部品の発注も実行できるようにしたので、双方の処理を効率よく実行できるようになる。

なお、上述した部品の発注処理は、例えば図９に示したような整備情報と故障情報の表示画面における発注ボタンを操作することで実行されてもよい。すなわち、発注ボタンが操作されると、図２７に示したような発注処理が実行される。なお、故障情報の登録処理は省略されてもよい。

また、図９の表示画面を形成するためのＨＴＭＬファイルには、整備情報とともに故障情報の内容または有無を表示させるためのコード（例えば、タグ、スクリプトなど）と、機能部位に関する部品の発注要求を送信するためのコード（例えば、発注ボタンフォームやスクリプトなど）が含まれている。

なお、ＣＰＵ２２１は、故障の対象方法が「部品交換」かどうかを判定し、「部品交換」となっている場合に限り、発注ボタンを表示するような画面情報を作成してもよい。このようにすれば、部品交換により故障を修理可能なことをユーザにわかり易く伝えることができよう。

次に故障情報の見易さを改善する方法を説明する。上述したように、故障情報は随時蓄積されてゆくため、同一の機能部位または同一の構成部品について多数の故障情報が登録される可能性もある。この場合、整備情報の画像に対し、すべての故障情報の説明文書を重ね合わせて表示することは難しい。そこで、本実施形態では、多数の故障情報が登録されている場合における、整備情報と故障情報の見易さを改善する。

すでに、図１２を用いて、Ｗｅｂのリンク機能を用いて段階的に表示するための画面の表示情報については説明したので、ここでは、ステップＳ１２１６に相当するサブルーチンについて説明する。

図３５は、整備情報の表示画面上に故障情報の詳細表示要求を送信するためのアイコンを作成する処理についての例示的なフローチャートである。

ステップＳ３５００において、ＣＰＵ２２１は、処理対象となっている構成部品の画面上の表示位置情報を取得する。なお、この表示位置情報は、各構成部品について予めデータベース化されてＨＤＤ２２４に記憶されているものとする。

ステップＳ３５０２において、ＣＰＵ２２１は、故障情報の詳細表示要求を送信するためのアイコン（リンクボタン）のファイル名、取得した表示位置情報、アイコンがクリックされたときの動作（例えば、詳細情報の送信要求の送信スクリプトやハイパーリンクなど）の情報を、構成部品用のテンプレートファイルに書き込む。

図３６は、故障情報の詳細表示要求を送信するためのアイコンが配置された整備情報の表示画面の一例を示す図である。図から明らかのように、故障情報の登録されている各構成部品と関連付けて、星型のアイコンが表示されている。この星形のアイコンがクリックされると、故障情報の詳細表示要求が送信される。

図３７は、故障情報の詳細表示に関する例示的なフローチャートである。ステップＳ３７００において、クライアント端末のＣＰＵ２０１は、詳細表示要求の送信指示が成されたことを検出すると、詳細表示要求をサーバー１５０に送信する。図３６の例で説明すると、星形のアイコン（例えば、リンクボタンなど）が操作部２０６から操作されたことを検出して、ＣＰＵ２０１は、リンクされたページの送信要求をサーバー１５０に送信する。

ステップＳ３７０２において、ＣＰＵ２２１は、詳細情報の送信要求を受信すると、ステップＳ３７０４に進み、詳細情報をＨＤＤ２２４などから読み出す。

ステップＳ３７０６において、ＣＰＵ２２１は、読み出した詳細情報を表示するための画面の表示情報を作成する。例えば、＜ｔａｂｌｅ＞などの一連のテーブルタグを用いて、読み出した故障情報を表示するためのＨＴＭＬファイルを作成する。ステップＳ３７０８において、ＣＰＵ２２１は、詳細情報表示用の画面の表示情報を送信する。

ステップＳ３７１０において、クライアント端末のＣＰＵ２０１は、画面の表示情報を受信すると、ステップＳ３７１２において、受信した画面の表示情報を表示装置２０５に表示させる。

図３８は、故障情報の詳細表示画面の一例を示す図である。図から明らかなように、クリックされたアイコンに対応する構成部品または機能部位の故障情報がテーブル形式で表示されている。

ところで、一つの故障部品について多数の故障が登録されていると、整備情報の表示画面に多数のアイコンが表示され、ユーザに煩雑な印象を与えかねない。そこで、本実施形態では、一つの構成部品または機能部位について複数の故障情報が登録されている場合は、故障情報の数に比し、アイコンの表示数を減らすことで、整備画面の見易さを改善するものである。極端な場合、複数の故障情報に対して単一のアイコンを表示してもよい。

図３９は、故障情報表示画面の作成処理に関する例示的なフローチャートである。なお、既に説明した個所は、同一の参照符号を付すことにより説明を省略する。

ステップＳ３９００において、ＣＰＵ２２１は、各構成部品について、検索抽出された故障情報の数をカウントする。ステップＳ３９０２において、各構成部品について、故障情報の数を示したアイコンを作成する。この例は、構成部品ごとに一つのアイコンを作成する。なお、故障情報の数より少ない数のアイコンであれば、必ずしも単一のアイコンである必要はない。以降では、図３５等で説明した故障情報表示画面の作成処理を実行する。

図４０は、故障情報表示画面の一例を示す図である。図３６では三つ表示されていたアイコンが、図４０では、単一のアイコンにまとめられていることがわかる。さらに、この例では、アイコン内に故障情報の登録数が表示されているので、各構成部品ごとに何件の故障情報が登録されているかが一目でわかる利点もある。

図４１は、故障情報の詳細表示画面に係る他の例を示すである。図４１は、図４０に対応したもので、クリックされたアイコンに対応する複数の故障情報が表示されている。図４１に表示された画面も図３７のフローチャートに沿って作成されたものである。とりわけ、図４１の場合は、クライアント端末から送信される詳細情報の表示要求の中に、複数の故障情報を表示させるための命令が含まれる。この表示要求にしたがって、ＣＰＵ２２１は、複数の故障情報を読み出して、テーブル化し、画面の表示情報を作成する。

以上の実施形態では、構成部品ごとの故障情報の登録数をカウントしたが、ＣＰＵ２２１は、複数の抽出された故障情報のうち故障種別ごとの数をカウントしてもよい。そして、上述のアイコンについても故障種別ごとに表示してもよい。さらに、故障情種別ごとの登録数をアイコンとともに表示してもよい。

また、故障情報には、故障の解消策（対処方法など）に関する情報に加え、当該解消策による故障解消率の情報が含まれていてもよい。故障解消率についても予め故障情報管理データベース１７１に記憶しておくことで、故障情報を読み出す際に故障解消率も含めて読み出すことができる。

また、表示された故障情報の中には、故障解消策に関する詳細な整備情報へのリンク情報が含まれていてもよい。例えば、図３８や、図４１に示されている対処方法である「交換」等をクリックすると、詳細な整備情報をサーバー１５０からクライアント端末に送信するようにしてもよい。例えば、対処方法である「交換」の文字部分を、詳細整備情報を含むＨＴＭＬファイルへのハイパーテキストリンクとして記述しておけばよい。

図４２は、詳細な故障情報を表示するための中間的な画面の一例を示す図である。この画面は、上述した星形の故障情報表示アイコンをクリックすると表示される画面であり、故障情報のうち概要的な情報だけを表示するようにしたものである。この画面に設けられている詳細表示ボタンがクリックされると、図４１等に示した最終的な詳細情報が表示されるようにしてもよい。すなわち、階層的に情報を表示させることで、整備情報や故障情報の表示画面の見易さを向上させることができる。

図４３は、故障情報の公開時期を管理するためのサブルーチンの例示的なフローチャートである。図４や図５に関連して説明したように、故障情報をクライアント端末から登録する際に、当該故障情報の公開条件を設定することができる。公開条件を設定することにより、故障情報が例えば信頼性のある情報へと成熟してから公開できるようになる。

ステップＳ４３００において、ＣＰＵ２２１は、各故障情報の公開条件（例えば、図５の情報提供時期など）を故障情報管理データベースから読み出す。なお、公開条件が、例えば「即日」となっている故障情報については、すでに公開対象となっているので、以下の処理の対象外にしてもよい。

ステップＳ４３０２において、ＣＰＵ２２１は、公開条件を満たしているかどうかを判定する際に役立つ比較情報を読み出す。例えば、公開条件が「所定期間（例：７日後）」であれば、故障情報の入力日を故障情報管理データベース１７１から読み出すとともに、内蔵タイマーから今日の日付データを取得し、差分演算を実行する。

あるいは、公開条件が「問い合せ」であれば、故障情報ごとの問い合せ先を読み出して問い合せ処理を実行する。例えば、故障情報と対応付けて記憶されている入力者の電子メールアドレスを、故障情報管理データベース１７１またはユーザ管理データベース１７２から読み出し、問い合わせの対象となっている故障情報を含む電子メールを作成して送信する。ＣＰＵ２２１は、公開可否に関する返事を電子メール等により受信する。

ステップＳ４３０４において、ＣＰＵ２２１は、取得した比較情報が公開条件に合致しているかどうかを判定する。例えば、今日の日付が、入力日から所定期間過ぎているかどうかを判定する。あるいは、公開情報の登録者から公開許可の電子メールを受信したかを判定する。公開条件を満たしていなければ、公開管理サブルーチンを終了する。

一方、公開条件を満たしていれば、ステップＳ４３０６において、公開条件を「公開許可（例：即日）」へと変更する。以上のように、公開条件を満たした故障情報だけを公開するようにすることで、より信頼の置ける故障情報を提供することができる。

なお、上述の公開条件は、例示に過ぎず、他の公開条件を採用してもよい。例えば、故障情報の入力日から所定期間が経過する前に、同一の商品について同一の故障情報が再度登録されていないことなどである。また、所定期間は、故障情報の種別ごとに設定するようにしてもよい。さらに、複数の公開条件を組み合わせてもよい。例えば、所定期間の経過及び登録者への問い合せを組み合わせるが如くである。

また、問い合せメール内に、対応する故障情報の編集画面へのリンク情報を記入しておけば、クライアント端末において、当該リンク情報をクリックすることで、サーバー１５０から編集画面を送信してもよい。この場合は、クライアント端末から公開条件を編集できるため、公開条件の編集の自由度が増す利点がある。

また、このように公開条件の編集サイトをサーバー１５０上に設けることで、上述のサブルーチン以外のタイミングでも、自由にクライアント端末が編集サイトにアクセスし、公開条件を設定しなおすようにしてもよい。例えば、故障情報を無条件に公開させるために、公開条件を無効化または変更するように設定してもよい。

図４４は、公開条件の編集処理に関する例示的なフローチャートである。ステップＳ４４００において、クライアント端末のＣＰＵ２０１は、サーバー１５０に対して公開条件の編集要求を送信する。例えば、図１９に示したメニュー画面から「公開条件の編集」が選択され、実行ボタンが操作されると、ＣＰＵ２０１は、編集要求を送信する。編集要求には、編集対象となる公開条件に関連する情報（例えば、故障情報の入力日、ユーザ名など）が含まれている。なお、上述したように、問い合せ電子メールに含まれるリンクをクリックすることにより編集要求が送信されてもよい。

ステップＳ４４０２において、サーバー１５０のＣＰＵ２２１は、編集要求を受信すると、ステップＳ４４０４に進み、編集対象の公開条件を、故障情報管理データベース１７１から読み出し、編集画面を作成する。ＣＰＵ２２１は、作成した編集画面の表示情報（例：ＨＴＭＬファイルなど）をクライアント端末に送信する。

ステップＳ４４０６において、クライアント端末のＣＰＵ２０１は、編集画面の表示情報を受信し、表示装置２０５に編集画面を表示する。ステップＳ４４０８において、ＣＰＵ２０１は、操作部２０６から入力された情報に基づいて、公開条件を編集する。ステップＳ４４１０において、ＣＰＵ２０１は、操作部２０６から送信指示に応じて、編集後の公開条件の登録要求をサーバー１５０に送信する。

ステップＳ４４１２において、サーバー１５０のＣＰＵ２２１は、登録要求を受信すると、ステップＳ４４１４において、登録要求に含まれる編集後の公開条件を故障情報管理データベース１７１に記憶する。

以上のようにして、公開条件をクライアント端末から自由に変更できるようになる。

以上説明したいように本実施形態によれば、例えば、サービス工場などに設置されたクライアント端末から、商品の故障情報が整備情報と関連付けられて投稿されるため、故障情報を共有できるようになり、最終的には、故障整備の効率が改善すると考えられる。

また、本実施形態によれば、整備情報の提供画面において故障情報が登録されていることを視覚的に表示し、ユーザの指示に応じて詳細な故障情報を提供するようにしたので、整備情報と故障情報を提供するためのユーザインタフェースが使いやすいものとなろう。

また、本実施形態によれば、例えば、整備情報の画像データと、故障情報の画像データとを、ユーザに提供する際に動的に重畳合成させて提供するようにしたので、整備情報と故障情報とを個別にアップデーすることが可能となり、より柔軟に整備情報と故障情報とを提供できよう。

本実施形態によれば、各機能部位を構成する構成部品を表示するページにおいて、故障情報を表示するようにしたので、構成部品と故障情報との関係をユーザにわかりやすく提供できよう。

本実施形態によれば、例えば、ハイパーテキストリンクなどのリンク機能を用いて、機能部位を表示するページと構成部品を表示するページとをリンクさせ、機能部位のページでは故障情報の有無を、構成部品のページでは故障情報の詳細を提供するようにしたので、ユーザは必要な情報へと容易にアクセスできるであろう。

本実施形態によれば、ユーザが好みの表示形態を選択できるようにしたので、ユーザの嗜好に応じて整備情報と故障情報とを提供できるようになろう。

本実施形態によれば、商品の種別コードや故障コードに基づいて故障情報等の検索を可能にしたので、ユーザは商品の種別コードや故障コードを入力することで、目的の整備情報と故障情報と容易にアクセスできるようになろう。

本実施形態によれば、商品から出力されコードをクライアント端末で受信することで、ユーザによるマニュアル入力による手間を省け、しかも誤入力を抑制できる利点がある。

本実施形態によれば、新しい内容の故障情報が登録された場合には、メーカーやサプライヤーなどの開発部門に通知するようにしたので、部品の改良や新規商品の設計に役立てることができよう。

本実施形態によれば、同一内容の故障情報が、ある程度寄せられると、当該故障情報は重要な情報と考えられるため、メーカーやサプライヤーなどに通知し、故障の原因などを設計レベルから詳細に調査することが可能となろう。

本実施形態によれば、故障情報の種別に応じて、頻発故障通知の送信を制御することで、必要なものを選別して通知を行なうことができる。

本実施形態によれば、システム側から提供された整備情報に関連して、クライアント端末から故障情報を登録できるようにしたので、ユーザは、故障情報を登録すべき整備情報を確認しながら故障情報を登録でき、故障情報の登録が容易になる利点がある。

本実施形態によれば、複数の故障情報のうち、一部の故障情報のみを提供するようにしたので、例えば、すべての故障情報が無秩序に表示されてしまうことによってユーザは戸惑わせるような問題を軽減できよう。

また、所定の選別ルールに則した一部の故障情報のみを読み出してユーザに提供するようにしたので、ユーザは選別ルールという秩序に従った故障情報を享受できるようになる。

例えば、製造番号の近いものや製造日の近いものなどを抽出できるように選別ルールを設定すれば、修理対象の商品とほぼ同時期に製造された他の商品についての故障情報だけを提供できるようになる。経験的に、同時期に製造された商品は、故障に関しても近い傾向を示すことがあるので、これらの選別ルールを適用すれば、より関連性の高い故障情報を入手しやすくなるだろう。

また、商品のグレードや付属品の有無などを選別ルールとして設定すれば、グレードや付属品が共通する他の商品の故障情報を入手できるようになる。例えば、商品のグレードが異なれば、エンジン等の仕様が異なったり、装備品の内容が異なったりするが、グレードの違いや付属品の有無が故障の傾向に影響を及ぼすことがある。特に、付属品（例：オプション部品など）の故障情報が必要な場合には、付属品の有無などを選別ルールとしなければ、必要な故障情報を入手できない。よって、グレードの違いや付属品の有無を選別ルールとして採用することで、役に立つ可能性の高い故障情報を入手できるだろう。

また、同一または類似した使用状況や使用環境を選別ルールとして設定しても、故障情報を有効に選別できよう。すなわち、故障の種別によっては、同一または類似の使用状況や使用環境において発生しやすい場合があるため、このような故障については、使用状況や使用環境を選別ルールとして設定することで、意味のある故障情報を抽出できよう。例えば、塩害の影響を受けやすい海岸付近で使用される自動車であれば、車体の腐食が生じやすいため、腐食に関連した故障情報を選別しやすいだろう。

また、故障の発生数を選別ルールとして設定してもよい。例えば、１００件以上報告されている故障を選別ルールとして設定すれば、発生する可能性の高そうな故障についての故障情報を入手できるようになろう。

なお、選別ルールの設定次第では、表示される故障情報が少なくなりすぎてしまう場合もあろう。そこで、追加の表示要求をクライアント端末から送信することで、最初の選別で漏れた故障情報も後からクライアント端末へと提供できるようになる。

本実施形態によれば、指定された商品の機能部位に関する故障情報に加え、当該機能部位と共通の構成部品を採用しているような、種別の異なる他の商品又は他の機能部位に関する故障情報も提供するようにしたので、ユーザは、指定された商品に関連する故障情報を幅広く入手できる。

また、指定された商品の故障情報と、他の商品の故障情報とを区別して表示するようにしたので、ユーザは、視覚的に両者を区別しやすくなる。例えば、共通部品の故障情報が複数存在した場合は、同一車種についての故障情報のほうが他の車種についての故障情報よりも修理の参考になる場合が多い。よって、両者を区別して表示することで、同一車種についての故障情報を参考にしやすくなろう。

また、指定された商品の故障情報を、種別の異なる商品の故障情報よりも優先的に表示することで、指定された商品の故障情報を主として参考にし、種別の異なる商品の故障情報については必要に応じて参考にすることも可能となろう。

このような優先表示の方法としては、例えば、指定された商品の故障情報を表示し、種別の異なる商品の故障情報については表示しないような方法も含まれる。この場合は、種別の異なる商品の故障情報については、要求に応じて表示すればよい。

なお、種別の異なる他の商品を抽出対象とすることで、ときには、ユーザの予想以上に多数の故障情報が表示されてしまうこともあろう。そのような場合には、単純な区別表示を行なうだけでは、十分に整理された情報を表示することができないかもしれない。そこで、同一のサプライヤーにより供給された機能部位や構成部品に限定して故障情報を抽出してもよい。また、限定的な抽出の条件としては、例えば、製造日、製造番号、商品分類を採用してもよい。商品分類とは、例えば、自動車であれば、セダン、ワンボックス、ワゴンなどの分類をいう。

また、所定の商品または所定の機能部位についての故障情報を登録する際に、当該故障情報を、他の商品または他の機能部位についての故障情報が要求されたときにも提供するか否かをクライアント端末からサーバーに設定してもよい。例えば、ある車種の車両についての故障情報を登録しようとしているサービスエンジニアが、他の車種の車両においてもこの故障情報が有用と考える場合がある。このような場合には、故障情報の提供対象の設定をサービスエンジニアの判断に任せてもよいだろう。そこで、ある商品の故障情報を、種別の異なる他の商品においても提供するか否かをクライアント端末等から設定できるようにした。

本実施形態によれば、部品の発注の際に故障情報を登録するようにユーザを導くことで、故障情報を効率よく収集することができる。故障情報の登録をサービスエンジニアなどのユーザに自由に任せたのでは、十分に故障情報を収集できない可能性もある。例えば、故障情報の登録の手間が煩わしいと考えるユーザなどは故障情報を登録しないであろう。一方で、部品を発注するタイミングは、部品が故障したときが多い。よって、部品を発注する際には、何らかの故障情報をユーザが把握している可能性が高い。そこで、部品の発注の際に故障情報を入力できるようにすることで、故障情報の収集効率が高まるであろう。

一方で、整備情報や故障情報を参照するときは、故障の修理のためである場合が多いと考えられる。その際に、故障の対処策が部品の交換であることを故障情報や整備情報が教示しているときは、修理に必要な部品をその画面から発注できれば便利であろう。そこで、本発明では、整備情報や故障情報を参照したときに、必要であれば部品を発注できるようにした。

なお、本実施形態では、部品の発注に必要な情報が入力された際に、当該情報や、既に登録されている故障情報に基づいて、発注対象部品についての故障情報の少なくとも一部を作成するようにした。これにより、故障情報の入力の手間を軽減することができる。例えば、部品の識別情報に基づいて、商品の種別または機能部位に関する情報を特定して、故障情報の一部を作成している。

また、登録済みの故障情報と発注要求に関する部品の識別情報に基づいて、部品に関する故障情報の少なくとも一部を推定することで、さらに、故障情報の入力を補助することができる。例えば、ある部品について統計上特定の故障が発生する確率が高ければ、当該故障情報を採用してもよい。

なお、自動で作成された故障情報は、必ずしも正しいとは限らない。そこで、作成した故障情報の修正画面をユーザに提示することで、修正の機会を与えることができる。これにより、正しい故障情報を収集できるようになろう。

また、ある部品と一緒に発注される可能性の高い関連部品の情報を記憶しておき、ある部品の発注の際には、当該関連部品の情報を案内することで、修理に必要な一連の部品を一括して発注できるようになる。

また、ある部品の発注回数から、故障の発生件数を求め、求められた故障の発生件数を整備情報などとともに表示させることで、故障の発生数を確認できるようになる。これにより、発生件数の多い故障については、故障の発生前であっても、事前対処を行なうことができよう。

また、発注要求に関連して入力された故障情報と、当該発注要求に係る部品の情報とを対応付けて記憶しておき、他のクライアント端末等から故障情報の送信要求を受信した場合には、故障情報に加え、部品の情報も提供する。すなわち、ある故障情報が参照されたときに、修理に必要となる部品の情報を提供することで、当該部品の発注効率と修理の効率が改善されよう。

本実施形態によれば、故障情報が存在することを表示するためのアイコンを整備情報に重畳させてクライアント端末に提供する。さらに、当該アイコンが操作されてから故障情報の詳細な内容を提供するようにしたので、整備情報と故障情報との見易さを向上させることができよう。

なお、複数の故障情報が登録されていても、アイコンはそれよりも少ない数（例えば、１つなど）しか表示しないようにすることで、画面内がアイコンで埋め尽くされて煩雑になってしまう事態を回避できよう。

また、アイコンがクリックされた場合に、階層的な画面情報情報を作成して提供することで、故障情報を段階的に参照できるようになる。

また、故障情報の数をアイコンとともに表示することで、いくつの故障情報が登録されているかを視覚的に理解できるようになる。

また、故障種別ごとの登録数をカウントして提供すれば、それぞれ種別の異なる故障についての故障情報が何件登録されているかも視覚的に把握できよう。

また、故障情報と関連して故障の解消策に関する情報も提供することで、サービスエンジニア等のユーザは、故障の解消策を即座に把握できよう。なお、解消策をそのまま表示してしまうと煩雑になるおそれがあるので、解決策はリンクを辿ることで段階的に表示されるようにする。なお、故障の解消策に加え、その解消策を適用した場合の解消率を提供してもよい。これにより、ユーザは、解消策の信頼性を判断できよう。

本実施形態によれば、登録された故障情報のうち公開条件を満たしているものから公開することで、例えば、情報として成熟したものを公開できるようになる。また、未成熟な故障情報であっても登録を可能としているので、故障情報の登録がおろそかになる問題を低減できよう。

公開条件を、故障情報の入力日から所定期間が経過する前に、同一の商品について同一の故障情報が再度登録されていないことと設定してもよい。例えば、一度故障対策をしたものの、その後故障観察において同一の故障が再発し、同一の故障情報が再度登録される場合もあろう。そのような場合には、前回登録された故障情報のうち故障対策に関する部分は信頼性が低いことになる。よって、公開条件をこのように設定することで、信頼性の低い故障情報の公開を低減することができよう。

図１は、実施形態に係る整備情報提供システムの一例を示す図である。図２は、実施形態に係る各装置のハードウエア構成例を示す図である。図３は、実施形態に係る故障情報の登録処理を示したフローチャートである。図４は、実施形態に係る故障情報入力ページの一例を示す図である。図５は、実施形態に係る故障情報管理データベースの一例を示す図である。図６は、実施形態に係る整備情報及び故障情報の提供処理に関するフローチャートである。図７は、整備情報の検索条件を入力する際に利用される入力ページの一例を示す図である。図８は、整備情報管理データベースの一例を示す図である。図９は、実施形態に係る整備情報と故障情報とを表示するための画面の一例を示す図である。図１０は、画面の表示情報の作成サブルーチンについての例示的なフローチャートである。図１１は、画面の表示情報の作成サブルーチンについての他の例示的なフローチャートである。図１２は、画面の表示情報作成サブルーチンのさらに他の例を示すフローチャートである。図１３は、整備情報と故障情報の段階的表示の一例を示す図である。図１４は、新規故障通知のサブルーチンを示すフローチャートである。図１５は、頻発故障通知に関する例示的なフローチャートである。図１６は、整備情報と故障情報との表示画面についてのカスタマイズ処理に関するサブルーチンのフローチャートである。図１７は、表示形態の設定画面の一例を示す図である。図１８は、故障情報登録処理に関する他の例を示したフローチャートである。図１９は、整備情報および故障情報の提供に関するメニュー画面の一例を示す図である。図２０は、故障情報を登録するか否かを選択するための画面の一例を示す図である。図２１は、故障情報の検索サブルーチンに関する例示的なフローチャートである。図２２は、選別ルールの問い合せ画面の一例を示した図である。図２３は、故障情報の追加表示処理についての例示的なフローチャートである。図２４は、類似商品についての故障情報も含めた検索処理に関する例示的なフローチャートである。図２５は、指定された商品・機能部位・構成部品についての故障情報が見つからなかった場合に実行される拡大検索処理の例示的なフローチャートである。図２６は、故障情報の優先表示に関するフローチャートである。図２７は、発注処理に関する例示的なフローチャートである。図２８は、発注情報の入力画面の一例を示す図である。図２９は、故障情報推定処理についての例示的なフローチャートである。図３０は、関連部品についての発注処理の例示的なフローチャートである。図３１は、関連部品に係る発注案内画面の一例を示す図である。図３２は、故障発生件数の推定処理に関する例示的なフローチャートである。図３３は、故障情報の登録の際に部品の発注処理に関する例示的なフローチャートである。図３４は、故障情報と発注情報の例示的な入力画面を示した図である。図３５は、整備情報の表示画面上に故障情報の詳細表示要求を送信するためのアイコンを作成する処理についての例示的なフローチャートである。図３６は、故障情報の詳細表示要求を送信するためのアイコンが配置された整備情報の表示画面の一例を示す図である。図３７は、故障情報の詳細表示に関する例示的なフローチャートである。図３８は、故障情報の詳細表示画面の一例を示す図である。図３９は、故障情報表示画面の作成処理に関する例示的なフローチャートである。図４０は、故障情報表示画面の一例を示す図である。図４１は、故障情報の詳細表示画面に係る他の例を示すである。図４２は、詳細な故障情報を表示するための中間的な画面の一例を示す図である。図４３は、故障情報の公開時期を管理するためのサブルーチンの例示的なフローチャートである。図４４は、公開条件の編集処理に関する例示的なフローチャートである。

Claims

ネットワークを介して接続された複数のクライアント端末に所定の商品の整備情報を提供する整備情報提供システムであって、
それぞれ種類の異なる複数の商品について、該商品を構成する複数の機能部位ごとの整備情報を記憶する整備情報記憶手段と、
何れかの前記機能部位について、何れかの前記クライアント端末から入力された故障情報を、該機能部位と対応付けて記憶する故障情報記憶手段と、
何れかの前記クライアント端末から、何れかの前記機能部位に関する前記整備情報の送信要求を受信する受信手段と、
受信された前記送信要求に応じて、対応する前記機能部位の整備情報を前記整備情報記憶手段から読み出すとともに、該機能部位に関する故障情報を前記故障情報記憶手段から読み出し、該故障情報が所定の公開条件を満たしている場合には、該整備情報とともに該故障情報の内容または有無を前記クライアント端末において表示させるための画面情報を作成し、該故障情報が所定の公開条件を満たしていない場合には、該整備情報を前記クライアント端末において表示させるための画面情報を、前記送信要求を送信してきた前記クライアント端末に送信する送信手段と
を含む整備情報提供システム。
前記所定の公開条件は、前記故障情報の入力日から所定期間が経過していることである請求項１に記載の整備情報提供システム。
前記所定の公開条件は、前記故障情報の入力日から所定期間が経過していることに加え、該故障情報を入力した前記クライアント端末から公開許可を得ていることである請求項２に記載の整備情報提供システム。
前記故障情報の入力日から所定期間が経過すると、前記故障情報を入力した前記クライアント端末に対し公開許可要求を送信する手段と、
前記クライアント端末から、公開許可を受信する手段と、
前記公開許可を受けた故障情報を公開可能な情報に変更する手段と
を更に含む請求項３に記載の整備情報提供システム。
前記所定の公開条件は、前記故障情報の入力日から所定期間が経過する前に、同一の商品について同一の故障情報が再度登録されていないことである請求項１に記載の整備情報提供システム。
前記所定期間は、故障情報の種別ごとに設定されている請求項１ないし５の何れかに記載の整備情報提供システム。
前記所定期間は、前記クライアント端末から設定されたものである請求項１ないし６の何れかに記載の整備情報提供システム。
前記故障情報を無条件に公開させるように前記公開条件を無効化または変更する手段をさらに含む請求項１に記載の整備情報提供システム。
ネットワークを介して複数のクライアント端末に所定の商品の整備情報を提供する整備情報提供方法であって、
それぞれ種類の異なる複数の商品について、該商品を構成する複数の機能部位ごとの整備情報を記憶するステップと、
何れかの前記機能部位について、何れかの前記クライアント端末から入力された故障情報を、該機能部位と対応付けて記憶するステップと、
何れかの前記クライアント端末から、何れかの前記機能部位に関する前記整備情報の送信要求を受信するステップと、
受信された前記送信要求に応じて、対応する前記機能部位の整備情報を読み出すとともに、該機能部位に関する故障情報を前記故障情報記憶手段から読み出すステップと、
該故障情報が所定の公開条件を満たしている場合には、該整備情報とともに該故障情報の内容または有無を前記クライアント端末において表示させるための画面情報を作成し、該故障情報が所定の公開条件を満たしていない場合には、該整備情報を前記クライアント端末において表示させるための画面情報を作成するステップと、
作成された前記画面情報を、前記送信要求を送信してきた前記クライアント端末に送信するステップと
を含む整備情報提供方法。