Information processing apparatus, control method, and storage medium

Abstract

To improve the function extension of an information processor.SOLUTION: An information processing apparatus that executes inference processing for diagnosis of one or more components included in the information processing apparatus, the information processing apparatus comprising an output unit configured to output sensing data indicating a state of the one or more components included in the information processing apparatus to a storage unit inside the information processing apparatus, the output unit outputs the sensing data to a first storage unit configured to store event data generated based on the sensing data and a second storage unit configured to store data for executing ETL processing, the event data stored in the first storage unit is transmitted to a server for collecting data via a network, and the inference processing is executed using the data stored in the second storage unit and then subjected to the ETL processing.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates to an information processing device, a control method, and a program. [Background technology]

[0002] Conventionally, information processing devices have been managed and the need for maintenance determined by transmitting event information, including fault information that occurs during operation of the device and counter information that indicates the operating status of each component that makes up the device, to an external management server. In addition, the readings and variations of each drive system and sensor system of the device can be sensed, and the sensing information transmitted to the server can be used to estimate the state of the device.

[0003] For example, if an error occurs in a device, sensing data on parts related to that location can be added to information indicating the location of the error, such as an error code, and immediately transmitted. This allows for more accurate and prompt maintenance. Furthermore, even if no malfunction occurs in a specific device, sensing data on consumable parts can be periodically transmitted. The collected sensing data can be used to learn the progress of wear on the consumable parts, thereby generating a consumable part lifespan prediction algorithm. While part wear was previously estimated using a counter indicating the number of times the consumable part was used, combining sensing data allows for more accurate prediction results. Predicting the lifespan of consumable parts allows for the prediction of impending failures and the necessary measures, such as replacing the consumable parts, to be taken. Furthermore, comparing the sensing data trends of other information processing devices managed by the management server can help predict signs of malfunctions.

[0004] Recently, devices have been provided with features that display highly accurate screens showing the status and abnormalities of regularly scheduled consumable parts, enabling service technicians to quickly respond to problems on-site. A prediction algorithm that uses large amounts of sensing data collected on the cloud to learn and verify the accuracy of consumable part lifespan predictions is deployed to the device, and the inference results are displayed on the device's screen. To derive the same inference results on the device as the verification results of the cloud-based consumable part lifespan prediction accuracy, the device must also use sensing data from the same consumable parts for inference processing. When transmitting sensing data within such equipment, a single device must reliably send events simultaneously to each of the intended uses. However, it is inefficient to operate multiple event data collection mechanisms for each intended use on the device.

[0005] In Patent Document 1, the device integrates collection instructions into one collection instruction in response to requests from multiple services. By simply operating one event data collection mechanism, the device can store the same event data for each client in the device's internal storage corresponding to the relevant events. [Prior art documents] [Patent documents]

[0006] [Patent Document 1] Japanese Patent Publication No. 2022-112807 Summary of the Invention [Problem to be solved by the invention]

[0007] The method described in Patent Document 1 only integrates collection instructions and switches event destinations on the server, and is not applicable to collection instructions from within the device. Therefore, it is necessary to use sensing data of consumable parts collected in advance on the cloud to learn the progress of wear on the consumable parts and derive inference results on the device that are identical to those verified for lifespan prediction accuracy on the cloud. To achieve this, the device must also perform inference processing using sensing data from the same consumable parts. Furthermore, if the consistency of data and inference logic is not guaranteed, incorporating a prediction algorithm verified on the cloud into the device requires evaluation and firmware upgrade of the entire device firmware. This has made it difficult to quickly evolve devices in line with advances in prediction algorithms. Therefore, there has traditionally been room for improvement in the functional expansion of devices, i.e., information processing devices.

[0008] The present invention has been made to solve the above-mentioned problems, and has an object to improve the function expansion of information processing devices. [Means for solving the problem]

[0009] An information processing device according to one embodiment of the present invention is an information processing device that executes inference processing for diagnosing one or more components provided in the information processing device, and includes an output means that outputs sensing data indicating the state of one or more components provided in the information processing device to a storage means inside the information processing device, the output means outputs the sensing data to a first storage means that stores event data generated based on the sensing data and a second storage means that stores data for executing ETL processing, the event data stored in the first storage means is transmitted via a network to a server that collects data, and the inference processing is executed using the ETL processed data after being stored in the second storage means. It is characterized by: [Effects of the Invention]

[0010] According to the present invention, it is possible to improve the function expansion of an information processing device. [Brief explanation of the drawings]

[0011] [Figure 1] 1 is a system configuration diagram showing a system according to a first embodiment of the present invention. [Figure 2] 1 is a block diagram showing a configuration of a management server 110 according to a first embodiment of the present invention. [Figure 3] FIG. 2 is a block diagram showing a configuration of a client machine 120 according to the first embodiment of the present invention. [Figure 4] 3 is a block diagram showing a configuration of an information processing controller unit 301 of a client machine 120 according to the first embodiment of the present invention. FIG. [Figure 5] FIG. 2 is a block diagram showing the software configuration of a management server 110 according to the first embodiment of the present invention. [Figure 6] FIG. 2 is a block diagram showing the software configuration of a client machine 120 according to the first embodiment of the present invention. [Figure 7] FIG. 3 is a diagram showing a collection file that indicates collection information according to the first embodiment of the present invention. [Figure 8] FIG. 3 is a diagram showing a dictionary used when converting sensing data into an event according to the first embodiment of the present invention. [Figure 9] FIG. 2 is a diagram showing an example of a configuration file in which a list of components to be subjected to inference processing is written, according to the first embodiment of the present invention. [Figure 10] FIG. 2 is a diagram showing an example of a monitor screen according to the first embodiment of the present invention. [Figure 11] FIG. 10 is a flowchart showing the processing from connection between the management server and the client machine to reflection of the notification setting of the data collection module of the client machine according to the first embodiment of the present invention. [Figure 12] FIG. 4 is a flowchart showing a process from event detection to writing to a transmission buffer according to the first embodiment of the present invention. [Figure 13]FIG. 4 is a flowchart showing a process from event detection to writing to a transmission buffer according to the first embodiment of the present invention. [Figure 14] FIG. 2 is a flowchart showing processing from the start of inference on a device to the completion of inference processing according to the first embodiment of the present invention. [Figure 15] FIG. 2 is a flowchart showing processing from the start of inference on the management server to the completion of the inference processing according to the first embodiment of the present invention. [Figure 16] FIG. 10 is a flowchart showing a process for updating a prediction algorithm on the cloud according to a second embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0012] The following describes embodiments of the present invention with reference to the drawings. Note that the following embodiments do not limit the scope of the present invention, and not all of the combinations of features described in the embodiments are necessarily essential to the solution of the present invention.

[0013] Since the prediction algorithm created in the cloud can be created using data with the same structure as the edge device, the prediction algorithm verified in the cloud can be applied to the edge device as is.By seamlessly linking the cloud and edge device, the present invention makes it possible to evolve devices in a short period of time in line with the evolution of the algorithm, persistently and efficiently, without duplication of evaluation of the prediction algorithm verified once in the cloud.

