JP2005135299A - Problem receipt device, method, and program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To allow a user to determine the presence/absence of a failure and its degree and to smoothly access a repair reception if necessary when a problem occurs in an apparatus used by the user. <P>SOLUTION: This problem receipt device is provided with a problem component input means making the user input a component element of the apparatus causing a problem, a symptom input means making the user input a symptom of the component element causing the problem, a determination means determining necessity for the repair of the apparatus from the symptom, and a repair receipt means urging on the user repair of the apparatus when the determination means determines that the apparatus needs repair. <P>COPYRIGHT: (C)2005,JPO&NCIPI

Description

  The present invention relates to a technology for providing a repair service for equipment.

  Today, various devices such as personal computers, personal digital assistants, communication devices, various household electrical appliances, and office equipment have spread to society. As a result, various functions such as housework support, information acquisition / processing / communication, office work management, and education support are provided at home, workplace, or school. However, as a result of the widespread use of these devices by a large number of users, there is a problem that maintenance and management of these devices or services such as failure handling are not sufficiently provided.

  For example, a personal computer may break down and call the manufacturer's call center. However, even though the user wants to send the repair quickly, the call center may not be connected and the user may be unable to do anything. In such a case, it is common that the user waits patiently until the call is connected to the call center and makes an inquiry.

  In addition, after the user submits the personal computer for repair, the user cannot easily know the repair status such as the state of the personal computer being repaired and when the repair is completed.

The following Patent Documents 1 to 4 are known as techniques relating to reception of repairs for personal computers, repair estimates, provision of failure classification information, and the like.
JP 2002-215822 A JP-T-2002-342510 JP 2002-352026 A JP 2003-108689 A

  An object of the present invention is to enable a user to easily determine the presence / absence of a failure and its extent when a problem occurs in a device used on the user side, and to smoothly access a repair reception as necessary. Is to provide technology.

  In order to solve the above problems, the present invention employs the following means. That is, the present invention is a defect accepting apparatus, a defect component input means for allowing a user to input a component of a device in which a defect has occurred, and a symptom input for allowing a user to input a symptom of the component in which the defect has occurred A means for determining the necessity of repair of the device from the means, and the symptom, and prompting the user to repair the device when the determination means determines that the device needs to be repaired Repair receiving means.

  As described above, the present invention prompts the component of the device in which the failure has occurred and the input of the symptom of the failure that has occurred in the component, determines the necessity of repair from the symptom, and determines that the repair is necessary. Receive repairs for damaged equipment. In this case, information indicating a symptom that is likely to occur or a symptom that may occur in the input component may be displayed in a list and may be selected by the user.

Preferably, a model input unit that allows a user to input model information of the device and a component determination unit that determines a component of the model based on the model information may be further provided. In this case, when the model information is input, the constituent elements included in the model are determined, so that the constituent elements may be displayed in a list and selected by the user.

  Preferably, the defect reception device further includes information providing means for providing the user with solution information for the symptom of the failure, and means for prompting the user to input a countermeasure execution result based on the solution information, The determination means may further determine the necessity of repair according to the countermeasure execution result. That is, by providing solution information and receiving input of a countermeasure execution result based on the solution, the necessity for repair can be determined more accurately.

  Preferably, the determination unit may determine based on one or more of the model, the component, the symptom, or the countermeasure execution result. That is, the determination means may determine the necessity of narrowing down and repairing a defective part based on the model, component, symptom, or countermeasure execution result.

  Preferably, the defect receiving device may further include an estimation unit that estimates a repair cost of the device according to the symptom. By estimating the repair cost, the user can determine whether or not to request repair at an early stage.

  Preferably, the defect accepting apparatus may further include means for allowing a user to search for a repair status of the device based on a receipt number for accepting repair of the device. Through such searching means, the user can check the repair status of the equipment that requested the repair.

  Further, the present invention may be a method in which a computer, other devices, machines, etc. execute any one of the processes described above. Furthermore, the present invention may be a program that causes a computer, other devices, machines, or the like to realize any of the above functions. Further, the present invention may be a program in which such a program is recorded on a computer-readable recording medium.

  According to the present invention, when a problem occurs in a device used on the user side, the user can easily determine whether or not there is a failure and the extent thereof, and smoothly access the repair reception as necessary. it can.

  Hereinafter, an information system according to the best mode for carrying out the present invention will be described with reference to the drawings. The configuration of the following embodiment is an exemplification, and the present invention is not limited to the configuration of the embodiment. FIG. 1 is a diagram showing an overview of the diagnosis and repair reception service via the web of the information system, FIG. 2 is a diagram showing the relationship between the web screen and the table of the information system, and FIGS. 3 and 4 are books. FIG. 5 is a diagram showing a menu screen for selecting a service provided by the information system of FIG. 1, and FIG. 6 is a diagram showing a diagnostic model selection screen. 7 is a diagram showing an accessory device selection screen, FIG. 8 is a diagram showing a symptom selection screen, FIG. 9 is a diagram showing an inquiry result screen in solution guidance processing, and FIG. 10 is a repair. 11 is a diagram showing an application screen, FIG. 11 is a diagram showing a user information screen for confirming user information, FIG. 12 is a diagram showing a guarantee target screen for determining whether or not it is a guarantee target, and FIG. , Providing services for a fee Is a diagram showing a screen (estimated presentation screen), FIG. 14, there FIG shows a free screen to provide services free of charge, Fig. 15 is a flowchart showing the processing when the solution guide.

