System and method for controlling system

Abstract

To prevent causing excessive resource consumption and processing stagnation on a server side in the configuration of a device and a server for receiving data from the device, when an unexpected amount of data is transmitted from a specific device due to a hardware failure on the device side or an incorrect detection of a sensor.SOLUTION: When the number of real-time events received from the same device 102 exceeds a threshold within a predetermined period of time (Yes in step 613), a condition monitoring server 101 transmits a data collection request 4016 to stop transmitting real-time events and to transmit periodic events to the device 102 (step 614). If the device 102 determines that the abnormality has been resolved based on the periodic event received from the device 102 during the suspension of transmission of the real-time event (Yes in step 622), a data collection request 4001 to resume transmission of the real-time event is transmitted to the device 102 (step 623).SELECTED DRAWING: Figure 6B

Description

[Technical field]

[0001] The present invention relates to a system and a method for controlling the system. [Background technology]

[0002] In recent years, image forming devices such as MFPs (Multi Function Printers) have become increasingly multifunctional, and it is becoming common for image forming devices to connect to servers and cloud services (hereinafter referred to as "servers") via the Internet to provide functions and services. IoT (Internet of Things) systems are becoming widespread, in which not only image forming devices but also everything else, such as homes and buildings, home appliances, automobiles, and electronic devices, connect to servers via the Internet as clients. For example, IoT systems transmit information obtained from sensors installed in clients to a server, and the server collects, analyzes, and utilizes the data to provide added value to service users.

[0003] In addition, unexpected amounts of data may be sent from a particular client due to hardware failure on the client side or false detection of a sensor. For example, data on the same event may be sent tens to hundreds of thousands of times a day due to an abnormality detected by a client's sensor. When a client sends abnormal data in this way, it can lead to excessive resource consumption and processing backlogs on the server side. As a result, processing of data from clients that are not experiencing abnormalities is also delayed.

[0004] Patent Document 1 proposes a technology in which, when a server determines that the amount of data received per unit time from a client exceeds a predetermined value, the server sends transmission rules to the client to control transmission, and the client follows the transmission rules and stops transmitting some of the data until the amount of data transmitted per unit time falls below the predetermined value. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] JP 2020-145647 A Summary of the Invention [Problem to be solved by the invention]

[0006] However, in the conventional technology, when a client transmits abnormal data as described above, the data transmission of the client is stopped. Therefore, the server side cannot monitor the status of the client at all until the abnormality is resolved on the client side.

[0007] The present invention has been made to solve the above problems, and aims to provide a mechanism that can flexibly avoid processing delays on the server side caused by abnormal data transmissions, while continuing monitoring through periodic notifications from the client terminal, even when the abnormal data transmissions are made by the client terminal. [Means for solving the problem]

[0008] The present invention is a system having one or more client terminals and a service that receives notification information from the client terminals, wherein the client terminal has a transmitting means capable of transmitting first notification information, which transmits information about an event that has occurred in the client terminal to the service at the time of the event occurrence, in response to a request from the service, and transmitting second notification information, which the client terminal periodically checks whether an event has occurred and transmits the information to the service, wherein the service has a control means that performs a first control to stop the transmission of the first notification information and send to the client terminal a first request to send the second notification information, when the number of the first notification information received from the same client terminal within a first period exceeds a first threshold value, and the control means performs a second control to send to the client terminal a second request to resume transmission of the first notification information, when it is determined that an abnormality has been resolved in the client terminal based on the second notification information received from the client terminal that has stopped transmitting the first notification information by the first control. Effect of the Invention

[0009] According to the present invention, even when an abnormal data transmission occurs from a client terminal, monitoring can be continued through periodic notifications from the client terminal, while flexibly avoiding processing delays on the server side due to the abnormal data transmission. [Brief description of the drawings]

[0010] [Figure 1] FIG. 1 is a diagram showing the overall configuration of a system according to an embodiment of the present invention. [Diagram 2] FIG. 2 is a diagram illustrating the hardware configuration of a status monitoring server and a device. [Diagram 3] FIG. 2 is a diagram showing the functional configuration of a status monitoring server and a device. [Figure 4A] FIG. 4 is a diagram explaining the data structures of various data handled by the status monitoring server. [Figure 4B] FIG. 4 is a diagram explaining the data structures of various data handled by the status monitoring server. [Figure 4C]FIG. 4 is a diagram explaining the data structures of various data handled by the status monitoring server. [Figure 4D] FIG. 4 is a diagram explaining the data structures of various data handled by the status monitoring server. [Figure 4E] FIG. 4 is a diagram explaining the data structures of various data handled by the status monitoring server. [Figure 4F] FIG. 4 is a diagram explaining the data structures of various data handled by the status monitoring server. [Diagram 5] 4 is a diagram for explaining a UI provided by the status monitoring server according to the first embodiment. [Figure 6A] 5 is a flowchart illustrating a processing procedure of a status monitoring server according to the first embodiment. [Figure 6B] 5 is a flowchart illustrating a processing procedure of a status monitoring server according to the first embodiment. [Figure 6C] 5 is a flowchart illustrating a processing procedure of a status monitoring server according to the first embodiment. [Figure 7] 13 is a diagram for explaining the data structure of a data collection request transmitted from a status monitoring server to a device according to the second embodiment. [Figure 8] 13 is a diagram for explaining the data structure of device information held by a status monitoring server according to the third embodiment; [Figure 9A] 13 is a flowchart illustrating real-time event processing of the status monitoring server according to the third embodiment. [Figure 9B] 13 is a flowchart illustrating periodic event processing of the status monitoring server according to the third embodiment. [Figure 10A] 13 is a diagram for explaining a data structure of device information held by a status monitoring server according to the fourth embodiment; [Figure 10B] 13 is a diagram for explaining the data structure of a data collection request transmitted from a status monitoring server to a device according to the fourth embodiment. [Figure 11A] 13 is a flowchart illustrating real-time event processing of the status monitoring server according to the fourth embodiment. [Figure 11B] 13 is a flowchart illustrating periodic event processing by the status monitoring server according to the fourth embodiment. [Figure 12]13A and 13B are diagrams for explaining a UI provided by a status monitoring server according to the fifth embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0011] Hereinafter, an embodiment of the present invention will be described with reference to the drawings. [First embodiment] <System configuration> FIG. 1 is a diagram illustrating an example of the overall configuration of a system according to an embodiment of the present invention. The system of this embodiment is composed of a status monitoring server 101 and at least one device 102. Note that the system may be configured to include other servers (not shown) that provide other functions in addition to the status monitoring server 101. The devices 102 include various devices such as image processing devices (image forming devices), houses and buildings, home appliances, automobiles, and electronic devices.

[0012] The status monitoring server 101 monitors the occurrence of errors in the device 102 and information on the remaining amount of consumables, and notifies the user as an alert when a response by the user is required. The device 102 detects error or warning information occurring in the device 102 from sensors mounted on the device 102 or wear levels estimated from the cumulative number of times functions are used, and notifies the status monitoring server 101 of the detection as event data. The status monitoring server 101 receives event data from the device 102, and stores information that needs to be presented to the user based on the event data as alert information. In this embodiment, the device 102 is configured to directly notify the status monitoring server 101, but if there is a server other than the status monitoring server 101, a server that mediates interactions between each server and the device 102 may be provided.

[0013] The status monitoring server 101 and the device 102 are connected via a network 103. The network 103 is a communication network realized by, for example, any one of a LAN (Local Area Network) such as the Internet, a WAN (Wide Area Network), a telephone line, etc., or a combination thereof.

[0014] <Hardware configuration of information processing device> FIG. 2 is a block diagram showing an example of the hardware configuration of an information processing device constituting the status monitoring server 101 and an image processing device constituting the device 102. As shown in FIG. The information processing device constituting the status monitoring server 101 includes a CPU (Central Processing Unit) 201 that executes software stored in a storage device such as a HDD (Hard Disk Drive) 203. The CPU 201 comprehensively controls each piece of hardware connected to a system bus 204.

[0015] The memory 202 functions as the main memory, work area, etc. of the CPU 201 . The HDD 203 is a non-volatile storage area and serves as a large-capacity storage device to record data. Note that the configuration may include other storage devices such as SSDs (Solid State Drives) instead of or in combination with the HDD.

[0016] The input control unit 205 controls input from an input device 206 such as a keyboard. Depending on the role of the information processing device, the input control unit 205 and the input device 206 may be omitted. The display control unit 207 controls the display on a display device 208 such as a liquid crystal display. Depending on the role of the information processing device, the display control unit 207 and the display device 208 may be omitted. A network control unit 209 exchanges data bidirectionally with other nodes via the network. It should be noted that the hardware configuration of the image processing apparatus constituting the device 102 includes the above-mentioned configuration as well as configurations (not shown) that are specific to the image processing apparatus, such as a printer unit and a scanner unit.

