Network device and method for controlling the network device

Abstract

To transmit no data that is not to be collected to each cloud service when transmitting data to a plurality of cloud services.SOLUTION: Included are a notification setting management unit 523 that manages a notification setting of an event received from a client application 540a that transmits data to a management server 110a; an event collection unit 511 for collecting data in a client 120 in accordance with the notification setting, and an event storage unit 512 for storing collected data in a message buffer 520a. When a notification setting of an event is received from a client application 540b that transmits data to the management server 110b, the event collection unit 511 collects the target data in accordance with conditions related to data in which the conditions collected in each notification setting match, and the event storage unit 512 stores the collected data in the message buffer 520a and a message buffer 520.SELECTED DRAWING: Figure 5

Description

[Technical field]

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

[0002] There is a known system in which a large number of various event logs are sent from operating devices to a server that manages event logs via the Internet and stored on the server. The server uses the accumulated event logs and applications on the server to analyze various changes in the device's status and quickly responds to events that occur, such as notifying the replacement of consumables and arranging maintenance work. The server also manages user operation history, analyzes usage status, and checks whether the device is being used correctly. For this reason, it is necessary to send events that occur on the device in the form of an event log that is easy for the server-side application to handle.

[0003] There are also configurations in which multiple cloud services are launched for each function, such as a cloud service that mainly handles device maintenance and another that manages user usage, and one device is connected to multiple cloud services at the same time. When connected to multiple cloud services, the device needs to reliably send events required for the operation of each cloud service. At the same time, strict management is also required to ensure that data outside the contract is not sent. However, it is not efficient to run multiple event data collection mechanisms corresponding to each cloud service on the device.

[0004] Patent Document 1 discloses a method in which one event collection cloud receives data collection requests from multiple services and integrates them as a single collection request to a device. This enables a device to send data in response to requests from multiple services by simply operating one event data collection mechanism. [Prior art documents] [Patent documents]

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

[0006] However, as disclosed in Patent Document 1, the method of merging requests on the cloud can be used only when there is one event collection cloud, and the case where there are multiple event collection clouds is not assumed. When there are multiple cloud systems that collect information, it is necessary to add a transmission client application for the other cloud system on the side of the device that is the information transmission source. Even when multiple transmission client applications are executed, the information collection operation in the device that is the transmission target should be unified to improve efficiency.

[0007] In addition, when transmitting device data to a cloud service, the data that can be transmitted may be strictly defined based on a contract, etc. Furthermore, depending on the contract, collected information may not be disclosed to another cloud system. Therefore, it is necessary to control so that data not covered by the contract is not transmitted from the device to the cloud service, and further, it is necessary to guarantee isolated functionality in which multiple transmission client applications cannot refer to each other's transmission targets.

[0008] An object of the present invention is to, when transmitting data to a plurality of cloud services, prevent data that is not to be collected from each cloud service from being transmitted to each cloud service. [Means for solving the problem]

[0009] In order to solve the above problems, a network device of the present invention is a network device in which a first client application for transmitting data to a first system via a network is executed, the network device having a management means for managing first definition information that is received from the first client application and defines the type of data to be collected in the network device and the conditions under which the data is collected, a collection means for collecting data in the network device according to the first definition information, and a storage means for storing the data collected by the collection means in a first dedicated area reserved for the first client application. The first client application transmits data acquired from the first dedicated area to the first system, and when a second client application for transmitting data to a second system via a network is added to the network device and second definition information is received from the second client application that defines the type of data to be collected in the network device and the conditions under which the data is collected, the collection means collects target data according to the conditions for data that match the conditions for collection in the first definition information and the second definition information. The storage means stores the target data collected at one time by the collection means in accordance with the conditions in the first dedicated area and in a second dedicated area secured for the second client application. Effect of the Invention

[0010] According to the present invention, when data is transmitted to a plurality of cloud services, data that is not the target of collection can be prevented from being transmitted to each cloud service. [Brief description of the drawings]

[0011] [Figure 1] FIG. 1 is a diagram showing the overall configuration of a system. [Diagram 2] FIG. 2 is a diagram illustrating a configuration of a management server. [Diagram 3] FIG. 2 is a diagram illustrating an outline of a configuration of a client. [Figure 4] FIG. 2 is a diagram illustrating a configuration of an information processing controller unit of a client. [Diagram 5] FIG. 2 is a diagram illustrating a software configuration of a client. [Figure 6] 5 is a flowchart showing an event collection and storage process in the first embodiment. [Figure 7] 13 is a flowchart showing a process for acquiring and updating an event notification setting. [Figure 8] FIG. 13 is a diagram showing an example of a collection file. [Figure 9] 13 is a flowchart showing an event collection and storage process in the second embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0012] (First embodiment) 1 is a diagram showing the overall configuration of a system for collecting data from network devices connected via a network in the present invention. A plurality of management servers 110 (management servers 110a and 110b) and clients 120 (clients 120a and 120b) are connected to a network 100. The management servers 110a and 110b each belong to a different system (first system 111a, second system 111b) that acquires data collected from the client 120 and uses the acquired data.

[0013] The client 120 is a network device connected to the network 100 and capable of communication, and is, for example, an information processing device such as a PC, a tablet, a multifunction device, or a camera. In this embodiment, a multifunction device that realizes multiple types of functions such as copying and faxing will be described as an example of the client 120. The client 120 in this embodiment has a function of transmitting data collected within the device to the management server 110 via the network 100. The client 120 transmits events within the device to the management server 110 in the form of events. The events transmitted to the management server 110 include, for example, a history of function execution, a history indicating the operating status of the device such as transition to and return from a power saving state, and a history of transition to and return from an abnormal state such as an error occurrence.

[0014] The management server 110 is an information processing device that collects events from devices on the network, such as the client 120, via the network 100. The collected events are stored in a storage in the management server 110. The event information accumulated in the storage is used for analyzing the operating status of the devices and providing services according to the analysis results. Note that the management server 110 may be realized by a server device, or a virtual machine (cloud service) that uses resources provided by a data center including a server device.

[0015] 2 is a diagram showing the configuration of the management server 110 (management server 110a, management server 110b). The management server 110 comprises a controller unit 200, an operation unit 210, and a display unit 220. The controller unit 200 comprises a CPU 202, a ROM 203, a HDD 204, an operation unit I / F 205, a display unit I / F 206, and a communication I / F 207. The elements in the controller unit 200 are connected via a system bus 208, and exchange data with each other.

