Information provision system and control method thereof

Abstract

To facilitate the handling of multiple errors with the same error code.SOLUTION: In an information provision system, a repair spot notification server includes: an error history management unit configured to manage printer error information collected from printers and provide a screen for listing unaddressed error information for a specified printer; and a repair procedure display unit configured to receive feedback regarding maintenance work performed on the printer. The managed error information includes device information for identifying the printer, an error code corresponding to a printer failure, a date and time of the error, and correspondence information for indicating whether the maintenance work has been performed. The error history management unit updates the correspondence information on the error addressed by the maintenance work that has received the feedback from an unaddressed state to an addressed state, and collectively updates the correspondence information on the same error code as the error code of the error regarding the error information on the same printer from the unaddressed state to the addressed state.SELECTED DRAWING: Figure 3

Description

[Technical Field]

[0001] The present invention relates to an information providing system for providing error information and a control method thereof. [Background technology]

[0002] Management systems have been developed to manage equipment information and operational information for image processing devices such as printers, copiers, and multifunction peripherals (hereinafter referred to as devices). In a management system, when a device malfunctions, a server receives a malfunction notification from the device, enabling management of the malfunction situation (when, which device, and what error occurred). Similar technologies have also been proposed for diagnosing malfunctions by analyzing the details of the malfunction. Patent Document 1 discloses a system that receives malfunction diagnosis results from a device and displays replacement guidance for malfunctioning parts based on past replacement work. Patent Document 2 discloses a system that searches a database that records solutions for each error type and status of a malfunctioning device, thereby presenting accurate maintenance information appropriate for the device's error type and status, independent of the skill of the service technician. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Publication No. 2020-199704 [Patent Document 2] Japanese Patent Application Laid-Open No. 2008-211622 Summary of the Invention [Problem to be solved by the invention]

[0004] Error information generated by a device is automatically acquired and displayed on the error information list screen. However, because multiple error transmissions are permitted as a measure to prevent missed error transmissions due to device restarts when an error occurs or missed reception due to data loss caused by the user's infrastructure environment, it is possible that multiple errors with the same error code will be displayed. In this case, even if the user follows the flow to resolve the error on the image processing device and recover from the error, the other multiple occurrences of the same error will not be resolved. This requires the user to manually change each error to a resolved state, which can be time-consuming and can increase work time. Furthermore, the error information list screen may become busy, resulting in other error information being overlooked or missing a resolution.

[0005] The present invention aims to facilitate the handling of multiple errors with the same error code. [Means for solving the problem]

[0006] In order to solve the above problem, the information providing system of the present invention has a management means for managing error information indicating errors that have occurred in the image processing device, collected from the image processing device; a provision means for providing a screen listing information on unaddressed errors in a designated image processing device; and a reception means for receiving feedback related to maintenance responses performed on the image processing device, wherein the error information managed by the management means includes device information that identifies the image processing device, an error code corresponding to a failure in the image processing device, the date and time the error occurred, and response information indicating whether maintenance responses have been performed, and the management means updates the response information for errors that have been addressed by maintenance for which feedback has been received from unaddressed to addressed, and collectively updates the response information for error codes that are the same as the error code of the error for the same image processing device from unaddressed to addressed. [Effects of the Invention]

[0007] According to the present invention, it is possible to easily handle multiple errors with the same error code. [Brief explanation of the drawings]

[0008] [Figure 1] FIG. 1 is a diagram showing the overall configuration of an information providing system. [Figure 2] FIG. 2 is a diagram illustrating the hardware configuration of a repair location notification server and a printer. [Figure 3] FIG. 2 is a diagram illustrating a software configuration of the information providing system. [Figure 4] 10 is a flowchart showing a recommended action estimation process. [Figure 5] 10 is a flowchart showing a recommended action estimation process. [Figure 6] 10 is a flowchart showing a process for estimating a part to be repaired and a process for estimating a treatment; [Figure 7] 10 is a flowchart showing a treatment priority adjustment process; [Figure 8] 10 is a flowchart illustrating a process for changing the response state of an error history. [Figure 9] FIG. 10 is a diagram illustrating an example of an error information list screen. [Figure 10] FIG. 10 is a diagram showing an example of a repair procedure display screen. [Figure 11] FIG. 10 is a diagram showing an example of a repair procedure display screen. [Figure 12] FIG. 11 is a diagram illustrating a software configuration of an information providing system according to a third embodiment. [Figure 13] FIG. 11 is a diagram showing an example of a repair procedure display screen in the third embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0009] Example 1 FIG. 1 is a diagram showing the overall configuration of an information provision system. The information provision system collects device operation information, including error information, from image processing devices via a network, and provides the error information, recommended repair locations, and information on actions to repair engineers and others. The information provision system includes a repair location notification server 101 that provides a repair location notification service, a printer 102 that is an image processing device that detects errors, and a PC 103 that is a terminal that receives information from the repair location notification service. These are connected to each other so that they can communicate with each other via a network 100. The network 100 may be configured to enable data transmission and reception, and any communication method is acceptable. For example, the network 100 may be configured using any of a LAN, a WAN, a cellular network such as LTE or 5G, a wireless network, a telephone line, a dedicated digital line, or a combination of these.

[0010] The repair location notification server 101 provides a repair location notification service that provides a PC 103 used by an engineer with data for outputting information about errors occurring in an image processing device such as the printer 102 and information about recommended actions to resolve the error. The repair location notification server 101 is located, for example, on the Internet. The repair location notification server 101 first receives error information indicating an error that has occurred in the printer 102 or other image processing device from the image processing device and estimates information about one or more repair parts required to resolve the error. The repair location notification server 101 also manages the results of actions taken in the market for similar errors in the past as market performance and determines the priority of the action based on that market performance. The repair location notification server 101 then provides the error information, repair part information, information about actions to resolve the error, and other information to a PC 103 used by a customer engineer or other user responsible for repairing the printer 102. The repair location notification server 101 also collects feedback information from customer engineers who have taken actions to resolve the error.

[0011] In this embodiment, the repair location notification server 101 allows multiple transmission of errors from the printer 102 as a measure to prevent missed error transmission due to device restart when an error occurs or missed reception due to data loss due to the user's infrastructure environment. As a result, error information for the same error code may be duplicated in the error history managed by the repair location notification server 101. Note that, although this embodiment describes an example in which a corrective action to an error is estimated based on market performance, this is not limiting. For example, a corrective action to an error may be estimated using AI. The AI ​​collects information on the work performed by a service technician and the parts replaced, and uses a trained model that has undergone machine learning based on this information to estimate a corrective action.

[0012] The repair location notification server 101 may be realized by one or more information processing devices, a virtual machine (cloud service) using resources provided by a data center including information processing devices, or a combination of these. The information providing system can also be implemented as a web-based application and can be used via a web browser on the PC 103. The repair location notification server 101 may also be implemented as separate servers: a data collection server that collects data such as error information from the printer 102, and a repair location notification server that estimates repair locations based on the data collected by the data collection server and presents recommended measures. The repair location notification server 101 may also be configured as an on-premise system using a physical server.

[0013] The printer 102 is an example of an image processing device managed by the information providing system. There may be multiple printers 102 managed by the information providing system. The image processing device is not limited to a printer, but may be an MFP with functions such as printing, faxing, copying, and scanning, a scanner device, a 3D printer, or any other device that has a printing function, a copying function, a scanning function, a data network transmission function, or a fax function. When the printer 102 detects an error related to the printer itself or an attached optional device, it sends error information including equipment information (device information) to the repair location notification server 101.

[0014] A personal computer (PC) 103 is an example of an information processing device. A predetermined OS is installed on the PC 103. A browser 331, which will be described later, is also installed on the PC 103. The PC 103 displays a screen provided by the repair location notification server 101 via the browser 331. For example, the PC 103 transmits a request to the repair location notification server 101 via the browser 331 to acquire error information (alert information) for the printer 102. The PC 103 then receives the error information from the repair location notification server 101 in response and displays it on a graphical user interface (GUI). The PC 103 is used, for example, by a company that dispatches customer engineers (service personnel) to perform maintenance on the printer 102. The engineers can perform remote control operations on the printer 102 via a screen provided by the remote control server 104 and displayed on the browser 331 of the PC 103. The PC 103 may be any terminal capable of displaying a screen provided by an information providing system, such as a tablet or smartphone.

[0015] 2(A) is a diagram showing the hardware configuration of repair location notification server 101. Note that PC 103 also has the same hardware configuration as repair location notification server 101. Repair location notification server 101 has CPU 201, ROM 202, RAM 203, HDD 204, input device 205, output device 206, and communication I / F 207. Each hardware component is connected to a system bus.

