JP6670526B2 - 入札装置、入札システム、入札方法及びコンピュータプログラム - Google Patents

Description

本発明は、事故車両の修理費用の競争入札を行う入札装置などに関する。

事故車両の修理費用に関して、競争電子入札システムが提案されている（特許文献１）。

特開２００４−１８５３９４号公報

しかし、従来の競争電子入札システムでは、入札価額のみで落札者を決めている。そのため、技術力やサービスの質などから決まる修理工場の評価は、考慮されていない。本発明はかかる事情に鑑みてなされたものである。本発明の目的は、競争入札において落札者を選択する際に、修理工場の評価も考慮可能な入札装置などを提供することである。

本願の一観点は、車両の修理費用の見積額を含む入札情報を一又は複数受付ける入札受付部と、受付けた入札情報の中から落札させる入札情報の選択を受け付ける落札受付部とを備える入札装置において、修理工場の特定情報を受け付ける特定情報受付部と、前記車両に関する事故情報を送信する事故情報送信部と、前記特定情報に対応付けられた評価値を取得する評価値取得部と、前記特定情報及び契約形態を対応付けた契約形態情報より、前記特定情報に対応付けられた契約形態を取得する契約形態取得部とを備え、前記事故情報は、公開範囲を判定する評価レベル及び契約形態が割り当てられており、前記評価値取得部により、受付けた前記修理工場の特定情報に対応付けられた評価値を取得し、取得した評価値が前記評価レベルを満たし、かつ、取得した契約形態が前記事故情報に割り当てられた契約形態と適合する場合に、前記事故情報送信部は、前記事故情報を送信し、前記入札情報には修理工場の特定情報が含まれており、前記評価値取得部は、前記入札情報に含む特定情報に対応付けられた修理工場の評価値を取得し、前記入札情報及び当該入札情報に対応付けられた修理工場の評価値を出力する入札情報出力部を備える。

本願の一観点によれば、競争入札において落札者を選択する際に、修理工場の評価も考慮可能となる。

入札システムの構成例を示す説明図である。 入札サーバのハードウェア構成例を示す説明図である。 保険会社端末及び修理工場端末のハードウェア構成例を示す説明図である。 事故情報ＤＢのレコードレイアウトの一例を示す説明図である。 事故車両情報ＤＢのレコードレイアウトの一例を示す説明図である。 事故画像ＤＢのレコードレイアウトの一例を示す説明図である。 入札情報ＤＢのレコードレイアウトの一例を示す説明図である。 見積情報ＤＢのレコードレイアウトの一例を示す説明図である。 工場評価情報ＤＢのレコードレイアウトの一例を示す説明図である。 ユーザ情報ＤＢのレコードレイアウトの一例を示す説明図である。 会社情報ＤＢのレコードレイアウトの一例を示す説明図である。 工場情報ＤＢのレコードレイアウトの一例を示す説明図である。 契約形態ＤＢのレコードレイアウトの一例を示す説明図である。 事故車両修理の業務フローの一例を示すフローチャートである。 入札サーバのメイン処理の手順の一例を示すフローチャートである。 事故情報処理の手順の一例を示すフローチャートである。 入札情報処理の手順の一例を示すフローチャートである。 工場情報処理の手順の一例を示すフローチャートである。 事故情報一覧画面の一例を示す説明図である。 事故情報詳細画面の一例を示す説明図である。 入札状況一覧画面の一例を示す説明図である。 入札情報詳細画面の一例を示す説明図である。 事故情報処理の手順の一例を示すフローチャートである。 事故情報抽出処理の一例を示すフローチャートである。 事故情報抽出処理の一例を示すフローチャートである。 事故情報詳細画面の一例を示す説明図である。 見積画面の一例を示す説明図である。 入札状況一覧画面の一例を示す説明図である。

実施の形態１
以下、本発明の実施の形態を、図面を参照して説明する。図１は入札システムの構成例を示す説明図である。入札システムは、入札サーバ１（入札装置）、保険会社端末２、修理工場端末３を含む。入札サーバ１は、例えば汎用コンピュータ、ワークステーション、デスクトップ型ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）等である。保険会社端末２及び修理工場端末３は、例えばデスクトップ型ＰＣ（パーソナルコンピュータ）、ノートブック型ＰＣ、タブレット型ＰＣ、スマートフォン等である。保険会社端末２は各保険会社に複数設けられていても良い。修理工場端末３は各修理工場に複数設けられていても良い。入札サーバ１、保険会社端末２、修理工場端末３は、それぞれネットワークＮを介して互いに通信可能としてある。

図２は入札サーバ１のハードウェア構成例を示す説明図である。入札サーバ１は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１１、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１２、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１３、大容量記憶装置１４、通信部１５、読取り部１６を含む。各構成はバスで接続されている。

ＣＰＵ１１はＲＯＭ１３に記憶された制御プログラム１Ｐ（コンピュータプログラム）に従いハードウェア各部を制御する。ＲＡＭ１２は例えばＳＲＡＭ（Ｓｔａｔｉｃ ＲＡＭ）、ＤＲＡＭ（Ｄｙｎａｍｉｃ ＲＡＭ）、フラッシュメモリである。ＲＡＭ１２はＣＰＵ１１によるプログラムの実行時に発生するデータを一時的に記憶する。

大容量記憶装置１４は、例えばハードディスク、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）などである。大容量記憶装置１４には、後述する各種データベースが記憶されている。また、制御プログラム１Ｐを大容量記憶装置１４に記憶するようにしておいても良い。

通信部１５はネットワークＮを介して、他のコンピュータと通信を行う。読取り部１６はＣＤ（Ｃｏｍｐａｃｔ Ｄｉｓｋ）−ＲＯＭ、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ）−ＲＯＭを含む可搬型記憶媒体１ａを読み取る。ＣＰＵ１１が読取り部１６を介して、制御プログラム１Ｐを可搬型記憶媒体１ａより読み取り、大容量記憶装置１４に記憶しても良い。また、ネットワークＮを介して他のコンピュータからＣＰＵ１１が制御プログラム１Ｐをダウンロードし、大容量記憶装置１４に記憶しても良い。さらにまた、半導体メモリ１ｂから、ＣＰＵ１１が制御プログラム１Ｐを読み込んでも良い。

図３は保険会社端末２及び修理工場端末３のハードウェア構成例を示す説明図である。保険会社端末２及び修理工場端末３は同様な構成であるので、まとめて説明する。保険会社端末２（修理工場端末３）は、ＣＰＵ２１（３１）、ＲＡＭ２２（３２）、ＲＯＭ２３（３３）、大容量記憶装置２４（３４）、入力部２５（３５）、出力部２６（３６）、通信部２７（３７）、読取り部２８（３８）を含む。各構成はバスで接続されている。

ＣＰＵ２１（３１）はＲＯＭ２３（３３）に記憶された制御プログラム２Ｐ（３Ｐ）に従いハードウェア各部を制御する。ＲＡＭ２２（３２）は例えばＳＲＡＭ、ＤＲＡＭ、フラッシュメモリである。ＲＡＭ２２（３２）はＣＰＵ２１（３１）によるプログラムの実行時に発生するデータを一時的に記憶する。

大容量記憶装置２４（３４）は、例えばハードディスク、ＳＳＤなどである。大容量記憶装置２４（３４）には、後述する各種データベースが記憶されている。また、制御プログラム２Ｐ（３Ｐ）を大容量記憶装置２４（３４）に記憶するようにしておいても良い。

入力部２５（３５）はキーボード、マウスなど、データ入力を行うデバイスである。出力部２６（３６）は、画像出力を表示装置２６ａ（３６ａ）に、音声出力をスピーカなどに行う。