[0016] A CPU 201 (Central Processing Unit) controls the entire management server 110. The CPU 201 starts an OS (Operating System) by a boot program stored in a ROM 202. The CPU 201 also executes application programs stored in a HDD 204 on this OS, thereby executing various processes.

[0017] The ROM (Read Only Memory) 202 is a non-volatile storage area, and stores various data such as the basic control program of the management server 110, the OS (Operating System), and applications. The basic control program includes a boot program. The RAM (Random Access Memory) 202 is a volatile storage area, and is used as a temporary storage area and a work area when the CPU 201 performs various processes. The CPU 201 loads various control programs stored in the ROM 202 and the HDD 204 into the RAM 203.

[0018] The HDD (Hard Disk Drive) 204 is a non-volatile large-capacity storage unit. The HDD 204 stores application programs, setting values, data such as events collected from devices on the network 100, and the like. Note that, although the HDD 204 has been described as an example of a storage unit in this embodiment, the present invention is not limited to this, and may be a solid state drive (SSD) or a device that can read / write data by loading an external medium such as a memory card.

[0019] The operation unit 210 is, for example, a pointing device (for example, a mouse, a touch panel, etc.), an operation button, a keyboard, etc., and accepts operations, inputs, and instructions from a user. The operation unit I / F 205 is an interface with the operation unit 210, and sends information input by the user via the operation unit 210 to the CPU 201. The display unit 220 is, for example, a liquid crystal display or a touch panel, etc., and displays images and various data. The display unit I / F 206 outputs data to be displayed on the display unit 220 to the display unit 220. The operation unit 210 and the display unit 220 may be integrally configured as a touch panel, etc.

[0020] The communication I / F 207 is connected to the network 100, and inputs and outputs information to and from each device on the network 100 via the network 100. Note that the configuration of the management server 110 described using Fig. 2 is an example in which the management server 110 is realized by an information processing device such as a general computer, and is not limited to this. For example, the management server 110 does not need to include the operation unit 210, the display unit 220, and the interfaces corresponding to them.

[0021] 3 is a diagram for explaining an outline of the configuration of the client 120 (client 120a, client 120b). The client 120 is a multifunction peripheral including an information processing controller unit 301, a printer controller unit 302, a scanner controller unit 303, a printer 304, a scanner 305, and an operation unit 306. The information processing controller unit 301 is a controller that supervises information processing control related to the operation of the client 120. A detailed description of the information processing controller unit 301 will be given later with reference to FIG. 4.

[0022] An operation unit 306, a printer controller unit 302, and a scanner controller unit 303 are connected to the information processing controller unit 301. The operation unit 306 includes a display device and an input device, and displays various information to the user and accepts operations, inputs, and instructions from the user. The display device is, for example, a liquid crystal display or a touch panel. The input device is, for example, a pointing device (for example, a touch pad, a touch panel, etc.), an operation button, a keyboard, etc. In this embodiment, a case where the client 120 includes a touch panel as the operation unit 306 will be described as an example. By associating input coordinates and display coordinates on the touch panel, it is possible to configure a GUI that makes it appear as if the user can directly operate a screen displayed on the touch panel.

[0023] The printer 304 is an image output device that forms an image according to print data received from outside and outputs it on paper, or optically reads an original image set in the scanner 305 and outputs it on paper. The printer controller unit 302 controls the printer 304. The scanner 305 is an image input device that optically reads an original and generates an electronic file (scan data) based on the scan. The scanner controller unit 303 controls the scanner 305.

[0024] 4 is a diagram showing the configuration of the information processing controller unit 301 of the client 120. The information processing controller unit 301 has a CPU 401, a ROM 402, a RAM 403, a HDD 404, a communication I / F 405, an operation unit I / F 406, an image processing unit 407, a device controller I / F 408, and a power management unit 409. The elements in the information processing controller unit 301 are connected via a system bus 410 and exchange data with each other.

[0025] The CPU 401 controls the entire client 120. The CPU 401 starts the OS by a boot program stored in the ROM 402, and executes various processes described later by executing application programs stored in the HDD 404 on the OS. The ROM 402 is a non-volatile storage area, and stores various data such as a basic control program of the client 120, an OS (Operating System), and applications. The basic control program includes a boot program. The RAM 402 is a volatile storage area, and is used as a temporary storage area and a work area when the CPU 401 performs various processes. The RAM 403 provides an image memory area for temporarily storing image data. The CPU 401 loads various control programs stored in the ROM 402 and the HDD 404 in the RAM 403. That is, the CPU 401 functions as each processing unit that executes processes described later by executing a program stored in a readable storage medium.

[0026] The HDD 404 is a non-volatile large-capacity storage unit. Application programs, image data, various setting values, history, etc. are stored in the HDD 204. In the present embodiment, the HDD 404 is described as an example of a storage unit, but the present invention is not limited to this, and may be an SSD or a device that can read / write data by loading an external medium such as a memory card.

[0027] The communication I / F 405 is connected to the network 100, and inputs and outputs information via the network 100 to and from each device on the network 100, for example, the management server 110. The operation unit I / F 406 is an interface with the operation unit 306. The operation unit I / F 406 sends information input by a user via the operation unit 306 to the CPU 401, and also outputs data to be displayed on the operation unit 306 to the operation unit 306.

[0028] The image processing unit 407 performs various image processing on the image to be output to the printer 304 and the image acquired by the scanner 305. Examples of various image processing include image rotation, image compression, resolution conversion, color space conversion, and gradation conversion. The device controller I / F 408 connects to the printer controller unit 302 and the scanner controller unit 303, and controls input and output of data between the printer controller unit 302 and the scanner controller unit 303 and the CPU 401. The device controller I / F 408 also performs synchronous / asynchronous conversion of image data. The power management unit 409 performs power control of the client 120. As a specific example, the power management unit 409 controls on / off, as well as transition to a power saving state other than the normal power supply state and return to the normal state.

[0029] 5 is a diagram showing the software configuration of the client 120. The CPU 201 loads into the RAM 403 and executes programs stored in the ROM 402 and HDD 404 to function as each processing unit. In the client 120, software that realizes the functions of a general information processing device using a network or memory storage, as well as software that realizes the functions of a multifunction device such as scanning and printing, runs.