[0016] The CPU (Central Processing Unit) 201 controls the entire repair location notification server 101. The CPU 201 reads out control programs stored in the ROM 202 or HDD 204 and executes various control processes. The ROM 202 (Read Only Memory) is a memory dedicated to reading data, and stores basic control programs of the information processing device, such as the BIOS (Basic Input Output System). The RAM (Random Access Memory) 203 is a memory from which data can be read and written. The RAM 203 functions, for example, as a work area for the CPU 201. The HDD (Hard Disk Drive) 204 stores various data and programs. Note that in this embodiment, an example will be described in which the repair location notification server 101 includes the HDD 204 as a storage device, but this is not limiting and the server may include other storage devices, such as an SSD or a disk drive for loading external media.

[0017] The input device 205 accepts operations from the user. For example, a keyboard or a pointing device is connected to the input device 205. The output device 206 displays information to the user. For example, a display such as an LCD screen is connected to the output device 206. The communication I / F 207 is an interface for connecting to the network 100. The repair location notification server 101 communicates with external devices such as the printer 102 and PC 103 via the communication I / F 207 and the network 100.

[0018] After the repair location notification server 101 is started, the CPU 201 executes the BIOS and loads the OS from the HDD 204 to the RAM 203 in an executable state. The CPU 201 loads various software modules (described later) from the HDD 204 to the RAM 203 as needed in accordance with the operation of the OS. The various software modules are executed and run by the CPU 201 in cooperation with the above-mentioned devices. The communication I / F 207 is connected to the network 100 and is controlled by the CPU 201 in accordance with the operation of the OS to achieve communication.

[0019] 2(B) is a diagram showing the hardware configuration of the printer 102. The printer 102 has a CPU 231, ROM 232, RAM 233, network controller 234, DKC 235, raster controller 237, print engine 238, operation unit 239, storage device 240, and device I / F. Of these, the parts excluding the print engine 238 are sometimes called a controller that manages the control system of the printer. Each hardware component is connected to a system bus.

[0020] The CPU 231 controls the entire printer 102 and comprehensively controls access to various devices connected to the system bus. The CPU 231 reads control programs stored in a ROM 232 or control programs and resource data (resource information) stored in an external memory 236 connected via a disk controller (DKC 235), and executes various control processes.

[0021] The ROM 232 stores programs executed by the CPU 231. The RAM 233 functions as the main memory, work area, etc. of the CPU 231. The RAM 233 is configured so that the memory capacity can be expanded by an optional RAM connected to an expansion port (not shown). The storage device 240 is a storage means that functions as a large-capacity memory. The storage device 240 stores image data, various programs, and various setting information.

[0022] The network controller 234 is a communication controller, such as a network interface card (NIC). The CPU 231 exchanges data with external devices on the network 100 via the network controller 234. The DKC 235 controls access to storage devices such as an external memory 236. The external memory 236 stores programs and resource data.

[0023] The operation unit 239 displays a screen and accepts user operation instructions via the screen. The operation unit 239 is, for example, a touch panel. The touch panel displays settings such as the operation mode of the printer 102 and the operating status of the printer 102. By associating input coordinates on the touch panel with display coordinates, a GUI can be configured that makes it appear as if the user can directly operate the screen displayed on the touch panel. The operation unit 239 may also be provided with buttons for performing operations such as setting the operation mode of the printer 102 and specifying content data to be printed.

[0024] Raster controller 237 is a controller that converts print data written in, for example, PDL language into image data. Print engine 238 uses known printing technology to form an image on a recording medium (e.g., paper) based on image data input from raster controller 237. The printing method performed by print engine 238 can be, for example, electrophotography (laser beam method), inkjet method, dye sublimation (thermal transfer) method, or the like, and is not limited to this method. Device I / F 241 is a connection I / F with an external device that can be connected via USB or the like.

[0025] Figure 3 shows the software configuration of the information provision system. This software configuration is realized by the CPU executing programs stored in the memory of each device. Note that the table schema and data described below are merely examples, and the table schema and various data formats are not limited to these.

[0026] The repair location notification server 101 includes an operation information receiving unit 311, an error determination unit 312, an error history management unit 313, and a priority determination unit 314. The repair location notification server 101 further includes a market performance management unit 315, an aggregation filter unit 316, a correct answer master management unit 317, an estimation result management unit 318, a repair procedure display unit 319, and a feedback management unit 320.

[0027] The operation information receiving unit 311 receives operation information from the printer 102. The information received by the operation information receiving unit 311 includes information indicating the operation status of the printer 102, such as information identifying the device, error information (event information) based on the occurrence of an error, the number of pages printed by the printer 102, and the remaining amount of consumables. The information identifying the device included in the operation information includes, for example, a device ID that uniquely identifies the device and a model number that indicates the model of the device. The error information is, for example, an error code for identifying the type of error. The error code is a unique character string code assigned to each type of error. If the operation information includes error information, the operation information receiving unit 311 transmits the operation information to the error determination unit 312.

[0028] When the error determination unit 312 receives error information from the operation information receiving unit 311, it obtains from the error history management unit 313 an error history indicating information about errors that have occurred in the past in the printer that sent the error information. Then, based on the received error information, the error determination unit 312 estimates one or more parts that caused the error, i.e., one or more repair parts that can be used to resolve the error. The error determination unit 312 also estimates the likelihood of a malfunction. The error determination unit 312 treats the repair parts identified to resolve the error and their likelihood of malfunction as the error determination results. The error determination unit 312 sends the estimation results to the priority determination unit 314 along with the error information.

[0029] Table 1 is an example of the determination result output by the error determination unit 312. [Table 1]

[0030] The determination result includes a part number that uniquely identifies the part that caused the error and the possibility of failure for that part. The possibility of failure is indicated, for example, as high or low. If the error determination unit 312 is unable to identify the part to repair because it is unable to identify the error based on the received error information (error code), the determination result is "part to repair unable to be identified." The error determination unit 312 also saves the error information received from the printer 102 as error history in the error history management unit 313.

[0031] The error history management unit 313 saves and manages the error information received from the error determination unit 312 as an error history. Table 2 is an example of the error history managed by the error history management unit 313. [Table 2] The error history includes an error ID that uniquely identifies the error, a device ID that uniquely identifies the printer where the error occurred, a model number that indicates the model, an error code that indicates the type of error that occurred, a counter value that indicates the number of prints when the error occurred, and the date and time the error occurred.In addition, the error history includes response information and a batch action flag that indicate the response status to the error.

[0032] The initial value registered for response information (response status) is "Not responded to," indicating that no response has been made. Then, if it is confirmed based on feedback information that the error has been responded to, the value is changed to "Resolved," indicating that the error has been resolved, and the status is registered. In the example shown in Table 2, the error information indicated by the records in the first and second rows is duplicate error information with the same error code. The batch processing flag is information indicating that the process of changing the response status of the error history was carried out in bulk. When duplicate error information is changed from "Not responded to" to "Resolved," the batch processing flag is set on all of the duplicate error information except for the error information with the most recent error occurrence date and time.

[0033] The priority determination unit 314 estimates the priority of the procedure for the action (maintenance response) that should be performed to resolve the error that has occurred in the printer 102. Specifically, when the priority determination unit 314 receives the determination result from the error determination unit 312, it acquires market performance and feedback information. The priority determination unit 314 acquires market performance that matches the model number and error code of the error information included in the determination result from the market performance management unit 315, and feedback information corresponding to the determination result from the feedback management unit 320. The priority determination unit 314 ranks the repair procedures based on the market performance and feedback information. The priority determination unit 314 stores the ranked repair procedures in the estimation result management unit 318 as the estimation result.

[0034] The market performance management unit 315 holds and manages two types of tally results for all actions taken to resolve errors that have occurred in the past. One is a tally on the number of replaced parts (market replacement results), which tally the number of part replacements for each model number, error code, and part number. The other is a tally on actions taken, which tally the actions taken for each model number and error code. The market performance management unit 315 collects performance information, including actions taken for each model number, error code, and part number, from customer engineers who have taken actions to resolve errors, tally the number of actions taken for each part and action, and holds and manages the tally results.

[0035] Table 3 is an example of market replacement results, which are a total of the number of replacement parts in the market results managed by the market performance management unit 315. [Table 3]

[0036] The market performance regarding the number of replaced parts includes a model number indicating the type of machine, an error code indicating the type of error that occurred, the part number of the part replaced to correct the error, and the number of replacements indicating the actual number of parts replaced.

