JP2016151891A - Program, estimation method and estimation device - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a program, etc. that can estimate a repair cost including labor charge even if information about labor charge is not stored.SOLUTION: A program allows a computer to execute processes of: acquiring a first model relating to an article subjected to repair estimation; determining whether or not information relating to the repair associated with the first model is stored; and, when the information is determined not to be stored, displaying a second model relating to an article for which information stored in association is available for the repair estimation of the article, on the basis of the first model or the article specification of the first model.SELECTED DRAWING: Figure 3

Description

  The present invention relates to a program for estimating a repair by a computer, an estimation method, and an estimation apparatus.

  In estimating the cost required for vehicle repair, a vehicle repair estimation system that displays illustrations of parts of automobiles and colors selected parts is disclosed (Patent Document 1).

  In estimating the cost required for repairing a vehicle, an information providing apparatus that displays illustrations of automobile parts using different colors depending on the material is disclosed (Patent Document 2).

  A component selection system and a component supply system that reduce the burden of inventory management by collectively supplying components that may be replaced when repairing a vehicle are disclosed (Patent Document 3).

JP 2006-350743 A JP 2003-156922 A JP 2010-64662 A

  However, the system of Patent Document 1 does not disclose a method for calculating the repair labor cost. Moreover, in the apparatus of patent document 2 and the system of patent document 3, the repair cost is estimated using the wage information stored in advance in the auxiliary storage device. Therefore, for a vehicle type in which wage information is not stored, the user needs to input information related to the wage.

  In one aspect, an object of the present invention is to provide a program or the like that can estimate a repair cost including a wage even when wage information is not stored.

  In one aspect, the program acquires a first type relating to an article for which a repair estimate is to be made, determines whether or not information relating to a repair associated with the first type is stored in advance, and the information is stored. If it is determined that the information stored in association with the second model related to the article that can be used for the repair estimate of the article, the second model of the first model or the first model Causes the computer to execute a process of displaying based on the specification of the article.

  In one aspect, even if wage information is not stored, it is possible to provide a program that can estimate repair costs including wages.

It is an apparatus block diagram of an estimation apparatus. It is explanatory drawing which shows the record layout of reference DB. It is explanatory drawing which shows the screen of an estimation apparatus. It is a flowchart which shows the flow of a process of an estimation program. 10 is a flowchart showing a flow of processing of an estimation program according to the second embodiment. It is explanatory drawing which shows the record layout of vehicle type DB. 14 is a flowchart illustrating a flow of processing of an estimation program according to the third embodiment. 10 is a flowchart illustrating a flow of processing for selecting an alternative vehicle type according to a third embodiment. 10 is a flowchart illustrating a flow of processing for selecting an alternative vehicle type according to a third embodiment. 10 is a flowchart illustrating a flow of processing for selecting an alternative vehicle type according to a third embodiment. FIG. 10 is a device configuration diagram of an estimation device according to a fourth embodiment.