[0030] The client 120 has a user interface 501, a function application 502, a job control unit 503, a power control unit 504, an error control unit 505, a history / settings storage unit 506, a counter management unit 507, a configuration information management unit 508, and a timer notification unit 509. Furthermore, the client 120 has an event collection unit 510, a message buffer 520, a client application 540, a notification setting management unit 523, and a notification setting storage unit 521.

[0031] The client application 540 transmits data to a system that collects operation information and the like of the client 120. Therefore, a client application 540 is added to the client 120 for each system that collects operation information and the like of the client 120. Also, a message buffer 520 is provided for each client application 540. In this embodiment, an example will be described in which the client 120 is managed by two systems (management server 110a and management server 110b) that collect data within the client. Therefore, in this embodiment, the client 120 is provided with two client applications 540 and two message buffers 520 corresponding to each system. As a specific example, a client application 540a and a message buffer 520a, and a client application 540b and a message buffer 520b are provided.

[0032] The user interface 501 displays a screen operated by the user on the operation unit 306, and transmits the user's operation via the operation unit 306 to the software. The function application 502 operates the application functions of the multifunction device. The multifunction device has a plurality of application functions such as copy, print, and email transmission, and a function application 502 is provided for each application function. In other words, the client 120 has a plurality of function applications 502. The function application 502 operates the application functions of the multifunction device in response to a user's instruction via the operation unit 306, data reception via the communication I / F 405, or the like.

[0033] A job control unit 503 receives instructions from the functional application 502 and controls the printer controller unit 302 and the scanner controller unit 303 to execute printing and scanning. A power control unit 504 controls the power management unit 409 in conjunction with the state of the software in the client 120. As a specific example, the power control unit 504 controls the transition between a normal power supply state and a power saving state according to the state of the software.

[0034] The error control unit 505 detects an abnormal state that occurs in the client 120, such as the job control unit 503, the printer controller unit 302, or the scanner controller unit 303. In addition, the error control unit 505 instructs the stopping or degenerate operation of the application or the entire system according to the abnormal state, thereby controlling the operating status of the client 120. The history and setting storage unit 506 manages non-volatile information in the client 120. As a specific example, the history and setting storage unit 506 stores settings required for controlling the multifunction device and jobs, and summarizes and stores the user's operation history, job execution results, and error occurrences. In addition, the history and setting storage unit 506 also stores log information that is left for analysis and debugging purposes when a system malfunction occurs. The substance of the non-volatile data managed by the history and setting storage unit 506 is stored in the HDD 404.

[0035] A counter management unit 507 manages counts of the number of scans and prints generated within the device, counts measuring the degree of wear for each consumable part, and part lifespan information calculated from the counts. The entities of non-volatile data such as the counts and lifespan information managed by the counter management unit 507 are stored in the HDD 404. A configuration information management unit 508 manages the configuration of the hardware and software constituting the client 120. As the hardware and software constituting the client 120, for example, the configuration information management unit 508 manages external accessories such as a paper feed cassette, a paper output tray, and a finisher, firmware versions, a list of installed applications, and the like.

[0036] The event collection unit 510 collects data such as the operating status of the client 120 to be sent to the management server 110, and saves it in the form of an event. The event collection unit 510 has an event collection unit 511 and an event storage unit 512. The event collection unit 511 monitors events in the client 120, and collects target data according to conditions specified by the client application 540. The event storage unit 512 normalizes the data in the client 120 collected by the event collection unit 511 into the form of an event and stores it in the message buffer 520 to send it to the management server 110.

[0037] The collection of data in the client 120 by the event collection unit 511 will be described. The event collection unit 511 collects data in the client 120 according to the notification settings of the event stored in the notification setting storage unit 521 described later. For example, the event collection unit 511 monitors state transitions that occur in modules that spontaneously issue events (for example, the user interface 501 to the history and setting storage unit 506), and collects state transition data in real time. In addition, in order to periodically collect the operating status of the client 120, the event collection unit 511 requests the timer notification unit 509 to fire a timer after a specified time has elapsed. After the specified time has elapsed, the event collection unit 511, having received a notification from the timer notification unit 509, uses the timer firing as a trigger to collect the data to be periodically collected. Here, the data to be periodically collected is data to be periodically transmitted from the client 120 to the management server 110, and includes counters managed by the counter management unit 507 and configuration information managed by the configuration information management unit 508.

[0038] The event storage unit 512 normalizes the data in the client 120 collected by the event collection unit 511 into an event format, and stores the event in a message buffer for the client application that instructed the collection of the data. The normalization is performed using a general-purpose format such as JSON, for example, to make the collected data into a format for transmission to the management server 110. In addition to basic information such as the event name, the occurrence time, and the serial number of the information processing device, various additional information is added to the event depending on the type of the event. The event collection unit 511 collects the added information from the state of each module in the client 120, the contents stored in the non-volatile area, and the like. The data normalized into the event format is stored in the message buffer 520.

[0039] Message buffer 520 holds events normalized by event storage unit 512. Message buffer 520 is on non-volatile HDD 404, and is provided for each client application 540. Message buffer 520a is a dedicated area (first dedicated area) reserved for client application 540a. Similarly, message buffer 520b is a dedicated area (second dedicated area) reserved for client application 540b. Therefore, client application 540a cannot access message buffer 520b, and client application 540b cannot access message buffer 520a.

[0040] The client application 540 reads data collected from within the client 120 (within the network device) and stored in the message buffer 520, and sends it to the management server 110. There is a one-to-one correspondence between the client application 540 and the connected management server 110. Therefore, when connecting to multiple management servers 110, there are multiple client applications 540. The client 120 has a client application 540a for transmitting data to the management server 110a of the first system 111a, and a client application 540b for transmitting data to the management server 110b of the second system 111b.

