WO2021241672A1 - ネットワーク機器管理環境、ネットワーク機器管理装置子機及びネットワーク機器管理装置親機 - Google Patents

ネットワーク機器管理環境、ネットワーク機器管理装置子機及びネットワーク機器管理装置親機 Download PDF

Info

Publication number
WO2021241672A1
WO2021241672A1 PCT/JP2021/020140 JP2021020140W WO2021241672A1 WO 2021241672 A1 WO2021241672 A1 WO 2021241672A1 JP 2021020140 W JP2021020140 W JP 2021020140W WO 2021241672 A1 WO2021241672 A1 WO 2021241672A1
Authority
WO
WIPO (PCT)
Prior art keywords
network device
device management
slave unit
master unit
outlet
Prior art date
Application number
PCT/JP2021/020140
Other languages
English (en)
French (fr)
Inventor
日野利信
福井威徳
宇城久仁子
Original Assignee
バリューソリューション株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by バリューソリューション株式会社 filed Critical バリューソリューション株式会社
Publication of WO2021241672A1 publication Critical patent/WO2021241672A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/26—Power supply means, e.g. regulation thereof
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass

Definitions

  • the present invention relates to a monitoring device for a device connected to a network, particularly a device having an automatic power restart function.
  • the number of network communication devices (hereinafter referred to as network devices) connected to the network and the Internet is increasing day by day.
  • Security is added to DHCP to provide flexible connectivity to devices connected to the network, HTTP to provide information to an unspecified number of people connected to the network, SNMP used to monitor network devices, and TCP.
  • the number of applications provided for providing services such as SSL is increasing day by day.
  • Cited Document 1 Japanese Patent Application Laid-Open No. 2004-221867
  • This document describes a technique for connecting a network device to the power supply section of a network device power supply control device and rebooting the power supply section of the network device monitoring device to reboot the network device connected to this power supply section. There is.
  • the maximum number of managed units is defined by the number of outlets in the power supply unit of the network device power supply control device.
  • the maximum number of managed units is defined by the number of outlets in the power supply unit of the network device power supply control device.
  • An object of the present invention is to provide a means capable of managing a plurality of network devices without being restricted by the length of a power cable or the number of outlets.
  • the network device management environment includes a slave unit that supplies power to the network device and a master unit that communicates with the slave unit via the Internet, and does the slave unit supply power to the network device? It includes a switch to determine, and is characterized in that the master unit controls the slave unit.
  • This network device management environment may be characterized in that the master unit controls the slave unit by issuing a command.
  • This network device management environment may be characterized in that the command is a survival confirmation command for confirming the survival of the slave unit.
  • This network device management environment may be characterized in that the command is a condition monitoring command for acquiring information about the outlet of the slave unit.
  • This network device management environment may be characterized in that the command is an outlet On / Off instruction command that controls an arbitrary outlet of the slave unit.
  • This network device management environment may be characterized in that commands are sent and received using the HTTP communication protocol.
  • This network device management environment may be characterized by notifying the master unit that the slave unit is operating normally by a response from the slave unit to a command.
  • This network device management environment may be characterized in that the master unit updates the outlet information of the slave unit in response to a command from the slave unit.
  • This network device management environment may be characterized in that the power supply to a specific outlet of the slave unit is turned on by a command. Further, this network device management environment may be characterized in that the power supply of a specific outlet of the slave unit is turned off by a command.
  • This network device management environment may further include a monitoring PC, and the master unit may provide the monitoring PC with outlet information of the slave unit in response to a request from the monitoring PC.
  • This network device management environment may be further characterized in that the master unit manages the network device.
  • Another network device management environment includes a first slave unit that supplies power to the first network device, a second slave unit that supplies power to the second network device, and an Internet.
  • Each slave unit includes a master unit that communicates with the slave unit, and each slave unit includes a switch that determines whether to supply power to the network device, and the master unit controls each slave unit.
  • This network device management environment may be characterized in that the master unit updates the outlet information of each slave unit by the response from the first slave unit and the response from the second slave unit to the command.
  • This network device management environment may be characterized in that the master unit manages the outlet information of the first slave unit and the second slave unit in one table.
  • These network device management environments may be characterized in that the master unit manages the first network device and the second network device.
  • Another network device management environment is a slave unit that supplies power to the network device, a first master unit that communicates with the slave unit via the Internet, and a slave unit that communicates with the slave unit via the Internet.
  • a second master unit and a slave unit include a switch for determining whether to supply power to a network device, and the first master unit and the second master unit control the slave unit. ..
  • This network device management environment may be characterized in that the function of the first master unit and the function of the second master unit are the same.
  • This network device management environment may be characterized in that the function of the first master unit and the function of the second master unit are different.
  • the network device management device slave unit supplies power to the network device via the outlet, and the network device management device slave unit that has received the information monitoring command has outlet information regarding all the outlets of the network device management device slave unit. Is characterized by replying to the sender of the status monitoring command.
  • Another network device management device slave unit supplies power to the network device via the outlet, and this network device management device slave unit that has received the survival confirmation command confirms its own survival. It is characterized by notifying the command sender.
  • Another network device management device slave unit supplies power to the network device via the outlet, and this network device management device slave unit that has received the outlet On / Off instruction command is the outlet On. It is characterized by controlling the power supply of its own outlet specified by the Off instruction command.
  • This network device management device slave unit may be characterized in that the control result is transmitted to the outlet On / Off instruction command transmission source.
  • the network device management device master unit cooperates with a network device management device slave unit that supplies power to a network device via an outlet, and this network device management device master unit is a network device management device. It is characterized by sending a status monitoring command to the slave unit.
  • the network device management device master unit cooperates with a network device management device slave unit that supplies power to a network device via an outlet, and this network device management device master unit is a network device management device. It is characterized by sending a survival confirmation command to the slave unit.
  • the network device management device master unit cooperates with a network device management device slave unit that supplies power to a network device via an outlet, and this network device management device master unit is a network device management device. It is characterized in that an outlet On / Off instruction command is transmitted to a slave unit.
  • These network device management device master units may be characterized by monitoring the status of network devices connected to the network device management device slave units.
  • the network device management device master unit that receives the request from the management PC may be characterized in that the outlet information collected from the network device management device slave unit is sent back to the management PC.
  • the network device management device slave unit supplies power to the network device via the outlet, and may be characterized by including a first LAN IF and a second LAN IF.
  • This network device management device slave unit may be characterized in that the first LAN IF is a wired LAN. Further, this network device management device slave unit may be characterized in that the first LAN IF is a wireless LAN.
  • Another network device management device master unit communicates with the network device management device slave unit that supplies power to the network device via the outlet, and communicates with the first LAN IF and the second LAN. It is characterized by including IF.
  • This network device management device master unit may be characterized in that the first LAN IF is a wired LAN. Further, the network device management device master unit may be characterized in that the first LAN IF is a wireless LAN.
  • the network device monitoring means according to the present invention makes it possible to perform management accompanied by restarting the power supply of network devices existing at physically distant distances. Further, the network device monitoring means according to the present invention can dramatically increase the number of network devices to be managed for power management.
  • connection diagram which shows an example of the operating environment of the network equipment monitoring apparatus which concerns a prior application. It is a connection diagram which shows an example of the operating environment of the network equipment monitoring apparatus which concerns on 1st Embodiment of this invention. It is an external view (front view) of an example of a slave unit. It is a conceptual diagram about the communication system between a master unit and a slave unit of this invention. It is a conceptual diagram explaining the place where the text data which concerns on FIG. 4 is included in the HTTP request. It is a conceptual diagram explaining the place where the text data which concerns on FIG. 4 is contained in the HTTP response. It is a conceptual diagram about the communication system between a master unit and a slave unit at the time of "survival confirmation".
  • FIG. 1 is a connection diagram showing an example of the operating environment of the network equipment monitoring device related to the prior application.
  • This operating environment is configured by connecting a monitoring PC 1, a network device monitoring device 2, a monitoring target A3, and a monitoring target B4 across a LAN 7.
  • the monitoring PC 1 is a PC for monitoring the status of the network device monitoring device 2. It is assumed that the browser can be operated on this PC. Further, the network device monitoring device 2 generates and outputs data that can be displayed by the browser operating on the monitoring PC 1.
  • the network device monitoring device 2 is a monitoring device that monitors the status of the hardware and software modules of the monitoring target A3 and the monitoring target B4 that it supplies power to.
  • the network device monitoring device 2 has outlets for power supply for the number of monitoring targets. These outlets are controlled by a relay (not shown) in the network device monitoring device 2, and are configured to be able to turn on / off the power supply internally.
  • the monitoring target A3 is a target (network device) monitored by the network device monitoring device 2.
  • the router function is provided to the user and the like.
  • the power cable of the monitoring target A3 is connected to the outlet of the network device monitoring device 2. As a result, the power supply of the monitoring target A3 can be turned on / off by the control of the network device monitoring device 2.
  • the monitoring target B4 is a target to be monitored by the network device monitoring device 2.
  • the HTTP server function and the payment server function are provided to the user and the like.
  • the power cable of the monitoring target B4 is connected to the outlet of the network device monitoring device 2. As a result, the power supply to the monitoring target B4 can be turned on / off by controlling the network device monitoring device 2.
  • the user is guided by the data of the homepage described in the HTML format provided by the HTTP server function on the monitored A3, and is provided with the service of the payment server function. Therefore, when the HTTP server function is down, the user cannot use the payment server function in most cases. Therefore, when only the payment server function is operating and the other router functions and the HTTP server functions are not operating, the significance of the operation of the payment server function is reduced. In this case, it is significant to restart the monitored target B4.
  • the invention relating to the network device monitoring device related to the prior application is to change the operation depending on whether the HTTP server function is down or the payment server function is down as described above.
  • connection protocol is partially restricted.
  • FIG. 2 is a connection diagram showing an example of the operating environment of the network equipment monitoring device according to the first embodiment of the present invention.
  • the feature of the present invention is that the network device monitoring device 2 of the prior application is divided into a master unit 2a and a slave unit 2b and 2c.
  • the network topology of the present invention is mainly composed of local networks 7 and 8 connected across the Internet 9.
  • the monitoring PC 1 and the master unit 2a are connected to the local network 7.
  • the slave units 2b and 2c are connected to the local network 8, and the monitoring target A3 and the monitoring target B4 are connected.
  • the power cable of the monitoring target A3 is connected to the slave unit 2b, and the power cable of the monitoring target B4 is connected to the slave unit 2c.
  • This network topology includes two local networks 7 and 8 sandwiching the Internet 9.
  • the master unit 2a exists in the local network 7, and the slave units 2b and 2c exist in the local network 8.
  • the monitoring PC 1 and the master unit 2a are connected to the local network 7 so that they can communicate with each other. Further, the monitoring target A3 and the monitoring target B4, and the slave unit 2b and the slave unit 2c are connected to the local network 8. Further, it is connected to the Internet 9 by a router or the like (not shown).
  • the Internet 9 in the present specification is an abstract network for connecting the local network 7 and the local network 8.
  • the Internet is usually defined as "a global network (global information and communication network) that uses the Internet Protocol Suite and interconnects multiple computer networks" (Wikipedia).
  • Wikipedia global information and communication network
  • the Internet 9 in this specification does not assume that an internal network having a clear ownership is excluded, nor does it require globalization. It may be considered as an intermediate route connecting a plurality of computer networks (local network 7 and local network 8 in this specification).
  • the monitoring PC 1 is a monitoring PC for the user to confirm the status of the monitoring target A3 and the monitoring target B4 with respect to the master unit 2a.
  • the monitoring PC1 does not directly inquire about these monitoring targets.
  • the monitoring PC 1 inquires of the master unit 2a about the status of these monitoring targets. Although one monitoring PC is prepared in this figure, a plurality of monitoring PCs 1 may exist.
  • the master unit 2a is a network device monitoring device for directly monitoring the monitoring target A4 and the monitoring target B6. That is, the master unit 2a is in charge of the network monitoring operation (polling, etc.) in the prior application.
  • the master unit 2a confirms the status of these monitoring targets by communicating with the monitoring targets.
  • the master unit 2a has a plurality of slave units for one unit, but a plurality of master units may manage a plurality of slave units.
  • the range of the present invention also includes a form in which a plurality of master units manage one slave unit.
  • the slave unit 2b and the slave unit 2c return the status of 1) the outlet connected to the monitored target A3 and the outlet connected to the monitored target B4 in response to the request from the master unit 2a, and 2) the outlet connected to the monitored target A3 and the monitored target.
  • It is a network device monitoring device characterized in that the output state of the outlet connected to B4 is changed, and 3) the outlet connected to the monitored target A3 and the outlet connected to the monitored target B4 are restarted. That is, each slave unit collects information on the operation regarding On / Off of the power supply and the outlet related thereto in the prior application.
  • Each slave unit supplies power to the monitoring target monitored by the master unit.
  • the slave unit 2b supplies power to the monitored target A3.
  • the slave unit 2c supplies electric power to the monitored target B4.
  • each slave unit does not collect information directly from the network device to be monitored.
  • FIG. 3 is an external view (front view) of an example of the slave unit 2b. Needless to say, the arrangement of each component does not need to be concerned with this figure.
  • the appearance of the slave unit 2b includes an outlet 2b-01, 2b-02, 2b-03, 2b-04, 2b-05, 2b-06, a LAN port 2b-11, and a power cable 2b-12. ..
  • outlets are provided in one handset 2b, which is a product, is a design matter, and may be increased or decreased as necessary.
  • Outlet 2b-01, 2b-02, 2b-03, 2b-04, 2b-05, 2b-06 means a power supply terminal for supplying power to the monitored object and one set of its internal circuit. Therefore, it can be said that the slave unit 2b in this figure has six outlets and can connect up to six network devices.
  • Outlets 2b-01, 2b-02, 2b-05 can supply AC100V power. Further, the outlet 2b-03 can supply DC5V, and the outlet 2b-04 can supply DC12V to the monitoring target.
  • the outlet 2b-06 serves as a contact terminal. These include relays and switching elements (collectively, switches), and can freely turn on and off the power supply.
  • the slave unit 2b can provide information on these outlets to the master unit 2a. Further, the slave unit 2b can operate the switch of each outlet by the command of the master unit 2a.
  • LAN port 2b-11 is a LAN port for connecting to the network 8 in FIG.
  • the slave unit 2b communicates with the master unit 2a via the LAN port 2b-11.
  • the power cable 2b-12 is a power cord for supplying power to the slave unit 2b.
  • the appearance of the master unit 2a is basically the same as that of the slave unit 2b. However, since the master unit 2a does not need to directly supply power to the monitoring target, it differs from the slave unit in that it is established even if the outlet does not exist.
  • HTTP Hypertext Transfer Protocol
  • TSL Transport Layer: Transport Layer Security
  • HTTPS Hypertext Transfer Protocol
  • the initial value 443 is assigned as the well-known port for the communication port number. Therefore, in the present specification, since the master unit 2a, the slave unit 2b, and the slave unit 2c adopt the HTTPS protocol, it means that each of the lower physical layer, data link layer, network layer, and transport layer Internet protocol is supported. Not to mention.
  • TLS negotiation When communicating via HTTPS, establish a session and perform TLS negotiation after starting a TLS session.
  • the authentication method is negotiated and decided, and then authentication and key exchange are performed to determine the common key. After that, this common key will be used for encrypted communication.
  • the common key acquisition process is not directly related to the present invention, the description thereof will be omitted hereafter.
  • the monitoring target A3 and the monitoring target B4 are network devices to be monitored by the master unit 2a.
  • the monitoring target A3 and the monitoring target B4 are not limited to devices (for example, servers) that generally connect to the Internet. However, in order to enable survival reporting, the monitored target A3 and the monitored target B4 are required to implement an arbitrary Internet protocol.
  • FIG. 4 is a conceptual diagram relating to a communication method between the master unit 2a and the slave unit 2b of the present invention.
  • the slave unit 2b is used, but the behavior is of course the same for the slave unit 2c.
  • communication is performed between the master unit and the slave unit using the Get method of the HTTPS method.
  • the HTTPS request is sent including the text data according to the present invention to inform the slave unit 2b whether it is any of the above three types of the "command" according to the present invention.
  • the slave unit 2b returns an HTTPS response including the text data according to the present invention to the master unit 2a, that is, a "response" according to the present invention.
  • Communication is performed with this as one set.
  • HTTPS is a protocol in which the process of acquiring a common key for HTTP is increased, and the configuration of request and response does not change (because it is originally specified by RFC7230). Therefore, in the present specification, HTTPS and HTTP are mixed.
  • the master unit 2a determines that the slave unit 2b itself is not working as a timeout. At this time, it is a design matter of the master unit 2a whether to set the timeout value for each slave unit or to set one timeout value in common.
  • FIG. 5 is a conceptual diagram illustrating where the text data corresponding to the command according to FIG. 4 is included in the HTTP request.
  • FIG. 6 is a conceptual diagram illustrating where in the HTTP response the text data corresponding to the response according to FIG. 4 is included. Since the same data format is used for both HTTPS and HTTP, they will be described with reference to this figure.
  • RFC7230 defines the data format of HTTP request and HTTP response. Note that FIGS. 5 and 6 are related to HTTP and are not related to the present invention, so that the drawing numbers are omitted.
  • HTTP request consists of a request line, a header and a message body.
  • HTTP response is composed of a response line, a header, and a message body.
  • the request line in FIG. 5 is one of the data fields of the HTTP request.
  • the request line must describe the method (communication purpose), the path representing the destination (including the query), and the HTTP version. As described above, it is assumed that the Get method is used in the present invention.
  • the HTTP version is assumed to be 1.1.
  • a communication purpose for the slave unit 2b and additional information (authentication ID and authentication password) thereof are attached to the path of the HTTP request in the present invention in the form of a query.
  • the header in FIG. 5 is a data field representing additional information related to the request. Information such as the character code to be used, keep-alive (does the session continue even after communication ends?), And the specification of the authentication method is described.
  • the message body in FIG. 5 is a data field for sending supplementary information and the like in the HTTP request.
  • CR + LF carriage return + line feed
  • the encrypted data is attached to the query in the request line path. Therefore, the message body of the HTTP request is not used. However, it may be attached to the message body.
  • the response line of the HTTP response in FIG. 6 is one of the data fields of the HTTP response.
  • the HTTP version, status code, supplementary information (mainly detailed information on the status code) and the like are described.
  • the header in FIG. 6 is a data field representing additional information related to the response.
  • the message body in FIG. 6 is a data field to which data to be sent back to the requester is attached.
  • HTML data to be displayed by the requesting browser is attached to this message body and is encrypted.
  • the processing result is attached to the message body and encrypted.
  • the text data that makes the HTTPS request the "command" of the present invention is stored in the query added to the path of the HTTPS request. Further, it is assumed that the text data that makes the HTTPS response the "response" of the present invention is stored in the message body of the HTTPS response. However, they may be included in another request line, response line and header.
  • FIG. 7 is a conceptual diagram regarding a communication method between the master unit 2a and the slave unit 2b at the time of “survival confirmation”. From this figure, parentheses are inserted after the command and response, and the character string included in the parentheses is the character string stored in the query (command) or message body (response) of the request line. The error processing will be described in the explanation of the operation of each hardware (see (Processing of the slave unit survival confirmation module SW2)).
  • the survival confirmation is a command in which the master unit 2a confirms whether the slave unit 2b is operating normally.
  • the master unit 2a issues a command to the slave unit 2b at an arbitrary timing.
  • "HELLO" is described in the request line path query of the HTTPS request (hereinafter referred to as the HTTPS request query) and encrypted.
  • the HTTP module of the slave unit 2b that received the above command sent from the master unit 2a confirms whether this message is the message according to the present invention by the path specified on the request line.
  • the slave unit 2b When the slave unit 2b confirms that this request is a message according to the present invention, the slave unit 2b confirms that the decrypted content of the received query is the text "HELLO". At that time, if necessary, the handset 2b takes into consideration the received header information (character code to be used, etc.).
  • the slave unit 2b If the content of the query after decryption is the text "HELLO", it is understood that the slave unit 2b is being asked about its own operating status. If the slave unit 2b is operating without any problem, the message body of the HTTPS response to be sent back is set as "ALIVE" and returned to the HTTP module after being encrypted. If necessary, the information about the HTTP response header is returned to the HTTP module. If the module of the slave unit 2b according to the present invention is not operating, the HTTPS response cannot be returned as a matter of course because the necessary information is not available. Since the slave unit 2b cannot return the HTTPS response, the response does not reach the master unit 2a, and the master unit 2a processes it as a timeout.
  • the HTTP module (not shown) of the master unit 2a that received this HTTP response confirms that the slave unit 2b is operating by confirming that "ALIVE" is attached to the message body of this HTTP response after decoding. become.
  • FIG. 8 is a conceptual diagram regarding a communication method between the master unit 2a and the slave unit 2b at the time of “status monitoring”.
  • parentheses are inserted after the command and response, and the character string included in the parentheses is the character string stored in the message body. Further, error handling will be described in the description of each hardware as in FIG. 7.
  • “Condition monitoring” in the present specification means collecting all the "outlet” information possessed by the slave unit 2b and replying to the master unit 2b. Therefore, since the information of the slave unit 2b is transmitted to the outside, it is confirmed whether or not the information is provided by the authentication ID and the authentication password.
  • the HTTP module of the slave unit 2b that received the above command sent from the master unit 2a confirms on the request line whether this message is the message according to the present invention.
  • the slave unit 2b decodes the received HTTPS request and confirms that the beginning of the query is the text "STATUS". At that time, if necessary, the slave unit 2b takes into consideration the received header information. If the beginning of the HTTPS request query is the text "STATUS", it is understood that the slave unit 2b is being asked about the status of each outlet of its own.
  • the slave unit 2b extracts the authentication ID and the authentication password from the remaining decrypted HTTPS request queries.
  • the message body is "STATUS" followed by "," (comma) for character-to-character identification, authentication ID, ",” (comma) for character-to-character identification, and authentication password, but these arrangements are design matters. be.
  • the designer may select as appropriate, such as replacing with or &.
  • it is described as using ",” (comma) for character-to-character identification (the same applies hereinafter).
  • the handset 2b compares with the authentication ID and the authentication password held by itself. If the result of the comparison between the authentication ID and the authentication password matches, the slave unit 2b collects the operating status of the outlet in the own hardware. When the collection of the state of each of its own outlets is completed, the response body of the HTTPS response to be sent back is generated.
  • the response body for the HTTPS response starts with the text "RESP,” and then describes the collected outlet information. Details of the outlet information will be described in the description of each hardware (see (Processing of the slave unit status monitoring module SW3)).
  • FIG. 9 is a conceptual diagram regarding a communication method between the master unit 2a and the slave unit 2b at the time of “outlet On / Off instruction”.
  • parentheses are inserted after the command and response, and the character string included in the parentheses is the character string stored in the message body. Further, error handling will be described in the description of each hardware as in FIG. 7.
  • the "outlet On / Off instruction" in the present specification is intended to turn on / off the power supply to the outlet of the slave unit 2b. Therefore, since the operation of the slave unit 2b is involved, it is confirmed whether or not the information is provided by using the authentication ID and the authentication password as in the case of "status monitoring".
  • the HTTP module of the slave unit 2b that received the above command sent from the master unit 2a confirms on the request line whether this message is the message according to the present invention.
  • the slave unit 2b decodes the received HTTPS request and confirms the query. Then, the slave unit 2b confirms that the beginning of the content after the restoration is the text "CONT". At that time, if necessary, the slave unit 2b takes into consideration the received header information. If the beginning of the content of the compound word query is the text "CONT", it is understood that the slave unit 2b is instructed to turn on / off the power supply to its own outlet.
  • the slave unit 2b extracts the authentication ID and the authentication password from the remaining decrypted queries.
  • the handset 2b compares with the authentication ID and the authentication password held by itself. When the comparison between the authentication ID and the authentication password matches, the slave unit 2b executes an operation for the power supply of the outlet (outlet number in FIG. 9) of the number specified in the query after decryption. The power supply state to be changed at this time is also described in the query after decoding (“instruction” in FIG. 9).
  • the slave unit 2b generates a message body of the HTTP response to be sent back with reference to the change result.
  • the "instruction” is 1 byte of data, and means that the relay of the outlet is turned on / off. In the present specification, 1 is defined as On and 0 is defined as Off.
  • the response body for HTTPS response starts with the text "RESULT”, connects the character spacing ",” (comma), and then describes the result of the setting change. Details of the results will be described in the description of each hardware (see (Processing of outlet On / Off instruction module SW4 of the slave unit)).
  • FIG. 10 is a conceptual diagram showing the physical and electrical configuration of the slave unit 2b.
  • the slave unit 2b according to the present invention includes a CPU 101, a bus controller 102, a memory 201, a peripheral bus controller 202, a LAN IF301, an LED controller 302, a relay controller 303, a relay 311, 312, 313, and outlets 321, 322, 323. It is composed.
  • the CPU 101 is a central control device that performs processing according to a program recorded in the memory 201. Although CPU is used in this specification, there is no problem with MPU.
  • the bus controller 102 is a chipset that the CPU 101 goes through when accessing the memory 201 or the like.
  • the bus controller 102 is connected to the internal bus a and the external bus b, and controls communication from the CPU 101 with the controllers and the like existing in the external bus b and the peripheral bus c.
  • the bus controller 102 may be a commercially available product or a dedicated product according to the type of the CPU 101, and it is sufficient that the CPU 101 can communicate with the controllers existing in the external bus b and the peripheral bus c.
  • the memory 201 is a memory for recording a program executed by the CPU 101 and data (settings of a network device monitoring device, etc.) to be processed. Normally, it can be considered separately as a volatile storage element such as DRAM, a non-volatile storage element such as NVRAM that is retained even when the power is turned off, and a ROM (Read Only Memory), but this specification includes all of them. And the memory 201. Further, although the memory 201 is connected only to the external bus b in this figure, it may be distributed and arranged in the internal bus a and the peripheral bus c.
  • the former should be larger in terms of the memory capacity of the master unit 2a and the memory capacity of the slave unit 2b.
  • the slave unit 2b may retain its own network information (IP address, etc.) and outlet information, but the master unit 2a must secure the slave unit 2b for the maximum number of connections.
  • IP address, etc. IP address, etc.
  • the memory capacity required for communication is specifically confirmed below. First, the slave unit 2b will be examined.
  • an authentication ID and an authentication password are required when performing status monitoring and outlet On / Off instructions.
  • the authentication password should be as long as possible because the larger the number of characters, the higher the encryption strength.
  • the slave unit 2b needs to secure its own authentication ID (15 bytes) and authentication password (32 bytes), respectively. However, it is not necessary to be concerned with the number of these bytes, and a longer byte length may be used.
  • the outlet number is a number uniquely assigned to each outlet.
  • the outlet characteristic information is a data field that indicates what kind of output the outlet produces. Specifically, it represents AC100V, DC5V, DC12V, contacts, etc. of each outlet in FIG. Specifically, 1 is assigned to AC100V, 2 is assigned to DC5V, 4 is assigned to DC12V, and the like is stored in this data field.
  • the master unit 2a First confirms a data field that needs to be managed for each slave unit in order to manage a plurality of slave units.
  • the network address and port number of the handset 2b are required. If both the master unit and the slave unit exist in the IPv4 local network, the IP address (4 bytes) and the subnet mask (4 bytes) are sufficient as the network address, but the two local networks 7 sandwiching the Internet 9 are sufficient. In the case of a configuration including 8 and 8, it is necessary to specify the gateway address (4 bytes) and the domain name or the global IP address. In this case, a maximum of 253 bytes is required as the data field of the domain name. These are indispensable as long as they communicate by IP.
  • an authentication ID and an authentication password are required for status monitoring and outlet On / Off instructions. Therefore, a data field for recording the authentication ID (15 bytes) and the authentication password (32 bytes) is required for each slave unit 2b.
  • a data field (2 bytes) that specifies the timeout time that specifies the communication timeout time and a data field (2 bytes) that specifies the retransmission time for survival confirmation are stored.
  • the peripheral bus controller 202 is a chipset that the CPU 101 or the like passes through when controlling the controller on the peripheral bus c via the external bus b. Like the bus controller 102, the peripheral bus controller 202 is also connected to the external bus b and the peripheral bus c.
  • the peripheral bus controller 202 corresponding to the type of the CPU 101 may be a commercial product or a dedicated product, and in the present embodiment, it is sufficient that the CPU 101 can communicate with the controller existing in the peripheral bus.
  • the timer 203 is a timer for internally measuring the time by an operation clock (not shown).
  • LAN IF301 is a group of interfaces including a connector (physical layer) and a chip (data link layer, network layer) for connecting to the network 8. Communicate with other network devices via this LAN IF301. Needless to say, this LAN IF301 must be connectable to the network 8.
  • the master unit 2a may be connected to the monitoring target by using either a wireless LAN or a wired LAN. Further, the slave unit 2b may be connected to the master unit 2a by using any of them.
  • the LED controller 302 is a controller for controlling the LED for visually transmitting the state of the network device monitoring device to the user. Although omitted in this figure, an LED (not shown) is connected to the LED controller 302, and the LED controller 302 is turned on and blinked to inform the user of the operating state of the slave unit 2b.
  • the relay controller 303 is a controller for controlling the relays 311, 312, 313.
  • the minimum required number of relays to be controlled is determined according to the product specifications of the slave unit 2b.
  • the relay controller 303 has a register according to the number of the relays.
  • the CPU 101 has a structure in which the corresponding relay is turned on / off by writing 1/0 to the corresponding register in the relay controller 303, and the power supply to the corresponding outlet is controlled. However, regardless of this, if a means capable of controlling the relay can be provided by any method, the relay controller 303 can play a role.
  • Relays 311 and 312,313 are relays for controlling the power supply from the power supply to the outlet.
  • the relays 311 and 312, 313 are configured so that the power supply to the corresponding outlets can be independently controlled by the control signal from the relay controller 303.
  • Outlets 321, 322, and 323 are outlets for supplying power to the monitoring target from the slave unit 2b. Each outlet is connected to a corresponding relay so that it can be controlled by the CPU 101.
  • an outlet is composed of a relay and a set of outlets connected to it. In the figure, it is shown by three sets of # 1, # 2, and # 3. In this figure, the outlet is composed of three, but this is just because of the space in the figure. In the actual machine, the number of outlets may be 6 according to FIG. In that case, an outlet # 4 (not shown) including the outlet 324 and the relay 314, an outlet # 5 (not shown) including the outlet 325 and the relay 315, and an outlet # 6 (not shown) including the outlet 326 and the relay 316 will be further added. A unique outlet number is assigned to each outlet, and this outlet number is used when designating an outlet operated by the master unit 2a.
  • a unique outlet number is assigned to each outlet in each slave unit. These are used when the master unit 2a designates a specific outlet to the slave unit and instructs an operation. Please refer to the description about outlet information and outlet number.
  • the master unit 2a does not have an outlet. This is because the direct control may be performed by the slave unit 2b. Of course, an outlet may be attached to the master unit 2a so that the master unit 2a directly manages the network device.
  • FIG. 11 is a diagram showing the configuration of the software module according to the present invention.
  • the software module according to the present invention includes an HTTP module SW1, a survival confirmation module SW2, a condition monitoring module SW3, and an outlet On / Off instruction module SW4.
  • the HTTP module SW1 is a module that 1) receives an HTTPS request shown in FIG. 5 from an IP module (not shown), 2) extracts a query added to a path after decoding, and 3) allocates processing to another module. Further, the data sent from the other modules are arranged in the HTTPS response format shown in FIG. 6 and then sent to the IP module.
  • the basic configuration is the same for both the master unit and the slave unit, but the operations of the survival confirmation module SW2, the status monitoring module SW3, and the outlet On / Off instruction module SW4 are different. This is because the slave unit processes the HTTPS request, while the master unit needs to process the HTTPS response.
  • the slave unit 2b determines whether to hand over the processing to the HTTP module SW1 according to the port number of the TCP header attached to the data received by the IP module (not shown).
  • the data of the HTTPS request whose processing is passed to the HTTP module SW1 is configured to include a request line, a header, and a message body (not used in the present specification).
  • this HTTPS request Based on the path name in the request line of this HTTPS request, it is determined whether this HTTPS request corresponds to the HTTPS request related to the present invention. If the HTTPS request is not related to the HTTPS request according to the present invention, the HTTPS module SW1 takes appropriate measures. However, they are design matters.
  • the module to which the HTTP module SW1 sends the data by the character string at the beginning of the query (“value 1” in the detail of the message body in FIG. 5) is determined. decide.
  • the character string corresponding to each module is "HELLO” for survival confirmation, "STATUS” for status monitoring, and "CONT” for outlet On / Off instruction. Therefore, the HTTP module SW1 performs parsing on the decrypted query and extracts these character strings. Then, the HTTP module SW1 deletes these character strings and the subsequent character-to-character identification ",” (comma) from the decrypted query data. After that, the HTTP module SW1 passes the deleted query data to the appropriate modules SW2-4. Error handling when a character string other than these appears at the beginning is a design matter.
  • the HTTP module SW1 attaches a TCP header to the data to which the processing is passed from each module SW2 to SW4, and passes it to the IP module.
  • the HTTP module SW2 attaches "ALIVE” for survival confirmation, "RESP” for status monitoring, and "RESULT” for outlet On / Off instructions at the beginning of the message body of the HTTPS response, but these are modules SW2-4. Attached by.
  • the data passed from each module SW2 to 4 is added to the message body of the HTTPS response, encrypted by the HTTP module SW1, and transmitted to the master unit 2a.
  • the survival confirmation module SW2 is a module that performs processing related to survival confirmation. As described above, when the HTTP module SW1 deletes HELLO or the like from the decrypted query, the remaining data does not exist, so that the actual contents of the query are lost. Therefore, only the processing is handed over to the survival confirmation module SW2. It should be noted that error handling when data that should not have been sent is sent is a design matter.
  • the status monitoring module SW3 is a module that performs processing related to status monitoring.
  • the outlet On / Off instruction module SW4 is a module that performs processing related to the outlet On / Off instruction.
  • these need to process the data passed from the HTTP module SW1 (the first character string and the subsequent character-to-character identification "," (comma) are deleted from the decrypted HTTP request query). There is. Therefore, each of these modules SW3 and SW4 is provided with a parser suitable for each of them. In the figure, these are described as SW3a and SW4a.
  • FIG. 12 is a flowchart relating to the reception process of the condition monitoring module SW3 of the slave unit 2b.
  • the parser SW3a of the status monitoring module SW3 first extracts the authentication ID (step S2001) and the authentication password (step S2002) from the data passed from the HTTP module SW1 (the one in which "STATUS," is deleted from the decrypted query). ..
  • the status monitoring module SW3 compares the extracted authentication ID and the authentication ID held by itself with the authentication password, and if they do not match, returns the character string "RESP, NAK" as a return value to the HTTP module SW1 (. Step S2003: No).
  • step S2003 determines whether the comparison results match (step S2003: Yes). If the comparison results match (step S2003: Yes), the condition monitoring module SW3 collects information on all outlets of the slave unit 2b itself (step S2004). At this time, the data may be read from the outlet set described in (Memory capacity of the slave unit), or the hardware information of the outlet may be actually read from the register or the like.
  • step S2004 The information collected in step S2004 is formed into a form that can be transmitted (step S2005).
  • the specific format is the same as that described in the storage format of the memory, and the format of ⁇ outlet number (1 byte), outlet characteristic information (2 bytes), outlet output information (1 byte) ⁇ for each outlet. (Hereafter, outlet information).
  • outlet information insert a ",” (comma) for character spacing between character strings. That is, outlet number 1 byte + character spacing identification ",” (comma) 1 byte + outlet characteristic information (2 bytes) + character spacing identification ",” (comma) 1 byte + outlet output information (1 byte)
  • a total of 6 bytes is used for information on one outlet. This is done for all the outlets of the slave unit 2b itself.
  • step S2006 all the outlet information is combined (step S2006).
  • the character strings are combined in the form of arranging them in the order of outlet numbers and connecting them with one byte of "," (comma) for character-to-character identification. That is, it is formed in the form of 1 outlet information (6 bytes) + character-to-character identification "," (comma) 1 byte + 1 outlet information (6 bytes) + ... It is a design matter how to distinguish between consecutive data when there are a plurality of outlet information due to the existence of a plurality of outlets.
  • the condition monitoring module SW3 After converting the outlet information of all the outlets of the slave unit 2b into data, the condition monitoring module SW3 adds "RESP," to the beginning of the character string (step S2007).
  • the message body of the HTTPS response is generated by the above procedure. This is sent to the HTTP module, and the HTTP module sends the HTTP response back to the master unit 2a.
  • FIG. 13 is a flowchart relating to the reception processing of the outlet On / Off instruction module SW4 of the slave unit.
  • the parser SW3a of the condition monitoring module SW3 first extracts the authentication ID (step S3001) and the authentication password (step S3002) from the data handed over from the HTTP module SW1. After extracting the authentication ID (step S3001) and the authentication password (step S3002), the authentication ID (step S3001) and the authentication password (step S3002) are used as a delimiter from the data handed over from the HTTP module SW1. Delete 1 byte of ",” (comma) for character-to-character identification twice (2 bytes in total).
  • the state monitoring module SW3 compares the extracted authentication ID and the authentication password with the authentication ID and the authentication password held by itself, and if they do not match, returns the character string "RESULT, NAK" as a return value to the HTTP module SW1 (step). S3003: No). Up to this point, it is almost the same as the condition monitoring module SW3.
  • the outlet number (step S3004) and the instruction (step S3005) are extracted from the data in which the authentication ID, authentication password, etc. are deleted.
  • the command is a command indicating whether to turn the relay of the outlet on or off, or to reboot (restart after a certain period of time).
  • the instruction itself is 1 byte, and 1 is On and 0 is Off. That is, the format of the outlet command is ⁇ outlet number (1 byte), outlet command (1 byte) ⁇ , and the outlet On / Off instruction module SW4 derives the target outlet and the operation from this.
  • the outlet number is a 1-byte number uniquely assigned to each outlet.
  • the master unit 2a can specify the outlet to be operated as the slave unit 2b.
  • the outlet command is a 1-byte number that indicates how to move each outlet. Specifically, the power supply is On, the power supply is Off, and the power supply is rebooted (Off-> On) is 4. Reboot is included in the instruction because if the power is turned off when the router is monitored, communication cannot be performed over the network and the router cannot be restarted. As a countermeasure against this, the slave unit 2b is provided with a reboot mechanism.
  • the outlet On / Off instruction module SW4 controls the relay of the outlet according to the instruction and acquires the result (step S3006). If the processing can be performed normally (step S3007: Yes), the return value is set to "RESULT, DONE" and the return value is returned to the HTTP module.
  • step S3007 If the processing cannot be performed normally (step S3007: No), the reason is transmitted to the master unit 2a.
  • the return value is set to "RESULT, ERROR, 0" when processing is not possible, for example, when the relay is damaged or an outlet number that does not originally exist is specified from the master unit 2a.
  • the access is made within the operation prohibition time of the relay (for example, the transmission of a command during the reboot period of the outlet command 4)
  • the outlet is busy and the return value is set to "RESULT, ERROR, 1". In this way, the return value to be returned from the slave unit 2b to the master unit 2a is determined.
  • FIG. 14 is a flowchart showing the operation when the power is turned on to the master unit 2a.
  • the CPU 101 of the master unit 2a resets the timer 203 and sets the counter X for counting the slave units to be managed by itself to 1 (step S1001).
  • step S1002 the CPU 101 of the master unit 2a reads the module for survival confirmation from the memory 201 and confirms the survival of the slave unit X (step S1002), subsequently reads the module for survival confirmation from the memory 201, and confirms the status of the slave unit.
  • step S1003 the timeout is confirmed by using the timer 203 reset in step S1001.
  • step S1004 When the confirmation is completed regardless of the success or failure of the survival confirmation and the status monitoring, the value of X is incremented by 1 (step S1004). Then, steps S1002 to S1004 are repeated until the confirmation of all the slave units managed by the user is completed (step S1005: No). When the confirmation of all the slave units is completed (step S1006: Yes), the processing at the time of startup is completed.
  • the master unit 2a may send three commands: 1) survival confirmation, 2) status monitoring, and 3) outlet On / Off instruction.
  • the master unit 2a takes the following measures when transmitting a command.
  • the master unit 2a When transmitting a survival confirmation command, the master unit 2a describes the path name of the destination slave unit 2b in the request line of the HTTPS request. Also, the character string "HELLO" is attached to the query and encrypted.
  • the master unit 2a When transmitting a status monitoring command, the master unit 2a describes the path name of the destination slave unit 2b in the request line of the HTTP request. Further, the master unit 2a describes the character string "STATUS," followed by the authentication ID and the authentication password in a predetermined format, attaches them as a query to the path of the request line, and then encrypts and transmits them.
  • the syntax is described in (Status Monitoring) above, so please check it.
  • Outlet On / Off instruction When transmitting the outlet On / Off instruction command, describe the path name of the destination slave unit 2b in the request line of the HTTP request. Further, the master unit 2a describes the character string "CONT," followed by the authentication ID and the authentication password, and the outlet number of the slave unit 2b to be instructed and the content of the instruction (outlet instruction). After that, the data is attached to the path as a query and then encrypted, and the master unit 2a sends an HTTPS request.
  • the format of the outlet instruction is ⁇ outlet number (1 byte), outlet output information (1 byte) ⁇ .
  • the outlet On / Off instruction operates only one outlet at a time, it is not considered to operate two outlets with one command (HTTP request). However, one command may include multiple outlet instructions.
  • the encrypted return value returned by each module SW2 to SW4 of the slave unit to the HTTP module SW1 of the slave unit is returned as an HTTP response to the master unit 2a. Therefore, it can be said that how to process the value is left to the design on the master unit 2a side.
  • the following is an example of handling, but it is not a thing that sticks to this.
  • the message body of the HTTP response for survival confirmation is "ALIVE" Only attached. Others are only timeouts, so you only need to consider dealing with this "ALIVE”. If it can be confirmed that "ALIVE" has returned after the decoding by the master unit 2a, the master unit 2a recognizes that the target slave unit is alive. Next, the master unit 2a generally requests an HTTP request as a status monitoring command from the corresponding slave unit, but this is a design matter and any processing may be continued.
  • the message body of the HTTP response which is the response of the HTTP request related to status monitoring, is "RESP, 1 outlet information, 2 outlet information "
  • the encrypted data in the form of is attached.
  • the outlet information of 1 above has a data field configuration of ⁇ outlet number (1 byte), outlet characteristic information (2 bytes), outlet output information (1 byte) ⁇ .
  • the message body of the HTTP response regarding the outlet On / Off returned from the slave unit 2b contains the following data. ⁇ RESULT, DONE ⁇ RESULT, ERROR, 0 ⁇ RESULT, ERROR, 1 Even in this case, the master unit 2a parses the decrypted message body. When "RESULT, DONE" is returned, it means that the slave unit has performed the processing as instructed by the master unit 2a. Therefore, in order to reflect it, the data of the corresponding slave unit 2b stored in its own memory is corrected. At this time, the master unit 2a side may modify the memory at its own discretion, or may issue an HTTP request for status monitoring to rewrite all the information regarding the slave unit.
  • the master unit 2a since the master unit 2a always issues an HTTP request, it is essential to receive an HTTP response. Also, what to do next from the received result is also the process on the master unit 2a side, so it is necessary to implement it on the master unit side.
  • Information on the slave unit 2b collected by the master unit 2a and the outlet of the slave unit can be provided to the user not only by the master unit 2a itself but also by sending and displaying it to the monitoring PC1. It is also possible for the master unit 2a to periodically issue the above-mentioned HTTP request to each slave unit to perform automatic monitoring and automatic control.
  • FIG. 15 is a diagram of the topology according to the second embodiment of the present invention.
  • two master units 2a are connected across the Internet 9. Further, the monitoring PC 1 connects to these two master units 2a via the Internet 7.
  • HTTP is a "communication method without memory” and is affected only by the situation at the time of communication, so that such an operation can be performed.
  • monitoring and slave unit control can be easily duplicated, and it becomes possible to provide an environment that is resistant to failures.
  • one master unit restarts and the like, and the other master unit provides information to the monitoring PC 1, so that the processing can be shared.
  • the identifier (example: STATUS) located at the beginning of the query string of the path of the request line of the HTTPS request was used to confirm the existence, monitor the status, and identify the outlet On / Off. Instead of this, it is possible to attach these to the message body that was not used.
  • the HTTP + TSL method is used as the communication method, but the use of the HTTP method is also included in the range of the present invention.
  • the GET method is used as the HTTP request method, it goes without saying that processing by the POST method is also included in the range of the present invention.
  • the master unit when the master unit manages a plurality of slave units, it is managed by the table (data form) of 1. However, creating and managing a table for each slave unit is also included in the range of the present invention.
  • IPv6 Although described above on the premise of IPv4, implementation in IPv6 is also included in the scope of the present invention.
  • the present invention is applicable to a monitoring device for network equipment. Needless to say, not only routers, billing servers, and HTTP servers, but also other network devices may be monitored.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Small-Scale Networks (AREA)
  • Power Sources (AREA)
  • Computer And Data Communications (AREA)
  • Communication Control (AREA)