[0037] The priority determination unit 314 determines the priority of repair parts based on the counted number of replacement parts and the determination result of the error determination unit 312. The priority determination unit 314 sets the priority by ranking repair parts that are likely to resolve errors, for example, in descending order of the number of market-record treatments that match the part numbers of repair parts included in the determination result. Table 4 is an example of the estimation result of repair parts estimated by the priority determination unit 314. [Table 4] The estimation results include the device ID, error code, part number of the repair part for the error, probability of the cause of the failure, and priority indicating the order of the parts to be repaired. An example of a method for calculating the priority of repair parts will be described later.

[0038] Table 5 is an example of market treatment results, which is a compilation of treatments of market results managed by the market performance management unit 315. [Table 5]

[0039] The market performance of the remedy includes the model number indicating the model, the error code indicating the type of error that occurred, and the remedy taken for the error. Furthermore, if the remedy taken was a replacement, the market performance of the remedy includes the part number indicating the replaced part.

[0040] The priority determination unit 314 determines the priority of the measures to resolve the error based on the estimated priority of the repair part and the determination result of the error determination unit 312. Table 6 is an example of the estimated result of the measures determined by the priority determination unit 314. Table 6 shows the priority of the process for an error with the model number Model-001 and the error code E001-001. [Table 6] The estimated results of the corrective action include the device ID, error code, the action to resolve the error, and the priority of each action. The action to resolve the error can be, for example, replacing a part, adjusting settings or updating firmware, or cleaning.

[0041] The feedback management unit 320 compiles feedback information about actions taken by customer engineers in response to past errors, and stores and manages the feedback information for each error. The feedback management unit 320 acquires device information, error information, and information about the process used to resolve the error from the PC 103 or the like as feedback information. The feedback management unit 320 then manages the action score for each combination of model and error ID. The feedback management unit 320 compiles and stores the scores of each action for each error of each model, and re-compiles the action score value according to the content of the feedback information each time it receives feedback information. The feedback management unit 320 transmits the action score corresponding to the estimated error, which is the determination result received from the error determination unit 312, to the priority determination unit 314. The priority determination unit 314 adjusts the priority value of the estimated result of the action based on the action score. The priority determination unit 314 manages the estimate for the repair part and the estimate for the action as a single estimation result.

[0042] The correct answer master management unit 317 manages a correct answer master that defines the theoretically correct combinations of parts and treatments. The aggregation filter unit 316, for example, excludes combinations that are not defined as theoretically correct from the combinations of repair parts and treatments obtained from the aggregation results of the treatment market performance (Table 5) and the treatment estimation results (Table 6) in accordance with the definitions of the correct answer master management unit 317.

[0043] The estimation result management unit 318 manages the combination of the priority (Table 4) and the treatment (Table 6) of the part to be repaired determined by the priority determination unit 314. Table 7 is an example of the estimation results managed by the estimation result management unit 318. [Table 7]

[0044] The estimation results managed by the estimation result management unit 318 include the priority of the part, device ID, error code, part number, failure cause probability, and priority of each treatment (replacement, cleaning, adjustment).

[0045] The repair procedure display unit 319 provides a repair procedure display screen to the PC 103, which is viewed by the customer engineer, via the browser 331. Specifically, when the repair procedure display unit 319 receives a repair procedure acquisition request including a device ID and an error ID from the browser 331 of the PC 103, it acquires an error history in which the device ID and error ID match from the error history management unit 313. The repair procedure display unit 319 acquires an estimation result in which the device ID and error code match from the estimation result management unit 318. Then, the repair procedure display unit 319 generates a repair procedure display screen based on the acquired error history and estimation result, and returns it to the browser 331 of the PC 103.

[0046] Furthermore, after the customer engineer has performed the action (maintenance response), the repair procedure display unit 319 generates a feedback information input screen for inputting the execution result (feedback) and provides it to the browser 331. The feedback information input screen displays error information including device information and error code in advance, and the customer engineer inputs the response details of the action (maintenance response) performed to resolve the error. The repair procedure display unit 319 also functions as a receiving means for receiving feedback on the response from the PC 103, and sends the received feedback information to the feedback management unit 320. Furthermore, based on the feedback information, the error history management unit 313 updates the response status, which indicates the response status of the error information it manages, from "not responded to" to "responded to."

[0047] In the present embodiment, the error determination unit 312 and the priority determination unit 314 make estimations using a rule base based on received error information and a history of past errors, but the present invention is not limited to this. For example, repair parts and measures may be estimated using machine learning, including deep learning.

[0048] The printer 102 has an operation information transmission unit 321, a job execution unit 322, and a control unit 323. The operation information transmission unit 321 transmits operation information of the printer 102, including error information that has occurred in the printer 102 and that has been collected by the control unit 323, to the repair point notification server 101. The job execution unit 322 executes jobs submitted to the printer 102. For example, when a print job is submitted, the job execution unit 322 executes printing processing based on the print job. The control unit 323 collects the operation status of the printer 102 and transmits the collected information as operation information to the repair point notification server 101 via the operation information transmission unit 321. For example, the control unit 323 detects an error that has occurred in the printer 102, collects the error information, and transmits the error information to the repair point notification server 101 via the operation information transmission unit 321.

[0049] The PC 103 has a browser 331. The PC 103 transmits a request to acquire repair part information for the printer 102 to the repair part notification server 101 via the browser 331, receives repair part information from the repair part notification server 101 in response, and displays it on a GUI. The PC 103 also receives a feedback information input screen for inputting feedback information from the repair part notification server 101 via the browser 331, and displays it on a GUI. In other words, the PC 103 displays a screen provided by the information providing system via the browser 331, which is a web browser.

[0050] Next, a process for estimating a measure to resolve an error in the printer 102 (recommended measure estimation process) will be described. The results of the recommended measure estimation process are stored in the estimation result management unit 318 and, when a display request is received from the PC 103, are provided to a customer engineer or the like via the browser 331. FIGS. 4 and 5 are flowcharts showing the recommended measure estimation process. In the recommended measure estimation process, the estimation results shown in Table 7 are finally calculated and stored in the estimation result management unit 318. The process executed by the printer 102 in the recommended measure estimation process is realized by the CPU 231 of the printer 102 reading out programs and resource data stored in memory (ROM 232, external memory 236, etc.) and executing the programs. The process executed by the repair point notification server 101 in the measure estimation process is realized by the CPU 201 of the repair point notification server 101 reading out programs and resource data stored in memory (ROM 202, HDD 204, etc.) and executing the programs.

[0051] In S401, the control unit 323 of the printer 102 detects whether an error has occurred in the printer 102. If the control unit 323 detects an error, it performs the process of S402. On the other hand, if no error is detected, the control unit 323 repeats the process of S401. In S402, the operation information transmission unit 321 of the printer 102 transmits operation information including error information corresponding to the error detected by the control unit 323 to the repair location notification server 101. Note that, hereinafter, operation information including error information will also be simply referred to as error information. The error information transmitted by the operation information transmission unit 321 includes, for example, an error ID that uniquely identifies the error, a device ID and model number that are device information, an error code that indicates the error, a counter value that indicates the number of prints when the error occurred, and the date and time the error occurred. In other words, the operation information transmission unit 321 of the printer 102 transmits information that the error history management unit 313 of the repair location notification server 101 manages as error history to the repair location notification server 101. In this embodiment, an example will be described in which the counter value is included in the error information, but for example, the counter value may be transmitted as counter information separate from the error information to the repair point notification server 101. When the counter information is transmitted separately from the error information, the repair point notification server 101 associates the error information with the counter information.

[0052] Receipt of error information from the printer 102 triggers the start of processing of a service (repair location notification service) provided by the repair location notification server 101. In S403, the operation information receiving unit 311 of the repair location notification server 101 receives the error information from the printer 102. In S404, the error determination unit 312 registers the error information received from the printer 102 in the error history management unit 313 as an error history.

[0053] In S405, the error determination unit 312 obtains, from the error histories managed by the error history management unit 313, error histories previously received from the printer 102 that was the sender of the error information received in S403. Specifically, the error determination unit 312 obtains, from the error histories managed by the error history management unit 313, error histories that match the device ID included in the error information received from the printer 102. For example, if the device ID included in the error information is "DEV0000001", the error determination unit 312 obtains the records in the first and third rows of Table 2.

[0054] In S406, the error determination unit 312 outputs a list of part numbers of parts to be repaired and their possible failures to resolve the error based on a rule base, using the error information received from the printer 102 and the error history acquired from the error history management unit 313. The list of part numbers of parts to be repaired and their possible failures is shown in Table 1.