通信部２７（３７）はネットワークＮを介して、他のコンピュータと通信を行う。読取り部２８（３８）はＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭを含む可搬型記憶媒体２ａ（３ａ）を読み取る。ＣＰＵ２１（３１）が読取り部２８（３８）を介して、制御プログラム２Ｐ（３Ｐ）を可搬型記憶媒体２ａ（３ａ）より読み取り、大容量記憶装置２４（３４）に記憶しても良い。また、ネットワークＮを介して他のコンピュータからＣＰＵ２１（３１）が制御プログラム２Ｐ（３Ｐ）をダウンロードし、大容量記憶装置２４（３４）に記憶しても良い。さらにまた、半導体メモリ２ｂ（３ｂ）から、ＣＰＵ２１（３１）が制御プログラム２Ｐ（３Ｐ）を読み込んでも良い。

次に、入札システムで用いられる各種データベースについて説明する。以下に説明するデータベースは、入札サーバ１の大容量記憶装置１４に記憶されている。図４は事故情報ＤＢ（ＤａｔａＢａｓｅ）１４１のレコードレイアウトの一例を示す説明図である。事故情報ＤＢ１４１は事故に関する基本的な事項を記憶するデータベースである。事故情報ＤＢ１４１は、事故登録ＣＤ、保険会社ＣＤ、公開日、締切日、地域、コメント、落札ＣＤ、公開レベルの各列を含む。事故登録ＣＤには事故情報を一意に特定する値を記憶する。保険会社ＣＤには事故情報を登録した保険会社を特定する値を記憶する。公開日は事故情報を公開した日付を記憶する。締切日には入札の期限を記憶する。地域は事故に係る車両の所在地域を記憶する。当該所在は車両の登録住所や、車両オーナーの居住地より、取得しても良い。コメントには事故情報を登録した保険会社の担当者のコメントを記憶する。落札ＣＤは事故情報にかかる入札に関して、落札が確定した場合に、落札となった入札情報を特定する入札ＣＤの値を記憶する。公開レベル（公開範囲）は事故情報を公開する範囲を示す値を記憶する。例えば、０：非公開、１：全ての工場、２：評価レベルが一定値以上の工場、３：提携・契約工場のみ、４：契約工場のみのように定める。上述において、ＣＤはコード（ｃｏｄｅ）の略語である。

図５は事故車両情報ＤＢ１４２のレコードレイアウトの一例を示す説明図である。事故車両情報ＤＢ１４２は事故に係る車両（事故車両）についての情報を記憶するデータベースである。事故車両情報ＤＢ１４２は、事故登録ＣＤ、プレートＮＯ、車種、年式、排気量、トランスミッション、色、走行距離、エンジン番号の各列を含む。事故登録ＣＤは、事故車両に対応する事故情報ＤＢ１４１のレコードと同一の値を記憶する。プレートＮＯは、事故車両のナンバープレートの値を記憶する。車種は、事故車両の車種を記憶する。年式は、事故車両の年式を記憶する。年式とは車両が製造された年を示す。排気量は、事故車両の排気量を記憶する。トランスミッションは、事故車両のトランスミッションを記憶する。例えば、４ＡＴは４速のオートマチックトランスミッションを示す。色は、事故車両の車体色を記憶する。走行距離には、事故車両の総走行距離を記憶する。エンジン番号は、事故車両のエンジンの番号を記憶する。

図６は事故画像ＤＢ１４３のレコードレイアウトの一例を示す説明図である。事故画像ＤＢ１４３は事故車両の状況示す写真画像を記憶するデータベースである。事故画像ＤＢ１４３は事故登録ＣＤ、画像ＣＤ、画像データ、ファイル拡張子、ファイル名の各列を含む。事故登録ＣＤは、写真画像の被写体である事故車両に対応する事故情報ＤＢ１４１のレコードの事故登録ＣＤと同一の値を記憶する。画像ＣＤは写真画像を一意に特定する値を記憶する。画像データは写真画像のバイナリデータを記憶する。ファイル拡張子は画像データのデータ形式を示すファイルの拡張子を記憶する。例えば、ＪＰＥＧ（Ｊｏｉｎｔ Ｐｈｏｔｏｇｒａｐｈｉｃ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）であれば、ｊｐｇ又はｊｐｅｇを記憶する。ＴＩＦＦ（Ｔａｇｇｅｄ Ｉｍａｇｅ Ｆｉｌｅ Ｆｏｒｍａｔ）であれば、ｔｉｆ又はｔｉｆｆを記憶する。ファイル名は、写真画像ファイルのファイル名の拡張子を除いたファイル名本体を記憶する。

図７は入札情報ＤＢ１４４のレコードレイアウトの一例を示す説明図である。入札情報ＤＢ１４４は入札に関する基本的な情報を記憶するデータベースである。入札情報ＤＢ１４４は入札ＣＤ、事故登録ＣＤ、入札年月日、入札結果、工場ＣＤ、納車予定日の各列を含む。入札ＣＤには入札情報を一意に特定する値を記憶する。事故登録ＣＤは、入札対象となっている事故に対応する事故情報ＤＢ１４１のレコードの事故登録ＣＤと同一の値を記憶する。入札年月日は、入札データを登録した日付、すなわち応札した日付を記憶する。入札結果は落札したか否かを示すフラグを記憶する。例えば、応札中の場合はＮＵＬＬを、落札予定の場合は１を、落札が確定した場合には２を、落札しなかった場合には０を記憶する。工場ＣＤは入札を行った修理工場を特定する工場ＣＤの値を記憶する。納車予定日は落札した修理工場が事故車両修理を完了して、保険会社又は事故車両オーナーに納車する予定の日付を記憶する。

図８は見積情報ＤＢ１４５のレコードレイアウトの一例を示す説明図である。見積情報ＤＢ１４５は入札情報に対応付けられる修理費用見積に関する情報を記憶するデータベースである。見積情報ＤＢ１４５は入札ＣＤ、合計金額、メカニカル合計、部品合計の各列を含む。入札ＣＤは対応付けられている入札情報ＤＢ１４４のレコードの入札ＣＤと同一の値を記憶する。合計金額は修理費用の合計金額を記憶する。メカニカル合計は整備士、板金塗装職人などの工賃の合計金額を記憶する。部品合計は修理に際して、調達した部品費用の合計金額を記憶する。

図９は工場評価情報ＤＢ１４６のレコードレイアウトの一例を示す説明図である。工場評価情報ＤＢ１４６は、保険会社毎の各修理工場の評価に関する情報を記憶するデータベースである。工場評価情報ＤＢ１４６は保険会社ＣＤ、工場ＣＤ、評価、公開レベルの各列を含む。保険会社ＣＤは評価する保険会社を一意に特定する値を記憶する。工場ＣＤは評価される修理工場を一意に特定する値を記憶する。評価は評価値を記憶する。評価は例えば、満点を１００として、７５点というように付ける。また、５段階評価としても良い。公開レベルは評価を他の保険会社や修理工場にも参照可能とするなど、評価情報を公開する範囲を定める。例えば、０：非公開、１：公開とする。公開レベルが０の場合は、非公開であり、評価を行った保険会社及び評価された修理工場のみが参照可能である。公開レベルが１の場合は、全ての保険会社と修理工場が参照可能である。

図１０はユーザ情報ＤＢ１４７のレコードレイアウトの一例を示す説明図である。ユーザ情報ＤＢ１４７は、入札システムを利用するユーザについての情報を記憶するデータベースである。ユーザ情報ＤＢ１４７はユーザＩＤ、パスワード、氏名、電話番号、携帯番号、メールアドレス、ユーザ種類、所属ＣＤ、機能権限ＣＤの各列を含む。ユーザＩＤはユーザを一意に特定する値を記憶する。パスワードはログインの際に認証に用いるパスワードを記憶する。氏名はユーザの氏名を記憶する。電話番号はユーザの連絡先電話番号を記憶する。携帯番号はユーザの携帯電話の番号を記憶する。メールアドレスはユーザの電子メールアドレスを記憶する。ユーザ種類はユーザの種類を記憶する。例えば、１は保険会社、２は修理工場を示す。所属ＣＤは所属する組織のコードを記憶する。機能権限ＣＤは入札システムで利用できる機能を定義した内容を示すコードを記憶する。例えば、機能権限ＣＤは、保険会社の一般社員の権限を示す。３は、修理工場の一般行員の権限を示す。機能権限ＣＤにより、入札システムにアクセスした際に表示されるメニューの内容が変化する。

