JP2005227881A - Maintenance information supply server - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To share information on troubles of products in common via a network, and to effectively collect trouble information. <P>SOLUTION: Client terminals 100a to 100d installed on service facilities or the like input the trouble information on products to a maintenance information supply server 150 by associating with maintenance information. The maintenance information supply server 150 provides the input trouble information together with the maintenance information to each of the client terminals 100a to 100d. Thus, the plurality of client terminals 100a to 100d can share trouble information in common. Further, the maintenance information supply server 150 registers the trouble information on trouble information management database 171 by receiving the trouble information through the client terminal when placing an order for components. <P>COPYRIGHT: (C)2005,JPO&NCIPI

Description

  The present invention relates to a system for providing product maintenance information, and more particularly, to a system for providing failure information of the product in association with the maintenance information.

  Conventionally, maintenance manuals for automobiles and the like have been provided using paper as a medium. However, the paper maintenance manual is inconvenient because it takes time to reach the required page.

Therefore, a technique has been proposed in which a maintenance manual is digitized and distributed to general consumers via a network (Patent Document 1).
Japanese Patent Application Laid-Open No. 2002-117038.

  By the way, the timing when product maintenance is required is during periodic inspections or product failures.In particular, in the case of a failure, the service engineer refers to the maintenance manual, and what parts are responsible for what cause. You must consider whether it is broken.

  If the service factory in charge of maintenance has dealt with similar failure cases in the past, it will be possible to deal with this failure case smoothly based on the experience at that time. However, in the case of a failure case that is experienced for the first time, the service engineer must investigate the cause of the accident and search for a countermeasure method by relying only on his / her ability, which is a heavy burden. In this case, it will take more time than necessary to resolve the failure.

  On the other hand, if it is a global product sold on a nationwide or global scale, there is a possibility that a solution for the trouble that has become a problem has been established at some service factory. If the solution can be shared among different service factories, the efficiency of fault maintenance will be greatly improved.

  Conventionally, however, information on the failure of a product has been accumulated only at the service factory where the failed product was brought in, except for a serious failure. For this reason, failure information cannot be shared among a plurality of different service factories.

  As described above, there has been a problem that cannot be solved simply by digitizing the maintenance manual.

  Furthermore, when the maintenance manual is read and the parts necessary for repair are found, it is necessary to start the parts ordering system and place an order for the parts. That is, there is no system that can be executed seamlessly even though grasping of parts necessary for repair and order processing are mutually related processes.

  By the way, in the present invention, failure information can be provided together with maintenance information. From the viewpoint of registering this failure information, it is a good opportunity to efficiently collect failure information when ordering parts.

  Accordingly, the present invention aims to solve at least one of these problems and other problems. Other issues are described below.

  In order to solve the above problems, the present invention provides a maintenance information providing system that provides maintenance information of a predetermined product to a plurality of client terminals connected via a network, for example, for a plurality of products of different types. , Maintenance information storage means for storing maintenance information for each of a plurality of functional parts constituting the product, and failure information input from any of the client terminals with respect to any of the functional parts, corresponding to the functional parts Corresponding to the received transmission request, the failure information storage means to be attached, the receiving means for receiving the maintenance information transmission request for any of the functional parts from any of the client terminals, The maintenance information on the functional part is read from the maintenance information storage means, and the failure information on the functional part is read from the failure information storage means. A maintenance information providing system comprising: transmission means for transmitting, to the client terminal that has transmitted the transmission request, screen information for causing the client terminal to display the content or presence of the failure information together with the maintenance information. Further, means for receiving an order request for any of the parts constituting the product from any of the client terminals, and upon receipt of the order request, transmits an input request for failure information of the part relating to the order request. Means for storing the failure information input in response to the input request in the failure information storage means.

  According to the present invention, failure information can be efficiently collected by guiding the user to register failure information when placing an order for a part. If the registration of failure information is freely left to a user such as a service engineer, failure information may not be collected sufficiently. For example, a user who thinks troublesome registration of failure information will not register failure information. On the other hand, the timing for ordering parts is often when a part fails. Therefore, when ordering a part, there is a high possibility that the user grasps some failure information. Therefore, failure information can be input at the time of ordering parts, so that failure information collection efficiency will be improved.

  On the other hand, when referring to maintenance information or failure information, it is often considered that the failure is for repair. At that time, if the failure information or the maintenance information teaches that the countermeasure for the failure is the replacement of the part, it would be convenient if the part necessary for the repair can be ordered from the screen. Therefore, according to the present invention, parts can be ordered if necessary when referring to maintenance information or failure information.

  In the present invention, when information necessary for ordering a part is input, at least a part of the failure information for the part to be ordered is created based on the information or the already registered failure information. I made it. Thereby, the trouble of inputting failure information can be reduced. For example, a part of the failure information is created by specifying information on the type or functional part of the product based on the part identification information.

  Further, it is possible to further assist the input of the failure information by estimating at least a part of the failure information related to the part based on the registered failure information and the part identification information related to the order request. For example, if there is a statistically high probability that a specific failure will occur for a certain part, the failure information may be adopted.

  Note that failure information automatically created is not always correct. Therefore, an opportunity for correction can be given by presenting a correction screen for the created failure information to the user. This will allow correct fault information to be collected.

  In addition, information on related parts that are likely to be ordered together with a part is stored, and when ordering a part, information on the relevant part is guided to provide a series of information necessary for repair. Parts can be ordered in a batch.

  In addition, the number of failure occurrences is obtained from the number of orders of a certain part, and the number of failure occurrences obtained is displayed together with maintenance information or the like, so that the number of failure occurrences can be confirmed. As a result, for failures with a large number of occurrences, prior measures can be taken even before the occurrence of failures.

  In addition, when the failure information input in connection with the order request and the component information related to the order request are stored in association with each other, and a failure information transmission request is received from another client terminal or the like In addition to failure information, it also provides component information. That is, when certain failure information is referred to, the information on the parts necessary for repair is provided, so that the ordering efficiency of the parts and the repair efficiency are improved.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings.

  FIG. 1 is a diagram illustrating an example of a maintenance information providing system according to an embodiment. Reference numerals 100a to 100d denote client terminals such as personal computers. Each client terminal is located at a dealer, service factory, manufacturer, supplier, or the like. The client terminals 100a to 100d are connected to the maintenance information providing server 150 via a network such as the Internet. The client terminal may be a general desktop computer or mobile computer as long as it can execute a computer program capable of realizing the present invention described below. Of course, a dedicated terminal for executing the processing described below may be used. In short, any computer may be used as long as each function according to the present embodiment can be realized.

  The maintenance information providing server 150 also includes a maintenance information management database 170 that stores maintenance information, a failure information management database 171 that stores failure information registered from any client terminal, and authentication of a user who uses the client terminal. A user management database 172 for managing information and the like, an order management database 173 for managing part order data, and the like are provided. Note that these databases may be realized by a database server on a computer physically different from the maintenance information providing server 150.

  FIG. 2 is a diagram illustrating a hardware configuration example of each device according to the embodiment. The client terminals 100a to 100d include a central processing unit (CPU) 201. The CPU 201 executes various processes and controls based on computer programs stored in the ROM 202 and the hard disk drive (HDD) 204. As these control programs, there are a WEB client (so-called browser) program, an e-mail client program, and the like for executing appropriate processing according to a flowchart described later. Temporary data is stored in the RAM 203 that functions as a work area. The display device 205 is a liquid crystal display or a CRT. The operation unit 206 is an input / output device such as a keyboard and a pointing device. The network interface 207 is a communication circuit for connecting to a network such as the Internet. The automobile interface 208 is a communication circuit for communicating with a computer mounted on the automobile.

  On the other hand, the server 150 includes a central processing unit (CPU) 221 that executes various processes and controls based on computer programs stored in the ROM 222 and the hard disk drive 224. Examples of the control program include various scripts such as a WEB server program, a CGI program, an e-mail server program, an HTML file, and a Java (registered trademark) script. The server 150 is also provided with a display device 225, which displays processing contents, processing results, and the like. An operation unit 226 such as a touch panel device, a numeric keypad, and a pointing device is also provided. Further, the CPU 221 transmits / receives data to / from other devices such as the client terminal 100 via the communication interface circuit 227.

FIG. 3 is a flowchart illustrating failure information registration processing according to the embodiment.
In step S300, failure information is input from any of the client terminals 100a to 100d. For example, the CPU 201 of the client terminal activates a WEB browser client program and accesses the server 150 according to the address of the server 150 input from the operation unit 206. The CPU 221 of the server 150 transmits the page requested from the client terminal. Here, it is assumed that an input page for failure information is requested. The CPU 201 receives the input page and displays it on the display device 205.