[0055] In S407, the priority determination unit 314 obtains from the market performance management unit 315 market performance data (market replacement performance data and market action performance data) that match the model number and error code in the error information. For example, assume that the model number included in the error information is "Model-001" and the error code is "E001-0001." In this case, the priority determination unit 314 obtains the records in rows 1 to 6 of Table 3 as market replacement performance data, and the records in all rows of Table 6 as market action performance data.

[0056] In S408, the priority determination unit 314 checks the determination result (Table 1) of the repair parts output by the error determination unit 312 and determines whether there are any parts determined to have a high failure probability. Specifically, if the determination result (Table 1) listing the part numbers and failure probabilities output in S406 indicates a high failure probability for the repair parts, the priority determination unit 314 determines that there are any parts determined to have a high failure probability, and performs the process of S409. For example, if there is a mixture of high and low probabilities for each part, the priority determination unit 314 performs the process of S409. On the other hand, if the failure probability for all repair parts is low, the priority determination unit 314 determines that there are no parts determined to have a high failure probability, and performs the process of S410. The process of S410 will be described in Example 2.

[0057] In S409, the priority determination unit 314 ranks the parts that are estimated to need repair and sets priorities. Specifically, the priority determination unit 314 first obtains, from the market performance acquired in S407, the number of replacement parts whose part numbers match the part numbers included in the list of failure possibilities (Table 1) output in S406. Next, the priority determination unit 314 calculates the failure cause probability for each part number and associates it with the part number. The failure cause probability is calculated, for example, as "(number of replacement repair parts / total number of replacements of all parts replaced due to errors) x 100." In other words, the priority determination unit 314 calculates the failure cause probability for each part so that the sum of the failure cause probabilities of all parts replaced for an error code that has occurred in a certain model is 100%.

[0058] For example, suppose the part numbers of the estimated repair parts are [Part1-111, Part2-222, Part3-333, Part4-444, Part5-555] and the market performance data acquired in S407 are lines 1 to 5 of Table 3. In this case, the total number of replacements for all parts in the market performance data from lines 1 to 5 is 1,000. The failure cause probability for part number "Part1-111" is "(510 / 1,000) x 100 = 51.0." Similarly, the failure cause probabilities for other part numbers "Part2-222," "Part3-333," "Part4-444," and "Part5-555" are "21.8," "9.2," "4.0," and "14.0," respectively. The priority determination unit 314 then sets the calculated failure cause probabilities as priorities. In this embodiment, the failure cause probability is calculated as the ratio of the number of repaired parts that have been repaired to the total number of replacements of all repaired parts that need to be repaired, but the method of calculating the failure cause probability is not limited to this and other methods may be used.

[0059] Next, the priority determination unit 314 performs priority ranking. At this time, the priority determination unit 314 refers not only to the calculated failure cause probability but also to the list (Table 1) of part numbers of parts to be repaired and their failure probabilities output by the error determination unit 312 in S406. Therefore, the priority determination unit 314 performs priority ranking based on the calculated failure cause probability and the list of failure probabilities output by the error determination unit 312 in S406, taking into account the level of failure probability of each part.

[0060] For example, the failure cause probability of "Part1-111" is "(510 / 1000) x 100 = 51.0." Similarly, the failure cause probabilities of other part numbers "Part2-222," "Part3-333," "Part4-444," and "Part5-555" are "21.8," "9.2," "4.0," and "14.0," respectively. Furthermore, based on the failure probability of the part number, the priority determination unit 314 sorts the repair parts with a "high probability" and those with a "low probability" in descending order of failure cause probability. In Table 1, the failure probabilities of part numbers "Part2-222," "Part3-333," "Part4-444," and "Part5-555" are "high probability," "high probability," "high probability," "low probability," and "low probability," respectively. The failure cause probabilities of the "high probability" repair parts "Part1-111," "Part2-222," and "Part3-333," respectively, are "51.0," "21.8," and "9.2." Therefore, the order of priority is "Part1-111," "Part2-222," and "Part3-333." Similarly, the failure cause probabilities of the "low probability" repair parts "Part4-444" and "Part5-555," respectively, are "4.0" and "14.0," and the order of priority is "Part5-555" and "Part4-444." Then, when these are combined and ranked in order of decreasing failure probability, the priorities are "1" to "5" for "Part1-111," "Part2-222," "Part3-333," "Part5-555," and "Part4-444," respectively. Furthermore, the priorities in the estimation results of the repair parts estimated by the priority determination unit 314 for "Part4-444" and "Part5-555" which have a low probability of failure are set to no priority ("-") as shown in Table 4.

[0061] In S411 and S412, the aggregation filter unit 316 filters out actions that cannot exist for the component from the combinations of repair parts and actions identified in the repair part estimation process. In S411, the aggregation filter unit 316 verifies the combinations of repair parts and actions identified in the repair part estimation process according to the definitions in the correct answer master management unit 317, and identifies combinations of repair parts and actions that are theoretically incorrect. For example, depending on the component, one of the actions "replacement," "cleaning," or "adjustment" may not exist, and actions that cannot exist are theoretically incorrect actions. The correct answer master defines theoretically correct actions. The aggregation filter unit 316 determines that combinations that do not exist in the definitions in the correct answer master management unit 317 are theoretically incorrect repair parts. If the combination is theoretically incorrect, the aggregation filter unit 316 performs processing in S412. On the other hand, the aggregation filter unit 316 determines that combinations that exist in the definitions in the correct answer master management unit 317 are theoretically correct repair parts. If the combination is theoretically correct, the aggregation filter unit 316 performs processing in S413.

[0062] In S412, the aggregation filter unit 316 deletes combinations of repair parts and treatments that are theoretically incorrect. The aggregation filter unit 316 sets the priority of treatments that are determined to be impossible to exist to "-" (none). For repair parts that the error determination unit 312 determines to be unlikely, all treatments are also set to "-". Even if a treatment exists for the repair part, it is set to "-", but this is distinguished from cases where no treatment exists for the repair part using the method described below in the explanation of UI display.

[0063] In S413, the priority determination unit 314 checks whether verification of all combinations of repair parts and actions (S411) has been completed. If verification of all combinations of repair parts and actions has not been completed, the process returns to S411. On the other hand, if verification of all combinations of repair parts and actions has been completed, the process proceeds to S414. In S414, the priority determination unit 314 obtains each action score based on feedback information from the feedback management unit 320, and recalculates and adjusts the action priority based on the action score. The method of adjusting the action priority will be described later.

[0064] In S415, the priority determination unit 314 registers the calculated priority of each measure, together with the device ID and error code of the error information, as an estimation result in the estimation result management unit 318. For example, an example of the estimation result of the recommended measure calculated from the examples of Tables 4 and 6 is shown in Table 7. As described above, the repair point notification server 101 can estimate the recommended measure for the error that occurred in the printer 102. When the repair procedure display unit 319 receives a request from the browser 331 of the PC 103 to display the measure estimated to resolve the error, it displays a repair procedure display screen based on the estimation result (Table 7) registered in the estimation result management unit 318.

[0065] 6 is a flowchart showing the processing in S407 to S413 of the recommended action estimation process executed by the priority determination unit 314. Each processing executed by the priority determination unit 314 is realized by the CPU 201 of the repair point notification server 101 reading out programs and resource data stored in memory (ROM 202, HDD 204, etc.) and executing the programs.

[0066] FIG. 6(A) is a flowchart showing the repair part estimation process executed by the priority determination unit 314. Through the repair part estimation process, the priority determination unit 314 finally calculates the repair part estimation result (Table 4). In S601, the priority determination unit 314 acquires market replacement records whose part numbers match the repair parts included in the determination result by the error determination unit 312 from the market replacement records (Table 3), which are a compilation of the number of replacement parts in market records managed by the market performance management unit 315. The market replacement records acquired here include information on the model number, error code, and replacement part. In S602, the priority determination unit 314 tallyes up the replacement parts and the number of replacements for each combination of model number and error code. In the compilation, the priority of the repair parts is also ranked.

[0067] In S603, the priority determination unit 314 deletes invalid combinations from the combinations of model numbers, error codes, and replacement parts. The priority determination unit 314 deletes invalid combinations by having the aggregation filter unit 316 perform filtering using a correct answer master that defines theoretically correct processing for failures managed in the correct answer master management unit 317. In S604, the priority determination unit 314 registers the repair part estimation results calculated up to S603 in the priority determination unit 314. Through the repair part estimation processing shown in FIG. 6(A), the priority determination unit 314 calculates the repair part estimation results shown in Table 4.