Abstract

【課題】　電源ケーブルの長さやコンセントの数に拘束されることなく複数のネットワーク機器を管理可能な手段を提供することにある。 【解決手段】　ネットワーク機器管理装置を親機２ａと子機２ｂの二つに分ける。この二つの間はＨＴＴＰを使うことでルータを越える通信を確保する。子機２ｂは自身の有するアウトレット２ｂ－０１、２ｂ－０２、２ｂ－０３、２ｂ－０４、２ｂ－０５、２ｂ－０６のリレーを制御することで接続したネットワーク機器を管理する。　親機２ａは子機に対してアウトレットの情報を要求し、子機２ｂは親機にそれらを提供する。提供された情報は全ての子機のアウトレットについて１つのテーブルで管理され、管理用ＰＣ１にそのテーブルの情報を元を要求に応じて提供する。

Description

ネットワーク機器管理環境、ネットワーク機器管理装置子機及びネットワーク機器管理装置親機
　本発明は、ネットワークに接続された機器の監視装置、特に自動電源再起動機能を保持するものに関する。
　ネットワーク及びインターネットに接続されたネットワーク通信機器（以下ネットワーク機器）の数は日々増大する一方である。ネットワークに接続された機器にフレキシブルな接続性を提供するためのＤＨＣＰ、ネットワークに接続する不特定多数に情報の提供を行うためのＨＴＴＰ、ネットワーク機器の監視に用いるＳＮＭＰ、ＴＣＰに対してセキュリティを付加するＳＳＬなどサービスの提供に供されるアプリケーションは日々増えるばかりである。
　従来のネットワーク機器の監視方法に関する文献としては、特開２００４―２２１８６７公開公報（引用文献１）が挙げられる。この文献には、ネットワーク機器電源制御装置の電源部にネットワーク機器を接続し、ネットワーク機器監視装置の電源部をリブートすることでこの電源部に接続されたネットワーク機器のリブートを行う技術が記載されている。
特開２００４―２２１８６７公開公報
　しかし、ネットワーク機器監視装置の電源部にネットワーク機器を接続する必要があることから、ネットワーク機器電源制御装置の電源部とネットワーク機器との間の距離は接続に用いる電源ケーブルの長さに拘束される。従って、ネットワーク機器が１階、ネットワーク機器電源制御装置が１０階と言ったように物理的に距離がある場合には特許文献１記載の発明の適用は不可能である。
　また、特許文献１記載の発明では、ネットワーク機器電源制御装置の電源部がもつコンセントの数によって、最大管理台数が規定される。これでは、製造ライン等複数台の機器の管理を行う際に、一元的な管理を行うことができなくなる。すなわち、複数台のネットワーク機器電源制御装置が必要になる。
　本発明の目的は、電源ケーブルの長さやコンセントの数に拘束されることなく複数のネットワーク機器を管理可能な手段を提供することにある。
　本発明のさらに他の目的および利点は、以下の説明から明らかになろう。
　本発明に係るネットワーク機器管理環境は、ネットワーク機器に電源を供給する子機と、インターネットを介して子機と通信を行う親機と、を含み、子機はネットワーク機器への電源供給を行うか決定するスイッチを含み、親機が子機を制御することを特徴とする。
　このネットワーク機器管理環境は、親機がコマンドを発行することで子機を制御することを特徴としても良い。
　このネットワーク機器管理環境は、コマンドが子機の生存を確認する生存確認コマンドであることを特徴としても良い。
　このネットワーク機器管理環境は、コマンドが子機のアウトレットに関する情報を取得する状態監視コマンドであることを特徴としても良い。
　このネットワーク機器管理環境は、コマンドが子機の任意のアウトレットを制御するアウトレットＯｎ・Ｏｆｆ指示コマンドであることを特徴としても良い。
　このネットワーク機器管理環境は、コマンドがＨＴＴＰ通信プロトコルで送受信されることを特徴としても良い。
　このネットワーク機器管理環境は、コマンドに対する子機からのレスポンスで親機に子機が正常動作をしていることを通知することを特徴としても良い。
　このネットワーク機器管理環境は、コマンドに対する子機からのレスポンスで親機が子機のアウトレット情報を更新することを特徴としても良い。
　このネットワーク機器管理環境は、コマンドで子機の特定のアウトレットの電源供給をＯｎにすることを特徴としても良い。また、このネットワーク機器管理環境は、コマンドで子機の特定のアウトレットの電源供給をＯｆｆにすることを特徴としても良い。
　このネットワーク機器管理環境は、更に監視用ＰＣを含み、監視用ＰＣからの求めに応じて親機が監視用ＰＣに子機のアウトレット情報を提供することを特徴としても良い。
　このネットワーク機器管理環境は、さらに親機がネットワーク機器を管理することを特徴としても良い。
　本発明に係る別のネットワーク機器管理環境は、第１のネットワーク機器に電源を供給する第１の子機と、第２のネットワーク機器に電源を供給する第２の子機と、インターネットを介して子機と通信を行う親機と、を含み、各子機は前記ネットワーク機器への電源供給を行うか決定するスイッチを含み、親機が各子機を制御することを特徴とする。
　このネットワーク機器管理環境は、コマンドに対する第１の子機からのレスポンス及び第２の子機からのレスポンスで親機が各子機のアウトレット情報を更新することを特徴としても良い。
　このネットワーク機器管理環境は、親機は１のテーブルで第１の子機及び第２の子機のアウトレット情報を管理することを特徴としても良い。
　これらのネットワーク機器管理環境は、親機が第１のネットワーク機器及び第２のネットワーク機器を管理することを特徴としても良い。
　本発明に係る別のネットワーク機器管理環境は、ネットワーク機器に電源を供給する子機と、インターネットを介して子機と通信を行う第１の親機と、インターネットを介して子機と通信を行う第２の親機と、を含み、子機はネットワーク機器への電源供給を行うか決定するスイッチを含み、第１の親機及び第２の親機が子機を制御することを特徴とする。
　このネットワーク機器管理環境は、第１の親機の機能と、第２の親機の機能が同じであることを特徴としても良い。
　このネットワーク機器管理環境は、第１の親機の機能と、第２の親機の機能が異なることを特徴としても良い。
　本発明に係るネットワーク機器管理装置子機は、アウトレットを介してネットワーク機器に電力を供給するものであって、情報監視コマンドを受信したこのネットワーク機器管理装置子機は自身の持つアウトレットすべてに関するアウトレット情報を状態監視コマンドの送信元に返信することを特徴とする。
　本発明に係る別のネットワーク機器管理装置子機は、アウトレットを介してネットワーク機器に電力を供給するものであって、生存確認コマンドを受信したこのネットワーク機器管理装置子機は自身の生存を生存確認コマンド送信元に通知することを特徴とする。
　本発明に係る別のネットワーク機器管理装置子機は、アウトレットを介してネットワーク機器に電力を供給するものであって、アウトレットＯｎ・Ｏｆｆ指示コマンドを受信したこのネットワーク機器管理装置子機はアウトレットＯｎ・Ｏｆｆ指示コマンドで指定された自身の持つアウトレットの電源供給を制御することを特徴とする。
　このネットワーク機器管理装置子機において、制御結果をアウトレットＯｎ・Ｏｆｆ指示コマンド送信元に送信することを特徴としても良い。
　本発明に係るネットワーク機器管理装置親機は、アウトレットを介してネットワーク機器に電力を供給するネットワーク機器管理装置子機と協働するものであって、このネットワーク機器管理装置親機はネットワーク機器管理装置子機に対して状態監視コマンドを送信することを特徴とする。
　本発明に係るネットワーク機器管理装置親機は、アウトレットを介してネットワーク機器に電力を供給するネットワーク機器管理装置子機と協働するものであって、このネットワーク機器管理装置親機はネットワーク機器管理装置子機に対して生存確認コマンドを送信することを特徴とする。
　本発明に係るネットワーク機器管理装置親機は、アウトレットを介してネットワーク機器に電力を供給するネットワーク機器管理装置子機と協働するものであって、このネットワーク機器管理装置親機はネットワーク機器管理装置子機に対してアウトレットＯｎ・Ｏｆｆ指示コマンドを送信することを特徴とする。
　これらのネットワーク機器管理装置親機は、ネットワーク機器管理装置子機に接続されたネットワーク機器の状態を監視することを特徴としても良い。
　管理用ＰＣからの要求を受けたこのネットワーク機器管理装置親機は前記ネットワーク機器管理装置子機から収集したアウトレット情報を前記管理用ＰＣに送り返すことを特徴としても良い。
　本発明に係るネットワーク機器管理装置子機は、アウトレットを介してネットワーク機器に電力を供給するものであって、第１のＬＡＮ　ＩＦ及び第２のＬＡＮ　ＩＦを含むことを特徴としても良い。
　このネットワーク機器管理装置子機は、第１のＬＡＮ　ＩＦは有線ＬＡＮであることを特徴としても良い。またこのネットワーク機器管理装置子機は、第１のＬＡＮ　ＩＦは無線ＬＡＮであることを特徴としても良い。
　本発明に係る別のネットワーク機器管理装置親機は、アウトレットを介してネットワーク機器に電力を供給するネットワーク機器管理装置子機と通信を行うものであって、第１のＬＡＮ　ＩＦ及び第２のＬＡＮ　ＩＦを含むことを特徴とする。
　このネットワーク機器管理装置親機は、第１のＬＡＮ　ＩＦは有線ＬＡＮであることを特徴としても良い。また、このネットワーク機器管理装置親機は、第１のＬＡＮ　ＩＦは無線ＬＡＮであることを特徴としても良い。
　本発明に関わるネットワーク機器監視手段によって、物理的に離れた距離に存在するネットワーク機器の電源再起動を伴う管理を行うことが可能になる。
　また本発明に関わるネットワーク機器監視手段によって、電源管理を実施するネットワーク機器の管理対象数を劇的に増やすことが可能になる。
先行出願にかかわるネットワーク機器監視装置の動作環境の一例を表す接続図である。 本発明の第１の実施の形態にかかわるネットワーク機器監視装置の動作環境の一例を表す接続図である。 子機の一例の外観図（正面図）である。 本発明の親機と子機との間の通信方式に関する概念図である。 図４に係るテキストデータが、ＨＴＴＰリクエストの何処に含まれるかを説明する概念図である。 図４に係るテキストデータが、ＨＴＴＰレスポンスの何処に含まれるかを説明する概念図である。 「生存確認」時の親機と子機との間の通信方式に関する概念図である。 「状態監視」時の親機と子機との間の通信方式に関する概念図である。 「アウトレットＯｎ・Ｏｆｆ指示」時の親機と子機との間の通信方式に関する概念図である。 子機の物理的電気的構成を表す概念図である。 本発明に係るソフトウェアモジュールの構成を表す図である。 子機の状態監視モジュールの受信処理に関するフローチャートである。 子機のアウトレットＯｎ・Ｏｆｆ指示モジュールの受信処理に関するフローチャートである。 親機に電源を投入した時の動作を表すフローチャートである。 本発明の第２の実施の形態に係るトポロジの図である。
　以下本発明の実施の形態を図に基いて説明する。
（基礎となる技術）
　まず、出願人が出願した特願２０１６－０４０９３３（先行出願）に係る技術について説明する。
　図１は、先行出願にかかわるネットワーク機器監視装置の動作環境の一例を表す接続図である。
　この動作環境は、ＬＡＮ７を挟んで監視用ＰＣ１、ネットワーク機器監視装置２、監視対象Ａ３、監視対象Ｂ４が接続されて構成される。
　監視用ＰＣ１は、ネットワーク機器監視装置２の状況をモニタするためのＰＣである。このＰＣ上ではブラウザが動作可能であることを想定する。また、この監視用ＰＣ１で動作するブラウザで表示可能なデータをネットワーク機器監視装置２は生成し出力する。
　ネットワーク機器監視装置２は、自身が電源供給する監視対象Ａ３、監視対象Ｂ４のハードウェア及びソフトウェアモジュールの状態を監視する監視装置である。ネットワーク機器監視装置２は電源供給用のコンセントを監視対象の台数分持つ。これらのコンセントはネットワーク機器監視装置２内の図示しないリレーで制御され、内部的に電源をＯｎ／Ｏｆｆできるように構成される。
　監視対象Ａ３は、ネットワーク機器監視装置２が監視する対象（ネットワーク機器）である。監視対象Ａ３上はルータ機能をユーザ等に提供する。監視対象Ａ３の電源ケーブルはネットワーク機器監視装置２のコンセントに接続される。これにより、ネットワーク機器監視装置２の制御により、監視対象Ａ３の電源をＯｎ／Ｏｆｆが可能に構成されている。
　監視対象Ｂ４は、ネットワーク機器監視装置２が監視する対象である。監視対象Ｂ４上はＨＴＴＰサーバ機能及び決済サーバ機能をユーザ等に提供する。監視対象Ｂ４の電源ケーブルはネットワーク機器監視装置２のコンセントに接続される。これにより、ネットワーク機器監視装置２の制御により、監視対象Ｂ４への電源供給をＯｎ・Ｏｆｆすることができるよう構成されている。
　通常、ユーザは、監視対象Ａ３上のＨＴＴＰサーバ機能が提供するＨＴＭＬ形式で記載されたホームページのデータから誘導されて決済サーバ機能のサービスを提供される受けることになる。このため、ＨＴＴＰサーバ機能がダウンしているときには、ユーザは決済サーバ機能の利用ができないことがほとんどである。よって決済サーバ機能のみが稼働しており、他のルータ機能、ＨＴＴＰサーバ機能が非稼働な状態では決済サーバ機能の動作の意義は低下する。この場合監視対象Ｂ４を再起動する意味は大きい。
　一方、ＨＴＴＰサーバ機能が生きていれば各種情報を配信することが可能になる。この時決済サーバ機能がダウンしていたとしても、ＨＴＴＰサーバ機能を継続して動作させる必要はいささかも衰えることは無い。そのようなときに監視対象Ｂ４を再起動するのは問題が生じる。
　上記の様なＨＴＴＰサーバ機能がダウンしているときと決済サーバ機能がダウンしているときとで動作を変更する、と言うのが先行出願にかかわるネットワーク機器監視装置に関する発明である。
（第1の実施の形態）
　しかし、先行技術においては各監視対象の電源ケーブルをネットワーク機器監視装置２の図示しないコンセントに接続する必要がある。従って、ネットワーク機器監視装置２からあまり物理的な距離を離すことができないという欠点があった。これはビルの上層階と下層階を一元管理したいといった要求に応じることができないことを意味する。
　また監視対象３Ａが提供するルータを越えてネットワーク外部の端末に接続する場合、接続用プロトコルが一部制限されるなどの問題も考えられる。
　上記の問題を鑑み、本明細書に係る発明を考案した。以下その内容について説明する。
（第１の実施の形態）
（トポロジの説明）
　図２は、本発明の第１の実施の形態にかかわるネットワーク機器監視装置の動作環境の一例を表す接続図である。
　本発明の特徴としては、先行出願のネットワーク機器監視装置２を親機２ａと子機２ｂ、２ｃに二分したことにある。
　本発明のネットワークトポロジは、インターネット９を挟んで接続されたローカルネットワーク７、８を中心に構成される。そしてローカルネットワーク７には監視用ＰＣ１と親機２ａが接続されている。またローカルネットワーク８には子機２ｂ、２ｃと監視対象Ａ３、監視対象Ｂ４が接続されている。子機２ｂには監視対象Ａ３の電源ケーブルが、子機２ｃには監視対象Ｂ４の電源ケーブルがそれぞれ接続されている。
　このネットワークトポロジは、インターネット９を挟んだ２つのローカルネットワーク７、８を含んで構成される。そして親機２ａはローカルネットワーク７に、子機２ｂ、２ｃはローカルネットワーク８にそれぞれ存在する。
　ローカルネットワーク７には、監視用ＰＣ１と親機２ａが通信可能なように接続されている。またローカルネットワーク８には、監視対象Ａ３及び監視対象Ｂ４と、子機２ｂと子機２ｃが接続されている。また図示しないルータなどによってインターネット９に接続される。
　本明細書におけるインターネット９は、ローカルネットワーク７とローカルネットワーク８を接続するための抽象的なネットワークである。通常インターネットとは「インターネット・プロトコル・スイートを使用し、複数のコンピュータネットワークを相互接続した、グローバルなネットワーク（地球規模の情報通信網）のこと」と定義される（Ｗｉｋｉｐｅｄｉａ）。しかし本明細書におけるインターネット９は、所有権が明確な社内ネットワークなどを排除することは想定してないし、グローバルなことも求めない。複数のコンピュータネットワーク（本明細書ではローカルネットワーク７とローカルネットワーク８）が接続される中間経路程度に考えればよい。
　監視用ＰＣ１は、親機２ａに対して監視対象Ａ３及び監視対象Ｂ４の状況をユーザが確認するための監視用ＰＣである。
　監視用ＰＣ１は直接これら監視対象に対しては問い合わせを行うことは無い。監視用ＰＣ１は親機２ａに対して、これらの監視対象の状況を問い合わせる。なお本図においては監視用ＰＣが１台用意されているが、監視用ＰＣ１が複数台存在しても構わない。
　親機２ａは、監視対象Ａ４及び監視対象Ｂ６を直接的に監視するためのネットワーク機器監視装置である。すなわち、先行出願におけるネットワークの監視動作（ポーリング等）は親機２ａが担当する。
　通常、親機２ａが、監視対象との間で通信を行うことでこれらの監視対象の状況を確認する。監視対象Ａ３及び監視対象Ｂ４が正常に動作していないと確認できた場合には、親機２ａが子機２ｂと子機２ｃに対して監視対象Ａ３及び監視対象Ｂ４の再起動処理を求める。
　また親機２ａは子機２ｂ及び子機２ｃとの間で通信を行うことで、各子機が監視対象に提供する電源（＝アウトレット）の情報を収集する。
　なお、本図においては親機２ａが１台に対して子機が複数台存在する形式を取っているが、複数の親機が複数の子機を管理しても構わない。また複数の親機が１の子機を管理するような形式も本発明の射程に含まれる。
　子機２ｂ及び子機２ｃは、親機２ａからの求めに応じて１）監視対象Ａ３につながるアウトレット及び監視対象Ｂ４につながるアウトレットの状況を返送し、２）監視対象Ａ３につながるアウトレット及び監視対象Ｂ４につながるアウトレットの出力状態を変更し、３）監視対象Ａ３につながるアウトレット及び監視対象Ｂ４につながるアウトレットの再起動を行う、ことを特徴とするネットワーク機器監視装置である。すなわち、先行出願における電源のＯｎ・Ｏｆｆに関する動作及びそれに関連したアウトレットに関する情報の収集を各子機は実施する。
　各子機は親機が監視を行う監視対象に対して電力を供給する。本図においては、子機２ｂは監視対象Ａ３に対して電力を供給する。また、子機２ｃは監視対象Ｂ４に対して電力を供給する。但し各子機が監視対象であるネットワーク機器に対して直接情報の収集を行うことはない。
　図３は、子機２ｂの一例の外観図（正面図）である。なお、各構成要素の配置は本図に拘る必要が無いことは言うまでもない。
　この子機２ｂの外観は、アウトレット２ｂ－０１、２ｂ－０２、２ｂ－０３、２ｂ－０４、２ｂ－０５、２ｂ－０６及びＬＡＮポート２ｂ－１１、電源ケーブル２ｂ－１２を含んで構成される。無論商品たる子機２ｂ１台に幾つアウトレットを備えるかは設計事項であり、必要に応じて増減させればよい。
　アウトレット２ｂ－０１、２ｂ－０２、２ｂ－０３、２ｂ－０４、２ｂ－０５、２ｂ－０６は、監視対象に電源を供給するための電源供給端子及びその内部回路１セットを意味する。従って本図における子機２ｂは６つのアウトレットを有しており、最大６つのネットワーク機器を接続できるといえる。
　アウトレット２ｂ－０１、２ｂ－０２、２ｂ－０５は、ＡＣ１００Ｖの電源を供給できる。またアウトレット２ｂ－０３はＤＣ５Ｖを、アウトレット２ｂ－０４はＤＣ１２Ｖをそれぞれ監視対象に供給できる。アウトレット２ｂ－０６は、接点端子となる。これらはリレーやスイッチング素子（これらを総称してスイッチ）を内部に含んでおり、電源供給のＯｎ、Ｏｆｆを自由に行えるようになっている。
　本発明に係る子機２ｂは、これらのアウトレットの情報を親機２ａに対して提供できるようになっている。また親機２ａのコマンドによって、子機２ｂは各アウトレットのスイッチを操作できるようになっている。
　ＬＡＮポート２ｂ－１１は、図２のネットワーク８に接続するためのＬＡＮポートである。このＬＡＮポート２ｂ－１１を介して、子機２ｂは親機２ａと通信を行う。
　電源ケーブル２ｂ－１２は、子機２ｂに電源を供給するための電源コードである。
　なお親機２ａの外観も基本的には子機２ｂのそれと違いない。但し、親機２ａは自身が直接監視対象に電力を供給する必要が無いため、アウトレットが存在しなくても成立する点で子機とは異なる。
　本明細書において、親機２ａと子機２ｂ、子機２ｃの間は、ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ　Ｔｒａｎｓｆｅｒ　Ｐｒｏｔｏｃｏｌ：ハイパーテキスト・トランスファー・プロトコル）＋ＴＳＬ（Ｔｒａｎｓｐｏｒｔ　Ｓｅｃｕｒｉｔｙ　Ｌａｙｅｒ：トランスポート・レイヤー・セキュリティ）、すなわちＨＴＴＰＳ（Ｈｙｐｅｒｔｅｘｔ　Ｔｒａｎｓｆｅｒ　Ｐｒｏｔｏｃｏｌ　Ｓｅｃｕｒｅ：ハイパーテキスト・トランスファー・プロトコル・セキュア）、を用いて通信することを想定している。よって通信ポート番号はウェルノウンポートとして初期値４４３が割り当てられる。従って本明細書において、親機２ａと子機２ｂ、子機２ｃはＨＴＴＰＳプロトコルを採用する為、下位の物理層、データリンク層、ネットワーク層、トランスポート層の各インターネットプロトコルをサポートすることはいうまでもない。
　ＨＴＴＰＳで通信する際には、セッション確立、ＴＬＳセッション開始後ＴＬＳネゴシエーションを行う。ＴＬＳネゴシエーションでは認証方式を交渉、決定し、その後認証、鍵交換を行い、共通鍵を決定する。以降この共通鍵を利用して暗号化し通信することになる。ただし共通鍵の取得プロセスは本発明には直接関係が無いのでこれ以降説明は省略する。
　監視対象Ａ３及び監視対象Ｂ４は、親機２ａが監視を行う監視対象たるネットワーク機器である。
　監視対象Ａ３及び監視対象Ｂ４は、一般的にインターネットに接続するような機器（例えばサーバ）とは限定していない。しかし、生存報告を可能にする為に、監視対象Ａ３及び監視対象Ｂ４は任意のインターネットプロトコルを実装することが求められる。
　次に本発明実現のために実施される親機と子機の間で行われる通信について説明する。
（親機と子機間の通信）
　親機と子機間の通信は以下の３つの目的を想定する。
　　１）生存確認
　　２）状態監視
　　３）アウトレットＯｎ・Ｏｆｆ指示
　いずれの目的であっても、以下の基本的な通信方式は共通する。
　図４は本発明の親機２ａと子機２ｂとの間の通信方式に関する概念図である。図４では子機２ｂとしているが挙動は子機２ｃでももちろん同じである。
　本発明において、親機と子機の間はＨＴＴＰＳ方式のＧｅｔメソッドを用いて通信を行う。この時ＨＴＴＰＳリクエストは本発明に係るテキストデータを含めて送ることで本発明に係る「コマンド」の内上記３種の何れかであるかを子機２ｂに伝える。それに応じて子機２ｂが親機２ａに対して本発明に係るテキストデータを内包したＨＴＴＰＳレスポンス、すなわち本発明に係る「レスポンス」を返す。これを１セットとして通信を行う。なお、上述の通りＨＴＴＰＳはＨＴＴＰに共通鍵を取得するプロセスが増えたプロトコルであり、リクエスト及びレスポンスの構成は変わらない（もともとＲＦＣ７２３０で規定されている為）。よって、本明細書内ではＨＴＴＰＳとＨＴＴＰを混用する。
　親機２ａがコマンドを発行した後、一定時間が経過してもレスポンスが子機２ｂから返送されなかった場合には、タイムアウトとして子機２ｂ自体が動いていないと親機２ａは判断する。この時、子機ごとにタイムアウト値を設定するか、共通で１つのタイムアウト値とするかは親機２ａの設計事項である。
　図５は、図４に係るコマンドに該当するテキストデータが、ＨＴＴＰリクエストの何処に含まれるかを説明する概念図である。また図６は、図４に係るレスポンスに該当するテキストデータがＨＴＴＰレスポンスの何処に含まれるかを説明する概念図である。なお、ＨＴＴＰＳでもＨＴＴＰでも同じデータフォーマットを用いるため、この図で説明する。
　ＲＦＣ７２３０ではＨＴＴＰリクエスト及びＨＴＴＰレスポンスのデータ形式を定義する。なお図５及び図６は、ＨＴＴＰにかかわる物であり、本発明に関連するモノではないので図番は省略する。
　基本的にＨＴＴＰリクエストもＨＴＴＰレスポンスも同じデータ形式をとる。ＨＴＴＰリクエストはリクエスト行、ヘッダ及びメッセージボディから構成される。また、ＨＴＴＰレスポンスはレスポンス行、ヘッダ及びメッセージボディから構成される。
　図５のリクエスト行は、ＨＴＴＰリクエストのデータフィールドの一つである。リクエスト行にはメソッド（通信目的）、送信先を表すパス（クエリも含む）、ＨＴＴＰのバージョンを記載しなければならない。なお、既述の通り、本発明ではＧｅｔメソッドを使用することを想定する。またＨＴＴＰのバージョンは１．１を想定する。本発明におけるＨＴＴＰリクエストのパスには、子機２ｂに対する通信目的及びその付加情報（認証ＩＤや認証パスワード）がクエリの形で添付される。
　図５のヘッダは、リクエストに関連する追加情報を表すデータフィールドである。使用する文字コードやキープアライブ（通信が終わってもセッションを維持し続けるか？）、認証方式の指定等と言った情報が記載される。
　図５のメッセージボディは、該ＨＴＴＰリクエストにおける補足情報などを送るためのデータフィールドである。ヘッダとメッセージボディの間にはＣＲ＋ＬＦ（キャリッジリターン＋ラインフィード）が挿入されており、その間の識別は比較的容易である。本発明においては暗号化したデータをリクエスト行パス中のクエリに添付される。そのためＨＴＴＰリクエストのメッセージボディは使用しない。ただし、メッセージボディに添付するような形にしても良い。
　図６のＨＴＴＰレスポンスのレスポンス行は、ＨＴＴＰレスポンスのデータフィールドの一つである。レスポンス行には、ＨＴＴＰのバージョン、ステータスコード、補足情報（主にステータスコードの詳細情報）などが記載される。
　図６のヘッダは、レスポンスに関連する追加情報を表すデータフィールドである。
　図６のメッセージボディは、要求元に送り返すデータを添付するデータフィールドである。一般的なＨＴＴＰＳ　Ｇｅｔメソッドによる通信であれば、このメッセージボディには要求元のブラウザで表示するためのＨＴＭＬデータが添付され、暗号化されることになる。本発明でも、処理結果がメッセージボディに添付され暗号化されることになる。
　ＨＴＴＰＳリクエストを本発明の「コマンド」足らしめるテキストデータはＨＴＴＰＳリクエストのパスに付加されるクエリに格納されることを想定する。また、ＨＴＴＰＳレスポンスを、本発明の「レスポンス」足らしめるテキストデータはＨＴＴＰＳレスポンスのメッセージボディに格納されることを想定する。ただし、別のリクエスト行、レスポンス行及びヘッダにそれらを含ませるようにしても良い。
（生存確認）
　次に通信目的である「生存確認」について説明する。
　図７は、「生存確認」時の親機２ａと子機２ｂとの間の通信方式に関する概念図である。なお本図よりコマンド及びレスポンスの後ろに括弧書きを挿入するが、この括弧書き中に含まれる文字列がリクエスト行のクエリ（コマンド）あるいはメッセージボディ（レスポンス）に格納される文字列である。なお、エラー処理については各ハードの動作の説明で記載する（（子機の生存確認モジュールＳＷ２の処理）参照）。
　生存確認は、子機２ｂが正常に動作しているかを親機２ａが確認するコマンドである。
　任意のタイミングで親機２ａは、子機２ｂに対してコマンドを発行する。この際、ＨＴＴＰＳリクエストのリクエスト行パスのクエリ（以下ＨＴＴＰＳリクエストのクエリ）に「ＨＥＬＬＯ」を記載し暗号化される。
　親機２ａから送られた上記コマンドを受信した子機２ｂのＨＴＴＰモジュールは、リクエスト行上で指示されたパスによってこのメッセージが本発明に係るメッセージかを確認する。
　このリクエストが本発明に係るメッセージであることを子機２ｂが確認すると、子機２ｂは受け取ったクエリの復号後の内容がテキストの「ＨＥＬＬＯ」であることを確認する。その際必要であれば、子機２ｂは受け取ったヘッダの情報を参酌する（使用する文字コードなど）。
　復号後のクエリの内容がテキストの「ＨＥＬＬＯ」であれば、子機２ｂは自身の稼働状態を問われているのだと理解する。子機２ｂが問題なく動作していれば、送り返すＨＴＴＰＳレスポンスのメッセージボディを「ＡＬＩＶＥ」として暗号化後にＨＴＴＰモジュールに戻す。また必要があればＨＴＴＰレスポンスのヘッダに関する情報をＨＴＴＰモジュールに戻す。なお、子機２ｂの本発明に係るモジュールが動作していない場合は、必要な情報がそろわないため当然ＨＴＴＰＳレスポンスは返せない。子機２ｂはＨＴＴＰＳレスポンスを返せないため、親機２ａにはレスポンスは届かず、親機２ａではタイムアウトとして処理する。
　このＨＴＴＰレスポンスを受け取った親機２ａの図示しないＨＴＴＰモジュールはこのＨＴＴＰレスポンスのメッセージボディに復号後「ＡＬＩＶＥ」が付いていることを確認することで子機２ｂが動作していることを確認することになる。
　なお生存確認に関しては内部設定の変更等を行うことを想定していないため、本明細書では親機２ａから子機２ｂにＩＤやパスワード等は送られないとしている。しかしこれらを送信対象とすることも本発明の射程に含まれる。
（状態監視）
　次に通信目的である「状態監視」について説明する。
　図８は、「状態監視」時の親機２ａと子機２ｂとの間の通信方式に関する概念図である。なお本図もコマンド及びレスポンスの後ろに括弧書きを挿入するが、この括弧書き中に含まれる文字列がメッセージボディに格納される文字列である。また、エラー処理については図７同様各ハードの記載で説明する。
　本明細書における「状態監視」とは、子機２ｂの有する全ての「アウトレット」の情報を収集して親機２ｂに返答することを言う。従って、子機２ｂの情報が外部に発信されることとなる為、認証ＩＤ及び認証パスワードで情報の提供の是非を確認する。
　親機２ａから送られた上記コマンドを受信した子機２ｂのＨＴＴＰモジュールは、リクエスト行でこのメッセージが本発明に係るメッセージかを確認する。
　子機２ｂは受け取ったＨＴＴＰＳリクエストを復号し、クエリの先頭がテキストの「ＳＴＡＴＵＳ」であることを確認する。その際必要であれば、子機２ｂは受け取ったヘッダの情報を参酌する。ＨＴＴＰＳリクエストのクエリの先頭がテキストの「ＳＴＡＴＵＳ」であれば、子機２ｂは自身の各アウトレットの状態を問われているのだと理解する。
　次に、その子機２ｂが親機２ａに対して状態監視を許可しているか確認する。子機２ｂは残りの復号後のＨＴＴＰＳリクエストのクエリから認証ＩＤ及び認証パスワードを抽出する。図上ではメッセージボディは「ＳＴＡＴＵＳ」に続いて文字間識別の“、”（コンマ）、認証ＩＤ、文字間識別の“、”（コンマ）、認証パスワードと続くが、これらの並びは設計事項である。また文字間識別の“、”（コンマ）を？や＆に置き換えるなども設計者が適宜選択すればよい。但し本明細書では文字間識別に“、”（コンマ）を使うものとして記述する（以下同様）。
　認証ＩＤ及び認証パスワードが抽出できれば、子機２ｂは自身が保持する認証ＩＤ及び認証パスワードとの比較を行う。認証ＩＤと認証パスワードの比較の結果が一致した場合には子機２ｂは自ハードウェア内のアウトレットの稼働状況を収集する。自身の各アウトレットの状態の収集が終了したら、送り返すＨＴＴＰＳレスポンスのレスポンスボディを生成する。
　ＨＴＴＰＳレスポンス用のレスポンスボディはテキスト「ＲＥＳＰ、」を先頭にし、その後収集したアウトレット情報を記載する。アウトレット情報の詳細は各ハードの記載で説明する（（子機の状態監視モジュールＳＷ３の処理）参照）。
（アウトレットＯｎ・Ｏｆｆ指示）
　次に通信目的である「アウトレットＯｎ・Ｏｆｆ指示」について説明する。
　図９は、「アウトレットＯｎ・Ｏｆｆ指示」時の親機２ａと子機２ｂとの間の通信方式に関する概念図である。なお本図もコマンド及びレスポンスの後ろに括弧書きを挿入するが、この括弧書き中に含まれる文字列がメッセージボディに格納される文字列である。また、エラー処理については図７同様各ハードの記載で説明する。
　本明細書における「アウトレットＯｎ・Ｏｆｆ指示」は、子機２ｂが有するアウトレットへの電源の供給をＯｎ・Ｏｆｆすることを目的とする。従って、子機２ｂの操作を伴うため、「状態監視」時同様、認証ＩＤと認証パスワードを用いて情報の提供の是非を確認する。
　親機２ａから送られた上記コマンドを受信した子機２ｂのＨＴＴＰモジュールは、リクエスト行でこのメッセージが本発明に係るメッセージかを確認する。
　子機２ｂは受け取ったＨＴＴＰＳリクエストを復号しクエリを確認する。そして子機２ｂは復合後の内容の先頭がテキストの「ＣＯＮＴ」であることを確認する。その際必要であれば、子機２ｂは受け取ったヘッダの情報を参酌する。複合語のクエリの内容の先頭がテキストの「ＣＯＮＴ」であれば、子機２ｂは自身が有するアウトレットへの電源供給のＯｎ・Ｏｆｆを指示されているのだと理解する。
　次に、その子機２ｂが親機２ａに対してアウトレットＯｎ・Ｏｆｆ指示を許可しているか確認する。子機２ｂは残りの復号後のクエリから認証ＩＤ及び認証パスワードを抽出する。
　認証ＩＤ及び認証パスワードが抽出できれば、子機２ｂは自身が保持する認証ＩＤ及び認証パスワードとの比較を行う。認証ＩＤと認証パスワードの比較が一致した場合には子機２ｂは復号後のクエリ中で指示された番号のアウトレット（図９中のアウトレット番号）の電源に対する動作を実行する。この際の、変更される電源の供給状態も復号後のクエリ中に記載されている（図９中の「命令」）。子機２ｂは、その変更結果を参考に送り返すＨＴＴＰレスポンスのメッセージボディを生成する。ここで「命令」とは１バイトのデータであり、該アウトレットのリレーをＯｎ・Ｏｆｆすることを意味する。本明細書においては１をＯｎ、０をＯｆｆとして定義する。
　ＨＴＴＰＳレスポンス用のレスポンスボディはテキスト「ＲＥＳＵＬＴ」を先頭にし、文字間識別の“、”（コンマ）をつなげた後に、設定変更の結果を記載する。結果の詳細は各ハードの記載で説明する（（子機のアウトレットＯｎ・Ｏｆｆ指示モジュールＳＷ４の処理）参照）。
（ハードウェア構成）
　次にハードウェア構成について説明する。
　図３の説明でも述べたが、親機２ａと子機２ｂの基本的な違いはアウトレットの数のみである。突き詰めて考えればメモリの搭載量なども相違するが、昨今の状況ではいずれであっても十分な容量を確保できる。よって、本明細書では親機２ａと子機２ｂのハードウェアはアウトレットの数以外は共通するものとして説明する。従って、相違点についてはここで記す。
　図１０は、子機２ｂの物理的電気的構成を表す概念図である。
　本発明に関わる子機２ｂはＣＰＵ１０１、バスコントローラ１０２、メモリ２０１、周辺用バスコントローラ２０２、ＬＡＮ　ＩＦ３０１、ＬＥＤコントローラ３０２、リレーコントローラ３０３、リレー３１１、３１２，３１３、コンセント３２１、３２２、３２３を含んで構成される。
　ＣＰＵ１０１は、メモリ２０１中に記録されたプログラムに従い処理を行う中央制御装置である。本明細書ではＣＰＵとしているが、ＭＰＵでも問題はない。
バスコントローラ１０２は、ＣＰＵ１０１がメモリ２０１等にアクセスする際に経由するチップセットである。
　その性質上バスコントローラ１０２は、内部バスａ及び外部バスｂに接続されており、ＣＰＵ１０１から外部バスｂ及び周辺用バスｃに存在するコントローラ等との通信を制御する。
　市場ではＣＰＵ１０１の種類に対応してバスコントローラ１０２は市販品あるいは専用品に拘らず、ＣＰＵ１０１と外部バスｂ及び周辺用バスｃに存在するコントローラ等との通信ができれば良い。
　メモリ２０１は、ＣＰＵ１０１が実行するプログラム及び処理の対象となるデータ（ネットワーク機器監視装置の設定など）を記録するためのメモリである。通常だとＤＲＡＭのような揮発性記憶素子と電源を切っても保持されるＮＶＲＡＭのような不揮発的な記憶素子、ＲＯＭ（Ｒｅａｄ　Ｏｎｌｙ　Ｍｅｍｏｒｙ）に分けて考えられるが、本明細書では全てを包含してメモリ２０１とする。また本図ではメモリ２０１を外部バスｂのみに接続しているが、内部バスａや周辺バスｃに分散させて配置しても良い。
　メモリ２０１には、一般的なＨＴＴＰモジュールだけでなく、本発明に係るサブモジュール（以下単にサブモジュール）もプログラムとして記憶されている。
　理論上、親機２ａのメモリの容量と子機２ｂのメモリの容量では前者の方が大きい方が良い。子機２ｂは自身のネットワーク情報（ＩＰアドレス等）とアウトレット情報を保持すればよいが、親機２ａは子機２ｂを最大接続数分確保しなければならないためである。但し、近年ではメモリの容量も大きくなっている為、特に気にしない場合も多い。
　以下具体的に通信に必要なメモリ容量を確認する。
　まず子機２ｂについて検討する。
（子機のメモリ容量）
　ＨＴＴＰ及びＩＰで通信をする以上、子機２ｂも相手と通信する際には自身のＩＰアドレス、ＩＰｖ４であればサブネットマスク、ゲートウェイアドレスが必要になることは言うまでもない。まずはこれらを記憶する（各４バイト）。ただし、これらはＩＰ層に関する情報であるのでＩＰ層に管理を任せても問題は無い。
　また本発明では、状態監視やアウトレットＯｎ・Ｏｆｆ指示を行う際には認証ＩＤと認証パスワードが必要になる。認証ＩＤはともかく認証パスワードは文字数が多ければ多いほど暗号強度が高くなる為できる限り長くすべきである。子機２ｂは自分の認証ＩＤ（１５バイト）と認証パスワード（３２バイト）をそれぞれ確保する必要がある。ただし、これらのバイト数に拘る必要は無く、もっと長いバイト長でも良い。
　また自身のＨＴＴＰモジュールに割り当てられているポート番号も記憶する（２バイト）。
　さらにアウトレット１つごとに｛アウトレット番号（１バイト）、アウトレットの特性情報（２バイト）、アウトレットの出力情報（１バイト）｝が必要になる。これをアウトレットセットと称呼する。
　以下、アウトレットセットのデータフィールドについて説明する。
　アウトレット番号は、各アウトレットに対して一意に割り当てられる番号である。
　アウトレットの特性情報は、アウトレットがどのような出力を行うかを表すデータフィールドである。具体的には図３の各アウトレットがもつＡＣ１００Ｖ、ＤＣ５Ｖ、ＤＣ１２Ｖ、接点などを表す。具体的にはＡＣ１００Ｖに１、ＤＣ５Ｖに２、ＤＣ１２Ｖに４などを割り当てて、それをこのデータフィールドに記憶することになる。
　アウトレットの出力情報は、現在どのような出力状態を表すデータフィールドである。具体的にはＯＮ＝１、ＯＦＦ＝２、故障＝４、不明＝８（値は１０進数）などを割り当て、アウトレットが現在どのような状況下であるかを取得してこのデータフィールドに記憶することになる。
　さらに各アウトレットの電源をＯｆｆ－＞ＯＮあるいはＯｎ－＞Ｏｆｆする際に、最低限待つ時間を表すデータフィールドを記憶する（１バイト）。
　以上を合計すると４＊３＋１５＋３２＋２＋４＊ｎ（アウトレット数）＋１＝６２＋（４＊ｎ）が必要になる。アウトレットが１つなら６６バイト、アウトレットが６つなら８６バイトが必要になる。
（親機のメモリ容量）
　次に親機２ａについて検討する。
　親機２ａは、複数の子機を管理するためにまず子機ごとに管理が必要なデータフィールドを確認する。
　まず子機２ｂのネットワークアドレスおよびポート番号が必要になる。親機、子機ともにＩＰｖ４ローカルネットワーク内に存在するのであれば、ネットワークアドレスとしてはＩＰアドレス（４バイト）およびサブネットマスク（４バイト）で十分であるが、インターネット９を挟んだ２つのローカルネットワーク７、８を含んだ構成の場合、ゲートウェイアドレス（４バイト）と、ドメイン名あるいはグローバルＩＰアドレスを指定する必要がある。この場合、ドメイン名のデータフィールドとして最大２５３バイトが必要になる。ＩＰで通信する以上、これらは必須である。なお、ドメイン名で指定したパケットが所定の子機に到達するためには、ローカルネットワーク８内の図示しないルータによってパケットを転送する所謂ルーティングが必要となるが、ルーティング設定については本発明には直接関係が無いのでこれ以降説明は省略する。
　また、状態監視やアウトレットＯｎ・Ｏｆｆ指示を行う際には認証ＩＤと認証パスワードが必要になる。よって子機２ｂごとに、認証ＩＤ（１５バイト）と認証パスワード（３２バイト）を記録するデータフィールドが必要である。
　更に当該子機２ｂが持つアウトレットごとに｛アウトレット番号（１バイト）、アウトレットの特性情報（２バイト）、アウトレットの出力情報（１バイト）｝が必要になる。これらの性質は子機２ｂのそれらと同様である。
　以上より、通信先の子機２ｂごとに（４＋４＋４＋２５３＋４）＋２＋１５＋３２＋４＊ｘ（子機２ｂのアウトレット数）＝３１８＋４＊ｘが必要になる。
　そのほかシステム用のパラメータとして、通信タイムアウト時間を規定するタイムアウト時間を規定するデータフィールド（２バイト）及び生存確認の再送信時間を規定するデータフィールド（２バイト）が記憶される。
　以上より、１子機あたりに４＋｛（３１８＋４＊ａ）＋（３１８＋４＊ｂ）＋（３１８＋４＊ｃ）＋…｝が親機２ａに必要な容量となる。もちろんシステム用のメモリが必要となる為、これだけあればプログラムが動くというものではないことは言うまでもない。
　周辺用バスコントローラ２０２は、ＣＰＵ１０１等が外部バスｂを経由して周辺用バスｃ上にあるコントローラを制御する際に経由するチップセットである。
　バスコントローラ１０２同様、周辺用バスコントローラ２０２も外部バスｂ及び周辺用バスｃに接続されている。
　市場ではＣＰＵ１０１の種類に対応して周辺用バスコントローラ２０２も市販品あるいは専用品に拘らず、本実施の形態ではＣＰＵ１０１と周辺用バスに存在するコントローラ等との通信ができれば良い。
　タイマ２０３は、図示しない動作クロックによって内部で時間を図るためのタイマである。
　ＬＡＮ　ＩＦ３０１は、ネットワーク８に接続する為のコネクタ（物理層）及びチップ（データリンク層、ネットワーク層）などを含むインターフェイス群である。このＬＡＮ　ＩＦ３０１を経由して他のネットワーク機器との通信を行う。このＬＡＮ　ＩＦ３０１は、ネットワーク８と接続可能なものでなければならないことは言うまでもない。
　このＬＡＮ　ＩＦ３０１が複数ある場合には、ＬＡＮ　ＩＦごとにＩＰアドレスが割り振られる。従って、子機２ｂが無線ＬＡＮと有線ＬＡＮの二つのＬＡＮ　ＩＦを有する場合には、其々にＩＰアドレスが割り振られることに注意する。親機２ａは無線ＬＡＮ及び有線ＬＡＮのいずれをもちいて監視対象と接続しても良い。また子機２ｂはいずれを用いて親機２ａと接続しても良い。
　ＬＥＤコントローラ３０２は、ネットワーク機器監視装置の状態をユーザに視覚伝達する為のＬＥＤを制御するためのコントローラである。本図では省略しているが、ＬＥＤコントローラ３０２は図示しないＬＥＤが接続され、これを点灯、点滅させることでユーザに子機２ｂの動作状態を伝える。
　リレーコントローラ３０３は、リレー３１１，３１２、３１３を制御するためのコントローラである。子機２ｂの製品仕様に応じて、制御するリレーの最低必要数が決定される。そしてそのリレーの数に応じてリレーコントローラ３０３はレジスタを持つ。ＣＰＵ１０１はリレーコントローラ３０３中の該当するレジスタに１／０を書き込むことで、該当するリレーをＯｎ／Ｏｆｆし、対応するコンセントへの電源供給を制御する構造になっている。但しこれに拘るものでなく、いかなる方法であってもリレーを制御できる手段を提供できれば、リレーコントローラ３０３の役割を果たすことが可能である。
　リレー３１１、３１２，３１３は、電源からコンセントへの電力供給を制御するための継電器である。リレー３１１、３１２，３１３は、リレーコントローラ３０３からの制御信号によってそれぞれ対応するコンセントへの電力供給が独立して制御可能なように構成されている。
　コンセント３２１、３２２、３２３は、子機２ｂから監視対象に電力を供給するためのコンセントである。各コンセントは対応するリレーに接続されることで、ＣＰＵ１０１による制御が可能になっている。
　先にも述べたがリレーとそれに接続されるコンセント一組でアウトレットを構成する。図中では＃１、＃２、＃３の３組で示される。本図ではアウトレットは３つから構成されているが、あくまでもこれは図のスペースの都合上そうしているだけである。実機では図３準拠でアウトレットを６つにしても良い。その場合はコンセント３２４とリレー３１４を含む図示しないアウトレット＃４、コンセント３２５とリレー３１５を含む図示しないアウトレット＃５、コンセント３２６とリレー３１６を含む図示しないアウトレット＃６がさらに追加されることになる。各アウトレットには一意のアウトレット番号が割り当てられており、親機２ａが操作するアウトレットを指定する際にこのアウトレット番号が用いられる。
　各子機内の各アウトレットには、子機単位で一意のアウトレット番号が割り振られている。これらは親機２ａが子機に対して特定のアウトレットを指定して操作を指示する際に用いられる。アウトレット情報、アウトレット番号に関する記載を参照されたい。
　既述の通り親機２ａにはアウトレットが存在しなくても問題はない。直接の制御は子機２ｂに行わせればよいためである。もちろん親機２ａにアウトレットをつけて親機２ａが直接ネットワーク機器を管理するようにしても良い。
　なお、監視対象とコンセントの接続を適切に行わないと、該監視対象に異常が発生し電源を切断するときに異なる監視対象の電源を切断することになる。よってユーザは注意を払って接続及び子機２ｂの設定を行うべきである。本明細書ではそれらの対応は取れているものとして説明している。
　次に、親機２ａと子機２ｂ間で通信を行う際の親機２ａ及び子機２ｂの内部動作について説明する。
（ソフトウェアモジュールの構成）
　図１１は、本発明に係るソフトウェアモジュールの構成を表す図である。
　本発明に係るソフトウェアモジュールは、ＨＴＴＰモジュールＳＷ１、生存確認モジュールＳＷ２、状態監視モジュールＳＷ３、アウトレットＯｎ・Ｏｆｆ指示モジュールＳＷ４を含む。
　ＨＴＴＰモジュールＳＷ１は、１）図示しないＩＰモジュールから図５に示すＨＴＴＰＳリクエストを受け取り、２）復号した後、パスに付加されるクエリを抽出し、３）処理を他のモジュールに割り当てるモジュールである。また他のモジュールから送られたデータを図６に示すＨＴＴＰＳレスポンス形式に整えた後ＩＰモジュールに送信する。親機も子機も基本構成は同じだが、生存確認モジュールＳＷ２、状態監視モジュールＳＷ３、アウトレットＯｎ・Ｏｆｆ指示モジュールＳＷ４の動作は異なる。子機はＨＴＴＰＳリクエストを処理するのに対し、親機はＨＴＴＰＳレスポンスを処理する必要があるためである。
　親機２ａがＨＴＴＰＳリクエストを送信した後、子機２ｂでは図示しないＩＰモジュールが受信したデータに添付されたＴＣＰヘッダのポート番号によってＨＴＴＰモジュールＳＷ１に処理を引き渡すかを決定する。
　ＨＴＴＰモジュールＳＷ１に処理が引き渡されたＨＴＴＰＳリクエストのデータは図５のように、リクエスト行、ヘッダ、メッセージボディ（本明細書では不使用）を含んで構成される。
　このＨＴＴＰＳリクエストのリクエスト行中のパス名によって、このＨＴＴＰＳリクエストが本発明にかかわるＨＴＴＰＳリクエストに相当するかを判断する。ＨＴＴＰＳリクエストが本発明に係るＨＴＴＰＳリクエストに関連するモノでなければＨＴＴＰモジュールＳＷ１は相応の対応を取る。但しそれらは設計事項である。
　送られたＨＴＴＰＳコマンドが本発明に係るＨＴＴＰＳリクエストであると判断すると、ＨＴＴＰモジュールＳＷ１がクエリの先頭の文字列（図５メッセージボディ詳細の「値１」）によってどのモジュールにそのデータを送るかを決定する。すでに述べた通り各モジュールに対応する文字列は、生存確認は「ＨＥＬＬＯ」、状態監視は「ＳＴＡＴＵＳ」、アウトレットＯｎ・Ｏｆｆ指示は「ＣＯＮＴ」である。よってＨＴＴＰモジュールＳＷ１は、復号後のクエリに対して構文解析を行い、これらの文字列を抽出する。そして、ＨＴＴＰモジュールＳＷ１は、復号後のクエリのデータからこれらの文字列および続く文字間識別の“、”（コンマ）を削除する。その後に、ＨＴＴＰモジュールＳＷ１は適切なモジュールＳＷ２～４に削除後のクエリのデータを引き渡す。これら以外の文字列が先頭に出現した際のエラー処理は設計事項である。
　また、ＨＴＴＰＳレスポンスを送信する場合には、ＨＴＴＰモジュールＳＷ１は各モジュールＳＷ２～４から処理を引き渡されたデータにＴＣＰヘッダを添付し、ＩＰモジュールに引き渡す。この際、ＨＴＴＰＳレスポンスのメッセージボディの先頭に、生存確認は「ＡＬＩＶＥ」、状態監視は「ＲＥＳＰ」、アウトレットＯｎ・Ｏｆｆ指示は「ＲＥＳＵＬＴ」を添付する必要があるが、これらは各モジュールＳＷ２～４によって添付される。各モジュールＳＷ２～４から渡されたデータはＨＴＴＰＳレスポンスのメッセージボディに付加され、ＨＴＴＰモジュールＳＷ１によって暗号化され親機２ａに送信される。
（子機の生存確認モジュールＳＷ２の処理）
　生存確認モジュールＳＷ２は、生存確認に関する処理を行うモジュールである。上記の通りＨＴＴＰモジュールＳＷ１が復号後のクエリからＨＥＬＬＯ等を削除すると、残存データが存在しなくなるのでクエリの実質的な中身は喪失する。従って、生存確認モジュールＳＷ２には処理のみを引き渡すことになる。なお、本来送られてくるはずのないデータが送られてきた場合のエラー処理は設計事項である。
　生存確認は、ＨＴＴＰＳレスポンスのメッセージボディに「ＡＬＩＶＥ」をつけてＨＴＴＰモジュールＳＷ１に処理を返すのみである。従って、本モジュール起動時は引き渡されるデータは無い。そして、戻り値として「ＡＬＩＶＥ」だけをＨＴＴＰモジュールＳＷ１に戻して終了する。但し、生存確認モジュールＳＷ２がハードウェアの動作確認を行い正常であることを確認した後に生存確認モジュールＳＷ２が「ＡＬＩＶＥ」をつけてＨＴＴＰモジュールＳＷ１に処理を返しても良い。なお、この場合のエラー発生時の挙動は設計事項である。
（子機の状態監視モジュールＳＷ３の処理）
　状態監視モジュールＳＷ３は、状態監視に関する処理を行うモジュールである。また、アウトレットＯｎ・Ｏｆｆ指示モジュールＳＷ４は、アウトレットＯｎ・Ｏｆｆ指示に関する処理を行うモジュールである。これらは生存確認モジュールＳＷ２と異なり、ＨＴＴＰモジュールＳＷ１から引き渡されるデータ（復号後のＨＴＴＰリクエストのクエリから先頭文字列およびそれに続く文字間識別の“、”（コンマ）を削除したもの）を処理する必要がある。従って、これら各モジュールＳＷ３、ＳＷ４にはそれぞれに適した構文解析手段（パーサ）が付与されている。図上ではこれらはＳＷ３ａ、ＳＷ４ａと記載されている。
　図１２は、子機２ｂの状態監視モジュールＳＷ３の受信処理に関するフローチャートである。
　状態監視モジュールＳＷ３のパーサＳＷ３ａは、まずＨＴＴＰモジュールＳＷ１から引き渡されたデータ（復号後のクエリから「ＳＴＡＴＵＳ、」を削除したもの）から認証ＩＤ（ステップＳ２００１）及び認証パスワード（ステップＳ２００２）を抽出する。
　そして、状態監視モジュールＳＷ３は抽出した認証ＩＤと認証パスワードを自身が保持する認証ＩＤと認証パスワードを比較し、一致していなければＨＴＴＰモジュールＳＷ１に文字列「ＲＥＳＰ、ＮＡＫ」を戻り値として返す（ステップＳ２００３：Ｎｏ）。
　一方比較の結果が一致していれば（ステップＳ２００３：Ｙｅｓ）、状態監視モジュールＳＷ３は子機２ｂ自身の全てのアウトレットの情報を収集する（ステップＳ２００４）。この際、（子機のメモリ容量）で説明した、アウトレットセットからデータを読みだしても良いし、実際に当該アウトレットのハードの情報をレジスタ等から読みだしても良い。
　ステップＳ２００４で収集した情報を、送信可能な形に形成する（ステップＳ２００５）。具体的な形式は、メモリの記憶形式に記載ものと同じで、１つのアウトレットごとに｛アウトレット番号（１バイト）、アウトレットの特性情報（２バイト）、アウトレットの出力情報（１バイト）｝の形式になる（以下アウトレット情報）。また文字列間には文字間識別の“、”（コンマ）を挿入する。すなわちアウトレット番号１バイト＋文字間識別の“、”（コンマ）１バイト＋アウトレットの特性情報（２バイト）＋文字間識別の“、”（コンマ）１バイト＋アウトレットの出力情報（１バイト）の計６バイトで１アウトレットの情報にする。これを子機２ｂ自身の有する全てのアウトレットに対して行う。
　そして、全てのアウトレット情報を結合する（ステップＳ２００６）。ここではアウトレット番号順に並べて文字間識別の“、”（コンマ）１バイトでつなげていく形で文字列を結合する。すなわち１アウトレット情報（６バイト）＋文字間識別の“、”（コンマ）１バイト＋１アウトレット情報（６バイト）＋…と言う形で形成される。アウトレットが複数存在することでアウトレット情報が複数ある際に、連続するデータ間をどのように識別するか設計事項である。
　この子機２ｂの持つ全アウトレットのアウトレット情報をデータにしたのちに、状態監視モジュールＳＷ３はその文字列の先頭に「ＲＥＳＰ、」を追加する（ステップＳ２００７）。
　以上の手順にてＨＴＴＰＳレスポンスのメッセージボディが生成される。これをＨＴＴＰモジュールに送り、ＨＴＴＰモジュールはＨＴＴＰレスポンスを親機２ａに送り返すことになる。
（子機のアウトレットＯｎ・Ｏｆｆ指示モジュールＳＷ４の処理）
　図１３は子機のアウトレットＯｎ・Ｏｆｆ指示モジュールＳＷ４の受信処理に関するフローチャートである。
　状態監視モジュールＳＷ３のパーサＳＷ３ａは、まずＨＴＴＰモジュールＳＷ１から引き渡されたデータから認証ＩＤ（ステップＳ３００１）及び認証パスワード（ステップＳ３００２）を抽出する。なお、認証ＩＤ（ステップＳ３００１）及び認証パスワード（ステップＳ３００２）を抽出した後に、ＨＴＴＰモジュールＳＷ１から引き渡されたデータから認証ＩＤ（ステップＳ３００１）及び認証パスワード（ステップＳ３００２）及びそれの区切りとして使用していた文字間識別の“、”（コンマ）１バイトを２回（計２バイト）削除する。
　そして、状態監視モジュールＳＷ３は抽出した認証ＩＤと認証パスワードを自身が保持する認証ＩＤと認証パスワードと比較し、一致しなければＨＴＴＰモジュールＳＷ１に文字列「ＲＥＳＵＬＴ、ＮＡＫ」を戻り値として返す（ステップＳ３００３：Ｎｏ）。ここまでは、状態監視モジュールＳＷ３とほぼ同じである。
　比較の結果が一致していれば（ステップＳ３００３：Ｙｅｓ）、認証ＩＤ、認証パスワード等を削除したデータから、アウトレット番号（ステップＳ３００４）及び命令（ステップＳ３００５）を抽出する。前述の通り、命令とは該アウトレットのリレーをＯｎ・Ｏｆｆいずれにするか、あるいはリブート（一定時間後に再起動）を表すコマンドである。本明細書では命令自体は１バイトであり、１でＯｎ、０でＯｆｆとする。すなわちアウトレット命令の形式は、｛アウトレット番号（１バイト）、アウトレットコマンド（１バイト）｝の形式であり、アウトレットＯｎ・Ｏｆｆ指示モジュールＳＷ４はこれから対象アウトレットと動作を導出する。
　以下、アウトレット命令の各パラメータについて説明する。
　アウトレット番号は、各アウトレットに対して一意に割り当てられる１バイトの番号である。これを用いることで親機２ａは操作対象になるアウトレットを子機２ｂに指定することができる。
　アウトレットコマンドは、各アウトレットをどのように動かすかをあらわす１バイトの番号である。具体的には電源をＯｎが１、電源をＯｆｆが２、電源をリブートする（Ｏｆｆ－＞Ｏｎ）が４、と言った形であり当てられる。リブートが命令の中に含まれるのは、ルータを監視対象とした場合に電源をＯｆｆしてしまうとネットワークを越えて通信ができなくなり、ルータを再起動できなくなる。この対策として子機２ｂにリブート機構を持たせるようにしたものである。
　この命令に従い、アウトレットＯｎ・Ｏｆｆ指示モジュールＳＷ４は該アウトレットのリレーを命令に従い制御し、その結果を取得する（ステップＳ３００６）。正常に処理できた場合には（ステップＳ３００７：Ｙｅｓ）、戻り値を「ＲＥＳＵＬＴ、ＤＯＮＥ」とし戻り値としてＨＴＴＰモジュールに返す。
　正常に処理できなかった場合には（ステップＳ３００７：Ｎｏ）、その理由が何かを親機２ａに送信する。本図においては処理不能の場合、例えばリレーの破損や本来存在しないアウトレット番号が親機２ａから指定された場合など、は戻り値を「ＲＥＳＵＬＴ、ＥＲＲＯＲ、０」とする。一方、リレーの操作禁止時間（例えばアウトレット命令４のリブート期間中のコマンドの送信など）以内にアクセスした等の場合、該アウトレットはビジーとして戻り値を「ＲＥＳＵＬＴ、ＥＲＲＯＲ、１」とする。
　このように、子機２ｂから親機２ａに戻す戻り値を決定する。
（親機起動時の動作）
　次に親機の起動時の動作について説明する。
　図１４は、親機２ａに電源を投入した時の動作を表すフローチャートである。
　電源を投入すると、親機２ａのＣＰＵ１０１はタイマ２０３をリセットし、また自身が管理する為の子機をカウントする為のカウンタＸを１に設定する（ステップＳ１００１）。
　そして、親機２ａのＣＰＵ１０１は生存確認用のモジュールをメモリ２０１から読み出し子機Ｘの生存確認を行い（ステップＳ１００２）、続けて生存確認用のモジュールをメモリ２０１から読み出し、当該子機の状態確認を行い当該子機のアウトレットの状態を確認する（ステップＳ１００３）。この確認の際に、ステップＳ１００１でリセットしたタイマ２０３を用いてタイムアウトの確認を行う。子機の電源が入っていないなどにより、これらの処理はタイムアウトしてしまうことで上記処理が終了することもある。またステップＳ１００２でタイムアウトした場合にステップＳ１００３を当該子機に実施するかは設計事項である。
　生存確認および状態監視の成否にかかわらず確認が終了すると、Ｘの値を１増分する（ステップＳ１００４）。そして自身が管理する全ての子機の確認が終了するまでステップＳ１００２～Ｓ１００４を繰り返す（ステップＳ１００５：Ｎｏ）。全ての子機の確認が終了すると（ステップＳ１００６：Ｙｅｓ）、起動時の処理を終了する。
（親機２ａによるコマンドの送信）
　次に親機２ａによるコマンドの送信について説明する。
　これまでも述べたが親機２ａは１）生存確認、２）状態監視、３）アウトレットＯｎ・Ｏｆｆ指示の３つのコマンドを送信することがある。親機２ａはコマンド送信時にそれぞれ以下のような処置をとる。
１）生存確認
　生存確認コマンドを送信する際には、親機２ａはＨＴＴＰＳリクエストのリクエスト行に送信先の子機２ｂのパス名を記載する。また文字列「ＨＥＬＬＯ」をクエリに添付し暗号化する。
２）状態監視
　状態監視コマンドを送信する際には、親機２ａはＨＴＴＰリクエストのリクエスト行に送信先の子機２ｂのパス名を記載する。また親機２ａは文字列「ＳＴＡＴＵＳ、」及びそれに続けて認証ＩＤと認証パスワードを所定の形式で記載しこれらをリクエスト行のパスにクエリとして添付した後にこれらを暗号化して送信する。構文は既述の（状態監視）に記載されているので確認してほしい。
３）アウトレットＯｎ・Ｏｆｆ指示
　アウトレットＯｎ・Ｏｆｆ指示コマンドを送信する際には、ＨＴＴＰリクエストのリクエスト行に送信先の子機２ｂのパス名を記載する。また親機２ａは文字列「ＣＯＮＴ、」及びそれに続けて認証ＩＤと認証パスワードを、そして命令対象である子機２ｂのアウトレット番号と命令の内容（アウトレット命令）をそれぞれ記載する。その後データをクエリとしてパスに添付した後に暗号化し、親機２ａはＨＴＴＰＳリクエストを送信する。なおアウトレット命令の形式は、｛アウトレット番号（１バイト）、アウトレットの出力情報（１バイト）｝の形式になる。本明細書ではアウトレットＯｎ・Ｏｆｆ指示は同時に一つのアウトレットしか操作することを想定していないため、１つのコマンド（ＨＴＴＰリクエスト）で２つのアウトレットを操作することを考えていない。しかし、一つのコマンドに複数のアウトレット命令を含ませても良い。
　最後に、親機２ａによるＨＴＴＰＳレスポンスの受信について説明する。
　子機の各モジュールＳＷ２～ＳＷ４が子機のＨＴＴＰモジュールＳＷ１に返した戻り値の暗号化後のものが親機２ａへのＨＴＴＰレスポンスとして戻される。従って、その値をどのように処理するかは親機２ａ側の設計に委ねられると言える。以下は取り扱いの例であるが、これに拘るモノではない。
（生存確認に関するＨＴＴＰレスポンスの受信）
　既述の通り、生存確認のＨＴＴＰレスポンスのメッセージボディには、
　　「ＡＬＩＶＥ」
のみが添付される。他はタイムアウトのみなので、この「ＡＬＩＶＥ」に対してのみ対応を考えればよい。
　親機２ａによる復号化後、「ＡＬＩＶＥ」が戻っていることが確認できれば、親機２ａは対象子機が生きていることを認識する。次に親機２aは状態監視コマンドとしてのＨＴＴＰリクエストを該当する子機に要求することが一般的であるが、設計事項でありどのような処理を続けても良い。
（状態監視に関するＨＴＴＰレスポンスの受信）
　これまた既述の通り、状態監視に関するＨＴＴＰリクエストの応答であるＨＴＴＰレスポンスのメッセージボディには、
　　「ＲＥＳＰ、１のアウトレット情報、２のアウトレット情報…」
と言う形の暗号化後のデータが添付される。そして、上記１のアウトレット情報は｛アウトレット番号（１バイト）、アウトレットの特性情報（２バイト）、アウトレットの出力情報（１バイト）｝のデータフィールド構成となる。
　これを、子機ごとかつアウトレットごとに構文解析し、自身のメモリに記憶する。記憶の形式は（親機のメモリ容量）で説明したので、そちらを参酌されたい。
（アウトレットＯｎ・Ｏｆｆに関するＨＴＴＰレスポンスの受信）
　子機２ｂから戻ってくるアウトレットＯｎ・Ｏｆｆに関するＨＴＴＰレスポンスのメッセージボディには次のようなデータが含まれている。
　　◆ＲＥＳＵＬＴ、ＤＯＮＥ
　　◆ＲＥＳＵＬＴ、ＥＲＲＯＲ、０
　　◆ＲＥＳＵＬＴ、ＥＲＲＯＲ、１
　この場合でも親機２ａは復号化後のメッセージボディを構文解析する。
　「ＲＥＳＵＬＴ、ＤＯＮＥ」が戻ってきた際には親機２ａの指示通りに子機が処理を行ったという事になる。従って、それを反映させるべく自身のメモリに記憶した該当する子機２ｂのデータを修正する。この際、親機２ａ側が自身の判断でメモリを修正しても良いし、状態監視に関するＨＴＴＰリクエストを発行して、該子機に関する情報すべてを書き換えても良い。
　「ＲＥＳＵＬＴ、ＥＲＲＯＲ、０」の場合、子機２ｂの内部処理がうまく実行されなかった場合になる。この場合は、再び該子機に対して状態監視に関するＨＴＴＰリクエストを発行することが一般的であるが、設計事項であり、どのような処理を続けても良い。
　「ＲＥＳＵＬＴ、ＥＲＲＯＲ、１」の場合、子機２ｂの該当アウトレットがビジーだったことを示す。この場合は、再び該子機に対して状態監視に関するＨＴＴＰリクエストを発行することが一般的であるが、設計事項であり、どのような処理を続けても良い。
　いずれにしても、親機２ａは必ずＨＴＴＰリクエストを発行するため、ＨＴＴＰレスポンスを受け取ることが必須となる。また、受け取った結果から次に何をするかも親機２ａ側の処理であるため、親機側での実装が必要になる。
　最後に親機２ａの情報をどのように活用するか説明する。
　親機２ａが収集した子機２ｂ及びその子機のアウトレットに関する情報は親機２ａ自身が用いるだけでなく監視用ＰＣ１に送り表示することでユーザに提供することが可能になる。
　また親機２ａが上記のＨＴＴＰリクエストを周期的に各子機へ発行し、自動監視及び自動制御を行うことも可能である。
　このようにすることで、遠隔地にある子機及び子機に接続されたネットワーク機器の監視を可能にし、結果大規模なネットワーク環境の管理を可能ならしめる。
（第２の実施の形態）
　次に本発明の第２の実施の形態について説明する。
　本発明においては、親機２ａと子機２ｂの間はＨＴＴＰで通信を行う。従って、１の子機に複数の親機が接続しても他の親機が存在することによって生じる問題は起きない。
　図１５は、本発明の第２の実施の形態に係るトポロジの図である。
　本図では、インターネット９を挟んで２つの親機２ａが接続されている。またこれらにインターネット７経由で、監視用ＰＣ１がこれら２つの親機２ａに接続する。
　第１の実施の形態でも述べたが、子機側はリアクションをするのみであるので、親機側のＩＰアドレス等は覚える必要はない。また、ＨＴＴＰは「記憶を持たない通信方式」であり、通信時の状況にのみ左右されるのでこのような運用をすることができる。
　複数の親機に同じ機能を提供することで監視及び子機制御を容易に二重化でき、障害に強い環境を提供することが可能になる。
　また、一方の親機が再起動等の実行を行い、他方の親機が監視用ＰＣ１に情報を提供することで、処理を分担することが可能になる。
　以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記の実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更が可能であることは言うまでもない。
　例えば、上記ではＨＴＴＰＳリクエストのリクエスト行のパスのクエリストリングの先頭に位置する識別子（例：ＳＴＡＴＵＳ）によって生存確認、状態監視、アウトレットＯｎ・Ｏｆｆの識別をなしていた。これに代えて、使用しないとしていたメッセージボディにこれらを付すことも可能である。
　また上記では、通信方式としてＨＴＴＰ＋ＴＳＬ方式を用いるとしているが、ＨＴＴＰ方式を用いることも本発明の射程に含まれる。また、ＨＴＴＰリクエストメソッドとしてＧＥＴメソッドを用いるとしているが、ＰＯＳＴメソッドで処理を行うことも本発明の射程に含まれることは言うまでもない。
　また、上記では、親機が複数の子機を管理する場合１のテーブル（データフォーム）で管理していた。しかし、子機ごとにテーブルを作成し管理することも本発明の射程に含まれる。
　また上記では状態監視モジュールＳＷ３が返信するアウトレット情報を｛アウトレット番号（１バイト）、アウトレットの特性情報（２バイト）、アウトレットの出力情報（１バイト）｝という固定長バイト表記で表した。これを｛Ｎｕｍｂｅｒ＝１，Ｔｙｐｅ＝５，Ｓｔａｔｕｓ＝Ｏｎ｝（注：Ｎｕｍｂｅｒはアウトレット番号、Ｔｙｐｅはアウトレットの特性情報、Ｓｔａｔｕｓはアウトレットの出力情報）のように可変長テキスト表記に変更することも可能である。同様に親機２ａから子機２ｂに送るアウトレットＯｎ・Ｏｆｆ指示のアウトレット命令を｛Ｎｕｍｂｅｒ＝１，Ｏｒｄｅｒ＝Ｏｎ｝（注：Ｎｕｍｂｅｒはアウトレット番号、Ｏｒｄｅｒはアウトレットコマンド）のような可変長テキスト表記にしても良い。
　また上記ではＩＰｖ４前提で説明したが、ＩＰｖ６での実装も本発明の射程に含まれる。
　本発明はネットワーク機器の監視装置に適用可能である。また、ルータや課金サーバ、ＨＴＴＰサーバだけでなく、他のネットワーク機器を監視対象としても良いことは言うまでもない。
　１：監視用ＰＣ、
　２：ネットワーク機器監視装置、
　２ａ：親機、
　２ｂ、２ｃ：子機、
　３：監視対象Ａ、
　４：監視対象Ｂ、
　７、８：ローカルネットワーク、
　９：インターネット、
　２ｂ－０１、２ｂ－０２、２ｂ－０３、２ｂ－０４、２ｂ－０５、２ｂ－０６：アウトレット、
　２ｂ－１１：ＬＡＮポート、
　２ｂ－１２：電源ケーブル、
　１０１：ＣＰＵ、
１０２：バスコントローラ、
　２０１：メモリ、
　２０２：周辺用バスコントローラ、
　３０１：ＬＡＮ　Ｉ／Ｆ、
　３０２：ＬＥＤコントローラ、
　３０３：リレーコントローラ、
　３１１、３１２，３１３：リレー、
　３２１、３２２、３２３：コンセント。
 

 