[0014] <Embodiment 1> 1 is a system configuration diagram showing a system according to a first embodiment of the present invention. The system 10 according to the first embodiment of the present invention is configured by connecting a management server 110, a client machine 120, and a client machine 121 to a network 100. Each of the management server 110, the client machine 120, and the client machine 121 is an information processing device.

[0015] Each of client device 120 and client device 121 has a function for notifying management server 110 of events occurring within client device 120 in the form of historical events. Management server 110 has a function for saving events notified from multiple client devices, such as client devices 120 and 121, in storage within the management server. The information accumulated in the storage is used for analyzing operation monitoring information, etc.

[0016] The management server 110 is realized by a general information processing device such as a computer that can have data storage, information processing calculations, and network communication functionality, or a cloud service with equivalent functions. The client device 120 will be described as an example of a multifunction device that can perform multiple functions, such as copying and faxing. The client device 120 has a function to notify the management server 110 of the execution history of these functions, as well as the history of transitions to and returns from power-saving states, and the history of transitions to and returns from abnormal states such as error occurrences.

[0017] 2 is a block diagram showing the configuration of the management server 110 according to the first embodiment of the present invention. The management server 110 is realized by an information processing device such as a general computer. The management server 110 includes a controller unit 200, an operation unit 220, and a display unit 230.

[0018] The controller unit 200 includes a CPU (Central Processing Unit) 201. The CPU 201 starts up an OS (Operating System) by a boot program stored in a ROM (Read Only Memory) 202.

[0019] A CPU 201 runs application programs stored in a hard disk drive (HDD) 204 on this OS, thereby executing various processes. A random access memory (RAM) 202 is used as a working area for the CPU 201. The HDD 204 stores the application programs and data such as settings and history.

[0020] The CPU 201 is connected to a ROM 202, a RAM 203, an operation unit I / F 205, a display unit I / F 206, and a network 207 via a system bus 208. I / F is an abbreviation for interface.

[0021] The operation unit I / F 205 is an interface with an operation unit 209 consisting of a mouse, keyboard, etc., and sends information input by a user via the operation unit 209 to the CPU 201. The display unit I / F 206 outputs image data to be displayed on a display unit 210 consisting of a display, etc., to the display unit 210. In addition, the network 207 is connected to the network 100, and inputs and outputs information to and from each device on the network 100 via the network 100.

[0022] 3 is a block diagram showing the configuration of the client device 120 according to the first embodiment of the present invention. The client device 121 is similar to the client device 120, so a detailed description of the configuration of the client device 121 will be omitted. The client device 120 includes an information processing controller unit 301, a printer controller unit 302, a scanner controller unit 303, a printer 304, a scanner 305, and an operation unit 306. In this embodiment, the client device 120 is a multifunction device.

[0023] The information processing controller unit 301 is a controller that controls information processing related to the operation of the client device 120, and is connected to an operation unit 306. The information processing controller unit 301 is further connected to a printer controller unit 302 that controls a printer 304, which is an image output device, and a scanner controller unit 303 that controls a scanner 305, which is an image input device.

[0024] FIG. 4 is a block diagram showing the configuration of the information processing controller unit 301 shown in FIG. 3. The information processing controller unit 301 has a CPU 401, a ROM 402, a RAM 403, and an HDD 404. The CPU 401 starts the OS using a boot program stored in the ROM 402. The CPU 401 runs application programs stored in the HDD 404 on this OS, thereby performing various processes. The RAM 403 is used as a work area for the CPU 401. The RAM 403 also provides a work area for the CPU 401, as well as an image memory area for temporarily storing image data. The HDD 404 stores the application programs, image data, various setting values, and history.

[0025] The information processing controller unit 301 has a network 405, an operation unit I / F 406, an image processing unit 407, a device controller I / F 408, a power supply control unit 409, and a system bus 410. The CPU 401 is connected to the operation unit I / F 406, the device controller I / F 408, the network 405, the image processing unit 407, and the power supply control unit 409, along with the ROM 402 and RAM 403, via the system bus 410.

[0026] The operation unit I / F 406 is an interface with the operation unit 306 having a touch panel, and outputs image data to be displayed on the operation unit 306 to the operation unit 306. The operation unit I / F 406 also sends information input by a user via the operation unit 306 to the CPU 401. The device controller I / F 408 is connected to the scanner controller unit 302 and the printer controller unit 303. The device controller I / F 408 performs synchronous / asynchronous conversion of image data. The network 405 is connected to the network 100, and inputs and outputs information to and from each device on the network 100 via the network 100.

[0027] The image processing unit 407 performs processes such as image processing for output to the printer 304, image processing for input from the scanner 305, image rotation, image compression, resolution conversion, color space conversion, and gradation conversion. The power management unit 409 controls the power supply of the entire client device 120. In addition to controlling power on / off, the power management unit 409 also controls transition to a power-saving state other than the normal power supply state and return from the power-saving state to the normal power supply state.

[0028] Fig. 5 is a block diagram showing the software configuration of the management server 110 according to the first embodiment of the present invention. Fig. 6 is a block diagram showing the software configuration of the client machine 120 according to the first embodiment of the present invention.

[0029] The client device 120 has the components shown in Fig. 6. The components shown in Fig. 6 are stored in any one of the storage means, RAM 403, HDD 404, and ROM 402, and are executed by the CPU 401. Software that realizes various functions such as scanning, printing, and using a network or memory storage runs on the client device 120.

[0030] The user interface 501 has the function of displaying a screen for the user to operate on the operation unit 306 and transmitting the user's operation to software. There are multiple function applications 502 in the client device 120 for each function such as copying, printing, and sending email. The function applications 502 operate the application functions of the client device 120, which is a multifunction device, in response to a user instruction via the operation unit 306 or data reception via the network 405, etc.

[0031] A job control unit 503 receives instructions from a function application 502 and controls the printer control unit 302 and scanner control unit 303 to perform scanning and printing. A power control unit 504 controls the power management unit 409 in conjunction with the state of the software in the client device 120, and manages the transition between the normal power supply state and the power saving state. An error control unit 505 receives notifications of abnormal states that occur mainly in the job control unit 503, printer control unit 302, scanner control unit 303, etc., and performs control such as stopping the entire client device 120 and issuing degraded operation instructions.

[0032] The history and setting storage unit 506 manages non-volatile information within the client device 120. The history and setting storage unit 506 stores settings necessary for the functions of the client device 120 as a multifunction device and for controlling jobs, and also summarizes and saves user operation history, job execution results, and error occurrences. The history and setting storage unit 506 also saves log information that is saved for analysis and debugging purposes when a problem occurs within the client device 120. The entity of the non-volatile data managed by the history and setting storage unit 506 is stored in, for example, the HDD 404.