<Outline of service>
FIG. 1 shows an outline of a web diagnosis and repair reception service. This service implements equipment failure diagnosis and repair reception on a website on the Internet. By accessing a website on the Internet, a user can receive a failure determination service, a countermeasure information providing service at the time of a failure, and a repair reception service without telephone support.

  This service is realized on a web server on the Internet. The web server includes computers and programs on the Internet that provide information via the web. Since the configuration, function, and operation of the web server are widely known, description thereof is omitted. In addition, there are no limitations on the types of devices targeted by this service, and various devices such as personal computers, personal digital assistants, communication devices, various home appliances, and office devices can be targeted. However, in this embodiment, a personal computer will be described as an example.

  As shown in FIG. 1, this service is provided to the user through the Internet by the repair determination site 1 and the repair information providing site 5. In addition, the integrated information system 2, the repair service system 3, and the repair integrated system 4 are operating in cooperation with the repair determination site 1 and the repair information providing site 5.

  The repair determination site 1 and the repair information providing site 5 are web sites composed of web information described in HTML and a program linked to the web information. The integrated information system 2 records information (for example, address, name, telephone number, etc.) relating to the user who receives the service, and further manages the repair application submitted according to the determination at the repair determination site 1 It is. The repair service system 3 is a system for instructing the dispatch of a carrier to the user's home based on the repair application registered in the integrated information system 2. The repair integrated system 4 is a system for recording the repair status of the repair target product taken from the user.

  Hereinafter, a user operation procedure at the repair determination site 1 will be described. The user accesses the site through the terminal. Here, it is assumed that the user has already been registered as a member who receives a service provided by the information system (a member of a so-called friend society). Therefore, the user accesses the repair determination site 1 by presenting the member ID.

  Here, the terminal is, for example, a personal computer, a portable information terminal, a mobile phone, or the like. When the user accesses the repair determination site 1, first, the model of the diagnosis target device is selected or input (S1). Then, the repair determination site 1 displays the components included in the device specified by the model. The user selects a component that is presumed to be a failure location from the displayed components (S2).

  Then, the repair determination site 1 displays information indicating the symptom of the failure from the model and the failure location. The user selects an appropriate one from the displayed failure symptoms (S3). Then, the repair determination site 1 displays a solution for the symptom of the failure and prompts the user to execute the solution (S4). The solutions are measures, measures, etc. that can be implemented by the user without repairing the device. For example, cable connection confirmation, specific process (also called a task) stop, personal computer reset, OS (operating system) reinstallation, hard disk initialization, and the like.