図１１は会社情報ＤＢ１４８のレコードレイアウトの一例を示す説明図である。会社情報ＤＢ１４８は保険会社についての情報を記憶するデータベースである。会社情報ＤＢ１４８は会社ＣＤ、所属ＣＤ、名称、郵便番号、住所、電話番号、ＦＡＸ番号、メールアドレスの各列を含む。会社ＣＤは会社を一意に特定する値を記憶する。所属ＣＤは会社の下位に位置する組織、例えば、支店、営業所を一意に特定する値を記憶する。名称は会社の名称を記憶する。会社名に支店名、営業所名を含めても良い。郵便番号は会社所在地に対応した郵便番号を記憶する。住所は所在地を記憶する。電話番号は会社の連絡先電話番号を記憶する。ＦＡＸ番号は会社のＦＡＸ番号を記憶する。メールアドレスは会社の連絡先メールアドレスを記憶する。

図１２は工場情報ＤＢ１４９のレコードレイアウトの一例を示す説明図である。工場情報ＤＢ１４９は修理工場に関する情報を記憶するデータベースである。工場情報ＤＢ１４９は工場ＣＤ、所属ＣＤ、工場名、郵便番号、住所、電話番号、ＦＡＸ番号、メールアドレスの各列を含む。工場ＣＤは上位の修理工場を一意に特定する値を記憶する。所属ＣＤは下位の工場を一意に特定する値を記憶する。工場ＣＤと所属ＣＤとの関係は、会社情報ＤＢ１４８の会社ＣＤと所属ＣＤと同様な関係である。工場名は工場の名称を記憶する下位の工場の名称を含めても良い。郵便番号は工場所在地に対応した郵便番号を記憶する。住所は工場の所在地を記憶する。電話番号は工場の連絡先電話番号を記憶する。ＦＡＸ番号は工場のＦＡＸ番号を記憶する。メールアドレスは工場の連絡先メールアドレスを記憶する。

図１３は契約形態ＤＢ１４ａのレコードレイアウトの一例を示す説明図である。契約形態ＤＢ１４ａは保険会社と修理工場との契約形態の情報を記憶するデータベースである。契約形態ＤＢ１４ａは保険会社ＣＤ、工場ＣＤ、契約形態の各列を含む。保険会社ＣＤは保険会社を一意に特定する値を記憶する。工場ＣＤは修理工場を一意に特定する値を記憶する。契約形態は保険会社ＣＤで特定される保険会社と工場ＣＤで特定される修理工場との契約形態を示す形態コードが記憶される。例えば、形態コードは、１であれば認定工場、２であれば提携工場、３であれば契約工場を示す。契約形態により取引条件が異なるものとする。

次に、事故車両修理の業務フローについて説明する。図１４は事故車両修理の業務フローの一例を示すフローチャートである。事故発生後、車両のオーナーから事故の連絡が保険会社に対してなされる（ステップＳ１）。保険会社は事故を受け付ける（ステップＳ２）。保険会社は保険契約データ、受付時にオーナーから得た情報を用いて、事故情報を入札システムに登録する（ステップＳ３）。保険会社は入札するために必要なデータが揃った時点で、事故情報を公開する（ステップＳ４）。修理工場は定期的に入札システムへアクセスし、事故情報を検索する（ステップＳ５）。または、事故情報が公開された時点で、修理工場に電子メールが送信し、それを機に、修理工場が新たな事故情報を検索しても良い。修理工場は事故車両の内容を確認する（ステップＳ６）。修理工場は確認した内容に基づき、修理費用の見積を行う（ステップＳ７）。修理工場は入札データを入力する（ステップＳ８）。

なお、見積は既存の見積システムで作成しても良い。入札システムに見積システムとの連携機能を設け、入札システムの記憶する事故情報を見積システム送り、見積システムで作成した見積を入札システムで受け取っても良い。また見積システムにおいて、部品費用を見積もる際に、部品調査システムを用いて、中古部品を含めた部品検索、部品発注を行っても良い。

保険会社は事故情報公開から所定期間経過した後に、入札情報の確認をする（ステップＳ９）。保険会社は修理を依頼する修理工場の選定を行う（ステップＳ１０）。修理工場の選定にあたっては、見積金額の大小だけではなく、修理工場の評価を加味して、選定しても良い。保険会社は修理工場に対して、ＬＯＡ（Ｌｅｔｔｅｒ Ｏｆ Ａｐｐｒｏｖａｌ：同意書）を送付する（ステップＳ１１）。修理工場はＬＯＡを受領し（ステップＳ１２）、必要事項を記載の上、保険会社に返送する（ステップＳ１３）。保険会社はＬＯＡを受領する（ステップＳ１４）。保険会社はＬＯＡに問題がなれば、発注を確定する（ステップＳ１５）。保険会社は落札決定を修理工場に通知する（ステップＳ１６）。

保険会社は事故車両を落札した修理工場に移送する（ステップＳ１７）。修理工場は事故車両を受け入れ（ステップＳ１８）、修理を行う（ステップＳ１９）。修理工場は修理が完了した場合、完了通知をオーナー及び保険会社に行う（ステップＳ２０）。オーナーは修理工場に出向き、車両を引き取る（ステップＳ２１）。保険会社は完了通知を確認し（ステップＳ２２）、修理代金を修理工場に支払う（ステップＳ２３）。修理工場は修理代金を受領する（ステップＳ２４）。保険会社は工場の評価を行う（ステップＳ２５）。

次に、入札システムにおける入札サーバ１の動作について説明する。図１５は入札サーバ１のメイン処理の手順の一例を示すフローチャートである。保険会社のオペレータは、事故情報の登録のため、保険会社端末２より入札サーバ１へアクセスする。入札サーバ１のＣＰＵ１１はログイン処理を行う（ステップＳ３１）。ＣＰＵ１１はログインユーザの種類と機能権限ＣＤより権限判定を行う（ステップＳ３２）。ＣＰＵ１１は判定された権限に基づいてメニュー画面を生成し、保険会社端末２に送信する（ステップＳ３３）。ＣＰＵ１１は保険会社端末２よりメニューの選択を受付ける（ステップＳ３４）。ＣＰＵ１１は選択されたメニューが事故情報であるか否かを判定する（ステップＳ３５）。ＣＰＵ１１は事故情報が選択されたと判定した場合（ステップＳ３５でＹＥＳ）、事故情報処理を行う（ステップＳ３６）。ＣＰＵ１１は、処理をステップＳ３３に戻す。

ＣＰＵ１１は事故情報が選択されていないと判定した場合（ステップＳ３５でＮＯ）、工場情報が選択されたか否かを判定する（ステップＳ３７）。ＣＰＵ１１は工場情報が選択されたと判定した場合（ステップＳ３７でＹＥＳ）、ＣＰＵ１１は工事情報処理を実行する（ステップＳ３８）。ＣＰＵ１１は処理をステップＳ３３に戻す。

ＣＰＵ１１は工場情報が選択されていないと判定した場合（ステップＳ３７でＮＯ）、ユーザ情報が選択されたか否かを判定する（ステップＳ３９）。ＣＰＵ１１はユーザ情報が選択されたと判断した場合（ステップＳ３９でＹＥＳ）、ユーザ情報処理を実行する（ステップＳ４０）。ＣＰＵ１１は処理をステップＳ３３に戻す。
ここで、ユーザ情報処理により提供する機能には、各ユーザが自らについての氏名、電話番号、携帯番号、メールアドレスの登録内容を確認し、必要に応じて変更を行える機能と、管理者権限のユーザのみが行える会社住所、会社電話番号の変更、各ユーザの権限設定機能などを含む。