Claims (34)

  1. 　ネットワーク機器に電源を供給する子機と、
    　インターネットを介して前記子機と通信を行う親機と、を含むネットワーク機器管理環境であって、
    　前記子機は前記ネットワーク機器への電源供給を行うか決定するスイッチを含み、
    　前記親機が前記子機を制御することを特徴とするネットワーク機器管理環境。
  2. 　請求項１記載のネットワーク機器管理環境において、
    　前記親機がコマンドを発行することで前記子機を制御することを特徴とするネットワーク機器管理環境。
  3. 　請求項２記載のネットワーク機器管理環境において、
    　前記コマンドが前記子機の生存を確認する生存確認コマンドであることを特徴とするネットワーク機器管理環境。
  4. 　請求項２記載のネットワーク機器管理環境において、
    　前記コマンドが前記子機のアウトレットに関する情報を取得する状態監視コマンドであることを特徴とするネットワーク機器管理環境。
  5. 　請求項２記載のネットワーク機器管理環境において、
    　前記コマンドが前記子機の任意のアウトレットを制御するアウトレットＯｎ・Ｏｆｆ指示コマンドであることを特徴とするネットワーク機器管理環境。
  6. 　請求項２記載のネットワーク機器管理環境において、
    　前記コマンドがＨＴＴＰ通信プロトコルで送受信されることを特徴とするネットワーク機器管理環境。
  7. 　請求項３記載のネットワーク環境管理環境において、
    　前記コマンドに対する前記子機からのレスポンスで前記親機に前記子機が正常動作をしていることを通知することを特徴とするネットワーク機器管理環境。
  8. 　請求項４記載のネットワーク環境管理環境において、
    　前記コマンドに対する前記子機からのレスポンスで前記親機が前記子機のアウトレット情報を更新することを特徴とするネットワーク機器管理環境。
  9. 　請求項５記載のネットワーク機器管理環境において、
    　前記コマンドで前記子機の特定のアウトレットの電源供給をＯｎにすることを特徴とするネットワーク機器管理環境。
  10. 　請求項５記載のネットワーク機器管理環境において、
    　前記コマンドで前記子機の特定のアウトレットの電源供給をＯｆｆにすることを特徴とするネットワーク機器管理環境。
  11. 　請求項８記載のネットワーク機器管理環境において、
    　更に監視用ＰＣを含み、
    　前記監視用ＰＣからの求めに応じて前記親機が前記監視用ＰＣに前記子機のアウトレット情報を提供することを特徴とするネットワーク機器管理環境。
  12. 　請求項１乃至１１記載のネットワーク機器管理環境において、
    　前記親機が前記ネットワーク機器を管理することを特徴とするネットワーク機器管理環境。
  13. 　第１のネットワーク機器に電源を供給する第１の子機と、
    　第２のネットワーク機器に電源を供給する第２の子機と、
    　インターネットを介して前記子機と通信を行う親機と、を含むネットワーク機器管理環境であって、
    　前記各子機は前記ネットワーク機器への電源供給を行うか決定するスイッチを含み、
    　前記親機が前記各子機を制御することを特徴とするネットワーク機器管理環境。
  14. 　請求項１３記載のネットワーク機器管理環境において、
    　前記コマンドに対する前記第１の子機からのレスポンス及び前記第２の子機からのレスポンスで前記親機が前記各子機のアウトレット情報を更新することを特徴とするネットワーク機器管理環境。
  15. 　請求項１４記載のネットワーク機器管理環境において、
    　前記親機は１のテーブルで前記第１の子機及び前記第２の子機のアウトレット情報を管理することを特徴とするネットワーク機器管理環境。
  16. 　請求項１３乃至１５記載のネットワーク機器管理環境において、
    　前記親機が前記第１のネットワーク機器及び前記第２のネットワーク機器を管理することを特徴とするネットワーク機器管理環境。
  17. 　ネットワーク機器に電源を供給する子機と、
    　インターネットを介して前記子機と通信を行う第１の親機と、
    前記インターネットを介して前記子機と通信を行う第２の親機と、を含むネットワーク機器管理環境であって、
    　前記子機は前記ネットワーク機器への電源供給を行うか決定するスイッチを含み、
    　前記第１の親機及び前記第２の親機が前記子機を制御することを特徴とするネットワーク機器管理環境。
  18. 　請求項１７記載のネットワーク機器管理環境において、
    　前記第１の親機の機能と、前記第２の親機の機能が同じであることを特徴とするネットワーク機器管理環境。
  19. 　請求項１７記載のネットワーク機器管理環境において、
    　前記第１の親機の機能と、前記第２の親機の機能が異なることを特徴とするネットワーク機器管理環境。
  20. 　アウトレットを介してネットワーク機器に電力を供給するネットワーク機器管理装置子機であって、
    　情報監視コマンドを受信した該ネットワーク機器管理装置子機は自身の持つアウトレットすべてに関するアウトレット情報を前記状態監視コマンドの送信元に返信することを特徴とするネットワーク機器管理装置子機。
  21. 　アウトレットを介してネットワーク機器に電力を供給するネットワーク機器管理装置子機であって、
    　生存確認コマンドを受信した該ネットワーク機器管理装置子機は自身の生存を前記生存確認コマンド送信元に通知することを特徴とするネットワーク機器管理装置子機。
  22. 　アウトレットを介してネットワーク機器に電力を供給するネットワーク機器管理装置子機であって、
    　アウトレットＯｎ・Ｏｆｆ指示コマンドを受信した該ネットワーク機器管理装置子機は前記アウトレットＯｎ・Ｏｆｆ指示コマンドで指定された自身の持つアウトレットの電源供給を制御することを特徴とするネットワーク機器管理装置子機。
  23. 　請求項２２記載のネットワーク機器管理装置子機において、前記制御結果を前記アウトレットＯｎ・Ｏｆｆ指示コマンド送信元に送信することを特徴とするネットワーク機器管理装置子機。
  24. 　アウトレットを介してネットワーク機器に電力を供給するネットワーク機器管理装置子機と協働するネットワーク機器管理装置親機であって、
    　該ネットワーク機器管理装置親機は前記ネットワーク機器管理装置子機に対して状態監視コマンドを送信することを特徴とするネットワーク機器管理装置親機。
  25. 　アウトレットを介してネットワーク機器に電力を供給するネットワーク機器管理装置子機と協働するネットワーク機器管理装置親機であって、
    　該ネットワーク機器管理装置親機は前記ネットワーク機器管理装置子機に対して生存確認コマンドを送信することを特徴とするネットワーク機器管理装置親機。
  26. 　アウトレットを介してネットワーク機器に電力を供給するネットワーク機器管理装置子機と協働するネットワーク機器管理装置親機であって、
    　該ネットワーク機器管理装置親機は前記ネットワーク機器管理装置子機に対してアウトレットＯｎ・Ｏｆｆ指示コマンドを送信することを特徴とするネットワーク機器管理装置親機。
  27. 　請求項２４乃至２６のいずれか１記載のネットワーク機器管理装置親機において、
    　該ネットワーク機器管理装置親機は前記ネットワーク機器管理装置子機に接続されたネットワーク機器の状態を監視することを特徴とするネットワーク機器管理装置親機。
  28. 　請求項２４乃至２７のいずれか１記載のネットワーク機器管理装置親機において、
    　管理用ＰＣからの要求を受けた該ネットワーク機器管理装置親機は前記ネットワーク機器管理装置子機から収集したアウトレット情報を前記管理用ＰＣに送り返すことを特徴とするネットワーク機器管理装置親機。
  29. 　アウトレットを介してネットワーク機器に電力を供給するネットワーク機器管理装置子機であって、
    　第１のＬＡＮ　ＩＦ及び第２のＬＡＮ　ＩＦを含むことを特徴とするネットワーク機器管理装置子機。
  30. 　請求項２９記載のネットワーク機器管理装置子機において、
    　前記第１のＬＡＮ　ＩＦは有線ＬＡＮであることを特徴とするネットワーク機器管理装置子機。
  31. 　請求項２９記載のネットワーク機器管理装置子機において、
    　前記第１のＬＡＮ　ＩＦは無線ＬＡＮであることを特徴とするネットワーク機器管理装置子機。
  32. 　アウトレットを介してネットワーク機器に電力を供給するネットワーク機器管理装置子機と通信を行うネットワーク機器管理装置親機であって、
    　第１のＬＡＮ　ＩＦ及び第２のＬＡＮ　ＩＦを含むことを特徴とするネットワーク機器管理装置親機。
  33. 　請求項３２記載のネットワーク機器管理装置親機において、
    　前記第１のＬＡＮ　ＩＦは有線ＬＡＮであることを特徴とするネットワーク機器管理装置親機。
  34. 　請求項３２記載のネットワーク機器管理装置親機において、
    　前記第１のＬＡＮ　ＩＦは無線ＬＡＮであることを特徴とするネットワーク機器管理装置親機。

     