Then, the user inputs the result of the countermeasure (whether it has been solved) to the repair determination site 1. As a result, if the failure is resolved, the user closes the website. On the other hand, when the failure is not resolved, the repair determination site 1 displays a new solution. Similarly, the user inputs the implementation result of the countermeasure (whether or not it has been solved) to the repair determination site 1. Such a process is called a solution guidance process. After repeating the guidance of the solution and the input of the solution execution result, the repair determination site 1 displays a failure diagnosis result (also called an inquiry result) from the information obtained so far (S5). .

  If the diagnosis result indicates that there is a possibility of hardware failure, for example, the user applies for repair (S6). At the time of this repair application, an estimate of the repair cost is displayed. When the user transmits an application after confirming the repair cost, the reception is terminated and the application is registered in the integrated information system 2. In this embodiment, the user's address, name, telephone number, etc. are already registered in the integrated information system 2 together with the user's member ID.

  When the integrated information system 2 registers the reception of the repair, the integrated information system 2 searches the address, name, telephone number, etc. based on the member ID of the user, and notifies the repaired flight system 3 of it. The repair flight system 3 notifies the predetermined carrier of the address, name, telephone number, etc., and instructs to pick up the equipment. At this time, the repair service system 3 also notifies the registration number identifying the repair application accepted by the integrated information system 2 at the same time.

  The carrier picks up the device to be repaired from the user in exchange for the registration number. The equipment collected from the user is sent to the repair department of the manufacturer and stored. The repair department of the manufacturer inputs the repair progress status of the device to the repair integrated system 4. When the user wants to know the repair status of the equipment handed over, the user accesses the repair information providing site 5 on the Internet. The repair information providing site 5 requests the user to input a registration number (S10). When the user inputs the registration number received from the carrier, the repair status of the device is displayed (S11).

  In addition to the service using the web screen as described above, a function for receiving support from a call center operator may be provided. For example, in each service step shown in S1 to S6 in FIG. 1, by selecting a predetermined button or menu on the web, a function of notifying an operator call message to the call center may be provided. By this notification, the operator may confirm the user's telephone number and make a call to the user.