[0033] The counter management unit 507 manages counts of the number of scanned and printed pages generated within the client device 120, counts measuring the degree of wear such as the number of sheets passed for each consumable part, and part lifespan information calculated from these. The substance of the non-volatile data managed by the counter management unit 507 is stored in, for example, the HDD 404.

[0034] The sensing unit 508 collects sensing data obtained by measuring the operating states of the components that make up the units from the information processing controller unit 301, printer controller unit 302, and scanner controller unit 303. The sensing unit 508 temporarily stores the collected sensing data in the sensing data storage unit 511. Examples of components include an optical component unit, a drive system component unit, a fixing unit, a paper feed unit, and a transport unit. The sensing data is measured for each unit component and for each component component.

[0035] The event collection unit 510 monitors state transitions occurring in modules that spontaneously issue events within the client device 120, normalizes the events, and stores them in a message buffer 520 to send them to the management server 110. Examples of modules that spontaneously issue events include a user interface 501, a function application 502, a job control unit 503, a power control unit 504, an error control unit 505, and a history / settings storage unit 506. The message buffer 520 includes message buffers 520a and 520b. The message buffer 520 is located on the HDD 404, and events normalized by the event collection unit 510 are stored in a non-volatile area. The message buffer 520a or the means for storing data in the message buffer 520a is an example of a first storage means for storing data to be sent to an external device, such as the management server 110. The message buffer 520b or the means for storing data in the message buffer 520b is an example of a second storage means for storing data to be used for internal processing, such as an ETL processing unit 554 or an inference processing unit 555.

[0036] The event collection unit 510 also requests the timer notification unit 509 to fire a timer after a specified time has elapsed. After receiving a notification from the timer notification unit 509, the event collection unit 510 collects an event to be periodically transmitted, triggered by the timer firing. The event collection unit 510 collects counters and configuration information managed by the counter management unit 507, configuration information management unit 508, etc. After acquiring this information, it is normalized and saved in the message buffer 520, just as in the case of event-driven functioning.

[0037] Event normalization uses a general-purpose format such as JSON. JSON is an abbreviation for JavaScript Object Notation. According to normalization, in addition to basic information such as the event name, occurrence time, and serial number of the information processing device, various additional information is added depending on the type of event. This added information is collected by the event collection unit 510 from the status of each module in the client device 120 and content stored in a non-volatile memory. Examples of modules in the client device 120 include the counter management unit 507 and the configuration information management unit 508 in addition to the above-mentioned modules that issue events autonomously.

[0038] The data collection module 540 reads the data collected from the client device 120 and stored in the message buffer 520 as described above, and sends it to the management server 110. There is one data collection module 540 for each management server 110 to which the client device 120 is connected. Therefore, if the client device 120 is connected to multiple management servers 110, the client device 120 has multiple data collection modules 540.

[0039] An event sending unit 530 in a data collection module 540 receives the issuance of an event by detecting writing to a dedicated message buffer 520 provided for each data collection module 540. In response to this, the data collection module 540 reads information from the message buffer 520 and sends the event to the management server 110 via a network communication unit 532. The network communication unit 532 communicates using the Network 405.

[0040] Data collection module 560 reads the data collected from within client device 120 and stored in message buffer 520 as described above, and sends it to a module within client device 120 .

[0041] The calculation drive unit 552 in the data collection module 560 receives the issuance of an event by detecting writing to a dedicated message buffer 520 provided for each data collection module 560. In response to this, the data collection module 560 reads information from the message buffer 520 and sends the event to the data collection module 560 via the calculation drive unit 552.

[0042] The data collection module 560 can also receive event notification settings from within the data collection module 560. A notification setting acquisition unit 553 within the data collection module 560 has a function of acquiring the notification settings read from the configuration information management unit 550 via the configuration information acquisition unit 551.

[0043] The calculation driver 552 sends an event to the ETL processor 554. ETL processing refers to the process of extracting, converting, and loading data, and is a process of cleaning and organizing raw values ​​of sensing data from each component and compiling them into storage called a data warehouse. The ETL processing in this embodiment is executed by the inference processor 555 to diagnose the lifespan, status, and presence or absence of abnormalities of the information processing device or each component of the information processing device. The ETL processing may also be prepared for data analysis and machine learning (ML) by the management server 110.

[0044] The inference processing unit 555 reads the data processed by the ETL processing unit 554 and executes inference processing to diagnose the lifespan, status, and presence or absence of abnormalities of the information processing device or each component of the information processing device. The ETL processing unit 554 and the inference processing unit 555 may be configured to process components in parallel, or to process components in series in order with priority assigned to each component. The inference results obtained by the inference processing unit 555 are stored in the inference result storage unit 556 and, if necessary, displayed on the screen of the operation unit 306, thereby providing the user with information as the diagnosis result for each component. The inference results obtained by the inference processing unit 555 may also be stored in the message buffer 520a and transmitted to the management server 110.

[0045] When the inference process for each component is completed, the inference result storage unit 556 outputs the inference result, and the monitor UI unit 557 receives the inference result for each component, whereby the inference result is displayed on the operation unit 306.

[0046] Next, the management server 110 will be described with reference to Fig. 5. The data receiving unit 572 periodically receives sensing data events of consumable parts from the data collection module 540 and stores the events in the sensing data storage unit 573. The data receiving unit 572 of the management server 110 is connected to the network communication unit 532 of Fig. 6. The data collection request unit 571 of the management server 110 is connected to the network communication unit 532 of Fig. 6.

[0047] The sensing data storage unit 573 holds sensing data from multiple information processing devices. The part life analysis unit 576 learns the progress of wear of consumable parts from the sensing data, etc., in the sensing data storage unit 573. The algorithm management unit 577 generates / manages life prediction algorithms for consumable parts.

[0048] Conventionally, part wear was estimated using a counter indicating the number of times a consumable part was used. The part life analysis unit 576 can calculate more accurate predictions by combining sensing values, or sensing data, to estimate part wear. For example, the drum unit's lifespan was previously estimated solely based on the life value of the part's counter information. The part life analysis unit 576 uses sensing data events that include not only the drum color identification but also the drum film thickness detection current result, drum rotation speed, rotation time, and engine process speed. This allows the part life analysis unit 576 to infer the occurrence of drum scratches, thereby adding the ability to detect random failures. Furthermore, conventionally, data equivalent to condition information was not available for troubleshooting issues such as reader contamination. The part life analysis unit 576 can identify problem areas by inferring using sensing data events such as the reading surface, black, RGB reader shading values, and CMOS sensor temperature.

[0049] The calculation driver 574 periodically sends events from the sensing data storage unit 573 to the ETL processing unit 554 in the management server 110. The inference processing unit 555 reads data processed by the ETL processing unit 554 and executes inference processing. The ETL processing unit 554 and the inference processing unit 555 are programs that execute the same processing as the data collection module 560. That is, in this embodiment, the same prediction algorithm that has been verified for the accuracy of life prediction of consumable parts on the cloud, i.e., on the management server 100, is deployed to the device, i.e., the client machine 120. This configuration ensures that the estimation result storage unit 575, which stores the verification results of the accuracy of life prediction of consumable parts on the cloud, and the estimation result storage unit 556 in the data collection module 560 hold the same inference results.

