JP2022027302A - Apparatus management device, remote management system, apparatus control method, and program - Google Patents

Abstract

To provide an apparatus management device, a remote management system, an apparatus control method, and a program that dynamically change communication settings according to the usage status.SOLUTION: In a remote management system 1, an apparatus management device 10 for managing an apparatus 50 in a local network 7 acquires a request for the apparatus 50 requested by a client and performs processing corresponding to a type of the acquired request. The apparatus management device 10 then changes communication settings of the apparatus 50 according to a performed processing history, and transmits an apparatus control request (an example of a control request) for requesting a setting change to the changed communication settings to the apparatus 50.SELECTED DRAWING: Figure 10

Description

The present disclosure relates to a device management device, a remote management system, a device control method and a program.

A remote management system that remotely manages devices existing in a local network such as a LAN (Local Area Network) from outside the local network is known. In such a remote management system, for example, an intermediary device capable of acquiring device information from a device is provided in a local network. The management device located outside the local network realizes remote management of the device by communicating with the mediation device via a firewall.

Further, when using the API provided by the management device, there is known a technique of setting a billing condition for each application that uses the API and calculating a billing amount for each application according to the set billing condition (). For example, Patent Document 1).

However, the conventional method has a problem that the behavior such as the communication setting of the device to be managed cannot be dynamically controlled according to the usage status of the API.

In order to solve the above-mentioned problems, the invention according to claim 1 is a device management device for managing devices in a local network, and is a method for acquiring a request for the device requested by a client. A process execution means for executing a process according to the type of the request, a communication control means for changing the communication setting of the device according to the executed process history, and a request for changing the setting to the changed communication setting. It is a device management device including a transmission means for transmitting a control request to be performed to the device.

According to the present invention, there is an effect that the communication setting of the device can be dynamically changed according to the usage situation.

It is a figure which shows an example of the remote management system which concerns on embodiment. It is a figure which shows an example of the hardware composition of the computer which concerns on embodiment. It is a figure which shows an example of the functional structure of the device management apparatus which concerns on embodiment. (A) is a conceptual diagram showing an example of a device information management table according to an embodiment, and (B) is a conceptual diagram showing an example of an application information management table according to an embodiment. (A) is a conceptual diagram showing an example of an authentication information management table according to an embodiment, and (B) is a conceptual diagram showing an example of a billing condition management table according to an embodiment. (A) is a conceptual diagram showing an example of an alert condition management table according to an embodiment, and (B) is a conceptual diagram showing an example of a device control condition management table according to an embodiment. It is a conceptual diagram which shows an example of the connection destination condition management table which concerns on embodiment. (A) is a conceptual diagram showing an example of a processing history management table according to an embodiment, and (B) is a conceptual diagram showing an example of a communication setting management table according to an embodiment. It is a conceptual diagram which shows an example of the connection time management table which concerns on embodiment. It is a figure which shows an example of the functional structure of the apparatus and a client terminal which concerns on embodiment. It is a sequence diagram which shows an example of the setting process of the management condition in the remote management system which concerns on embodiment. It is a flowchart which shows an example of the setting process of the management condition in the device management apparatus which concerns on embodiment. It is a sequence diagram which shows an example of the charge processing according to the usage state of API in the remote management system which concerns on embodiment. It is a flowchart which shows an example of the API control processing in the device management apparatus which concerns on embodiment. It is a sequence diagram which shows an example of the device control processing according to the usage state of API in the remote management system which concerns on embodiment. It is a flowchart which shows an example of the device control processing in the device management apparatus which concerns on embodiment. It is a flowchart which shows an example of the change process of the endpoint of a device in the device management apparatus which concerns on embodiment. It is a flowchart which shows an example of the change process of the communication protocol with a device in the device management apparatus which concerns on embodiment. (A) is a conceptual diagram showing another example of the device information management table according to the embodiment, and (B) is a conceptual diagram showing another example of the alert condition management table according to the embodiment.

Hereinafter, embodiments for carrying out the invention will be described with reference to the drawings. In the description of the drawings, the same elements are designated by the same reference numerals, and duplicate description will be omitted.

● Embodiment ●
● System configuration FIG. 1 is a diagram showing an example of a remote management system according to an embodiment. The remote management system 1 shown in FIG. 1 is a system that centrally and remotely manages a device 50 existing in a remote location by using a device management device 10 on the cloud.

The remote management system 1 includes a management system 3, a local network 7, and a client terminal 90. The local network 7 is connected to the management system 3 via the communication network 5. The local network 7 and the management system 3 are connected, for example, by using a firewall 9 as an interface. Further, the communication network 5 is constructed by the Internet, a mobile communication network (mobile communication network), and the like. The communication network 5 includes not only wired communication but also mobile communication networks such as 3G (3rd Generation), 4G (4th Generation), 5G (5th Generation) or LTE (Long Term Evolution), and Wi-Fi (Wireless). It may include a part constructed by wireless communication such as Fidelity (registered trademark)) or WiMAX (Worldwide Interoperability for Microwave Access). Further, the communication network 5 may include a network constructed by a blockchain.

The local network 7 is a network formed in a network environment such as an office, a conference room, a warehouse, a factory, or a specific production line. The local network 7 is, for example, an in-house LAN (Local Area Network) that does not go through the Internet. The local network 7 includes an MFP (Multi-Function Peripheral) 50a, a PJ (Projector: projector) 50b, an IWB (Interactive White Board: a white board having an electronic blackboard function capable of mutual communication) 50c, and a PC (Personal). Computer: personal computer) 50d, sensor device 50e (eg, electronic balance, barometer, accelerometer, current meter, thermometer, photometric meter, human sensor, camera, illuminance meter that can communicate with the outside) is included. The MFP50a, PJ50b, IWB50c, PC50d, and sensor device 50e are managed devices to be remotely managed in the remote management system 1. The device 50 used in the following description is a general term for these managed devices.

The firewall 9 has a function of passing only a specific packet from the device management device 10 from the communication network 5 into the local network 7. This allows the firewall 9 to block unintended or unauthorized access to the local network 7. Further, the firewall 9 has a function of forwarding the packet from the intermediary device 30 to the device management device 10.

The management system 3 is a system for managing the device 50 located in the local network 7. The management system 3 includes a device management device 10 and a service providing device 70. The device management device 10 is, for example, a server computer that provides a remote management service for remotely managing a device 50 to be managed via an intermediary device 30. As an example of management, the device management device 10 monitors the state of the device 50 in real time, or periodically acquires maintenance information (parts usage status, alarm information, etc.) of the device 50. When the device 50 is the MFP 50a, the device management device 10 can acquire information on the state such as the remaining amount of toner or the number of printed sheets from the MFP 50a. Further, the device management device 10 can give an instruction to print the document data stored in the MFP 50a. Further, the device management device 10 can control ON or OFF of the power supply for PJ50b, IWB50c and PC50d. Further, the device management device 10 can acquire the information acquired by the sensor device 50e with respect to the sensor device 50e.

The service providing device 70 is a server computer for realizing a desired solution by cooperating with the device management device 10. The service providing device 70 provides, for example, a log collection service for the device 50, a counter collection service for the device 50, or a maintenance service for the device 50. Further, when the device 50 to be managed is the MFP 50a, the service providing device 70 provides a cloud print service, a cloud scan service, a cloud storage service, or the like related to the MFP 50a. Further, the service providing device 70 provides, for example, a multilingual translation service using the device 50.

The device management device 10 and the service providing device 70 may be constructed by a single computer, or may be constructed by a plurality of computers arbitrarily assigned by dividing each part (function or means) of each device. You may. Further, the management system 3 may be, for example, a computer in which all or a part of each function of the device management device 10 and the service providing device 7 is integrated.

The client terminal 90 (90a, 90b, 90c, hereinafter referred to as a client terminal 90 when it is not necessary to distinguish them) is a notebook PC used by a client who is a device manager who monitors the device 50 using the device management device 10. Etc. terminals. The client terminal 90 provides the client with information on the device 50 to be managed by displaying the device information of the device 50 managed by the device management device 10 using a Web browser or the like. Further, the plurality of client terminals 90 can access the device management device 10 from different bases.

Further, the management applications 900a to 900c (hereinafter referred to as management applications 900 when it is not necessary to distinguish them) are operating on the client terminals 90a to 90c, respectively. The device management device 10 can set the content of the application to be provided according to, for example, the usage environment of the local network 7, the type of the device 50, the contract content of the client, and the like, and the application to be provided for each client terminal 90 can be set. I manage it.

The client terminal 90 is not limited to a notebook PC, and may be, for example, a terminal such as a tablet terminal, a smartphone, a wearable terminal, or a desktop PC. Further, the client terminal 90 may be configured to be able to directly communicate with the device 50 in the local network 7. For example, when the manager or the like of the device 50 performs the installation work on site, the client terminal 90 used by the person in charge of installation communicates directly with the device 50 in the local network 7 to smoothly perform the installation work. Can be done.