<Web screen and data structure>
FIG. 2 shows a relation diagram of types of screens displayed on the Internet web and data related to the screens. As described above, the screen displayed on the web includes model selection, trouble occurrence location selection (location selection in FIG. 1), trouble content selection (symptom selection in FIG. 1), and solution method guidance (solution in FIG. 1). Measure guide) and diagnosis results (interview results in FIG. 1) are included. The diagnosis result may be added and displayed on the solution guidance screen.

  When the user selects a model on the model selection screen, the model-specific location table 27 is referred to, and a list of location data included in the model is retrieved. A list of location data is displayed on the trouble occurrence location selection screen. When the user selects a trouble occurrence location on the trouble occurrence location selection screen, the location master 20, the symptom master 21, and the check sheet 22 are referred to. A list of symptoms that may occur at the trouble occurrence location is displayed as trouble contents. Therefore, the user selects a symptom displayed on the screen.

  Data indicating this symptom is defined in the symptom master 21 and associated with the location data in the check sheet 22. That is, each record of the check sheet 22 associates symptom data of the symptom master 21 with each piece of place data of the place master 20.

  When the user selects trouble contents (symptoms), a solution guidance screen is displayed according to the symptom. In the solution guidance screen, the confirmation content table 24 is referred to, the confirmation content is displayed as an option, and the user's selection is received. The confirmation content table 24 is associated with the model-specific information table 25 and the model information table 26, and is used for inquiring the user regarding the model-specific components.

  On the solution guidance screen, an entry in the next confirmation content table 24 is selected according to the option selected by the user, and the next option is displayed. The selection of such confirmation contents is repeated one or more times, the cause of the failure is specified, and the countermeasure contents are presented. Then, the user answers whether or not the problem is finally solved. When the problem is solved, the user ends the service provided by the information system. On the other hand, if the problem is not resolved, the diagnosis result is displayed, the fault location is specified, and the application for repair is prompted.

  When applying for repair, the information system refers to the estimated part master 29 and displays an estimated cost for replacing the part or the like at the failure location. After confirming the estimated cost, the user determines whether or not to request repair.

  3 and 4 are related diagrams of tables managed by the information system. In FIGS. 3 and 4, the records of each table are displayed in association with each other. When a model, a location, and a symptom are input via the above-described web, a record of the check sheet 22 is selected based on the input result. The check sheet 22 is a table having a check sheet No, a location code, a symptom code (data of five types of symptom codes is illustrated in FIG. 3), a person-in-charge code, and an option code.

  Here, the check sheet No. is a serial number that identifies each record of the check sheet 22. The location code is a code that identifies a location in the model to be repaired. This location code is defined in the location master 20 in association with the location name. The symptom code (symptom 1 to symptom 5) is associated with information about the symptom such as symptom name and symptom level in the symptom master 21. As described above, the check sheet 22 defines the symptom that can occur in association with the location code (that is, the location where the trouble has occurred). Therefore, the check sheet 22 having a location and symptom corresponding to the location and symptom input by the user is selected. As shown in FIG. 3, the check sheet 22 is linked to the confirmation content index table 23 by the check sheet No.

  The confirmation content index table 23 is a table for controlling confirmation content to be inquired to the user when the trouble occurrence location and symptom are specified. That is, the confirmation content to be inquired (confirmation content No in the confirmation content table 24) is held for the check sheet that matches the location code and symptom code input by the user.

  The confirmation content table 24 has confirmation content No, location code, category (category 1 code, category 2 code), title, confirmation content, options 1 to 5 and person-in-charge code. The confirmation content table 24 is associated with the model-specific information table 25, the model information table 26, and the model-specific location table 27 shown in FIG. In the model-specific information table 25 and the like, the model number is specified when the model information of the user is input, and is associated with the confirmation content table 24.

  The title displayed in the confirmation content table 24 and the confirmation content record a solution displayed at the time of solution guidance. The options displayed at that time are recorded in the options 1 to 5 of the confirmation content table 24. On the other hand, the option comments 1 to 5 in the confirmation content index table 23 store a message displayed when each option is selected.

  Stored product main body 1, display, and stored product attachment 1, etc. store information on repair target products that require repair as a result of the above inquiry. The component code 1 code 1 to the component code 5 code 1 are codes (up to 5 in the present embodiment) of components that require replacement or the like in the repair target product as a result of the inquiry. As shown in FIG. 2, in this embodiment, the information below the repair product main body 1 is repeatedly stored whenever the repair target product increases as a result of the inquiry, and information on up to five sets of repair target products can be stored. .

  The component 1 code 1 and the like in the confirmation content index table 23 are associated with the model component master 28 and the estimated component master 29 through the component code. In the model part master 28, part codes of all parts for each model are defined. This model is specified by inputting the model on the web. Further, the estimated part master 29 stores the estimated price of the part corresponding to each part code. This information system stores the component code information in the confirmation content index table 23 when the failure target component can be identified based on the guidance of the solution and the input of the solution execution result. At the time of repair acceptance, this information system calculates an estimated repair amount from the part code information stored in the confirmation content index table 23 and the model part master 28 and estimated part master 29 information.

<Screen configuration and operation procedure>
FIG. 5 shows a menu screen displayed on the website of the information system. This screen is displayed when the user accesses the repair determination site 1 on the Internet with his / her terminal. By selecting the support tab 30 from the selection items at the top of the menu screen, the top page of the web repair consultation service is displayed. On this top page, an operation guide column 32 and a start button 31 are arranged.

  The operation guide column 32 displays the flow of operations for receiving each service, such as “1 Confirmation of trouble status”, “2 Interview and result guidance”, “3 Repair application”, and “4 Interview result guidance”. The After the user confirms the operation guide, the service starts when the start button 31 is pressed.

  FIG. 6 shows a diagnostic model selection screen. On this screen, a step display unit 40 that displays a service flow to the user, a guidance unit 41 that displays a description of operations on this screen to the user, and an input unit 42 that inputs the product type name of the device to be diagnosed. Each part of is displayed.

  The step display unit 40 indicates that this service is composed of “step 1 confirmation of trouble situation”, “step 2 consultation and result guidance”, “step 3 repair application”, “step 4 inquiry result guidance”, and the like. In addition, the step display unit 40 indicates which step is being executed by highlighting (for example, displaying the frame portion thickly or highlighting the background).

  The guidance unit 41 displays a message prompting the user to input the type name of the product in which a problem has occurred, a method for checking the type name of the product, and the like. The input unit 42 includes a friend group registration type name selection field 43, a product type name input field 44, a product type to selection field 45, and an inquiry start button 46.

