(57)【要約】【課題】複数種類の業者間で執り行われる業務を効率的に支援し、管理することができる業務管理装置及びその制御方法、業務管理システム、プログラムを提供する。【解決手段】ネットワーク事業者サーバ５００は、ネットワーク４００を介して、修理対象の事故案件の審査状況を示す審査状況情報を保険業者端末３００から受信する。その審査状況情報に基づいて、事故案件に係る協定の成立の是非を判定する。その判定の結果、事故案件に係る協定が成立している場合、事故案件に関する事故案件情報に基づいて、該事故案件での修理に必要な修理用部品の発注先となる発注先端末を決定する。そして、ネットワーク４００を介して、決定された発注先端末６００へ、修理用部品の発注を依頼する発注依頼情報を送信する。【選択図】  図１
2004213371.tif 000002
【特許請求の範囲】
【請求項１】
修理業者が有する修理業者端末と、前記修理業者が修理用部品を発注する発注先業者が有する発注先端末と、保険業者が有する保険業者端末とネットワークを介して相互に接続され、これらの業者間で執り行われる業務を管理する業務管理装置であって、
前記ネットワークを介して、修理対象の事故案件の審査状況を示す審査状況情報を前記保険業者端末から受信する受信手段と、
前記審査状況情報に基づいて、前記事故案件に係る協定の成立の是非を判定する判定手段と、
前記判定手段の判定の結果、前記事故案件に係る協定が成立している場合、前記事故案件に関する事故案件情報に基づいて、該事故案件での修理に必要な修理用部品の発注先となる発注先端末を決定する決定手段と、
前記ネットワークを介して、前記決定手段で決定された発注先端末へ、前記修理用部品の発注を依頼する発注依頼情報を送信する送信手段と
を備えることを特徴とする業務管理装置。
【請求項２】
前記修理業者が所有する修理用部品の在庫を管理する部品在庫データベースと、該修理業者の発注先を管理する発注先データベースを記憶する記憶手段と、
前記事故案件情報に基づいて、前記部品在庫データベースを参照して、該事故案件での修理に必要な修理用部品を検索する検索手段とを更に備え、
前記決定手段は、前記事故案件情報に基づいて、前記発注先データベースを参照して、前記検索手段で検索された修理用部品の発注先となる発注先端末を決定する
ことを特徴とする請求項１に記載の業務管理装置。
【請求項３】
前記発注先データベースは、修理業者毎の発注先を管理し、かつその発注先には優先度が設定されている
ことを特徴とする請求項２に記載の業務管理装置。
【請求項４】
前記ネットワークを介して、前記修理用部品を発注した場合の納品予定日を問い合わせるための納品予定日依頼情報を前記発注先端末へ送信する納品予定日依頼情報送信手段と、
前記ネットワークを介して、前記納品予定日依頼情報を送信した発注先端末から発注部品の納品予定日を示す納品予定日情報を受信する納品予定日情報受信手段と、
前記納品予定日情報に基づいて、前記修理用部品の発注先となる発注先端末を決定する発注先端末決定手段と
を更に備えることを特徴とする請求項１に記載の業務管理装置。
【請求項５】
前記ネットワークを介して、前記事故案件での修理に必要な修理用部品の発注に関する発注情報を前記修理業者端末へ送信する発注情報送信手段と
を更に備えることを特徴とする請求項１に記載の業務管理装置。
【請求項６】
前記発注情報を含む前記事故案件に係る審査状況を示す審査状況情報を生成する生成手段と
を更に備えることを特徴とする請求項５に記載の業務管理装置。
【請求項７】
修理業者が有する修理業者端末と、前記修理業者が修理用部品を発注する発注先業者が有する発注先端末と、保険業者が有する保険業者端末と、これらの業者間で執り行われる業務を管理する業務管理端末とがネットワークを介して相互に接続されて構成される業務管理システムであって、
前記保険業者端末は、
前記ネットワークを介して、修理対象の事故案件の審査状況を示す審査状況情報を送信する第１送信手段とを備え、
前記業務管理端末は、
前記審査状況情報を受信する第１受信手段と、
前記審査状況情報に基づいて、前記事故案件に係る協定の成立の是非を判定する判定手段と、
前記判定手段の判定の結果、前記事故案件に係る協定が成立している場合、前記事故案件に関する事故案件情報に基づいて、該事故案件での修理に必要な修理用部品の発注先となる発注先端末を決定する決定手段と、
前記ネットワークを介して、前記決定手段で決定された発注先端末へ、前記修理用部品の発注を依頼する発注依頼情報を送信する第２送信手段とを備え、
前記発注先端末は、
前記ネットワークを介して、前記発注依頼情報を受信する第２受信手段と
を備えることを特徴とする業務管理システム。
【請求項８】
修理業者が有する修理業者端末と、前記修理業者が修理用部品を発注する発注先業者が有する発注先端末と、保険業者が有する保険業者端末とネットワークを介して相互に接続され、これらの業者間で執り行われる業務を管理する業務管理装置の制御方法であって、
前記ネットワークを介して、修理対象の事故案件の審査状況を示す審査状況情報を前記保険業者端末から受信する受信工程と、
前記審査状況情報に基づいて、前記事故案件に係る協定の成立の是非を判定する判定工程と、
前記判定工程の判定の結果、前記事故案件に係る協定が成立している場合、前記事故案件に関する事故案件情報に基づいて、該事故案件での修理に必要な修理用部品の発注先となる発注先端末を決定する決定工程と、
前記ネットワークを介して、前記決定工程で決定された発注先端末へ、前記修理用部品の発注を依頼する発注依頼情報を送信する送信工程と
を備えることを特徴とする業務管理装置の制御方法。
【請求項９】
修理業者が有する修理業者端末と、前記修理業者が修理用部品を発注する発注先業者が有する発注先端末と、保険業者が有する保険業者端末とネットワークを介して相互に接続され、これらの業者間で執り行われる業務を管理する業務管理装置の制御を実現するプログラムであって、
前記ネットワークを介して、修理対象の事故案件の審査状況を示す審査状況情報を前記保険業者端末から受信する受信工程のプログラムコードと、
前記審査状況情報に基づいて、前記事故案件に係る協定の成立の是非を判定する判定工程のプログラムコードと、
前記判定工程の判定の結果、前記事故案件に係る協定が成立している場合、前記事故案件に関する事故案件情報に基づいて、該事故案件での修理に必要な修理用部品の発注先となる発注先端末を決定する決定工程のプログラムコードと、
前記ネットワークを介して、前記決定工程で決定された発注先端末へ、前記修理用部品の発注を依頼する発注依頼情報を送信する送信工程のプログラムコードと
を備えることを特徴とするプログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、業者が有する修理業者端末と、前記修理業者が修理用部品を発注する発注先業者が有する発注先端末と、保険業者が有する保険業者端末とネットワークを介して相互に接続され、これらの業者間で執り行われる業務を管理する業務管理装置及びその制御方法、業務管理システム、プログラムに関するものである。
【０００２】
【従来の技術】
特定の業務においては、多量の画像データとそれに関する添付書類データを管理する必要が生じる。例えば、修理業者側で事故車両の修理個所をデジタルカメラで撮影し（１事故案件あたり、２０枚程度）、その撮影された画像データに対し、見積ソフトで作成した見積ファイルを添付して、保険業者側に送信している。
【０００３】
保険業者側では、その事故案件の画像データと見積ファイルを受信して、画像データと見積ファイルの内容を確認し、見積が妥当である場合は、その事故案件に係る保険処理を合意する協定が成立する。一方、見積が妥当でない場合は、保険業者側の見積を示す等して修理業者に再見積を指示したり、保険業者の調査員が修理業者の修理工場に実際に現地調査に行く等して、見積の妥当性を再確認している。
【０００４】
また、このような環境において、協定成立後に事故車の修理状況を保険業者、修理業者、事故車の所有者が常時把握できる管理システムが提案されている（特許文献１）。
【０００５】
更に、修理に必要な部品の選定を迅速かつ効率的に行うために、保険業者は在庫検索を専門の検索業者に依頼し、専門の検索業者から検索結果を得ることができる検索システムが提案されている（特許文献２）。
【０００６】
【特許文献１】
特開２００１−２２９２３８
【特許文献２】
特開２００１−３５７１５０
【発明が解決しようとする課題】
しかしながら、上記の従来技術では、以下のような問題がある。
【０００７】
修理業者は協定にかかる審査の進捗が把握できず、進捗を把握するには確認する都度保険業者に電話やＦＡＸ、メールなどの手段を用いて確認をしなければならなかった。
【０００８】
また、上記の問題点のために、修理完了までの期間が正確に把握できないため、事故車の所有者に対しても正確な情報を随時伝えることができなかった。
【０００９】
さらに、協定成立したとしても、協定成立内容は修理業者が保険業者に提出した内容と変更が生じていることがあり、通知を受けた後に修理部品の確保を行わなければならないというような煩雑な作業があった。
【００１０】
特に、多くの修理業者では修理部品の管理は各修理業者に任されており、発注が必要となった時に各工場で発注表に発注品を記載し、発注先（部品業者）に発注を依頼していた。
【００１１】
本発明は上記の課題に鑑みてなされたものであり、複数種類の業者間で執り行われる業務を効率的に支援し、管理することができる業務管理装置及びその制御方法、業務管理システム、プログラムを提供することを目的とする。
【００１２】
【課題を解決するための手段】
上記の目的を達成するための本発明による業務管理装置は以下の構成を備える。即ち、
修理業者が有する修理業者端末と、前記修理業者が修理用部品を発注する発注先業者が有する発注先端末と、保険業者が有する保険業者端末とネットワークを介して相互に接続され、これらの業者間で執り行われる業務を管理する業務管理装置であって、
前記ネットワークを介して、修理対象の事故案件の審査状況を示す審査状況情報を前記保険業者端末から受信する受信手段と、
前記審査状況情報に基づいて、前記事故案件に係る協定の成立の是非を判定する判定手段と、
前記判定手段の判定の結果、前記事故案件に係る協定が成立している場合、前記事故案件に関する事故案件情報に基づいて、該事故案件での修理に必要な修理用部品の発注先となる発注先端末を決定する決定手段と、
前記ネットワークを介して、前記決定手段で決定された発注先端末へ、前記修理用部品の発注を依頼する発注依頼情報を送信する送信手段と
を備える。
【００１３】
また、好ましくは、前記修理業者が所有する修理用部品の在庫を管理する部品在庫データベースと、該修理業者の発注先を管理する発注先データベースを記憶する記憶手段と、
前記事故案件情報に基づいて、前記部品在庫データベースを参照して、該事故案件での修理に必要な修理用部品を検索する検索手段とを更に備え、
前記決定手段は、前記事故案件情報に基づいて、前記発注先データベースを参照して、前記検索手段で検索された修理用部品の発注先となる発注先端末を決定する。
【００１４】
また、好ましくは、前記発注先データベースは、修理業者毎の発注先を管理し、かつその発注先には優先度が設定されている。
【００１５】
また、好ましくは、前記ネットワークを介して、前記修理用部品を発注した場合の納品予定日を問い合わせるための納品予定日依頼情報を前記発注先端末へ送信する納品予定日依頼情報送信手段と、
前記ネットワークを介して、前記納品予定日依頼情報を送信した発注先端末から発注部品の納品予定日を示す納品予定日情報を受信する納品予定日情報受信手段と、
前記納品予定日情報に基づいて、前記修理用部品の発注先となる発注先端末を決定する発注先端末決定手段と
を更に備える。
【００１６】
また、好ましくは、前記ネットワークを介して、前記事故案件での修理に必要な修理用部品の発注に関する発注情報を前記修理業者端末へ送信する発注情報送信手段と
を更に備える。
【００１７】
また、好ましくは、前記発注情報を含む前記事故案件に係る審査状況を示す審査状況情報を生成する生成手段と
を更に備える。
【００１８】
上記の目的を達成するための本発明による業務管理システムは以下の構成を備える。即ち、
修理業者が有する修理業者端末と、前記修理業者が修理用部品を発注する発注先業者が有する発注先端末と、保険業者が有する保険業者端末と、これらの業者間で執り行われる業務を管理する業務管理端末とがネットワークを介して相互に接続されて構成される業務管理システムであって、
前記保険業者端末は、
前記ネットワークを介して、修理対象の事故案件の審査状況を示す審査状況情報を送信する第１送信手段とを備え、
前記業務管理端末は、
前記審査状況情報を受信する第１受信手段と、
前記審査状況情報に基づいて、前記事故案件に係る協定の成立の是非を判定する判定手段と、
前記判定手段の判定の結果、前記事故案件に係る協定が成立している場合、前記事故案件に関する事故案件情報に基づいて、該事故案件での修理に必要な修理用部品の発注先となる発注先端末を決定する決定手段と、
前記ネットワークを介して、前記決定手段で決定された発注先端末へ、前記修理用部品の発注を依頼する発注依頼情報を送信する第２送信手段とを備え、
前記発注先端末は、
前記ネットワークを介して、前記発注依頼情報を受信する第２受信手段と
を備える。
【００１９】
上記の目的を達成するための本発明による業務管理装置の制御方法は以下の構成を備える。即ち、
修理業者が有する修理業者端末と、前記修理業者が修理用部品を発注する発注先業者が有する発注先端末と、保険業者が有する保険業者端末とネットワークを介して相互に接続され、これらの業者間で執り行われる業務を管理する業務管理装置の制御方法であって、
前記ネットワークを介して、修理対象の事故案件の審査状況を示す審査状況情報を前記保険業者端末から受信する受信工程と、
前記審査状況情報に基づいて、前記事故案件に係る協定の成立の是非を判定する判定工程と、
前記判定工程の判定の結果、前記事故案件に係る協定が成立している場合、前記事故案件に関する事故案件情報に基づいて、該事故案件での修理に必要な修理用部品の発注先となる発注先端末を決定する決定工程と、
前記ネットワークを介して、前記決定工程で決定された発注先端末へ、前記修理用部品の発注を依頼する発注依頼情報を送信する送信工程と
を備える。
【００２０】
上記の目的を達成するための本発明によるプログラムは以下の構成を備える。即ち、
修理業者が有する修理業者端末と、前記修理業者が修理用部品を発注する発注先業者が有する発注先端末と、保険業者が有する保険業者端末とネットワークを介して相互に接続され、これらの業者間で執り行われる業務を管理する業務管理装置の制御を実現するプログラムであって、
前記ネットワークを介して、修理対象の事故案件の審査状況を示す審査状況情報を前記保険業者端末から受信する受信工程のプログラムコードと、
前記審査状況情報に基づいて、前記事故案件に係る協定の成立の是非を判定する判定工程のプログラムコードと、
前記判定工程の判定の結果、前記事故案件に係る協定が成立している場合、前記事故案件に関する事故案件情報に基づいて、該事故案件での修理に必要な修理用部品の発注先となる発注先端末を決定する決定工程のプログラムコードと、
前記ネットワークを介して、前記決定工程で決定された発注先端末へ、前記修理用部品の発注を依頼する発注依頼情報を送信する送信工程のプログラムコードと
を備える。
【００２１】
【発明の実施の形態】
以下、図面を参照して、本発明の実施形態を詳細に説明する。
【００２２】
尚、以下の説明において、「サーバ」とは、ＷＷＷシステムにおいてＨＴＭＬ文書や画像などの情報を蓄積しておき、Ｗｅｂブラウザなどのクライアントソフトウェアからの要求を受けてインターネットなどのネットワークを通じて情報送信を行うＷｅｂサーバ（ウェブサーバ）や、ネットワークを通じてユーザからの要求を受けて、データベースシステムなどの処理に橋渡しを行う機能を備えたアプリケーションサーバ（または、Ｗｅｂアプリケーションサーバ）を意味するものである。
【００２３】
また、「クライアント」とは、ネットワークにおいてサーバの提供する機能やデータを利用するコンピュータ、およびソフトウェアを意味するものである。このクライアントとしては、本実施形態では、例えば、ネットワークに接続された修理業者が有する修理業者端末、保険業者の顧客窓口業務等を行うサービスセンタ（事業所、営業店、代理店）が有するサービスセンタ端末等のコンピュータ、修理業者が修理用部品を発注する発注先が有する発注先端末およびコンピュータ上で動作するＷｅｂブラウザ、ビューワ等が該当する。
【００２４】
また、以下に説明する本発明の実施形態では、例えば、インターネットを介するＷｅｂ環境下で、修理業者と保険業者との間の修理費用に係る協定の支援と、修理業者と発注先との間の発注の支援を実現する例を挙げて説明するが、本発明はこのような構成に限定されるものではない。つまり、サーバが提供するサービスに係る処理を実行するための各種操作画面がクライアントのブラウザ（ビューワ）上で表示可能な形態を提供できるようなコンピュータネットワーク環境であれば、本発明を適用することができる。
【００２５】
＜実施形態１＞
図１は本発明の実施形態１の業務管理システムの構成を示す図である。
【００２６】
実施形態１の業務管理システムは、車両の修理工場等の各修理業者と、損保会社、その販売店や支店や営業所等を含む保険業者、ネットワーク事業者（ＩＳＰ、ＡＳＰ等）、修理業者が修理用部品を発注する発注先（部品業者）それぞれが所有する端末間をネットワーク４００を介して相互に接続し、特に、修理業者と保険業者間での修理費用に係る協定と、修理業者と発注先との間の発注をネットワーク事業者によって支援・管理するものである。
【００２７】
尚、図１のネットワーク４００上に接続される各種端末の構成は一例であり、用途や目的に応じて様々な構成例があることは言うまでもない。
【００２８】
保険業者は保険業者サーバ１００を有し、ネットワーク４００を介して修理業者端末２００、ネットワーク事業者サーバ５００、ＳＣ（サービスセンタ）端末３００、発注先端末６００から送信されてくるデータを受信し、その受信したデータの内容に基づいて、データを記憶、管理する。また、保険業者が有する保険業者端末は、保険業者サーバ１００、端末１０１、ＳＣ端末３００となるが、特に、実施形態１では、ＳＣ端末３００で修理費用に係る協定を実行する例として説明するが、保険業者サーバ１００、端末１０１上で修理費用に係る協定を実行することも可能である。
【００２９】
尚、保険業者サーバ１００は、特定の位置に配置される必要はなく、保険業者サーバ１００とＬＡＮを介して接続された端末群１０１からアクセス可能であれば、ネットワーク４００上の任意の位置で接続されていれば良い。
【００３０】
修理業者はネットワーク４００を介してネットワーク事業者サーバ５００や保険業者サーバ１００に接続する修理業者端末２００を有し、デジタルカメラ２０１より入力した事故案件毎の複数の事故車両の画像データ（事故画像）と、それに事故案件の修理に必要な見積ファイル、各事故案件に係る事故情報等を事故案件情報としてネットワーク事業者サーバ５００へ送信する。また、発注先端末６００へ修理用部品の発注依頼や発注内容、納品日等を含む発注情報を送信することができるが、特に、実施形態１では、この発注に係る処理をネットワーク事業者サーバ５００が代行する。
【００３１】
これにより、修理業者端末２００は、ネットワーク事業者サーバ５００より事故案件情報に対する協定成立状況や、発注状況に関する情報を受信することができる。
【００３２】
修理業者端末２００は、デジタルカメラ、デジタルビデオカメラ、カメラ機能付き携帯端末（携帯電話、ＰＤＡ等）、スキャナ等の画像入力装置２０１が接続可能である。また、この画像入力装置２０１には、その位置を特定するためのＧＰＳ機能を有しており、ＧＰＳ衛星２０２より被写体や画像入力装置２０１自身の位置情報を取得することが可能である。
【００３３】
尚、画像入力装置２０１と修理業者端末２００間の画像の通信は、有線または無線通信のどちらでも良く、あるいはＰＣカードやＭＯ等の記憶媒体を利用しても良い。また、画像入力装置２０１は、ＧＰＳ機能により被写体や画像入力装置２０１自身の位置情報を取得しているが、位置情報を取得できるものであれば良く、これに限定されない。例えば、撮影時にその撮影位置が画像入力装置２０１のユーザインタフェースを介して入力された情報から位置情報を取得するようにしても良い。
【００３４】
ネットワーク事業者はネットワーク事業者サーバ５００を有し、修理業者と保険業者間での修理費用に係る協定の支援・管理サービスを提供する。加えて、修理業者と発注先間の発注に係る支援・管理サービスを提供する。
【００３５】
ネットワーク事業者サーバ５００は、例えば、修理業者端末２００から事故案件情報（事故画像、それに添付された見積ファイル、事故情報等）を受信した場合は、その受信した事故案件情報中の事故画像に基づいて、その事故画像の信頼性を評価する。そして、その評価結果、その評価結果に基づく事故案件に係る審査方法を示す審査項目（審査項目情報）を含めた事故案件情報を、指定のＳＣ端末３００へ送信する。また、これらの事故案件情報は、用途や目的に応じて、ネットワーク事業者サーバ５００内のデータベースで登録し、管理されても良い。
【００３６】
尚、この事故案件情報を管理するデータベースでは、事故画像及びそれに添付されたあるいは別途作成された見積ファイルを修理業者毎に管理するために、修理業者毎の修理業者別フォルダを有している。また、事故画像や見積ファイルはデータベースではなく、フォルダ単位で管理しても良い。
【００３７】
また、ネットワーク事業者サーバ５００は、各修理業者端末２００を識別するための情報（電話番号、コンピュータ名（ホスト名））を管理する修理業者端末情報テーブルを有している。
【００３８】
そして、ネットワーク事業者サーバ５００は、ある修理業者端末２００から事故案件情報の送信要求があると、修理業者端末情報テーブルを参照して、その送信要求元を判定し、送信されてくる事故案件情報を自動的に対応するフォルダへ登録する。この判定は、例えば、送信要求元がダイアルアップでネットワーク事業者サーバ５００への接続要求を行っている場合はその発信電話番号、また、ネットワーク接続である場合はその接続要求を行う端末のコンピュータ名（ホスト名）あるいは予め取り決めた認証番号、あるいはネットワークアダプタのＭＡＣアドレス等で判定する。
【００３９】
更に、ネットワーク事業者サーバ５００は、各発注先端末６００を識別するための情報（電話番号、コンピュータ名（ホスト名））を管理する発注先端末情報テーブルを有している。そして、ネットワーク事業者サーバ５００は、事故案件情報に対する協定が成立した場合に受信する協定成立情報に基づいて、発注先端末情報テーブルを参照し、その事故案件情報に対する発注情報を生成して、発注先端末６００へ送信する。また、この発注情報に対する発注部品の納品に関する納品情報（納品日、納品予定日等）を発注先端末６００より受信すると、それを修理業者端末２００へ送信する。
【００４０】
発注先はネットワーク４００を介してネットワーク事業者サーバ５００や修理業者端末１００に接続する発注先端末６００を有し、特に、ネットワーク事業者サーバ５００から発注情報を受信し、その発注情報に基づいて発注部品に対する納品情報をネットワーク事業者サーバ５００へ送信する。
【００４１】
保険業者のＳＣはネットワーク４００を介してネットワーク事業者サーバ５００や保険業者サーバ１００に接続するＳＣ端末３００を有し、特に、ネットワーク事業者サーバ５００から事故案件情報を受信し、その事故案件情報に基づいて修理業者との協定に係る審査等の各種処理を実行する。
【００４２】
尚、保険業者サーバ１００とＬＡＮを介して接続する端末群１０１も、ＳＣ端末３００と同様の機能を有し、必要に応じて、ネットワーク事業者サーバ５００から事故案件情報を受信し、その事故案件情報に基づいて修理業者との協定に係る審査等の処理を実行する。
【００４３】
４００はネットワークであり、典型的にはインターネットやＬＡＮやＷＡＮや電話回線、専用デジタル回線、ＡＴＭやフレームリレー回線、通信衛星回線、ケーブルテレビ回線、データ放送用無線回線等のいずれか、またはこれらの組み合わせにより実現されるいわゆる通信ネットワークであり、データの送受信が可能であれば良い。
【００４４】
また、ネットワーク４００間を介する各種端末間の通信は、安全性を考慮して、ＳＳＬ等のセキュリティ通信を実行することが望ましい。加えて、このセキュリティ通信は、通信環境に基づいて、適宜設定しても良い。例えば、ストック型ではＳＳＬを、転送型ではＶＰＮを使用しても良い。
【００４５】
次に、図１の保険業者サーバ１００、端末１０１、修理業者端末２００、ＳＣ端末３００、ネットワーク事業者サーバ５００、発注先端末６００の各種端末のハードウェア構成について、図２を用いて説明する。
【００４６】
図２は本発明の実施形態１の各種端末のハードウェア構成を示す図である。
【００４７】
図２において、ＣＰＵ２０１、ＲＡＭ２０２、ＲＯＭ２０３、ＬＡＮアダプタ２０４、ビデオアダプタ２０５、画像入力Ｉ／Ｆ２０６、キーボード２０７、マウス２０８、ハードディスク２０９、ＣＤ−ＲＯＭドライブ２１１はそれぞれシステムバス２１０を介して互いに接続されている。システムバス２１０は、例えば、ＰＣＩバス、ＡＧＰバス、メモリバス等を意味する。また、図２では、各バス間の接続用チップやキーボードインタフェースやいわゆるＳＣＳＩやＡＴＡＰＩのような入出力用インタフェースは省略されている。
【００４８】
尚、画像入力Ｉ／Ｆ２０６は、特に、修理業者端末２００に搭載されているものであり、外部機器としての画像入力装置２０１間の画像入力を制御する。
【００４９】
ＣＰＵ２０１は四則演算や比較演算等の各種の演算や、ハードウェアやソフトウェアの制御を行う。ＲＡＭ２０２には、ハードディスク２０９やＣＤ−ＲＯＭドライブ２１１に装着されたＣＤ−ＲＯＭやＣＤ−Ｒ等の記憶媒体から読み出されたオペレーションシステムのプログラムやアプリケーションプログラム等が記憶され、これらはＣＰＵ２０１の制御の元に実行される。
【００５０】
ＲＯＭ２０３にはオペレーションシステムと協働してハードディスク等への入出力を司るいわゆるＢＩＯＳ等が記憶される。ＬＡＮアダプタ２０４は、ＣＰＵ２０１によって制御されるオペレーションシステムの通信プログラムと協働してネットワーク４００を介した外部との通信を行う。ビデオアダプタ２０５はディスプレイ装置に出力する画像信号を生成し、キーボード２０７やマウス２０８は各種指示を入力するために用いられる。
【００５１】
ハードディスク２０９はオペレーションシステムや以下に示す各端末で実行されるフローチャートのステップに対応する部分を実行するためのアプリケーションプログラムや、各種データを記憶している。また、本発明で説明される各種データベースやテーブルも記憶している。
【００５２】
ＣＤ−ＲＯＭドライブ２１１はＣＤ−ＲＯＭやＣＤ−ＲやＣＤ−Ｒ／Ｗ等の記憶媒体を装着してアプリケーションプログラムをハードディスク２０９にインストールするのに用いる。尚、ＣＤ−ＲＯＭドライブの代わりにＣＤ−ＲドライブやＣＤ−Ｒ／ＷドライブやＭＯドライブ等を用いても良いのは言うまでもない。
【００５３】
まず、実施形態１の業務管理システムで実行される処理の概要について、図３を用いて説明する。
【００５４】
図３は本発明の実施形態１の業務管理システムで実行される処理の概要を示すフローチャートである。
【００５５】
まず、ステップＳ１０１で、画像入力装置２０１は、修理対象である事故車両の複数の修理箇所の画像（事故画像）を撮影する。ステップＳ１０２で、事故画像を修理業者端末２００へ出力する。
【００５６】
ステップＳ１０３で、修理業者端末２００は、画像入力装置２０１より事故画像を入力する。この入力した事故画像はハードディスク２８に記憶される。ステップＳ１０４で、事故画像に関する事故情報を入力するための事故情報入力画面９００（図９）を表示して、この事故情報入力画面９００を介して事故情報を入力する。
【００５７】
ここで、図９の事故情報入力画面９００について説明する。
【００５８】
図９は本発明の実施形態１の事故情報入力画面の一例を示す図である。
【００５９】
図９の事故情報入力画面９００において、９０１は各種事故情報を入力するための入力フィールドである。事故情報としては、例えば、事故番号、事故発生日、立会日、顧客名、車両の登録番号、保険業者名、証券番号、自動車名、修理業者名、送信元名（事故情報の送信元）等がある。
【００６０】
９０２はＯＫボタンであり、入力フィールド９０１で入力されている事故情報の入力を確定する場合に押下する。このＯＫボタン９０２が押下されると、入力フィールド９０１上の事故情報が修理業者端末２００のハードディスク２８に記憶される。９０３はキャンセルボタンであり、入力フィールド９０１上の入力をキャンセルする場合に押下する。
【００６１】
図３の説明に戻る。
【００６２】
ステップＳ１０４において、事故情報の入力後、送信対象の事故画像を選択するための送信画像設定画面１０００（図１０）を表示する。
【００６３】
ここで、図１０の送信画像設定画面１０００について説明する。
【００６４】
図１０は本発明の実施形態１の送信画像設定画面の一例を示す図である。
【００６５】
図１０の送信画像設定画面１０００において、１００１は送信対象の事故画像を選択するための選択フィールドである。この選択フィールド１００１中の参照ボタンを押下すると、ハードディスク２８に記憶されている事故画像群を選択するための選択画面が表示され、その選択画面から所望の事故画像を選択することができる。１００２は送信対象の事故画像に添付する添付ファイルを選択するための選択フィールドである。この選択フィールド１００２中の参照ボタンを押下すると、ハードディスク２８に記憶されているファイル群を選択するための選択画面が表示され、その選択画面から所望のファイルを選択することができる。
【００６６】
尚、この添付ファイルとは、例えば、事故画像に対応する事故車両を修理するために必要な修理費用の見積ファイルである。
【００６７】
１００３は各選択フィールド１００１や１００２で選択された画像や添付ファイルの送信を指示するための送信ボタンである。１００４は各選択フィールド１００１や１００２で選択された画像や添付ファイルの選択をキャンセルするためのキャンセルボタンである。
【００６８】
図３の説明に戻る。
【００６９】
ステップＳ１０４において、送信画像設定画面１０００上の送信ボタン１００３が押下されると、送信画像設定画面１０００で選択された事故画像、添付ファイル及び対応する事故情報を事故案件情報としてネットワーク事業者サーバ５００へ送信する。
【００７０】
尚、この送信は、修理業者端末２００からの指示に基づいてデータ送信を行うプッシュ型でも、ネットワーク事業者サーバ５００からの指示に基づいてデータ送信を行うプル型のどちらでもあっても良く、その送信タイミング（１日１回、１時間毎等）や送信単位（事故案件単位、保険業者単位等）は用途や目的に応じて適宜設定可能である。
【００７１】
また、事故画像は、修理業者端末２００よりネットワーク４００を介して外部端末に送信される画像である。そのため、事故画像には、その送信経路での改竄を防止するために、必要に応じて電子透かし情報が付加される。この電子透かし情報としては、画像入力装置２０１に対する撮影者、撮影日時、位置情報、撮影方向等の撮影情報が含まれる。また、この電子透かし情報のフォーマットは、予めネットワーク事業者サーバ５００で定義されている専用フォーマットものであり、この専用フォーマットでの電子透かし情報を生成する画像入力装置２０１が修理業者へ提供されることになる。
【００７２】
つまり、この画像入力装置２０１以外の画像入力装置を使用して電子透かし情報を生成したり、専用フォーマット以外のフォーマットで生成された電子透かし情報を不正電子透かし情報となる。
【００７３】
また、修理業者端末２００において、ＳＣ端末３００で通常実行される各事故案件に関する案件データを作成するようにしても良い。この案件データを作成するための案件作成画面１１００について、図１１を用いて説明する。
【００７４】
図１１は本発明の実施形態１の案件作成画面の一例を示す図である。
【００７５】
図１１の案件作成画面１１００において、１１０１は、ハードディスク２８に記憶されている１事故案件に対応する事故画像のサムネール画像の表示フィールドである。１１０２は、添付ファイルのサムネール画像の表示フィールドである。１１０３は、事故情報入力画面９００（図９）で入力された事故情報の表示／入力フィールドである。また、１１０４は各種機能ボタンであり、事故画像の選択機能、事故画像の編集機能、添付書類の選択機能、報告書作成機能、データ送信機能等のボタンが構成されている。
【００７６】
これらのボタンの内、特に、このデータ送信機能を実現するボタン（送信ボタン）は、アドレス帳で送信先名称と送信方式（メール／Ｗｅｂ／標準フォーマット等）を設定しておき、送信ボタン押下で送信先選択画面を表示して、選択された送信先に設定されている送信方式で送信することが可能である。
【００７７】
このように、案件作成画面１１００は、事故情報入力画面９００や送信画像設定画面１０００で実現される機能を、１つの画面に集約して実現できるように構成されている。
【００７８】
図３の説明に戻る。
【００７９】
次に、ステップＳ１０５で、ネットワーク事業者サーバ５００は、修理業者端末２００より事故案件情報を受信する。ステップＳ１０６で、事故の審査を行うＳＣ端末３００を決定する。但し、このステップＳ１０６は、ステップＳ１０９の後に実行しても良い。
【００８０】
尚、このステップＳ１０６におけるＳＣ端末の決定は、各ＳＣ端末３００の事故案件未処理数を事前に取得しておき、例えば、未処理数が少ないＳＣ端末３００に送信する。これは、具体的には、事故案件情報中の送信ＩＤ・事故番号・保険業者名・登録番号等をデータベースに突き合わせることで行われる。
【００８１】
あるいは、ネットワーク事業者サーバ５００に事故車の車種に応じて最適のＳＣ端末を選択するためのテーブルを更に備えて、当該テーブルに地域別車種別に修理内容を判定する資格を有する担当者のＳＣ端末を記憶させても良い。また、ネットワーク事業者サーバ５００に修理業者に応じて、ＳＣ端末を選択するためのテーブルを更に備えておいても良い。
【００８２】
次に、ステップＳ１０７で、ステップＳ１０５で受信した事故案件情報（事故画像）の信頼度を評価するための信頼度評価処理を実行する。尚、この信頼度評価処理の詳細については、図４を用いて後述する。次に、ステップＳ１０９で、評価された信頼度に基づいて、事故案件に係る審査方法を示す審査項目（審査項目情報）を決定する審査項目決定処理を実行する。尚、この審査項目決定処理の詳細は、図５を用いて後述する。
【００８３】
そして、この審査項目決定処理後、ステップＳ１０７及びＳ１０９の処理結果の信頼度情報と審査項目情報を含めた事故案件情報をＳＣ端末３００へ送信する。また、これと並行して、ＳＣ端末３００を管理する保険業者の保険業者サーバ１００へ事故案件情報を送信しても良い。
【００８４】
尚、この送信は、修理業者端末２００からの指示に基づいてデータ送信を行うプル型でも、ネットワーク事業者サーバ５００からの指示に基づいてデータ送信を行うプッシュ型のどちらでもあっても良く、その送信タイミング（１日１回、１時間毎等）や送信単位（事故案件単位、保険業者単位等）は用途や目的に応じて適宜設定可能である。
【００８５】
次に、ステップＳ１０８で、ＳＣ端末３００は、ネットワーク事業者サーバ５００より処理対象である事故案件情報（事故画像、添付ファイル及び対応する事故情報、信頼度情報、審査項目情報等）を受信する。この受信の際には、ＳＣ端末３００には、処理対象画像の着信を通知する通知画面１２００（図１２）が表示される。この通知画面１２００は、すべてのＳＣ端末３００に表示されても良いし、指定のＳＣ端末３００のみに通知されても良い。
【００８６】
ステップＳ１１１で、審査項目の判断を行い、審査指示を行うための審査処理を実行する。尚、この審査処理の詳細は、図６を用いて説明する。そして、ＳＣ端末３００は、この審査処理によって生成される審査状況情報をネットワーク事業者サーバ５００へ送信する。
【００８７】
次に、ステップＳ１１２で、ネットワーク事業者サーバ５００は、ＳＣ端末３００より審査状況情報を受信する。ステップＳ１１３で、受信した審査状況情報中に協定成立情報があるか否かを判定する。協定成立情報がない場合（ステップＳ１１３でＮＯ）、ステップＳ１１４へ進み、審査状況情報を更新し、その更新した審査状況情報を修理業者端末２００へ送信する。
【００８８】
尚、審査状況情報は、事故案件情報とそれに関する審査状況（協定成立／不成立、現地調査、再審査、審査中、未審査、再審査等）、発注部品の発注状況等を管理する情報であり、ネットワーク事業者サーバ５００のハードディスク２８内の審査状況情報テーブル（図１７）で管理される。尚、図１７に示す審査状況情報テーブルは、１つの事故案件情報に対する審査状況情報を示すものであり、実際には、各事故案件情報に対して審査状況情報が存在している。
【００８９】
そして、ステップＳ１１５で、修理業者端末２００は、ネットワーク事業者サーバ５００より審査状況情報を受信する。これにより、修理業者端末２００では、審査状況情報に基づく審査状況画面１３００（図１３）が表示される。
【００９０】
ここで、図１３の審査状況画面１３００について説明する。
【００９１】
図１３は本発明の実施形態１の審査状況画面の一例を示す図である。
【００９２】
図１３の審査状況画面１３００において、１３０１は事故案件情報毎の審査状況情報を表示する表示フィールドであり、審査状況情報テーブルに基づいて生成される。図１３の表示フィールド１３０１の表示項目としては、審査状況、協定成立日、送信日、登録番号、顧客名、保険業者名、発注情報となっているが、これに限定されず、審査状況情報テーブルから取得可能な情報であれば、どのような構成であっても良い。
【００９３】
１３０２は協定が成立した事故案件情報に対する修理用部品の発注内容を確認する詳細ボタンであり、審査状況項目で表示される審査状況が「協定成立」となっている場合に、発注情報項目に表示される。
【００９４】
尚、この審査状況画面１３００の更新は、ネットワーク事業者サーバ５００からの指示あるいは修理業者端末２００からの指示に基づいて実行することができる。
【００９５】
また、修理業者端末２００で詳細ボタン１３０２が押下された場合には、その詳細ボタン１３０２に対応する事故案件情報に対する発注内容を示す発注情報（発注部品及びその納品日等）が、ネットワーク事業者サーバ５００から修理業者端末２００へ送信される。これにより、修理業者端末２００は発注内容を確認することができる。
【００９６】
一方、ステップＳ１１３において、審査状況情報中に協定成立情報がある場合（ステップＳ１１３でＹＥＳ）、ステップＳ１１６に進み、審査状況情報を更新し、その更新した審査状況情報を修理業者端末２００へ送信する。また、ネットワーク事業者サーバ５００では、修理業者端末２００と同様に、審査状況画面１３００を表示することができる。そして、ネットワーク事業者サーバ５００は、この審査状況情報及び見積ファイルに基づいて、協定が成立した事故案件情報に対する発注情報を生成し、発注先端末６００へ送信する発注処理を実行する。
【００９７】
尚、この発注処理の詳細については、２種類の方法が想定され、１つ目の方法は、図７を用いて後述する。また、２つ目の方法は、実施形態２として図８を用いて後述する。
【００９８】
ステップＳ１１７で、発注先端末６００は、発注情報をネットワーク事業者サーバ５００より受信する。そして、受信した発注情報に基づいて、発注部品の納品日等を含む納品情報をネットワーク事業者サーバ５００へ送信する。
【００９９】
次に、図３のステップＳ１０７の信頼度評価処理の詳細について、図４を用いて説明する。
【０１００】
図４は本発明の実施形態１の信頼度評価処理の詳細を示すフローチャートである。
【０１０１】
ステップＳ２０１で、処理対象の事故画像に電子透かし情報が入っているか否かを判定する。電子透かし情報が入っている場合（ステップＳ２０１でＹＥＳ）、ステップＳ２０２へ進む。一方、電子透かし情報が入っていない場合（ステップＳ２０１でＮＯ）、ステップＳ２０５へ進む。
【０１０２】
ステップＳ２０１において、電子透かし情報がある場合、ステップＳ２０２で、その電子透かし情報が不正電子透かし情報であるか否かを判定する。不正電子透かし情報である場合（ステップＳ２０２でＹＥＳ）、ステップＳ２０３へ進む。一方、不正電子透かし情報でない場合（ステップＳ２０２でＮＯ）、ステップＳ２０４へ進む。
【０１０３】
ステップＳ２０２において、不正電子透かし情報である場合、ステップＳ２０３で、処理対象の事故画像の送信元である修理業者がブラックリスト（ＢＬ）に登録されているＢＬ修理業者であるか否かを判定する。この判定は、例えば、ハードディスク２８に記憶されているブラックリストテーブル（図１８）を参照して行う。判定の結果、ＢＬ修理業者である場合（ステップＳ２０３でＹＥＳ）、ステップＳ２０６へ進み、処理対象の事故画像の信頼度を信頼度０に設定する。一方、ＢＬ修理業者でない場合（ステップＳ２０３でＮＯ）、ステップＳ２０７へ進み、処理対象の事故画像の信頼度を信頼度１に設定する。
【０１０４】
尚、図１８のブラックリストテーブルは、通常、保険業者から提供されるものであり、図１８では、単に、ＢＬ修理業者を列挙している構成であるが、保険業者毎のＢＬ修理業者を管理するようにしても良い。また、ブラックリストテーブルは、ネットワーク事業者サーバ５００で管理されている必要はなく、各保険業者サーバ５００で管理しておき、これをネットワーク事業者サーバ５００が必要に応じて参照するような構成であっても良い。
【０１０５】
ステップＳ２０２において、不正電子透かし情報でない場合、ステップＳ２０４で、処理対象の事故画像の送信元である修理業者がＢＬ修理業者であるか否かを判定する。ＢＬ修理業者である場合（ステップＳ２０４でＹＥＳ）、ステップＳ２０８へ進み、処理対象の事故画像の信頼度を信頼度４に設定する。一方、ＢＬ修理業者でない場合（ステップＳ２０４でＮＯ）、ステップＳ２０９へ進み、処理対象の事故画像の信頼度を信頼度５に設定する。
【０１０６】
ステップＳ２０１において、電子透かし情報がない場合、ステップＳ２０５で、処理対象の事故画像の送信元である修理業者がＢＬ修理業者であるか否かを判定する。ＢＬ修理業者である場合（ステップＳ２０５でＹＥＳ）、ステップＳ２１０へ進み、処理対象の事故画像の信頼度を信頼度２に設定する。一方、ＢＬ修理業者でない場合（ステップＳ２０５でＮＯ）、ステップＳ２１１へ進み、処理対象の事故画像の信頼度を信頼度３に設定する。
【０１０７】
以上のようにして、処理対象の事故画像の信頼度が設定される。また、事故案件には、通常、複数の事故画像が存在するので、各事故画像に信頼度が設定されることになる。そのため、最終的な事故案件に係る信頼度は、その事故案件の各事故画像の信頼度の内、最低の信頼度を採用する。また、各事故画像の信頼度の平均を事故案件の信頼度としても良い。
【０１０８】
次に、図３のステップＳ１０９の審査項目決定処理の詳細について、図５を用いて説明する。
【０１０９】
図５は本発明の実施形態１の審査項目決定処理の詳細を示すフローチャートである。
【０１１０】
ステップＳ３０１で、信頼度評価処理で評価された信頼度が信頼度４以上であるか否かを判定する。信頼度４以上である場合（ステップＳ３０１でＹＥＳ）、ステップＳ３０３へ進み、審査項目情報として画像審査を設定する。一方、信頼度４未満である場合（ステップＳ３０１でＮＯ）、ステップＳ３０２に進む。
【０１１１】
ステップＳ３０２で、信頼度が信頼度３であるか否かを判定する。信頼度３である場合（ステップＳ３０２でＹＥＳ）、審査項目情報を画像審査及び現地調査に設定する。一方、信頼度３でない場合（ステップＳ３０２でＮＯ）、ステップＳ３０５へ進み、審査項目情報を現地調査に設定する。
【０１１２】
尚、この審査項目情報の設定は、例えば、図１９に示すような、信頼度とそれに対応する審査項目情報を管理する審査項目情報設定テーブルを参照して行っても良い。この審査項目情報設定テーブルは、ハードディスク２８に記憶される。
【０１１３】
次に、図３のステップＳ１１１の審査処理の詳細について、図６を用いて説明する。
【０１１４】
図６は本発明の実施形態１の審査処理の詳細を示すフローチャートである。
【０１１５】
まず、ステップＳ４０１で、審査開始指示の有無を判定する。尚、審査指示の有無の判定は、通知画面１２００（図１２）上の作業開始ボタンの押下の有無で判定するか、受信案件リスト画面１５００（図１４）で表示される事故案件情報から所望の事故案件情報の選択の有無で判定する。
【０１１６】
この受信案件リスト画面１５００では、未処理（受信案件）の事故案件情報や、ＳＣ端末３００（アジャスタ）別の事故案件情報等のカテゴリ別に事故案件情報を閲覧できるように構成されている。
【０１１７】
審査開始指示がない場合（ステップＳ４０１でＮＯ）、審査開始指示があるまで待機する。一方、審査開始指示がある場合（ステップＳ４０１でＹＥＳ）、案件作成画面１６００（図１５）が表示される。尚、該案件作成画面１６００（図１５）は、１２００（図１２）上の作業開始ボタンで作業開始が行われた場合、一度受信案件リスト画面１５００（図１４）で表示された後に表示させるようにしても良い。
【０１１８】
この案件作成画面１６００は、上述の案件作成画面１１００（図１１）と同様のものであるが、案件作成画面１６００では、案件作成画面１１００の構成に加えて、ネットワーク事業者サーバ５００で評価された信頼度情報（１６０１）が表示される。また、この案件作成画面１６００で表示される表示内容に基づいて、最終的な審査項目を決定するための審査ボタン１６０２を含んでいる。
【０１１９】
この審査ボタン１６０２が押下されると、審査結果選択画面１７００（図１６）が表示される。この審査結果選択画面１７００は、画像審査による協定の成立／不成立、再審査を選択するための画面である。そして、確定ボタンが押下されると、この選択状況に応じて、協定の成立／不成立、再審査を示す情報が出力される。また、審査ボタン１６０２が押下された時点で、審査中であることを示す審査中情報が生成される。
【０１２０】
図６の説明に戻る。
【０１２１】
ステップＳ４０２において、審査指示が画像審査指示の場合は、ステップＳ４０３へ進み、画像審査中であることを示す画像審査中情報を含む審査状況情報をネットワーク事業者サーバ５００へ送信する。次に、ステップＳ４０４で、協定成立の指示の有無を判定する。協定成立の指示の有無を判定する。この判定は、審査結果選択画面１７００に対する操作に基づいて判定する。
【０１２２】
協定成立の場合（ステップＳ４０４でＹＥＳ）、ステップＳ４０７に進む。一方、協定不成立の場合（ステップＳ４０４でＮＯ）、ステップＳ４１０に進み、再度、画像審査をやり直すための再審査情報を含む審査状況情報をネットワーク事業者サーバ５００へ送信する。この再審査情報は、画像審査に係る新たな情報を取得するために、例えば、修理業者に再度別の事故画像の送信を要求する情報である。
【０１２３】
また、ステップＳ４０２において、審査指示が画像審査および現地調査指示の場合は、ステップＳ４０５へ進み、画像審査中であることを示す画像審査中情報を含む審査状況情報をネットワーク事業者サーバ５００へ送信する。次に、ステップＳ４０６で、協定成立の指示の有無を判定する。協定不成立の場合（ステップＳ４０６でＮＯ）、ステップＳ４０８に進む。一方、協定成立の場合（ステップＳ４０６でＹＥＳ）、ステップＳ４０７に進む。
【０１２４】
尚、ステップＳ４０４及びＳ４０６の判定は、通常、ＳＣ端末３００のオペレータによって入力された情報に基づくものであるが、オペレータの上長等の承認者によって入力された情報に基づいても良い。
【０１２５】
ステップＳ４０７で、ＳＣ端末３００は、協定成立情報をネットワーク事業者サーバ５００へ送信する。この送信は、ＳＣ端末３００のオペレータの上長の承認が得られて、協定成立が確定された後に実行されても良い。
【０１２６】
更に、ステップＳ４０２において、審査指示が現地調査指示の場合、ステップＳ４０８へ進み、現地調査指示を示す現地調査情報を修理工場端末２００へ送信する。その後、ステップＳ４０９で、現地調査情報を送信した旨を通知する。尚、この通知手段は、メール・電話・ＦＡＸ・ＷＥＢ等の各種手段を利用することができる。また、現地調査情報を送信する際、ネットワーク事業者サーバ５００を介して送信されても良い。
【０１２７】
次に、図３のステップＳ１１６の発注処理の詳細について、図７を用いて説明する。
【０１２８】
図７は本発明の実施形態１の発注処理の詳細を示すフローチャートである。
【０１２９】
まず、ステップＳ６０１で、ネットワーク事業者サーバ５００は、事故案件情報に含まれる見積ファイル（図２０）とネットワーク事業者サーバ５００のハードディスク２８に記憶されている修理業者毎の部品在庫データベースに基づいて、発注が必要な修理用部品（発注部品）を検索する。つまり、見積ファイル中の部品の内、在庫数が０となっている部品を検索する。
【０１３０】
尚、部品在庫データベースは、修理業者毎に、修理業者が現在所有している修理用部品の在庫数を管理するものである。この在庫数の通知は、例えば、修理業者端末２００からネットワーク事業者サーバ５００へ在庫数情報を送信することで行っても良いし、メール・電話・ＦＡＸ・ＷＥＢ等の各種手段を利用しても良い。
【０１３１】
ステップＳ６０２で、発注部品の発注先を、ネットワーク事業者サーバ５００のハードディスク２８に記憶されている修理業者毎の発注先データベース（図２１）を参照して決定する。そして、その決定した発注先端末６００へ、発注部品を含む発注依頼情報を送信する。
【０１３２】
尚、図２１の発注先データベースは、修理業者毎に、発注先端末６００が優先度順に管理されている。そして、発注先端末６００の決定は、発注先データベースから、優先度が高い発注先端末６００を発注先として優先的に決定する。また、一旦決定した発注先への発注が不可能となった場合には、次の優先度の発注先端末６００を発注部品の発注先へ決定する。
【０１３３】
また、この発注先の決定方法は、用途や目的に応じて様々な方法を実行することができるが、例えば、各発注先への発注内容（発注回数、発注金額、発注部品数等）を別途管理しておき、その発注内容に基づいて発注先を決定しても良い。例えば、優先度の高い発注先に３回発注を行ったら、次の優先度の発注先へ１回発注行うようにしても良い。更に、複数の発注先に見積もりを依頼して最も安い価格を回答した発注先を選択しても良い。
【０１３４】
このように、各発注先に優先度を設定しておくことで、その優先度に基づいた発注先の決定を行うことができる。
【０１３５】
ステップＳ６０３で、発注依頼情報で依頼した発注部品の納品日を示す納品情報を発注先端末６００より受信する。尚、納品情報が示す納品日が未定である場合には、現在の発注先の次の優先度の発注先を、発注部品の発注先に再決定し、その発注先へ発注依頼情報を送信することもできる。
【０１３６】
ステップＳ６０６で、審査状況情報の更新を行う。この場合、更新される情報としては、発注先、発注部品、納品日等がある。
【０１３７】
ステップＳ６０４で、修理業者端末２００から発注情報の要求の有無を判定する。発注情報の要求がない場合（ステップＳ６０５でＮＯ）、発注情報の要求があるまで待機する。一方、発注情報の要求がある場合（ステップＳ６０５でＹＥＳ）、ステップＳ６０５に進み、修理業者端末２００に発注情報（図２２）を送信する。
【０１３８】
尚、図２２の発注情報は、発注部品、発注先、納品日となっているが、発注に関する情報であれば、これに限定されない。
【０１３９】
また、図７では、在庫数が０となっている部品を発注対象としたが、在庫数が所定数未満になっている部品も発注対象としても良い。また、その旨を修理業者端末２００に通知することで、部品の補充・発注を促すアナウンスを提供することができる。
【０１４０】
以上説明したように、実施形態１によれば、ネットワーク事業者サーバ５００では、修理業者と保険業者間の協定を支援し、特に、協定が成立する場合には、修理業者に代って修理用部品の発注を発注先端末６００に対して実行する。また、協定の成立状況や、修理用部品の発注状況を修理業者端末２００へ送信する。
【０１４１】
これにより、協定成立、協定成立後の修理用部品の発注までの進捗状況をリアルタイムに修理業者端末２００に提供することができる。
【０１４２】
また、修理業者は、協定成立、協定成立後の修理用部品の発注までの進捗状況を常時確認することができるので、事故車の修理時期の見通しを容易に立てることができるようになり、事故車の所有者に対しても現在の状況を正確に伝えることができる。
【０１４３】
更に、ネットワーク事業者サーバ５００で、各修理業者が所有する修理用部品の在庫管理を実行しているので、協定成立と同時に各修理業者の在庫を確認し、必要に応じて、修理業者に代わり部品の発注を実行することができる。
【０１４４】
また、発注の際には、その発注先に優先度をつけて管理しているので、各修理業者が通常使う納品業者や得意先業者に対して優先的に発注を実行することができる。
【０１４５】
＜実施形態２＞
実施形態１では、発注先データベースに登録されている発注先端末６００の優先度に基づいて、発注先を決定していたが、発注部品の納品予定日を発注可能な発注先すべてに問い合わせ、その納品予定日が最先となる発注先端末６００を発注先に決定するようにしても良い。
【０１４６】
以下、実施形態２の発注処理の詳細について、図８を用いて説明する。
【０１４７】
図８は本発明の実施形態２の発注処理の詳細を示すフローチャートである。
【０１４８】
尚、図８の処理において、図７と同じ処理には同一のステップ番号を付加し、その説明については省略する。
【０１４９】
ステップＳ７０２で、発注先データベース（図２１）を参照して、ステップＳ６０１で検索された発注部品を発注した場合の納品予定日を問い合わせるための納品予定日依頼情報を、発注可能なすべての発注先端末６００に送信する。尚、発注可能な発注先端末６００としては、修理業者があらかじめ指定している発注先端末であっても良いし、発注先データベースに登録されているすべての発注先端末であっても良い。
【０１５０】
ステップＳ７０３で、納品予定日依頼情報を送信した発注先から発注部品の納品予定日を示す納品予定日情報を発注先端末６００より受信する。
【０１５１】
ステップＳ７０４で、受信した納品予定日情報の内、納品日が最先の納品予定情報を送信した発注先端末６００を検索する。そして、検索された発注先へ発注依頼情報を送信する。尚、この発注予定情報の検索は、例えば、納品予定依頼情報を送信してから所定期間内に受信した発注予定情報に対して行う。
【０１５２】
但し、ステップＳ６０６では、審査状況情報として更新される情報としては、発注先、発注部品、納品予定日等となる。
【０１５３】
以上説明したように、実施形態２によれば、実施形態１で説明した効果に加えて、ネットワーク事業者サーバ５００は、発注の際、発注先に発注部品の納品予定日を確認し、その確認結果に基づいて、最終的に発注先が確定した場合には、その納品予定日を修理業者端末２００に提供することができるので、修理業者は、事故車の修理に取り掛かるまでの日数、修理完了日を容易に算出して事故車の持ち主に通知することができ、顧客の満足度を向上させることができる。
【０１５４】
また、ネットワーク事業者サーバ５００は、納品予定日情報に基づいて、一番早く納品できる発注先を選択して、その選択した発注先へ発注を行うので、修理完了までにかかる日数を短縮できる。これにより、修理業者の稼働率や資金の回転率が上がり、収益も向上させることができる。
【０１５５】
以上、実施形態例を詳述したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記憶媒体等としての実施態様をとることが可能であり、具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
【０１５６】
尚、本発明は、前述した実施形態の機能を実現するソフトウェアのプログラム（実施形態では図に示すフローチャートに対応したプログラム）を、システムあるいは装置に直接あるいは遠隔から供給し、そのシステムあるいは装置のコンピュータが該供給されたプログラムコードを読み出して実行することによっても達成される場合を含む。
【０１５７】
従って、本発明の機能処理をコンピュータで実現するために、該コンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明は、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。
【０１５８】
その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等の形態であっても良い。
【０１５９】
プログラムを供給するための記録媒体としては、例えば、フロッピー（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−Ｒ、ＤＶＤ−ＲＷ、ＤＶＤ＋Ｒ、ＤＶＤ＋ＲＷ）などがある。
【０１６０】
その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続し、該ホームページから本発明のコンピュータプログラムそのもの、もしくは圧縮され自動インストール機能を含むファイルをハードディスク等の記録媒体にダウンロードすることによっても供給できる。また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明に含まれるものである。
【０１６１】
また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせ、その鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。
【０１６２】
また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される他、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部または全部を行ない、その処理によっても前述した実施形態の機能が実現され得る。
【０１６３】
さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行ない、その処理によっても前述した実施形態の機能が実現される。
【０１６４】
【発明の効果】
以上説明したように、本発明によれば、複数種類の業者間で執り行われる業務を効率的に支援し、管理することができる業務管理装置及びその制御方法、業務管理システム、プログラムを提供できる。
【図面の簡単な説明】
【図１】本発明の実施形態１の業務管理システムの構成を示す図である。
【図２】本発明の実施形態１の各種端末のハードウェア構成を示す図である。
【図３】本発明の実施形態１の業務管理システムで実行される処理の概要を示すフローチャートである。
【図４】本発明の実施形態１の信頼度評価処理の詳細を示すフローチャートである。
【図５】本発明の実施形態１の審査項目決定処理の詳細を示すフローチャートである。
【図６】本発明の実施形態１の審査処理の詳細を示すフローチャートである。
【図７】本発明の実施形態１の発注処理の詳細を示すフローチャートである。
【図８】本発明の実施形態２の発注処理の詳細を示すフローチャートである。
【図９】本発明の実施形態１の事故情報入力画面の一例を示す図である。
【図１０】本発明の実施形態１の送信画像設定画面の一例を示す図である。
【図１１】本発明の実施形態１の案件作成画面の一例を示す図である。
【図１２】本発明の実施形態１の通知画面の一例を示す図である。
【図１３】本発明の実施形態１の審査状況画面の一例を示す図である。
【図１４】本発明の実施形態１の受信案件リスト画面の一例を示す図である。
【図１５】本発明の実施形態１の案件作成画面の一例を示す図である。
【図１６】本発明の実施形態１の審査結果選択画面の一例を示す図である。
【図１７】本発明の実施形態１の審査情報情報テーブルの一例を示す図である。
【図１８】本発明の実施形態１のブラックリストテーブルの一例を示す図である。
【図１９】本発明の実施形態１の審査項目情報設定テーブルの一例を示す図である。
【図２０】本発明の実施形態１の見積ファイルの一例を示す図である。
【図２１】本発明の実施形態１の発注先データベースの一例を示す図である。
【図２２】本発明の実施形態１の発注情報の一例を示すである。
【符号の説明】
１００  保険業者サーバ
１０１  端末
２００  修理業者端末
２０１  画像入力装置
２０２  ＧＰＳ衛星
３００  ＳＣ端末
４００  ネットワーク
５００  ネットワーク事業者サーバ
６００  発注先端末
【図１】
2004213371.tif 000003
【図２】
2004213371.tif 000004
【図３】
2004213371.tif 000005
【図４】
2004213371.tif 000006
【図５】
2004213371.tif 000007
【図６】
2004213371.tif 000008
【図７】
2004213371.tif 000009
【図８】
2004213371.tif 000010
【図９】
2004213371.tif 000011
【図１０】
2004213371.tif 000012
【図１１】
2004213371.tif 000013
【図１２】
2004213371.tif 000014
【図１３】
2004213371.tif 000015
【図１４】
2004213371.tif 000016
【図１５】
2004213371.tif 000017
【図１６】
2004213371.tif 000018
【図１７】
2004213371.tif 000019
【図１８】
2004213371.tif 000020
【図１９】
2004213371.tif 000021
【図２０】
2004213371.tif 000022
【図２１】
2004213371.tif 000023
【図２２】
2004213371.tif 000024