The intermediary device 30 is a device that mediates communication between the device management device 10 and the device 50 in the local network 7. The intermediary device 30 maintains a constant session to send a message from the device management device 10 beyond the firewall 9 into the local network 7, and is monitored by the device management device 10 while ensuring the security in the local network 7. Two-way communication with the device 50 of the above is realized. The intermediary device 30 can communicate with the device 50 and the firewall 9 via a wired or wireless LAN or the like. The intermediary device 30 receives an instruction from the device management device 10 to access the device 50, sends an alert notification from the device 50 to the device management device 10, and acquires information on the device 50 based on a preset schedule. Notification or life-and-death monitoring (for example, whether or not the device 50 can communicate) is performed.

Since the remote management system 1 can collectively transmit the information of the plurality of devices 50 existing in the same local network 7 from the intermediary device 30 to the device management device 10, the communication load can be reduced. Further, since the remote management system 1 does not need to set network security such as access permission to the firewall 9 for each device 50 by providing the intermediary device 30, it is possible to reduce the burden associated with the device setting of the user. .. The intermediary device 30 may be a box-type (box-type) communication device that functions as a single unit, or may be built in a device such as the MFP 50a.

Further, the intermediary device 30 can communicate with the device management device 10 on the communication network 5 via the firewall 9. That is, it can be said that the mediation device 30 is located inside the firewall 9 (local network 7 having the interface as the interface), and the device management device 10 is located outside the firewall 9 (local network 7 with the interface as the interface).

The device 50 (MFP50a, PJ50b, IWB50c, PC50d and sensor device 50e) is located in the local network 7 and in the firewall 9 (local network 7 having the interface as the interface). The device 50 is a managed device for which maintenance by the device management device 10 or counter meter reading is performed. The device 50 is not limited to the examples shown in FIG. 1 (MFP50a, PJ50b, IWB50c, PC50d and sensor device 50e), and is, for example, an industrial machine such as a processing device, an inspection device, a transport device or a picking device, and a fundus. It may be a medical device such as an inspection device, an X-ray inspection device, a blood pressure monitor, a body fat meter, a vision meter or a pacemaker, a 3D printer, an image pickup device, or the like. Further, the device 50 may be a vending machine, a power supply device, an air conditioning system, a measurement system for gas, water, electricity, etc., an autonomous traveling robot, or the like. Further, the device 50 may be equipped with a device having a communication function attached to a terminal having no communication function such as a motion sensor.

Further, FIG. 1 shows an example in which the management system 3 remotely manages a plurality of devices 50 located in one local network 7, and the management system 3 is a device 50 located in each of the plurality of local networks 7. May be configured to be remotely managed. Further, FIG. 1 shows an example in which one intermediary device 30 is located in one local network 7, but the intermediary device 30 may be configured such that two or more units are located in one local network. .. In this case, the plurality of intermediary devices 30 may share the functions of each intermediary device 30.

● Hardware configuration Next, the hardware configuration of each device according to the embodiment will be described. Each device constituting the remote management system 1 has a general computer configuration. Here, a general computer hardware configuration example will be described.

FIG. 2 is a diagram showing an example of the hardware configuration of the computer according to the embodiment. The computer hardware configuration shown in FIG. 2 may have the same configuration in each embodiment, and components may be added or deleted as necessary. The computer includes a CPU (Central Processing Unit) 101, a ROM (Read Only Memory) 102, a RAM (Random Access Memory) 103, an HD (Hard Disk) 104, an HDD (Hard Disk Drive) controller 105, a display 106, and an external device connection I. It includes a / F (Interface) 108, a communication I / F 109, a bus line 110, a keyboard 111, a pointing device 112, a DVD-RW (Digital Versatile Disk Rewritable) drive 114, and a media I / F 116.

Of these, the CPU 101 controls the operation of the entire computer. The ROM 102 stores a program used to drive the CPU 101 such as an IPL. The RAM 103 is used as a work area of the CPU 101. The HD 104 stores various data such as programs. The HDD controller 105 controls reading or writing of various data to the HD 104 according to the control of the CPU 101. The display 106 displays various information such as cursors, menus, windows, characters, or images. The display 106 is an example of a display unit. The display 106 may be a touch panel display provided with input means. The external device connection I / F 108 is an interface for connecting various external devices. The communication I / F 109 is an interface for transmitting / receiving data to / from another computer, electronic device, or the like. The communication I / F 109 is, for example, a communication interface such as a wired or wireless LAN. Further, the communication I / F 109 may be provided with a mobile communication such as 3G, 4G, 5G or LTE, and a communication interface such as Wi-Fi or WiMAX. The bus line 110 is an address bus, a data bus, or the like for electrically connecting each component such as the CPU 101 shown in FIG.

Further, the keyboard 111 is a kind of input means including a plurality of keys for inputting characters, numerical values, various instructions and the like. The pointing device 112 is a kind of input means for selecting or executing various instructions, selecting a processing target, moving a cursor, and the like. The input means may be not only the keyboard 111 and the pointing device 112, but also a touch panel, a voice input device, or the like. The DVD-RW drive 114 controls reading or writing of various data to the DVD-RW 113 as an example of a detachable recording medium. The detachable recording medium is not limited to the DVD-RW, but may be a DVD-R, a Blu-ray (registered trademark) Disc (Blu-ray disc), or the like. The media I / F 116 controls reading or writing (storage) of data to a recording medium 115 such as a flash memory.

In the hardware configuration of each device according to the embodiment, components may be added or deleted as necessary. For example, the remote management system A and the remote management system B may be configured without an input means such as a keyboard 111 and a display 106. Further, the device 50 may be configured to include a module or the like for providing a function or a service according to the type of each device.

Further, each of the above programs may be a file in an installable format or an executable format, and may be recorded and distributed on a computer-readable recording medium. Examples of the recording medium include a CD-R (Compact Disc Recordable), a DVD (Digital Versatile Disk), a Blu-ray Disc, an SD card, a USB (Universal Serial Bus) memory, and the like. In addition, the recording medium can be provided domestically or internationally as a program product. For example, the device management device 10 realizes the device control method according to the present invention by executing the program according to the present invention.

● Functional configuration Next, the functional configuration of the remote management system according to the embodiment will be described with reference to FIGS. 3 to 10. In addition, in FIGS. 3 to 10, those related to the processing or operation described later are shown. FIG. 3 is a diagram showing an example of the functional configuration of the device management device according to the embodiment.

First, the device management device 10 includes a device communication unit 11, a terminal communication unit 12, an authentication unit 13, a judgment unit 14, a client information management unit 15, a condition setting unit 16, an API (Application Programming Interface) processing unit 17, and a billing processing unit. It has an equipment control unit 21, a connection time management unit 22, and a storage / reading unit 19. Each of these parts has a function or functions realized by operating any of the components shown in FIG. 2 by a command from the CPU 101 according to a program for a device management device developed on the RAM 103. It is a means. Further, the device management device 10 has a storage unit 1000 constructed by the ROM 102, HD 104 or the recording medium 115 shown in FIG.

The device communication unit 11 is mainly realized by processing the CPU 101 with respect to the communication I / F 109, and communicates various data or information with the device 50. The device communication unit 11 transmits, for example, a command indicating a predetermined control request to the device 50 to the device 50. Further, the device communication unit 11 receives a response to a command transmitted to the device 50 or device information about the device 50 spontaneously transmitted from the device 50.

Here, the device communication unit 11 receives, for example, a poll sent from the device 50 to the device management device 10 as a connection request / response format, and transmits a response to the poll to the device 50. The connection request / response format is a format in which a connection request is made from the device 50 located inside the firewall 9 to the device management device 10 located outside the firewall 9, and a response is made from the device management device 10 to the device 50. Is. For the connection request / response format, for example, a protocol such as TCP / IP (Transmission Control Protocol / Internet Protocol), SMTP (Simple Mail Transfer Protocol), SOAP (Simple Object Access Protocol), or SNMP (Simple Network Management Protocol) is used. do. The firewall 9 is generally set to pass a request transmitted from within the local network 7 and a response to the request, but not to pass a request from the communication network 5 side to the local network 7. Therefore, in order to start the connection between the device management device 10 and the device 50, a connection start request must be transmitted from the device 50 to the device management device 10 in relation to the firewall 9.