[0017] The information processing device constituting the status monitoring server 101 is realized by an information processing device provided as a cloud computing service. Examples of cloud computing include serverless computing and virtual machines. In cloud computing, multiple hardware resources shown in FIG. 2 are used. Note that the status monitoring server 101 may be an on-premise server, and the information processing device constituting the status monitoring server 101 may be realized by one computer or multiple computers.

[0018] <Functional configuration> FIG. 3 is a block diagram showing an example of the functional configuration of the status monitoring server 101 and the device 102. As shown in FIG. The status monitoring server 101 provides a function for remotely monitoring and managing the status of the device 102. The functions provided by the status monitoring server 101 are called "services." These will be described in detail below.

[0019] The status monitoring server 101 comprises a device management unit 301, a device status management unit 302, an event processing unit 303, an event reception history management unit 304, an event reception unit 305, and a UI management unit 306. Each of these units is realized by the CPU 201 of the information processing device constituting the status monitoring server 101 loading into the memory 202 and executing a program stored in the HDD 203 or the like as necessary.

[0020] The device management unit 301 manages device information to be managed by the status monitoring server 101. The devices managed by the device management unit 301 are devices that are added or deleted by device registration / deletion instructions (not shown) to the status monitoring server 101. Alternatively, the device management unit 301 may be configured to target devices that are enabled for management by the status monitoring server 101, among devices managed by a separate server (not shown) that comprehensively manages device information.

[0021] Furthermore, the device management unit 301 transmits a data collection request to the device 102. The target of the data collection request includes an alert occurrence notification of the device 102. The alert occurrence notification notifies, for example, an event such as the body cover of the device 102 not being closed, the need to replace parts, or the need to replace consumables, together with alert level information such as an error or warning. The event data of the alert occurrence notification and the data structure of the data collection request transmitted to the device 102 will be described later with reference to FIGS. 4A to 4F.

[0022] The device status management unit 302 manages alert information indicating the status of the device targeted by the status monitoring server 101. The alert information is information generated based on event data of an alert occurrence notification received from the device 102, and includes an alert code indicating the time of the alert occurrence, the location where the alert occurred, the type and status of the alert, the alert level, and details of the alert. The data structure of the alert information will be described later with reference to Figs. 4A to 4F.

[0023] The event processing unit 303 acquires from the event receiving unit 305 and processes the event data that the event receiving unit 305 receives from the device 102 and holds. The event processing unit 303 interprets the event data, generates alert information for the device 102, and transmits the alert information to the device status management unit 302 to store it. The event processing unit 303 also transmits the event data to the event reception history management unit 304 to store it.

[0024] The event reception history management unit 304 holds the event data received from the device 102 as history information. The event reception history management unit 304 accepts and stores the event data processed by the event processing unit 303 from the event processing unit 303. In addition, the event reception history management unit 304 receives an instruction from the event processing unit 303, acquires event data that has occurred within a predetermined period, and returns the event data to the event processing unit 303.

[0025] The event receiving unit 305 receives and holds event data from the device 102. It provides the event data in response to a request from the event processing 303. The data structure of the event data will be described later with reference to Figs. 4A to 4F. The event data held as history in the event reception history management unit 304 described above has the same data structure.

[0026] The UI management unit 306 manages the UI provided by the status monitoring server 101. The UI provided by the status monitoring server 101 is provided as a UI for a Web application, and can be displayed on a Web browser. The Web application is composed of HTML that represents a Web page, CSS (Cascading Style Sheets) that is a style sheet, a programming language that runs on the Web browser (for example, JavaScript (registered trademark)), and the like. Furthermore, device information displayed on the UI is acquired by using JavaScript that runs on the Web browser to acquire information held in the device management unit 301 and device status management unit 302 via an API (not shown) provided by the status monitoring server 101.

[0027] Next, the device 102 will be described. The device 102 includes a data collection request receiving unit 311, a data collecting unit 312, and an event notifying unit 313. Each of these units is realized by the CPU 201 of the device 102 loading a program stored in the HDD 203 or the like into the memory 202 and executing it as necessary.

[0028] The data collection request receiving unit 311 receives a data collection request from the status monitoring server 101, and notifies the data collection unit 312 of the collection target specified in the received data collection request. The data collection unit 312 holds data of collection targets notified by the data collection request receiving unit 311 , collects various data based on the collection targets, and transmits the data to the event notification unit 313 . The event notification unit 313 notifies the data collection management server 101 of the data collected by the data collection unit 312 .

[0029] For example, when the data collection request receiving unit 311 receives a data collection request including an alert occurrence notification, the data collection unit 312 checks for the occurrence of an alert in the device 102 at the time of the occurrence of an alert in the device 102 or periodically, as specified in the data collection request, and generates event data for the alert occurrence notification. The generated event data is notified to the status monitoring server 101 by the event notification unit 313.

[0030] <Data Structure> Figures 4A to 4F are diagrams for explaining the data structures of various data handled by the status monitoring server 101. Hereinafter, Figures 4A to 4F will be collectively referred to simply as "Figure 4." Here, the data structures of the data collection requests 4001 and 4016 sent to the device 102, the event data 4101, 4111, 4116, 4128 notifying the device 102 of the occurrence of an alert, the device information 4201 managed by the status monitoring server 101, and the alert information 4207 will be described. The device information 4201 and the alert information 4207 are stored in the format of JSON (JavaScript Object Notation) or XML (Extensible Markup Language) on the HDD 203 of the status monitoring server 101. Alternatively, they may be stored in an external database (not shown). In this embodiment, the JSON format is shown as an example, but the method and format of storage are not particularly limited.

[0031] First, the data structure of the data collection request that the status monitoring server 101 sends to the device 102 will be described. The data collection request 4001 corresponds to an example of data when requesting the device 102 to transmit a real-time event and a periodic event. The data collection request 4016 corresponds to an example of data when real-time event collection is stopped and transmission of only periodic events is requested.

[0032] The data collection request 4001 will now be described. In the data collection request 4001, a transmission request 4002 for a real-time event and a transmission request 4003 for a periodic event are defined.

[0033] In the real-time event transmission request 4002, the firing condition 4006 indicates the firing condition of the event, and in this example, "realtime" is specified. "Realtime" indicates that the event is notified immediately when the event occurs. The notification target 4004 indicates the classification of the event to be notified as the real-time event transmission request 4002. In this example, "Alert" (4007), "Capacity" (4008), "Cover" (4009), and "Part" (4010) are specified as the classification of the event to be notified.

[0034] "Alert" (4007) notifies as an alert when any error or warning occurs in the device 102. "Capacity" (4008) notifies as an alert when an error or warning related to capacity occurs, for example, when the output paper is accumulated and the paper output tray is full, or when the paper feed tray of the cassette has run out of paper and needs to be replenished. "Cover" (4009) notifies as an alert when an error or warning related to opening and closing a cover occurs, for example, when the main body cover of the device 102 is open or when the toner bottle cover is open. "Part" (4010) notifies as an alert when an error or warning related to a part occurs, for example, when a part of the device 102, such as a fixing unit or fixing roller, wears out and needs to be replaced.

[0035] In the transmission request 4002, it is specified that an event should be notified in real time by the ignition condition 4006. Therefore, the device 102 immediately notifies an event that matches the classification specified in the notification target 4005 when the event occurs.

[0036] In the periodic event transmission request 4003, the firing condition 4011 indicates the event firing condition similar to the above-mentioned 4006, and "cron(0 * / 12 * * *)" is specified. "cron(0 * / 12 * * *)" indicates that the event is to be notified at 0 minutes every 12 hours in the cron format.

[0037] Notification target 4005 indicates the classification of the event to be notified as periodic event transmission request 4003. Here, it indicates that "Alert" (4012), "Capacity" (4013), "Cover" (4014), and "Part" (4015) are specified, similarly to real-time event transmission request 4002. In the transmission request 4003, it is specified that an event should be notified periodically by the ignition condition 4011. Therefore, the device 102 checks the event occurring in the device 102 at the timing of the event notification, and if an event that matches the classification specified in the notification target 4005 occurs, it notifies the event.

[0038] In this way, by specifying the alert information of the device 102 to be handled by the status monitoring server 101 as a transmission request, the device 102 notifies the occurrence of the corresponding phenomenon as an event in accordance with the specified transmission request. In this example, an example of specifying a transmission request related to an alert is shown, but a configuration in which a transmission request is specified for receiving a notification when the power of the device 102 is turned on / off or when the hardware configuration or software configuration of the device 102 is changed may also be used.