ＣＰＵ１１はユーザ情報が選択されていないと判断した場合（ステップＳ３９でＮＯ）、ログアウト処理を行う（ステップＳ４１）。ＣＰＵ１１はメイン処理を終了する。

なお、図１５に示すメイン処理は、保険会社のユーザがログインした場合を示している。修理工場のユーザがログインした場合も同様である。しかし、修理工場のユーザは工場情報処理の実行は許可されていないので、ステップＳ３７、Ｓ３８は実行されない。ＣＰＵ１１はステップＳ３５でＮＯと判定した場合、ステップＳ３９を実行する。

次に、事故情報処理（図１５のステップＳ３６）について説明する。図１６は事故情報処理の手順の一例を示すフローチャートである。図１６に示す事故情報処理は、保険会社のユーザがログインした場合の処理である。入札サーバ１のＣＰＵ１１は一覧画面を送信する（ステップＳ５１）。ＣＰＵ１１は事故情報ＤＢ１４１より事故情報を取得する。ＣＰＵ１１はユーザのログイン時にユーザが所属する保険会社の保険会社ＣＤを取得しており、ユーザ所属の保険会社に関する事故情報のみを取得する。ＣＰＵ１１は取得した事故情報に含まれる事故登録ＣＤをキーに、事故車両情報ＤＢ１４２、事故画像ＤＢ１４３を検索し、事故車両情報、事故画像を取得する。ここで取得する事故車両情報、事故画像の項目は、一覧表示に必要な項目のみでも良い。ＣＰＵ１１は取得した事故情報、事故車両情報、事故画像より、一覧画面を生成し、通信部１５、ネットワークＮを介して保険会社端末２へ送信する。

保険会社端末２は入札サーバ１から受信した一覧画面を表示装置２６ａに表示する。保険会社のユーザは行う操作を指示する。入札サーバ１のＣＰＵ１１は新規登録を受付けたか否かを判定する（ステップＳ５２）。ＣＰＵ１１は新規登録を受付けたと判定した場合（ステップＳ５２でＹＥＳ）、登録画面を送信する（ステップＳ５３）。

ＣＰＵ１１は新規登録を受け付けていないと判定した場合（ステップＳ５２でＮＯ）、一覧からレコードが選択されたか否かを判定する（ステップＳ５４）。ＣＰＵ１１はレコードが選択されたと判定した場合（ステップＳ５４でＹＥＳ）、選択された事故に対応する事故情報を登録画面に埋め込む（ステップＳ５５）。ＣＰＵ１１は、登録画面を送信する（ステップＳ５３）。

保険会社端末２は入札サーバ１から受信した登録画面を表示装置２６ａに表示する。保険会社のユーザは登録画面を用いて、事故情報の入力を行う。ＣＰＵ１１は登録又は更新操作がされたか否かを判定する（ステップＳ５６）。ＣＰＵ１１は登録又は更新操作がされたと判定した場合（ステップＳ５６でＹＥＳ）、事故情報の登録又は更新を行う（ステップＳ５７）。登録の場合、ＣＰＵ１１は事故情報ＤＢ１４１、事故車両情報ＤＢ１４２、事故画像ＤＢ１４３に新規レコードを追加する。更新の場合は、ＣＰＵ１１は事故情報ＤＢ１４１、事故車両情報ＤＢ１４２、事故画像ＤＢ１４３の対象レコードを上書きする。ＣＰＵ１１は処理をステップＳ５５へ戻す。

ＣＰＵ１１は登録又は更新の操作ではないと判定した場合（ステップＳ５６でＮＯ）、削除であるか否かを判定する（ステップＳ５８）。ＣＰＵ１１は受付けた操作が削除であると判定した場合（ステップＳ５８でＹＥＳ）、対象レコードを削除する（ステップＳ５９）。削除するのは、事故情報ＤＢ１４１、事故車両情報ＤＢ１４２、事故画像ＤＢ１４３それぞれの対象レコードである。ＣＰＵ１１は処理をステップＳ５２に戻す。

ＣＰＵ１１は受付けた操作が削除でないと判定した場合（ステップＳ５８でＮＯ）、受付けた操作が入札情報処理か否かを判定する（ステップＳ６０）。ＣＰＵ１１は受付けた操作が入札情報処理であると判定した場合（ステップＳ６０でＹＥＳ）、入札情報処理を実行し（ステップＳ６１）、処理をステップＳ５５に戻す。

ＣＰＵ１１は受付けた操作が入札情報処理でないと判定した場合（ステップＳ６０でＮＯ）、処理をステップＳ５２に戻す。

ＣＰＵ１１は一覧からレコードが選択されていないと判定した場合（ステップＳ５４でＮＯ）、事故情報処理を終了し、処理を呼び出し元に戻す。

次に入札情報処理について説明する。図１７は入札情報処理（図１６のステップＳ６１）の手順の一例を示すフローチャートである。入札サーバ１のＣＰＵ１１は、選択されている事故案件に対する入札情報の一覧画面を送信する（ステップＳ７１）。ＣＰＵ１１は選択されている事故案件の事故登録ＣＤをキーに、入札情報ＤＢ１４４から入札情報を取得する。ＣＰＵ１１は取得した入札情報それぞれの入札ＣＤをキーに、見積情報ＤＢ１４５から見積情報を取得する。ＣＰＵ１１は取得した入札情報それぞれの入札ＣＤ及びユーザが所属する保険会社の保険会社ＣＤをキーに、工場評価情報ＤＢ１４６から工場の評価を取得する。ＣＰＵ１１は取得した入札情報、見積情報、工場の評価より、一覧表示画面を出力し、通信部１５、ネットワークＮを介して保険会社端末２へ送信する。

保険会社端末２は入札サーバ１から受信した一覧画面を表示装置２６ａに表示する。保険会社のユーザは行う操作を選択する。ＣＰＵ１１は一覧からレコードが選択されたか否かを判定する（ステップＳ７２）。ＣＰＵ１１は一覧からレコードが選択されたと判定した場合（ステップＳ７２でＹＥＳ）、入札についての詳細情報を表示出力する（ステップＳ７３）。ＣＰＵ１１は落札操作がされたか否かを判定する（ステップＳ７４）。ＣＰＵ１１は落札操作がされたと判定した場合（ステップＳ７４でＹＥＳ）、選択されている入札情報の入札結果が落札予定であるか否かを判定する（ステップＳ７５）。ＣＰＵ１１は入札結果が落札予定であると判定した場合（ステップＳ７５でＹＥＳ）、落札処理を行う（ステップＳ７６）。ＣＰＵ１１は選択されている入札情報の入札結果を、落札確定に設定する。また、選択されている事故案件に対する他の入札情報については、入札結果を落札しなかった場合の値とする。ＣＰＵ１１は処理をステップＳ７３に戻す。ＣＰＵ１１は入札結果が落札予定ではないと判定した場合（ステップＳ７５でＮＯ）、入札結果を落札予定に設定する（ステップＳ７７）。ＣＰＵ１１は処理をステップＳ７３に戻す。

ＣＰＵ１１は落札操作ではないと判定した場合（ステップＳ７４でＮＯ）、落札取り消しであるか否かを判定する（ステップＳ７８）。ＣＰＵ１１は落札取り消しであると判定した場合（ステップＳ７８でＹＥＳ）、選択されている入札情報の入札結果が落札確定ではないか否かを判定する（ステップＳ７９）。ＣＰＵ１１は選択されている入札情報の入札結果が落札確定ではないと判定した場合（ステップＳ７９でＹＥＳ）、入札結果を、応札中を示すＮＵＬＬに設定する（ステップＳ８０）。ＣＰＵ１１は処理をステップＳ７３に戻す。ＣＰＵ１１は選択されている入札情報の入札結果が落札確定であると判定した場合（ステップＳ７９でＮＯ）、取り消しはできないので、処理をステップＳ７３に戻す。その際に、取り消しはできない旨のエラーメッセージを表示しても良い。