On the other hand, the device communication unit 11 maintains a communication session so that the device 50 can always communicate with the device management device 10 as a constant connection format, and various data or information is exchanged with the device 50. Send and receive. The constant connection format is a connection format that enables connection from the device management device 10 without a connection request from inside the firewall 9. Specifically, in the constant connection format, the device management device 10 can connect to the device 50 in the firewall 9 starting from the initial communication (Handshake) from the device 50. As the always-on connection format, for example, a protocol such as WebSocket, MQTT (Message Queueing Telemetry Transport), or VPN (Virtual Private Network) is used. In this embodiment, either the connection request / response format or the constant connection format may be used.

The terminal communication unit 12 is mainly realized by processing the CPU 101 with respect to the communication I / F 109, and communicates various data or information with the client terminal 90. For example, the terminal communication unit 12 functions as a server unit of a Web application, and receives a request from a client terminal 90 by a Web API (Web Application Programming Interface) using a communication protocol such as HTTPS (HyperText Transfer Protocol Secure). , Performs processing according to the request and sends it to the client terminal 90. The communication protocol used is not limited to this, and a protocol such as FTP (File Transfer Protocol), HTTP (HyperText Transfer Protocol) or SNMP (Simple Network Management Protocol) may be used. Further, the terminal communication unit 12 issues (generates) a command to be transmitted to the device 50 when communication from the device management device 10 to the device 50 is required. The issued command is, for example, a control command such as acquisition of state information of the device 50 or ON / OFF of the power supply. The terminal communication unit 12 may have a function of maintaining a constant connection state such as WebSocket or MQTT in order to notify the command result received by the device communication unit 11 on the screen of the client terminal 90 in real time. .. The device management device 10 provides a secure communication path between the management application 900 and the device 50 via the terminal communication unit 12.

The authentication unit 13 is realized by the processing of the CPU 101, and performs the authentication processing of the client such as the device manager of the device 50 registered in the device management device 10. The determination unit 14 is realized by the processing of the CPU 101 and makes various determinations. The determination unit 14 determines, for example, the type of request requested by the client.

The client information management unit 15 manages client information about a client, which is realized by processing of the CPU 101 and is a device manager or the like of the device 50 registered in the device management device 10. The client information includes, for example, device information regarding the device 50 and application information regarding the management application 900 operating on the client terminal 90.

The condition setting unit 16 is realized by the processing of the CPU 101 and sets the management conditions for the device 50. The management condition includes, for example, a billing condition according to the processing for the request requested by the client, an alert condition according to the processing history for the request, a device control condition, and a connection destination condition.

The API processing unit 17 is mainly realized by the processing of the CPU 101, and performs the API processing according to the request from the client. The API processing unit 17 has a function as, for example, a processing execution unit, distributes processing corresponding to the type of request requested by the client, and executes the distributed processing.

The billing processing unit 18 is realized by the processing of the CPU 101, and performs billing processing according to the processing history in the API processing unit 17. The billing processing unit 18 dynamically calculates the billing amount according to, for example, the billing conditions set in the billing condition management DB 1004 described later.

The device control unit 21 mainly controls the operation (behavior) of the device 50 according to the usage status or the billing amount determined by the usage status, which is realized by the processing of the CPU 101. The device control unit 21 has a function as, for example, a communication control unit, and changes the communication setting of the device 50 according to the processing history executed by the API processing unit 17. The device control unit 21 changes the communication frequency with the device 50, for example, as a communication setting of the device 50. Further, the device control unit 21 changes the endpoint to which the request requested by the client is connected, for example, as the communication setting of the device 50. Further, the device control unit 21 changes the communication protocol used for communication with the device, for example, as a communication setting of the device 50.

The connection time management unit 22 is realized mainly by the processing of the CPU 101, and manages the connection time in the constant connection format with the device 50. The connection time in the always-on connection format is used when calculating the billing amount for each device 50.

The storage / reading unit 19 is mainly realized by the processing of the CPU 101, stores various data (or information) in the storage unit 1000, and reads various data (or information) from the storage unit 1000.

○ Device information management table FIG. 4A is a conceptual diagram showing an example of a device information management table according to an embodiment. The device information management table is a table for managing various information about the device 50 to be managed by the device management device 10. In the storage unit 1000, a device information management DB 1001 configured by a device information management table as shown in FIG. 4A is constructed.

The device information management table is a device associated with a device ID that identifies the device 50, an application ID that identifies the management application 900 that operates on the client terminal 90, and a communication prohibition flag that indicates whether or not communication with the device management device 10 is restricted. Manages information. Of these, the device ID is, for example, the model name or serial number of the device 50. Further, the communication prohibition flag indicates "true" when the communication with the device management device 10 is restricted, and indicates "false" when the communication with the device management device 10 is not restricted. The device information management table holds as a communication prohibition flag whether or not communication between the device 50 and the device management device is restricted as a boolean value. In the example of FIG. 4A, the communication of the device 50 with the device ID “dev001” is restricted. When the device management device 10 receives a connection request from the device 50 whose communication is restricted, the device management device 10 can prevent the use of the API by transmitting an error notification to the device 50 at the time of authentication. The device information may include other attribute values of the device 50, state information indicating the status of the device 50, and the like.

○ Application information management table FIG. 4B is a conceptual diagram showing an example of an application information management table according to an embodiment. The application information management table stores various information about the management application 900 operating on the client terminal 90. In the storage unit 1000, an application information management DB 1002 configured by an application information management table as shown in FIG. 4B is constructed.

The application information management table manages the application ID that identifies the management application 900, the notification protocol that indicates the communication protocol when accessing the management application 900, and the notification URL (Uniform Resource Locator) that indicates the destination of the management application 900. ing. When communicating with the management application 900, the device management device 10 communicates with the client terminal 90 having the management application 900 by using the notification protocol and the notification URL associated with the application ID. The application information may include other attribute values of the management application 900.

-Authentication information management table FIG. 5 (A) is a conceptual diagram showing an example of the authentication information management table according to the embodiment. The authentication information management table stores various information used for the authentication process of the client accessing the device management device 10. In the storage unit 1000, an authentication information management DB 1003 configured by an authentication information management table as shown in FIG. 5A is constructed.

The authentication information management table manages the client ID assigned to access the device management device 10 in association with each client ID that identifies the client. The client ID is the application ID of the management application 900 used by the client or the device ID of the device 50. The client certificate is an example of authentication information. Depending on the authentication method, the authentication information may be a client ID, an e-mail address, a password, or the like instead of the client certificate, or may be an arbitrary character string uniquely specified for each client. good.

○ Billing condition management table FIG. 5B is a conceptual diagram showing an example of the billing condition management table according to the embodiment. The billing condition management table is a table for managing conditions for performing billing processing for processing executed in response to a request from a client. In the storage unit 1000, a billing condition management DB 1004 configured by a billing condition management table as shown in FIG. 5B is constructed.

The billing condition management table has a client ID for identifying the client, an apiID for identifying the API corresponding to the executed processing, an evaluation function showing a calculation formula used for calculating the billing amount, a currency unit, and the number of monthly calls from the client. Manages the associated billing terms. Of these, the client ID is the application ID of the management application 900 or the device ID of the device 50 used by the client. In addition, the evaluation function indicates the charge setting for each client used to calculate the charge amount. In the evaluation function, x indicates the number of monthly calls, and f (x) indicates the billing amount for that month.

In the example of FIG. 5B, the device 50 with the client ID “dev001” uses the APIs of apiIDs “api001” and “api002”, and the API of “api002” is larger than the API of “api001”. The usage fee is set high. Further, the device 50 with the client ID "dev002" uses the API of the apiID "api002", but the contract is made more frequently than the device 50 with the client ID "dev001", so the charge setting is cheaper. It has become. Further, the evaluation function may be a non-linear calculation formula such as the client ID "app001", or may be classified into cases such as the client ID "app002". The device management device 10 uniquely specifies the billing conditions according to the type of request (call) for each client by the combination of the client ID and the apiID. The billing condition is an example of the management condition of the device 50.

○ Alert condition management table FIG. 6A is a conceptual diagram showing an example of an alert condition management table according to an embodiment. The alert condition management table is a table for managing the conditions for issuing an alert notification to the management application 900 according to the billing status. In the storage unit 1000, an alert condition management DB 1005 configured by an alert condition management table as shown in FIG. 6A is constructed.

The alert condition management table manages alert conditions associated with a device ID that identifies the device 50, an API that identifies the API corresponding to the executed process, and a threshold value (monthly) for the charge amount according to the process. .. The device management device 10 uniquely identifies the alert condition by the combination of the device ID and the apiID. When the billing amount calculated based on the above billing condition is equal to or higher than the billing amount threshold value shown in the alert condition or exceeds the billing amount threshold value, the device management device 10 sends an alert communication to the management application 900. Issue. The alert condition is an example of the management condition of the device 50.

-Equipment control condition management table FIG. 6B is a conceptual diagram showing an example of the equipment control condition management table according to the embodiment. The device control condition management table is a table for managing the conditions for controlling the behavior (operation) of the device 50. In the storage unit 1000, a device control condition management DB 1006 configured by a device control condition management table as shown in FIG. 6B is constructed.