The user inputs the product type name in any of the friend group registration type name selection field 43, the product type name input field 44, and the product type to selection field 45. For example, the friend group registration type name selection field 43 displays, in a pull-down menu, the product type name registered as the membership information when the user has already joined the friend group. The user may select the displayed product type name. In addition, the user may input the product type name directly into the product type name input field 44 using a keyboard. In addition, the user may select a product type name from the product types displayed in the selection field 45 from the product type. When the user presses the inquiry start button 46 after inputting the product type name, the screen changes to the attached device selection screen of FIG.

  FIG. 7 shows an attached device selection screen. In the accessory selection screen, the step display unit 40 highlights that “Step 2 Inquiry and Guidance of Results” is currently being executed. Further, on the accessory selection screen, a model selection unit 50 is displayed below the step display unit 40. This information system refers to the model-specific location table 27 of the database from the model information entered on the model selection screen, reads out and displays the list of accessory devices included in the model. In the example of FIG. 7, for example, in addition to standard attached devices such as a screen, a keyboard, and a mouse, devices specific to the model such as a sound speaker and a CD / DVD, or “a personal computer cannot be started / stopped”, The trouble status of typical functions such as “cannot be recovered” is displayed. These are collectively called trouble occurrence points. When the user selects a trouble occurrence location, the screen changes to the symptom selection screen in FIG.

  In addition, by pressing the history transfer button 91 to the window arranged at the lower part of the attached device Sena Ward screen, information input by the user is transferred to the call center operator as a history. In addition, by pressing the inquiry button 92, the call center operator is notified that the user is seeking operator assistance. Upon receiving this notification, the operator confirms the telephone number of the user and calls the user who is accessing the website.

  FIG. 8 shows a symptom selection screen. On the symptom selection screen, a guidance unit 41 and a symptom selection unit 60 are displayed below the step display unit 40. The guidance unit 41 displays a message that prompts the user to select a trouble symptom. The symptom selection unit 60 displays a list of symptoms that are assumed to occur at the trouble occurrence location in the model together with a selection button. For example, if the trouble occurs on the screen, the list of symptoms may include “LCD display (lid) cannot be fixed”, “Nothing is displayed”, “Display error”, “The screen goes black during operation”, etc. Is displayed. When the user selects a symptom, the screen changes to the inquiry result screen of FIG.

  It should be noted that by pressing the save state button 90 at the window located at the bottom of the symptom selection screen, the information input by the user is saved as a current state in a server (not shown). Functions of the history transfer button 91 and the inquiry button 92 are the same as those in FIG.

  FIG. 9 shows an inquiry result screen. Here, the inquiry result screen (diagnosis result screen) also serves as a solution guidance screen. In the inquiry result screen, the step display unit 40 highlights that “Step 4 Guidance on the inquiry result” is currently being executed. Further, on the inquiry result screen, a location and symptom display part 70, a confirmation content inquiry part 71, an inquiry result part 72, and a repair application button 73 are displayed below the step display part 40.

  The location and symptom display unit 70 displays a trouble occurrence location (for example, a screen) and a trouble symptom (for example, “display abnormality”) that have already been input. The confirmation content inquiring unit 71 displays a treatment assumed when the trouble occurrence location and the trouble symptom are specified, and an inquiry about the treatment. These are set in the confirmation content table 24 shown in FIG.