[0039] Next, the data collection request 4016 will be described. The data collection request 4016 corresponds to a case where real-time events are stopped and only periodic events are requested to be transmitted. For this reason, in the notification target 4017, alert-related events (the above-mentioned Alert (4007), "Capacity" (4008), "Cover" (4009), and "Part" (4010)) are not specified in the classification of events to be notified specified in the real-time event transmission request 4002. The transmission request for the periodic event is the same as the transmission request 4003 for the periodic event.

[0040] In the process described below, when the status monitoring server 101 detects an abnormal event transmission by the device 102, it transmits a data collection request such as this data collection request 4016 to the device 102, thereby controlling so that an alert-type event that is the cause of the abnormal transmission is not notified. As a result, no notification is given when an event occurs, and an event is notified every 12 hours as specified by the periodic event transmission request 4003.

[0041] Next, the data structure of the event data of the alert occurrence notification sent from the device 102 to the status monitoring server 101 will be described.

[0042] First, the event data of the real-time event will be described. Event data 4101 is an example of event data for a real-time event. The event data 4101 corresponds to event data notifying an alert indicating that the fixing unit, which is a part of the device 102, needs to be replaced, in accordance with the designation of "Part" (4010) in the transmission request 4002 of the real-time event described above.

[0043] The event ID 4103 indicates an event ID that uniquely identifies an event. The event name 4104 indicates the name of the event. The device ID 4105 indicates a device ID that uniquely identifies the device that is the source of the event. The event occurrence time 4106 indicates the time when the event occurred.

[0044] The document information 4102 is document information associated with an event. The document information 4102 includes an alert type 4107, an alert target 4108, an alert status 4109, and an alert code 4110.

[0045] The alert type 4107 indicates the type of alert, and in this example indicates "Need Replacement", that is, a state in which replacement is required. An alert target 4108 indicates the target of the alert, and in this example, indicates that the target is "FixingUnit", that is, the fixing unit. The alert target changes depending on the location where the alert occurs, and for example, the value specified changes depending on the component of the device 102, such as "FixingRoller" indicating the fixing roller. The alert status 4109 indicates the status of the alert, and in this example indicates "Now", that is, a status in which the fuser needs to be replaced immediately. Other values ​​such as "Soon", which indicates that replacement will be required in the near future, but not immediately, are specified in the alert status 4109. The alert code 4110 is a code indicating details of the alert, and the code in which each digit is expressed in hexadecimal can express information such as the level of the alert (error, warning, service call), the source of the alert, and the type of alert.

[0046] Like the above-mentioned event data 4101, the event data 4111 is also an example of event data for a real-time event, but this shows an example of a case where a notification is given that an event that occurred in the device 102 has been resolved. Here, it is assumed that a notification is given when an alert that has occurred in the event data 4101, indicating that the fixing unit needs to be replaced, is resolved by replacing the fixing unit. In the event data 4111, the alert type 4112 included in the document information is specified as "NeedReplacement", the alert target 4113 is specified as "FixingUnit", the alert status 4114 is blank, and the alert code 4115 is blank, indicating that the condition requiring replacement of the fixing unit has been resolved.

[0047] Next, the event data of a regular event will be described. Event data 4116 is an example of event data for a regular event. The event data 4116 corresponds to event data notifying of an error or warning related to a part occurring in the device 102 at that time due to a periodic event notified every 12 hours in accordance with the specification of "Part" (4015) in the aforementioned periodic event transmission request 4003. In this example, document information 4117 including an alert 4118 indicating that the fuser unit needs to be replaced and an alert 4119 indicating that the fuser roller needs to be replaced is notified.

[0048] 4120 to 4123 of the event data 4116 indicate the event ID, the event name, the device ID, and the time when the event occurred, similarly to 4103 to 4106 described above. Like the above-mentioned 4107 to 4110, 4124 to 4127 of the alert 4118 indicate the alert type, the alert target, the alert state, and the alert code, and indicate a state in which the fixing unit needs to be replaced immediately. Alert 4119 indicates that the fuser roller will soon need replacing.

[0049] Like the event data 4116, the event data 4128 is also an example of event data for a periodic event, but this indicates a state in which, at the timing of the periodic event, no errors or warnings have occurred related to parts in the device 102. Therefore, in the event data 4128, the event document information 4129 is notified as being empty.

[0050] Next, the device information of the device 102 held by the status monitoring server 101 will be described. The device information 4201 is an example of device information. The device information 4201 includes a device ID 4202 that uniquely identifies the device, a device name 4203 that indicates the name of the device, a device installation location 4204, a device IP address 4205, and an event reception stop flag 4206 that indicates whether event reception from the device 102 has been stopped. If the event reception stop flag 4206 is "false", this indicates that event reception has not been stopped. On the other hand, if the event reception stop flag 4206 is "true", this indicates that event reception has been stopped.

[0051] Next, the alert information of the device 102 held by the status monitoring server 101 will be described. The alert information 4207 is an example of alert information. The status monitoring server 101 detects the occurrence of an alert upon receiving an event notification from the device 102 and generates alert information. The status monitoring server 101 also detects the resolution of the alert upon receiving an event notification from the device 102 and deletes the alert information. Note that when an alert is resolved, the status monitoring server 101 can provide information on past alerts by retaining the alert information as alert history information (not shown).

[0052] The alert information 4207 includes an alert ID 4210 that uniquely identifies the alert, a device ID 4211 that indicates the device in which the alert has occurred, an alert status 4208 that indicates the state of the alert, and a time 4217 when the alert occurred. The alert status 4208 includes an alert type 4212 , an alert target 4213 , an alert state 4214 , and an alert list 4209 . Furthermore, the alert list 4209 includes an alert code 4215 and an alert level 4216 . The status monitoring server 101 receives the event data 4101 of the real-time event or the event data 4116 of the periodic event described above, and generates alert information such as 4207 based on this event information.

[0053] Next, the relationship between alert information and event information will be explained, taking alert information 4207 and event data 4101 of a real-time event as examples. In the alert information 4207, the alert ID 4210 is generated by combining the device ID 4105, the alert type 4107, and the alert target 4108 of the real-time event 4101. This combination makes it possible to uniquely determine the event occurring in the device 102. Note that a new unique ID may be generated using a UUID (Universally Unique Identifier) ​​and specified as the alert ID. In the device ID 4211, the device ID 4105 of the real-time event 4101 is specified.

[0054] The alert type 4107, alert target 4108, and alert state 4109 contained in the document information 4102 of the real-time event 4101 are specified as the alert type 4212, alert target 4213, and alert state 4214 of the alert status 4208, respectively. The alert code 4110 in the document information 4102 of the real-time event 4101 is specified as the alert code 4215 in the alert list 4209. Also, the alert level 4216 can be determined by interpreting the alert code 4110. For example, the first two digits of the code indicate the alert level, and '03' indicates an error state. The code system is not particularly limited, and may be one defined in the specifications of the device 102 or standard specifications such as RFC (Request For Comments). The occurrence time 4106 of the real-time event 4101 is specified as the occurrence time 4217 of the alert.

[0055] <ui> FIG. 5 is a diagram showing an example of a UI provided by the UI management unit 306 of the status monitoring server 101. As shown in FIG. The device details UI 501 is composed of basic information about the device, a status tab 502, a consumables tab, and a security tab. In this example, the status tab 502 is selected and the operating status of the device is displayed in the status tab.

[0056] In the error message 503, a message indicating that a user action is required, such as calling an operator or a service, is displayed. The device error information 504 displays an error message 507, an error occurrence time 508, and a time elapsed since the occurrence 509. This error information is displayed based on the alert information 4207 shown in Fig. 4 obtained from the status monitoring server 101 by an API (not shown).

[0057] In the error message 507, a predefined message determined from the alert type 4212, the alert target 4213, and the alert state 4214 of the alert information 4207 is displayed. In the error occurrence time 508, the alert occurrence time 4217 of the alert information 4207 is displayed. In the field of time elapsed since occurrence 509, the difference in time between the time when the device details UI 501 screen is displayed and the error occurrence time 508 is displayed. Furthermore, depending on the alert level 4216 of the alert information 4207, the background color of the message 503 is displayed in red in the case of an error, and in yellow in the case of a warning.

[0058] In the device error information 504, the device status can be reflected instantly by a real-time event, and when the real-time event is stopped, the device status can be reflected periodically by a periodic event.