[0041] The client application 540 includes an event sending unit 530, a network communication unit 531, and a notification setting acquisition unit 532. The event sending unit 530 acquires an event stored in the message buffer 520 and transmits it to the management server 110 corresponding to the client application 540. As a specific example, the event sending unit 530 grasps that an event has been issued by detecting writing to a dedicated message buffer 520 prepared for each client application. The event sending unit 530 that detects the issuance of an event acquires the event from the message buffer 520 and transmits the event to the management server 110 via the communication I / F 405 and the network communication unit 531. The event sending unit 530a transmits the event acquired from the message buffer 520a, which is a dedicated area for the client application 540a, to the management server 110a. Similarly, the event sending unit 530b transmits the event acquired from the message buffer 520b, which is a dedicated area for the client application 540b, to the management server 110b.

[0042] The notification setting acquisition unit 532 receives an event notification setting from the management server 110 corresponding to the client application 540 via the network communication unit 531. Here, the event notification setting is a content indicating definition information of which data in the device managed by the management server 110 is to be sent to the management server 110 as an event and at what timing. The event notification setting is acquired as a collection file. A detailed description of the collection file will be given later with reference to FIG. 8. The notification setting acquisition unit 532a receives the event notification setting from the management server 110a. Similarly, the notification setting acquisition unit 532b receives the event notification setting from the management server 110b. Then, the notification setting acquisition unit 532a and the notification setting acquisition unit 532b send the received event notification setting to the notification setting management unit 523.

[0043] Notification setting management unit 523 acquires and manages event notification settings from notification setting acquisition unit 532 of client application 540. When event notification settings are acquired from multiple client applications 540, notification setting management unit 523 integrates and manages the notification settings of the multiple events. Notification setting management unit 523 also stores the acquired event notification settings in notification setting retention unit 521. The acquisition and management of event notification settings will be described in detail later with reference to Figs. 7 and 8.

[0044] The notification setting storage unit 521 stores the notification settings of the event. The notification setting storage unit 521 is located on the non-volatile HDD 404, and the notification settings of the event are saved in the form of a file. The notification setting storage unit 521 is stored in the form of a file on the HDD 404. The event collection unit 510 collects events and stores them in the message buffer 520 in accordance with the notification settings of the events stored in the notification setting storage unit 521.

[0045] Notification setting storage unit 521 records, as event notification settings, the type of data to be collected from client 120 and the conditions for collection. Notification setting storage unit 521 also records in which message buffer 520 corresponding to which client application 540 the collected events are to be saved. As a specific example, message buffer 520a corresponding to client application 540a is specified as the save destination for events collected in accordance with the event notification settings acquired from client application 540a. Similarly, message buffer 520b corresponding to client application 540b is specified as the save destination for events collected in accordance with the event notification settings acquired from client application 540b.

[0046] The event storage unit 512 determines the message buffer 520 to which the event collected by the event collection unit 511 is to be saved according to the information on the event saving destination saved in the notification setting holding unit 521, and saves the event. As a specific example, the event storage unit 512 determines the event saving destination to be either the message buffer 520a or the message buffer 520b, or both the message buffer 520a and the message buffer 520b, according to the information on the event saving destination. By allocating the event saving destination in this way, for example, an event requested by another client application 540b but not requested by the client application 540a is not written in the message buffer 520a. That is, only events to be sent to the management server 110a are saved in the message buffer 520a, and only events to be sent to the management server 110b are saved in the message buffer 520b. Therefore, data outside the contract is not sent to each management server 110.

[0047] Next, the details of the event notification settings will be described. Table 1 shows the relationship between the event notification settings and the events. [Table 1] The names written in the "Event" column are units (hereinafter referred to as "events") that are normalized by giving a name to state transitions that occur within a device. In other words, these events are the units that the event collection unit 510 collects from within the device and stores in the message buffer 520, and are the units that are sent to the management server 110. For example, JobStarted is an event that means that a job such as copying or printing has started to be executed. ErrorOccurred is an event that means that some kind of abnormal condition has occurred within the device. The "Description" column provides an explanation of each event.

[0048] The names written in the "Collection" column are units in which multiple events are grouped together based on the semantic unit of their actions (hereinafter, referred to as collections). In this embodiment, the setting for enabling transmission to the management server 110 is made on a collection basis. Therefore, in the event notification settings held by the notification setting holding unit 521, the type of data to be collected within the client 120 is set on a collection basis. For example, when an Alarm collection is specified in the event notification settings, ErrorOccurred and AlarmOccurred events will be sent to the management server 110. In other words, when an Alarm collection is specified, ErrorOccurred and AlarmOccurred events become the targets of collection by the event collection unit 511.

[0049] The "Periodic Transmission" column defines whether the event is a snapshot event that is sent periodically for each collection. An event with a circle in the "Periodic Transmission" column is a snapshot event that is sent periodically by activation, a timer, or the like. When enabling periodic transmission, the notification setting management unit 523 sets the transmission interval of the collection event for which periodic transmission is enabled, and the notification setting storage unit 521 stores the event as part of the notification setting of the event. For example, when periodic transmission of a Basic collection is specified, a BasicInfoSnapshotted event having basic information such as the model name, installation location, and firmware version as attributes is periodically transmitted to the management server 110 at the specified transmission interval. Similarly, when periodic transmission of a Counter collection is specified, CounterSnapshotted, PartsCounterSnapshotted, and the like are periodically transmitted. Note that CounterSnapshotted is information indicating a list of counter information for billing, and PartsCounterSnapshotted is information indicating a list of counter information for the wear degree of parts.

[0050] Fig. 6 is a flowchart showing the event collection process and storage process in the first embodiment. The flow is shown from the event collection unit 511 collecting target data to the event storage unit 512 storing the events in each message buffer 520 in order to transmit various occurrences in the client 120 as events to the management server 110. Each process shown in Fig. 6 is realized by the CPU 401 expanding a program stored in a readable storage medium (ROM 402 or HDD 404) into the RAM 403 and executing it.

[0051] First, a process of monitoring state transitions occurring in a module that spontaneously issues an event, collecting state transition data in real time, and saving the data as an event will be described. As a specific example, a case where an error occurs in the client 120 will be described. Fig. 6(A) is a flowchart showing a process of collecting and saving an error occurrence event.

[0052] In step S601, event collection unit 511 detects the occurrence of an error in client 120. As a specific example, when an error occurs in client 120, error control unit 505 first detects the error. Error control unit 505 that has detected the error notifies event collection unit 511 of the occurrence of the error. Event collection unit 511 receives the notification from error control unit 505 and detects the occurrence of an error in client 120.