The device control condition management table manages device control conditions associated with the device ID that identifies the device 50, the threshold value of the billing amount according to the processing (monthly), the currency unit, and the command definition issued to the device 50. ing. Of these, it is assumed that the command definition has an interface definition between the management application 900 and the device 50. Since the device 50 knows in advance that the control message is transmitted from the device management device 10 using the command definition format, it is possible to make settings according to the received command definition.

In the example of FIG. 6B, the device 50 with the device ID "dev001" receives the command "{" stateChange ":" sleep "}" from the device management device 10 when the monthly billing amount exceeds 200,000 yen. And go to sleep. Further, when the monthly billing amount exceeds 2000000 yen, the device 50 with the device ID "dev001" receives the command "{" stateChange ":" stop "}" from the device management device 10 and stops the function. In addition, the device 50 with the device ID "dev002" receives the command "{" command ": {" polling_interval ": 10}}" from the device management device 10 and polls when the monthly charge exceeds US $ 10,000. Change the interval (communication frequency). In this case, the device 50 with the device ID "dev002" suppresses the billing amount by lengthening the polling interval and reducing the communication frequency.

Further, the device 50 having the device ID "dev001" receives the command "IOTPF_FORBIDDEN_ACCESS" from the device management device 10 when the monthly billing amount exceeds 3000000 yen, and the use of the API is restricted. "IOTPF" is an arbitrary character string, and is prohibited from being used by the device 50 or the management application 900 as a reserved word of the device management device 10. That is, when the device 50 or the management application 900 tries to set a command definition starting with "IOTPF", the device management device 10 sends a client error (400Bad Request). The device control condition is an example of the management condition of the device 50. Further, the device control condition including the command definition that limits the use of the API is an example of the limit condition that limits the communication with the device management device 10 according to the billing amount of the client.

○ Connection destination condition management table FIG. 7 is a conceptual diagram showing an example of the connection destination condition management table according to the embodiment. The connection destination condition management table is a table for managing the conditions for changing the connection destination (endpoint) of the device 50. In the storage unit 1000, a connection destination condition management DB 1007 configured by a connection destination condition management table as shown in FIG. 7 is constructed.

The connection destination condition management table manages the device ID that identifies the device 50, the apiID that identifies the API, the threshold value of the billing amount according to the processing, the currency unit, and the connection destination condition associated with the connection destination of the device 50 to be changed. is doing. Of these, the connection destination is the request destination of the request from the client, and indicates the URL of the service providing device 70 that provides a predetermined solution. The connection destination condition is an example of the management condition of the device 50.

○ Processing history management table FIG. 8A is a conceptual diagram showing an example of the processing history management table according to the embodiment. The processing history management table is a table for managing the processing history executed in response to the request from the client. In the storage unit 1000, a processing history management DB 1008 configured by a processing history management table as shown in FIG. 8A is constructed. The processing history management DB 1008 is an example of the processing history storage means.

The processing history management table is a history of the device ID that identifies the device 50, the API that identifies the API that corresponds to the executed process, the request that corresponds to the executed process, and the billing amount according to the executed process (monthly). ) Manages the associated processing history. Of these, the request is an arbitrary character string that uniquely identifies the request requested by the client. The device management device 10 stores the request requested by the client and the history of the billing amount for the processing executed in response to the request in the processing history management table in association with each other.

○ Communication setting management table FIG. 8B is a conceptual diagram showing an example of the communication setting management table according to the embodiment. The communication setting management table is a table for managing the communication settings of the device 50 in the communication with the device management device 10. In the storage unit 1000, a communication setting management DB 1009 configured by a communication setting management table as shown in FIG. 8B is constructed.

The communication setting management table is associated with the device ID that identifies the device 50, the connection destination information indicating the connection destination of the device 50, the communication protocol used for communication with the device management device 10, and the communication frequency with the device management device 10. Managing communication settings. Of these, the connection destination information indicates the communication endpoint of the device 50, and indicates, for example, the URL indicating the destination of the service providing device 70.

○ Connection time management table FIG. 9 is a conceptual diagram showing an example of the connection time management table according to the embodiment. The connection time management table is a table for managing various information regarding the connection time in the constant connection with the device 50. In the storage unit 1000, a connection time management DB 1010 configured by a connection time management table as shown in FIG. 9 is constructed.

The connection time management table is a device ID that identifies the device 50, a connection condition that indicates the period or cycle of constant connection between the device management device 10 and the device 50, and a cumulative value of the history of the connection time in the constant connection ( The connection history indicating (monthly) is managed in association with each other.

Subsequently, the functional configurations of the device 50 and the client terminal 90 will be described with reference to FIG. FIG. 10 is a diagram showing an example of the functional configuration of the device and the client terminal according to the embodiment.

First, the device 50 has a communication unit 51, a reception unit 52, a display control unit 53, a determination unit 54, a setting unit 55, and a storage / reading unit 59. Each of these parts is a function realized by operating by an instruction from the CPU 101 according to a device program developed on the RAM 103, or a means for functioning, in any of the components shown in FIG. be. Further, the device 50 has a storage unit 5000 constructed by the ROM 102, HD 104 or the recording medium 115 shown in FIG.

The communication unit 51 is mainly realized by processing the CPU 101 with respect to the communication I / F 109, and communicates various data or information with the device management device 10 via the intermediary device 30. The communication unit 51 transmits, for example, a request to the device management device 10 to request a predetermined process for the device 50. Further, the communication unit 51 receives, for example, a control request for the device 50 transmitted from the device management device 10.

The reception unit 52 is mainly realized by processing the CPU 101 with respect to the keyboard 111 or the pointing device 112, and receives various selections or inputs from the user. The display control unit 53 is mainly realized by the processing of the CPU 101, and causes the display 106 to display various images. The determination unit 54 is realized by the processing of the CPU 101 and makes various determinations. The determination unit 54 determines, for example, the necessity or propriety of setting change for changing the behavior of the device 50.

The setting unit 55 is mainly realized by the processing of the CPU 101, and performs various settings of the device 50. The setting unit 55 updates the settings of the device 50, for example, in response to the control request transmitted from the device management device 10.

The storage / reading unit 59 is mainly realized by the processing of the CPU 101, and stores various data (or information) in the storage unit 5000 and reads various data (or information) from the storage unit 5000.

Next, the client terminal 90 has a communication unit 91, a reception unit 92, a display control unit 93, and a storage / reading unit 99. Each of these parts is a function realized by operating one of the components shown in FIG. 2 by an instruction from the CPU 101 according to a program for a client terminal expanded on the RAM 103, or a means for functioning. Is. Further, the client terminal 90 has a storage unit 9000 constructed by the ROM 102, HD 104 or the recording medium 115 shown in FIG.

The communication unit 91 is mainly realized by processing the CPU 101 with respect to the communication I / F 109, and uses the management application 900 to communicate various data or information with the device management device 10. The communication unit 91 plays a role as a client unit of a Web application, and is described in a language such as HTML (Hyper Text Markup Language), JavaScript (registered trademark), or CSS (Cascading Style Sheets) that operates in a Web browser. It is realized by executing the program.

The reception unit 92 is mainly realized by processing the CPU 101 with respect to the keyboard 111 or the pointing device 112, and receives various selections or inputs from the user. The display control unit 93 is mainly realized by the processing of the CPU 101, and causes the display 106 to display various images.

The storage / reading unit 99 is mainly realized by the processing of the CPU 101, and stores various data (or information) in the storage unit 9000 and reads various data (or information) from the storage unit 9000.

● Processing or operation of the embodiment ○ Management condition setting processing Next, the processing or operation of the remote management system according to the embodiment will be described with reference to FIGS. 11 to 19. First, the process of setting the management conditions of the device 50 in advance will be described with reference to FIGS. 11 and 12. FIG. 11 is a sequence diagram showing an example of a management condition setting process in the remote management system according to the embodiment. Note that FIGS. 11 and 12 will be described assuming that the registration of client information regarding the device 50 and the management application 900 has already been completed.

First, the reception unit 92 of the client terminal 90 receives input of condition information indicating the management conditions of the device 50 by the device management device 10 by an input operation or the like to the input means of the client (step S101). Next, the communication unit 91 transmits a condition setting request indicating that the device management device 10 is requested to set the management conditions corresponding to the input condition information (step S102). This condition setting request includes an application ID (client ID) of the management application 900 of the client terminal 90, authentication information for accessing the device management device 10, and condition information accepted in step S101. As a result, the terminal communication unit 12 of the device management device 10 receives the condition setting request transmitted from the client terminal 90.

The device management device 10 executes a management condition setting process for the device 50 in response to the condition setting request received in step S102 (step S103). Here, the details of the condition setting process executed by the device management device 10 will be described with reference to FIG. FIG. 12 is a flowchart showing an example of a management condition setting process in the device management device according to the embodiment.

The client information management unit 15 searches the application information management DB 1002 (see FIG. 4B) using the application ID received in step S102 as a search key, and is associated with the same application ID as the received application ID. The application information is read out via the storage / reading unit 19 (step S11). Further, the authentication unit 13 performs a client authentication process using the application ID and the authentication information received in step S102 (step S12). In this case, the authentication unit 13 permits the client to access when the received authentication information and the authentication information associated with the application ID (client ID) received in the authentication information management DB 1003 match. Then, when the authentication of the client is successful (YES in step S13), the authentication unit 13 shifts the process to step S14.

Next, the condition setting unit 16 performs the condition setting process based on the condition information received in step S13 (step S14). Specifically, first, the determination unit 14 determines the type of received condition information. The type of condition information is, for example, one of a billing condition, an alert condition, a device control condition, and a connection destination condition, which are management conditions of the device 50. Then, the condition setting unit 16 registers various conditions for the storage destination according to the type of the condition information.

When the condition information indicates the setting of the billing condition, the condition setting unit 16 registers the setting of the billing condition in the billing condition management DB 1004 (see FIG. 5B). Further, when the condition information indicates the setting of the alert condition, the condition setting unit 16 registers the setting of the alert condition in the alert condition management DB 1005 (see FIG. 6A). Further, when the condition information indicates the setting of the device control condition, the condition setting unit 16 registers the setting of the device control condition in the device control condition management DB 1006 (see FIG. 6B), and also sets the condition. When the condition information indicates the setting of the connection destination condition, the unit 16 registers the setting of the connection destination condition in the connection destination condition management DB 1007 (see FIG. 7).

Then, the terminal communication unit 12 uses the notification protocol shown in the application information read in step S11 to the client terminal 90 having the management application 900 corresponding to the notification URL shown in the application information. Then, a setting completion notification indicating that the condition setting is completed is transmitted (step S15). As a result, the communication unit 91 of the client terminal 90 receives the setting completion notification transmitted from the device management device 10.

On the other hand, in step S13, when the authentication of the client fails (NO in step S13), the authentication unit 13 shifts the process to step S16. The terminal communication unit 12 authenticates the client terminal 90 having the management application 900 corresponding to the notification URL shown in the application information by using the notification protocol shown in the application information read in step S11. Sends an authentication failure notification indicating that has failed (step S16). As a result, the communication unit 91 of the client terminal 90 receives the authentication failure notification transmitted from the device management device 10.

As described above, the remote management system 1 can perform device management according to the usage status of the client by setting various management conditions for each client in the device management device 10 in advance. Further, the remote management system 1 can flexibly set the management conditions suitable for the actual usage situation by changing the management conditions set according to the request from the client.

○ Billing process according to the API usage status Next, a process of calculating the billing amount according to the API usage status will be described with reference to FIGS. 13 and 14. FIG. 13 is a sequence diagram showing an example of billing processing according to the usage status of the API in the remote management system according to the embodiment. Note that FIGS. 13 and 14 will be described assuming that the billing condition and the alert condition are set and registered in the device management device 10 by the above-mentioned processing.

First, the communication unit 51 of the device 50 transmits an API control request requesting a predetermined process to the device management device 10 (step S301). This API control request includes the device ID (client ID) of the device 50, the authentication information for accessing the device management device 10, and the content of the request. Further, the communication unit 91 of the client terminal 90 transmits an API control request requesting predetermined processing to the device 50 to the device management device 10 in response to an input operation or the like to the input means of the device manager (step). S302). This API control request includes an application ID (client ID) of the management application 900 of the client terminal 90, authentication information for accessing the device management device 10, and the content of the request. Either of the processes of step S301 and step S302 may be performed. That is, the API control request is transmitted from either the device 50 or the client terminal 90 to the device management device 10. As a result, the device communication unit 11 or the terminal communication unit 12 of the device management device 10 receives (acquires) the API control request transmitted from either the device 50 or the client terminal 90, respectively.