ＣＰＵ１１は落札取り消しではないと判定した場合（ステップＳ７８でＮＯ）、処理をステップＳ７１へ戻す。ＣＰＵ１１は一覧からレコードが選択された以外の操作がされた判定した場合（ステップＳ７２でＮＯ）、入札情報処理を終了し、処理を呼び出し元に戻す。

次に工場情報処理について説明する。図１８は工場情報処理（図１５のステップＳ３８）の手順の一例を示すフローチャートである。入札サーバ１のＣＰＵ１１は、工場情報の一覧画面を送信する（ステップＳ９１）。ＣＰＵ１１は工場情報ＤＢ１４９から工場情報を取得する。ＣＰＵ１１は取得した工場情報それぞれの工場ＣＤ及びユーザが所属する保険会社の保険会社ＣＤをキーに、契約形態ＤＢ１４ａからそれぞれの工場の契約形態を取得する。ＣＰＵ１１は取得した工場情報、契約形態より、一覧画面を生成し、通信部１５、ネットワークＮを介して保険会社端末２へ送信する。

保険会社端末２は入札サーバ１から受信した一覧画面を表示装置２６ａに表示する。保険会社のユーザは行う操作を選択する。入札サーバ１のＣＰＵ１１は一覧からレコードが選択されたか否かを判定する（ステップＳ９２）。ＣＰＵ１１は一覧からレコードが選択されたと判定した場合（ステップＳ９２でＹＥＳ）、工場についての詳細情報を表示する画面を送信する（ステップＳ９３）。ユーザは必要に応じて、評価及び契約形態に登録・更新を行う。ＣＰＵ１１は登録・更新操作がされたか否かを判定する（ステップＳ９４）。ＣＰＵ１１は登録・更新操作がされたと判定した場合（ステップＳ９４でＹＥＳ）、登録・更新処理を行う（ステップＳ９５）。ＣＰＵ１１は工場評価情報ＤＢ１４６に評価を新たに登録、または工場評価情報ＤＢ１４６に記憶している評価を更新する。また、ＣＰＵ１１は契約形態ＤＢ１４ａに契約形態を新たに登録、または契約形態ＤＢ１４ａに記憶している契約形態を更新する。ＣＰＵ１１は処理をステップＳ９３に戻す。

ＣＰＵ１１は登録・更新操作以外の操作がされたと判定した場合（ステップＳ９４でＮＯ）、処理をステップＳ９１に戻す。ＣＰＵ１１は一覧でのレコード選択以外の操作がされたと判定した場合（ステップＳ９２でＮＯ）、工場情報処理を終了し、処理を呼び出し元に戻す。

次に、保険会社端末２に表示される画面について説明する。図１９は事故情報一覧画面の一例を示す説明図である。事故情報一覧画面は、一覧表示部１９１、新規登録ボタン１９２、戻るボタン１９３、横スクロールバー１９４を含む。一覧表示部１９１はすでに登録している事故情報が一覧表示される。図１９に示す例では、横方向にデータ項目を並べているため、一部のデータ項目が隠れて表示されてない。隠れているデータ項目を表示するためには、横スクロールバー１９４をマウス等でドラッグ・アンド・ドロップする。新規登録ボタン１９２をマウスクリック等の操作で選択すると、新規登録のための画面が表示される。戻るボタン１９３をマウス等の操作で選択すると、メニュー画面に遷移する。マウスクリック等の操作で一覧表示部１９１に表示されている事故情報を選択すると、事故情報詳細画面に遷移する。図１９に示す例では、マウスポインタｍによりＮｏ．１の事故情報が選択されようとしている。

図２０は事故情報詳細画面の一例を示す説明図である。事故情報詳細画面は詳細表示部２０１、更新ボタン２０２、削除ボタン２０３、入札状況ボタン２０４、戻るボタン２０５を含む。詳細表示部２０１は事故情報の詳細が表示される。画像欄に示すカメラアイコン２０６をマウスクリック等の操作で選択すると、事故車両の画像を参照することが可能である。また、詳細表示部２０１において、すでに入力されている値をマウスでダブルクリック等の操作をすると編集モードになり、内容を更新する事が可能である。更新後に更新ボタン２０２をマウスクリック等の操作で選択すると、変更内容が事故情報ＤＢ１４１、事故車両情報ＤＢ１４２、事故画像ＤＢ１４３等に反映される。削除ボタン２０３をマウスクリック等の操作で選択すると、表示されている事故情報が削除される。入札状況ボタン２０４をマウスクリック等の操作で選択すると、入札状況一覧画面に遷移する。戻るボタン２０５をマウスクリック等の操作で選択すると、メニュー画面に遷移する。なお、新規登録画面は、事故情報詳細画面と同様な構成である。

図２１は入札状況一覧画面の一例を示す説明図である。入札状況一覧画面は事故情報表示部２１１、一覧表示部２１２、戻るボタン２１３、状態表示部２１４を含む。事故情報表示部２１１は選択している事故の情報が表示される。一覧表示部２１２は入札内容が一覧表示される。戻るボタン２１３をマウスクリック等の操作で選択すると、事故情報詳細画面に遷移する。状態表示部２１４は入札の状態を表示する。例えば、入札前であれば「非公開」、入札を受付けていれば「入札中」、入札期間が終了し落札する修理工場の選定を待っているのであれば「選定待ち」、落札する修理工場が決まっていれば「落札予定」、落札が確定すれば「落札確定」を表示する。マウスクリック等の操作で一覧表示部２１２に表示されている入札情報を選択すると、入札情報詳細画面に遷移する。図２１に示す例では、マウスポインタｍにより入札ＣＤが２０１４０４４４２３１の入札情報が選択されようとしている。図２１の一覧表示部２１２においては、入札している各修理工場の評価を示す評価欄２１２ａがあり、保険会社のユーザは入札金額のみでなく、各修理工場の評価も加味して、落札させる修理工場を選択することが可能となっている。

図２２は入札情報詳細画面の一例を示す説明図である。入札情報詳細画面は、事故情報表示部２２１、詳細表示部２２２、落札ボタン２２３、戻るボタン２２４を含む。事故情報表示部２２１は選択している事故の情報が表示される。詳細表示部２２２は入札情報の詳細が表示される。見積書欄に示す文書アイコン２２５をマウスクリック等の操作で選択すると、見積書を参照することが可能である。落札ボタン２２３をマウスクリック等の操作で選択すると、入札中であれば、表示されている入札が落札予定となる。すでに落札予定である場合は、落札確定となる。戻るボタン２２４をマウスクリック等の操作で選択すると、入札状況一覧画面に遷移する。

次に、修理工場のユーザがログインした場合の事故情報処理について説明する。図２３は事故情報処理の手順の一例を示すフローチャートである。入札サーバ１のＣＰＵ１１は表示対象となる事故情報の抽出をする（ステップＳ１０１）。ＣＰＵ１１は抽出した事故情報より一覧画面を生成し、通信部１５、ネットワークＮを介して修理工場端末３に送信する（ステップＳ１０２）。

修理工場端末３は入札サーバ１から受信した一覧画面を表示装置３６ａに表示する。修理工場のユーザは行う操作を指示する。入札サーバ１のＣＰＵ１１は一覧からレコードが選択されたか否かを判定する（ステップＳ１０３）。ＣＰＵ１１はレコードが選択されたと判定した場合（ステップＳ１０３でＹＥＳ）、選択された事故に対応する事故情報を詳細表示画面（事故情報詳細画面）に埋め込み、修理工場端末３に送信する（ステップＳ１０４）。なお、すでに入札がされている場合、ＣＰＵ１１は見積金額を見積情報ＤＢ１４５より読み込み、詳細表示画面に埋め込む。ＣＰＵ１１は入札が指示されたか否かを判定する（ステップＳ１０５）。ＣＰＵ１１は入札が指示されたと判定した場合（ステップＳ１０５でＹＥＳ）、入札処理を行う（ステップＳ１０６）。ＣＰＵ１１は入札情報ＤＢ１４４及び見積情報ＤＢ１４５に新規レコードを追加する。新規レコードの内容については、ＲＡＭ１２又は大容量記憶装置１４に設けた一時記憶領域に記憶されている。ＣＰＵ１１は処理をステップＳ１０１に戻す。