[0059] Information about errors that have occurred in the past is displayed in the error history 506. Like the alert information 4207, the error history is also displayed based on alert history information (not shown) acquired from the status monitoring server 101 via an API (not shown).

[0060] <Abnormality / Resolution Detection Processing> 6A to 6C are flowcharts showing an example of the processing procedure when the status monitoring server 101 of the first embodiment receives event data notified from the device 102. Hereinafter, Fig. 6A to Fig. 6C may be collectively referred to as "Fig. 6". Note that the processing of this flowchart is realized by the CPU 201 of the information processing device constituting the status monitoring server 101 loading a program stored in the HDD 203 or the like into the memory 202 and executing it as necessary. When the status monitoring server 101 determines in the process of receiving a real-time event notification that an abnormal number of events have been received from the device 102, the status monitoring server 101 stops the real-time event for the device 102. Also, when the status monitoring server 101 determines that the phenomenon causing the abnormality has been resolved by a periodic event, the status monitoring server 101 instructs the device 102 to start a real-time event. This will be explained in detail below.

[0061] 6A begins when the event receiving unit 305 of the status monitoring server 101 receives event data notified from the device 102. The event receiving unit 305, which has received the event data from the device 102, notifies the event processing unit 303 of the received event data. Note that the event receiving unit 305 may be configured to store the received event data (not shown) in a queue and provide the event processing unit 303 with the event data in response to a periodic inquiry from the event processing unit 303.

[0062] In S601, the event processing unit 303 interprets the event data received from the event receiving unit 305 and determines whether the event data is a real-time event. Specifically, the event processing unit 303 first refers to the event name of the event data. In the example of event data 4101 in Fig. 4, the event processing unit 303 refers to event name 4104, and in the example of event data 4116, the event processing unit 303 refers to event name 4121. Furthermore, the event processing unit 303 determines whether the event data is a real-time event or a periodic event based on the referred event name. For example, in the case of the event data 4101, it is determined from the event name 4104 "PartstStatusChanged" that this is a real-time event notifying that there has been a change in the status of a part. In the case of the event data 4116, since the event name 4121 is "PartstStatusSnapshotted", it is determined that this is a periodic event for notifying the status of the part.

[0063] A real-time event refers to an event notified according to a classification such as "Alert" (4007), "Capacity" (4008), "Cover" (4009), or "Part" (4010) that is specified as a notification target 4004 in a transmission request 4002 of a data collection request 4001. In the example of Fig. 4, event data 4101 and 4111 correspond to real-time events. Furthermore, a periodic event refers to an event notified according to a classification such as "Alert" (4012), "Capacity" (4013), "Cover" (4014), or "Part" (4015) that is specified as a notification target 4005 in a transmission request 4003 of a data collection request 4001. In the example of Fig. 4, event data 4116 and 4128 correspond to periodic events. It is assumed that the event processing unit 303 holds mapping information (not shown) between each classification and the corresponding event name.

[0064] If it is determined that the event is a real-time event (Yes in S601), the event processing unit 303 advances the process to S602. The real-time event processing in S602 is processing performed when a real-time event is received, and the details of the processing will be described later in S610 to S617 in FIG. 4B. On the other hand, if it is determined that it is a periodic event (No in S601), the event processing unit 303 advances the process to S603. The periodic event processing in S603 is processing performed when a periodic event is received, and details of the processing will be described later in S620 to S625 in FIG. 4C.

[0065] The real-time event processing in S602 will be described below with reference to FIG. 6B. FIG. 6B is a flowchart illustrating real-time event processing according to the first embodiment. In S610, the event processing unit 303 specifies the device ID of the received event data (device ID 4105 in the example of the event data 4101) and requests the device management unit 301 to obtain device information that matches the device ID. Upon receiving this request, the device management unit 301 returns device information that matches the specified device ID to the event processing 303. For example, device information such as device information 4201 is returned.

[0066] Next, in S611, the event processing unit 303 refers to the event reception stop flag of the device information acquired in S610 above (event reception stop flag 4206 in the example of device information 4201) and determines whether event reception from the device 102 has been stopped. If the event reception stop flag is "false", it is determined that event reception is not currently stopped. On the other hand, if the event reception stop flag is "true", it is determined that event reception is currently stopped.

[0067] If it is determined that event reception is stopped (Yes in S611), the event processing unit 303 does not process the received event and ends the processing of this flowchart. It should be noted that while event reception is stopped, no real-time events are transmitted from the device 102. In this case, however, events that are received until the transmission stoppage is reflected in the device 102 are assumed.

[0068] On the other hand, if it is determined that event reception is not stopped (No in S611), the event process unit 303 advances the process to S612. In S612, the event processing unit 303 inquires of the event reception history management unit 304 and acquires past event history information notified from the device corresponding to the device ID of the received event data.

[0069] Next, in S613, the event processing unit 303 judges whether the number of histories received by the device within a predetermined period of time exceeds a threshold based on the event history information acquired in S612. The predetermined period and threshold are determined in advance, and are not limited to any particular value (for example, a value that can be considered an abnormal notification from the characteristics of the device or event, such as 1000 events within one hour, is specified). The process related to the acquisition of event history information may be configured to acquire all event history information that matches the device ID, or may be configured to acquire only within a specified period of time. Also, only the number of event history information that matches the conditions may be counted and acquired.

[0070] Here, if the number of histories received by the device within the predetermined period does not exceed the threshold value (No in S613), the event processing unit 303 advances the process to S616. On the other hand, if the number of history events received by the device within the predetermined period exceeds the threshold (Yes in S613), the event processing unit 303 determines that an abnormal number of events have been received from the device 102, and proceeds to S614.

[0071] In S614, the event processing unit 303 instructs the device management unit 301 to stop the real-time event. Specifically, the real-time event is stopped by transmitting a data collection request such as a data collection request 4016 to the device 102, and control is performed so that only periodic events are transmitted. The device management unit 301 accepts a request from the event processing 303 and transmits a data collection request such as 4016 in FIG. 4 to the device 102.

[0072] Next, in S615, the device management unit 301 sends a data collection request to the device 102, and then updates the event reception stop flag of the device information for the device corresponding to the device ID of the received event data (event reception stop flag 4206 in the example of device information 4201) to “true” indicating that the event reception is to be stopped.

[0073] In S616, the event receiving unit 305 stores alert information based on the received event data. That is, the event receiving unit 305 instructs the device status management unit 302 to generate and store alert information such as the alert information 4207 based on the received event data.

[0074] Next, in S617, the event processing unit 303 instructs the event reception history management unit 304 to store the received event data. Specifically, the event data information of the received real-time event is held as previously received event information, and is stored so that the event reception history management unit 304 can acquire and return the information in response to an acquisition request shown in the process of S612.

[0075] Next, the periodic event processing in S603 will be described with reference to FIG. 6C. FIG. 6C is a flowchart illustrating periodic event processing according to the second embodiment. In S620, the event processing unit 303 specifies the device ID of the received event data (device ID 4122 in the example of the event data 4116) and requests the device management unit 301 to obtain device information that matches the device ID. Upon receiving this request, the device management unit 301 returns device information that matches the specified device ID to the event processing 303. For example, device information such as device information 4201 is returned.

[0076] Next, in S621, the event processing unit 303 refers to the event reception stop flag of the device information acquired in S620 above (event reception stop flag 4206 in the example of device information 4201) to determine whether event reception from the device 102 has been stopped. If it is determined that event reception is not stopped (No in S621), the event process unit 303 advances the process to S625 and updates the alert information. On the other hand, if it is determined that event reception is stopped (Yes in S621), the event process unit 303 advances the process to S622.

[0077] In S622, the event processing unit 303 refers to the received event data and judges whether the alert of the device has been resolved. Specifically, it refers to the document information of the received event data (4117 in the example of the event data 4116, and 4129 in the example of the event data 4128). If alert information is included as in the document information 4117, it is considered that the alert has not been resolved. On the other hand, if alert information is not included as in the document information 4129, it is considered that the alert has been resolved.

[0078] If it is determined here that the alert has not been resolved (No in S622), the event process unit 303 advances the process to S625 and updates the alert information. On the other hand, if it is determined that the alert has been resolved (Yes in S622), the event process unit 303 advances the process to S623.

[0079] In S623, the event processing unit 303 instructs the device management unit 301 to start the real-time event. Specifically, the event processing unit 303 controls the device management unit 301 to start the real-time event by transmitting a data collection request such as the data collection request 4001 in FIG. 4 to the device 102. The device management unit 301 accepts the request from the event processing unit 303 and transmits the data collection request to the device 102.