Next, the device management device 10 executes API control processing according to the type of request included in the received API control request (step S303). Here, the details of the API control process executed by the device management device 10 will be described with reference to FIG. FIG. 14 is a flowchart showing an example of API control processing in the device management device according to the embodiment.

The client information management unit 15 is the same as the received device ID by searching the device information management DB 1001 (see FIG. 4) using the device ID received in step S301 or the application ID received in step S302 as a search key. The device information associated with the device ID or the same application ID as the received application ID is read out via the storage / reading unit 19 (step S31). Further, the client information management unit 15 receives by searching the application information management DB 1002 (see FIG. 4B) using the application ID received in step S302 or the application ID read in step S31 as a search key. The application information associated with the applied application ID or the same application ID as the read application ID is read out via the storage / reading unit 19 (step S32).

Next, the authentication unit 13 performs a client authentication process using the device ID and authentication information received in step S301 or the application ID and authentication information received in step S302 (step S33). In this case, the authentication unit 13 matches the received authentication information with the authentication information associated with the device ID or application ID (client ID) received in the authentication information management DB 1003 (see FIG. 5A). If so, allow client access. Then, when the authentication of the client is successful (YES in step S34), the authentication unit 13 shifts the process to step S35. On the other hand, when the authentication of the client fails (NO in step S34), the authentication unit 13 shifts the process to step S44.

In step S44, when the API control request is received from the device 50 in step S301, the device communication unit 11 transmits an authentication failure notification indicating that the authentication has failed to the requesting device 50. On the other hand, when the API control request is received from the client terminal 90 in step S302, the terminal communication unit 12 is shown in the application information using the notification protocol shown in the application information read in step S32. The authentication failure notification is transmitted to the client terminal 90 having the management application 900 corresponding to the notification URL. As a result, the communication unit 51 of the device 50 or the communication unit 91 of the client terminal 90 receives the authentication failure notification transmitted from the device management device 10.

In step S35, the API processing unit 17 executes API control according to the API control request received in step S301 or step S302. Specifically, first, the determination unit 14 determines the type of request included in the received API control request. The request indicates the type of API to be used, the content of processing, information on the connection destination (endpoint), and the like. Then, the API processing unit 17 executes processing according to the type of request requested by the client.

Specifically, the API processing unit 17 reads the API according to the type of request. The API processing unit 17 uses the read API to access the service providing device 70 corresponding to the connection destination (endpoint) indicated in the request. Then, the API processing unit 17 executes the requested processing by cooperating with the service providing device 70 using the API.

Next, when the processing according to the client's request is successful (YES in step S36), the API processing unit 17 shifts the processing to step S37. On the other hand, when the processing according to the client's request fails (NO in step S36), the API processing unit 17 shifts the processing to step S45.

In step S45, when the API control request is received from the device 50 in step S301, the device communication unit 11 transmits a processing failure notification indicating that the requested processing has failed to the requesting device 50. .. On the other hand, when the API control request is received from the client terminal 90 in step S302, the terminal communication unit 12 is shown in the application information using the notification protocol shown in the application information read in step S32. A processing failure notification is transmitted to the client terminal 90 having the management application 900 corresponding to the notification URL. As a result, the communication unit 51 of the device 50 or the communication unit 91 of the client terminal 90 receives the processing failure notification transmitted from the device management device 10.

In step S37, when the API control request is received from the device 50 in step S301, the device communication unit 11 transmits the processing result executed in step 35 to the requesting device 50. On the other hand, when the API control request is received from the client terminal 90 in step S302, the terminal communication unit 12 is shown in the application information using the notification protocol shown in the application information read in step S32. The processing result executed in step 35 is transmitted to the client terminal 90 having the management application 900 corresponding to the notification URL. As a result, the communication unit 51 of the device 50 or the communication unit 91 of the client terminal 90 receives the processing result transmitted from the device management device 10.

Next, the billing processing unit 18 searches the billing condition management DB 1004 (see FIG. 5B) using the client ID received in step S301 or step S302 and the API ID of the API processed in step S35 as search keys. By doing so, the corresponding billing condition is read out (step S38). Then, the billing processing unit 18 performs billing processing for the client based on the billing condition read in step S38 and the processing result executed in step S35 (step S39). The billing processing unit 18 determines the billing amount for each client based on, for example, the calculation formula of the evaluation function shown in the read billing condition and the processing result such as the number of calls from the client or the constant connection time. calculate.