[0053] In step S602, the event collection unit 511 determines whether or not the event of the occurrence of an error detected in step S601 (hereinafter referred to as an error event) is to be notified to the management server 110. The event collection unit 511 determines whether or not the error event is to be notified according to the event notification settings stored in the notification setting storage unit 521. If the collection including the error event is set as a notification target to the management server 110 in the event notification settings, the process proceeds to step S603. On the other hand, if the collection including the error event is not set as a notification target to the management server 110 in the event notification settings, the process ends. Through steps S601 and S602, the event collection unit 511 can collect only events that are set as notification targets in the event notification settings.

[0054] In step S603, the event collection unit 511 acquires the current time. Then, in step S604, the event collection unit 511 collects information to be added to the error event. In step S605, the event storage unit 512 normalizes the error event together with the added information and time information. The event storage unit 512 normalizes in a format such as JSON, for example.

[0055] Steps S606 and S607 are event storage processes executed for each client application 540 that is currently issuing an event data collection instruction. In this embodiment, event storage processes corresponding to each of client application 540a and client application 540b are executed.

[0056] For example, first, the event storage process is executed for client application 540a. In step S605, event storage unit 512 judges whether the error event collected by event collection unit 511 is an event instructed to be collected and stored by client application 540a. As a specific example, event storage unit 512 judges whether message buffer 520a corresponding to client application 540a is specified as the storage destination of the error event according to the information on the storage destination of the event stored in notification setting holding unit 521. If message buffer 520a is specified as the storage destination of the error event, the process proceeds to step S607. On the other hand, if message buffer 520a is not specified as the storage destination of the error event, the process of storing the event corresponding to client application 540a is terminated.

[0057] In step S607, event storage unit 512 stores the error event in message buffer 520a of client application 540a. When the event storage process for client application 540a ends, the event storage process for client application 540b is then executed. In this manner, the event storage processes in steps S606 and S607 are repeated until they are executed for all client applications 540 that have issued event data collection instructions.

[0058] The events stored in message buffer 520a are then read by client application 540a and sent to management server 110a. Similarly, the events stored in message buffer 520b are read by client application 540b and sent to management server 110b.

[0059] Next, a process of collecting periodically transmitted data and saving it as an event will be described. As a specific example, a case where snapshot data of a counter in the client 120 is periodically transmitted will be described. Fig. 6(B) is a flowchart showing a process of periodically collecting and saving a snapshot of a counter.

[0060] In step S631, the event collection unit 511 determines whether or not there is a request for periodic collection of counter snapshots from the client application 540. As a specific example, the event collection unit 511 determines whether or not there is a request for periodic collection of counter snapshots based on whether or not there is a collection for which periodic transmission is set in the event notification settings held by the notification setting holding unit 521. If there is a collection for which periodic transmission is set in the event notification settings of the notification setting holding unit 521, it determines that there is a request for periodic collection of counter snapshots and proceeds to step S632. On the other hand, if there is no request for periodic collection of counter snapshots, this process ends.

[0061] In step S632, the event collection unit 511 sets a timer with a period specified in the notification setting of the event held by the notification setting holding unit 521. Next, in step S633, the event collection unit 511 detects firing of the timer set in step S632. Having detected the firing of the timer, the event collection unit 511 acquires the current time in step S634. Then, in step S635, the event collection unit 511 collects the counter value of the timer that has fired from the counter management unit 507. In step S636, the event storage unit 512 normalizes the collected counter data together with time information. The event storage unit 512 normalizes the data in a format such as JSON, for example.

[0062] Next, the normalized event storage process is performed for each client application 540. The event storage process in FIG. 6(B) is similar to the event storage process described in FIG. 6(A), so the same reference numerals are used and the description thereof is omitted. When the event storage process ends, in step S637, the event collection unit 511 sets the next timer. When the timer setting is completed, the process returns to step S633. By the above-described process, the counter collection and storage process is periodically repeated, so that each client application 540 can periodically transmit counter events to the corresponding management server 110.

[0063] The data of the client 120 collected and stored in the process of Fig. 6 is transmitted to the management server 110 and used for various services and applications built on a system including the management server 110. Therefore, the necessary data, i.e., the data to be collected, differs depending on the contracted service, and therefore the event notification settings differ for each service. In this embodiment, the event notification settings are managed in the form of a collection file. Therefore, the contents written in the collection file differ for each contracted service.

[0064] For example, in a system that provides a service for monitoring macro operational status such as the operating status on a dashboard, the Counter and Alarm collections in Table 1 are recorded in the collection file. In a system that provides an automatic delivery service for consumables, the Information collection in Table 1 is recorded in the collection file. In a system that provides a maintenance service by monitoring the operational status of the client 120, the Diagnosis collection in Table 1 is recorded in the collection file.

[0065] A process of connecting the management server 110 and the client 120 and setting and managing a collection file which is an event notification setting will be described. FIG. 7 is a flowchart showing a process of acquiring and updating an event notification setting. In FIG. 7, each process executed by a system including the management server 110 which provides a service to the client 120 will be described as being executed by the management server 110. Each process on the management server 110 side shown in FIG. 7 is realized by the CPU 201 loading a program stored in a readable storage medium (ROM 202 or HDD 204) into the RAM 203 and executing it. Also, each process on the client 120 side is realized by the CPU 401 loading a program stored in a readable storage medium (ROM 402 or HDD 404) into the RAM 403 and executing it.

[0066] First, a pre-processing that the management server 110 performs before connecting to the client 120 will be described. In step S701, the management server 110 registers information about the client device that is about to be connected. The information about the client device includes a device serial number, customer information, and the like. In this embodiment, an example in which the management server 110 connects to the client 120 will be described. Next, in step S702, the management server 110 determines the service to be provided to the client 120 based on the contract details of the customer who owns the client 120. In step S703, the management server 110 determines the contents of the collection file to be placed on the client 120 according to the service to be provided to the client 120.

[0067] On the other hand, on the client 120 side, in step S751, the network communication unit 531 performs an operation of connecting to the management server 110. Specifically, a connection is made to the management server 110 via the network 100 by a procedure such as inputting the address of the management server 110 in the network settings. Communication with the management server 110 is then performed.