[Embodiment 1]
The present embodiment relates to an estimation device that estimates the repair cost of a vehicle. The estimation device of the present embodiment determines whether or not an index relating to repair of the vehicle type has been created after receiving the vehicle type of the vehicle to be repaired. The specified reference model is extracted and the repair cost is estimated using the index of the reference model.

  Here, the index will be described. The index is an index indicating the work time for repairing automobiles, and is used as a standard for calculating repair costs in the automobile industry. The technical fee for auto repair is calculated based on the product of the index and the coefficient determined according to the location of the auto repair shop. The work time required for repairing the automobile varies depending on the structure of the automobile and the repair work. Therefore, an index is created for each vehicle type and repair work.

  Since it takes time to create an index, an index is created only for some vehicle types. The created index is commonly used within the automotive industry. For vehicle types for which no index has been created, technical fees for automobile repairs are calculated by using indexes for models with similar structures. Conventionally, selection of a vehicle type that uses an index has been manually performed based on the knowledge and experience of the user. Therefore, the user who has abundant knowledge about a vehicle performed operation of the estimation apparatus. The present embodiment relates to an estimation program for extracting a reference vehicle type that is a candidate for a vehicle type that uses an index.

  FIG. 1 is a device configuration diagram of the estimation device 10. The estimation device 10 according to the present embodiment includes a CPU 11, which is one or more arithmetic control devices, a main storage device 12 such as SRAM (Static RAM), DRAM (Dynamic RAM), or flash memory, and a storage device such as a hard disk and a semiconductor memory disk. Auxiliary storage device 13, an input unit 14 that is an input device such as a mouse, keyboard, touch panel, pen tablet, and microphone, an output unit 15 that is an output device such as a printer and a plotter, a display, a projector, a head mounted display, etc. A communication module 17 that communicates with a network such as the Internet or an intranet, and a reading unit 18 that reads a portable recording medium such as a disk unit, an SD (Secure Digital) card reader, and the like. The estimation device 10 is, for example, a general-purpose personal computer, a tablet, or a smartphone.

  The auxiliary storage device 13 stores various DBs such as an estimate program to be executed by the CPU 11 and a reference DB (DataBase) 131 necessary for executing the estimate program. Various DBs such as the reference DB 131 may be acquired from an external DB (not shown) via the communication module 17.

  FIG. 2 is an explanatory diagram showing a record layout of the reference DB 131. The reference DB 131 is a DB that associates a vehicle type for which no index is created, a reference vehicle type that can be used for the index, and a reason for selection of the reference vehicle type for estimation of repair costs. Here, the vehicle type is a model expressed by alphanumeric characters or the like determined by the vehicle manufacturer, and can be used when identifying detailed specifications of the vehicle.

  The reference DB 131 has an input vehicle type field, a reference vehicle type field, and a reason field. The reference DB 131 has one record for each vehicle type for which no index is created. In the input vehicle type field, vehicle types for which no index is created are recorded. In the reference vehicle type field, a reference vehicle type is recorded in which the index can be used to estimate the repair cost of the vehicle type recorded in the input vehicle type field.

  In the reason field, the reason for selecting the reference model is recorded. When “OEM car” is recorded in the reason field, it indicates that the input car model and the reference car model are in a relationship between the car model of the product supplied by the partner brand and the car model of the original product. Here, OEM is an abbreviation for Original Equipment Manufacturer, that is, an original brand supply item. When “same car rating” is recorded in the reason field, it indicates that the vehicle dimensions of the input model and the reference model are close. If “last year” is recorded in the reason field, it indicates that the input model is a successor product of the reference model and the reference model corresponds to the model of the previous model. In addition to these, the reason field records that the input car model and the reference car model are minor change cars of the same series, and that the input car model and the reference car model use the same engine. May be.

  FIG. 3 is an explanatory diagram showing a screen of the estimation device 10. The outline | summary of the estimation apparatus 10 is demonstrated using FIG.

  When estimating the cost required for vehicle repair, the CPU 11 accepts input of information related to the vehicle to be repaired. The CPU 11 determines whether or not the index of the vehicle type that has received the input is stored in the auxiliary storage device 13. If it is determined that it is not stored, the CPU 11 displays the screen shown in FIG. The screen of FIG. 3 will be described. The CPU 11 displays an explanation column 21 for explaining the situation to the user in the upper part of FIG. In the explanation column 21 of FIG. 3, it is necessary to select a similar vehicle type in order to estimate the vehicle type input by the user and that a reference vehicle type similar to the vehicle type input by the user is prepared. ing.

  The CPU 11 displays a vehicle information column 22 indicating the vehicle type, model year, door body shape, and the like input by the user under the description column 21. The CPU 11 displays a reference column 23 for displaying a reference vehicle type similar to the vehicle type input by the user under the vehicle information column 22. The CPU 11 displays a reason column 24 for displaying the reason for selecting the reference vehicle type under the reference column 23. The CPU 11 displays a return button 25 for accepting a user operation, a change button 26, and an estimate button 27 under the reason column 24, respectively. In the following description, the screen of FIG. 3 is referred to as a vehicle type proposal screen.

  FIG. 4 is a flowchart showing the flow of processing of the estimation program. The flow of processing performed by the CPU 11 of the estimation apparatus 10 according to the present embodiment will be described with reference to FIG. CPU11 receives vehicle information (Step S501). The vehicle information is information such as a vehicle type, a vehicle body number, and a vehicle owner name. The vehicle information may be received from the input unit 14 or may be received from another information terminal connected via the communication module 17.

  The CPU 11 determines whether or not the input vehicle type index is stored in the auxiliary storage device 13 (step S502). If it is determined that it is not stored (NO in step S502), the CPU 11 refers to the reference DB 131 stored in the auxiliary storage device 13 using the input vehicle type as a key, and determines the reference vehicle type and the reason for selecting the reference vehicle type. Obtain (step S503).

  The CPU 11 displays a vehicle type proposal screen including the reference vehicle type and the reason for selection on the display unit 16, and determines whether or not the index of the reference vehicle type can be adopted for the creation of an estimate (step S504). The determination is made based on whether or not the input of the estimate button 27 on the vehicle type proposal screen is accepted. When the input of the estimate button 27 is received, the CPU 11 determines that the index of the reference vehicle type can be adopted (YES in step S504). When the input of the change button 26 on the vehicle model proposal screen is received, it is determined that the index of the reference vehicle type cannot be adopted (NO in step S504), and the CPU 11 receives the input of the reference vehicle type by the user (step S506). Since the user has input the reference vehicle type in the past, details of the input method and description of the input screen are omitted.

  After the end of step S504 and after the end of step S506, the CPU 11 acquires the index of the reference vehicle type from the auxiliary storage device 13 (step S507).

  If it is determined that the input vehicle type index is stored in the auxiliary storage device 13 (YES in step S502), the CPU 11 acquires the vehicle type index input from the auxiliary storage device 13 (step S508).

  After the end of step S507 and after the end of step S508, the CPU 11 accepts a repair location (step S509). The CPU 11 uses the index acquired in step S503 or step S504 to create a repair estimate for the repair location received in step S509 (step S510). Since reception of repair points and creation of a repair estimate have been performed in the past, the description thereof will be omitted. Thereafter, the CPU 11 ends the process. Although the description of the flowchart is omitted, when the selection of the return button 25 is accepted, the CPU 11 interrupts the processing of this subroutine and returns to the vehicle information input screen.

  According to the present embodiment, it is possible to perform estimation using an appropriate reference vehicle type by referring to the reference DB 131 even if the vehicle type has no index. Therefore, even if the user has little knowledge about the vehicle, it is possible to provide the estimation device 10 that can create an appropriate estimate.

  When the reliability of the reference DB 131 is high, step S504 and step S506 are omitted, and after obtaining the reference vehicle type (step S503), the index of the reference vehicle type is obtained without waiting for input from the user (step S507). May be.

  In the present embodiment, automobile repair has been described as an example. However, the present estimation device 10 can be applied to estimate repairs of various articles such as motorcycles, home appliances, and information devices. In this case, the technical fee can be estimated by using the repair time data, etc., calculated by each manufacturer independently as an index.

  Even in the case of automobile repair, the repair time or repair cost data calculated independently by each manufacturer may be used as an index.