For example, “Please display the setup screen. Does it display normally?” “Is there anything near the TV or mobile phone that generates magnetism or radio waves? , Suggests keeping it away). When the trouble is resolved as a result of executing these measures, the user may close the screen. On the other hand, if the problem is not resolved, the user designates that the problem is not resolved with a button (“No, not displayed normally”, “No, not present”) or the like.

  Then, when the confirmation content to be inquired is in the confirmation content table 24, the information system displays the confirmation content on the confirmation content inquiry unit 71. On the other hand, when there is no confirmation content to be inquired next, the information system displays an inquiry result (for example, “repair is necessary”) or the like on the inquiry result section 72. When the user presses the repair application button 73, the screen changes to the repair application screen of FIG. Note that the functions of the save button 90, the history transfer button 91, and the inquiry button 92 in the state arranged at the bottom of the inquiry result screen are the same as those in FIG. 8 or FIG.

  On the repair application screen, the step display unit 40 highlights that “Step 5 repair application” is currently being executed. Further, on the repair application screen, a repair target confirmation unit 80 and a “next” button 81 are displayed below the step display unit 40. The repair target confirmation unit 80 displays notes to the user, a repair target model, a repair location (attachment), and the like. When the user presses the “Next” button 81, the user information screen of FIG. 11 is displayed.

  FIG. 11 shows a user information screen. The user information screen is a screen for confirming the user's first and last name, address, telephone number, the address of the receiver of the repaired product, and the like. Usually, input of a user's name, address, etc. is requested | required on a user information screen. However, in the present embodiment, when the user has already joined the friend's association, these pieces of information are retrieved from the member database (for example, the integrated information system 2 in FIG. 1) and displayed. When the confirmation of the user information screen (input of additional information as necessary) is completed, the information system then displays the guarantee target screen.

  FIG. 12 shows a guarantee target screen. The guarantee target screen is a screen that allows the user to input whether or not the device is a guarantee target. On the warranty target screen, it is requested to enter the warranty status and warranty period for the model. Further, on the guarantee target screen, an input as to whether or not to approve erasure of data on the hard disk is requested. When the user completes the input of the warranty target screen, a paid screen or a free screen is displayed depending on whether there is a warranty.

  FIG. 13 shows a paid screen. FIG. 14 shows a free screen. On the paid screen, an input of a desired pick-up date and time for the repair target product is requested, and an estimated repair amount is presented. On the other hand, the gratuitous screen requires the input of the desired pick-up date and time for the product to be repaired, and further presents that the repair is free of charge.

<Processing procedure>
FIG. 15 shows a solution guidance process executed on the inquiry screen. This process is executed by a web server (not shown) of the repair determination site 1 shown in FIG. In this process, the repair determination site 1 recognizes the model, location, and symptom based on the input in the model selection (S1), location selection (S2), and symptom selection (S3) in FIG. And the options are displayed (S10). Here, the confirmation content is, for example, “Please display the setup screen. Normal display?” For the location: screen, symptom: “display anomaly, disorder / fluctuation” as shown in FIG. "Are there anything near the TV or mobile phone that generates magnetism or radio waves?"

  In the options, answers to these questions or results for the treatment are displayed. Therefore, the repair determination site 1 waits for selection of options (S11). When the user selects any option (YES in S12), the repair determination site 1 determines whether or not the problem has been resolved from the option selection result (S13). When the problem is solved, the repair determination site 1 ends the solution guidance process.

  If the problem is not resolved, the repair determination site 1 determines whether a faulty part has been identified from the selection result of the above options (S14). The faulty part may be specified by narrowing down the corresponding part and specifying the corresponding part, for example, in accordance with the confirmation contents at the time of solution guidance for the part and symptom. Further, the failed part may be specified by referring to a rule such as “If the confirmation content is A, the part B is faulty”. Moreover, you may make it identify a failure part from the failure rate of the part relevant to an applicable location, and empirical estimated lifetime. When the failed part is specified, the repair determination site 1 records the failed part in the confirmation content index table 23 (S15).

  Next, the repair determination site 1 determines whether or not unconfirmed confirmation content remains in the confirmation content table 24 (S16). If unconfirmed confirmation content remains in the confirmation content table 24, the repair determination site 1 returns the control to S10 and displays the confirmation content. On the other hand, when there is no unconfirmed confirmation content, the repair determination site 1 determines whether or not repair is necessary (S17). For example, when a failure of one or more parts is specified, the repair determination site 1 may determine that repair is necessary.

  When the repair is necessary, the repair determination site 1 executes the repair estimate from the record of the component recorded in the confirmation content index table 23 and the estimated component master 29, and displays the estimate result (S18). Then, the repair determination site 1 waits for a repair request input from the user (S19).

  When a repair request is input from the user, the repair determination site 1 receives a repair, receives an input of a pick-up location of the product to be repaired, and further gives an instruction to pick up the product to be repaired (S20). This instruction is, for example, communicated to a carrier or the like, and the item to be repaired is picked up. On the other hand, when the repair is not required in the determination of S17 and when there is no repair request in the determination of S19 (for example, when no repair request is input for a predetermined time), the repair determination site 1 directly performs the solution guidance process. Exit.

  As described above, according to this information system, the model, location, and symptom are identified on the Internet web, and an inquiry related to the anticipated trouble corresponding to the identified model, location, and symptom is performed. It is executed once or more. The necessity of repair is determined based on the result of the inquiry, and the user is prompted to apply for repair. Therefore, the user can apply for repair immediately when it is determined that repair is necessary.

  Further, on the web, a location (part or function) corresponding to the model and a symptom corresponding to the location are displayed in a list. Therefore, the user can easily specify the location corresponding to the model. Further, the user can easily specify the symptom corresponding to the location.

  In addition, when applying for repair, an estimated amount necessary for repair is calculated from the parts to be repaired identified from the result of the inquiry and displayed on the web. Therefore, the user can determine whether or not to repair after easily grasping the estimated amount of the repair.

  Further, in this information system, a registration number for uniquely identifying the repair is given when the repair is accepted (or when the product to be repaired is picked up). In this information system, the repair status of each repair target product is tracked and recorded in the repair integrated system 4 together with the registration number. Information on the repair integrated system 4 is presented to the user through the repair information providing site 5. The user can check the status of the product to be repaired by accessing the repair information providing site 5 using the registration number.