[0068] Upon receiving a connection process from the client 120 (step S751), in step S704 the management server 110 confirms the connection of the client 120. As a result, communication is established between the client 120 and the management server 110, enabling data exchange.

[0069] In step S705, the management server 110 transmits the collection file determined in step S703 to the client 120. In step S752, the notification setting acquisition unit 532 of the client 120 receives the collection file transmitted from the management server 110. Then, the notification setting acquisition unit 532 passes the received collection file to the notification setting management unit 523.

[0070] In step S753, the notification setting management unit 523 compares the collection file acquired in step S752 with the collection file from the same acquisition source stored in the notification setting storage unit 521, and determines whether or not there has been a change. If there has been a change, the process proceeds to step S754. On the other hand, if there has been no change, the process proceeds to step S755. Note that if the notification setting storage unit 521 does not contain a collection file from the same acquisition source, that is, if this is the first collection file received from the management server 110, then it is assumed that there has been a change and the process proceeds to step S754.

[0071] In step S754, the notification setting management unit 523 rewrites the collection file stored in the notification setting holding unit 521 to the collection file received in step S752. Events are collected and stored according to the latest updated collection file, making it possible to send events as instructed by the management server 110. After that, after waiting for a certain period of time in step S755, the process returns to step S752 again, where the latest collection file is obtained from the management server 110, and any changes to the contents of the collection file are reflected in the notification setting holding unit 521, and this operation is repeated.

[0072] After step S705, the management server 110 changes the collection file if there is a change in the service provided to the client 120, so that the changed collection file can be sent to the client 120. As a specific example, first, in step S706, the management server 110 determines whether the content of the service provided to the client 120 has changed due to a change in the customer's contract, etc. If the content of the service has changed, the process proceeds to step S707. On the other hand, if the content of the service has not changed, step S706 is repeated. In step S707, the management server 110 changes the collection file in accordance with the change in the service. When the change in the collection file is completed, the process returns to step S705, and the changed collection file is sent to the client 120.

[0073] As described above, by modifying the collection file, it is possible to change the notification settings of the client 120 in accordance with the content of the service to which the customer has made a contract.

[0074] FIG. 8 is a diagram showing an example of a collection file. The collection file 800 is definition information in which notification settings for an event are described, and defines the type of data to be collected in the client 120 and the conditions for collection. The collection file 800 is generated by the management server 110 and transmitted from the management server 110 to the client 120 in step S705 of FIG. 7. The transmitted collection file 800 is received by the client 120 in step S752. Each collection file 800 received from each management server 110 is managed by the notification setting management unit 523 in the client 120. In this embodiment, an example of a collection file 800 in JSON format will be described, but the format of the collection file 800 may be any format that can be normalized in text, such as XML or CSV. When collecting data in the client 120, the contents of the collection file 800 are referred to in step S601 or step S631.

[0075] The collection file 800 describes three types of notification settings (notification settings 801 to 803). Each notification setting describes the type of data to be collected and the conditions for collection in order to send it to the management server 110. As a specific example, the collection to which the event belongs is described as the data type, and the timing for collecting the data is described as the data collection conditions.

[0076] In the notification settings 801, "Power" and "Alarm" are entered as the types of data to be collected, and "realtime" is entered as the condition for collection. "Realtime" is defined as sending immediately when an event occurs. In other words, in the notification settings 801, it is set to send immediately when an event belonging to the Power and Alarm collection occurs. When "realtime" is set, as shown in FIG. 6(A), data is collected in response to an error or the like occurring in the client 120, an event is issued, and the data is sent to the management server 110.

[0077] In the notification settings 802, "Basic" is entered as the type of data to be collected, and "up / cron" is entered as the collection conditions. "Up" defines transmission at startup, and "cron" defines periodic transmission. In the example of cron in the notification settings 802, the periodic transmission cycle is defined as six hours. In other words, in the notification settings 802, it is set so that events belonging to the Basic collection are sent to the management server 110 when the client 120 starts up and every six hours after startup.

[0078] In the notification settings 803, "Counter" and "PartsCounter" are entered as the types of data to be collected, and "cron" is entered as the condition for collection. In the example of cron in the notification settings 803, the periodic transmission cycle is defined as 12 hours. That is, in the notification settings 803, events belonging to the Counter and PartsCounter collections are set to be sent to the management server 110 at 12-hour cycles after the client 120 is started. The notification settings 802 and 803 are examples of periodic transmission, and as shown in FIG. 6(B), data is collected according to a timer in accordance with the notification settings, an event is issued, and the event is sent to the management server 110.

[0079] Next, a description will be given of management of event notification settings by the notification setting management unit 523. The notification setting management unit 523 acquires a collection file sent from the management server 110 as event notification settings from the notification setting acquisition unit 532 of each client application 540. When there are multiple client applications 540, the notification setting management unit 523 integrates and manages the notification settings (collection files) of multiple events acquired from each client application 540. The event notification settings managed by the notification setting management unit 523 are stored in the notification setting retention unit 521.

[0080] The integration of event notification settings will now be described. Table 2 is an example of event notification settings for each client application, and shows notification settings specified by three client applications. [Table 2] Table 2 shows the collection, firing type, and cycle obtained from the collection file for each client application. The collection indicates the type of data to be collected, and the firing type and cycle indicate the conditions under which the data is collected.

[0081] Table 3 is an example of a notification setting table in the first embodiment that integrates the notification settings of the events shown in Table 2. [Table 3] The notification settings for the integrated events include the collection, firing type, and cycle, as well as the message buffer to which the collected data is written. The message buffer that is set as the write destination for the collected data is the message buffer reserved for the client application that specified the notification settings for that collection. In Table 3, A is message buffer A that corresponds to client application A. Similarly, B is message buffer B that corresponds to client application B, and C is message buffer C that corresponds to client application C.

[0082] Collections of events that occur in real time are simply integrated by taking their OR. As a specific example, by taking the OR, all collections whose ignition type is set to realtime in the notification settings of each client are written in the integrated setting notification file, and the specified client application is registered as the write destination. In Table 2, the collections whose ignition type is realtime are Power and Alarm of client A, and Job and Alarm of client B. When these are integrated, they become Power whose ignition type is realtime and whose write destination is message buffer A, Alarm whose write destinations are message buffer A and message buffer B, and Job whose write destination is message buffer B. Data of the same type that matches the collection conditions specified by multiple client applications, such as Alarm, is collected at once by the event collection unit 511, and stored in each message buffer by the event storage unit 512.