FIG. 4 is a diagram illustrating an example of a failure information input page according to the embodiment. In this example, when a vehicle name is selected using a pull-down menu in which various vehicle names are registered in advance, a corresponding model code is entered in the model code column. The pull-down menu can be realized by Java (registered trademark) Script or CGI.
The serial number is manually input from the operation unit 206 into the text box. SCT represents the highest-level functional site (eg, engine, suspension, etc.). SC represents an intermediate functional part (eg, starter, lubricator, fuel device, etc.). The part name represents the lowest functional part (eg, starter). Since both are known information, they can be selected from the pull-down menu.
The failure mode is information indicating the content of the failure such as “internal failure”, “contact failure”, “disconnection”, and can be selected from a pull-down menu. The coping method is information indicating what action has been taken for the failure, such as “part replacement” or “repair”.
The travel distance is information indicating the travel distance of the failed automobile. The malfunction phenomenon is information indicating a phenomenon that has occurred due to a malfunction, such as “engine start failure”. The occurrence status is information for specifying when a failure occurs or when a malfunction occurs. The provisionable / unavailable radio box is for designating when the registered failure information is to be disclosed. In this example, it is possible to select provision on the same day, provision after a predetermined period, necessity of registrant permission (inquiry required), and the like. Note that these are merely examples, and the information content and input method may be changed as appropriate.

  In step S <b> 302, the CPU 201 transmits the input failure information to the maintenance information providing server 150 via the network interface 207. For example, in the input page of FIG. 4, when all necessary information is input and the transmission button is pressed, the CPU 201 transmits the input information to the server 150 via the network interface 207.

  In step S <b> 304, the CPU 221 of the server 150 receives failure information via the network interface 227. In step S306, the CPU 221 registers the failure information in the failure information management database 171.

  FIG. 5 is a diagram illustrating an example of a failure information management database according to the embodiment. In addition to the information described with reference to FIG. 4, information such as an input date, a user ID, a contact e-mail address, and an affiliated company is added. As the user ID, for example, the user ID acquired in the authentication process when the client terminals 100a to 100d connect to the server 150 may be used. Information such as a user ID and a password necessary for authentication is stored in the user management database 172. As the input date, for example, the CPU 221 can acquire and set date / time data when the failure information is received from the internal timer.

  FIG. 6 is a flowchart related to a process for providing maintenance information and failure information according to the embodiment. In step S <b> 600, when the CPU 201 of any of the client terminals 100 a to 100 d is instructed by the operation unit 206 to transmit the maintenance information, the CPU 201 transmits the maintenance information transmission request to the server 150 via the network interface 207. .

  For example, when a hyperlink to the maintenance information display page described in the main page of the server 150 (for example, the menu screen of FIG. 19) is clicked, a request for the maintenance information display page is transmitted from the client terminal. . Here, it is assumed that the search condition input page is displayed before the maintenance information is displayed. The server 150 transmits a page for inputting search conditions for searching for maintenance information. The client terminal receives the search condition input page and displays it on the display device 205. Further, the client terminal transmits the search condition input from the operation unit 206 to the server 150.

  FIG. 7 is a diagram illustrating an example of an input page used when inputting the maintenance information search condition. The search condition shown in FIG. 7 sets at least one of various kinds of information as described in FIG. In addition, a search condition related to failure information such as a failure form may be input from the beginning.

  In step S <b> 602, the server 150 receives a maintenance information transmission request (for example, a search request including a search condition) via the network interface 227. In step S604, the CPU 221 of the server 150 searches for maintenance information according to the received search condition.

  FIG. 8 is a diagram illustrating an example of the maintenance information management database. A maintenance book file number (file name), an electrical wiring diagram file number (file name), and the like are stored in association with the vehicle name, model code, SCT, SC, part name, and part code. It is assumed that the maintenance book file and the electrical wiring diagram file are stored in the HDD 224 in advance.

  In step S606, the CPU 221 of the server 150 retrieves and extracts failure information corresponding to the maintenance information extracted by the search from the failure information management database 171. For example, failure information including information that matches the model code, SCT, SC, part name, part number, etc. relating to the maintenance information is extracted.

  In step S608, the CPU 221 creates screen display information by superimposing the extracted maintenance information and failure information. Display information on the screen includes HTML, image data, Java (registered trademark) Script, Macromedia Flash (registered trademark), XML, SGML, SVG (Scalable Vector Graphics), PDF, as will be described in detail below. It can be created in various formats. Note that these are merely examples, and any file format may be adopted as long as the functions of the present invention can be realized. In step S610, the CPU 221 transmits the created screen display information to the client terminal that has transmitted the transmission request.

  In step S612, the CPU 201 of the client terminal receives screen display information. In step S614, the CPU 201 causes the display device 205 to display the received screen display information.

  FIG. 9 is a diagram illustrating an example of a screen for displaying maintenance information and failure information according to the embodiment. According to the display information on this screen, the maintenance information (maintenance document drawing) that has been retrieved and extracted and the failure information such as the failure mode are displayed superimposed on one page. In the present specification, unless otherwise specified, the superimposed display refers to displaying a plurality of information simultaneously on the same screen. Therefore, not only a plurality of pieces of information are displayed in an overlapping manner but also a plurality of pieces of information are displayed with some relevance. That is, if the correspondence between the maintenance information of component parts (or functional parts) and failure information is displayed in an easy-to-understand manner, they are all displayed in a superimposed manner.

  FIG. 10 is an exemplary flowchart of a screen display information creation subroutine. In step S <b> 1000, the CPU 221 of the server 150 reads the screen display information template file from the HDD 224. The template file is a basic HTML file for providing maintenance information and failure information, for example. Of course, other types of files may be used as described above.

  In step S1002, the CPU 221 writes information on the file name and file path of the maintenance book file in the template file. In step S1004, the CPU 221 determines whether failure information corresponding to the maintenance information extracted by the search has been extracted by the search. If not extracted, the screen display information creation subroutine is terminated.

  On the other hand, if it has been extracted, the process advances to step S1006, and the CPU 221 writes the file path or link information to the extracted failure information in the template file. Here, the description has been made on the assumption that there is a file describing failure information or a WEB page, but the content (text character string) of failure information may be directly written in the template file as shown in FIG. Although the description of the template file is omitted, it goes without saying that the template file may be used.

  FIG. 11 is another exemplary flowchart of a screen display information creation subroutine. In step S1100, the CPU 221 of the server 150 reads out an image file of maintenance information (such as a maintenance explanation diagram or a wiring diagram) into the RAM 203 according to the file name extracted by the search.

  In step S1102, it is determined whether failure information has been extracted. If extraction fails, the process returns to the original process. On the other hand, if it has been extracted, the CPU 221 also reads out failure information such as a failure mode and a coping method into the RAM 203. Further, for example, maintenance information is arranged in the first layer and failure information is arranged in the second layer by using a flash of Macromedia Inc., so that both are superimposed. Of course, other image formats and image processing software may be used as long as both can be superimposed.

  FIG. 12 is a flowchart showing still another example of the display information creation subroutine for the screen. In this example, whether or not failure information has been registered for each component constituting the functional part, that is, whether or not failure information has been registered, is displayed on the functional part page. Then, specific failure information is displayed on the lower component page. That is, maintenance information and failure information are displayed hierarchically.

  In step S1200, CPU 221 of server 150 reads a template file of display information on the functional part display screen from HDD 224. In step S1202, the CPU 221 writes information on the file name and file path of the maintenance document file for the functional part in the template file. As a result, a page for displaying maintenance information on the functional part is created.

  In step S1204, the CPU 221 determines whether failure information corresponding to the maintenance information extracted by the search has been extracted. If not extracted, the process advances to step S1208 to write link information to the component page. An image representing failure information “present” is not attached to this link information. However, it goes without saying that an image indicating failure information “none” may be attached.

  On the other hand, if it has been extracted, the process proceeds to step S1206, and the CPU 221 uses an icon representing “failure information registered” and link destination information (component page, CGI, etc.) called when the icon is clicked as a template. Write to file.

  In step S <b> 1210, the CPU 221 of the server 150 reads out the template file for each component included in the functional part from the HDD 224. In step S <b> 1212, the CPU 221 writes information regarding the file name and file path of the maintenance document file of each component into the template file.

  In step S1214, the CPU 221 determines whether failure information corresponding to the maintenance information extracted by the search has been extracted by the search. If not extracted, the screen display information creation subroutine is terminated. On the other hand, if extracted, the process proceeds to step S1216, and the CPU 221 writes the file path or link information to the extracted failure information in the template file.

  In this way, the presence / absence of failure information is displayed on the upper page, and the failure information is displayed on the lower page, so that the user can easily confirm the presence / absence of failure information and the failure information is registered. It will be easier to access the component page in stages. If failure information is not registered, “None” may or may not be displayed.

  FIG. 13 is a diagram illustrating an example of stepwise display of maintenance information and failure information. In particular, FIG. 13 shows a page related to a functional part. For functional parts that have components for which failure information is registered, a star-shaped image is displayed in association with the functional part to visually identify which functional part is associated with the failure information. It is easy. When the link to the component page (the “starter” portion in the figure) is clicked on the functional part display page of FIG. 13, the client terminal displays the component page as shown in FIG. Can do.

  FIG. 14 is a flowchart showing a new failure notification subroutine. By executing this subroutine when the failure information is registered, for example, when a new failure that requires attention is generated, a notification is given to the manufacturer or the supplier of the component. As a result, the establishment of a countermeasure for a new failure will be faster than before.

  In step S1400, the CPU 221 of the server 150 determines whether or not the failure information registered from the client terminal for an arbitrary component is the same as the failure information previously registered for the component. If there is no new failure, the process returns to the original process. On the other hand, if it is a new failure, the process advances to step S1402, and the CPU 221 searches and extracts a notification destination for the component. For example, the notification destination information may be stored for each part number in the maintenance information management database 170. The notification destination is an e-mail address or a facsimile number.

  In step S1404, the CPU 221 creates a new failure mail. In the new failure mail, for example, the content of failure information determined to be a new failure is described, or a hyperlink to the failure information is described. Also, the e-mail address of the notification destination is described as the destination.

  In step S1406, the CPU 221 transmits the created electronic mail via an SMTP server (not shown).

  As described above, when a new failure occurs, it is possible to notify the manufacturer or supplier. This will be useful for dealing with failures, designing improved parts, and designing new parts.

  FIG. 15 is an exemplary flowchart regarding frequent failure notification. The frequent failure notification is, for example, a notification transmitted to alert a manufacturer, supplier, or the like when a failure having the same content exceeds a certain threshold. As a result, a method for dealing with a large number of highly important faults will be immediately considered. This subroutine can be executed not only at the time of failure information registration but also at an arbitrary timing.

  In step S1500, the CPU 221 of the server 150 searches to determine whether failure information having the same content as the registered failure information has already been registered in the failure information management database 171. If failure information having the same content is not found, for example, the above-described new failure subroutine may be executed. If failure information having the same content is found by the search, the process proceeds to step S1502, and a counter managed for each type of failure information is incremented. In step S1504, the CPU 221 determines whether or not the counter value exceeds a predetermined threshold value. Note that this threshold value may be different for each type of failure. In this case, the counter value and the threshold value for each failure type will be stored in the HDD 224 in association with each other. If it is below the threshold value, the process returns to the original process even if the sub-reach is exited.

  If it exceeds the threshold, the process advances to step S1506, and the CPU 221 extracts the destination of the frequent failure mail. This destination is stored and managed in the HDD 224 or the like in association with the type of failure. In this way, the destination of frequent failure notifications can be changed for each type of failure. In step S1508, the CPU 221 creates a frequent failure mail including the content of the failure information. In step S1510, the CPU 221 transmits the created frequent failure mail to the destination via the SMTP server.

  As described above, when a failure occurs exceeding a predetermined threshold, a warning can be given by sending a frequent failure notification, so that a fundamental countermeasure can be established at an early stage. Let's go.

  In addition, since it is considered that it is generally sufficient to notify the frequent failure notification once, it may be controlled not to transmit the frequent failure notification after being notified once. For example, notification can be substantially prohibited by setting the threshold value to a large value. Alternatively, by managing the notification availability flag for each failure type and changing the flag to “No”, the CPU 221 can notify the frequent failure notification as long as the flag is denied even if a certain type of failure occurs frequently. Can be controlled not to send.

  In addition, the threshold for frequent failure notification can be set for each failure type, but it goes without saying that the availability of notification can also be set for each failure type. Such setting information can be stored in the HDD 224 as described above.

  FIG. 16 is a flowchart of a subroutine related to customization processing for the display screen of maintenance information and failure information. That is, since the display form that feels easy to view may be different for each user, a customization function for a display screen for failure information and the like is provided.

  In step S <b> 1600, the CPU 201 of the client terminal transmits a setting screen request to the server 150. In step S1602, the CPU 221 of the server 150 receives a setting screen request.

  In step S1604, the CPU 221 transmits information for displaying the setting screen to the client terminal. In step S1606, the CPU 201 of the client terminal receives information for displaying the setting screen.

  In step S1608, the CPU 201 causes the display device 205 to display a setting screen. In step S <b> 1610, the CPU 201 selects one of the display forms in response to an instruction from the operation unit 206.

  FIG. 17 is a diagram illustrating an example of a display form setting screen. In this example, any one of a plurality of display forms can be exclusively selected using a radio box.

  In step S <b> 1612, when detecting that the setting change button is pressed, the CPU 201 transmits a setting change request including an identification code for identifying the selected display form.

  In step S1614, the CPU 221 of the server 150 changes the template file for the user based on the display form identification code included in the received setting change request. For example, when setting information for each user is stored in the user management database 172, the setting information is changed according to a setting change request.

  As described above, the user can change the display form of the maintenance information and the failure information according to his / her preference.

  FIG. 18 is a flowchart showing another example of the failure information registration process. In this example, the failure information is registered while referring to the maintenance information on the component or functional part that is the registration target of the failure information. Since the parts to be registered can be visually confirmed, the user can feel secure.

  FIG. 19 is a diagram illustrating an example of a menu screen relating to provision of maintenance information and failure information. This menu screen is a screen that is displayed after the user ID and password are entered. In this example, maintenance information display, failure information display, parts ordering, setting change, and the like can be selected.

  In step S1800, the CPU 201 of the client terminal makes a transmission request for maintenance information. For example, in the exemplary menu screen shown in FIG. 19, when “display maintenance information” is selected and the execution button is operated, a maintenance information transmission request is transmitted.

  In step S1802, the CPU 221 of the server 150 transmits display information of a search condition input screen related to maintenance conditions as shown in FIG. When receiving the display information of the input screen, the CPU 201 of the client terminal displays it on the display device 205. When a search condition is input from the operation unit 206, the CPU 201 transmits the search condition to the server 150. In step S1804, the CPU 221 of the server 150 searches for maintenance information according to the search condition. In step S1806, the CPU 221 creates screen display information for displaying maintenance information. As described above, an HTML file or the like is created. In step S1808, the CPU 221 transmits screen display information to the client terminal.

  In step S1810, the CPU 201 of the client terminal receives screen display information. In step S1812, the CPU 201 displays the received screen display information on the display device 205. An example of the maintenance information display screen is as shown in FIGS. In step S1814, when an image portion of a component that is part of maintenance information is selected by the pointing device, the CPU 201 displays a message as to whether or not to register failure information.

  FIG. 20 is a diagram illustrating an example of a screen for selecting whether or not to register failure information. This screen is displayed when, for example, a component is selected and double-clicked or right-clicked. Here, when a “high” button, which means that failure information is registered, is clicked, the failure information registration process described with reference to FIG. 3 is executed.

  As described above, according to the present embodiment, since maintenance information is displayed and a component to be registered for failure information can be selected while visually checking, there is an advantage that failure information can be easily registered. .

  FIG. 21 is an exemplary flowchart regarding a failure information search subroutine. If a lot of failure information is registered for certain maintenance information, the information without a display screen becomes complicated, and the usability may be reduced. Therefore, not all fault information is provided, but a part of the fault information is provided to improve user convenience.

  In step S2100, the CPU 221 determines whether or not an instruction from the client terminal has been given regarding the selection of failure information. For example, in the maintenance information search condition input screen shown in FIG. 7, if a check box of “select failure information” is checked, it is determined that there is a selection instruction.

  In step S2102, the CPU 221 sets a selection rule. The selection rule may be set by reading from the user management database 172 and set in advance for each user, or may be set by inquiring the client terminal dynamically.

  FIG. 22 is a diagram showing an example of a screening rule inquiry screen. In this example, the product production number, production date, grade, presence / absence of accessories, usage status, usage environment, the number of occurrences of failures of the same content, etc. are shown as selection rules.

  When the production number is designated, failure information relating to the product of the production number having a predetermined relationship with the production number of the product designated by the user is selected. The predetermined relationship is, for example, 1000 units before and after the designated production number. Note that the serial number range may be specified from the client terminal.

  When the production date is designated, only failure information relating to the product having the predetermined relationship with the production date of the product related to the maintenance information transmission request is selected. The predetermined relevance is, for example, 90 days before and after a specified manufacturing date. Note that the range of the manufacturing date may be specified from the client terminal.

  When the grade is specified, only the failure information of the product with the same grade of the product related to the maintenance information transmission request is selected. For example, if the grade of a certain product is different, the specifications of the equipment and the engine may be different. Therefore, when obtaining failure information of a product close to the target product, it may be effective to select the failure information based on the grade. In the example of FIG. 22, a grade is selected by a pull-down menu.

  In addition, it is a product of the same grade, and the equipment may differ depending on the presence or absence of a dealer option. Therefore, by specifying the accessory, it is possible to select only the failure information of the product having the same accessory part. In the example of FIG. 22, an accessory can be designated by inputting the name or part number of the accessory.

  When the usage status is specified, only the failure information of the product having the same or similar usage status as the usage status of the product related to the maintenance information transmission request is selected. The usage status refers to the travel distance, vehicle speed, uphill slope, etc. when a failure occurs. In addition, since data such as travel distance rarely match completely between different vehicles, data within a certain range may be selected as similar. In the example of FIG. 22, the usage status can be entered in a text box.

  When the usage environment is specified, only failure information of products having the same or similar usage environment as the usage environment of the product related to the transmission request is selected. The use environment means a geographical or climatic environment such as a cold region, a non-cold region, a coastal area, and an urban area. In the example of FIG. 22, the use environment can be selected by a pull-down menu.

  When the number of occurrences is designated, failure information is sorted based on the number of occurrences of the same content. For example, if the number of cases is designated as “10 or more”, minor failure information can be eliminated.

  In FIG. 22, when the execution button is clicked, the CPU 201 of the client terminal transmits the designated selection rule and the input specific condition to the server 150.

  In step S2104, the CPU 221 adds the received selection rule to the failure information search condition. In this search condition, information such as a model code initially specified from the client terminal is set in advance. In step S2106, the CPU 221 searches for failure information in detail according to the set search condition.

  The failure information sorting process may be executed from the maintenance information display screen shown in FIG. For example, when failure information sorting is designated by right-clicking or the like on the maintenance information display screen, the CPU 201 of the client terminal transmits a sorting instruction. Upon receiving this sorting instruction, the CPU 221 determines that there is a maintenance information sorting instruction, and transmits the input screen of FIG. Subsequent processing is as described above.

  As described above, by introducing the failure information selection process, the user can select and display only the failure information closer to the desired one.

  Depending on the setting of the selection rule described above, the failure information to be displayed may be unexpectedly reduced. Therefore, it would be convenient to be able to additionally display other failure information that has been omitted from the selection. Hereinafter, the additional display process will be described.

  FIG. 23 is an exemplary flowchart of the failure information addition display process. In addition, about the process similar to the already demonstrated process, description is abbreviate | omitted by attaching | subjecting the same referential mark.

  In step S2300, the CPU 201 of the client terminal transmits a failure information addition display request. For example, when it is detected that an additional display button provided on the failure information display screen is operated, the additional display request is transmitted.

  In step S2302, the CPU 221 of the server 150 receives the additional display request. In step S2304, the CPU 221 determines a search condition for re-search. For example, a part or all of the search condition based on the selection rule is deleted from the previous search condition. The client terminal may be inquired which search condition should be deleted.

  In step S2306, the CPU 221 executes a re-search based on the new search condition. The subsequent steps are as described with reference to FIG.

  As described above, when the display request for failure information other than the failure information transmitted to the client terminal is received from the client terminal, the server 150, in response to the display request, among the plurality of failure information regarding the functional part and the component parts, Failure information can be read out and display information on the screen can be created and provided. That is, by starting the additional display process, it is possible to display failure information that has been omitted from the selection.

  When failure information is searched for the same product, sufficient failure information may not be obtained. However, in the case of a product such as an automobile, common parts are often used between different vehicle types. Therefore, there is a possibility that the failure information of the parts is sufficiently registered for other vehicle types. Therefore, it is possible to provide failure information of similar products that employ common parts.

  FIG. 24 is an exemplary flowchart regarding search processing including failure information for similar products. This failure information retrieval subroutine corresponds to step 606 in FIG.

  In step S2400, the CPU 221 searches and extracts a product code of a similar product based on a product code (for example, a model code) included in the maintenance information or failure information search condition received from the client terminal. For example, if an identification number is assigned to a similar product group in advance and a product code belonging to the similar product group is stored in the HDD 224 in association with the identification number, the product code of the similar product can be easily searched. .

  In step S2402, the CPU 221 sets the product code designated from the client terminal and the product code of the similar product as search conditions.

  In step S2404, the CPU 221 sets additional search conditions if necessary (optional). For example, functional parts or components provided by the same supplier, manufacturing date, serial number, product classification (eg sedan, one box, etc.), usage status, usage environment, grade, optional equipment, etc. Good. This may be set by inquiring the client terminal, or may be set in advance. By setting additional search conditions, it is possible to avoid a situation where failure information more than necessary is extracted.

  In step S2406, the CPU 221 searches for failure information according to the set search condition. As described above, it is possible to broadly extract and display failure information by expanding the search range to similar products.

  In addition, when the CPU 221 determines that failure information has not been found for the designated product, control may be performed so as to search for failure information about similar products. Such an enlarged search process may be applied to a designated functional part or a designated component part.

  FIG. 25 is an exemplary flowchart of an expansion search process executed when failure information about a specified product / functional part / component is not found. Description of processing common to FIG. 24 is omitted.

  In step S2500, the CPU 221 sets the product code of the product designated from the client terminal and the part code (for example, SCT, SC, part number) as search conditions. In step S2502, the CPU 221 sets additional conditions. The setting of the additional condition is as described in step S2404 above.

  In step S2504, the CPU 221 searches for failure information. In step S <b> 2506, the CPU 221 determines whether failure information about the designated product has been extracted. If it has been extracted, the process returns to the original process. On the other hand, if failure information is not extracted, processing corresponding to steps S2400, S2402, and S2406 is performed to search for failure information about similar products.

  As described above, when failure information is not extracted for a desired product, it is possible to avoid a situation in which a large amount of failure information is displayed unnecessarily by expanding the search range.

  Note that when registering the failure information, the user may specify whether or not the failure information is to be subjected to an enlarged search. That is, the failure information about the predetermined product or the predetermined functional part is designated as the failure information for specifying whether or not the failure information about the other product or the other functional part is requested. It is transmitted from the client terminal to the server 150 when information is registered. When receiving this designation information, the server 150 registers the designation information in the failure information management database 171. When the enlarged search is started, the CPU 221 searches and extracts only the failure information whose designation information is “provided”.

  By the way, when failure information is displayed for similar products as well as specified products, there is a case where it is desired to distinguish between the two. This is because the failure information for the designated product more closely matches the user's search request. Therefore, in the present embodiment, failure information of the designated product is preferentially displayed.

  FIG. 26 is a flowchart regarding priority display of failure information. In addition, about the process which is common in FIG. 10, description is abbreviate | omitted by attaching | subjecting the same referential mark.

  After the processing from step S1000 to step S1006, the CPU 221 creates display information for the priority display screen in step S2600. For example, the display colors of the specified product failure information and other failure information are made different. Alternatively, the designated failure information may be displayed in a higher order. In addition, normally, only failure information about a specified product may be displayed, and failure information about a similar product or the like may be displayed when an additional display button is pressed. In this way, differentiation between the two can be achieved. When changing the display color, for example, the CPU 221 may change the color tag in the HTML file. The change of the display order can also be realized by the CPU 221 sorting the order of the failure information paths in the HTML file. Further, the display / non-display switching of failure information of similar products may be performed by the CPU 221 changing and transmitting the HTML file in response to a display / non-display request transmitted from the client terminal.

  FIG. 27 is an exemplary flowchart regarding order processing. Generally, when ordering a part, the part often fails. On the other hand, failure information registration for parts has properties similar to writing on a bulletin board, so failure information is not always effectively registered in the database. Therefore, in the present embodiment, failure information can be input when placing a part order.

  In step S 2700, when the CPU 201 of the client terminal detects that an order request has been input from the operation unit 206, the client terminal CPU 201 transmits the order request via the network interface 207. For example, when an order button provided on the maintenance information display screen is operated, an order request is transmitted.