[0050] Furthermore, the accuracy comparison unit 578 compares the accuracy of the conventional prediction algorithm with the accuracy of the new prediction algorithm obtained through repeated learning. If the accuracy of the new prediction algorithm obtained through repeated learning exceeds the accuracy of the conventional prediction algorithm, the prediction algorithm is updated and the same algorithm is deployed to the device.

[0051] The client device 120 can also receive event notification settings from the management server 100. A notification setting acquisition unit 531 in the data collection module 540 has a function of acquiring notification settings from the management server 110 via a network communication unit 532.

[0052] The notification settings acquired by the notification setting acquisition units 531 and 553 of the data collection modules 540 and 560 are passed to the notification setting integration unit 522, which integrates them into one notification setting and stores it in the notification setting storage unit 521.

[0053] The notification setting storage unit 521 is stored in the form of a file on the HDD 404. The information stored in the notification setting storage unit 521 indicates which events are to be sent from among the events that occur in the target client device 120 and can be turned into events.

[0054] The event collection unit 510 receives the contents stored in the notification setting storage unit 521 and operates to output and store only events that are instructed to be notified in the message buffer 520. The notification setting storage unit 521 also records information about which data collection module's message buffer the issued event should be stored in. Message buffer 520a is provided for data collection module 540, and message buffer 520b is provided for data collection module 560. When outputting an event to be written to the message buffer 520, the event collection unit 510 determines whether to write the event to message buffer 520a or 520b by referring to the information about which data collection module's message buffer the event should be stored in. This allocation prevents events requested by other data collection modules from being written to the message buffer 520 of each data collection module. This prevents unrequested data from being sent to each data collection module.

[0055] Next, with reference to Table 1, which is a table showing the relationship between notification settings and events, notification settings set in notification setting storage unit 521 will be described using examples. Table 1 shows examples of events that actually occur on client device 120.

[0056] [Table 1]

[0057] In Table 1, the items listed in the Event column are units (hereinafter referred to as "events") that are normalized by giving names to state transitions that occur within the client device 120. These are the units that the event collection unit 510 writes to the message buffer 520 and that are sent to the management server 110. For example, an event with JobStarted in the Event column is an event that indicates that a job such as copying or printing has started to be executed. Also, an event with ErrorOccurred in the Event column is an event that indicates that some kind of abnormal state has occurred within the client device 120.

[0058] In Table 1, the entries in the Collection column are units that group multiple events based on the semantic meaning of their actions (hereinafter referred to as "collections"). Activation settings are made for each collection in the notification setting storage unit 521. In the example of Table 1, if an Alarm collection is specified, the ErrorOccurred and AlarmOccurred events will be sent.

[0059] Additionally, events marked with a circle in the periodic transmission column are snapshot events that are sent periodically by activation, a timer, etc. For example, when specifying in the notification setting storage unit 521 that a periodic transmission collection is enabled, the transmission interval is set in addition to specifying the collection.

[0060] When a Basic collection is specified, a BasicInfoSnapshotted event, whose attributes include basic information such as model name, installation location, and firmware version, will be sent periodically at the specified interval. Similarly, when a Counter collection is specified, CounterSnapshotted (a list of counter information for billing) will be sent periodically. Furthermore, when a PartsCounter collection is specified, PartsCounterSnapshotted (a list of counter information for the wear level of parts) will be sent periodically. Furthermore, when a ConditionData collection is specified, ConditionDataNotified, i.e., the sensing data of each part (characteristic values ​​for calculating the degree of wear and deterioration over time), will be sent collectively at regular intervals.

[0061] FIG. 7 is a diagram showing a collection file that instructs collection information according to the first embodiment of the present invention. A collection instruction is also called a collection request. FIG. 7(A) is a diagram showing an example of a collection file 600 that is sent in step S1005 of flowchart 1000 (described later) and accepted in step S1012 of flowchart 1010. Here, a sample in JSON format is shown, but any format that can be normalized in text, such as XML or CSV, can be used. XML is an abbreviation for Extensible Markup Language. CSV is an abbreviation for Comma Separated Values.

[0062] The sample in Figure 7(A) shows three types of event sending settings. First, in block 601, events belonging to the Power and Alarm collections are set in real time. Real time means that the event is sent immediately when it occurs. With this setting, when an error or other problem occurs within the client device 120, it is determined that an error event needs to be sent, and the event is issued and sent.

[0063] Blocks 602 and 603 are settings for periodic event transmission. In block 602, the Basic collection is set to up / cron. "up" means to send at startup, and "cron" means to send periodically. In this example, the cron notation specifies a periodic transmission cycle of 6 hours. With this setting, events belonging to the Basic collection will be sent immediately after startup and every 6 hours thereafter.

[0064] In block 603, the Counter and PartsCounter collections are configured in cron. The cycle is set to 12 hours. This setting means that events belonging to the Counter and PartsCounter collections will be sent 12 hours after startup and every 12 hours thereafter.

[0065] In block 604, the collection of ConditionData is set by cron. The cycle is set to 24 hours. This setting means that events belonging to ConditionData will be sent 24 hours after startup and thereafter at 24-hour cycles. Events sent with this collection file instruction are written to message buffer 502a and then sent to management server 110 via event sending unit 530 in data collection module 540.

[0066] FIG. 7B is a diagram showing an example of a collection file 610 sent in step S1025 of a flowchart 1020 described below and received in step S1012 of a flowchart 1010.

[0067] In block 611, the collections "MediaSettings", "Condition_DrumUnit", and "Condition_PaperFeed" are set up / cron. Furthermore, in block 611, the collections "Condition_ADF" and "Condition_Reader" are set up / cron. The cycle is set to 24 hours. With this setting, events belonging to the collections included in block 611 will be sent immediately after startup and then every 24 hours thereafter. Events sent with this collection file instruction are written to message buffer 502b and then sent to calculation drive unit 552 in data collection module 560.

[0068] Next, a method will be described in which the notification setting integration unit 522 integrates the notification settings of a plurality of data collection modules, and the event collection unit 510 distributes events to the message buffers 520 for the respective data collection modules when outputting the events.

[0069] As explained above, notification settings such as those indicated in the collection file 600 are sent from the management server 110 or the data collection module. They are then received by the notification setting acquisition unit 531 of the data collection module 540 or the notification setting acquisition unit 553 of the data collection module 560 and passed to the notification setting integration unit 522.

[0070] When there are multiple clients, such as the data collection module 540, multiple collections are passed to the notification setting integration unit 522, integrated, and stored in the notification setting holding unit 521. This integration method will be described below.

[0071] Events that occur in real time are simply integrated by taking their OR. In other words, if they exist in any of the multiple inputs, they will be adopted. For periodically sent events, different cycles may be specified by multiple data collection modules. Requests for periodically sent events with different cycles are realized by rounding them up to a single cycle. Events are saved by taking the OR of the contents specified by each data collection module, and the specified data collection module is registered as the write destination.