Next, the device control unit 21 searches the alert condition management DB 1005 (see FIG. 6A) using the device ID of the device 50 for which processing was executed in step S35 and the apiID corresponding to the processing content as search keys. , The alert condition associated with the same device ID and apiID set as the device ID and apiID corresponding to the processing result is read out via the storage / reading unit 19 (step S40). Then, the determination unit 14 determines whether the charge amount processed in step S39 corresponds to the alert condition read in step S40 (step S41). If the charge amount by the charge processing unit 18 is equal to or greater than the charge amount threshold value shown in the alert condition or exceeds the charge amount threshold value, the determination unit 14 determines that the alert condition is satisfied and determines that an alert is required. .. On the other hand, if the charge amount by the charge processing unit 18 is less than or less than the charge amount threshold indicated in the alert condition, the determination unit 14 determines that the alert condition does not apply, and the alert is unnecessary. Judge that there is.

When the determination unit 14 determines that an alert is necessary (alert required) (YES in step S41), the determination unit 14 shifts the process to step S42. On the other hand, when the determination unit 14 determines that the alert is unnecessary (NO in step S41), the determination unit 14 shifts the process to step S43.

Next, the terminal communication unit 12 uses the notification protocol shown in the application information read in step S32 to the client terminal 90 having the management application 900 corresponding to the notification URL shown in the application information. In response, an alert notification indicating that the billing amount is equal to or greater than the threshold or exceeds the threshold is sent. As a result, the communication unit 91 of the client terminal 90 receives the alert notification transmitted from the device management device 10.

Then, the billing processing unit 18 registers the processing history charged in step S39 in the processing history management DB 1008 (see FIG. 8A) (step S43). As the processing history, the billing processing unit 18 records the device ID of the device 50 whose processing was executed in step S35, the apiID corresponding to the processing content, the request corresponding to the executed processing, and the history of the billing amount processed. It is associated and registered in the processing history management DB 1008. The billing processing unit 18 may also register a time stamp indicating the time when the processing is executed.

In this way, the remote management system 1 executes API processing according to the type of request requested by the client, and performs billing processing based on the executed processing history and preset management conditions. As a result, the remote management system 1 can perform billing processing according to the usage status of the API of the client.

Further, the remote management system 1 is configured to perform billing processing only when the API processing is successful and not to charge if the processing is not successful for some reason. Therefore, for example, a processing failure may occur. Even for APIs that are known to occur frequently, it is possible to realize flexible billing processing according to the actual usage situation. Further, when the device 50 is always connected to the device management device 10, the remote management system 1 uses bidirectional communication such as WebSocket or MQTT by performing a billing process according to the length of the connection time. In addition, billing processing can be performed according to the usage status of communication resources.

The device management device 10 may be configured to collectively execute the billing process and the alert notification process in steps S38 to S42 by batch processing instead of executing them each time. In this case, the device management device 10 stores the processing content executed in step S35 in the processing history management DB 1008, and periodically executes billing processing and alert notification processing using the stored processing history.

-Device control processing according to the API usage status Next, with reference to FIGS. 15 to 18, a processing for controlling the operation (behavior) of the device 50 according to the API usage status will be described. FIG. 15 is a sequence diagram showing an example of device control processing according to the usage status of API in the remote management system according to the embodiment. Note that FIGS. 15 to 18 will be described as processing after the billing processing shown in FIGS. 13 and 14 is executed. Further, the processes shown in FIGS. 15 to 16 may be performed each time the processing using the API is performed, or may be performed, for example, at the timing of periodically reviewing the behavior of the device 50. ..

First, the device control unit 21 of the device management device 10 executes device control processing according to the processing history executed by the API processing unit 17 (step S501). Here, the details of the device control process in the device management device 10 will be described with reference to FIG. FIG. 16 is a flowchart showing an example of device control processing in the device management device according to the embodiment.

The device control unit 21 searches for the device control condition management DB 1006 (see FIG. 6B) using the device ID of the device 50 for which the process was executed in step S35 as a search key, so that the device 50 for which the process is executed is searched. The device control condition associated with the same device ID as the device ID is read out via the storage / reading unit 19 (step S51). Further, the device control unit 21 searches the process history management DB 1008 (see FIG. 8A) using the device ID of the device 50 for which the process was executed in step S35 as a search key, so that the device 50 for which the process is executed is performed. The processing history associated with the same device ID as the device ID of is read out via the storage / reading unit 19 (step S52).

Next, the determination unit 14 determines the necessity of device control using the device control conditions read in step S51 and the processing history read in step S52 (step S53). The determination unit 14 determines the necessity of device control by comparing the billing amount history shown in the processing history with the billing amount threshold value shown in the device control condition. If the billing amount history is equal to or higher than the billing amount threshold value or exceeds the billing amount threshold value, the determination unit 14 determines that device control is necessary, and determines that the device 50 needs to be controlled based on the command definition shown in the device control condition. Determined as the control content.

Next, when the control content determined in step S53 is related to the change of the communication setting of the device 50 (YES in step S54), the determination unit 14 shifts the process to step S55. For example, when the control content is a command indicating a change in the polling frequency (communication frequency) (for example, the command "{" command ": {" polling_interval ": 10}}"), the determination unit 14 controls the communication setting. It is judged that the content is related to the change of. Then, the device control unit 21 is associated with the corresponding device ID by searching the communication setting management DB 1009 (see FIG. 8B) using the device ID of the device 50 for which the process was executed in step S35 as a search key. Change the communication settings (step S55). For example, when the control content is a command indicating a change in the communication frequency, the device control unit 21 changes the communication frequency included in the communication setting to the value indicated by the command.

On the other hand, in step S54, if the control content determined in step S53 is not the content related to the change of the communication setting of the device 50 (NO in step S54), the determination unit 54 shifts the process to step S56. In step S56, when the control content determined in step S53 is the content related to the API usage restriction (YES in step S56), the determination unit 14 shifts the process to step S57. For example, when the control content is a command related to API usage restriction (for example, the command "IOTPF_FORBIDDEN_ACCESS"), the determination unit 14 determines that the control content is content related to API usage restriction.

Then, the device control unit 21 is associated with the corresponding device ID by searching the device information management DB 1001 (see FIG. 4A) using the device ID of the device 50 for which the process was executed in step S35 as a search key. The communication prohibition flag is changed (step S57). The device control unit 21 changes, for example, the communication prohibition flag included in the device information from "false" to "true".

In step S56, the determination unit 14 ends the process when the control content determined in step S53 is not the content related to the API usage restriction (NO in step S56). If the control content does not correspond to any of the communication setting change and API usage restriction, for example, the control content is a command to shift the device 50 to the sleep state or the stop state (for example, the command "{" stateChange ": For example, "sleep"} "or the command" {"stateChange": "stop"} ").

In this way, the device management device 10 determines the necessity or control content of device control based on the preset device control conditions and the processing history of the executed API, so that the actual client usage status can be determined. It is possible to dynamically control the equipment according to the situation. Further, when the processing history corresponds to a predetermined device control condition, the device management device 10 changes the communication frequency with the device 50, for example, for the purpose of use of the device 50, the purpose of use, the financial power of the client, or the like. The behavior of the device 50 can be flexibly controlled according to the necessity of communication based on the device 50. Further, when the processing history corresponds to a predetermined device control condition, the device management device 10 limits the use of the API of the device 50 so that excessive use of the API does not occur, so that, for example, the device 50 goes out of control. Even if it becomes unmanageable due to the above, it is possible to prevent unintended billing by the client.

Returning to FIG. 15, the device communication unit 11 transmits a device control request according to the control content determined in the process of FIG. 16 to the device 50 (step S502). This device control request includes a command indicating the control content determined in step S15. As a result, the communication unit 51 of the device 50 receives the device control request transmitted from the device management device 10.

The setting unit 55 of the device 50 updates the setting of the device 50 corresponding to the control content in response to the device control request received in step S502 (step S503). The setting unit 55 changes the behavior of the device 50 by updating the settings of the device 50. The setting unit 55 may reboot the device 50 if necessary. Then, the communication unit 51 transmits a setting update notification indicating that the setting update of the device 50 is completed to the requesting device management device 10 (step S504). As a result, the device communication unit 11 of the device management device 10 receives the setting update notification transmitted from the device 50.

The terminal communication unit 12 of the device management device 10 uses the notification protocol shown in the application information read in step S32, and has a client terminal having a management application 900 corresponding to the notification URL shown in the application information. A control result notification indicating the control result for the device 50 is transmitted to the 90 (step S505). Then, the communication unit 91 of the client terminal 90 transmits a reception notification indicating that the device control result has been received to the device management device 10 (step S506).

As described above, the remote management system 1 is based on the billing amount according to the processing history of the API executed in response to the request requested by the client and the threshold value of the billing amount shown in the set device control condition. By determining the operation (behavior) of the device 50, the device 50 can be dynamically controlled according to the usage status of the API for each client.