<Others>
Furthermore, this embodiment discloses the following invention. In addition, the constituent elements included in any of the following inventions (hereinafter referred to as supplementary notes) may be combined with the constituent elements of other supplementary notes.
(Additional remark 1) The malfunction component input means which makes a user input the component of the apparatus in which the malfunction occurred,
A symptom input means for allowing a user to input a symptom of the component in which the problem has occurred;
From the symptom, determination means for determining the necessity of repair of the device,
A malfunction acceptance device comprising: a repair acceptance unit that prompts a user to repair the device when the determination unit determines that the device needs to be repaired. (1)
(Appendix 2) Model input means for allowing a user to input model information of the device;
The defect acceptance device according to appendix 1, further comprising: a component determination unit that determines a component of a model based on the model information. (2)
(Supplementary Note 3) Information providing means for providing solution information for the symptoms of the failure to the user;
Means for prompting the user to input a countermeasure execution result based on the solution information,
The defect accepting apparatus according to appendix 1 or appendix 2, wherein the determination unit further determines the necessity of repair according to the countermeasure execution result. (3)
(Additional remark 4) The malfunction acceptance apparatus of Additional remark 3 which the said determination means determines based on any one or more of the said model, the said component, or the said countermeasure execution result.
(Appendix 5) The defect acceptance device according to any one of appendices 1 to 4, further comprising an estimation unit that estimates the repair cost of the device according to the symptom.
(Additional remark 6) The malfunction acceptance apparatus in any one of additional remarks 1 thru | or 5 further provided with the means by which a user can search the repair condition of the said apparatus based on the reception number which received the repair of the said apparatus.
(Additional remark 7) The malfunction component input step which a computer makes a user input the component of the apparatus in which the malfunction occurred,
A symptom input step for allowing a user to input a symptom of the component in which the problem has occurred;
A determination step for determining the necessity of repair of the device from the symptom;
A defect acceptance method for executing a repair acceptance step for urging a user to repair the device when it is determined in the determination step that the device needs to be repaired. (4)
(Supplementary note 8) Model input step for allowing the user to input model information of the device;
The defect accepting method according to appendix 7, further comprising: a component determining step for determining a component of the model based on the model information.
(Supplementary Note 9) An information providing step of providing solution information for the symptoms of the failure to the user;
Further executing a step of prompting the user to input a countermeasure execution result based on the solution information,
9. The defect accepting method according to appendix 7 or appendix 8, wherein in the determination step, the necessity for repair is further determined according to the countermeasure execution result.
(Supplementary note 10) The defect acceptance method according to supplementary note 9, wherein in the determination step, necessity of repair is determined based on any one or more of the model, the component, or the countermeasure execution result.
(Appendix 11) The defect acceptance method according to any one of appendices 7 to 10, further including an estimation step of estimating a repair cost of the device according to the symptom.
(Additional remark 12) The fault reception method in any one of Additional remark 7 thru | or 11 which further performs the step which searches the repair condition of the said apparatus based on the reception number which received the repair of the said apparatus according to the request | requirement from a user .
(Additional remark 13) The malfunction component input step which makes a computer input the component of the apparatus in which the malfunction occurred to the user,
A symptom input step for allowing a user to input a symptom of the component in which the problem has occurred;
A determination step for determining the necessity of repair of the device from the symptom;
A program for executing a repair acceptance step for urging a user to repair the device when it is determined in the determination step that the device needs to be repaired. (5)
(Supplementary Note 14) A model input step for allowing a user to input model information of the device;
14. The program according to appendix 13, further executing a component determination step for determining a component of a model based on the model information.
(Supplementary Note 15) An information providing step of providing solution information for the symptom of the failure to the user;
Further executing a step of prompting the user to input a countermeasure execution result based on the solution information,
15. The program according to appendix 13 or appendix 14, wherein in the determination step, the necessity for repair is further determined according to the countermeasure execution result.
(Supplementary note 16) The program according to supplementary note 15, wherein in the determination step, the necessity for repair is determined based on one or more of the model, the component, or the countermeasure execution result.
(Appendix 17) The program according to any one of appendices 13 to 16, further executing an estimation step of estimating a repair cost of the device according to the symptom.
(Additional remark 18) The program in any one of additional remark 13 thru | or 17 which further performs the step which searches the repair condition of the said apparatus based on the reception number which received the repair of the said apparatus according to the request | requirement from a user.