ＣＰＵ１１は入札が指示されていないと判定した場合（ステップＳ１０５でＮＯ）、取消が指示されたか否かを判定する（ステップＳ１０７）。ＣＰＵ１１は取消が指示されたと判定した場合（ステップＳ１０７でＹＥＳ）、入札の取消を行う（ステップＳ１０８）。すなわち、選択されている事故情報に対応付けられた入札情報を入札情報ＤＢ１４４から削除する。また、当該入札情報に対応付けられた見積情報を見積情報ＤＢ１４５から削除する。

ＣＰＵ１１は取消が指示されていないと判定した場合（ステップＳ１０７でＮＯ）、見積が指示されたか否かを判定する（ステップＳ１０９）。ＣＰＵ１１は見積が指示されていないと判定した場合（ステップＳ１０９でＮＯ）、処理をステップＳ１０１に戻す。

ＣＰＵ１１は見積が指示されたと判定した場合（ステップＳ１０９でＹＥＳ）、入力・変更画面を送信する（ステップＳ１１０）。修理工場端末３は入札サーバ１から受信した入力・変更画面を表示装置３６ａに表示する。修理工場のユーザは登録画面を用いて、入札情報の入力を行う。ＣＰＵ１１は登録又は更新操作がされた否かを判定する（ステップＳ１１１）。ＣＰＵ１１は登録又は更新操作がされたと判定した場合（ステップＳ１１１でＹＥＳ）、見積情報の登録又は変更を行う（ステップＳ１１２）。登録の場合、ＣＰＵ１１は入札情報ＤＢ１４４及び見積情報ＤＢ１４５に記憶すべき内容を、ＲＡＭ１２又は大容量記憶装置１４に設けた一時記憶領域に記憶する。変更の場合、ＣＰＵ１１は入札情報ＤＢ１４４及び見積情報ＤＢ１４５の対象レコードを上書きする。ＣＰＵ１１は処理をステップＳ１０４へ戻す。

ＣＰＵ１１は登録又は更新の操作ではないと判定した場合（ステップＳ１１１でＮＯ）、クリア又はインポートが指示された否かを判定する（ステップＳ１１３）。ＣＰＵ１１はクリア又はインポートが指示されたと判定した場合（ステップＳ１１３でＹＥＳ）、クリア又はインポート処理を行う（ステップＳ１１４）。クリアは入力・変更画面に入力された内容をクリアする。インポートは見積作成システムなどの他システムより直接データを読み込んだり、ＣＳＶ（Ｃｏｍｍａ−Ｓｅｐａｒａｔｅｄ Ｖａｌｕｅｓ）ファイルなどの汎用形式のファイルから見積データを読み込んだりすることである。これらについては周知の技術であるので、説明を省略する。ＣＰＵ１１は処理をステップＳ１１０に戻す。ＣＰＵ１１はクリア又はインポートが指示されていないと判定した場合（ステップＳ１１３でＮＯ）、処理をステップＳ１０４へ戻す。

ＣＰＵ１１は一覧からレコードの選択以外の操作がされたと判定した場合（ステップＳ１０３でＮＯ）、事故情報処理を終了し、処理を呼び出し元に戻す。

図２４及び図２５は事故情報抽出処理の一例を示すフローチャートである。入札サーバ１のＣＰＵ１１はログインしているユーザの所属ＣＤをキーに工場情報ＤＢ１４９を検索し、工場ＣＤを取得する（ステップＳ１２１）。ＣＰＵ１１は制限なしの事故情報を取得する（ステップＳ１２２）。制限なしの事故情報とは、公開レベルが全ての工場と設定されているものである。ＣＰＵ１１は取得した事故情報をＲＡＭ１２や大容量記憶装置１４などに設けた一時記憶領域に記憶する（ステップＳ１２３）。ＣＰＵ１１は制限ありの公開の事故情報を取得する（ステップＳ１２４）。すなわち、ＣＰＵ１１は非公開でもなく、全ての工場に参照可能でもない事故情報を取得する。ＣＰＵ１１は取得した事故情報から会社ＣＤを抽出する（ステップＳ１２５）。この際、同一の会社ＣＤが複数ある場合は、重複するものは削除し、同一の会社ＣＤを複数含まないようにする。ＣＰＵ１１は１つの会社ＣＤを選択する（ステップＳ１２６）。ＣＰＵ１１は選択した会社ＣＤ、ステップＳ１１１で取得した工場ＣＤをキーに、工場評価情報ＤＢ１４６を検索し、工場の評価値を取得する（ステップＳ１２７）。ＣＰＵ１１は選択した会社ＣＤ、ステップＳ１２１で取得した工場ＣＤをキーに、契約形態ＤＢ１４ａを検索し、選択した会社ＣＤに係る保険会社と工場との契約形態を取得する（ステップＳ１２８）。ＣＰＵ１１は選択した会社ＣＤ、ステップＳ１２７で取得した評価、ステップＳ１２８で取得した契約形態をＲＡＭ１２や大容量記憶装置１４などに設けた一時記憶領域に記憶する（ステップＳ１２９）。ＣＰＵ１１はステップＳ１２５で抽出した全ての会社ＣＤについて処理したか否かを判定する（ステップＳ１３０）。ＣＰＵ１１は全ての会社ＣＤについて処理したと判定した場合（ステップＳ１３０でＹＥＳ）、処理をステップＳ１３１に移す。ＣＰＵ１１は全ての会社ＣＤについて処理していないと判定した場合（ステップＳ１３０でＮＯ）、処理をステップＳ１２６に戻す。

ＣＰＵ１１はステップＳ１２４で取得した事故情報の中から１つのレコードを選択する（ステップＳ１３１）。ＣＰＵ１１は選択したレコードの公開レベルを参照し、参照制限は評価によるものであるか否かを判定する（ステップＳ１３２）。ＣＰＵ１１は評価による制限であると判定した場合（ステップＳ１３２でＹＥＳ）、工場の評価が予め定められている閾値以上であるか否かを判定する（ステップＳ１３３）。具体的には、ＣＰＵ１１は、選択したレコードに含まれる会社ＣＤを取得し、取得した会社ＣＤをキーにステップＳ１２９で記憶したデータを検索し、会社ＣＤに対応付けた評価を取得する。ＣＰＵ１１は取得した評価が閾値以上であるか否かを判定する。ＣＰＵ１１は評価が閾値以上であると判定した場合（ステップＳ１３３でＹＥＳ）、選択したレコードをステップＳ１２３で記憶した取得情報に追加する（ステップＳ１３４）。ＣＰＵ１１は処理をステップＳ１３５に移す。ＣＰＵ１１は評価が閾値未満であると判定した場合（ステップＳ１３３でＮＯ）、ＣＰＵ１１は取得した制限なしの事故情報の全レコードについて処理した否かを判定する（ステップＳ１３５）。

ＣＰＵ１１は評価による制限ではないと判定した場合（ステップＳ１３２でＮＯ）、契約による制限であるか否かを判定する（ステップＳ１３６）。ＣＰＵ１１は契約による制限であると判定した場合（ステップＳ１３６でＹＥＳ）、制限条件を満たしているか否かを判定する（ステップＳ１３７）。具体的には、ＣＰＵ１１は、選択したレコードに含まれる会社ＣＤを取得し、取得した会社ＣＤをキーにステップＳ１２９で記憶したデータを検索し、会社ＣＤに対応付けた契約形態を取得する。ＣＰＵ１１は契約形態が制限条件を満たすか否かを判定する。制限条件が契約工場のみの場合は、契約形態が契約工場である場合のみ条件を満たす。制限条件が提携工場のみの場合は、契約形態が提携工場のみならず、契約工場である場合も条件を満たすものとしてもよい。ＣＰＵ１１は契約形態が制限条件を満たすと判定した場合（ステップＳ１３７でＹＥＳ）、処理をステップＳ１３４に進める。ＣＰＵ１１は契約形態が制限条件を満たさないと判定した場合（ステップＳ１３７でＮＯ）、処理をステップＳ１３５に進める。ＣＰＵ１１は契約による制限ではないと判定した場合（ステップＳ１３６でＮＯ）、処理をステップＳ１３５に進める。