[0083] On the other hand, for periodic transmission events, different cycles may be specified by multiple client applications. However, when the event notification settings of each client application are registered in a table that integrates them, one cycle is selected for each collection. Therefore, in this embodiment, requests for periodic transmission events with different cycles are integrated by rounding them up to one cycle.

[0084] Specifically, the period is determined based on the following two rules. Rule 1: If a client application has priority, the period is set according to the setting of the high-priority client application. Rule 2: If client applications have the same priority, set the shortest cycle. If the priorities of the three client applications are A>B=C, then according to the integration rules described above, the results after integration of Table 2 will be as shown in Table 3.

[0085] For example, in Table 2, the collections of periodic transmissions that overlap among multiple client applications include Basic, Counter, PartCounter, and FunctionCounter. Of these, for the cycles of Basic, Counter, and PartCounter, the cycle specified by client application A is adopted because the priority of the client applications is set as A>B=C. For the cycle of FunctionCounter requested by client application B and client application C, which have the same priority, the shortest cycle of 2 hours is adopted. Note that, in this embodiment, an example of setting the cycle according to rules 1 and 2 has been described, but the cycle may be set according to only rule 2, which sets the shortest cycle.

[0086] The event notification settings table (Table 3) in which the event notification settings (collection file) of each client application are integrated by the notification setting management unit 523 is stored in the notification setting holding unit 521. The event notification settings table is referenced when collecting events (steps S602, S631, and S632 in FIG. 6) and when saving events (step S606 in FIG. 6). For example, the event saving unit 512 saves events collected at one time in a message buffer specified as the write destination in the event notification settings table by referring to the event notification settings table. By saving events only in the specified message buffer, it is possible to send only events specified in individual contracts to each management server 110.

[0087] As described above, according to this embodiment, by integrating the event notification settings of multiple client applications, the operation of the event collection unit 510 can be minimized and the collection operation can be unified. At the same time, control is performed so that event data other than that requested to be collected by each client application is not written to the message buffer of the client application. Therefore, control can be performed so that only data individually specified by the management server is sent to each management server, and data not included in the contract is not sent. Therefore, according to this embodiment, it is possible to operate only one data collection mechanism in the client 120, and control so that data not to be collected is not sent to each cloud service.

[0088] Second embodiment In the first embodiment, an example was described in which the operation of the event collection unit 510 is made more efficient by rounding up different cycles into one cycle when instructions for different cycles are received. However, in the first embodiment, there are cases in which the management server 110 cannot acquire events at the cycle as intended. For example, in the examples of Tables 2 and 3, as a result of cycle integration, client application B can receive events for any periodic transmission event, but receives events collected at a cycle different from the intended cycle. Therefore, in the second embodiment, the cycle for collecting events is set to the greatest common denominator of the cycles specified by multiple collections. Furthermore, when storing in the message buffer 520, a judgment is made as to whether or not it is time to store in each message buffer 520, so that the event can be sent to any management server 110 at the intended timing.

[0089] Table 4 is an example of a notification setting table in the second embodiment, which integrates the notification settings of the events shown in Table 2. [Table 4]

[0090] The period in the notification setting table is the period for collecting events by the event collection unit 511. When different periods for collecting events are instructed by multiple management servers 110 in a certain collection, the notification setting management unit 523 sets a period that is the greatest common denominator of the instructed periods.

[0091] The write destination in the notification setting table indicates the message buffer that saves the events collected by the event delivery unit 530. When different cycles are specified from multiple client applications 540 in a certain collection, in addition to the message buffer 520 that is the save destination, information on the timing of saving to each message buffer 520 is stored in the write destination. As a specific example, the save interval (specified cycle ÷ greatest common divisor) for each client application 540, which indicates how many times the event collection cycle, which is the greatest common divisor, should be written for each write destination information, is stored for each message buffer 520 as the save destination. The value in parentheses next to the write destination in the notification setting table is the value of the save interval.

[0092] Fig. 9 is a flowchart showing the event collection and storage process in the second embodiment. The flow is shown from the event collection unit 511 collecting target data to the event storage unit 512 storing the events in each message buffer 520 in order to transmit various occurrences in the client 120 as events to the management server 110. As a specific example, a case where snapshot data of a counter in the client 120 is periodically transmitted will be described. Each process shown in Fig. 9 is realized by the CPU 401 expanding a program stored in a readable storage medium (ROM 402 or HDD 404) in the RAM 403 and executing it.

[0093] In step S901, the event collection unit 511 determines whether or not there is a request for periodic collection of counter snapshots from the client application 540. The process in step S901 is the same as that in step S631. If there is a collection for which periodic transmission is set in the event notification settings in the notification setting storage unit 521, it is determined that there is a request for periodic collection of counter snapshots, and the process proceeds to step S902. On the other hand, if there is no request for periodic collection of counter snapshots, this process ends.

[0094] In step S902, the event collection unit 511 acquires the period and storage interval for collecting periodically transmitted events from the notification settings of the event stored in the notification setting storage unit 521, and sets the initialized number of firings N (N=0). As a specific example, the event collection unit 511 refers to the notification setting table (Table 4) stored in the notification setting storage unit 521, and acquires the period of the periodically transmitted collection and the storage interval set for each message buffer 520. The acquired period is the greatest common divisor of the periods of periodically transmitted collections specified by each client application 540. In the example of Table 4, the counter snapshot period is 4 hours, the storage interval in message buffer A is 3, and the storage interval in message buffer B is 1.

[0095] In step S903, the event collection unit 511 sets a timer based on the cycle acquired in step S902. In the example of Table 4, the event collection unit 511 sets a four-hour timer. After that, when the event collection unit 511 detects the firing of the timer in step S904, it increments the firing count to N=N+1 in step S905. The first time, N=1.