[Embodiment 2]
The present embodiment relates to an estimation device 10 that records a reference vehicle type and an input vehicle type in association with each other when an input of a reference vehicle type by a user is received. Description of portions common to the first embodiment is omitted.

  FIG. 5 is a flowchart showing a flow of processing of the estimation program according to the second embodiment. CPU11 receives vehicle information (Step S501). The CPU 11 determines whether or not the input vehicle type index is stored in the auxiliary storage device 13 (step S502). If it is determined that it is not stored (NO in step S502), the CPU 11 refers to the reference DB 131 stored in the auxiliary storage device 13 using the input vehicle type as a key, and determines the reference vehicle type and the reason for selecting the reference vehicle type. Obtain (step S503).

  The CPU 11 determines whether or not the reference vehicle type has been successfully acquired (step S521). The case where it is not successful is a case where the key vehicle type is not included in the input vehicle type field of the reference DB 131.

  If it is determined that the vehicle has succeeded (YES in step S521), the CPU 11 displays a vehicle type proposal screen including the reference vehicle type and the reason for selection on the display unit 16, and whether or not the index of the reference vehicle type can be adopted for the creation of the estimate. Is determined (step S504). The determination is made based on whether or not the input of the estimate button 27 on the vehicle type proposal screen is accepted. When the input of the estimate button 27 is received, the CPU 11 determines that the index of the reference vehicle type can be adopted (YES in step S504).

  When the input of the change button 26 on the vehicle type proposal screen is received, the CPU 11 determines that the reference vehicle type cannot be adopted (NO in step S504). When it is determined that acquisition of the reference vehicle type has failed (NO in step S521) and when it is determined that the reference vehicle type cannot be employed (NO in step S504), the CPU 11 receives input of the reference vehicle type from the input unit 14 by the user. (Step S506). The CPU 11 determines whether to save the reference vehicle type input by the user (step S522). The determination is made based on whether or not an input for instructing storage is received.

  If it is determined to be stored (YES in step S522), the CPU 11 records the reference vehicle type received in step S506 in the reference DB 131 in association with the input vehicle type received in step S501 (step S523). Here, when the input vehicle type is already recorded in the input field, the reference vehicle type field of the record is rewritten to the reference vehicle type input in step S506. If the input vehicle type is not recorded in the input field, a record that associates the input vehicle type with the reference vehicle type is added to the reference DB 131.

  It is desirable that the CPU 11 accepts the reason for determining the reference vehicle type from another information terminal connected via the input unit 14 or the communication module 17 and records it in the reason field of the record to be added to the reference DB 131. In addition, the history of correction and additional writing of the reference DB 131 is preferably recorded by providing a history field in the reference DB 131 or by providing a separate log file. The matters to be recorded include, for example, matters that have been corrected or added, users who have made corrections or additions, the date and time of correction or addition, and the like.

  When it is determined that the vehicle can be employed (YES in step S504), after the completion of step S523, and when it is determined that the reference vehicle type is not stored (NO in step S522), the CPU 11 acquires the index of the reference vehicle type from the auxiliary storage device 13. (Step S507).

  If it is determined that the input vehicle type index is stored in the auxiliary storage device 13 (YES in step S502), the CPU 11 acquires the vehicle type index input from the auxiliary storage device 13 (step S508).

  After completion of step S507 or after completion of step S508, the CPU 11 accepts a repair location (step S509). The CPU 11 uses the index acquired in step S503 or step S504 to create a repair estimate for the repair location received in step S509 (step S510). Since reception of repair points and creation of a repair estimate have been performed in the past, the description thereof will be omitted. Thereafter, the CPU 11 ends the process. Although the description of the flowchart is omitted, when the selection of the return button 25 is accepted, the CPU 11 interrupts the processing of this subroutine and returns to the vehicle information input screen.

  According to this embodiment, even if the update of the reference DB 131 is delayed as compared with the release of a new vehicle type, it is possible to provide the estimation device 10 that can enhance the recorded contents of the reference DB 131 each time a repair is accepted.