ＣＰＵ１１は全てのレコードについて処理したと判定した場合（ステップＳ１３５でＹＥＳ）、一時領域に記憶した取得情報の各レコードに対応した事故車両情報を取得する（ステップＳ１３８）。同様に、一時領域に記憶した取得情報の各レコードに対応した事故画像情報を取得する（ステップＳ１３９）。ＣＰＵ１１は事故情報抽出処理を終了し、処理を呼び出し元に戻す。

ＣＰＵ１１は全てのレコードについて処理していないと判定した場合（ステップＳ１３５でＮＯ）、処理をステップＳ１３１に戻し、未処理のレコードについての処理を行う。

図２６は事故情報詳細画面の一例を示す説明図である。事故情報詳細画面は詳細表示部２６１、見積金額表示部２６２、入札ボタン２６３、取消ボタン２６４、見積ボタン２６５、戻るボタン２６６を含む。詳細表示部２６１は事故情報の詳細が表示される。画像欄に示すカメラアイコン２６７をマウスクリック等の操作で選択すると、事故車両の画像を参照することが可能である。見積金額表示部２６２は、見積金額がすでに入力されている場合に、その金額を表示する。取消ボタン２６４は既に入札がされている場合に操作可能で、マウスクリック等の操作で選択すると入札が取り消される。見積ボタン２６５をマウスクリック等の操作で選択すると、見積画面に遷移する。戻るボタン２６６をマウスクリック等の操作で選択すると、事故情報一覧画面に遷移する。

図２７は見積画面の一例を示す説明図である。見積画面はメカニカル部２７１、部品部２７２、見積金額部２７３、入力欄追加ボタン２７４、２７５、登録・更新ボタン２７６、クリアボタン２７７、インポートボタン２７８、戻るボタン２７９を含む。メカニカル部２７１は自動車板金工や整備士等の人が行う作業の内容とそれに対する金額を表示、入力する領域である。部品部２７２は必要となる部品名、点数、単価、小計を表示、入力する領域である。入力欄追加ボタン２７４、２７５はそれぞれ、メカニカル部２７１、部品部２７２の入力欄が足りない場合に、欄を追加するためのボタンである。マウスクリック等の操作で入力欄追加ボタン２７４を選択すると、メカニカル部２７１の入力欄が、入力欄追加ボタン２７５を選択すると、部品部２７２の入力欄が追加される。見積金額部２７３はメカニカル部２７１、部品部２７２の入力内容にしたがって、メカニカル費用合計、部品費用合計が計算され表示される。さらに、メカニカル費用合計、部品費用合計が合算し、見積合計金額が計算され表示される。登録・更新ボタン２７６をマウスクリック等の操作で選択すると、見積画面で入力された内容が反映される。登録の場合、入力された内容を、ＲＡＭ１２や大容量記憶装置１４に設けた一時領域に、記憶する。クリアボタン２７７をマウスクリック等の操作で選択すると、見積画面で入力された内容がクリアされる。すでに見積情報が見積情報ＤＢ１４５に記憶されている場合は、その内容に戻る。インポートボタン２７８をマウスクリック等の操作で選択すると、インポート画面（図示しない）が表示され、見積作成システムなどの他システムより直接データを読み込んだり、ＣＳＶファイルなどの汎用形式のファイルから見積データを読み込んだりすることができる。戻るボタン２７９をマウスクリック等の操作で選択すると、事故情報詳細画面に戻る。

以上のように実施の形態１では、保険会社のユーザは入札金額のみでなく、各修理工場の評価も加味して、落札させる修理工場を選択することが可能である。修理金額が増加しても評価の高い工場に落札させることが可能となる。また、修理工場端末３には、それぞれの修理工場が入札可能な事故情報のみが表示されるので、修理工場は入札できない事故情報について、費用見積もりをしてしまうという無駄が発生することを防ぐことが可能となる。また、評価の高い修理工場のみに事故情報を公開する場合があるので、修理工場により良質の修理を行おうという動機を与えることとなる。
また、見積画面においては、インポート機能を設けてあるので、入札の際に必要となる見積情報を他のシステムや、汎用形式のファイルから読み込むことが可能である。

実施の形態２
実施の形態２では、入札状況一覧を表示する際に、入札金額と評価とを考慮して、入札させるべき修理工場を表示するようにする。実施の形態２において、入札システムの構成、入札サーバ１で行われる処理は、実施の形態１と同様である。以下の説明においては、実施の形態１と異なる部分を主として説明する。

図２８は入札状況一覧画面の一例を示す説明図である。入札状況一覧画面は事故情報表示部２８１、一覧表示部２８２、１位に決定ボタン２８３、戻るボタン２８４、状態表示部２８５を含む。事故情報表示部２８１は選択している事故の情報が表示される。一覧表示部２８２は入札内容が一覧表示される。戻るボタン２８４をマウスクリック等の操作で選択すると、事故情報詳細画面に遷移する。状態表示部２８５は入札の状態を表示する。例えば、入札前であれば「非公開」、入札を受け付けていれば「入札中」、入札期間が終了し落札する修理工場の選定を待っているのであれば「選定待ち」、落札する修理工場が決まっていれば「落札予定」、落札が確定すれば「落札確定」を表示する。

実施の形態２においては、一覧表示部２８２には、総合順位欄２８２ａが追加されている。総合順位は、入札金額と評価により決定される。工場Ａは、入札金額も安く、評価も５と高いため、総合順位が１位となっている。工場Ｃは、工場Ｂよりも入札金額が５０００円高いが、評価が工場Ｂよりも高いので、総合順位が２位となっている。総合順位決定方法の一例としては、次のようなものが考えられる。評価の差が１の場合、入札金額の差が５０００円以内であれば、評価が高い方を高順位にする。評価の差が２の場合、入札金額の差が１００００円以内であれば、評価が高い方を高順位にする。以下同様に、評価の差が３の場合は入札金額の差が１５０００円以内、評価の差が４の場合は入札金額の差が２００００円以内であれば、評価が高い方を高順位にする。総合順位決定方法の他の一例としては、評価の差が１の場合、入札金額の差額が低い入札金額の１％以内であれば、評価が高い方を高順位にする。評価の差が２の場合、入札金額の差額が低い入札金額の２％以内であれば、評価が高い方を高順位にする。以下同様に、評価の差が大きくなるほど、差額が大きくても、評価が高い方を高順位にする。上述の総合順位決定方法はあくまでも例示であり、他の決定方法でも良い。

１位に決定ボタン２８３は、総合順位が１位である工場を落札予定とすることを決定するためのボタンである。１位に決定ボタン２８３をマウスクリック等の操作により選択すると、ハッチングが掛かっている総合順位１位の工場Ａが、落札予定工場として決定される。

以上のように実施の形態２では、実施の形態１が奏する効果に加えて、以下の効果を奏する。入札状況一覧画面において、入札金額及び修理工場の評価を加味した総合順位を表示するので、保険会社のオペレータは容易に落札させる修理工場の選定を行うことが可能となる。

上述においては、事故車両を修理する場合において、修理費用の入札を行うこととしたが、それに限らない。経年劣化や使用劣化により不具合が生じた車両の修理費用について入札を行っても良い。この場合は、入札を実施するのは保険会社ではなく、車両のオーナーであっても良い。