[0096] In step S906, the event collection unit 511 determines whether to collect an event in response to the current timer firing based on the firing count N incremented in step S904 and the storage interval acquired in step S902. As a specific example, whether to collect an event is determined based on whether the firing count N is a multiple of any of the storage intervals. If the firing count N is a multiple of any of the storage intervals, the process proceeds to step S907. On the other hand, if the firing count N is not a multiple of any of the storage intervals, the process proceeds to step S911. This process allows the event collection to be executed only when it is necessary to collect an event within the firing cycle of the timer set by the greatest common denominator, so that the operation of the event collection unit 510 can be suppressed. In the example of Table 4, the storage interval of the message buffer A is 3 and the storage interval of the message buffer B is 1, so that it is determined to execute event collection even in the first case where the firing count N=1.

[0097] In step S907, the event collection unit 511 acquires the current time. Then, in step S908, the event collection unit 511 collects the target counter value of the fired timer from the counter management unit 507. In step S909, the event storage unit 512 normalizes the collected counter data together with the time information. The event storage unit 512 normalizes the data in a format such as JSON.

[0098] In step S910, event storage unit 512 stores the normalized event in the target message buffer. The message buffer in which the event is to be stored is determined based on the notification setting table (Table 4) stored in notification setting holding unit 521 and the number of firings N. For example, when the number of firings N is 1 or 2, event storage unit 512 stores the event only in message buffer B. When the number of firings N is 3, event storage unit 512 stores the event in message buffer A and message buffer B.

[0099] When the event saving process is completed, in step S911, the event collection unit 511 sets the next timer. When the timer setting is completed, the process returns to step S904. Note that in step S906 in the flowchart of Fig. 9, the event collection unit 511 determines whether or not to collect data based on the saving interval, but data may be collected at intervals of the greatest common denominator without making this determination. In step S910, the event saving unit 512 determines whether or not the interval is one for saving the collected data in each message buffer.

[0100] According to the above process, when the firing count N=1, i.e., 4 hours, or when the firing count N=2, i.e., 8 hours, the event is stored only in message buffer B, and the event is sent to the corresponding management server by client application B. When the firing count N=3, i.e., 12 hours, the event is stored in message buffer A and message buffer B, and the event is sent to each management server by each client application.

[0101] As described above, according to the second embodiment, for events that are sent periodically, it is possible to write events to each message buffer at the period requested by each client application while operating with one periodic timer. This makes it possible to integrate the periodic timers in the client 120 for efficiency, while enabling each management server 110 to send desired events at the timing intended.

[0102] (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.

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

Claims

1. A network device executing a first client application for transmitting data over a network to a first system, a management means for managing first definition information that defines the type of data to be collected within the network device and the conditions under which the data is collected and that is received from the first client application; a collection means for collecting data within the network device according to the first definition information; a storage means for storing the data collected by the collection means in a first dedicated area reserved for the first client application; The first client application transmits data obtained from the first dedicated area to the first system; when a second client application for transmitting data to a second system via a network is added to the network device and second definition information is received from the second client application, the second definition information defining the type of data to be collected within the network device and the conditions for collection, the collection means collects target data according to the conditions for data that match the conditions for collection in the first definition information and the second definition information; A network device characterized in that the storage means stores the target data collected at one time by the collection means according to the conditions in the first dedicated area and in a second dedicated area reserved for the second client application.

2. The first client application and the second client application are each set with a priority; The network device according to claim 1, characterized in that the collection means collects target data according to conditions received from a client application with a high priority for data that is collected under different conditions in the first definition information and the second definition information.

3. The network device according to claim 1, characterized in that, for data collected under different conditions in the first definition information and the second definition information, the collection means collects target data according to the conditions for which the period for collecting the data is the shortest.

4. Regarding data collected under different conditions in the first definition information and the second definition information, the collection means collects the target data at a period that is a greatest common divisor of periods for collecting the data defined in the first definition information and the second definition information; The network device according to claim 1, characterized in that the storage means stores the target data collected at one time by the collection means at the greatest common divisor period in the first dedicated area according to the period for collecting the data defined in the first definition information, and stores the target data in the second dedicated area according to the period for collecting the data defined in the second definition information.

5. The second client application transmits the data obtained from the second dedicated area to the second system. A network device according to any one of claims 1 to 4.

6. 1. A method of controlling a network device on which a first client application for transmitting data over a network to a first system is executed, comprising: a management step of managing first definition information, which is received from the first client application and defines the type of data to be collected within the network device and the conditions under which the data is collected; a collection step of collecting data within the network device according to the first definition information; and storing the collected data in a first dedicated area reserved for the first client application; The first client application transmits data obtained from the first dedicated area to the first system; a second client application for transmitting data to a second system via a network is added to the network device, and when second definition information is received from the second client application, the type of data to be collected within the network device and the conditions for collection are defined, in the collection step, target data is collected according to the conditions for data that match the conditions for collection in the first definition information and the second definition information; A method for controlling a network device, characterized in that in the storage step, the target data collected at one time according to the conditions in the collection step is stored in the first dedicated area and in a second dedicated area reserved for the second client application.

7. A network device in which a first program for transmitting data to a first system via a network and a second program different from the first program are executed, a management means for managing first definition information that defines the type of data to be collected within the network device for the first program and the conditions under which the data is collected, and second definition information that defines the type of data to be collected within the network device for the second program and the conditions under which the data is collected; a collection means for collecting data within the network device; A storage means for storing the data collected by the collection means, The collection means collects target data according to a condition for data that matches a condition to be collected in the first definition information and the second definition information, and A network device characterized in that the storage means stores the target data collected at one time by the collection means according to the conditions in a first dedicated area reserved for the first program and in a second dedicated area reserved for the second program.

8. The network device described in Claim 7, characterized in that the first program transmits data obtained from the first dedicated area to the first system.

9. A network device as described in claim 7 or 8, characterized in that the second program transmits data obtained from the second dedicated area to a second system different from the first system.

10. A method for controlling a network device in which a first program for transmitting data to a first system via a network and a second program different from the first program are executed, comprising: a management process for managing first definition information, which defines the type of data to be collected within the network device for the first program and the conditions under which the data is collected, and second definition information, which defines the type of data to be collected within the network device for the second program and the conditions under which the data is collected; a collecting step of collecting data within the network device; A storage step of storing the data collected in the collection step, In the collecting step, target data is collected according to conditions for data that match conditions collected in the first definition information and the second definition information; A method for controlling a network device, characterized in that, in the storage process, the target data collected at one time in accordance with the conditions in the collection process is stored in a first dedicated area reserved for the first program and in a second dedicated area reserved for the second program.

Images