[0072] When periodic transmission events are registered in a table through integration, one cycle is selected and saved. The write destination is also registered. If the collection definition name is the same, the cycle specified by the data collection module with the highest priority is used.

[0073] The state integrated in this way is stored in notification setting storage unit 521, and is referenced at step S1106 of flowchart 1100 and step S1113 of flowchart 1110, which will be described later. The event is written to message buffers 520a, 520b of the relevant data collection modules 540, 560 that are determined to need writing, and then the data collection modules 540, 560 use the event according to their respective purposes.

[0074] By implementing this in this way, the operation of the event collection unit 510 is minimized and collection operations are unified, and event data other than that requested to be collected is controlled so that it is not written to the corresponding message buffer.

[0075] 8 is a diagram showing a dictionary used when converting into a sensing data event according to the first embodiment of the present invention. Dictionary 700 is an example of a dictionary (data schema) referenced in step S1115 and step S1119 of flowchart 1110, which will be described later. Here, a sample in JSON format is shown, but any format that can be normalized in text, such as XML or CSV, can be used.

[0076] The sample in Figure 8 describes schemas for two types of sensing data values ​​for the drum. First, block 701 describes the trigger that receives the PrintJobEnd sensing data event. The dictionary definitions are divided into normal events and events such as errors and jams, and the conversion target for the characteristic value differs depending on the event.

[0077] Block 702 describes the part name such as drum, paper feed, reader, ADF, etc. In Fig. 8, an example where the part is a drum is described in block 702. The dictionary definitions are divided by part, and the conversion target for characteristic values ​​differs depending on the event.

[0078] Block 703 describes the name of the data pack for each part. A data pack is a collection of data, and in the case of a drum, the data packs for film thickness detection characteristics and job characteristics are different. Specific examples of characteristic values ​​in a data pack are explained in block 704.

[0079] Block 704 describes the characteristic values ​​for each data pack in key-value format. Block 704 in FIG. 8 shows the characteristic values ​​of a drum job characteristic data pack as an example. Within this job characteristic data pack, the process speed (processSpeed) is schema-defined as being converted into a numeric value type (numeric). In addition, block 704 in FIG. 8 describes the characteristic value of the drum rotation time (drumRotationTime).

[0080] For example, the data pack for film thickness detection characteristics contains the characteristic value of the film thickness detection current value, although this is not shown in Figure 8. In this way, the dictionary definitions are divided by data pack, and the conversion target for the characteristic value differs depending on the event.

[0081] 9 is a diagram showing an example of a configuration file in which a list of components to be subjected to inference processing is described, according to the first embodiment of the present invention. The configuration file 800 is an example of a configuration file referenced in step S1022 of a flowchart 1020, which will be described later. The configuration file 800 is managed by the configuration information management unit 550, and is read by the configuration information acquisition unit 551. In this embodiment, the information in the configuration file 800 managed by the configuration information management unit 550 can be rewritten by a firmware update or the like.

[0082] The configuration file 800 contains a list of components to be inferred and determines the inferred processing logic. A sample in JSON format is shown here, but any format that can be normalized as text, such as XML or CSV, can be used.

[0083] 9, two types of inference processing information, one for the drum and one for the paper feeder, are described. First, in block 801, startTime specifies the start time of the calculation driver 552. When this time arrives, the ETL processor 554 and inference processor 555 will operate.

[0084] In block 802, part names such as drum, paper feed, reader, ADF, etc. are described in targetPartsName. In FIG.

[0085] Block 803 describes the file name for each part that serves as an interface between estimation result storage unit 556 and monitor UI unit 557 and that monitor UI unit 557 references.

[0086] Screen identification information is written as DisplayCategory in block 804. Block 804 indicates where the inference information for the part should be output on the monitor screen, either for part life 902 or for troubleshooting 903 on screen 900 in Fig. 10(A) described below.

[0087] Block 805 indicates a message ID for identifying the resource text to be displayed on monitor UI unit 557. Using this message ID, monitor UI unit 557 displays the localized language of each component on the monitor UI. Block 805 is referenced when displaying component name 906 in FIG. 10(A), which will be described later.

[0088] Block 806 describes a life type that can distinguish between high-precision life and conventional life. If all parts are replaced with high-precision life, this configuration information becomes unnecessary. Block 806 is referenced when displaying life type 907 in Figure 10(A), which will be described later.

[0089] A threshold indicating a threshold for life prediction is defined in block 807. Exceeding this threshold means "immediate replacement of the part." Block 807 is referenced when drawing a graph 910 in FIG. 10(B), which will be described later.

[0090] Blocks 808 and 809 are the ranges of the life of the target part. Block 808 is the maximum value of the life of the target part, and block 809 is the minimum value of the life of the target part. The range of life differs for each part, and is referenced when drawing a graph 910 in Figure 10(B) described below.

[0091] In block 810, part names such as drum, paper feed, reader, ADF, etc. are written in targetPartsName. In Fig. 9, an example of a drum is written in block 810. The configuration file information for paper feed is also the same as the contents of blocks 801 to 809, so a description will be omitted.

[0092] 10 is a diagram showing an example of a monitor screen according to the first embodiment of the present invention. Screen 900 is an example of a screen for monitor display generated in step S1211 of flowchart 1200, which will be described later. Monitor UI unit 557 displays screen 900 on operation unit 306 using the inference results for each component.

[0093] Screens 900 in Figures 10(A) and 10(B) are service mode screens. The monitor UI unit 557 first displays screen 900 in Figure 10(A). When button 909 on screen 900 in Figure 10(A) is pressed, the monitor UI unit 557 transitions the display screen to screen 900 in Figure 10(B).

[0094] Screen 900 displays tabs for dash mode 901, part lifespan 902, troubleshooting 903, and history 904. Figure 10(A) shows an example in which information about part lifespan is displayed when part lifespan 902 is selected.

[0095] When part life 902 is selected, screen 900 displays list 905. In list 905, a list of part names for which condition prediction is to be performed is displayed in display field 906. In list 905, information distinguishing whether high-precision life or conventional life is being displayed is displayed in display field 907. In list 905, the current life value is displayed in display field 908. Display field 908 displays the value calculated / converted to life by the algorithm. For parts not applicable to the algorithm, the conventional raw life is displayed as is.

[0096] Additionally, the list 905 displays a button 909. The button 909 is a button for instructing the display of detailed life history of each part. When the monitor UI unit 557 receives a press of the button 909, it displays a graph 910 (screen 900 in FIG. 10(B)) for each part, and visualizes the transition of life information over time.

[0097] 10(B), the vertical axis 911 is displayed in percentage, and the horizontal axis 912 is displayed in dates. Also, in the graph 910, the display period of the horizontal axis 912 is shown as every two days, but the screen may be configured to allow selection of every week, every month, etc.

[0098] The display area 913 indicates the date and time of the last update of the graph 910. The display area 913 is provided so that when there is no plot in the graph display, it can be determined whether the graph is not displayed because the inference was not run due to the power being turned off or for some other reason.