また、１つの修理工場に対して、複数の保険会社が評価を行う場合もあるので、各保険会社による評価値を、複数の保険会社間で参照し合うことができるようにしても良い。例えば、図２１に示した入札状況一覧画面に表示されている工場を、マウスのダブルクリックをすると、各保険会社の評価が一覧表示されるようにする。修理工場の評価値を複数の保険会社間で参照し合うことは、評価値が多く集まることによる評価値の信憑性向上に繋がる。そして、複数の評価値が修理工場の評価に影響することから、修理の品質を一定水準に保とうという修理工場の意識付けにもつなげることが可能となる。
なお、各保険会社は自社の評価値を他社に公開するか否かを選択できるようにしても良い。この場合、自社の評価値を他社に公開しない保険会社には、他社の評価値を参照不可にしても良い。

各実施例で記載されている技術的特徴（構成要件）はお互いに組合せ可能であり、組み合わせすることにより、新しい技術的特徴を形成することができる。
今回開示された実施の形態はすべての点で例示であって、制限的なものでは無いと考えられるべきである。本発明の範囲は、上記した意味では無く、特許請求の範囲によって示され、特許請求の範囲と均等の意味及び範囲内でのすべての変更が含まれることが意図される。

１ 入札サーバ
１１ ＣＰＵ
１２ ＲＡＭ
１３ ＲＯＭ
１４ 大容量記憶装置
１４１ 事故情報ＤＢ
１４２ 事故車両情報ＤＢ
１４３ 事故画像ＤＢ
１４４ 入札情報ＤＢ
１４５ 見積情報ＤＢ
１４６ 工場評価情報ＤＢ
１４７ ユーザ情報ＤＢ
１４８ 会社情報ＤＢ
１４９ 工場情報ＤＢ
１４ａ 契約形態ＤＢ
１５ 通信部
１６ 読取り部
１ａ 可搬型記憶媒体
１ｂ 半導体メモリ
１Ｐ 制御プログラム
２ 保険会社端末
２１ ＣＰＵ
２２ ＲＡＭ
２３ ＲＯＭ
２４ 大容量記憶装置
２５ 入力部
２６ 出力部
２７ 通信部
２８ 読取り部
２６ａ 表示装置
２ａ 可搬型記憶媒体
２ｂ 半導体メモリ
２Ｐ 制御プログラム
３ 修理工場端末
３１ ＣＰＵ
３２ ＲＡＭ
３３ ＲＯＭ
３４ 大容量記憶装置
３５ 入力部
３６ 出力部
３７ 通信部
３８ 読取り部
３６ａ 表示装置
３ａ 可搬型記憶媒体
３ｂ 半導体メモリ
Ｎ ネットワーク
ｍ マウスポインタ

Claims (5)

1. 車両の修理費用の見積額を含む入札情報を一又は複数受付ける入札受付部と、
   受付けた入札情報の中から落札させる入札情報の選択を受け付ける落札受付部とを備える入札装置において、
   修理工場の特定情報を受け付ける特定情報受付部と、
   前記車両に関する事故情報を送信する事故情報送信部と、
   前記特定情報に対応付けられた評価値を取得する評価値取得部と、
   前記特定情報及び契約形態を対応付けた契約形態情報より、前記特定情報に対応付けられた契約形態を取得する契約形態取得部とを備え、
   前記事故情報は、公開範囲を判定する評価レベル及び契約形態が割り当てられており、
   前記評価値取得部により、受付けた前記修理工場の特定情報に対応付けられた評価値を取得し、取得した評価値が前記評価レベルを満たし、かつ、取得した契約形態が前記事故情報に割り当てられた契約形態と適合する場合に、前記事故情報送信部は、前記事故情報を送信し、
   前記入札情報には修理工場の特定情報が含まれており、
   前記評価値取得部は、前記入札情報に含む特定情報に対応付けられた修理工場の評価値を取得し、
   前記入札情報及び当該入札情報に対応付けられた修理工場の評価値を出力する入札情報出力部を
   備えることを特徴とする入札装置。
2. 前記入札情報に含まれる見積額及び当該入札情報に含まれる修理工場の特定情報に対応付けられた評価値に基づいて、落札対象となる入札情報を選択可能に設けた落札選択部
   を備えることを特徴とする請求項１に記載の入札装置。
3. 一又は複数の修理工場端末と、
   該修理工場端末から、車両の修理費用の見積額を含む入札情報を一又は複数受付ける入札受付部、及び受付けた入札情報の中から落札させる入札情報の選択を受け付ける落札受付部を有する入札装置と、
   該入札装置から入札情報を受け付け、落札させる入札情報の選択を行う保険会社端末と
   を備える入札システムにおいて、
   前記入札情報には修理工場の特定情報が含まれており、
   前記入札装置は、
   修理工場の特定情報を受け付ける特定情報受付部と、
   前記車両に関する事故情報を送信する事故情報送信部と、
   前記特定情報に対応付けられた評価値を取得する評価値取得部と、
   前記特定情報及び契約形態を対応付けた契約形態情報より、前記特定情報に対応付けられた契約形態を取得する契約形態取得部とを有し、
   前記事故情報は、公開範囲を判定する評価レベル及び契約形態が割り当てられており、
   前記評価値取得部により、受付けた前記修理工場の特定情報に対応付けられた評価値を取得し、取得した評価値が前記評価レベルを満たし、かつ、取得した契約形態が前記事故情報に割り当てられた契約形態と適合する場合に、前記事故情報送信部は、前記事故情報を送信し、
   前記入札装置は更に、
   前記評価値取得部は、前記入札情報に含む特定情報に対応付けられた修理工場の評価値を取得し、
   前記入札情報及び当該入札情報に対応付けられた修理工場の評価値を出力する入札情報出力部と、
   絞り込んだ前記入札情報及び当該入札情報に対応付けられた修理工場の評価値を、前記保険会社端末へ出力する入札情報出力部と
   を有することを特徴とする入札システム。
4. コンピュータが、車両の修理費用の見積額を含む入札情報を一又は複数受付け、受付けた入札情報の中から落札させる入札情報の選択を受け付ける入札方法において、
   修理工場の特定情報を受け付け、
   前記特定情報及び契約形態を対応付けた契約形態情報より、前記特定情報に対応付けられた契約形態を取得し、
   修理工場の特定情報及び評価値を対応付けた評価情報より、前記特定情報に対応付けられた評価値を取得し、
   前記車両に関する事故情報は、公開範囲を判定する評価レベル及び契約形態が割り当てられており、
   取得した評価値が前記評価レベルを満たし、かつ、前記契約形態情報から取得した契約形態が前記事故情報に割り当てられた契約形態と適合する場合に、事故情報を送信し、
   前記入札情報に含む特定情報に対応付けられた修理工場の評価値を取得し、
   前記入札情報及び当該入札情報に対応付けられた修理工場の評価値を出力する
   ことを特徴とする入札方法。
5. 車両の修理費用の見積額を含む入札情報を一又は複数受付け、受付けた入札情報の中から落札させる入札情報の選択を受け付けるコンピュータに、
   修理工場の特定情報を受け付け、
   前記特定情報及び契約形態を対応付けた契約形態情報より、前記特定情報に対応付けられた契約形態を取得し、
   修理工場の特定情報及び評価値を対応付けた評価情報より、前記特定情報に対応付けられた評価値を取得し、
   前記車両に関する事故情報は、公開範囲を判定する評価レベル及び契約形態が割り当てられており、
   取得した評価値が前記評価レベルを満たし、かつ、前記契約形態情報から取得した契約形態が前記事故情報に割り当てられた契約形態と適合する場合に、事故情報を送信し、
   前記入札情報には修理工場の特定情報が含まれており、
   前記入札情報に含む特定情報に対応付けられた修理工場の評価値を取得し、
   前記入札情報及び当該入札情報に対応付けられた修理工場の評価値を出力する
   処理を実行させることを特徴とするコンピュータプログラム。

Images