[Embodiment 3]
The present embodiment relates to an estimation apparatus 10 that selects a reference vehicle type with reference to the characteristics of the vehicle type. Description of portions common to the first embodiment is omitted.

  FIG. 6 is an explanatory diagram showing a record layout of the vehicle type DB. The vehicle type DB is a DB in which characteristics such as vehicle type specifications are recorded. The vehicle type DB includes a vehicle type field, a status field, an index field, a manufacturer field, an OEM original field, and a previous field. The vehicle type DB has one record for each vehicle type.

  The vehicle type is recorded in the vehicle type field. The state of the vehicle type is recorded in the state field. If “new model” is recorded in the state field, it indicates that the model has been released as a new model. If "Full model change" is recorded in the state field, this indicates that the model has been released as an almost new model, although it is in common with existing models. If “minor change” is recorded in the state field, this indicates that the vehicle has been released as a vehicle with much in common with the existing vehicle. When “Past” is recorded in the status field, this indicates that the vehicle type has been sold in the past but is not currently sold.

  In the index field, it is recorded whether or not an index for the vehicle type has been created. If “present” is recorded in the index field, it means that the index for that vehicle type has been created and can be referred to. When “None” is recorded in the index field, it means that the index of the vehicle type cannot be referred to. If “present” is recorded in the index field, the index of the vehicle type is stored in advance in the auxiliary storage device 13.

  The manufacturer name is recorded in the manufacturer field. In the OEM original field, the vehicle type of the original product is recorded when the vehicle type recorded in the vehicle type field is the vehicle type supplied by the partner brand. When "-" is recorded in the OEM field, it means that the vehicle type is not the vehicle type that is supplied by the partner brand. The car field before the model change is recorded in the front field. When "-" is recorded in the previous field, it means that the vehicle type is not the vehicle type that has undergone model change.

  Further, the vehicle type DB includes a field (not shown) in which characteristics of the vehicle type such as vehicle dimensions, body shape, number of doors, drive unit specifications, engine specifications, and sales volume are recorded.

  FIG. 7 is a flowchart showing a flow of processing of the estimation program according to the third embodiment. The processing flow of this embodiment will be described with reference to FIG. Note that description of portions common to the first embodiment is omitted.

  CPU11 receives vehicle information (Step S501). The vehicle information is information such as a vehicle type, a vehicle body number, and a vehicle owner name. The vehicle information may be received from the input unit 14 or may be received from another information terminal connected via the communication module 17.

  The CPU 11 extracts a record from the vehicle type DB using the input vehicle type as a key, refers to the index field, and determines whether or not the index is recorded in the auxiliary storage device 13 (step S502). If it is determined that the index is not stored in the auxiliary storage device 13 (NO in step S502), the CPU 11 starts a reference vehicle type selection subroutine (step S531). The reference vehicle type selection subroutine is a subroutine for selecting a reference vehicle type corresponding to the vehicle type input with reference to the vehicle type DB. The processing flow of the reference vehicle type selection subroutine will be described later. The CPU 11 acquires the index of the reference vehicle type from the auxiliary storage device 13 (step S507).

  If it is determined that the index is stored in the auxiliary storage device 13 (YES in step S502), the CPU 11 acquires the vehicle type index input from the auxiliary storage device 13 (step S508).

  After the end of step S507 and after the end of step S508, the CPU 11 accepts a repair location (step S509). The CPU 11 uses the index acquired in step S503 or step S504 to create a repair estimate for the repair location received in step S509 (step S510). Since reception of repair points and creation of a repair estimate have been performed in the past, the description thereof will be omitted. Thereafter, the CPU 11 ends the process. Although the description of the flowchart is omitted, when the selection of the return button 25 is accepted, the CPU 11 interrupts the processing of this subroutine and returns to the vehicle information input screen.

  8 to 10 are flowcharts showing a flow of processing for selecting a reference vehicle type according to the third embodiment. The flow of the reference vehicle type selection process will be described with reference to FIGS.

  CPU11 takes out a record from vehicle type DB by using an input vehicle type as a key. The CPU 11 refers to the OEM field of the retrieved record to determine whether or not the input vehicle type has a vehicle type that is the prototype of the partner brand supply (step S551). If it is determined that there is a prototype vehicle type (YES in step S551), the CPU 11 retrieves a record from the vehicle model DB using the prototype vehicle type as a key, refers to the index field, and determines whether an index has been created. Determination is made (step S552).

  If it is determined that an index has been created (YES in step S552), the CPU 11 determines the vehicle model that is the prototype of the partner brand supply as a reference vehicle model (step S553). CPU11 complete | finishes a process after that.

  When it is determined that there is no vehicle model that is the prototype of the partner brand supply (NO in step S551), and when it is determined that the index of the vehicle model that is the prototype of the partner brand supply is not stored in the auxiliary storage device ( In step S552, NO), the CPU 11 refers to the state field of the record of the input vehicle type and determines whether or not the vehicle type is a past sales vehicle (step S555). If it is determined that the vehicle has been sold in the past (YES in step S555), the CPU 11 determines whether or not there is a vehicle type after the minor change (step S556).

  The following procedure is used to determine the presence or absence of a vehicle after a minor change. The CPU 11 searches the previous field of the vehicle type DB using the input vehicle type as a key. When there is a record in which the input vehicle type is described in the previous field, the CPU 11 refers to the status field of the record. When “minor change” is recorded in the state field, the CPU 11 determines that there is a vehicle type after the minor change.

  When it is determined that there is a vehicle type after the minor change (YES in step S556), the CPU 11 determines whether or not the index of the vehicle type after the minor change is stored in the auxiliary storage device (step S557). The presence / absence of an index of the vehicle type after the minor change is determined by referring to the index field of the record of the vehicle type after the minor change.

  When it is determined that there is no vehicle type after the minor change (NO in step S556), and when it is determined that the index of the vehicle type after the minor change is not created (NO in step S557), the CPU 11 determines whether there is a vehicle type before the minor change. (Step S558). The presence / absence of the vehicle type before the minor change is determined from the record in the previous field of the record of the input vehicle type. If it is determined that there is a vehicle type before the minor change (YES in step S558), the CPU 11 retrieves the record from the vehicle type DB using the vehicle type before the minor change as a key, and refers to the index field to assist the index of the vehicle type before the minor change. It is determined whether or not it is stored in the storage device 13 (step S559).

  If it is determined that the index of the vehicle type after the minor change is stored in the auxiliary storage device 13 (YES in step S557), the CPU 11 determines the minor change vehicle type as the reference vehicle type (step S560). Also, when it is determined that the index of the vehicle type before the minor change is stored in the auxiliary storage device (YES in step S559), the CPU 11 determines the minor change vehicle type as the reference vehicle type (step S560). CPU11 complete | finishes a process after that.

  When it is determined that the input vehicle type is the current vehicle type (NO in step S555), the CPU 11 refers to the state field of the input vehicle type to determine whether the input vehicle type is a minor change vehicle (step S571). When it is determined that the vehicle is a minor change vehicle (YES in step S571), the CPU 11 determines whether or not the index of the vehicle type before the minor change is stored in the auxiliary storage device 13 (step S572). The determination is performed by searching the vehicle type DB using the vehicle type before the minor change recorded in the previous field of the record of the input vehicle type as a key, taking out the record, and referring to the index field.

  If it is determined that the index of the vehicle type before the minor change is stored in the auxiliary storage device (YES in step S572), the CPU 11 determines the vehicle type before the minor change as the reference vehicle type (step S573). The CPU 11 thereafter ends the process.

  If it is determined that the input vehicle type is not a minor change vehicle (NO in step S571), the CPU 11 determines whether the input vehicle type is a full model change vehicle (step S574). The determination is made with reference to the status field of the input vehicle type record.

  If it is determined that the input vehicle type is a full model change vehicle (YES in step S574), the CPU 11 determines whether there is a vehicle type of the same series (step S575). The determination is made by referring to the vehicle type field of the vehicle type DB and determining whether or not there is a vehicle type that is part of the vehicle type, for example, the vehicle type having the same two characters from the front. Note that a field for recording the series name of the vehicle type may be provided in the vehicle type DB for reference.

  Also, when it is determined that the input vehicle type is a past sales vehicle and there is no vehicle type before the minor change (NO in step S558), the CPU 11 determines whether there is a vehicle type of the same series (step S575). Even when it is determined that the input vehicle type is a past sale vehicle and the index of the vehicle type before the minor change is not stored in the auxiliary storage device (NO in step S559), the CPU 11 determines whether there is a vehicle type of the same series (step S575). ).

  When it is determined that there is a vehicle type of the same series (YES in step S575), the CPU 11 determines whether or not an index of the vehicle type of the same series has been created (step S576). If it is determined that an index has been created (YES in step S576), the CPU 11 determines the vehicle type of the series as a reference vehicle type (step S577). The CPU 11 thereafter ends the process.

  When it is determined that there is no vehicle type before the minor change in which an index has been created for the input vehicle type (NO in step S572), the CPU 11 determines whether there is an appropriate vehicle type for the reference vehicle type of the same manufacturer model (step S591). ). Even when it is determined that the input vehicle type is not a full model change vehicle (NO in step S574), the CPU 11 determines whether there is an appropriate vehicle type for the reference vehicle type of the same manufacturer (step S591). Even when it is determined that the input vehicle type is a fully remodeled vehicle and there is no vehicle of the same series (NO in step S575), the CPU 11 determines whether there is an appropriate vehicle type for the reference vehicle type of the same manufacturer's model (step). S591). Even when it is determined that there is no vehicle model for which an index is created in the same model as the input model (NO in step S576), the CPU 11 determines whether there is an appropriate model for the reference model among the models of the same manufacturer ( Step S591).

  In step S591, the appropriate vehicle type is, for example, a vehicle type whose vehicle dimensions are close to the input vehicle type, a vehicle type having the same body shape and the same number of doors, a vehicle type having the same drive system and engine, or the like. In step S591, a plurality of vehicle types may be selected as appropriate vehicle types.

  If it is determined that the manufacturer has an appropriate vehicle type (YES in step S591), the CPU 11 determines whether the vehicle type extracted in step S591 includes a vehicle type whose index is stored in the auxiliary storage device. (Step S592). If it is determined that the vehicle type in which the index is stored is included in the auxiliary storage device (YES in step S592), the CPU 11 determines the vehicle model with the largest number of vehicles sold as the reference vehicle type among the stored indexes. Step S593). The CPU 11 thereafter ends the process.

  If it is determined that the vehicle type extracted in step S591 does not include a vehicle type whose index is stored in the auxiliary storage device (NO in step S592), and it is determined that there is no appropriate vehicle type for the reference vehicle type of the same manufacturer model. In the case (NO in step S591), the CPU 11 determines whether or not there is an appropriate vehicle type as a reference vehicle type among other manufacturer's vehicle types (step S601). An appropriate vehicle type determination criterion in step S601 is the same as in step S591.

  If it is determined that another manufacturer has an appropriate vehicle type (YES in step S601), the CPU 11 determines whether the vehicle type extracted in step S601 includes a vehicle type whose index is stored in the auxiliary storage device. (Step S602). If it is determined that the vehicle type for which the index is stored is included in the auxiliary storage device (YES in step S602), the CPU 11 determines the vehicle model with the largest number of vehicles sold as the reference vehicle type among the indexes stored ( Step S603). The CPU 11 thereafter ends the process.

  If it is determined that the vehicle type extracted in step S601 does not include the vehicle type whose index is stored in the auxiliary storage device (NO in step S602), and it is determined that there is no appropriate vehicle type for the reference vehicle type from another manufacturer's vehicle type. In the case (NO in step S601), the CPU 11 accepts an input of the reference vehicle type by the user from the input unit 14 (step S604). The CPU 11 thereafter ends the process.

  According to the present embodiment, it is possible to provide an estimation device 10 that can perform estimation using an appropriate reference vehicle model without preparing the reference DB 131 in advance.

  Note that a reference DB 131 with no records recorded or an insufficient number of recorded records is prepared in advance, and the CPU 11 adds the reference vehicle type determined in the reference vehicle type selection subroutine to the reference DB 131. Also good. In this case, it is desirable that the CPU 11 receives the reason for determining the reference vehicle type from the input unit 14 and records it in the reason field of the record to be added to the reference DB 131. By doing in this way, CPU11 can record the knowledge and experience of the user who has abundant knowledge about a vehicle, and can produce | generate reference DB131 like what was used in Embodiment 1. FIG.

  In this case, it is desirable to record the history of correction and additional writing of the reference DB 131 by providing a history field in the reference DB 131 or by providing a separate log file. The matters to be recorded include, for example, matters that have been corrected or added, users who have made corrections or additions, the date and time of correction or addition, and the like.

  The CPU 11 may acquire the reference vehicle type with reference to the reference DB 131 between step S502 and step S531.