[0099] Line graph 914 is a line graph that shows the transition of the actual life value. Graph 910, for example, serves as an indicator, displaying the deterioration state of the part by changing the display color of line graph 914 in four stages, with the threshold value for each of these four stages being different for each part. Threshold 915 is a life threshold, and in this example, when it exceeds 100%, the indicator turns red, indicating deterioration state 4, meaning "immediate replacement of part." Button 916 is a button for closing graph 910, and monitor UI unit 557 transitions to screen 905 when button 916 is pressed.

[0100] 10(A) and 10(B), not all of the screen configurations described in this embodiment are necessarily essential to the solution of the invention, and therefore the invention is not limited to these.

[0101] 11 is a diagram showing a flowchart of processing from connection between the management server and the client machine to reflection of notification settings of the data collection module of the client machine according to the first embodiment of the present invention. In this embodiment, the processing in FIG. 11 is realized by CPU 401 executing a program stored in any one of storage means, RAM 403, HDD 404, and ROM 402.

[0102] The update of the collection file will be explained with reference to Figure 11. The data collected on the management server 110 according to the data flow in the flowchart of Figure 11 is used by various services and applications built on the management server 110, and these services are contracted for on a per-client device 120 basis. The data required to be sent from the client device 120 may differ depending on the contracted service, and therefore the content to be recorded in the collection will differ depending on the contracted service. For example, if you want to monitor macro-level operating conditions such as the operating status on a dashboard, you can set up the Counter and Alarm collections in Table 1. Other examples include setting up Information for an automatic delivery service for consumables, and setting up Diagnosis for an operation monitoring and maintenance service.

[0103] 11 shows the connection flow between the application of the management server 110 and the client device 120. Flowchart 1010 shows the operation flow of the event sending unit 530 of the data collection module 540 in the client device 120 at that time. Flowchart 1020 shows the operation flow of the notification setting acquisition unit 553 of the data collection module 560 in the client device 120 at that time.

[0104] First, in step S1001, the application program of the management server 110 registers information about the client device that will be connected, along with the device serial number, customer information, etc. Next, in step S1002, the management server 110 determines the services to be used based on the details of the customer's contract. Based on this, the management server 110 determines the contents of the collection to be placed on the client device 120 in step S1003.

[0105] On the other hand, in step S1011, the client device 120 performs an operation to connect to the management server 110. Specifically, this involves performing network settings and entering the address of the management server 110 to perform communication via the network 100, and then communicating with the application program of the management server 110. As a result, in step S1004, the management server 110 confirms the connection of the client device 120, and thereafter data is exchanged between the client and the server.

[0106] Next, in step S1005, the management server 110 sends the collection determined in step S1003 to the client device 120. The client device 120 receives this in step S1012. Next, in step S1013, the client device 120 determines whether the collection received in step S1012 has been changed from the collection it owns, and if so, proceeds to step S1014. In step S1014, the client device 120 overwrites the contents stored in the notification setting storage unit 521 with the collection received in S1012.

[0107] This means that the client device 120 has received the contents of the event transmission instructed by the management server 110. After that, the client device 120 waits for a certain period of time in step S1015, and then returns to step S1012 to obtain the latest collection and, if necessary, reflect it in the notification setting storage unit 521.

[0108] On the other hand, when the data collection module 560 confirms device startup in step S1021, it references in S1022 the configuration file 800 managed by the configuration information management unit 550 and read by the configuration information acquisition unit 551. In S1023, the data collection module 560 references targetPartsName 802, 810 to acquire a list of parts to be inferred, and determines the parts to be inferred. In S1024, the data collection module 560 determines the contents of the collection to be placed on the client device 120. In step S1025, the data collection module 560 sends the collection determined in step S1024 via the notification setting acquisition unit 553, and rewrites the contents stored in the notification setting storage unit 521.

[0109] On the management server 110 side, if the content of the registered service changes due to a change in the customer's contract in step S1006, the collection is changed to the corresponding collection in step S1007. Then, in step S1005, the management server 110 communicates with the client device 120 and performs an operation to reflect the latest collection in the client device 120.

[0110] According to this embodiment, it is possible to change the notification settings of the client device 120 in accordance with the service content subscribed to by the customer in this way. Furthermore, it is also possible to change the notification settings in accordance with the collection instructions of the data collection module 560 in the device. After the notification settings are reflected, each time a flow such as that shown in FIG. 11 is executed in the client device 120, a status change is notified to the data collection module in the form of an event. The notification settings are reflected even when the collection instructions of the data collection module 560 in the device are rewritten due to a firmware update or the like.

[0111] 12 and 13 are diagrams showing a flowchart of processing from event detection to writing to a transmission buffer according to the first embodiment of the present invention. Figures 12 and 13 are flowcharts showing the flow from when various events occur within the client machine 120 to when data is written to the message buffer 520 of each data collection module in order to send the event to the management server 110. In this embodiment, the processing in Figures 12 and 13 is realized by the CPU 401 executing a program stored in any one of the storage means, RAM 403, HDD 404, and ROM 402.

[0112] 12, the operation of a periodic event will be described using a counter data acquisition event as an example. In the case of a periodic event, in step S1101, event collection unit 510 first determines whether or not there is a request for periodic collection of a parts counter snapshot event in notification setting storage unit 521. If event collection unit 510 determines that there is no request for periodic collection of a parts counter snapshot event in notification setting storage unit 521, it terminates the processing of flowchart 1100. If event collection unit 510 determines that there is a request for periodic collection of a parts counter snapshot event in notification setting storage unit 521, it executes the processing of step S1102 and sets a timer for the specified period.

[0113] The event collection unit 510 detects the firing of the timer in step S1103, acquires the current time in step S1104, and collects the target counter values ​​and normalizes them together with the time information into a format such as JSON in step S1105.

[0114] After that, in the processing from step S1106, the event collection unit 510 performs the following processing for all data collection modules that are currently issuing the event data collection instruction. In step S1107, the event collection unit 510 determines whether writing to the message buffer 520 of each data collection module is necessary, based on the information stored in the notification setting storage unit 521. If the event collection unit 510 determines that writing is necessary, the process of step S1108 is executed. If the event collection unit 510 determines that writing is not necessary, the process of step S1108 is not executed. In step S1108, the event collection unit 510 records the data in the corresponding message buffer 520.

[0115] After that, each data collection module reads the data written in step S1108. After that, in step S1109, the event collection unit 510 sets the timer for the next firing time.

[0116] Next, with reference to flowchart 1110 in Fig. 13, a real-time event will be described using a sensing data occurrence event as an example. In step S1111, when the event collection unit 510 detects the occurrence of sensing data, it checks whether or not there is a setting for notifying a sensing data event in the notification settings stored in the notification setting storage unit 521, and ends the processing if there is not. If the event collection unit 510 determines that there is a setting for notifying a sensing data event in the notification settings stored in the notification setting storage unit 521, the processing of step S1112 is executed. In step S1112, the event collection unit 510 acquires the current time.