[0080] In S624, after sending a data collection request to the device 102, the device management unit 301 updates the event reception stop flag of the device information corresponding to the device ID of the received event data (in the example of device information 4201, event reception stop flag 4206) to “false” indicating that the event reception stop flag is not to be stopped.

[0081] In S625, the event receiving unit 305 stores alert information based on the received event data. That is, the event receiving unit 305 instructs the device status management unit 302 to generate and store alert information such as the alert information 4207 based on the event data of a periodic event such as the event data 4116.

[0082] As described above, when the status monitoring server 101 determines that an abnormal number of real-time events have been received from the device 102, it requests the device 102 to stop sending real-time events and to send only periodic events. Furthermore, when it determines that an alert has been resolved by receiving a periodic event, it requests the device 102 to resume sending real-time events. In this way, by controlling to receive only periodic events when an abnormal number of events is received from the device 102, it is possible to reduce the processing impact of the status monitoring server 101 due to notifications of the abnormal number of events while continuing to monitor the device. Also, the status monitoring server 101 can determine that the abnormality has been resolved by monitoring the periodic events and resume sending real-time events.

[0083] Second Embodiment In the first embodiment, a configuration has been shown in which, when an abnormal number of event notifications from the device 102 are detected, transmission of real-time events is stopped and a data collection request such as 4016 in Fig. 4 is sent to the device 102 so that only periodic events are sent. In this case, the ignition condition for the periodic event in the data collection request 4016 is specified to be notified every 12 hours, as in the case of concurrent use of real-time events. In this case, since the interval between periodic events is large, there is a possibility that a discrepancy will occur in the alert information held by the device 102 and the status monitoring server 101. In the second embodiment, by making the interval between periodic events shorter while a real-time event is stopped than when a real-time event is being transmitted, it is possible to reduce the impact of a mismatch with the state of the device 102 even in a configuration in which only periodic events are received. In the second embodiment, only the differences from the first embodiment will be described, and the configurations and processes that are not specifically stated are all the same as those in the first embodiment.

[0084] <Data Structure> FIG. 7 is a diagram for explaining a data collection request sent from the status monitoring server 101 to the device 102 in the second embodiment. The data collection request shown in this figure specifies the case where real-time events are stopped and only periodic events are requested to be transmitted when an abnormal number notification is detected from the device 102. This data collection request, like the data collection request 4016 shown in Fig. 4, indicates a state in which an alert-related event is not specified in the event classification to be notified specified in the real-time event transmission request 701. In other words, it indicates a state in which the above-mentioned "Alert" (4007), "Capacity" (4008), "Cover" (4009), and "Part" (4010) are not specified. When the alert is resolved, the sending of real-time events will resume and the sending interval for periodic events will be returned to normal (to every 12 hours in the above example).

[0085] Also, the event firing condition for the periodic event transmission request is set to "cron(0 * / 1 * * *)", and an example is shown in which the interval is specified to be every hour while the real-time event is stopped. Note that while the interval is every hour in this example, it may be specified to be shorter or longer. In this way, while the real-time event is stopped, the notification interval for the periodic event is set shorter than when the real-time event is not stopped (every 12 hours in the example of FIG. 4). This makes it possible to reduce the impact of a discrepancy in alert information between the device 102 and the status monitoring server 101 caused by not receiving real-time events.

[0086] Third Embodiment In the first and second embodiments, when an abnormal number of event notifications was detected, the transmission of real-time events related to alerts was stopped without being limited to a specific event. That is, "Alert", "Capacity", "Cover" and "Part" were not specified in the real-time event transmission request 4002 of the data collection request 4016 in Fig. 4 or in the real-time event transmission request of the data collection request in Fig. 7. In addition, in cases where an abnormal number of events is notified, this may be due to a failure of a part of the device 102 or a false detection by a specific sensor, and in such cases, the events for which the abnormal number is notified will be limited to specific events. In the third embodiment, taking such cases into consideration, instead of targeting all alert event categories as in the first and second embodiments, anomalies are judged for each event category, and transmission suspension is limited to the target event category, thereby stopping transmission of only the problematic event. In other words, events without abnormalities can be processed normally. In this embodiment, only the differences from the first and second embodiments will be described, and configurations and processes that are not specifically stated are all the same as those in the first and second embodiments.

[0087] <Data Structure> FIG. 8 is a diagram for explaining the data structure of the device information held by the status monitoring server 101 and the data collection request transmitted to the device 102 according to the third embodiment.

[0088] First, the device information will be described. The device information in this embodiment shows an example in which a list 801 of alert information to be the event stop target is added to the device information 4201 shown in FIG. List 801 is a list that holds alert information for which an event is to be stopped, and holds information on alerts for which the number of notifications from device 102 is determined to be abnormal in the process shown in Fig. 9A, which will be described later. Alert information added to list 801 is in a state in which event transmission from device 102 has been stopped, and when it is determined in the process shown in Fig. 9B, which will be described later, that alert information is deleted from list 801.

[0089] Items 802 and 803 in list 801 indicate the alert type and alert target of the alert information determined to be a notification of the number of abnormalities, and hold the values ​​notified in the alert type and alert target of the real-time event (4107 and 4108 in the example of real-time event 4101). Here, assuming a case in which the real-time event 4101 illustrated in Fig. 4 has been notified of the number of abnormalities, an example is shown in which "NeedReplacement" is specified in alert type 802 and "FixingUnit" is specified in alert target 803.

[0090] Next, a data collection request to be sent to the device 102 in the third embodiment will be described. Here, the data collection request in this embodiment will also be described assuming a case where an abnormal number of event data 4101 of the real-time event in Fig. 4 is notified, taking the event "PartStatusChanged" classified into "Parts" as an example.

[0091] Reference numeral 811 denotes a classification of real-time events to be sent as a data collection request 4016 when a real-time event is stopped. In the first and second embodiments, all of "Alert", "Capacity", "Cover" and "Part" are excluded (4017). However, this example shows an example in which only "Parts" is excluded and specified, which is regarded as an abnormality notification.

[0092] A periodic event transmission request 810 specifies "Parts" that is regarded as an abnormality notification in the event transmission target classification 813. Also, an example is shown in which an event firing condition is specified to be every hour, similar to 703 shown in the second embodiment. The periodic event transmission request 4003 815 specifies "Alert", "Capacity", and "Cover" which are classified as alerts other than "Parts" which is regarded as an abnormality notification in the periodic event transmission request 4003. This is the event firing condition every 12 hours.

[0093] <Abnormality / Resolution Detection Processing> The processing of the status monitoring server 101 of the third embodiment will be described below with reference to Figures 9A and 9B. The processing of the flowcharts of Figures 9A and 9B is realized by the CPU 201 of the information processing device constituting the status monitoring server 101 loading a program stored in the HDD 203 or the like into the memory 202 as necessary and executing it.

[0094] First, the real-time event processing of the third embodiment will be described with reference to FIG. 9A. Fig. 9A is a flowchart for explaining real-time event processing of the third embodiment. Unlike the first and second embodiments, it is judged whether or not an abnormal number is to be notified for each event, and an instruction is given to stop sending events that are deemed abnormal. In Fig. 9A, the processes indicated by the same numbers as those in Fig. 6B are the same processes as those in Fig. 6, and the explanation is omitted.

[0095] In this embodiment, if it is determined that event reception from the device 102 is stopped (No in S611), the event processing unit 303 advances the process to S901. The received event data will be described below using the symbols shown in the event data 4101 in Fig. 4. Also, the device information of the device corresponding to the device ID of the received event data will be described using the symbols shown in the device information 4201 in Fig. 8.

[0096] In S901, the event processing unit 303 determines whether the event received from the device 102 is an alert for an event that is being stopped. Specifically, the event processing unit 303 determines whether the alert information 801 of the device information 4201 acquired in S610 contains the same alert type 802 and alert target 803 as the alert type 4107 and alert target 4108 of the received event data 4101.

[0097] If the same alert type and alert target exist, the event processing unit 303 determines that the received event is an alert whose reception has been suspended (Yes in S901), and ends the processing of this flowchart. On the other hand, if the same alert type or alert target does not exist, the event processing unit 303 determines that the received event is not an alert whose reception has been stopped (No in S901), and the event processing unit 303 advances the process to S902.

[0098] In S902, the event processing unit 303 inquires of the event reception history management unit 304 and acquires past event history information having the same device ID 4105, alert type 4107, and alert target 4108 as the received real-time event data 4101.