In step S2702, when CPU 221 of server 150 receives the ordering request, in step S2704, CPU 221 transmits screen display information for inputting ordering information. In step S2706, the CPU 201 of the client terminal displays the input screen on the display device 205 when receiving the display information of the input screen.
FIG. 28 is a diagram illustrating an example of an order information input screen. On this input screen, order information necessary for specifying a part to be ordered, such as a car name and a part number, is input. In step S <b> 2708, the CPU 201 transmits the order information input from the operation unit 206 to the server 150.

  In step S2710, when receiving the ordering information, the CPU 221 estimates a part of the failure information from the information included in the ordering information in step S2712 (optional). Thereby, at least a part of the failure information to be registered is created, and the user's input effort can be reduced.

  In step S2714, the CPU 221 transmits display information of the failure information input screen to the client terminal. When step S2710 is executed, the estimated failure information is included in the display information of the failure information input screen.

  In step S <b> 2716, the CPU 201 receives display information of the failure information input screen and displays the display information on the display device 205. As the failure information input screen, for example, the screen shown in FIG. 4 can be considered. In step S <b> 2718, the CPU 201 transmits failure information input from the operation unit 206 to the server 150.

  When the failure information is input when the failure information estimated in advance is input, the user can appropriately add and correct the information and transmit it. Since part of the failure information has already been input, there is an advantage that the user's input effort is reduced.

  A registration unnecessary button may be provided on the failure information input screen. When the button is operated, the CPU 201 transmits a failure information registration unnecessary request. In this way, when ordering a part due to a common failure or a cause other than the failure, it may be user-friendly to omit the input of the cause of the failure.

  In step S2720, when receiving the failure information, the CPU 221 registers the failure information in the failure information management database 171. In step S2722, the ordering process is executed by registering ordering information in the ordering management database 173. The CPU 221 may create an e-mail including ordering information and send it to the component supplier.

  As described above, it is considered that failure information can be efficiently registered in the database by enabling failure information to be registered at the time of order processing. In addition, by estimating a part of the failure information from the ordering information, it is possible to reduce user input.

  FIG. 29 is an exemplary flowchart of the failure information estimation process. In step S2900, the CPU 221 reads failure-related information useful for estimating failure information from information included in the ordering information. The failure-related information is, for example, a car name or a part number.

  In step S2902, the CPU 221 specifies a product code (for example, a model code) and an identification code of a functional part in which a part to be ordered is adopted based on the failure related information. The model code can be specified from the vehicle name, and the functional part identification code can be specified from the part number. This is because the correspondence between these codes is registered in the maintenance information management database 170, the failure information management database 171 or the like, or in a component management database (not shown).

  In step S2904, the CPU 221 estimates the failure information of the part to be ordered by searching and extracting the failure information registered in the failure information management database 171 based on these identified identification codes. With the above processing, it is possible to estimate the failure information about the part to be ordered.

  Next, the ordering process for other parts related to the failed part will be described. In general, when a component fails, a plurality of components are often replaced at the same time. In that case, if you are skilled, you can order all the parts needed for repair, but there may be others who do not. In such a case, if information on other parts related to the contents of the failure can be guided to the user, the ordering efficiency can be improved and the time required for repair can be reduced. Therefore, in this embodiment, when ordering information is registered together with failure information for a certain part, related parts are also guided.

  FIG. 30 is an exemplary flowchart of an ordering process for related parts. This process is executed as a subroutine in the ordering process (S2720), for example.

  In step S3000, the CPU 221 creates guide screen display information for guiding related parts. For example, the CPU 221 searches and extracts from the order management database 173 the part codes of related parts that have been ordered in the past in relation to the failure information, based on the ordered part code and the failure information input in the above-described processing. . And the display information of the guidance screen including the part code, part name, etc. of the extracted related parts is created. In step S3002, the CPU 221 transmits display information of the created guidance screen to the client terminal.

  In step S3004, the CPU 201 of the client terminal receives the display information of the guidance screen and displays it on the display device 205.

  FIG. 31 is a diagram showing an example of an ordering guidance screen relating to related parts. In this example, guidance information on related parts is included in addition to the part name, part number, and failure information of the ordered part.

  In step S3006, when the CPU 201 detects an operation of an order request button for related parts (for example, the “Yes” button in FIG. 31), the CPU 201 transmits an order request for the related parts. Note that when pressing of the “No” button is detected, information indicating that no order is required is transmitted to the server 150. In this case, the server 150 ends the ordering process without placing an order for related parts.

  In step S3008, when the CPU 221 of the server 150 receives the order request for the related parts, in step S3010, the CPU 221 creates and transmits an e-mail for ordering the related parts from the supplier.

  In step S3012, the order history data in the order management database 173 is updated. As described above, when failure information is registered at the time of ordering a certain part, the related part is guided based on the past ordering history so that the user can place an order without forgetting the related part. .

  By the way, when ordering parts, failure information may not be registered. For example, if the target method is sufficiently established, failure information with the same contents will not be registered. However, it is also necessary to grasp how much a failure with the same content has occurred. For example, if there are frequent failures, a fundamental solution is necessary. As described above, the part is ordered when a failure occurs in the part. Therefore, in this embodiment, the approximate number of occurrences of failure is obtained from the number of orders for each part, and the number of occurrences of failure is provided together with maintenance information and failure information.

  FIG. 32 is an exemplary flowchart regarding the process of estimating the number of occurrences of failures. The estimation process may be executed after the ordering process is completed, but may be executed at an arbitrary timing.

  In step S 3200, the CPU 221 counts the number of orders for each part registered in the order management database 173 or each part registered in the failure information management database 171.

  In step S3202, the CPU 221 multiplies the counted order quantity by a predetermined coefficient (optional). The reason why the predetermined coefficient is used is that the number of parts ordered and the number of occurrences of failure do not necessarily match, and it is necessary to adjust both to bring them closer to the actual values. The predetermined coefficient may be determined empirically, for example, that an order has been placed for a reason other than a failure, or that there are a plurality of parts in order to eliminate one failure. The predetermined coefficient is stored in the HDD 224 or the like in association with each failure, for example.

  In step S3204, the CPU 221 extracts failure information corresponding to the component, and writes the count value in the portion of the number of occurrences in the failure information.

  As described above, the approximate number of occurrences is obtained. This number of occurrences is transmitted together when failure information is obtained from the client terminal.

  The failure information registration process shown in FIG. 30 is to register failure information when ordering parts. However, when registering the failure information, an order for parts may be executed. Therefore, in the present embodiment, parts are also ordered when the failure information is registered.

  FIG. 33 is an exemplary flowchart relating to part ordering processing at the time of registration of failure information. In step S <b> 3300, the CPU 201 of the client terminal transmits a failure information registration request to the server 150. For example, when the failure information registration button shown in FIG. 20 is operated, the registration request is transmitted.

  In step S3302, upon receiving a failure information registration request, the CPU 221 of the server 150 creates a failure information input screen and an order information input screen in step S3304, and transmits them to the client terminal.

  In step S3306, when the CPU 201 of the client terminal receives the input screen, the CPU 201 displays the input screen on the display device 205.

  FIG. 34 is a diagram showing an exemplary input screen for failure information and order information. In addition to the failure information shown in FIG. 4, the number of ordered parts can be entered. In step S <b> 3308, the CPU 201 transmits failure information and order information input from the operation unit 206 to the server 150.

  In step S3310, when the CPU 221 receives failure information and order information from the client terminal, the failure information and ordering information are registered according to step S304 described above. Then, the ordering process is executed according to step S2722 described above.

  As described above, since the ordering of parts can be executed when the failure information is registered, both processes can be executed efficiently.

  The part ordering process described above may be executed by operating an ordering button on the maintenance information and failure information display screen as shown in FIG. 9, for example. That is, when the order button is operated, the order process as shown in FIG. 27 is executed. The failure information registration process may be omitted.

  In addition, the HTML file for forming the display screen of FIG. 9 includes a code (for example, a tag, a script, etc.) for displaying the content or presence / absence of failure information together with maintenance information, and an ordering request for parts related to functional parts A code for transmission (for example, an order button form or a script) is included.

  The CPU 221 may determine whether or not the failure target method is “part replacement”, and may create screen information that displays an order button only when “part replacement” is set. In this way, the user can easily be informed that the failure can be repaired by replacing the parts.

  Next, a method for improving the visibility of failure information will be described. As described above, since failure information is accumulated at any time, there is a possibility that many pieces of failure information are registered for the same functional part or the same component. In this case, it is difficult to display an explanation document of all failure information superimposed on the maintenance information image. Therefore, in this embodiment, it is possible to improve the visibility of maintenance information and failure information when a large number of pieces of failure information are registered.

  Since the display information on the screen for displaying step by step using the Web link function has already been described with reference to FIG. 12, a subroutine corresponding to step S1216 will be described here.

  FIG. 35 is an exemplary flowchart of a process for creating an icon for transmitting a failure information detail display request on the maintenance information display screen.

  In step S3500, the CPU 221 acquires display position information on the screen of the component to be processed. Note that this display position information is stored in the HDD 224 in a database in advance for each component.

  In step S3502, the CPU 221 displays the file name of the icon (link button) for transmitting the failure information detail display request, the acquired display position information, and the operation when the icon is clicked (for example, the request for transmitting the detailed information). Write information (such as send script and hyperlink) to the template file for the component.

  FIG. 36 is a diagram illustrating an example of a maintenance information display screen on which an icon for transmitting a failure information detail display request is arranged. As is clear from the figure, a star icon is displayed in association with each component for which failure information is registered. When this star icon is clicked, a detailed display request for failure information is transmitted.

  FIG. 37 is an exemplary flowchart regarding detailed display of failure information. In step S3700, when the CPU 201 of the client terminal detects that a detailed display request transmission instruction has been issued, the CPU 201 transmits a detailed display request to the server 150. 36, the CPU 201 detects that a star-shaped icon (for example, a link button) has been operated from the operation unit 206, and transmits a link page transmission request to the server 150.

  In step S3702, when the CPU 221 receives a request for transmitting detailed information, the CPU 221 proceeds to step S3704 and reads the detailed information from the HDD 224 or the like.

  In step S3706, the CPU 221 creates screen display information for displaying the read detailed information. For example, an HTML file for displaying the read failure information is created using a series of table tags such as <table>. In step S3708, the CPU 221 transmits display information of a screen for displaying detailed information.

  In step S3710, when the CPU 201 of the client terminal receives the screen display information, the CPU 201 of the client terminal displays the received screen display information on the display device 205 in step S3712.

  FIG. 38 is a diagram illustrating an example of a failure information detail display screen. As apparent from the figure, the failure information of the component or functional part corresponding to the clicked icon is displayed in a table format.

  By the way, if many faults are registered for one faulty part, many icons are displayed on the maintenance information display screen, which may give a complicated impression to the user. Therefore, in this embodiment, when a plurality of pieces of failure information are registered for one component or functional part, the maintenance screen is easier to read by reducing the number of displayed icons than the number of pieces of failure information. Is to improve. In an extreme case, a single icon may be displayed for a plurality of pieces of failure information.

  FIG. 39 is an exemplary flowchart regarding a process for creating a failure information display screen. In addition, the part already demonstrated is abbreviate | omitted description by attaching | subjecting the same referential mark.

  In step S3900, the CPU 221 counts the number of pieces of failure information retrieved for each component. In step S3902, an icon indicating the number of pieces of failure information is created for each component. In this example, one icon is created for each component. Note that it is not always necessary to use a single icon as long as the number of icons is smaller than the number of pieces of failure information. Thereafter, the failure information display screen creation process described with reference to FIG. 35 and the like is executed.

  FIG. 40 is a diagram illustrating an example of the failure information display screen. It can be seen that three icons displayed in FIG. 36 are combined into a single icon in FIG. Furthermore, in this example, since the number of pieces of failure information registered is displayed in the icon, there is an advantage that it is possible to know at a glance how many pieces of failure information are registered for each component.

  FIG. 41 shows another example of the failure information detail display screen. FIG. 41 corresponds to FIG. 40 and displays a plurality of pieces of failure information corresponding to the clicked icon. The screen displayed in FIG. 41 is also created according to the flowchart of FIG. In particular, in the case of FIG. 41, the detailed information display request transmitted from the client terminal includes a command for displaying a plurality of pieces of failure information. In accordance with this display request, the CPU 221 reads out a plurality of pieces of failure information, tabulates them, and creates screen display information.

  In the above embodiment, the number of registered failure information for each component is counted, but the CPU 221 may count the number for each failure type among the plurality of extracted failure information. The icons described above may also be displayed for each failure type. Further, the number of registrations for each failure type may be displayed together with an icon.

  Further, the failure information may include information on the failure resolution rate by the solution in addition to the information on the solution for the failure (such as a coping method). By storing the failure resolution rate in the failure information management database 171 in advance, the failure resolution rate can be read when the failure information is read.

  In addition, the displayed failure information may include link information to detailed maintenance information related to the solution for the failure. For example, when the user clicks “exchange” which is the coping method shown in FIG. 38 or 41, detailed maintenance information may be transmitted from the server 150 to the client terminal. For example, the character part of “exchange” as a coping method may be described as a hypertext link to an HTML file including detailed maintenance information.

  FIG. 42 is a diagram illustrating an example of an intermediate screen for displaying detailed failure information. This screen is a screen that is displayed when the above-mentioned star-shaped failure information display icon is clicked, and displays only summary information of the failure information. When a detailed display button provided on this screen is clicked, the final detailed information shown in FIG. 41 or the like may be displayed. That is, by displaying information hierarchically, it is possible to improve the visibility of the maintenance information and failure information display screen.

  FIG. 43 is an exemplary flowchart of a subroutine for managing the disclosure time of failure information. As described with reference to FIGS. 4 and 5, when failure information is registered from a client terminal, a disclosure condition for the failure information can be set. By setting the release condition, it becomes possible to release the failure information after it has matured into, for example, reliable information.

  In step S4300, the CPU 221 reads out the disclosure conditions (for example, information provision timing in FIG. 5) of each failure information from the failure information management database. Note that failure information whose release condition is, for example, “same day” has already been disclosed, and may be excluded from the following processing.

  In step S4302, the CPU 221 reads out comparison information that is useful in determining whether the disclosure condition is satisfied. For example, if the disclosure condition is “predetermined period (eg, after 7 days)”, the input date of the failure information is read from the failure information management database 171 and today's date data is acquired from the built-in timer and the difference calculation is executed. .

  Alternatively, if the disclosure condition is “inquiry”, the inquiry destination for each failure information is read and the inquiry process is executed. For example, the e-mail address of the input person stored in association with the failure information is read from the failure information management database 171 or the user management database 172, and an e-mail including the failure information to be inquired is created. Send. The CPU 221 receives a reply regarding whether or not to disclose the information by e-mail or the like.

  In step S4304, the CPU 221 determines whether or not the acquired comparison information matches the disclosure condition. For example, it is determined whether today's date has passed a predetermined period from the input date. Alternatively, it is determined whether a public permission e-mail has been received from a public information registrant. If the disclosure condition is not satisfied, the disclosure management subroutine is terminated.

  On the other hand, if the release condition is satisfied, the release condition is changed to “open permission (eg, same day)” in step S4306. As described above, it is possible to provide more reliable failure information by disclosing only the failure information that satisfies the disclosure condition.

  Note that the above-described disclosure conditions are merely examples, and other disclosure conditions may be adopted. For example, the same failure information is not registered again for the same product before a predetermined period elapses from the failure information input date. The predetermined period may be set for each type of failure information. Furthermore, a plurality of disclosure conditions may be combined. For example, a combination of the passage of a predetermined period and an inquiry to a registrant.

  Also, if link information to the corresponding failure information edit screen is entered in the inquiry mail, the edit screen may be transmitted from the server 150 by clicking the link information on the client terminal. In this case, since the disclosure conditions can be edited from the client terminal, there is an advantage that the degree of freedom in editing the disclosure conditions is increased.

  In addition, by providing the editing site for the publishing condition on the server 150 as described above, the client terminal may freely access the editing site and reset the publishing condition at a timing other than the above-described subroutine. For example, the disclosure condition may be set to be invalidated or changed in order to make the failure information public unconditionally.

  FIG. 44 is an exemplary flowchart regarding the editing process of the disclosure condition. In step S <b> 4400, the CPU 201 of the client terminal transmits a public condition editing request to the server 150. For example, when “Edit Publication Conditions” is selected from the menu screen shown in FIG. 19 and the execution button is operated, the CPU 201 transmits an editing request. The edit request includes information related to the disclosure condition to be edited (for example, failure information input date, user name, etc.). As described above, the edit request may be transmitted by clicking a link included in the inquiry e-mail.

  In step S4402, when the CPU 221 of the server 150 receives the edit request, the process proceeds to step S4404, where the release conditions to be edited are read from the failure information management database 171 and an edit screen is created. The CPU 221 transmits the created editing screen display information (eg, HTML file) to the client terminal.

  In step S <b> 4406, the CPU 201 of the client terminal receives display information of the edit screen and displays the edit screen on the display device 205. In step S4408, the CPU 201 edits the disclosure conditions based on the information input from the operation unit 206. In step S <b> 4410, the CPU 201 transmits a post-edit registration condition registration request to the server 150 in response to a transmission instruction from the operation unit 206.

  In step S4412, when receiving the registration request, the CPU 221 of the server 150 stores the edited publication condition included in the registration request in the failure information management database 171 in step S4414.

  As described above, the disclosure conditions can be freely changed from the client terminal.

  As described above, according to the present embodiment, for example, product failure information is posted in association with maintenance information from a client terminal installed in a service factory or the like, so that failure information can be shared, Eventually, the efficiency of failure maintenance will be improved.

  In addition, according to the present embodiment, it is visually displayed that failure information is registered on the maintenance information provision screen, and detailed failure information is provided in accordance with a user instruction. The user interface for providing fault information will be easy to use.

  Further, according to the present embodiment, for example, maintenance information image data and failure information image data are dynamically superimposed and provided when provided to the user, so that maintenance information and failure information are provided. It is possible to update the information individually, and to provide maintenance information and failure information more flexibly.

  According to the present embodiment, since the failure information is displayed on the page displaying the component parts constituting each functional part, the relationship between the component parts and the failure information can be easily provided to the user.

  According to the present embodiment, for example, using a link function such as a hypertext link, a page displaying a functional part and a page displaying a component are linked, and the presence or absence of failure information is configured on the functional part page. Since the parts page provides details of the failure information, the user will have easy access to the necessary information.

  According to the present embodiment, since the user can select a favorite display mode, maintenance information and failure information can be provided according to the user's preference.

  According to the present embodiment, since the failure information and the like can be searched based on the product type code and failure code, the user inputs the product type code and failure code, so that the desired maintenance information and failure information are input. And will be easily accessible.

  According to the present embodiment, by receiving the code output from the product at the client terminal, there is an advantage that the trouble of manual input by the user can be saved and erroneous input can be suppressed.

  According to the present embodiment, when new failure information is registered, it is notified to the development department such as a manufacturer or a supplier, so that it can be used to improve parts or design a new product.

  According to this embodiment, when failure information with the same content is received to some extent, the failure information is considered to be important information, so the manufacturer or supplier is notified and the cause of the failure is investigated in detail from the design level. It will be possible.

  According to the present embodiment, by controlling the transmission of frequent failure notifications according to the type of failure information, necessary items can be selected and notified.

  According to the present embodiment, since the failure information can be registered from the client terminal in relation to the maintenance information provided from the system side, the user can check the failure information while registering the failure information. There is an advantage that the failure information can be easily registered.

  According to the present embodiment, only a part of failure information among a plurality of pieces of failure information is provided. For example, the user is confused by displaying all the failure information in a disorderly manner. Let's alleviate the problem.

  In addition, since only a part of the failure information according to the predetermined sorting rule is read out and provided to the user, the user can enjoy the failure information according to the order called the sorting rule.

  For example, if a selection rule is set so that items with a similar production number or products with a similar production date can be extracted, it is possible to provide only failure information about other products manufactured almost simultaneously with the product to be repaired. become. Empirically, products manufactured at the same time may show similar trends in terms of failure, so applying these screening rules will make it easier to obtain more relevant failure information.

  Moreover, if the grade of a product, the presence or absence of an accessory, etc. are set as a selection rule, it becomes possible to obtain failure information of other products having a common grade or accessory. For example, if the product grade is different, the specifications of the engine and the like are different, and the contents of the equipment are different, but the difference in grade and the presence or absence of accessories may affect the tendency of failure. In particular, when failure information of accessories (eg, optional parts) is necessary, the necessary failure information cannot be obtained unless the selection rules are based on the presence or absence of accessories. Therefore, by adopting the difference in grades and the presence / absence of accessories as a selection rule, failure information that is highly likely to be useful can be obtained.

  Moreover, even if the same or similar usage status or usage environment is set as a selection rule, failure information can be effectively selected. In other words, depending on the type of failure, it may be likely to occur in the same or similar usage status or usage environment, so it is meaningful to set such usage status or usage environment as a selection rule. Failure information can be extracted. For example, if a car is used near the coast that is susceptible to salt damage, the car body is likely to corrode, so it would be easier to select failure information related to corrosion.

  Further, the number of occurrences of failures may be set as a selection rule. For example, if a failure that has been reported more than 100 is set as a selection rule, failure information about a failure that is likely to occur can be obtained.

  Depending on the setting of the selection rule, the displayed failure information may be too small. Therefore, by transmitting an additional display request from the client terminal, it is possible to provide the client terminal with the failure information leaked in the first selection later.

  According to the present embodiment, in addition to failure information related to the functional part of the designated product, failure information related to other products of different types or other functional parts that employ the same component as the functional part. In addition, the user can obtain a wide range of failure information related to the designated product.

  In addition, since the failure information of the designated product and the failure information of other products are distinguished and displayed, the user can easily distinguish the two visually. For example, when there are a plurality of pieces of failure information for common parts, failure information for the same vehicle type is often more helpful for repair than failure information for other vehicle types. Therefore, by distinguishing and displaying both, it will be easy to refer to the failure information about the same vehicle type.

  In addition, failure information of specified products is displayed with priority over failure information of products of different types, so that failure information of specified products is mainly used as reference, and failure information of products of different types is necessary. It will be possible to refer to it depending on the situation.

  Such a priority display method includes, for example, a method of displaying failure information of a specified product and not displaying failure information of a product of a different type. In this case, the failure information of products of different types may be displayed on demand.

  It should be noted that by using other products of different types as extraction targets, sometimes more failure information than the user's expectation may be displayed. In such a case, it may not be possible to display well-organized information simply by performing simple distinction display. Therefore, failure information may be extracted by limiting to functional parts and components supplied by the same supplier. Moreover, as a limited extraction condition, for example, a manufacturing date, a manufacturing number, or a product classification may be adopted. For example, in the case of an automobile, the product classification means a classification such as a sedan, a one box, or a wagon.

  In addition, when registering failure information for a predetermined product or a predetermined functional part, whether or not the failure information is also provided when failure information for another product or another functional part is requested. The server may be set from the client terminal. For example, a service engineer who is trying to register failure information about a vehicle of a certain vehicle type may consider the failure information useful for vehicles of other vehicle types. In such a case, it may be left to the decision of the service engineer to set the failure information provision target. Therefore, it is possible to set whether or not failure information of a certain product is provided also for other products of different types from a client terminal or the like.

  According to the present embodiment, the failure information can be efficiently collected by guiding the user to register the failure information when ordering the parts. If the registration of failure information is freely left to a user such as a service engineer, failure information may not be collected sufficiently. For example, a user who thinks troublesome registration of failure information will not register failure information. On the other hand, the timing for ordering parts is often when a part fails. Therefore, when ordering a part, there is a high possibility that the user grasps some failure information. Therefore, failure information can be input at the time of ordering parts, so that failure information collection efficiency will be improved.

  On the other hand, when referring to maintenance information or failure information, it is often considered that the failure is for repair. At that time, if the failure information or the maintenance information teaches that the countermeasure for the failure is the replacement of the part, it would be convenient if the part necessary for the repair can be ordered from the screen. Therefore, according to the present invention, parts can be ordered if necessary when referring to maintenance information or failure information.

  In this embodiment, when information necessary for ordering a part is input, at least a part of the failure information about the order target part is created based on the information or the already registered failure information. I did it. Thereby, the trouble of inputting failure information can be reduced. For example, a part of the failure information is created by specifying information on the type or functional part of the product based on the part identification information.

  Further, it is possible to further assist the input of the failure information by estimating at least a part of the failure information related to the part based on the registered failure information and the part identification information related to the order request. For example, if there is a statistically high probability that a specific failure will occur for a certain part, the failure information may be adopted.

  Note that failure information automatically created is not always correct. Therefore, an opportunity for correction can be given by presenting a correction screen for the created failure information to the user. This will allow correct fault information to be collected.

  In addition, information on related parts that are likely to be ordered together with a part is stored, and when ordering a part, information on the relevant part is guided to provide a series of information necessary for repair. Parts can be ordered in a batch.

  In addition, the number of failure occurrences is obtained from the number of orders of a certain part, and the number of failure occurrences obtained is displayed together with maintenance information or the like, so that the number of failure occurrences can be confirmed. As a result, for failures with a large number of occurrences, prior measures can be taken even before the occurrence of failures.

  In addition, when the failure information input in connection with the order request and the component information related to the order request are stored in association with each other, and a failure information transmission request is received from another client terminal or the like In addition to failure information, it also provides component information. That is, when certain failure information is referred to, the information on the parts necessary for repair is provided, so that the ordering efficiency of the parts and the repair efficiency are improved.

  According to this embodiment, an icon for displaying the presence of failure information is superimposed on the maintenance information and provided to the client terminal. Furthermore, since the detailed contents of the failure information are provided after the icon is operated, it is possible to improve the visibility of the maintenance information and the failure information.

  Even if a plurality of pieces of failure information are registered, by displaying only a smaller number of icons (for example, one), the screen is filled with icons and becomes complicated. Let's avoid the situation.

  In addition, when the icon is clicked, the failure information can be referred step by step by creating and providing hierarchical screen information information.

  Further, by displaying the number of pieces of failure information together with icons, it becomes possible to visually understand how many pieces of failure information are registered.

  Also, if the number of registrations for each failure type is counted and provided, it is possible to visually grasp how many pieces of failure information are registered for different types of failures.

  In addition, by providing information on a solution for a failure in association with the failure information, a user such as a service engineer can immediately grasp the solution for the failure. If the solution is displayed as it is, it may be complicated, so the solution is displayed step by step by following the link. In addition to the solution for the failure, a solution rate when the solution is applied may be provided. Thereby, the user will be able to judge the reliability of the solution.

  According to the present embodiment, by releasing the registered failure information that satisfies the release condition, for example, mature information can be released. In addition, since even immature failure information can be registered, it is possible to reduce the problem of failure information registration being neglected.

  For example, by setting the release condition to be a predetermined period, the registered failure information can be released after a certain period. It will be automatically published after a certain period of time, so you can avoid forgetting to publish.

  Further, if the release condition is obtained from the client terminal that has input the failure information, the release condition can be released based on the judgment of the registrant of the failure information. In order to obtain the publication permission, for example, a publication permission request may be transmitted to the client terminal that has input the failure information to receive the publication permission.

  The disclosure condition may be set such that the same failure information is not registered again for the same product before a predetermined period elapses from the input date of the failure information. For example, there may be a case where the same failure information is re-registered and the same failure information is registered again after failure countermeasures have been taken once, but subsequently in failure observation. In such a case, the portion related to the failure countermeasure in the failure information registered last time has low reliability. Therefore, by setting the disclosure conditions in this way, disclosure of failure information with low reliability can be reduced.

  Note that a disclosure condition such as a predetermined period may be set for each failure type. This is because, depending on the type of failure, there may be a minor failure that may be disclosed immediately, or there may be a serious failure that should be disclosed after the time has been investigated sufficiently. The predetermined period may be set by the user via the client terminal.

  Moreover, the failure information may be disclosed unconditionally by changing the disclosure conditions. That is, when it is determined that the failure information is important to be widely propagated, the disclosure condition is changed so that the failure information can be disclosed even before the predetermined period.