Here, another example of the device control process in the device management device 10 will be described with reference to FIGS. 17 and 18. First, with reference to FIG. 17, a process of changing the connection destination of the request from the client according to the usage status of the API will be described. FIG. 17 is a flowchart showing an example of a device endpoint change process in the device management device according to the embodiment. The process shown in FIG. 17 is executed in the process of step S501 in FIG. 15, similarly to FIG.

The device control unit 21 responds to the processing result by searching the connection destination condition management DB 1007 (see FIG. 7) using the device ID of the device 50 for which the processing was executed in step S35 and the apiID corresponding to the processing content as a search key. The connection destination condition associated with the same device ID and apiID set as the device ID and apiID is read out via the storage / reading unit 19 (step S61). Further, the device control unit 21 searches the process history management DB 1008 (see FIG. 8A) using the device ID of the device 50 for which the process was executed in step S35 as a search key, so that the device 50 for which the process is executed is performed. The processing history associated with the same device ID as the device ID of is read out via the storage / reading unit 19 (step S62).

Next, the determination unit 14 determines whether or not the connection destination needs to be changed by using the connection destination condition read in step S61 and the processing history read in step S62 (step S63). The determination unit 14 determines the necessity of changing the connection destination by comparing the charge amount history shown in the processing history with the charge amount threshold value shown in the connection destination condition.

When the determination unit 14 determines that the connection destination needs to be changed (YES in step S63), the determination unit 14 shifts the process to step S64. If the billing amount history is equal to or greater than the billing amount threshold value or exceeds the billing amount threshold value, the determination unit 14 determines that the connection destination needs to be changed. On the other hand, when the determination unit 14 determines that it is not necessary to change the connection destination (NO in step S63), the determination unit 14 ends the process without performing device control.

Next, the device control unit 21 searches the communication setting management DB 1009 (see FIG. 8B) using the device ID of the device 50 for which the process was executed in step S35 as a search key, and associates the device ID with the corresponding device ID. The changed communication setting is changed (step S64). For example, the device control unit 21 changes the connection destination included in the communication setting to the connection destination shown in the connection destination condition read in step S62, and adds an endpoint of the device 50. In this case, the device control unit 21 suppresses the amount charged to the client by setting the device 50 as a connection destination with a low-performance or inexpensive endpoint.

Then, the billing processing unit 18 searches the billing condition management DB 1004 (see FIG. 5B) using the device ID of the device 50 whose processing was executed in step S35 and the apiID corresponding to the processing content as a search key. The billing condition associated with the same client ID and apiID set as the device ID and apiID corresponding to the processing result is updated (step S65). In this case, the billing processing unit 18 updates the billing conditions so as to correspond to the charge setting of the connection destination changed in step S64.

In this way, the device management device 10 changes the communication endpoint of the device 50 according to the usage status of the API. As a result, the device management device 10 can flexibly change or expand the endpoint of the device 50 to which the request requested by the client is connected according to the usage status of the API and the billing amount associated with the usage status. can.

Next, with reference to FIG. 18, a process of controlling the operation (behavior) of the device 50 according to the connection time of the communication in the constant connection format will be described. FIG. 18 is a flowchart showing an example of a process of changing a communication protocol with a device in the device management device according to the embodiment. The process shown in FIG. 18 is executed in the process of step S501 in FIG. 15, similarly to FIGS. 16 and 17.

The connection time management unit 22 searches the connection time management DB 1010 (see FIG. 9) using the device ID of the device 50 for which processing was executed in step S35 as a search key, and thereby has the same device ID as the device ID corresponding to the processing result. The connection time information associated with the above is read out via the storage / reading unit 19 (step S71).

Next, the determination unit 14 determines whether the connection time (connection history) in the constant connection state shown in the connection time information read in step S61 has elapsed a predetermined time set in advance. When the determination unit 14 determines that the connection time in the constant connection state has elapsed (YES in step S72), the determination unit 14 shifts the process to step S73. On the other hand, when the determination unit 14 determines that the connection time in the constant connection state has not elapsed (NO in step S72), the determination unit 14 ends the process without performing device control.

Next, the device control unit 21 searches the communication setting management DB 1009 (see FIG. 8B) using the device ID of the device 50 for which the process was executed in step S35 as a search key, and associates the device ID with the corresponding device ID. The changed communication setting is changed (step S73). For example, the device control unit 21 changes the communication protocol included in the communication setting from the always-on type protocol to the connection request / response type protocol.

Then, the billing processing unit 18 searches the billing condition management DB 1004 (see FIG. 5B) using the device ID of the device 50 whose processing was executed in step S35 and the apiID corresponding to the processing content as a search key. The billing condition associated with the same client ID and apiID set as the device ID and apiID corresponding to the processing result is updated (step S74). In this case, the billing processing unit 18 updates the billing conditions so as to correspond to the charge setting of the communication protocol changed in step S73.

As described above, when the device management device 10 is always connected to the device 50, the device management device 10 changes the communication protocol used for communication with the device 50 according to the length of the connection time. As a result, the device management device 10 can control the behavior and billing conditions of the device 50 according to the usage status of the communication resource even when the communication of the always-on type such as WebSocket or MQTT is used.

○ Setting when one device is shared by a plurality of clients Next, a case where one device 50 is shared by a plurality of clients (management application 900) will be described with reference to FIG. When the device 50 is shared by a plurality of clients, it is necessary to set the ratio of payment of the billing amount to the device 50. Therefore, the storage unit 1000 of the device management device 10 replaces the device information management table shown in FIG. 4 (A) with the device information configured by the device information management table shown in FIG. 19 (A). Build management DB 1001. The device information management DB 1001 configured by the device information management table shown in FIG. 19A is an example of a payment ratio storage means.

The device information management table shown in FIG. 19A includes, in addition to the configuration of the device information management table of FIG. 4A, an API payment ratio indicating the payment ratio of the charge amount related to sharing. In FIG. 19A, the device management device 10 uniquely identifies the device information by the combination of the device ID and the application ID. Further, in the example of FIG. 19A, the device 50 of the device ID "dev001" is managed only by the management application 900 of the application ID "app001", but the device 50 of the device ID "dev002" is the application ID. It is managed by two management apps 900, "app001" and "app002". The payment ratio of the billing amount of the device 50 of the device ID "dev002" is 0.8 for "app001" and 0.2 for "app002". That is, as for the payment for the charged amount, 80% of the charged amount is charged to "app001" and 20% is charged to "app002". In this way, when the device management device 10 shares the specific device 50 with a plurality of clients, the billing target can be sorted by presetting the payment ratio.

Further, in this case, the storage unit 1000 of the device management device 10 is configured by the alert condition management table shown in FIG. 19 (B) instead of the alert condition management table shown in FIG. 6 (A). Alert condition management DB 1005 is constructed. The alert condition management table shown in FIG. 19B includes an application ID that identifies the management application 900 in addition to the configuration of the alert condition management table of FIG. 6A. In FIG. 19B, the device management device 10 uniquely identifies the alert condition by the combination of the device ID, the application ID, and the apiID.

Similar to FIG. 19A, in the example of FIG. 19B, the device 50 of the device ID “dev001” is managed only by the management application 900 of the application ID “app001”, but the device ID “dev002”. The device 50 is managed by two management applications 900 of the application IDs “app001” and “app002”. When the device management device 10 manages one device 50 (for example, the device 50 of the device ID "dev002") by a plurality of clients (for example, the management application 900 of the application IDs "app001" and "app002"). Different alert conditions can be set for each client. As a result, the device management device 10 can be used by the client according to the API payment ratio set in the device information shown in FIG. 19A, the purpose or use of managing the device 50, the financial power of the client, and the like. Since the alert condition for each device 50 can be set, the alert notification can be sent at a timing suitable for the client.

In this way, the device management device 10 sets the payment ratio of the billing amount for each of the plurality of management applications 900 that manage one device 50, and the alert condition. As a result, the device management device 10 can calculate the billing amount for each of the plurality of management applications 900 that manage one device 50. Therefore, for example, the management application 900 is added according to the purpose or use of managing the device 50. be able to.

● Effect of the embodiment As described above, the remote management system 1 charges the client based on the processing history of the API executed in response to the request requested by the client and the preset management conditions. By determining the operation (behavior) of the device 50, the device 50 can be dynamically controlled according to the usage status of the API for each client. For example, when the billing amount exceeds a certain amount as a result of the device 50 performing a large amount of polling communication, the remote management system 1 reduces the frequency of polling communication or switches to cheaper always-on communication. You can change the communication settings of the device 50. Further, the remote management system 1 can change the communication setting of the device 50 by connecting the device 50 to a lower function or cheaper endpoint, for example, when the billing amount becomes a certain amount or more.