[0099] Next, in S903, the event processing unit 303 judges whether the number of event histories of the alert of the device in a predetermined period of time exceeds a threshold value based on the event history information acquired in S902. The predetermined period and threshold value are determined in advance, and are not limited to any particular value (for example, a value that can be considered an abnormal notification from the characteristics of the device or event, such as 1000 events in one hour, is specified). The process related to the acquisition of event history information may be configured to acquire all event history information that matches the device ID and alert pair type and the alert target, or may be configured to specify a period and acquire only within that range. Also, only the number of event history information that matches the conditions may be counted and acquired.

[0100] Here, if it is determined that the number of event histories of the alert in question for that device within the predetermined period will not exceed the threshold value (No in S903), the event processing unit 303 advances the process to S616. On the other hand, if it is determined that the number of event histories of the alert for that device within the predetermined period exceeds the threshold (Yes in S903), the event processing unit 303 determines that an abnormal number of events have been received, and proceeds to S904.

[0101] In S904, the event processing unit 303 instructs the device management unit 301 to stop sending the real-time event of the alert for that device. For example, if the event of the alert is an event classified as "Parts", a data collection request such as 4016 in FIG. 8 is sent to the device 102. This stops the real-time event considered to be abnormal (in this example, the real-time event classified as "Parts") and controls so that only other real-time events and periodic events are sent. The device management unit 301 accepts the request from the event processing 303 and sends a data collection request to the device 102.

[0102] In S905, after transmitting the data collection request to the device 102, the device management unit 301 adds the alert type 4107 of the received event data 4101 as alert information to the alert information 801 of the device information 4201 of that device. Also, the device management unit 301 updates the event reception stop flag 4306 to stop "true" and advances the process to S616.

[0103] Next, the periodic event processing of the third embodiment will be described with reference to FIG. 9B. Fig. 9B is a flowchart for explaining periodic event processing according to the third embodiment. In Fig. 9B, the processes indicated with the same numbers as those in Fig. 6C are the same as those in Fig. 6C, and their explanation will be omitted.

[0104] In the third embodiment, if it is determined that event reception from the device 102 is stopped (Yes in S621), in the processes of S910 to S913, it is confirmed whether the stopped event has been resolved based on the received event data. The received event data will be explained below using the reference numerals of event data 4116 in Fig. 4. Also, the device information of the device corresponding to the device ID of the received event data will be explained using the reference numerals of device information 4201 in Fig. 8.

[0105] First, in S910, the event processing unit 303 refers to the alert information 801 in the device information 4201 acquired in S620, and selects one of them as the processing target. Next, in S911, the event processing unit 303 checks whether the alert information to be processed is included in the alert information 801 of the event data 4116 received from the device 102. Specifically, the event processing unit 303 checks whether the alert information to be processed is included in the alert information 801 of the event data 4116 ... by comparing the alert type 4107 and alert target 4108 of the event data 4101 with the alert type 802 and alert target 803 of the alert information to be processed.

[0106] If the alert information of the received event data does not include the alert information of the target alert, the event process unit 303 assumes that the alert to be processed has been resolved (Yes in S911), and proceeds to S912. In S912, the event process unit 303 deletes the alert information to be processed from the alert information 801, and advances the process to S913.

[0107] On the other hand, if the alert information of the received event data includes the alert information of the target alert, the event process unit 303 determines that the alert to be processed has not been resolved (No in S911), and proceeds to S913.

[0108] In S913, the event processing unit 303 checks whether all the alert information has been processed by referring to the alert information 801 of the device information 4201. If there is still unprocessed alert information (No in S913), the event processing unit 303 returns the process to S910 and processes the unprocessed alert information. On the other hand, if all the alert information has been processed (Yes in S913), the event process unit 303 advances the process to S914.

[0109] In S914, the event processing unit 303 checks whether there is any alert information that has been deleted from the alert information that has been deemed to have resolved the abnormality and is currently suspended in S910 to S913. Here, if there is no deleted alert information (No in S914), the event process unit 303 advances the process to S625. On the other hand, if there is deleted alert information (Yes in S914), the event process unit 303 advances the process to S915.

[0110] In S915, the event processing unit 303 instructs the device management unit 301 to start a real-time event of the event for which the abnormality is deemed to have been resolved. Specifically, as in the above example, when it is determined that the abnormality notification of "Parts" has been resolved while the event notification of "Parts" is stopped, a data collection request is transmitted to the device 102, which includes "Parts" in the classification of the transmission target of the real-time event and includes "Parts" in the classification of the transmission target of the periodic event specified as the event firing condition every 12 hours. That is, a data collection request before the detection of the abnormality of "Parts" as shown in 4001 in FIG. 4 is transmitted to the device 102.

[0111] In S916, the device management unit 301 determines whether or not there is no suspended alert information in the alert information 801 of the device information 4201 after transmitting the data collection request to the device 102. If there is no suspended alert information at all (Yes in S916), the device management unit 301 advances the process to S624 and updates the event reception stop flag 4206 of the device information 4201 to "false" indicating that the device is not suspended. On the other hand, if there is at least one piece of suspended alert information (No in S916), the device management unit 301 advances the process to S625 and updates the alert information.

[0112] Through the above process, abnormalities are judged for each event, and the transmission of events that are deemed abnormal is stopped, thereby stopping the transmission of only the problematic event, and events that are not abnormal can be processed normally.

[0113] [Fourth embodiment] In the first to third embodiments, when it is determined that an alert has been resolved by a periodic event, the transmission of a real-time event is immediately resumed. In this configuration, when an alert occurrence and resolution are notified consecutively, the following events may occur. For example, there are cases where the occurrence and resolution of an alert are repeatedly notified depending on the detection accuracy of the sensor of the device 102, such as when the body cover of the device 102 is half-open and the sensor erroneously detects both the cover being open and closed. In such a case, if resolution is detected at the timing of event confirmation during periodic event notification, it is notified as a periodic event, and real-time event notification of the event that was suspended is resumed even though the abnormality notification has not been resolved.

[0114] In the fourth embodiment, taking such a case into consideration, as in the first to third embodiments described above, when it is determined that the problem has been resolved by a periodic event, the transmission of the real-time event is temporarily resumed, and the notification status of the real-time event is verified for a predetermined period of time. If there is no problem as a result, the transmission state is continued, and if it is determined that the abnormality continues, the real-time event is stopped again. In this embodiment, only the differences from the first to third embodiments will be described, and the configurations and processes that are not specifically stated are all the same as those of the first to third embodiments.

[0115] <Data Structure> FIG. 10A is a diagram illustrating the data structure of device information held by the status monitoring server 101 according to the fourth embodiment. FIG. 10A shows an example in which a status attribute indicating that verification is in progress and the start time of verification are added to the alert information 801 of the device information 4201 shown in FIG.

[0116] In the alert information 801 shown in FIG. 10A, two pieces of alert information are defined. In the first example, as in the example of the third embodiment, the alert type 1001 is specified as "NeesReplacement," the alert target 1002 is specified as "FixingUnit," and further, "Stopped" is specified as the status 1003 indicating whether this alert is stopped or being verified. This alert information indicates a state in which the transmission of an alert event indicating the need to replace the fixing unit has been stopped. The second alert has "CoverOpen" specified in alert type 1004, "Body" specified in alert target 1005, "Verifying" specified in status 1006, and 1007 indicating the time when it was determined that the abnormality had been resolved and verification of the abnormality resolution began. This alert information indicates that verification is currently being conducted on whether the body cover has been resolved because it is open.

[0117] 10B is a diagram for explaining the data structure of a data collection request to be transmitted to the device 102 in the fourth embodiment. In this example, in addition to the "Parts" shown in the first to third embodiments, the "Cover" classification is excluded from the targets of real-time event notification.

[0118] Reference numeral 1011 denotes a classification of a real-time event to be transmitted as a data collection request 4016 when a real-time event is stopped. In the first and second embodiments, all of "Alert", "Capacity", "Cover" and "Part" are excluded from the classification as shown in 4017 in Fig. 4, but in this example, "Parts" and "Cover" are excluded from the classification, which are regarded as abnormality notifications.

[0119] Reference numeral 1012 denotes a classification for the transmission of a periodic event specified as a data collection request 4016 when a real-time event is stopped. "Parts" and "Cover" regarded as abnormality notifications are specified as the classification 1012 for the transmission of events. Also, like 703 in Fig. 7 shown in the second embodiment, an example is shown in which an event is specified as an event firing condition every hour.

[0120] In the example 1013, "Alert" and "Capacity" are specified, which are classified as alerts other than "Parts" and "Cover" that are regarded as abnormal notifications, in the transmission request 4003 for the periodic event. This is set as the event firing condition every 12 hours.