FIG. 1 is a diagram illustrating an example of a maintenance information providing system according to an embodiment. FIG. 2 is a diagram illustrating a hardware configuration example of each device according to the embodiment. FIG. 3 is a flowchart illustrating failure information registration processing according to the embodiment. FIG. 4 is a diagram illustrating an example of a failure information input page according to the embodiment. FIG. 5 is a diagram illustrating an example of a failure information management database according to the embodiment. FIG. 6 is a flowchart related to a process for providing maintenance information and failure information according to the embodiment. FIG. 7 is a diagram illustrating an example of an input page used when inputting the maintenance information search condition. FIG. 8 is a diagram illustrating an example of the maintenance information management database. FIG. 9 is a diagram illustrating an example of a screen for displaying maintenance information and failure information according to the embodiment. FIG. 10 is an exemplary flowchart of a screen display information creation subroutine. FIG. 11 is another exemplary flowchart of a screen display information creation subroutine. FIG. 12 is a flowchart showing still another example of the display information creation subroutine for the screen. FIG. 13 is a diagram illustrating an example of stepwise display of maintenance information and failure information. FIG. 14 is a flowchart showing a new failure notification subroutine. FIG. 15 is an exemplary flowchart regarding frequent failure notification. FIG. 16 is a flowchart of a subroutine related to customization processing for the display screen of maintenance information and failure information. FIG. 17 is a diagram illustrating an example of a display form setting screen. FIG. 18 is a flowchart showing another example of the failure information registration process. FIG. 19 is a diagram illustrating an example of a menu screen relating to provision of maintenance information and failure information. FIG. 20 is a diagram illustrating an example of a screen for selecting whether or not to register failure information. FIG. 21 is an exemplary flowchart regarding a failure information search subroutine. FIG. 22 is a diagram showing an example of a screening rule inquiry screen. FIG. 23 is an exemplary flowchart of the failure information addition display process. FIG. 24 is an exemplary flowchart regarding search processing including failure information for similar products. FIG. 25 is an exemplary flowchart of an expansion search process executed when failure information about a specified product / functional part / component is not found. FIG. 26 is a flowchart regarding priority display of failure information. FIG. 27 is an exemplary flowchart regarding order processing. FIG. 28 is a diagram illustrating an example of an order information input screen. FIG. 29 is an exemplary flowchart of the failure information estimation process. FIG. 30 is an exemplary flowchart of an ordering process for related parts. FIG. 31 is a diagram showing an example of an ordering guidance screen relating to related parts. FIG. 32 is an exemplary flowchart regarding the process of estimating the number of occurrences of failures. FIG. 33 is an exemplary flowchart relating to part ordering processing at the time of registration of failure information. FIG. 34 is a diagram showing an exemplary input screen for failure information and order information. FIG. 35 is an exemplary flowchart of a process for creating an icon for transmitting a failure information detail display request on the maintenance information display screen. FIG. 36 is a diagram illustrating an example of a maintenance information display screen on which an icon for transmitting a failure information detail display request is arranged. FIG. 37 is an exemplary flowchart regarding detailed display of failure information. FIG. 38 is a diagram illustrating an example of a failure information detail display screen. FIG. 39 is an exemplary flowchart regarding a process for creating a failure information display screen. FIG. 40 is a diagram illustrating an example of the failure information display screen. FIG. 41 shows another example of the failure information detail display screen. FIG. 42 is a diagram illustrating an example of an intermediate screen for displaying detailed failure information. FIG. 43 is an exemplary flowchart of a subroutine for managing the disclosure time of failure information. FIG. 44 is an exemplary flowchart regarding the editing process of the disclosure condition.