[0068] 6(B) is a flowchart showing the treatment estimation process executed by the priority determination unit 314. Through the treatment estimation process, the priority determination unit 314 finally calculates the treatment estimation result (Table 6). In S605, the priority determination unit 314 acquires market replacement records whose part numbers match the repair parts included in the determination result by the error determination unit 312 from the market treatment record (Table 5), which is a compilation of treatments for market results managed by the market performance management unit 315. The market treatment record acquired here includes information on the model number, error code, and performed treatment. In S606, the priority determination unit 314 tally up the performed treatments and the number of treatments for each combination of model number and error code.

[0069] In S607, the priority determination unit 314 determines the priority of each action based on the actual results of actions taken in the market tabulated in S606. Here, the actions available as market results are categorized and tabulated into three types: "replacement," "adjustment," and "cleaning." The number of actions taken for each model number and error code is calculated, and the respective percentages are calculated as percentages. The action with the highest calculated percentage is assigned a priority of "A." Furthermore, using the action with the highest percentage as the standard, if the difference from that action is within 5%, the action is assigned a priority of "A." If the difference is between 5% and 20%, the action is assigned a priority of "B." If the difference is greater than 20%, the action is assigned a priority of "C." For example, if the percentage of "replacement" is 50%, the percentage of "cleaning" is 35%, and the percentage of "adjustment" is 15%, then "replacement" will have a priority of "A," "cleaning" will have a priority of "B," and "adjustment" will have a priority of "C." In the example of Table 5, Table 6 shows the estimated recommended actions for an error with a model number of Model-001 and an error code of E001-001. In S608, the priority determination unit 314 registers the estimated results of the actions tallied up to S607 in the priority determination unit 314. Note that the estimated results may include the proportion of the number of actions for each action along with the priorities indicated by "A," "B," and "C." Through the action estimation process shown in FIG. 6(B), the priority determination unit 314 calculates the estimated results of the actions shown in Table 6.

[0070] Details of the treatment priority adjustment process in S414 will be explained using Fig. 7. Fig. 7 is a flowchart showing the treatment priority adjustment process executed by the priority determination unit 314. This process is executed after the priority determination unit 314 confirms in S413 that verification of all combinations of repair parts and treatments has been completed, and before registering the estimation results in the estimation result management unit 318 in S415. By the treatment priority adjustment process shown in Fig. 7, the priority determination unit 314 calculates the estimation results (Table 7) to be registered in the estimation result management unit 318. Each process executed by the priority determination unit 314 is realized by the CPU 201 of the repair point notification server 101 reading out programs and resource data stored in memory (ROM 202, HDD 204, etc.) and executing the programs.

[0071] In S701, the priority determination unit 314 adjusts the priority of the action estimated by the action estimation process based on feedback information. First, the priority determination unit 314 obtains the percentage of the number of actions based on market performance of the recommended action estimated based on market performance as an action score. This percentage of the action score is the percentage used when setting the priority in S607. The action score is a value assigned to each of "replacement," "adjustment," and "cleaning," and the initial value for each error code is calculated from the percentage of actions in market performance. For example, if the percentage of "replacement" is 50%, the percentage of "cleaning," and the percentage of "adjustment" is 35%, and the percentage of "adjustment" is 15%, the initial score for "replacement" will be 50, the initial score for "cleaning," and the initial score for "adjustment" will be 35, and the initial score for "adjustment." The priority determination unit 314 then reflects the content of the feedback information stored in the feedback management unit 320 and changes the action score. At this time, the priority determination unit 314 filters feedback information linked to error history to which a "batch action flag" has been assigned so as not to reflect the feedback information. The "batch action flag" will be explained later in the section on error information response status change processing. Based on the feedback information, the priority determination unit 314 increments the score by +2 for actions that were actually performed and decrements the score by -1 for other actions. For example, if there are two pieces of feedback information about "replacement" being performed, the score for "replacement" is updated to 54 by adding +2 for two cases, the score for "cleaning" is updated to 33 by adding -1 for two cases, and the score for "adjustment" is updated to 13 by adding -1 for two cases. In addition, when adding action scores, the number of consecutive score increments for the action already with the highest action score is counted. For example, when "replacement" has the highest score and one piece of feedback is received that indicates a replacement action, the count is incremented by +1, and when feedback is received that indicates a different action, the count is decremented by -1. The count cannot be less than 0. The order in which feedback is processed is, for example, the order in which the feedback was received.

[0072] In S702, the priority determination unit 314 updates the treatment priority based on the treatment score acquired in S701. According to the method of the market performance aggregation processing described in S607, the treatment score is used as a proportion of each treatment to determine the priority of each treatment again. In S703, the priority determination unit 314 checks how many times the treatment with the highest treatment score has received a score increase in that state. The count calculated in S701 is acquired, and if the count value is 10 or greater, the priority determination unit 314 performs the processing of S704. On the other hand, if the count value is 9 or less, the priority determination unit 314 performs the processing of S705.

[0073] In S704, the priority determination unit 314 assigns a special priority of "A+" to the action with the highest action priority of "A" and ends the process. In S705, the priority determination unit 314 simply ends the process. That is, the action with the highest action priority of "A" is assigned the priority of "A" as is. After completing S704 or S705, the priority determination unit 314 registers the priority of the estimated recommended action for which adjustment has been completed in the estimation result management unit 318. By the action priority adjustment process shown in FIG. 7, the priority determination unit 314 calculates the estimation result to be registered in the estimation result management unit 318 shown in FIG. 7.

[0074] When an error information acquisition request including a device ID is received from the browser 331 of the PC 103, the repair procedure display unit 319 generates an error information list screen (FIG. 9) based on the error history managed by the error history management unit 313 and provides it to the PC 103. The alert list on the error information list screen displays a list of error information whose response status (response information) in the error history (Table 2) is "not handled."

[0075] When error information is selected from the alert list on the error information list screen, the repair procedure display unit 319 of the repair location notification server 101 displays a repair procedure display screen ( FIG. 10 ) showing the repair procedure for the selected error. The customer engineer refers to the repair procedure display screen and performs the high-priority process. When the error is resolved by the implemented process, the customer engineer enters feedback information on a feedback information input screen (not shown) provided on the browser 331 of the PC 103 and sends it to the repair location notification server 101. The feedback information sent from the PC 103 to the repair location notification server 101 includes device information including the device ID on which the process was performed, error information such as an error code, the date and time the error occurred, and information on the process that resolved the error. Upon receiving the feedback information, the repair location notification server 101 manages the feedback information in the feedback management unit 320. Furthermore, the repair location notification server 101 performs a process to change the response status of the error history managed by the error history management unit 313 based on the feedback information. In this embodiment, the repair location notification server 101 allows multiple error transmissions to prevent missed error transmissions due to device restarts when an error occurs, or missed reception due to data loss caused by the user's infrastructure environment. Therefore, error information with the same error code may be duplicated. Even if error information is duplicated, only one action is taken for the error in the duplicated error information. Therefore, when a report is received that an action has been taken for one of the duplicated error information and the action has been taken, it is desirable to treat the other duplicated error information as also having been taken.

[0076] Figure 8 is a flowchart explaining the process of changing the response status of an error history. Each process shown in Figure 8 is realized by CPU 201 of repair point notification server 101 reading out programs and resource data stored in memory (ROM 202, HDD 204, etc.) and executing the programs. The process of changing the response status of an error history is started when repair point notification server 101 receives from PC 103 the details of the measures taken to resolve the error as feedback on the estimation result calculated by repair point notification server 101.

[0077] In S800, the error history management unit 313 acquires error information from the error history based on feedback information received from the browser 331 of the PC 103. The error history management unit 313 acquires all error information associated with the device ID included in the feedback information and having a response status of "unsupported" from the error history. In other words, the error history management unit 313 acquires not only the repair procedure display target errors that are the targets of treatment displayed on the repair procedure display screen, but also all error information for the printer 102 whose response status is "unsupported."

[0078] In S801, the error history management unit 313 searches the error information acquired in S800 for error information with the same error code as the error code included in the feedback information to check whether there is error information with the same error code. That is, the error history management unit 313 checks whether there is other error information with the same error code as the repair procedure display target error that is the target of treatment displayed on the repair procedure display screen. If there is error information with the same error code as the repair procedure display target error, the process proceeds to S803. On the other hand, if there is no error information with the same error code as the repair procedure display target error, the process proceeds to S802.