[Embodiment 4]
The fourth embodiment relates to a mode for realizing the estimation device 10 by operating a general-purpose computer 46 and an estimation program 47 in combination. FIG. 11 is a device configuration diagram of the estimation device 10 according to the fourth embodiment. The configuration of this embodiment will be described with reference to FIG. Note that description of portions common to the first embodiment is omitted.

  The estimation apparatus 10 according to the present embodiment includes a general-purpose computer 46 including a CPU 11, a main storage device 12, an auxiliary storage device 13, an input unit 14, an output unit 15, a display unit 16, a communication module 17, a reading unit 18, and a bus. use.

  The estimation program 47 is recorded on the portable recording medium 48. The CPU 11 reads the estimation program 47 via the reading unit 18 and stores it in the auxiliary storage device 13. The CPU 11 may read the estimation program 47 stored in the semiconductor memory 49 such as a flash memory installed in the computer 46. Further, the CPU 11 may download the estimation program 47 from the communication module 17 and another server computer (not shown) connected via a network (not shown) and store it in the auxiliary storage device 13.

  The computer 46 reads the estimation program 47 for executing the above-described various software processes from the portable recording medium 48 or the semiconductor memory 49, or downloads it from another server computer via a network. The estimation program 47 is installed as a control program for the general-purpose computer 46, loaded into the main storage device 12, and executed. Thereby, the computer 46 functions as the estimation device 10 described above.

  Each DB and index shown above may be read via the communication module 17 from a storage device (not shown) connected to the network.