● Summary ●
As described above, the device management device according to the embodiment of the present invention is the device management device 10 that manages the device 50 in the local network 7, and acquires a request for the device 50 requested by the client. Executes the process according to the type of the acquired request. Then, the device management device 10 changes the communication setting of the device 50 according to the executed processing history, and issues a device control request (an example of a control request) requesting a setting change to the changed communication setting. Send to 50. As a result, the device management device 10 can dynamically change the communication settings of the device 50 according to the usage status.

Further, the device management device 10 according to the embodiment of the present invention sets management conditions (for example, device control conditions or connection destination conditions) of the device 50 according to the executed processing history, and the executed processing history is recorded. If the management conditions are met, the communication settings of the device 50 are changed. As a result, the device management device 10 can change the communication settings according to the usage status of the client by setting various management conditions for each client in advance.

Further, the device management device 10 according to the embodiment of the present invention performs billing processing according to the executed processing history when the processing according to the type of the acquired request is successful. Then, the device management device 10 sets management conditions (for example, device control conditions or connection destination conditions) according to the billing amount for each client, and the billing amount according to the executed processing history corresponds to the management conditions. , Change the communication settings of the device 50. As a result, the device management device 10 performs billing processing based on the processing history executed according to the type of request requested by the client and the preset management conditions, and thus billing processing according to the usage status of the client. It can be performed. Further, the device management device 10 performs billing processing only when the processing is successful, and does not charge when the processing is not successful for some reason. Therefore, for example, processing failures occur frequently. Even for processing that is known in advance, it is possible to realize flexible billing processing according to the actual usage situation.

Further, the device management device 10 according to the embodiment of the present invention sets an alert condition according to the billing amount of the client as a management condition of the device 50, and the billing amount of the client corresponds to the set alert condition. If so, an alert notification is sent to the client. Further, when the device 50 is shared by a plurality of clients, the device management device 10 stores a payment ratio for each client with respect to the billing amount according to the executed processing history, and uses the stored payment ratio as the stored payment ratio. Set the corresponding alert conditions. As a result, the device management device 10 can set alert conditions for the device 50 for each client according to the set payment ratio, the purpose or use of managing the device 50, the financial power of the client, and the like. , Alerts can be sent at the right time for the client.

Further, in the device management device 10 according to the embodiment of the present invention, when the charge amount according to the executed processing history corresponds to the management condition of the device 50 (for example, the connection destination condition), the communication setting of the device 50 is set. , Change the connection destination of the request of the device 50. Further, when the connection time for constant connection with the device 50 has elapsed, the device management device 10 changes the communication protocol used for communication with the device 50 as the communication setting of the device 50. Further, when the charge amount according to the executed processing history corresponds to the management condition (for example, the device control condition), the device management device 10 changes the communication frequency with the device 50 as the communication setting of the device 50. As a result, the device management device 10 can change various communication settings with the device 50 based on the executed processing history and the set management conditions, so that the device 50 behaves according to the usage status. It can be controlled flexibly.

Further, the device management device 10 according to the embodiment of the present invention sets a restriction condition for restricting communication with the device management device 10 according to the billing amount of the client as a management condition, and corresponds to the executed processing history. When the charged amount satisfies the restriction condition, the device 50 is set to restrict the use of the API, and a device control request (an example of the control request) for restricting the use of the API is transmitted to the client. As a result, when the processing history corresponds to the restriction condition, the device management device 10 limits the use of the API of the device 50 so that excessive use of the API does not occur, so that, for example, the device 50 manages due to a runaway or the like. Even if it becomes impossible, it is possible to prevent unintended billing by the client.

● Supplement ●
Each function of the embodiment described above can be realized by one or more processing circuits. Here, the "processing circuit" in the present embodiment is a processor programmed to execute each function by software like a processor implemented by an electronic circuit, and a processor designed to execute each function described above. It shall include devices such as ASIC (Application Specific Integrated Circuit), DSP (digital signal processor), FPGA (field programmable gate array), SOC (System on a chip), GPU (Graphics Processing Unit) and conventional circuit modules. ..

Further, the various tables of the embodiment described above may be generated by the learning effect of machine learning, and by classifying the data of each related item by machine learning, the table is not used. You may. Here, machine learning is a technique for making a computer acquire learning ability like a human being, and the computer autonomously generates an algorithm necessary for judgment such as data identification from learning data taken in advance. However, it refers to a technology that applies this to new data to make predictions. The learning method for machine learning may be any of supervised learning, unsupervised learning, semi-supervised learning, intensive learning and deep learning, and may be a learning method combining these learning methods, and machine learning. It doesn't matter how you learn for.

Although the device management device, the remote management system, the device control method, and the program according to one embodiment of the present invention have been described so far, the present invention is not limited to the above-described embodiment, and other embodiments are added. , Changes or deletions, etc. can be made within the range conceivable by those skilled in the art, and are included in the scope of the present invention as long as the actions and effects of the present invention are exhibited in any of the embodiments.

1 Remote management system 3 Management system 5 Communication network 7 Local network 10 Equipment management device 11 Equipment communication unit (example of acquisition means, example of transmission means)
12 Terminal communication unit (example of acquisition means)
16 Condition setting unit (an example of condition setting means)
18 Billing processing unit (an example of billing processing means)
17 API processing unit (an example of processing execution means)
21 Equipment control unit (an example of communication control means)
30 Mediation device 50 Equipment 55 Setting unit (example of setting means)
70 Service providing device 90 Client terminal 1001 Device information management DB (example of payment ratio storage means)
1008 Processing history management DB (an example of processing history storage means)

Japanese Patent No. 652718

Claims (15)

A device management device that manages devices in a local network.
An acquisition means for acquiring a request for the device requested by a client, and
A process execution means that executes a process according to the type of the acquired request, and a process execution means.
A communication control means that changes the communication settings of the device according to the executed processing history, and
A transmission means for transmitting a control request requesting a setting change to the changed communication setting to the device, and a transmission means.
Equipment management device equipped with. The device management device according to claim 1.
A condition setting means for setting management conditions of the device according to the processing history is provided.
The communication control means is a device management device that changes the communication settings when the processing history corresponds to the management conditions. The device management device according to claim 2, further
A billing processing means for performing billing processing according to the processing history is provided.
The condition setting means sets the management conditions according to the billing amount for each client, and sets the management conditions.
The communication control means is a device management device that changes the communication setting when the billing amount according to the processing history corresponds to the management condition. The device management device according to claim 3, wherein the billing processing means performs the billing processing when the processing by the processing executing means is successful. The device management device according to claim 3 or 4.
A processing history storage means for storing the processing history is provided.
The billing processing means is a device management device that performs the billing processing using the stored processing history. The condition setting means sets alert conditions according to the billing amount of the client as the management conditions.
The device management device according to any one of claims 3 to 5, wherein the transmission means transmits an alert notification to the client when the billing amount of the client corresponds to the set alert condition. The device management device according to any one of claims 3 to 6.
When the device is shared by a plurality of clients, a payment ratio storage means for storing the payment ratio for each client with respect to the billing amount according to the processing history is provided.
The condition setting means is a device management device that sets the alert condition according to the stored payment ratio. The communication control means is any one of claims 3 to 7 for changing the connection destination of the request of the device as the communication setting when the billing amount according to the processing history corresponds to the management condition. The equipment management device described in. One of claims 3 to 8, wherein the communication control means changes the communication protocol used for communication with the device as the communication setting when the connection time for constant connection with the device has elapsed. The equipment management device described in the section. As the management condition, the condition setting means sets a restriction condition for restricting communication with the device management device according to the billing amount of the client.
When the billing amount according to the processing history satisfies the restriction condition, the communication control means sets the device to restrict the use of the API.
The device management device according to any one of claims 3 to 9, wherein the transmission means transmits the control request for limiting the use of the API to the client. The communication control means according to any one of claims 3 to 10 for changing the communication frequency with the device as the communication setting when the billing amount according to the processing history corresponds to the management condition. Equipment management device. The device management device according to any one of claims 1 to 11, wherein the process executing means reads an API corresponding to the type of the acquired request and executes a process using the read API. A remote management system including the device management device according to any one of claims 1 to 12 and the device.
The device is
A remote management system including a setting means for updating the settings of the device based on the control request transmitted from the device management device. A device control method executed by a device management device that manages devices in a local network.
The acquisition step to acquire the request for the device requested by the client, and
A process execution step that executes a process according to the type of the acquired request, and
A communication control step that changes the communication settings of the device according to the executed processing history,
A transmission step of transmitting a control request requesting a setting change to the changed communication setting to the device, and a transmission step.
Device control method to execute. For device management devices that manage devices in the local network
The acquisition step to acquire the request for the device requested by the client, and
A process execution step that executes a process according to the type of the acquired request, and
A communication control step that changes the communication settings of the device according to the executed processing history,
A transmission step of transmitting a control request requesting a setting change to the changed communication setting to the device, and a transmission step.
The program to be executed.

Images