[0079] In S802, the error history management unit 313 changes the response status of the error information of the error for which the repair procedure is to be displayed to "Response Completed." That is, the error history management unit 313 updates the response status of the error information for which feedback related to the action (maintenance action) input by the customer engineer who took action to resolve the error has been received from "Not Response Completed" to "Response Completed."

[0080] In S803, the error history management unit 313 changes the response status of the error for which repair procedures are to be displayed and all errors with the same error code as the error for which repair procedures are to be displayed to "resolved." That is, the error history management unit 313 updates the response status of the error for which feedback related to the maintenance response has been received to "resolved," and simultaneously updates the response status of all errors with the same error code as the error from "not resolved" to "resolved." At the same time, the error history management unit 313 assigns a "collective action flag" to the error information of all errors whose response status has been changed collectively, except for the error for which repair procedures are to be displayed. Note that the error for which repair procedures are to be displayed is the error with the most recent occurrence date and time among the errors with the same error code. Therefore, the "collective action flag" is assigned to the error information of all errors whose response status has been changed collectively, except for the one with the most recent occurrence date and time. The "collective action flag" indicates that the error information is the error for which feedback has been received and the response status has been changed collectively. That is, the error history management unit 313 assigns a "collective action flag" to error information that has the same error code as the error for which feedback regarding maintenance response has been received and whose response status has been updated to "resolved" in a lump sum.

[0081] In this embodiment, when aggregating maintenance response records, error information marked with a "batch action flag" is not included in the aggregation. This allows for the aggregation of duplicate error information with the same error code, even if the printer 102 sends multiple errors. For example, when saving feedback information in the feedback management unit 320, the feedback information is linked to all error information whose response status has been changed to "resolved." Then, when aggregating feedback information and calculating a response score, the feedback management unit 320 filters out feedback information from error histories marked with a "batch action flag" so as not to aggregate it. By excluding feedback information from error histories marked with a "batch action flag" when calculating the response score, the accuracy of the response score used in the response priority adjustment process can be improved. When multiple feedbacks for duplicate errors are saved for a single user repair response, a discrepancy occurs between the number of dispatches and the number of feedbacks. However, setting the "batch action flag" can suppress this discrepancy.

[0082] In S804, the error history management unit 313 saves the error information whose response status has been changed to "resolved" in the error history managed by the error history management unit 313. In this way, the response status of the error managed as the error history that is the target of repair procedure display and the error with the same error code as the target of repair procedure display can be changed to "resolved" all at once. In addition, the repair procedure display unit 319 reflects the change from "not handled" to "handled" by updating the display of the list of alarms that show the "not handled" error information displayed on the error information list screen, and excludes the error information that has been changed to "handled" from the list of alarms.

[0083] The repair location notification server 101 allows multiple error transmissions to prevent missed error transmissions due to device restarts when an error occurs or data loss due to the user's infrastructure environment. Therefore, error information for the same error code may be duplicated. The response status change process shown in FIG. 8 allows for error information for the same error code to be processed as well, even if duplicate error information is received from the printer 102. Once a response to one error is completed, all errors with the same error code can be processed as completed. By collectively marking duplicate errors as having been processed, errors that occur when compiling error history data can be reduced, improving the accuracy of estimating the location of the failure and the response. Furthermore, by collectively marking errors as having been processed, the customer engineer only needs to report the response once, eliminating the need to report the response to each error individually, thereby reducing the workload of the customer engineer.

[0084] In this embodiment, an example has been described in which the response status of the error code that is the same as the error for which feedback was received is automatically updated to "resolved," but the user may be allowed to select whether or not to update all error information for the same error code at once. For example, a check box that allows the customer engineer who has performed the action to select whether or not to "mark other alerts as resolved as well" can be provided on the screen where the feedback information is entered, thereby accepting the selection of whether or not to perform a bulk update.

[0085] 9 is a diagram showing an example of an error information list screen. The error information list screen 900 is provided by the repair procedure display unit 319 of the repair point notification server 101 that has accepted an error information acquisition request including a device ID from the browser 331 of the PC 103, and is displayed on the browser 331 of the PC 103. The error information list screen 900 displays error information of devices managed by the repair point notification server 101.

[0086] The error information list screen 900 includes device information including a device ID 901 and a list of alerts. The device ID 901 displays the device ID specified in the error information acquisition request. Furthermore, the error information list screen 900 may include information about the customer who has installed the device, a service information list, a list of completed actions, and a firmware update list. The service information list displays notes for the user (here, the user in charge of repairs) regarding the device. The completed actions list displays a list of alerts (errors) for which repair actions have been completed in the device. The firmware update list displays a list of the update history of the software (firmware) installed in the device.

[0087] The alert list displays a list of error information 902 that has occurred in the specified device. The error information 902 includes an error code 904 and an occurrence date and time 905. If there are duplicate errors, the error information 902 displays the number of duplicate errors 903. The error information 902 may also display the estimated accuracy of the error information.

[0088] The error information 902 is information about an error that has occurred in a device associated with the device ID specified in the error information acquisition request. The error information acquired here includes at least the error code, the date and time of occurrence, and the response status. The repair procedure display unit 319 displays in the alert list only errors whose response status is "unhandled" in the error history managed by the error history management unit 313. If there is information about multiple errors, they are displayed in order of most recent date and time of occurrence, for example.

[0089] When the error information contains multiple errors with the same error code, the repair procedure display unit 319 displays them together as a single piece of error information 902, and then displays the number of duplicate errors as the number of duplicate errors 903. Error code 904 displays the error code for each error. Occurrence date and time 905 displays the date and time when each error occurred. In the case of duplicate errors where errors with the same error code are displayed together, the date and time when the most recent error occurred among the duplicate errors is displayed.

[0090] 10 and 11 are diagrams showing examples of repair procedure display screens. Repair procedure display screen 1000 is provided by repair procedure display unit 319 of repair location notification server 101, which has received a repair procedure acquisition request including a device ID and an error code from browser 331 of PC 103, and is displayed on browser 331. The information provision system displays repair procedures for resolving each error that has occurred, and repair procedure display screen 1000 includes repair procedures for the error specified by browser 331. For example, when a customer engineer selects error information 902 from the alert list on error information list screen 900 (FIG. 9), browser 331 transmits a repair procedure acquisition request including the error code and device ID corresponding to the selected error information 902. Then, browser 331 displays the repair procedure display screen provided by repair location notification server 101 in response to the repair procedure acquisition request.

[0091] Fig. 10 is an example of a repair procedure display screen when there is no treatment assigned a treatment priority of "A+". Fig. 11 is an example of a repair procedure display screen when there is a treatment assigned a treatment priority of "A+". Repair procedure display screen 1000 displays the error history and estimation results managed by repair point notification server 101. Repair procedure display screen 1000 includes device ID 1001, error code 1002, occurrence date and time 1003, repair part 1004, part number 1005, failure cause probability 1006, recommended treatment 1007, part number 1009, and response completion button 1020.

[0092] Device ID 1001 displays the device ID of the error history whose error code matches the error ID specified in the repair procedure acquisition request and the error history managed by error history management unit 313. Error code 1002 displays the error code of the error history whose error code matches the error ID specified in the repair procedure acquisition request and the error history managed by error history management unit 313.

[0093] The occurrence date and time 1003 displays the date and time of the error history managed by the error history management unit 313, where the error code specified in the repair procedure acquisition request matches the error code. The repair part 1004 displays the estimation result managed by the estimation result management unit 318, where the error ID of the repair procedure acquisition request is located. The repair procedure display unit 319 displays the estimation results in the repair part 1004 in descending order of priority for the replacement part estimation results, thereby indicating to the customer engineer which part to repair first. Note that in this embodiment, the estimation results are displayed in order of priority. However, for example, if there are multiple estimation results, an icon or message indicating that the part is a "part that requires repair" may be displayed on the repair procedure display screen 1000 for an estimation result with a priority above a certain threshold. The part number 1005 displays the part number of the repair part 1004. In addition, in the case of a part that is determined by the error determination unit 312 to have a low probability of failure, it may be displayed lower in accordance with the priority managed by the estimation result management unit 318, and the display itself may be grayed out.

[0094] Failure cause probability 1006 displays the failure cause probability of the repair part managed by the estimation result management unit 318, and indicates the proportion of market performance that the part in question accounts for among parts of the same model that have been replaced due to the same error. Furthermore, in the case of a part that has been determined by the error determination unit 312 to have a low probability of failure, failure cause probability 1006 may be displayed as "low probability" rather than a numerical value indicating a proportion.