The figure which shows the outline | summary of the diagnosis and repair reception service by the web of the information system which concerns on embodiment of this invention Relationship between web screen and table of this information system Relationship diagram of tables managed by this information system (1) Relationship diagram of tables managed by this information system (2) The figure which shows the menu screen which selects the service provided with the information system of FIG. Diagram showing diagnostic model selection screen Figure showing the accessory selection screen Figure showing the symptom selection screen Figure showing the interview result screen Figure showing the repair application screen The figure which shows the user information screen which confirms user information The figure which shows the guarantee object screen which judges whether it is the guarantee object Figure showing a paid screen (estimated amount presentation screen) Figure showing a free screen Flow chart showing the process at the time of solution guidance

Explanation of symbols

DESCRIPTION OF SYMBOLS 1 Repair judgment site 2 Integrated information system 3 Repair flight system 4 Repair integrated system 5 Repair information provision site 20 Location master 21 Symptom master 22 Check sheet table 23 Check contents index table 24 Check contents table

Claims (5)

A failure component input means for allowing the user to input a component of the device in which the failure has occurred;
A symptom input means for allowing a user to input a symptom of the component in which the problem has occurred;
From the symptom, determination means for determining the necessity of repair of the device,
A defect acceptance device comprising: a repair acceptance unit that prompts a user to repair the device when the determination unit determines that the device needs to be repaired. Model input means for allowing the user to input model information of the device;
The defect acceptance device according to claim 1, further comprising: a component determination unit that determines a component of a model based on the model information. Information providing means for providing the user with solution information for the symptoms of the failure;
Means for prompting the user to input a countermeasure execution result based on the solution information;
The defect accepting apparatus according to claim 1, wherein the determination unit further determines necessity of repair according to the countermeasure execution result. A failure component input step in which the computer inputs a component of the device in which the failure has occurred;
A symptom input step for allowing a user to input a symptom of the component in which the problem has occurred;
A determination step for determining the necessity of repair of the device from the symptom;
A defect acceptance method for executing a repair acceptance step for urging a user to repair the device when it is determined that the device needs to be repaired in the determination step. A failure component input step for causing the computer to input a component of the device in which the failure has occurred;
A symptom input step for allowing a user to input a symptom of the component in which the problem has occurred;
A determination step for determining the necessity of repair of the device from the symptom;
A program for executing a repair acceptance step for urging a user to repair the device when it is determined in the determination step that the device needs to be repaired.

Images