Claims (13)

A maintenance information providing system for providing maintenance information of a predetermined product to a plurality of client terminals connected via a network,
Maintenance information storage means for storing maintenance information for each of a plurality of functional parts constituting the product for a plurality of products of different types,
Failure information storage means for storing the failure information input from any of the client terminals in association with the functional portion for any of the functional portions;
Receiving means for receiving a transmission request for the maintenance information related to any of the functional parts from any of the client terminals;
In response to the received transmission request, the maintenance information of the corresponding functional part is read from the maintenance information storage means, and the failure information related to the functional part is read from the failure information storage means, and the failure information along with the maintenance information is read. In a maintenance information providing system comprising: transmission means for transmitting to the client terminal that has transmitted the transmission request, screen information for causing the client terminal to display the content or presence of
Means for receiving an order request for any of the parts constituting the product from any of the client terminals;
Upon receiving the order request, means for transmitting an input request for failure information of a part related to the order request;
A maintenance information providing system including means for storing the failure information input in response to the input request in the failure information storage means;   The maintenance information providing system according to claim 1, further comprising means for creating at least a part of failure information about a part to be ordered based on the order request received from the client terminal and the registered failure information. .   The maintenance information providing system according to claim 2, further comprising a specifying unit that specifies information on a type or a functional part of the product based on identification information of a part related to the order request.   The unit according to claim 2, further comprising means for estimating at least part of the failure information related to the part based on past failure information stored in the failure information storage means and identification information of the part related to the order request. Maintenance information provision system. Means for creating input screen information for inputting additional information or correction information for the estimated failure information;
Means for transmitting the created input screen information to the client terminal;
Means for receiving additional information or correction information input at the client terminal according to the input screen information;
The maintenance information providing system according to claim 4, further comprising means for storing the received additional information or correction information in the failure information storage means. Means for storing information on related parts ordered in the past in relation to the parts;
6. The information processing apparatus according to claim 1, further comprising: a unit that reads out information on the related part and creates input screen information for inputting an order request for the related part when the part is ordered. Maintenance information provision system. Means for counting the number of occurrences of failures related to the part according to the number of orders of the part;
7. The maintenance information providing system according to claim 1, further comprising means for transmitting the number of occurrences together with the maintenance information and failure information. The failure information storage means stores the failure information input in association with the order request and the component information related to the order request in association with each other,
The maintenance information providing system according to any one of claims 1 to 7, wherein when the failure information is transmitted, the transmission unit transmits information on the component corresponding to the failure information to the client terminal. A maintenance information providing system for providing maintenance information of a predetermined product to a plurality of client terminals connected via a network,
Maintenance information storage means for storing maintenance information for each of a plurality of functional parts constituting the product for a plurality of products of different types,
Failure information storage means for storing the failure information input from any of the client terminals in association with the functional portion for any of the functional portions;
Receiving means for receiving a transmission request for the maintenance information related to any of the functional parts from any of the client terminals;
In response to the received transmission request, the maintenance information of the corresponding functional part is read from the maintenance information storage means, and the failure information related to the functional part is read from the failure information storage means, and the failure information along with the maintenance information is read. In a maintenance information providing system comprising: transmission means for transmitting to the client terminal that has transmitted the transmission request, screen information for causing the client terminal to display the content or presence of
Means for receiving a registration request for the failure information from any of the client terminals;
Upon receiving the failure information registration request, means for transmitting the failure information input screen information and input screen information for inputting an ordering request for parts related to the failure information;
Means for receiving the failure information transmitted from the client terminal and an ordering request for the parts;
A maintenance information providing system including means for storing the received failure information in the failure information storage means. A maintenance information providing system for providing maintenance information of a predetermined product to a plurality of client terminals connected via a network,
Maintenance information storage means for storing maintenance information for each of a plurality of functional parts constituting the product for a plurality of different types of products,
Failure information storage means for storing the failure information input from any of the client terminals in association with the functional portion for any of the functional portions;
Receiving means for receiving a transmission request for the maintenance information related to any of the functional parts from any of the client terminals;
In response to the received transmission request, the maintenance information of the corresponding functional part is read from the maintenance information storage means, and the failure information related to the functional part is read from the failure information storage means and the read maintenance information And a creating means for creating a code for displaying the content or presence / absence of the failure information on the client terminal, and a code for transmitting an ordering request for parts related to the functional part,
Transmitting means for transmitting the generated code to the client terminal that has transmitted the transmission request; and order request receiving means for receiving an order request for the part transmitted from the client terminal that has received the code. Maintenance information provision system. A maintenance information providing method for providing maintenance information of a predetermined product to a plurality of client terminals via a network,
Receiving, from any of the client terminals, a request for transmission of the maintenance information regarding any of the functional parts;
In response to the received transmission request, reading the maintenance information of the corresponding functional part, and reading failure information regarding the functional part;
In the maintenance information providing method, including the step of transmitting screen information for displaying the content or presence / absence of the failure information together with the maintenance information on the client terminal to the client terminal that has transmitted the transmission request,
Receiving an order request for any of the parts constituting the product from any of the client terminals;
When receiving the order request, a step of transmitting an input request for failure information of parts related to the order request;
Storing maintenance information input in response to the input request. A maintenance information providing method for providing maintenance information of a predetermined product to a plurality of client terminals via a network,
Receiving, from any of the client terminals, a request for transmission of the maintenance information regarding any of the functional parts;
In response to the received transmission request, reading the maintenance information of the corresponding functional part, and reading failure information regarding the functional part;
In the maintenance information providing method, including the step of transmitting screen information for displaying the content or presence / absence of the failure information together with the maintenance information on the client terminal to the client terminal that has transmitted the transmission request,
Receiving a failure information registration request for any functional part constituting the product or any part constituting the functional part from any of the client terminals;
Upon receiving the failure information registration request, transmitting the input screen information for inputting the failure information and the input screen information for inputting an ordering request for parts related to the failure information;
Receiving the failure information transmitted from the client terminal and an ordering request for the parts;
A maintenance information providing method including the step of storing the received failure information in association with a functional part of the product to which the component is applied. A maintenance information providing method for providing maintenance information of a predetermined product to a plurality of client terminals via a network,
For each of a plurality of different types of products, storing maintenance information for each of a plurality of functional parts constituting the product;
For any one of the functional parts, storing the failure information input from any of the client terminals in association with the functional part;
Receiving, from any of the client terminals, a request for transmission of the maintenance information regarding any of the functional parts;
In response to the received transmission request, reading the maintenance information of the corresponding functional part, and reading failure information regarding the functional part;
The transmission request has been transmitted with a code for displaying the content or presence / absence of the failure information together with the read maintenance information at the client terminal and a code for transmitting a part order request for the functional part. A maintenance information providing method comprising: transmitting to the client terminal; and receiving an order request for the parts transmitted from the client terminal.

Images