[0121] <Abnormality / Resolution Detection Processing> The processing of the status monitoring server 101 of the fourth embodiment will be described below with reference to Figures 11A and 11B. The processing of the flowcharts of Figures 11A and 11B is realized by the CPU 201 of the information processing device constituting the status monitoring server 101 loading a program stored in the HDD 203 or the like into the memory 202 as necessary and executing it.

[0122] First, the real-time event processing of the fourth embodiment will be described with reference to FIG. 11A. Fig. 11A is a flowchart for explaining the real-time event processing of the third embodiment. In this embodiment, when the abnormality resolution is detected by the periodic event, the transmission of the real-time event is started in a verification state, and if there is no problem according to the notification status of the real-time event after that, the transmission of the real-time event is continued, but if there is an abnormality, the transmission of the real-time event is stopped. In Fig. 11A, the processes indicated by the same numbers as Fig. 6 and Fig. 9 are the same processes as Fig. 6 and Fig. 9, and the description will be omitted.

[0123] In the fourth embodiment, when it is determined that the real-time event received from the device 102 is an alert during the event stop (Yes in S901), the event processing unit 303 advances the process to S1101. Hereinafter, the received event data will be described using the reference numerals of the event data 4101 in Fig. 4. Also, the device information of the device corresponding to the device ID of the received event data will be described using the reference numerals of the device information 4201 in Fig. 10A.

[0124] In S1101, the event processing unit 303 judges whether the status of the alert information judged to be stopped in S901 above is under verification. Specifically, the event processing unit 303 refers to the status of the alert information judged to be stopped above, and if the status is "Verifying", it is judged to be under verification, and if otherwise ("Stopped"), it is judged to be not under verification. For example, if the alert information judged to be stopped in S901 above is the first alert information in FIG. 10A, it refers to the status 1003 of the alert information 801 in FIG. 10A and judges that it is not under verification since the status is "Stopped". Also, if the alert information is the second alert information in FIG. 10A, it refers to the status 1006 of the alert information 801 in FIG. 10A and judges that it is under verification since the status is "Verifying".

[0125] If it is determined that verification is not in progress (No in S1101), the event processing unit 303 advances the process to S617. On the other hand, if it is determined that verification is underway (Yes in S1101), the event processing unit 303 advances the process to S1102.

[0126] In S1102, the event processing unit 303 further determines whether a predetermined period of time has passed since the start of verification. Specifically, the event processing unit 303 refers to the verification start time 1007 in the alert information 801 of the device information 4201, and determines whether the difference in time between the current time and the verification start time 1007 exceeds a predetermined time.

[0127] If the predetermined time has not yet elapsed (No in S1102), the event processing unit 303 determines that the elapsed time for verification is insufficient, and proceeds to S617. On the other hand, if the predetermined time has already been exceeded (Yes in S1102), the event processing unit 303 advances the process to S1103.

[0128] In S1103, the event processing unit 303 queries the event reception history management unit 304 and acquires past event history information (after the verification start time 1007) having the same device ID 4105, alert type 4107, and alert target 4108 of the received event data 4101.

[0129] Next, in S1104, the event processing unit 303 judges whether the number of event histories of the device within a predetermined period of time exceeds a threshold value based on the event history information acquired in S1103 above. The predetermined period and threshold value are determined in advance for use during verification, and are not limited to any particular value (for example, a value that can be considered an abnormal notification from the characteristics of the device or event, such as 100 events within 5 minutes, is specified). The process related to acquisition of event history information may be configured to acquire all event history information that matches the device ID and alert pair type and the alert target, or may be configured to specify a period and acquire only within that range. Also, only the number of event history information that matches the conditions may be counted and acquired.

[0130] If it is determined that the number of event histories of the device within the predetermined period has not exceeded the threshold (No in S1104), the event processing unit 303 advances the process to S1106 and updates the device information. In this case, in S1106, the device management unit 301 deletes the alert information determined to be suspended in the above S901 from the alert information 801, and advances the process to S617.

[0131] On the other hand, if it is determined that the number of event histories of the device within the predetermined period has exceeded the threshold value (Yes in S1104), the event processing unit 303 determines that an abnormal number of events have been received, and proceeds to S1105.

[0132] In S1105, the event processing unit 303 instructs the device management unit 301 to stop the real-time event. For example, if the "Cover" event is determined to be an abnormality notification, a transmission request is sent to the device 102 that does not include "Cover" in the classification of the transmission target of the real-time event, but includes "Cover" in the classification of the transmission target of the periodic event specified as the hourly event firing condition, i.e., a data collection request such as 4016 in FIG. 10B. This stops the real-time event that is considered to be an abnormality, and controls so that only the periodic event is sent. The device management unit 301 accepts the request from the event processing 303 and sends a data collection request to the device 102.

[0133] When proceeding to S1106 after transmitting the data collection request to the device 102 in S1105 above, the device management unit 301 updates the status of the alert information determined to be stopped in S901 above to "Stopped" and proceeds to S617. For example, if the alert information determined to be stopped in S901 above is the second alert information in Fig. 10A, the status 1006 of the alert information 801 in Fig. 10A is updated to "Stopped".

[0134] Next, the periodic event processing of the fourth embodiment will be described with reference to FIG. 11B. Fig. 11B is a flowchart for explaining periodic event processing according to the fourth embodiment. In Fig. 11B, the processes indicated by the same numbers as in Fig. 6 and Fig. 9 are the same processes as in Fig. 6 and Fig. 9, and the explanation thereof will be omitted.

[0135] In the fourth embodiment, if it is determined in S911 that the stopped alert to be processed has been resolved (Yes in S911), the event processing unit 303 advances the process to S1111. Hereinafter, the received event data will be described using the reference numerals of the event data 4116 in Fig. 4. Also, the device information of the device corresponding to the device ID of the received event data will be described using the reference numerals of the device information 4201 in Fig. 10A. In S1111, the event processing unit 303 updates the status of the alert information to be processed to "Verifying", indicating that verification is underway, and proceeds to S913. For example, if the alert information to be processed is the first alert information in Fig. 10A, the status 1003 of the alert information 801 in Fig. 10A is updated to "Verifying".

[0136] Furthermore, in S1112, the event processing unit 303 checks whether there is any alert information that has been deemed to have resolved the abnormality in S910 to S913 and has its status updated to "Verifying." Here, if there is no alert information that has been updated to the "Verifying" status (No in S1112), the event processing unit 303 advances the process to S625. On the other hand, if there is alert information whose status has been updated to "Verifying" (Yes in S1112), the event processing unit 303 advances the process to S1103.

[0137] In S1113, the event processing unit 303 instructs the device management unit 301 to start a real-time event for the event for which the abnormality is deemed to have been resolved. As in the above example, if it is determined that the abnormality notification for "Cover" has been resolved while the event notification for "Cover" is stopped, a transmission request that includes "Cover" in the classification of the transmission target for the real-time event and includes "Cover" in the classification of the transmission target for the periodic event specified as the event firing condition every 12 hours, for example, a data collection request such as 4016 in FIG. 8B, is transmitted to the device 102.

[0138] By the above processing, when a real-time event is resumed, the notification status of the real-time event is verified for a specified period of time, and if there is no problem, the event is resumed, but if it is determined that the abnormality continues, the real-time event is not resumed.

[0139] Fifth embodiment Since only periodic events are handled while transmission of real-time events is stopped, there is a possibility that a difference may occur in the display of the UI provided by the device 102 and the UI provided by the status monitoring server 101. In the fifth embodiment, taking such a case into consideration, an example is shown in which when transmission of real-time events is stopped, the UI of the status monitoring server 101 is displayed so that the user can recognize this. In this embodiment, only the differences from the first to fourth embodiments will be described, and the configurations and processes that are not specifically stated are all the same as those of the first to fourth embodiments.

[0140] <ui> FIG. 12 shows an example of the UI of the status monitoring server 101 of the fifth embodiment, and similarly to FIG. 5, a message indicating that transmission of real-time events has been stopped is displayed. In the fifth embodiment, the error message 1201 displays a message indicating that a user action is required. The message 1201 further displays that the transmission of real-time events is stopped, and further displays the possibility that there is a difference between the status displayed on the device 102 and that on the device itself. The message displayed in the error message 1201 is displayed when the device information 4201 shown in FIG. 10 is obtained from the status monitoring server 101 by an API (not shown) and the event reception stop flag 4206 of the device information 4201 is "true."

[0141] As described above, according to the fifth embodiment, it is possible to easily make the user aware that there may be a difference in the status display between the UI provided by the device 102 and the UI provided by the status monitoring server 101 because transmission of real-time events is stopped.