[0117] After that, in the process from step S1113, the event collection unit 510 performs the subsequent allocation process for all data collection modules that are currently executing the event data collection instruction.

[0118] In step S1114, the event collection unit 510 determines whether or not writing to the message buffer 520a of the data collection module 540, which is a client of the management server 110, is necessary, based on the information stored in the notification setting storage unit 521. If the event collection unit 510 determines that writing is necessary, the process proceeds to step S1115. If the event collection unit 510 determines that writing is not necessary, the process proceeds to step S1118.

[0119] In step S1115, the event collection unit 510 converts all components and all characteristic values ​​into sensing data events using the dictionary 700. In step S1116, the event collection unit 510 normalizes the sensing data when outputting it. In step S1117, the event collection unit 510 records the data in the corresponding message buffer 520a.

[0120] Thereafter, in step S1118, the event collection unit 510 determines whether writing to the message buffer 520b of another data collection module 560 is necessary, based on the information stored in the notification setting storage unit 521. If the event collection unit 510 determines that writing is necessary, the process proceeds to step S1119. If the event collection unit 510 determines that writing is not necessary, the process returns to step S1113.

[0121] In step S1119, the event collection unit 510 converts the sensing data into an event using the dictionary 700. In step S1120, the event collection unit 510 normalizes the sensing data when outputting it. In step S1121, the event collection unit 510 records the data in the corresponding message buffer 520b.

[0122] After that, in response to the writing in step S1121, each data collection module executes an operation to read the data.

[0123] 14 is a diagram showing a flowchart of processing from the start of inference on a device to the completion of inference processing according to the first embodiment of the present invention. In this embodiment, the processing in FIG. 14 is realized by the CPU 401 executing a program stored in any one of the storage means, RAM 403, HDD 404, and ROM 402.

[0124] 14, the processing from the start of the inference processing to the completion of the inference processing in the data collection module 560 of the client device 120 will be described. In step S1201, the configuration information acquisition unit 551 of the data collection module 560 determines whether or not an instruction to periodically collect sensing data events has been issued, based on the configuration file 800. If the configuration information acquisition unit 551 determines that an instruction to periodically collect sensing data events has been issued, the processing of step S1202 is executed. If the configuration information acquisition unit 551 determines that an instruction to periodically collect sensing data events has not been issued, the processing of flowchart 1200 ends.

[0125] In step S1202, the data collection module 560 sets the start time timer of the calculation driving unit 552 in accordance with startTime 801. In step S1203, the data collection module 560 detects the firing of the timer. In step S1204, the data collection module 560 starts the calculation driving unit 552. In step S1205, the calculation driving unit 550 reads out event information normalized in a format such as JSON from the target message buffer 520b.

[0126] Thereafter, in the processing from step S1206, the data collection module 560 executes ETL processing and inference processing for all parts based on the information in the configuration file 800. In step S1207, the data collection module 560 determines whether the part should be calculated by executing an inference algorithm and displaying a value converted to life, or whether the part does not require inference processing, which simply displays the conventional raw life. If the data collection module 560 determines that inference processing is not required, the process returns to step S1206. If the data collection module 560 determines that inference processing is required, the process of step S1208 is executed.

[0127] In step S1208, the ETL processing unit 554 executes ETL processing for the target component. In step S1209, the inference processing unit 555 reads the data processed by the ETL processing unit 554 and executes inference processing. Note that the ETL processing unit 554 and the inference processing unit 555 may be configured to process components in parallel, or to assign priorities to components and process them in serial order. Therefore, the present invention is not limited to this.

[0128] When the inference process for each component is completed, the inference result storage unit 556 outputs the inference result in step S1210. Then, the monitor UI unit 557 generates an inference result for each component in step S1211. After that, the data collection module 560 sets a timer for the next firing time in step S1212.

[0129] 15 is a diagram showing a flowchart of processing from the start of inference on the management server to the completion of inference processing according to the first embodiment of the present invention. In this embodiment, the processing in FIG. 15 is realized by the CPU 201 executing a program stored in any one of the storage means, RAM 203, HDD 204, and ROM 202.

[0130] 15, the processing from the start of the inference processing on the management server 110 side to the completion of the inference processing will be described. In step S1301, the data receiving unit 572 determines whether or not a sensing data event of a consumable part has been periodically received from the data collection module 540. If the data receiving unit 572 determines that a sensing data event has not been received, the processing of the flowchart 1300 ends. If the data receiving unit 572 determines that a sensing data event has been received, the processing of step S1302 is executed.

[0131] In step S1302, the data receiving unit 572 stores the received sensing data event in the sensing data storage unit 573. When the management server 110 detects in step S1303 that the start time timer of the arithmetic driving unit 574, which has been set in advance according to startTime 801, has fired, the management server 110 starts the arithmetic driving unit 574 in step S1304.

[0132] In step S1305, the calculation driver 574 reads out the event information normalized in a format such as JSON from the sensing data storage unit 573. The flow from step S1306 to step S1310 is the same as step S1206 to step S1210, and therefore description thereof will be omitted.

[0133] When the inference process for each component is completed, in step S1311 the inference result accumulation unit 575 passes the inference results to the accuracy comparison unit 578 to verify the accuracy. That is, the accuracy comparison unit 578 compares the accuracy of the conventional prediction algorithm with the accuracy of the new prediction algorithm that has been repeatedly trained.

[0134] Thereafter, in step S1312, the management server 110 sets the timer for the next firing time. This completes the explanation of the first embodiment.

[0135] <Embodiment 2> Next, a description will be given of a second embodiment of the present invention. In the second embodiment, the same points as in the first embodiment will not be described, and only the points that differ from the first embodiment will be described.

[0136] In the first embodiment, an example is shown in which a device firmware update replaces the configuration file 800 stored in the configuration information management unit 550 and the ETL processing unit 554 and inference processing unit 555 based on the configuration file 800. However, if the means for rewriting the configuration file 800, ETL processing unit 554, and inference processing unit 555 is assumed to be a device firmware update, only a fixed predictive algorithm can be run for that model and firmware version. As a result, it may not be possible to evolve the device in a short period of time in line with the evolution of the prediction algorithm. To address this issue, in the second embodiment, a method for updating the prediction algorithm and an example in which only the configuration file 800, ETL processing unit 554, and inference processing unit 555 can be independently updated are described with reference to a flowchart 1400 in FIG. 16 .

[0137] FIG. 16 is a flowchart illustrating a process for updating a prediction algorithm on the cloud, i.e., on the management server 110, according to the second embodiment of the present invention. The sensing data storage unit 573 stores sensing data from multiple information processing devices. In step S1401, the part life analysis unit 576 determines whether the part is in a learning state based on a progress learning state, which indicates whether the progress of wear of a consumable part is being learned. The progress learning state is the learning state if progress is being learned, and the learning state is stopped if progress learning has been stopped. For example, progress indicates how much wear occurs per day. If the part life analysis unit 576 determines that the part is in the learning state, the process of step S1402 is executed. If the part life analysis unit 576 determines that the part is not in the learning state, the process of flowchart 1400 ends.