PCT/JP2021/020140 2020-05-29 2021-05-27 ネットワーク機器管理環境、ネットワーク機器管理装置子機及びネットワーク機器管理装置親機 WO2021241672A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2020094244A JP7082447B2 (ja) 2020-05-29 2020-05-29 ネットワーク機器管理環境、ネットワーク機器管理装置子機及びネットワーク機器管理装置親機
JP2020-094244 2020-05-29

Publications (1)

Publication Number Publication Date
WO2021241672A1 true WO2021241672A1 (ja) 2021-12-02

Family

ID=78744616

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2021/020140 WO2021241672A1 (ja) 2020-05-29 2021-05-27 ネットワーク機器管理環境、ネットワーク機器管理装置子機及びネットワーク機器管理装置親機

Country Status (2)

Country Link
JP (1) JP7082447B2 (ja)
WO (1) WO2021241672A1 (ja)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004221867A (ja) * 2003-01-14 2004-08-05 Matsushita Electric Ind Co Ltd ネットワーク機器電源制御装置
JP2015106393A (ja) * 2013-12-03 2015-06-08 キヤノン株式会社 画像形成システム、画像形成装置、これらの制御方法およびプログラム
JP2016115273A (ja) * 2014-12-17 2016-06-23 株式会社リコー 電力制御システム、電力制御方法、情報処理装置、および電力制御プログラム
JP2019084768A (ja) * 2017-11-08 2019-06-06 キヤノン株式会社 画像形成装置、制御方法およびプログラム

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004221867A (ja) * 2003-01-14 2004-08-05 Matsushita Electric Ind Co Ltd ネットワーク機器電源制御装置
JP2015106393A (ja) * 2013-12-03 2015-06-08 キヤノン株式会社 画像形成システム、画像形成装置、これらの制御方法およびプログラム
JP2016115273A (ja) * 2014-12-17 2016-06-23 株式会社リコー 電力制御システム、電力制御方法、情報処理装置、および電力制御プログラム
JP2019084768A (ja) * 2017-11-08 2019-06-06 キヤノン株式会社 画像形成装置、制御方法およびプログラム