[0095] Recommended action 1007 displays the priority of the recommended action. Recommended action 1007 displays the priority of "replacement," "cleaning," and "adjustment" as "A+," "A," "B," "C," or "-" based on the recommended action estimation result managed by the estimation result management unit 318. Recommended action 1007 indicates that the priority of replacement is "A." The "-" displayed in recommended action 1008 indicates that a specific action does not exist for some parts. Recommended action 1112 is an example of a case where an action with action priority "A+" is assigned as a result of the action priority adjustment process (FIG. 7) based on feedback.

[0096] The response completion button 1020 is a button that the customer engineer selects when the action to resolve the error (maintenance response) is completed. Upon detecting the selection of the response completion button 1020, the repair procedure display unit 319 of the repair location notification server 101 provides a feedback information input screen to the browser 331 of the PC 103. The customer engineer inputs feedback information according to the display on the feedback information input screen and transmits the feedback information to the repair procedure display unit 319 of the repair location notification server 101. The feedback information transmitted from the PC 103 to the repair location notification server 101 includes device information for the device for which maintenance was performed and error information including an error code corresponding to the resolved error. The feedback information transmitted from the PC 103 to the repair location notification server 101 also includes the action taken by the customer engineer to resolve the error (maintenance response content). The feedback information input screen also displays information indicating how many errors with the same error code as the currently displayed error have occurred. That is, if the number of duplicate errors 903 is displayed in the alert list, information explaining the number of duplicate errors 903 is displayed on the feedback information input screen.

[0097] The part number 1009, failure cause probability 1010, and recommended action 1011 are examples of parts determined by the error determination unit 312 to have a low probability of failure. In this case, they are displayed lower in the order of priority managed by the estimation result management unit 318. Furthermore, parts determined to have a low probability of failure may be displayed, for example, grayed out, so that they can be distinguished at a glance from parts determined to have a high probability of failure. Furthermore, actions for parts determined to have a low probability of failure are displayed as "--" as shown in the recommended action 1011, but a background color is added to distinguish them from "--" when no action exists (a theoretically incorrect action). In this way, the repair procedure display screen 1000 ranks repair parts for resolving an error that has occurred in the printer 102 in order of the likelihood of resolving the error, and also displays recommended actions.

[0098] As described above, according to this embodiment, even if duplicate error information with the same error code is received from the printer 102, once a resolution for one error is completed, it is possible to process errors with the same error code as having been resolved. By collectively marking errors as resolved, errors that may arise from aggregating error history, etc., can be reduced, improving the accuracy of estimating the location of a failure and the resolution. Furthermore, by collectively marking errors as resolved, customer engineers no longer need to report that each error has been resolved, thereby reducing the amount of work required by the customer engineers. Furthermore, by displaying duplicate errors together in the alert list on the error information list screen, the screen becomes easier for customer engineers to view, reducing the risk of overlooking errors and resulting in missed resolutions. Furthermore, by displaying duplicate errors together in the alert list on the error information list screen, feedback information only needs to be entered on the screen once, thereby reducing the time required for customer engineers to enter feedback information.

[0099] Example 2 In the first embodiment, it was assumed that the error determination unit 312 outputs one or more components with a high failure probability in S406. That is, in the first embodiment, the error determination unit 312 outputs one or more components with a high failure probability, and the process of S409 is performed after the determination of S408. However, the error determination unit 312 may output only components with a low failure probability without outputting components with a high failure probability. In this case, the process of S410 is performed after the determination of S408. According to the display method of the repair procedure display screen in the first embodiment, all components are displayed grayed out, the failure cause probability is displayed as "low probability," and the priority of the treatment is not displayed as "A," "B," or "C." This results in insufficient information being provided to the user. Therefore, in this embodiment, an example will be described in which appropriate information is displayed on the repair procedure display screen even when the error determination unit 312 outputs only components with a low failure probability. Note that the description of the same parts as in the first embodiment will be omitted.

[0100] The software configuration in this embodiment is the same as the software configuration in embodiment 1 (FIG. 3). In this embodiment, the priority determination unit 314 ranks the parts that are estimated to need repair and sets priorities in S410. In S409 in embodiment 1, the difference in the level of failure probability output by the error determination unit 312 between parts was used to process the priorities and failure cause probabilities, but this is not done in this embodiment.

[0101] Specifically, the priority determination unit 314 first obtains, from the market performance acquired in S407, the number of replacement parts whose part numbers match the part numbers included in the failure probability list (Table 1) output in S406. In this embodiment, it is assumed that all of the negotiability values ​​in the failure probability list (Table 1) output by the error determination unit 312 are "low." Next, the priority determination unit 314 calculates the failure cause probability for each part number and associates it with the part number. The failure cause probability is calculated, for example, as "(number of replacement repair parts / total number of replacements of all parts replaced due to errors) x 100." In other words, the priority determination unit 314 calculates the failure cause probability for each part so that the sum of the failure cause probabilities of all parts replaced for an error code that has occurred in a certain model is 100%.

[0102] For example, suppose the part numbers of the estimated repair parts are [Part1-111, Part2-222, Part3-333, Part4-444, Part5-555] and the market performance data acquired in S407 are lines 1 to 5 of Table 3. In this case, the total number of replacements for all parts in the market performance data from lines 1 to 5 is 1,000. The failure cause probability for part number "Part1-111" is "(510 / 1,000) x 100 = 51.0." Similarly, the failure cause probabilities for other part numbers "Part2-222," "Part3-333," "Part4-444," and "Part5-555" are "21.8," "9.2," "4.0," and "14.0," respectively. The priority determination unit 314 then sets the calculated failure cause probabilities as priorities.

[0103] The priority determination unit 314 performs priority ranking. At this time, the priority determination unit 314 performs ranking based on the calculated failure cause probability. Table 8 is an example of the estimation results managed by the estimation result management unit 318 in this embodiment. Table 8 in this embodiment corresponds to Table 7 in Example 1. [Table 8]

[0104] The estimation results managed by the estimation result management unit 318 include the priority of the part, device ID, error code, part number, failure cause probability, and priority of each treatment, such as replacement, cleaning, and adjustment. When displaying a repair procedure display screen based on the estimation results, the repair procedure display unit 319 does not display a distinction between "high probability" and "low probability" for the failure cause probability (for example, displaying "low probability" in gray), nor does it hide the priority. The repair procedure display unit 319 displays all repair parts in color on the repair procedure display screen, and also displays the failure cause probability and treatment priority.

[0105] As described above, according to this embodiment, even when the error determination unit 312 does not output parts with a high probability of failure but outputs only parts with a low probability of failure, it is possible to display appropriate information on the repair procedure display screen and provide sufficient information to the user.

[0106] Example 3 In the second embodiment, an example was described in which when the error determination unit 312 determines that all parts are likely to fail as having a low probability, the same display is made as for a high probability. However, if the same display is used for low probability and high probability, customer engineers will not be able to distinguish the difference in estimation accuracy. Therefore, in this embodiment, an icon display that can identify the estimation accuracy (reliability) is added to the repair procedure display screen, so that customer engineers can recognize the accuracy of the information displayed on the repair procedure display screen. Note that in this embodiment, explanations of parts that are similar to those in the first embodiment will be omitted.

[0107] The repair location notification server 101 of this embodiment includes a reliability determination unit 1201 in addition to the software configuration of the repair location notification server 101 shown in FIG. 3. The reliability determination unit 1201 determines the accuracy (estimation accuracy, reliability) of the estimated information. The reliability is determined, for example, based on the failure probability of each component in the list of estimated faulty components (Table 1) output by the error determination unit 312 and the market performance managed by the market performance management unit 315. The reliability determination unit 1201 first increases or decreases the reliability level by one level depending on whether the failure probability of each component in the list of faulty components output by the error determination unit 312 includes a high probability. For example, if a high probability is included, the reliability is set to 3, and if a high probability is not included, the reliability is set to 2. Next, the reliability determination unit 1201 increases or decreases the reliability level by one level based on the state of the market performance of the target error managed by the market performance management unit 315, or leaves it as is. For example, if the market performance does not reach a reliable parameter, the reliability is decreased by one level. Table 9 shows an example of the reliability level determined by the reliability determination unit 1201. The number of stars represents the reliability, with more stars being assigned as the reliability increases. [Table 9] The reliability level is determined based on whether the output of the error determination means included in the error determination unit 312 includes a high-probability component and whether the market performance parameter is equal to or greater than a threshold value; the more information is available, the more "★" icons representing reliability are displayed. If the failure probability of each component in the list of failed components output by the error determination unit 312 includes a high probability, and the market performance for the target errors managed by the market performance management unit 315 has reached a reliable parameter, the reliability is 3. If the failure probability of each component in the list of failed components output by the error determination unit 312 includes a high probability, and the market performance for the target errors managed by the market performance management unit 315 has not reached a reliable parameter, the reliability is 2. If the failure probability of each component in the list of failed components output by the error determination unit 312 does not include a high probability, and the market performance for the target errors managed by the market performance management unit 315 has reached a reliable parameter, the reliability is 2. If the failure probability of each part in the list of faulty parts output by the error determination unit 312 does not include a probability, and the market performance for the target error managed by the market performance management unit 315 does not reach a reliable parameter, the reliability will be 1.