The technical features (components) described in each embodiment can be combined with each other, and new technical features can be formed by combining them.
The embodiments disclosed herein are illustrative in all respects and should not be considered as restrictive. The scope of the present invention is defined not by the above-described meaning but by the scope of the claims, and is intended to include all modifications within the meaning and scope equivalent to the scope of the claims.

10 Estimator 11 CPU
12 Main storage device 13 Auxiliary storage device 131 Reference DB
DESCRIPTION OF SYMBOLS 14 Input part 15 Output part 16 Display part 17 Communication module 18 Reading part 21 Description column 22 Vehicle information column 23 Reference column 24 Reason column 25 Return button 26 Change button 27 Estimate button 46 Computer

Claims (8)

Obtain the first model for the item for which the repair estimate is to be made,
Determining whether information relating to the repair associated with the first type is stored in advance;
If it is determined that the information is not stored, the second type related to the article that can use the information stored in association for the repair estimate of the article is the first type or the first type. A program for causing a computer to execute a process of displaying based on characteristics of an article of one type.   The program according to claim 1, wherein the program causes the computer to execute a process of displaying a reason for selecting the second type.   3. The program according to claim 1, wherein the computer executes a process of performing a repair estimate using the information associated with the second type. 4. The article is an automobile;
The program according to any one of claims 1 to 3, wherein the information is an index related to automobile repair.   The relationship between the first model and the second model is that the model of the partner brand supply product and the model of the product that is the prototype of the model, the model of the old product and the model of the successor product, or the same series The program according to any one of claims 1 to 4, wherein the program is a type relationship between products belonging to the category.   The program according to any one of claims 1 to 5, which causes a computer to execute a process of storing the first type and the second type in association with each other. Obtain the first model for the item for which the repair estimate is to be made,
Determining whether information relating to the repair associated with the first type is stored in advance;
If it is determined that the information is not stored, the second type related to the article that can use the information stored in association for the repair estimate of the article is the first type or the first type. An estimation method that causes a computer to execute a process of displaying based on characteristics of an article of one type. An acquisition unit that acquires a first type of an article for which a repair estimate is to be made, a determination unit that determines whether or not information relating to repair associated with the first type is stored in advance, and the information is not stored If it is determined that the second type related to the article that can use the information stored in association with it for the repair estimate of the article, the first type or the characteristics of the first type of article And a display unit for displaying based on the estimation device.

Images