[0138] In step S1402, the part life analysis unit 576 learns the progress of wear of the consumable parts and updates the learned progress. In step S1403, the part life analysis unit 576 performs more accurate inference of the part wear by combining sensing data with a counter that indicates the number of times the consumable part has been used in the past. Then, based on the results, the algorithm management unit 577 generates and manages a life prediction algorithm for the consumable parts.

[0139] In step S1404, the accuracy comparison unit 578 compares the accuracy of the conventional prediction algorithm (the estimation result of step S1311) with the accuracy of the new prediction algorithm after repeated learning (the estimation result of step S1403). If the accuracy comparison unit 578 determines that the accuracy of the new prediction algorithm after repeated learning is higher than that of the conventional prediction algorithm, the process of step S1405 is executed. If the accuracy comparison unit 578 determines that the accuracy of the new prediction algorithm after repeated learning is not higher than that of the conventional prediction algorithm, the process of flowchart 1400 ends.

[0140] In step S1405, the management server 110 generates a configuration file 800, an ETL processing unit 554, and an inference processing unit 555 that have been revised to have greater accuracy. In step S1406, the management server 110 uses the differential update function to deploy only the generated configuration file 800, the ETL processing unit 554, and the inference processing unit 555 to the device, thereby performing an update.

[0141] According to the second embodiment, differential update distribution is performed in a short period of time in line with the evolution of the prediction algorithm, allowing the device to evolve in line with the update frequency of the prediction algorithm. The sequence after deployment is omitted here because the operational flow of the notification setting acquisition unit 553 of the data collection module 560 in the client device 120 is the same as that of flowchart 1020. This concludes the description of the second embodiment.

[0142] (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. It can also be realized by a circuit (e.g., ASIC) that realizes one or more functions.

[0143] 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.

[0144] The disclosure of this embodiment includes the following configuration, method, and program. (Configuration 1) An information processing device that executes inference processing for diagnosing one or more components provided in the information processing device, an output unit that outputs sensing data indicating the state of one or more components included in the information processing device to a storage unit inside the information processing device; the output means outputs the sensing data to a first storage means that stores event data generated based on the sensing data and a second storage means that stores data for executing ETL processing; the event data stored in the first storage means is transmitted to a server for collecting data via a network; The inference process is executed using the ETL-processed data after being stored in the second storage means. 1. An information processing device comprising: (Configuration 2) 2. The information processing apparatus according to configuration 1, further comprising a display means for displaying the diagnosis results of one or more components obtained by the inference process. (Configuration 3) The diagnosis results of one or more components obtained by the inference process are stored in the first storage means; 3. The information processing apparatus according to configuration 1 or 2, further characterized in that the diagnosis result stored in the first storage means is transmitted to the server. (Configuration 4) 4. The information processing device according to any one of configurations 1 to 3, wherein the one or more components included in the information processing device are components for controlling image processing of a printer or a scanner executed by the information processing device. (Configuration 5) an acquisition means for acquiring a collection file indicating collection information; The output means outputs the sensing data specified in the collection file to at least one of the first storage means and the second storage means in accordance with the collection file. 5. The information processing device according to any one of configurations 1 to 4. (Configuration 6) The system further includes a management unit for managing a configuration file in which components that are the targets of the inference process are described, 6. The information processing device according to any one of configurations 1 to 5, wherein the configuration file is updated by updating firmware of the information processing device. (Method 1) A control method for an information processing device that executes inference processing for diagnosing one or more components included in the information processing device, comprising: an output step of outputting sensing data indicating the state of one or more components included in the information processing device to a storage means inside the information processing device; In the output step, the sensing data is output to a first storage means that stores event data generated based on the sensing data and a second storage means that stores data for executing ETL processing; the event data stored in the first storage means is transmitted to a server for collecting data via a network; The inference process is executed using the ETL-processed data after being stored in the second storage means. A control method comprising: (Program 1) A computer as an information processing device that executes inference processing for diagnosing one or more components included in the information processing device, a program for executing an output step of outputting sensing data indicating a state of one or more components included in the information processing device to a storage means inside the information processing device, In the output step, the sensing data is output to a first storage means that stores event data generated based on the sensing data and a second storage means that stores data for executing ETL processing; the event data stored in the first storage means is transmitted to a server for collecting data via a network; The inference process is executed using the ETL-processed data after being stored in the second storage means. A program characterized by: [Explanation of symbols]

[0145] 100 Network 110 Management Server 120, 121 Client machines

Claims

1. An information processing device that executes inference processing for diagnosing one or more components included in the information processing device, an output unit that outputs sensing data indicating the state of one or more components included in the information processing device to a storage unit inside the information processing device; the output means outputs the sensing data to a first storage means that stores event data generated based on the sensing data and a second storage means that stores data for executing ETL processing; the event data stored in the first storage means is transmitted to a server for collecting data via a network; the inference process is executed using the ETL-processed data after being stored in the second storage means; 1. An information processing device comprising:

2. 2. The information processing apparatus according to claim 1, further comprising a display means for displaying the diagnosis results of one or more components obtained by said inference processing.

3. the diagnosis results of the one or more components obtained by the inference process are stored in the first storage means; 2. The information processing apparatus according to claim 1, further comprising: transmitting the diagnostic results stored in the first storage means to the server.

4. 2. The information processing apparatus according to claim 1, wherein the one or more components included in the information processing apparatus are components for controlling image processing of a printer or a scanner executed by the information processing apparatus.

5. an acquisition means for acquiring a collection file indicating collection information; The output means outputs the sensing data specified in the collection file to at least one of the first storage means and the second storage means in accordance with the collection file.

2. The information processing apparatus according to claim 1, wherein:

6. The system further includes a management unit for managing a configuration file in which components that are the targets of the inference process are described, 2. The information processing apparatus according to claim 1, wherein the configuration file is updated by updating firmware of the information processing apparatus.

7. A control method for an information processing device that executes inference processing for diagnosing one or more components included in the information processing device, comprising: an output step of outputting sensing data indicating the state of one or more components included in the information processing device to a storage means inside the information processing device; In the output step, the sensing data is output to a first storage means for storing event data generated based on the sensing data and a second storage means for storing data for executing ETL processing; the event data stored in the first storage means is transmitted to a server for collecting data via a network; the inference process is executed using the ETL-processed data after being stored in the second storage means; A control method comprising:

8. A computer as an information processing device that executes inference processing for diagnosing one or more components included in the information processing device, a program for executing an output step of outputting sensing data indicating a state of one or more components included in the information processing device to a storage means inside the information processing device, In the output step, the sensing data is output to a first storage means for storing event data generated based on the sensing data and a second storage means for storing data for executing ETL processing; the event data stored in the first storage means is transmitted to a server for collecting data via a network; the inference process is executed using the ETL-processed data after being stored in the second storage means; A program characterized by:

Images