Also Published As

Publication number Publication date
JP7082447B2 (ja) 2022-06-08
JP2021189735A (ja) 2021-12-13

Similar Documents

Publication Publication Date Title
JP4624701B2 (ja) ネットワークを介した機器情報の管理装置およびその方法
JP4065434B2 (ja) ルータ装置およびルータ装置の立上げ方法
US7555007B2 (en) Integrated management system and method for network connection means in networks having different telecommunication protocols
JP2003337772A (ja) 通信ネットワークを介した遠隔制御サービス提供装置及びこれを用いたシステム並びにその方法
US9130783B2 (en) Relay communication system and access management apparatus
US20050044196A1 (en) Method of and system for host based configuration of network devices
JP4792964B2 (ja) 位置情報システム
AU2006201049A1 (en) Network device and management technique of the same
WO2021241672A1 (ja) ネットワーク機器管理環境、ネットワーク機器管理装置子機及びネットワーク機器管理装置親機
JP2004193988A (ja) ネットワーク接続手段の集中管理システム及び方法
JP2004306200A (ja) ロボット制御システム
JP2000236348A (ja) インターネットプロトコルを用いた遠隔機器の管理システム
CN111130865A (zh) 一种基于二层交换的网络设备固件批量升级方法及***
JP4792963B2 (ja) 位置情報システム
CN104022901A (zh) 国网集中器onu模块的plc配置管理方法
JP4635523B2 (ja) 位置情報システム及びそのシステムで用いられる機器、集線装置、並びに機器管理装置
JP4092858B2 (ja) インターネット接続におけるセキュリティ方法およびターミナルアダプタ装置
JP4792962B2 (ja) 位置情報システム
JP4820381B2 (ja) ネットワーク構成方法、ノード装置、管理装置およびネットワーク
KR20070079860A (ko) 복수의 구성요소들을 하나의 공인 ｉｐ를 통해 관리하는원격관리 시스템 및 그 방법
KR102689073B1 (ko) 원격 전원 제어를 위한 네트워크 스위치, 네트워크 관리 장치 및 시스템
JP6465745B2 (ja) 構成方法、サーバ、及び、端末
JP5077311B2 (ja) 中継通信システム及びアクセス管理装置
JP5700295B2 (ja) ネットワークシステム
JP5272974B2 (ja) 中継通信システム及びアクセス管理装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21812858

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21812858

Country of ref document: EP

Kind code of ref document: A1