[0142] In systems that are connected to many clients, such as IoT systems, it is common to configure the server to increase or decrease resources depending on the load of connected clients and the amount of data being sent. In such a configuration, if a client sends abnormal data, unnecessary costs are incurred because resources are consumed in proportion to the amount of data sent. There is also a configuration in which the number of simultaneous processes is determined in advance based on the expected number of clients and the amount of data received, and the received data is buffered and processed in order without exceeding the number of simultaneous processes. In such a configuration, a large amount of data from a client that sends abnormal data is buffered, causing delays in processing for other clients. Conventional technology does not control the timing of notifications (real-time events or periodic events), but stops sending data from the client when it detects an abnormality until the client side determines that the problem has been resolved, meaning that no events can be processed during that time.In addition, because control is performed between the server and the client, it is not possible to realize control that depends on the purpose of the application service that handles the client data. In contrast, in each of the above-mentioned embodiments, the status monitoring server 101 detects and resolves an amount of data transmission (abnormal data transmission) that exceeds expectations by a client terminal such as the device 102, and instructs the client to control transmission while taking into consideration the notification timing (real time or regular). As a result, when an abnormal data transmission occurs from a client terminal, it is possible to flexibly avoid processing delays on the server side due to the abnormal data transmission while continuing monitoring through regular notifications from the client terminal. It is also possible to avoid unnecessary costs on the server side. Therefore, even when an abnormality notification is generated by a device, the impact on server costs and processing can be reduced, and even when a device event is stopped, device monitoring can continue through periodic events.

[0143] It goes without saying that the configurations and contents of the various data described above are not limited to those described above, and the data may have various configurations and contents depending on the application and purpose. Although one embodiment has been described above, the present invention can be embodied, for example, as a system, an apparatus, a method, a program, a storage medium, etc. Specifically, the present invention may be applied to a system composed of multiple devices, or may be applied to an apparatus composed of a single device. Furthermore, any combination of the above-described embodiments is also included in the present invention.

[0144] (Other embodiments) The present invention can also be realized by a process in which a program for implementing one or more of the functions of the above-described embodiments is supplied to a system or device via a network or a storage medium, and one or more processors in a 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 implements one or more of the functions. Furthermore, the present invention may be applied to a system made up of a plurality of devices, or to an apparatus made up of a single device. The present invention is not limited to the above-mentioned embodiment, and various modifications (including organic combinations of the embodiments) are possible based on the spirit of the present invention, and are not excluded from the scope of the present invention. In other words, the present invention includes all configurations that combine the above-mentioned embodiments and their modifications.

[0145] The disclosure of this embodiment includes the following configurations and methods. (Configuration 1) A system having one or more client terminals and a service for receiving notification information from the client terminals, The client terminal includes: a transmitting means capable of transmitting first notification information for transmitting information on an event occurring in the client terminal to the service at the timing of the occurrence in response to a request from the service, and transmitting second notification information for periodically checking whether an event has occurred in the client terminal and transmitting the information to the service, The service is a control means for performing a first control to stop transmission of the first notification information and transmit a first request to the client terminal to transmit the second notification information when the number of the first notification information received from the same client terminal within a first period exceeds a first threshold value; When the control means determines that the abnormality has been resolved in the client terminal that has stopped transmitting the first notification information based on the second notification information received from the client terminal, the control means performs a second control to transmit a second request to the client terminal to resume transmitting the first notification information. A system characterized by: (Configuration 2) The client terminal transmits the second notification information at an interval specified by a request from the service, The system described in configuration 1, wherein the control means specifies, in the first request, as the transmission interval of the second notification information, a second interval that is shorter than a first interval, which is the transmission interval of the second notification information when transmission of the first notification information is not stopped. (Configuration 3) when the number of the first notification information related to the same event received from the same client terminal within the first period exceeds the first threshold, the control means transmits the first request to the client terminal to stop transmission of the first notification information related to the event; The system according to any one of configurations 1 to 3, further characterized in that when the control means determines that an abnormality related to any of the events has been resolved in a client terminal that has stopped transmitting the first notification information related to at least one event based on the second notification information received from the client terminal, the control means transmits the second request to the client terminal to resume transmitting the first notification information related to the event. (Configuration 4) The control means performs control in the second control so as to remove the client terminal that has resumed transmission of the first notification information from the target of the first control; The system according to any one of configurations 1 to 4, further characterized in that, for a client terminal that is not subject to the first control, when the number of the first notification information received from the client terminal exceeds a second threshold within a third period after the resumption of transmission of the first notification information, the control means sends the first request to the client terminal to stop transmitting the first notification information. (Configuration 5) The system described in configuration 4, characterized in that the control means subjects a client terminal that has resumed transmitting the first notification information to the first control if the number of pieces of first notification information received from the client terminal within the third period does not exceed the second threshold. (Configuration 6) The service is providing means for providing information of the client terminal; The system according to any one of configurations 1 to 5, wherein the providing means provides information to the effect that, for a client terminal that has stopped transmitting the first notice information, that fact. (Method 1) A method for controlling a system having one or more client terminals and a service for receiving notification information from the client terminals, comprising: Executed by the client terminal, a step of controlling transmission of first notification information for transmitting information on an event occurring in the client terminal to the service at the timing of the event occurrence in response to a request from the service, and transmission of second notification information for periodically checking whether an event has occurred by the client terminal and transmitting the information to the service; Executed by the service, performing a first control step of, when the number of the first notification information received from a same client terminal within a first period exceeds a first threshold, stopping transmission of the first notification information and transmitting a first request to the client terminal to transmit the second notification information; performing a second control of transmitting a second request to the client terminal to resume transmission of the first notification information when it is determined that the abnormality has been resolved in the client terminal based on the second notification information received from the client terminal that has stopped transmission of the first notification information by the first control; 13. A method for controlling a system comprising:< / ui> < / ui>

Claims

1. A system having one or more client terminals and a service that receives notification information from the client terminals, The client terminal a transmission means for transmitting a first notification that transmits information about an event that has occurred in the client terminal to the service at the timing of the event occurrence, and a second notification that transmits information about an event that should be transmitted to the service in accordance with a result of checking whether or not a regular event has occurred in the client terminal; The service is a control means for performing a first control of transmitting, to the client terminal, a first request for transmitting the second notification while stopping transmission of the first notification when the number of the first notifications received from the client terminal within a first period exceeds a first threshold value; The control means further performs second control to transmit, to the client terminal, a second request to resume transmission of the first notification, when it is determined that the abnormality has been resolved in the client terminal based on the second notification received from the client terminal that has stopped transmission of the first notification under the first control. A system characterized by:

2. the client terminal transmits the second notification to the service at specific intervals; 2. The system according to claim 1, wherein the control means specifies in the first request as the specific interval for the second notification a second interval that is shorter than a first interval that is the transmission interval for the second notification before transmission of the first notification is stopped.

3. when the number of first notifications regarding the same event received from the same client terminal within the first period exceeds the first threshold, the control means transmits the first request to the client terminal to stop transmitting the first notifications regarding the event; The system described in claim 1 or 2, further characterized in that when the control means determines based on the second notification received from the client terminal that has stopped sending the first notification regarding at least one event that an abnormality regarding any of the events has been resolved at the client terminal, the control means sends the second request to the client terminal to resume sending the first notification regarding the event.

4. the control means controls the client terminal that has resumed transmission of the first notification in the second control so as to exclude the client terminal from the target of the first control; The system described in claim 1 or 2 is further characterized in that, for a client terminal that is not subject to the first control, if the number of first notifications received from the client terminal exceeds a second threshold within a third period after the resumption of transmission of the first notification, the control means sends the first request to the client terminal to stop sending the first notification.

5. The service is providing means for providing information about the client terminal; 3. The system according to claim 1, wherein the providing unit provides information to the client terminal that has stopped transmitting the first notification to that effect.

6. A control method for a system having one or more client terminals and a service that receives notification information from the client terminals, comprising: Executed by the client terminal, a step of transmitting a first notification that transmits information about an event that has occurred in the client terminal to the service at the timing of the event occurrence, and transmitting a second notification that transmits information about the event that should be transmitted to the service in accordance with a result of checking whether or not a periodic event has occurred in the client terminal; Executed by the service, performing a first control step of, when the number of the first notifications received from the client terminal within a first period exceeds a first threshold, stopping transmission of the first notifications and transmitting a first request to the client terminal to transmit the second notification; a step of performing a second control by the first control to transmit, when it is determined based on the second notification received from the client terminal that has stopped transmitting the first notification by the first control, that the abnormality has been resolved in the client terminal, a second request to resume transmitting the first notification to the client terminal; A method for controlling a system, comprising:

Images