[0108] In this embodiment, reliability is determined based on the failure probability of each part in the list of estimated faulty parts (Table 1) output by the error determination unit 312 and the market performance managed by the market performance management unit 315, but the method for determining reliability is not limited to this. For example, it may be calculated using a three-level numerical value based on the quantity of market performance. For example, if the total number of replacements for a combination of "model number" and "error code" is less than 100, the estimation accuracy is 0; if it is 100 or more but less than 500, the estimation accuracy is 1; if it is 500 or more but less than 1000, the estimation accuracy is 2; and if it is 1000 or more, the estimation accuracy is 3. A larger total number of replacements is defined as a higher estimation accuracy, and a larger numerical value is assigned. In this embodiment, reliability is displayed in three levels, but any number of levels may be used.

[0109] Fig. 13 is a diagram showing an example of a repair procedure display screen in Example 3. The repair procedure display unit 319 of the repair point notification server 101 displays a reliability display unit 1301 on a repair procedure display screen 1300 based on the reliability calculated by the reliability determination unit 1201. The repair procedure display screen 1300 in Fig. 13 is an example of a screen in which the reliability display unit 1301 is added to the repair procedure display screen 1000 in Fig. 10.

[0110] According to this embodiment, the reliability of the estimated results is displayed on the repair procedure display screen, allowing the customer engineer to understand the estimated accuracy of the parts and procedures displayed on the repair procedure display screen.

[0111] Example 4 In Example 1, actions that are defined as not existing in the correct answer master, which defines theoretically correct actions, are displayed as "-". If a customer engineer performs the action displayed as "-" and enters it in the feedback, the action score for the action that is not actually existing will fluctuate and the action priority will be adjusted, which will weaken the definition of the correct answer master. Therefore, in this example, we will explain how to handle feedback information when an action defined as not existing in the correct answer master is actually performed. Note that in this example, explanations of parts that are similar to those in Example 1 will be omitted.

[0112] Feedback information for actions defined as not existing in the correct master is accumulated in the feedback management unit 320, as in the first embodiment. In the first embodiment, the priority determination unit 314 performs action priority adjustment processing using feedback information, but this is not performed in the present embodiment. In the present embodiment, the priority determination unit 314 does not perform action priority adjustment processing using feedback information for actions defined as not existing in the correct master, so the action scores of actions defined as not existing in the correct master are not changed. The repair procedure display unit 319 of the repair location notification server 101 does not reflect the action scores of actions defined as not existing in the correct master on the screen provided to the PC 103. Meanwhile, the feedback management unit 320 visualizes and transmits to the correct master management unit 317 the accumulated feedback information indicating that actions defined as not existing in the correct master have been executed. This allows the person developing and adjusting the correct master to utilize this information to reduce the discrepancy between the user and the correct master.

[0113] As described above, according to this embodiment, feedback information of actions defined as not existing in the correct answer master can be prevented from being reflected in the action priority adjustment process and the display screen. On the other hand, it is possible to notify the person in charge of developing and adjusting the correct answer master of feedback information of actions defined as not existing in the correct answer master.

[0114] The disclosure of this embodiment includes the following configuration of an information providing system. (Configuration 1) a management unit for managing error information indicating an error that has occurred in the image processing device and that is collected from the image processing device; providing means for providing a screen listing information on unhandled errors of the designated image processing device; a receiving unit for receiving feedback regarding a response to maintenance performed on the image processing device, The error information managed by the management means includes device information for identifying the image processing device, an error code corresponding to a failure of the image processing device, a date and time of the error occurrence, and response information indicating whether or not a maintenance response has been performed, The management means updates the response information for errors that have been addressed through maintenance that has received feedback from "not addressed" to "addressed," and collectively updates the response information for error codes that are the same as the error code of the error for the same image processing device from "not addressed" to "addressed." (Configuration 2) 2. The information providing system according to configuration 1, wherein the providing means displays information on a plurality of errors with the same error code together in the list. (Configuration 3) The information providing system described in configuration 2 is characterized in that when multiple error information items with the same error code are displayed together in the list, the providing means displays the most recent of the multiple occurrence dates and times as the date and time of the error, and displays the number of errors with the same error code. (Configuration 4) The management means assigns a batch processing flag to the batch-updated error information, An information providing system according to any one of configurations 1 to 3, characterized in that when aggregating the results of the maintenance response, error information to which the batch processing flag has been assigned is not included in the aggregation. (Configuration 5) The information providing system according to any one of configurations 1 to 4, wherein the reception means provides a screen for inputting the details of the maintenance actions taken on the image processing device as feedback, and receives feedback including the details of the actions entered on the screen, an error code indicating the error for which the actions were taken, and device information indicating the image processing device for which the actions were taken. (Configuration 6) The image processing device further includes an estimation unit for performing an estimation process regarding a fault location that is the cause of an error in the image processing device and a necessary measure to eliminate the error, 6. The information processing system according to any one of configurations 1 to 5, wherein the providing means provides an estimation result corresponding to error information selected from the list.

[0115] (Other embodiments) The present invention can also be realized by supplying a program that realizes one or more functions of the above-described embodiments to a system or device via a network or a storage medium, and having one or more processors in the computer of the system or device read and execute the program.The present invention can also be realized by a circuit (e.g., ASIC) that realizes one or more functions.

[0116] Although the preferred embodiments of the present invention have been described above, the present invention is not limited to these embodiments and various modifications and changes are possible within the scope of the gist of the present invention.

Claims

1. a management unit for managing error information indicating an error that has occurred in the image processing device and that is collected from the image processing device; providing means for providing a screen listing information on unhandled errors of the designated image processing device; a receiving unit for receiving feedback regarding a response to maintenance performed on the image processing device, The error information managed by the management means includes device information for identifying the image processing device, an error code corresponding to a failure of the image processing device, a date and time of the error occurrence, and response information indicating whether or not a maintenance response has been performed, The management means updates the response information for errors that have been addressed through maintenance that has received feedback from "not addressed" to "addressed," and collectively updates the response information for error codes that are the same as the error code of the error for the same image processing device from "not addressed" to "addressed."

2. 2. The information providing system according to claim 1, wherein the providing unit displays information on a plurality of errors having the same error code together in the list.

3. The information providing system of claim 2, characterized in that when the providing means displays multiple error information with the same error code together in the list, it displays the most recent of the multiple occurrence dates and times as the date and time of the error, and displays the number of errors with the same error code.

4. The management means assigns a batch processing flag to the batch-updated error information, 2. The information providing system according to claim 1, wherein when the results of the maintenance actions are compiled, the error information to which the collective action flag is assigned is not included in the compilation.

5. The information providing system according to claim 1, characterized in that the reception means provides a screen for inputting the details of the maintenance actions taken on the image processing device as feedback, and receives feedback including the details of the actions entered on the screen, an error code indicating the error for which the actions were taken, and device information indicating the image processing device for which the actions were taken.

6. The image processing device further includes an estimation unit that performs estimation processing relating to a fault location that is the cause of an error in the image processing device and a measure to resolve the error, 2. The information providing system according to claim 1, wherein the providing unit provides an estimation result corresponding to the error information selected from the list.

7. managing error information collected from the image processing device and indicating an error that has occurred in the image processing device; a providing step of providing a screen listing information on unhandled errors of the designated image processing device; a receiving step of receiving feedback regarding a response to maintenance performed on the image processing device; updating the error information based on the feedback; The error information includes device information for identifying the image processing device, an error code corresponding to a failure of the image processing device, the date and time of the error occurrence, and response information indicating whether or not a maintenance response has been performed, The control method for an information providing system is characterized in that the response information for an error that has been addressed by the maintenance that received the feedback is updated from "not addressed" to "addressed," and the response information for an error code that is the same as the error code of the error for the same image processing device is also updated in one go from "not addressed" to "addressed."

Images