WO2021255826A1 - 宅内機器管理装置、方法およびプログラム - Google Patents

宅内機器管理装置、方法およびプログラム Download PDF

Info

Publication number
WO2021255826A1
WO2021255826A1 PCT/JP2020/023570 JP2020023570W WO2021255826A1 WO 2021255826 A1 WO2021255826 A1 WO 2021255826A1 JP 2020023570 W JP2020023570 W JP 2020023570W WO 2021255826 A1 WO2021255826 A1 WO 2021255826A1
Authority
WO
WIPO (PCT)
Prior art keywords
vendor
information
unit
home
user terminal
Prior art date
Application number
PCT/JP2020/023570
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 日本電信電話株式会社
Priority to JP2022531141A priority Critical patent/JP7414138B2/ja
Priority to US18/008,382 priority patent/US11824676B2/en
Priority to PCT/JP2020/023570 priority patent/WO2021255826A1/ja
Publication of WO2021255826A1 publication Critical patent/WO2021255826A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0813—Configuration setting characterised by the conditions triggering a change of settings
    • H04L41/082—Configuration setting characterised by the conditions triggering a change of settings the condition being updates or upgrades of network functionality
    • 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]
    • H04L12/2803—Home automation networks
    • H04L12/2807—Exchanging configuration information on appliance services in a home automation network
    • H04L12/2812—Exchanging configuration information on appliance services in a home automation network describing content present in a home automation network, e.g. audio video content
    • 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]
    • H04L12/2803—Home automation networks
    • H04L12/2807—Exchanging configuration information on appliance services in a home automation network
    • 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]
    • H04L12/2803—Home automation networks
    • H04L12/2816—Controlling appliance services of a home automation network by calling their functionalities
    • H04L12/2818—Controlling appliance services of a home automation network by calling their functionalities from a device located outside both the home and the home network
    • 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]
    • H04L12/2803—Home automation networks
    • H04L12/283—Processing of data at an internetworking point of a home automation network
    • H04L12/2836—Protocol conversion between an external network and a home network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/085—Retrieval of network configuration; Tracking network configuration history
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/085—Retrieval of network configuration; Tracking network configuration history
    • H04L41/0853—Retrieval of network configuration; Tracking network configuration history by actively collecting configuration information or by backing up configuration information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/22—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks comprising specially adapted graphical user interfaces [GUI]

Definitions

  • An embodiment of the present invention relates to a home device management device, a method and a program.
  • Non-Patent Document 1 As a representative standard of HEMS, there is the ECHONET Lite standard (see Non-Patent Document 1) by the Echonet Consortium, and if the device complies with this standard, the management device may be a device of a different vendor. Can be managed in common.
  • ECHONET Lite makes it possible to refer to and control home devices as IoT devices from the outside from the conventional HEMS-like use, so Web API (non-patented) as a common API for cloud applications. (Refer to Reference 2) is also set. If you create an application that conforms to this API, you can access devices from different vendors with the same application as long as it is an ECHONET Lite compatible device.
  • ECHONET Lite Standards Ver.1.13 Part 1 Overview of ECHONET Lite https://echonet.jp/wp/wp-content/uploads/pdf/General/Standard/ECHONET_lite_V1_13_jp/ECHONET-Lite_Ver.1.13_01.pdf
  • ECHONET Lite Web API Guidelines https://echonet.jp/wp/wp-content/uploads/pdf/General/Download/web_API/ECHONET_Lite_Web_API_guideline_v1.00.pdf
  • vendor-specific equipment that does not support the ECHONET Lite standard
  • the present invention was made by paying attention to the above circumstances, and the purpose of the present invention is to provide a technology that enables access to a vendor-specific device from a common API-compatible application.
  • the home device management device is a home device management device connected to a user terminal and a user home home control device corresponding to the user terminal via a wide area network.
  • the device management table in which the address information in the home network and the device information for specifying the device including the vendor name are registered for each of the standard-compliant devices connected to the home network of the user's home.
  • information on the vendor-specific device is provided to the home control device that controls the standard-compliant device and the vendor-specific device connected to the home network.
  • the registration unit registered in the device management table together with the identification information indicating that the device is a vendor-specific device, and the information of the vendor-specific device registered in the device management table by the registration unit are sent to the user terminal.
  • the confirmation unit that acquires the result of approval, modification, or addition by the user terminal, and the result of approval, modification, or addition by the user terminal acquired by the confirmation unit, the vendor-specific specification in the device management table. It is equipped with an update unit that updates the registered contents of the device.
  • FIG. 1 is a diagram showing an overall configuration of a home device management system according to the first embodiment of the present invention.
  • FIG. 2 is a diagram showing an example of a device management table.
  • FIG. 3 is a diagram showing an example of a protocol conversion table for company A.
  • FIG. 4 is a schematic diagram showing an example of a computer configuration of an IoT common API compatible server.
  • FIG. 5 is a diagram showing a data flow between each part of the home device management system when device registration is performed in the normal mode.
  • FIG. 6 is a sequence diagram showing data communication between each unit when device registration is performed in the normal mode.
  • FIG. 7 is a diagram showing an example of a device management table after device registration.
  • FIG. 1 is a diagram showing an overall configuration of a home device management system according to the first embodiment of the present invention.
  • FIG. 2 is a diagram showing an example of a device management table.
  • FIG. 3 is a diagram showing an example of a protocol conversion table for company A.
  • FIG. 4
  • FIG. 8 is a diagram showing a data flow between each part of the home device management system when device registration is performed in the extended mode.
  • FIG. 9 is a sequence diagram showing data communication between each unit when device registration is performed in the extended mode.
  • FIG. 10 is a diagram showing an example of a device management table after device registration.
  • FIG. 11 is a diagram showing a data flow between each part of the home device management system when controlling the device in the user's home.
  • FIG. 12 is a sequence diagram showing data communication between each unit when controlling an air conditioner (hereinafter, abbreviated as an air conditioner), which is a standard-compliant device.
  • FIG. 13 is a sequence diagram showing data communication when controlling an air conditioner, which is a device of company A's original specifications.
  • FIG. 14 is a diagram showing the overall configuration of the home device management system according to the second embodiment of the present invention and the flow of data between each part of the home device management system when controlling the devices in the user's home.
  • FIG. 15 is a sequence diagram showing data communication when controlling an air conditioner, which is a device of company A's original specifications.
  • FIG. 16 is a diagram showing the overall configuration of the home device management system according to the third embodiment of the present invention and the flow of data between each part of the home device management system when the device is registered in the extended mode.
  • FIG. 17 is a sequence diagram showing data communication between each unit when device registration is performed in the extended mode.
  • FIG. 1 is a diagram showing the overall configuration of the home device management system 100 according to the first embodiment of the present invention.
  • the home device management system shown in FIG. 1 includes a user terminal 101, a user home 102, and an IoT common API as a home crisis management device according to the first embodiment, which can be connected to each other via a wide area network such as the Internet. It is equipped with a corresponding server 103.
  • the IoT common API compatible server 103 is configured on the cloud, and the user terminal 101 can communicate with the device deployed in the user's home 102 via the IoT common API compatible server 103. Note that FIG.
  • the user terminal 101 shows only one set of the user terminal 101 and the user's home 102, but it goes without saying that a plurality of sets may be included.
  • a plurality of user terminals 101 can be combined with one user's home 102.
  • the user's house 102 is not limited to the user's residence, but may include a facility used by the user such as an office or a workplace.
  • the user terminal 101 may be any mobile device such as a smartphone, a wearable terminal, or a tablet.
  • a common API-compatible application (described as a common API-compatible application in the figure) 110 is operating.
  • the common API compatible application 110 can display the "device registration” button and the "device control” button on the GUI display unit 111 provided by the user terminal 101.
  • the GUI display unit 111 includes, for example, a touch panel in which a display device and a position input device are combined, and by touching the position of the displayed "device registration” button or “device control” button, the user is allowed to touch the position in the user's house 102. You can select whether you want to register the device or control it.
  • the common API-compatible application 110 When the user selects device registration, the common API-compatible application 110 further displays a mode selection button on the GUI display unit 111 to allow the user to select whether to perform device registration in the normal mode or the extended mode. Is possible.
  • the common API-compatible application 110 can display a list of devices to be controlled on the GUI display unit 111 and allow the user to select the device to be controlled.
  • the common API-compatible application 110 can further display a control item on the GUI display unit 111 and instruct the user how to control the selected device.
  • the control items are, for example, temperature, air volume, wind direction, etc. when the device to be controlled is an air conditioner.
  • the common API-compatible application 110 transmits an instruction selected by the user to the IoT common API-compatible server 103 on the cloud by the wireless communication unit included in the user terminal 101.
  • the user home 102 includes a controller 120, a device 121, a device 122, and a device 123 connected to each other via a home network.
  • the controller 120 is an in-home control device that controls the devices 121 to 123 via the in-home network.
  • the device 121 and the device 122 are standard-compliant devices, and in FIG. 1, the device 121 is shown as the device 1 (standard), and the device 122 is shown as the device 2 (standard).
  • the device 123 is a vendor-specific device, for example, a device of company A's own specifications, and is shown as device 3 (company A's own) in FIG.
  • the device and controller 120 in the user's home 102 are connected to the IoT common API compatible server 103 on the cloud via a gateway / router or the like that connects the home network and the wide area network outside the home, which is not shown in FIG. Communication is possible.
  • the IoT common API compatible server 103 includes a GUI unit 130, a device search unit 131, a device information input unit 132, a device management table 133, and a device control unit 134.
  • the GUI unit 130 can receive an instruction from the user terminal 101 and determine whether the instruction is device registration or device control, and further, the device registration is extended to the normal mode or extended according to the instruction further received when the device registration instruction is received. It is possible to determine whether it is done in the mode.
  • the GUI unit 130 sends a device registration request to the device search unit 131 when the instruction is device registration, and sends a request message corresponding to the common API to the device control unit 134 when the instruction is device control.
  • the GUI unit 130 can also send information from the user terminal 101 to the device information input unit 132.
  • the device search unit 131 operates in the normal mode or the extended mode depending on whether the device registration is performed in the normal mode or the extended mode.
  • the device search unit 131 transmits a device inquiry request (normal) to the controller 120 of the user's home 102 via the cloud.
  • the device search unit 131 transmits a device inquiry request (extended) to the controller 120 of the user's house 102 via the cloud.
  • the device information input unit 132 can receive device information, a MAC address value, an IP address value, etc. for each device of the user's house 102 from the controller 120 of the user's house 102.
  • the device information input unit 132 inputs information about each of these received devices or information from the user terminal 101 received by the GUI unit 130 into the device management table 133.
  • the device management table 133 is stored in a non-volatile memory such as a flash memory that can be written and read at any time, corresponding to each of the user's homes 102 managed by the IoT common API compatible server 103.
  • the device management table 133 shows the model name, device name, identification number, IP address value, common / extended flag, MAC address value, and vendor for each of the devices arranged in the user's house 102. I remember my name.
  • FIG. 2 shows a case where no device is stored, that is, a case where all the values are blank.
  • the common / extended flag is a flag value for determining whether the registered device is a standard-compliant device or a vendor-specific device, and has one bit.
  • the device control unit 134 controls to control the devices 121 to 123 of the user's house 102.
  • the device control unit 134 includes a plurality of protocol conversion tables 135A, 135B, ..., A device type determination unit 136, a command conversion unit 137, and a protocol conversion unit 138.
  • the protocol conversion tables 135A, 135B, ... are stored in a non-volatile memory such as a flash memory that can be written or read at any time.
  • One protocol conversion table can be created for each vendor to be converted.
  • the protocol conversion table is created in advance by the management source or operation source of the IoT common API compatible server 103 based on the publicly available information or the information acquired by concluding a technical contract with the corresponding vendor, and is compatible with the IoT common API. It is installed in the server 103.
  • FIG. 3 is an example of a protocol conversion table (protocol conversion table (A)) 135A for company A, which includes a model name, a model code (standard), a model code (company A), a parameter name (common API), and a parameter code.
  • Protocol conversion table 135A for company A is shown, but there is also a protocol conversion table for company B as shown in FIG. 1, and there is also a protocol conversion table for any other vendor. do.
  • the device type determination unit 136 determines whether the device control target is a standard-compliant device or a vendor-specific device by referring to the device management table 133.
  • the command conversion unit 137 converts a common API-compatible request message into a standard-compatible command when the device control target is a standard-compatible device.
  • the protocol conversion unit 138 converts a common API-compatible request message into a vendor-specific command when the device control target is a vendor-specific device. For example, when the request message corresponding to the common API is a message for controlling the device of company A, the protocol conversion unit 138 refers to the protocol conversion table (A) 135A for company A and specifies the original specifications of company A. It is possible to convert the request message corresponding to the common API for the device of A company into the command of the company A's original specification.
  • the IoT common API-compatible server 103 has a correspondence relationship between the user terminal 101 and the user's home 102, and address information necessary for communicating with the controller 120 of the user terminal 101 and the user's home 102.
  • user information including, etc. is stored in advance in the format of a user database or the like.
  • FIG. 4 is a schematic diagram showing an example of a computer configuration that can support a user terminal 101, an IoT common API compatible server 103, or a controller 120.
  • the user terminal 101, the IoT common API compatible server 103, or the controller 120 is configured by a computer device and has a processor 401 such as a CPU. Then, in the IoT common API compatible server 103 and the controller 120, the processor 401 communicates with the program memory 402, the data memory 403, the storage 404, and the input / output interface (referred to as input / output IF in FIG. 4) 405. The interface 406 is connected via the bus 407. Further, in the user terminal 101, a communication device 408 is further connected to the processor 401.
  • the program memory 402 is a non-temporary tangible computer-readable storage medium in which, for example, a non-volatile memory such as a flash memory that can be written and read at any time and a non-volatile memory such as a ROM (Read Only Memory) are combined. It was used.
  • the program memory 402 stores programs necessary for the processor 401 to execute various control processes.
  • the data memory 403 is used as a tangible computer-readable storage medium, for example, in combination with the above-mentioned non-volatile memory and a volatile memory such as RAM (RandomAccessMemory).
  • the data memory 403 is used to store various data acquired and created in the process of performing various processes.
  • the storage 404 is a non-temporary tangible computer-readable storage medium, for example, a large-capacity storage using a non-volatile memory such as an HDD (Hard Disk Drive) or SSD (Solid State Drive) that can be written and read at any time. Has a medium.
  • the storage 404 stores various programs and data necessary for the processor 401 to execute various control processes. For example, a control program necessary for the processor 401 to execute the control process as the user terminal 101, the IoT common API compatible server 103, or the controller 120 according to the first embodiment is stored. The program stored in the storage 404 is read out onto the data memory 403 by the processor 401 and executed as needed. Further, the storage 404 of the IoT common API compatible server 103 stores the device management table 133, the protocol conversion tables 135A, 135B, ....
  • the control program in the user terminal 101 can, for example, make the processor 401 of the user terminal 101 function as a common API-compatible application 110. Further, the control program in the IoT common API compatible server 103 can make the processor 401 of the IoT common API compatible server 103 function as a GUI unit 130, a device search unit 131, a device information input unit 132, and a device control unit 134. .. Further, the control program in the controller 120 can cause the processor 401 of the controller 120 to function as the search mode determination unit 124, the standard search function unit 125, and the extended search function unit 126. The management program may be stored in the program memory 402 instead of the storage 404.
  • An input unit 409 and a display unit 410 are connected to the input / output interface 405.
  • the input unit 409 and the display unit 410 can use a touch panel like the GUI display unit 111 of the user terminal 101. Further, the input unit 409 and the display unit 410 may be configured by independent devices, respectively.
  • the communication interface 406 is an interface that adopts a low power wireless data communication standard such as Bluetooth (registered trademark) in the user terminal 101.
  • the communication interface 406, in the controller 120, may include a wireless or wired communication module for connecting to a home network.
  • the communication interface 406 may include a wireless or wired communication module for connecting to a wide area network in the IoT common API compatible server 103.
  • the communication device 408 in the user terminal 101 is a wireless communication device for connecting to a wireless access network for accessing a wide area network.
  • the wireless access network includes, for example, a mobile phone network that operates under a standard such as 3G, 4G, or 5G, a wireless LAN (Local Area Network), and the like.
  • FIG. 5 is a diagram showing a data flow between each part of the home device management system when device registration is performed in the normal mode.
  • FIG. 6 is a sequence diagram showing data communication between each unit when device registration is performed in the normal mode.
  • the devices 121 to 123 arranged in the user's house 102 will be described as air conditioners 501 to 503. That is, the standard-compliant device 121 (device 1 (standard)) and the device 122 (device 2 (standard)) are shown as the standard-compliant air conditioner 501 (air conditioner 1 (standard) in FIG. 5, and the air conditioner in FIG. 6). 1) and air conditioner 502 (shown as air conditioner 2 (standard) in FIG. 5 and shown as air conditioner 2 in FIG. 6). Further, the device 123 (equipment 3 (unique to company A)) unique to company A is shown as an air conditioner 503 (proprietary to air conditioner 3 (unique to company A) in FIG. 5) and is shown as air conditioner 3 in FIG. .).
  • the user selects device registration through the GUI display unit 111, and further selects a normal mode (ST1).
  • the common API-compatible application 110 of the user terminal 101 transmits a device registration request (normal) indicating that device registration is performed in the normal mode to the IoT common API-compatible server 103 (S1).
  • the IoT common API compatible server 103 that has received the device registration request (normal) determines in the GUI unit 130 that the device registration is performed in the normal mode based on the received device registration request (normal) (ST2).
  • the GUI unit 130 transmits to the device search unit 131 an instruction for the device search unit 131 to operate in the normal mode (S2).
  • the device search unit 131 Upon receiving the instruction, the device search unit 131 operates in the normal mode and transmits a device inquiry request (normal) to the controller 120 of the user's home 102 corresponding to the user of the user terminal 101 (S3).
  • the controller 120 that has received the device inquiry request (normal) determines in the search mode determination unit 124 that the received device inquiry request (normal) is in the normal mode (ST3).
  • the search mode determination unit 124 transmits an instruction to issue a device search request command corresponding to the standard to the standard search function unit 125 (S4).
  • the standard search function unit 125 When the standard search function unit 125 receives the instruction, it sends a standard-compliant device search request command to all of the air conditioners 501 to 503 via the network in the house (S5).
  • the air conditioner 501 and the air conditioner 502 which are devices conforming to the standard, can recognize the device search request corresponding to the standard. Therefore, each of the air conditioner 501 and the air conditioner 502 returns the device information including the model name, the device name, the identification number, the IP address value, and the like to the standard search function unit 125 (S6).
  • the air conditioner 503, which is a vendor-specific device does not respond because it cannot recognize the device search request corresponding to this standard.
  • the standard search function unit 125 that has received the device information additionally transmits a MAC address acquisition request to the air conditioner 501 and the air conditioner 502 that are determined to be devices conforming to the standard (S7).
  • the standard search function unit 125 acquires the MAC address values returned from each of the air conditioner 501 and the air conditioner 502 (S8).
  • the controller 120 transmits the acquired device information and the MAC address value to the IoT common API compatible server 103.
  • the IoT common API compatible server 103 sends the received device information and the MAC address value to the device information input unit 132 (S9).
  • the device information input unit 132 inputs the device information and the MAC address value of the device corresponding to the standard in the device management table 133, and registers each device with the common / extended flag value set to "0" (ST4).
  • FIG. 7 is an example of the device management table 133 after performing the device registration described with reference to FIGS. 5 and 6 in the normal mode.
  • the device management table 133 After performing the device registration in the normal mode, it is possible to register the information about the air conditioners 501 and 502, which are the devices conforming to the standard, in the device management table 133.
  • the information about the air conditioner 503, which is the device of the company A's original specifications cannot be registered in the device management table 133. Since the vendor name cannot be obtained from the device information, it is not registered and is N / A.
  • the IoT common API-compatible server 103 is registered in the device management table 133 in the common API-compatible application 110 of the user terminal 101 after registering information about the device in the device management table 133. Sends information indicating that the device is being controlled.
  • the common API-compatible application 110 of the user terminal 101 that has received the information shall display it as a device to be controlled.
  • FIG. 8 is a diagram showing a data flow between each part of the home device management system when device registration is performed in the extended mode.
  • FIG. 9 is a sequence diagram showing data communication between each unit when device registration is performed in the extended mode.
  • the device is registered after the device registration already described with reference to FIGS. 5 and 6 is performed in the normal mode. Therefore, it is assumed that the information regarding the air conditioner 501 and the air conditioner 502 shown in FIG. 7 is registered in the device management table 133.
  • the device search unit 131 When the device registration is performed in the extended mode, the device search unit 131 operates in the extended mode and can send a device inquiry request (extended) to the controller 120.
  • the controller 120 can transmit a MAC address acquisition request by multicast from the extended search function unit 126 in response to the reception of the device inquiry request (extended).
  • the user selects device registration through the GUI display unit 111, and further selects the extended mode (ST21).
  • the common API-compatible application 110 of the user terminal 101 transmits a device registration request (extension) indicating that device registration is performed in the extended mode to the IoT common API-compatible server 103 (S21).
  • the IoT common API compatible server 103 that has received the device registration request (extended) determines in the GUI unit 130 that the device registration is performed in the extended mode based on the received device registration request (extended) (ST22).
  • the GUI unit 130 transmits to the device search unit 131 an instruction for the device search unit 131 to operate in the extended mode (S22).
  • the device search unit 131 Upon receiving the instruction, the device search unit 131 operates in the extended mode and transmits a device inquiry request (extended) to the controller 120 of the user's home 102 corresponding to the user of the user terminal 101 (S23).
  • the device search unit 131 functions as an inquiry unit that inquires of the vendor-specific device information to the controller 120, which is a home control device, in response to a registration request from the user terminal.
  • the controller 120 that has received the device inquiry request (extended) determines in the search mode determination unit 124 that the received device inquiry request (extended) is in the extended mode (ST23).
  • the search mode determination unit 124 transmits an instruction for making a MAC address acquisition request to the extended search function unit 126 (S24).
  • the extended search function unit 126 Upon receiving the instruction, the extended search function unit 126 transmits a MAC address acquisition request to the air conditioners 501 to 503 via the in-house network by multicast (S25).
  • the air conditioners 501 to 503 that have received the MAC address acquisition request return their respective MAC address values and IP address values to the extended search function unit 126 (S26).
  • the controller 120 transmits the acquired MAC address value and IP address value to the IoT common API compatible server 103.
  • the IoT common API compatible server 103 sends the received MAC address value and IP address value to the device information input unit 132 (S27).
  • the device information input unit 132 collates each of the received MAC address values with the MAC address values registered in the device management table 133. As a result, for example, it is found that the MAC address values of the air conditioner 501 and the air conditioner 502 have been registered, and the MAC address values of the air conditioner 503 have not been registered. Therefore, the device information input unit 132 determines that the unregistered device is a device of the vendor's original specification, inputs the MAC address value and the IP address value to the device management table 133, and sets the common / extended flag value to "1". By setting, the air conditioner 503 is registered (ST24).
  • the device information input unit 132 receives at least the address information of the device unique to the vendor, which is sent from the controller 120 as the home control device in response to the inquiry from the device search unit 131 as the inquiry unit. It functions as a registration unit for registering information of the air conditioner 503, which is a vendor-specific device, including the common / extended flag value, which is identification information indicating that the device is a vendor-specific device, in the device management table 133.
  • the device information input unit 132 sends the MAC address value and the IP address value of the air conditioner 503 in this example to the GUI unit 130 for each of the vendor-specific devices registered this time in the device management table 133 (S28).
  • the GUI unit 130 transmits the MAC address value and the IP address value to the common API-compatible application 110 of the user terminal 101 (S29).
  • the common API-compatible application 110 of the user terminal 101 is a device that includes the MAC address value and the IP address value of the device transmitted to the GUI unit 130 of the user terminal 101, as well as the model name, device name, and vendor name of the device. Display the device information input screen that allows you to input information. The user inputs device information including a model name, a device name, and a vendor name on this device information input screen (ST25). Then, the common API-compatible application 110 of the user terminal 101 transmits these input device information to the IoT common API-compatible server 103 (S30).
  • the GUI unit 130 of the IoT common API compatible server 103 receives the device information and transmits it to the device information input unit 132 (S31).
  • the GUI unit 130 and the device information input unit 132 send the address information, which is the information of the vendor-specific device registered in the device management table 133 by the device information input unit 132 as the registration unit, to the user terminal 101.
  • the device information input unit 132 inputs the device information sent from the GUI unit 130 into the device management table 133 of the unregistered device.
  • the device information input unit 132 automatically generates this identification number after inputting the device information. Is registered in the device management table 133 (ST26).
  • the device information input unit 132 is a vendor-specific device in the device management table 133 based on the device information obtained by the GUI unit 130 as the confirmation unit and the user terminal 101 acquired by the device information input unit 132. It functions as an update unit that updates the registered contents.
  • FIG. 10 is an example of the device management table 133 after performing the device registration described with reference to FIGS. 8 and 9 in the extended mode.
  • the information about the air conditioner 503, which is the device of the vendor A's original specification, which was not registered in the normal mode is registered in the device management table 133. It will be.
  • the standard-compliant device is registered with the common / extended flag value as "0"
  • the vendor-specific device is registered with the common / extended flag value as "1".
  • the vendor-specific device that was not registered in the device management table 133 and was not displayed as a device to be controlled in the common API-compatible application 110 of the user terminal 101 just by registering the device in the normal mode. Is also registered in the device management table 133, and is displayed as a device to be controlled in the common API-compatible application 110 of the user terminal 101.
  • FIG. 11 is a diagram showing a data flow between each part of the home device management system when the user controls the devices in the user home 102.
  • the device control is executed after the device registration described above is performed in the normal mode and the extended mode. Therefore, it is assumed that information about each air conditioner is registered in the device management table 133, for example, as shown in FIG. Further, it is assumed that the protocol conversion tables (A) 135A and (B) 135B are created in advance by the operation source of the IoT common API compatible server 103 and stored in the IoT common API compatible server 103.
  • the device control unit 134 searches the device management table 133 for the device to be controlled by the device type determination unit 136 based on the device control request message including the device control information from the common API-compatible application of the user terminal 101. Is possible.
  • the device control unit 134 determines that the device to be controlled is a device compliant with the standard.
  • the device control unit 134 further confirms the vendor name of the device management table 133, for example, the vendor name is A. In the case of a company, it is possible to determine that the device to be controlled is a device of company A's original specifications.
  • the device type determination unit 136 determines that the device to be controlled is a device compatible with the standard
  • the device type determination unit 136 sends a device control request message to the command conversion unit 137.
  • the command conversion unit 137 can convert the control information included in the device control request message into a command corresponding to the standard in binary format and send it to the controller 120.
  • the controller 120 can control the device to be controlled by sending a command corresponding to the standard to the device to be controlled.
  • the device control request message and the device to be controlled are the device of company A's own specification. It is possible to transmit the information that there is to the protocol conversion unit 138.
  • the protocol conversion unit 138 refers to a corresponding protocol conversion table, for example, the protocol conversion unit 138 (A), and converts the control information included in the device control request message into a binary format command specified by the company A. Then, the protocol conversion unit 138 can control the device to be controlled by directly transmitting this command to the device to be controlled.
  • FIG. 12 is a sequence diagram showing data communication between each unit when controlling the air conditioner 501, which is a standard-compliant device.
  • a list of control target devices is displayed on the GUI display unit 111.
  • the user selects air conditioner 501.
  • the GUI display unit 111 displays items for controlling the temperature, air volume, wind direction, etc., for example, the user inputs the set temperature as 20 degrees (ST41).
  • the common API compatible application 110 creates a common API compatible device control request message including control information selected and input by these users. Then, the common API-compatible application 110 of the user terminal 101 transmits the device control request message corresponding to the common API to the GUI unit 130 of the IoT common API-compatible server 103 (S41).
  • the GUI unit 130 determines that the message received from the common API-compatible application 110 of the user terminal 101 is a device control request message including control information, and determines that the device control request message corresponding to the common API is the device type of the device control unit 134. It is transmitted to the determination unit 136 (S42).
  • the device type determination unit 136 determines that the device control request message corresponding to the common API is intended for the air conditioner 501, searches for the air conditioner 501 registered in the device management table 133, and sets the value of the common / extended flag. Confirm. As shown in FIG. 7, since the value of the common / extended flag of the air conditioner 501 is “0”, the device type determination unit 136 determines that the air conditioner 501 is a device conforming to the standard (ST42).
  • the device type determination unit 136 determines that the air conditioner 501 is a standard-compliant air conditioner, and transmits a common API-compatible device control request message including control information to the command conversion unit 137 (S43).
  • the command conversion unit 137 converts the control information included in the received device control request message corresponding to the common API into a command corresponding to the standard in binary format (ST43). Then, the command conversion unit 137 transmits the command corresponding to this standard to the controller 120 of the user's house 102 corresponding to the user terminal 101 (S44).
  • the controller 120 transmits the received command to the air conditioner 501, which is the device to be controlled (S45).
  • the air conditioner 501 sets the temperature setting to 20 degrees according to the command (ST44).
  • FIG. 13 is a sequence diagram showing data communication between each unit when controlling the air conditioner 503, which is a device of company A's original specifications.
  • a list of control target devices is displayed on the GUI display unit 111.
  • the user selects the air conditioner 503.
  • the GUI display unit 111 displays items for controlling the temperature, air volume, wind direction, etc., for example, the user inputs the set temperature as 20 degrees (ST51).
  • the common API compatible application 110 creates a common API compatible device control request message including control information selected and input by these users. Then, the common API-compatible application 110 of the user terminal 101 transmits the device control request message corresponding to the common API to the GUI unit 130 of the IoT common API-compatible server 103 (S51).
  • the GUI unit 130 determines that the message received from the common API-compatible application 110 of the user terminal 101 is a device control request message including control information, and determines that the device control request message corresponding to the common API is the device type of the device control unit 134. It is transmitted to the determination unit 136 (S52).
  • the GUI unit 130 functions as a request receiving unit for receiving a device control message, which is a control request including the device to be controlled in the user's house 102 and the control content thereof, from the end of the user end 101.
  • the device type determination unit 136 determines that the device control request message corresponding to the common API is intended for the air conditioner 503, searches for the air conditioner 503 registered in the device management table 133, and sets the value of the common / extended flag. Confirm. As shown in FIG. 7, since the value of the common / extended flag of the air conditioner 503 is “1”, the device type determination unit 136 further confirms the vendor name registered in the device management table 133. Since the registered vendor name is company A, the device type determination unit 136 determines that the air conditioner 503 is a device of company A's own specifications (ST52).
  • the device type determination unit 136 determines whether the device to be controlled included in the control request received by the GUI unit 130 as the request receiving unit is a standard-compliant device or a vendor-specific device. , It functions as a discriminating unit for discriminating by referring to the device management table 133.
  • the device type determination unit 136 determines that the air conditioner 503 is an air conditioner of company A's own specifications, and receives a common API-compatible device control request message including control information and information that the air conditioner 503 is a device of company A's own specifications. It is transmitted to the protocol conversion unit 138 (S53).
  • the protocol conversion unit 138 refers to the corresponding protocol conversion table (A) 135A based on the received information that the device is a device of the company A's own specification, and binaries the control information included in the device control request message corresponding to the common API. It is converted into a command of the format A company's original specification (ST53).
  • the protocol conversion unit 138 directly transmits the command of the company A's original specifications to the air conditioner 503, which is the control target of the user's house 102 corresponding to the user terminal 101, without going through the controller 120 (S54).
  • the protocol conversion unit 138 refers to the protocol conversion table, converts the control content included in the control request into a command specified by the vendor, and transmits the command to the air conditioner 503, which is the device to be controlled. Functions as.
  • the air conditioner 503 that received the command from the protocol conversion unit 138 sets the temperature setting to 20 degrees according to the command (ST54).
  • the vendor having the original specification device can recognize the vendor's original specification device by the IoT common API compatible server 103 without making any special modification to the company's product. Therefore, it is possible to access the vendor's original device from the common API compatible application 110. Furthermore, by holding the protocol conversion table in the IoT common API compatible server 103, the common API specifications can be converted to the vendor's original specifications, and the common API compatible application 110 can be used to refer to the vendor's original specifications. Control is possible.
  • the user can uniformly refer to and control the standard-compliant device and the vendor-specific device by using only the common API-compatible application 110. Therefore, the user only needs to install the common API compatible application 110 on the user terminal 101, and it is not necessary to switch between the common API compatible application 110 and the vendor's original application for each control target model, which improves convenience. ..
  • FIG. 14 is a diagram showing the overall configuration of the home device management system according to the second embodiment of the present invention and the flow of data between each part of the home device management system when controlling the devices in the user's home.
  • the home device management system in the present embodiment is different from the first embodiment in the following points. That is, in the present embodiment, the protocol conversion function does not exist in the IoT common API-compatible server 103, but exists in the shared protocol conversion server 1401 on the cloud 1402.
  • the shared protocol conversion server 1401 includes a protocol conversion receiving unit 1410, a protocol conversion unit 1411, and a plurality of protocol conversion tables 1412A, 1412B, ....
  • This shared protocol conversion server 1401 shall be operated by a third-party organization, and for the registered devices of participating vendors (for example, companies A and B), the common API can be protocol-converted to the vendor's own API. .. Further, it is assumed that the protocol conversion tables 1412A, 1412B, ... Are created in advance by the participating vendor or the operating organization of the shared protocol conversion server 1401 and stored in the shared protocol conversion server 1401. Further, the shared protocol conversion server 1401 can be realized by a computer configuration as shown in FIG.
  • the IoT common API compatible server 103 provides the device control unit 134 with a protocol conversion inquiry unit 1438 instead of the protocol conversion unit 138.
  • the protocol conversion inquiry unit 1438 can communicate with the protocol conversion reception unit 1410 of the shared protocol conversion server 1401 via the cloud 1402.
  • the protocol conversion inquiry unit 1438 transmits the device control information to the shared protocol conversion server 1401 via the cloud 1402 when the device to be controlled is a vendor-specific device, for example, an air conditioner 503. It is possible to transmit a device control request message corresponding to the common API including the device and information that the air conditioner 503 is a device of the company A's original specifications.
  • the shared protocol conversion server 1401 can receive the device control request message and information corresponding to the common API from the protocol conversion inquiry unit 1438 by the protocol conversion reception unit 1410 and transfer the information to the protocol conversion unit 1411. Is.
  • the protocol conversion unit 1411 can refer to the protocol conversion tables 1412A, 1412B, ... Based on the information, and convert the control information included in the device control request message corresponding to the common API into a binary format vendor-specific command. It is possible.
  • the protocol conversion unit 1411 can return this command to the protocol conversion inquiry unit 1438 of the IoT common API compatible server 103 on the cloud 1402 via the protocol conversion reception unit 1410.
  • FIG. 15 is a sequence diagram showing data communication when controlling an air conditioner 503, which is a device of company A's original specifications, in a home device management system configured as shown in FIG.
  • a list of control target devices is displayed on the GUI display unit 111.
  • the user selects the air conditioner 503.
  • the GUI display unit 111 displays items for controlling the temperature, air volume, wind direction, etc., for example, the user inputs the set temperature as 20 degrees (ST61).
  • the common API compatible application 110 creates a common API compatible device control request message including control information selected and input by these users. Then, the common API-compatible application 110 of the user terminal 101 transmits this common API-compatible device control request message to the GUI unit 130 of the IoT common API-compatible server 103 (S61).
  • the GUI unit 130 determines that the message received from the common API-compatible application 110 of the user terminal 101 is a device control request message including control information, and determines that the device control request message corresponding to the common API is the device type of the device control unit 134. It is transmitted to the determination unit 136 (S62).
  • the device type determination unit 136 determines that the device control request message corresponding to the common API is intended for the air conditioner 503, searches for the air conditioner 503 registered in the device management table 133, and sets the value of the common / extended flag. Confirm. As shown in FIG. 7, since the value of the common / extended flag of the air conditioner 3503 is “1”, the device type determination unit 136 further confirms the vendor name registered in the device management table 133. Since the registered vendor name is company A, the device type determination unit 136 determines that the air conditioner 503 is a device of company A's own specifications (ST62).
  • the device type determination unit 136 determines that the air conditioner 503 is an air conditioner of company A's own specifications, and receives a common API-compatible device control request message including control information and information that the air conditioner 503 is a device of company A's own specifications. It is transmitted to the protocol conversion inquiry unit 1438 (S63).
  • the protocol conversion inquiry unit 1438 includes a common API-compatible device control request message including control information and information that the air conditioner 503 is a device of company A's own specifications, for example, a vendor name indicating a vendor registered in the device management table 133. Is transmitted to the shared protocol conversion server 1401 on the cloud 1402 (S64). The shared protocol conversion server 1401 receives the request message and information in the protocol conversion reception unit 1410, and the protocol conversion reception unit 1410 transfers them to the protocol conversion reception unit (S65).
  • the protocol conversion unit 1411 refers to the corresponding protocol conversion table (A) 1412A based on the information that the device is a device of the company A's own specification, and inputs the control information included in the device control request message corresponding to the common API in binary format. Convert to a command of company A's original specifications (ST63).
  • the protocol conversion unit 1411 transmits the command to the protocol conversion reception unit 1410 (S66).
  • the protocol conversion reception unit 1410 transmits the command to the IoT common API compatible server 103 on the cloud 1402 (S67).
  • the IoT common API compatible server 103 receives the command by the protocol conversion inquiry unit 1438.
  • the protocol conversion inquiry unit 1438 directly transmits the received command of the company A's original specifications to the air conditioner 503, which is the control target of the user's house 102 corresponding to the user terminal 101, without going through the controller 120 (S68). ).
  • the protocol conversion inquiry unit 1438 registers the control content included in the control request from the user terminal 101 and the device to be controlled discriminated by the device type determination unit 136 as the discrimination unit in the device management table 133.
  • the information indicating the vendor included in the device information was transmitted to the shared protocol conversion server 1401 which is a conversion server that converts the control contents into the command of the vendor's original specification via the wide area network, and was converted by the conversion server.
  • the shared protocol conversion server 1401 which is a conversion server that converts the control contents into the command of the vendor's original specification via the wide area network, and was converted by the conversion server.
  • the command By receiving the command, it functions as a conversion unit that converts the control content into the command of the vendor's original specification and sends the command of the vendor's original specification to the air conditioner 503 which is the device to be controlled.
  • the air conditioner 503 that received the command from the protocol conversion inquiry unit 1438 sets the temperature setting to 20 degrees according to the command (ST64).
  • the vendor having the device of the original specification can use the device of the vendor's original specification by the IoT common API compatible server 103 without making any special modification to the company's product. It will be recognizable, and it will be possible to access vendor-specific devices from a common API-compatible application. Furthermore, by holding the protocol conversion table in the shared protocol conversion server 1401, the common API specifications can be converted to the vendor's original specifications, and the common API compatible application 110 can be used to refer to the vendor's original specifications. Control is possible.
  • the user can uniformly refer to and control the standard-compliant device and the vendor-specific device by using only the common API-compatible application 110. Therefore, the user only needs to install the common API compatible application 110 on the user terminal 101, and it is not necessary to switch between the common API compatible application 110 and the vendor's original application for each control target model, which improves convenience. ..
  • the shared protocol conversion server 1401 operated by the third-party organization provides the protocol conversion function, the IoT common API compatible server 103 does not need to prepare it. As long as a third party provides the shared protocol conversion server 1401 with an appropriate protocol conversion table at an appropriate time, it is possible to manage various devices in the user's home 102.
  • FIG. 16 is a diagram showing the overall configuration of the home device management system according to the third embodiment of the present invention and the flow of data between each part of the home device management system when the device is registered in the extended mode.
  • the MAC address value is acquired from all the devices.
  • HTIP Home-network Topology Identifying Protocol
  • the controller 120 in the user's house 102 and the air conditioner 504 (shown as the air conditioner 4 (standard) in FIG. 16 and shown as the air conditioner 4 in FIG. 17), which is a device unique to the company B, are HTIP system. It is assumed that it corresponds to. Therefore, the controller 120 has an HTIP manager 1610, and the air conditioner 504 includes an HTIP agent 1620.
  • the HTIP manager 1610 and the HTIP agent 1620 can communicate with each other via the home network.
  • the HTIP agent 1620 can communicate with the HTIP manager 1610 at an arbitrary timing and transmit the HTIP information including the device information of the air conditioner 504 to the HTIP manager 1610. Further, the HTIP manager 1610 can store the device information. It is assumed that the other configurations are the same as those of the first embodiment.
  • FIG. 17 is a sequence diagram showing data communication between each part when device registration is performed in the extended mode.
  • the HTIP agent 1620 communicates with the HTIP manager 1610 in the controller 120 at an arbitrary timing, and the IP address value and MAC address value of the air conditioner 504, the model name, the device name, and the like. And the device information including the manufacturer code is transmitted to the HTIP manager 1610 as HTIP information (S101). As a result, the HTIP manager 1610 stores the HTIP information including the device information of the air conditioner 504 (ST101).
  • the user selects device registration through the GUI display unit 111, and further selects the extended mode (ST71).
  • the common API-compatible application 110 of the user terminal 101 transmits a device registration request (extension) indicating that device registration is performed in the extended mode to the IoT common API-compatible server 103 (S71).
  • the IoT common API compatible server 103 that has received the device registration request (extended) determines in the GUI unit 130 that the device registration is performed in the extended mode based on the received device registration request (extended) (ST72).
  • the GUI unit 130 transmits to the device search unit 131 an instruction for the device search unit 131 to operate in the extended mode (S72).
  • the device search unit 131 Upon receiving the instruction, the device search unit 131 operates in the extended mode and transmits a device inquiry request (extended) to the controller 120 of the user's home 102 corresponding to the user of the user terminal 101 (S73).
  • the controller 120 that has received the device inquiry request (extended) determines in the search mode determination unit 124 that the received device inquiry request (extended) is in the extended mode (ST73).
  • the search mode determination unit 124 transmits an instruction for making a MAC address acquisition request to the extended search function unit 126 (S74).
  • the extended search function unit 126 Upon receiving the instruction, the extended search function unit 126 inquires of the HTIP manager 1610 via the network in the house (S75). Upon receiving this inquiry, the HTIP manager 1610 receives the IP address value and MAC address value stored in the vendor's original device corresponding to the HTIP method, in this example, the air conditioner 504, and the model name, device name, and manufacturer code. The device information including the device information and the HTIP information including the device information including the above are returned to the extended search function unit 126 (S76). As a result, the extended search function unit 126 can acquire the IP address value, the MAC address value, and the device information of the vendor's original device corresponding to the HTIP method in the user's house 102.
  • the controller 120 transmits the IP address value, the MAC address value, and the device information acquired by the extended search function unit 126 to the IoT common API compatible server 103.
  • the IoT common API compatible server 103 sends the received information to the device information input unit 132 (S77).
  • the device information input unit 132 collates the MAC address value included in the received information with the MAC address value registered in the device management table 133. As a result, for example, it turns out that the MAC address value of the air conditioner 504 is not registered. Therefore, the device information input unit 132 estimates the vendor name from the manufacturer code of the device information included in the received information, and the device information input unit 132 has the same IP address value included in the received information as this manufacturer code. From, create an identification number. Then, the device information input unit 132 displays the device management table 133 with the model name, device name, identification number, IP address value, and MAC address value of the air conditioner 504 included in the received information, estimated or created. , Enter the vendor name. Further, the device information input unit 132 sets the value of the common / extended flag of the air conditioner 504 to "1". In this way, the device information input unit 132 registers the air conditioner 504 in the device management table 133 (ST74).
  • the device information input unit 132 contains information including the IP address value, MAC address value, vendor name, model name, and device name of the air conditioner 504 in this example, for each of the vendor-specific devices registered this time in the device management table 133. Is sent to the GUI unit 130 (S78).
  • the GUI unit 130 transmits this information to the common API-compatible application 110 of the user terminal 101 (S79).
  • the common API-compatible application 110 of the user terminal 101 displays the transmitted information in the GUI unit 130 of the user terminal 101, and displays a confirmation screen for prompting the user to confirm whether or not the information is correct.
  • the user confirms whether the information is correct, and if it is correct, performs an approval operation on the confirmation screen, and if there is an error, performs a correction operation to correct the part (ST75).
  • the common API-compatible application 110 of the user terminal 101 transmits confirmation result information indicating the result of the confirmation by the user to the IoT common API-compatible server 103 (S80).
  • the GUI unit 130 of the IoT common API compatible server 103 receives the confirmation result information from the user terminal 101 and transfers it to the device information input unit 132 (S81).
  • the GUI unit 130 and the device information input unit 132 use the user terminal to input the address information and the device information which are the vendor-specific device information registered in the device management table 133 by the device information input unit 132 as the registration unit. It sends to 101 and functions as a confirmation unit for acquiring the approval result or correction result of the device information by the user terminal 101.
  • the device information input unit 132 confirms or corrects the information input to the device management table 133 of the air conditioner 504 based on the confirmation result information sent from the GUI unit 130 (ST76).
  • the device information input unit 132 is a vendor-specific device in the device management table 133 based on the confirmation result information which is the confirmation result obtained by the GUI unit 130 as the confirmation unit and the user terminal 101 acquired by the device information input unit 132. It functions as an update unit that confirms or corrects the registered contents of.
  • the vendor having the proprietary equipment does not make any special modification to the company's product, and the IoT common API.
  • the corresponding server 103 can recognize the device of the vendor's original specification.
  • the user can uniformly refer to and control the standard-compliant device and the vendor-specific device by using only the common API-compatible application 110. Therefore, the user only needs to install the common API compatible application 110 on the user terminal 101, and it is not necessary to switch between the common API compatible application 110 and the vendor's original application for each control target model, which improves convenience. ..
  • the vendor's original device supports the HTIP method, not only can it be registered in the device management table 133, but also device information can be acquired from the device, so that the user can save the trouble of inputting the device information.
  • the present invention is not limited to the above embodiment.
  • the controller 120 supports the IoT common API for each of the MAC address value and the IP address value of the air conditioner 501 and the air conditioner 502, which are not compatible with the HTIP method and are compatible with the standard, and the air conditioner 503, which is a device unique to the vendor. It can be sent to the server 103, and the MAC address value and IP address value of the air conditioner 504, which is a vendor-specific device corresponding to the HTIP method, and the device information can be sent to the IoT common API compatible server 103.
  • the user can input necessary information about the air conditioner 503 and confirm the acquired information of the air conditioner 504 by the common API-compatible application 110 of the user terminal 101.
  • the method described in the above embodiment is, for example, a magnetic disk (floppy (registered trademark) disk, hard disk, etc.) or an optical disk (CD-ROM, DVD) as a program (software means) that can be executed by a computer (computer). , MO, etc.), stored in a recording medium such as a semiconductor memory (ROM, RAM, flash memory, etc.), or transmitted and distributed by a communication medium.
  • the program stored on the medium side also includes a setting program for configuring the software means (including not only the execution program but also the table and the data structure) to be executed by the computer in the computer.
  • a computer that realizes this device reads a program recorded on a recording medium, constructs software means by a setting program in some cases, and executes the above-mentioned processing by controlling the operation by the software means.
  • the recording medium referred to in the present specification is not limited to distribution, and includes storage media such as magnetic disks and semiconductor memories provided in devices connected inside a computer or via a network.
  • the present invention is not limited to the above embodiment as it is, and at the implementation stage, the components can be modified and embodied within a range that does not deviate from the gist thereof.
  • various inventions can be formed by an appropriate combination of the plurality of components disclosed in the above-described embodiment. For example, some components may be removed from all the components shown in the embodiments. Furthermore, components over different embodiments may be combined as appropriate.
  • Input / output interface 406 ... Communication interface 407 ... Bus 408 ... Communication device 409 ... Input unit 410 ... Display unit 501-504 ... Air conditioner (air conditioner) 1401 ... Shared protocol conversion server 1402 ... Cloud 1410 ... Protocol conversion reception unit 1438 ... Protocol conversion inquiry unit

Landscapes

  • Engineering & Computer Science (AREA)
  • Automation & Control Theory (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer And Data Communications (AREA)
  • Small-Scale Networks (AREA)

Abstract

一実施形態に係る宅内機器管理装置は、広域ネットワークを介したユーザ端末からの登録要求に応じて、宅内ネットワークに接続された標準規格対応の機器およびベンダ独自仕様の機器を制御する宅内制御装置に対し、前記広域ネットワークを介してベンダ独自仕様の機器の情報を問合せる問合部と、前記宅内制御装置から送られてくる、少なくともアドレス情報を含む前記ベンダ独自仕様の機器の情報を、ベンダ独自仕様の機器であることを示す識別情報と共に機器管理テーブルに登録する登録部と、前記機器管理テーブルに登録した前記ベンダ独自仕様の機器の前記情報を前記ユーザ端末に送り、前記ユーザ端末による承認、修正または追加された結果を取得する確認部と、前記ユーザ端末による承認、修正または追加された結果により、前記機器管理テーブルにおける前記ベンダ独自仕様の機器の登録内容を更新する更新部と、を備える。

Description

宅内機器管理装置、方法およびプログラム
　この発明の実施形態は、宅内機器管理装置、方法およびプログラムに関する。
　近年、インターネットやセンサ機器の発展により、Ｍ２Ｍ（Machine to Machine）／ＩｏＴ（Internet of Things）と呼ばれるシステム／サービスの検討が進んでいる。特に、ＨＥＭＳ（Home Energy Management System）と呼ばれる住宅内の家電機器を管理するシステムに対しては、標準化も推進されている。また、宅内の家電機器に、クラウドからアクセスするアプリケーションソフトウェア（以下、アプリケーションと略記する。）作成支援のための共通ＷｅｂＡＰＩ（Application Programming Interface）も整備されつつある。
　ＨＥＭＳの代表的な標準規格として、エコーネットコンソーシアムによる、ECHONET Lite規格（非特許文献１を参照）があり、同規格に対応した機器であれば、管理装置は、異なるベンダの機器であっても共通的に管理することができる。
　また、上記ECHONET Lite規格は、これまでのＨＥＭＳ的な利用から、宅内機器をＩｏＴ機器として、外部から参照・制御することを可能とするため、クラウドアプリケーション向けに、共通ＡＰＩとしてのＷｅｂＡＰＩ（非特許文献２を参照）についても作定している。このＡＰＩに準拠したアプリケーションを作成すれば、ECHONET Lite対応機器であれば、同一のアプリケーションで、異なるベンダの機器へもアクセスすることができる。
ECHONET Lite規格書 Ver.1.13 第1部 ECHONET Liteの概要（https://echonet.jp/wp/wp-content/uploads/pdf/General/Standard/ECHONET_lite_V1_13_jp/ECHONET-Lite_Ver.1.13_01.pdf） ECHONET Lite Web APIガイドライン（https://echonet.jp/wp/wp-content/uploads/pdf/General/Download/web_API/ECHONET_Lite_Web_API_guideline_v1.00.pdf）
　ところが、ECHONET Lite規格に対応していない、ベンダ独自仕様の機器については、独自ＡＰＩおよびベンダ独自の、即ち専用の、アプリケーションを用いて参照および制御する必要がある。そのため、上記の共通ＡＰＩを用いたアプリケーションでは、当該ベンダ独自仕様の機器にアクセスすることはできない。
　この発明は、上記事情に着目してなされたもので、その目的とするところは、共通ＡＰＩ対応アプリケーションからベンダ独自仕様の機器へアクセス可能とする技術を提供することにある。
　上記目的を達成するために、この発明の一態様に係る宅内機器管理装置は、ユーザ端末と前記ユーザ端末に対応するユーザ宅の宅内制御装置とに広域ネットワークを介して接続される宅内機器管理装置であって、前記ユーザ宅の宅内ネットワークに接続された標準規格対応の機器それぞれについて、前記宅内ネットワークにおけるアドレス情報と、ベンダ名を含む前記機器を特定する機器情報と、を登録した機器管理テーブルと、前記ユーザ端末からの登録要求に応じて、前記宅内ネットワークに接続された前記標準規格対応の機器およびベンダ独自仕様の機器を制御する前記宅内制御装置に対し、前記ベンダ独自仕様の機器の情報を問合せる問合部と、前記問合部からの前記問合せに応答して前記宅内制御装置から送られてくる、少なくとも前記ベンダ独自仕様の機器のアドレス情報を含む前記ベンダ独自仕様の機器の情報を、ベンダ独自仕様の機器であることを示す識別情報と共に前記機器管理テーブルに登録する登録部と、前記登録部によって前記機器管理テーブルに登録した前記ベンダ独自仕様の機器の前記情報を前記ユーザ端末に送り、前記ユーザ端末による承認、修正または追加された結果を取得する確認部と、前記確認部が取得した前記ユーザ端末による承認、修正または追加された結果により、前記機器管理テーブルにおける前記ベンダ独自仕様の機器の登録内容を更新する更新部と、備える。
　この発明の一態様によれば、共通ＡＰＩ対応アプリケーションからベンダ独自仕様の機器へアクセス可能とする技術を提供することができる。
図１は、本発明の第１の実施形態における宅内機器管理システムの全体構成を示す図である。 図２は、機器管理テーブルの例を示す図である。 図３は、Ａ社用のプロトコル変換テーブルの例を示す図である。 図４は、ＩｏＴ共通ＡＰＩ対応サーバのコンピュータ構成の一例を示す模式図である。 図５は、通常モードで機器登録を行う場合の宅内機器管理システムの各部間のデータの流れを示す図である。 図６は、機器登録を通常モードで行う際の各部間でのデータ通信を示すシーケンス図である。 図７は、機器登録後の機器管理テーブルの例を示す図である。 図８は、拡張モードで機器登録を行う場合の宅内機器管理システムの各部間のデータの流れを示す図である。 図９は、機器登録を拡張モードで行う際の各部間でのデータ通信を示すシーケンス図である。 図１０は、機器登録後の機器管理テーブルの例を示す図である。 図１１は、ユーザ宅内の機器の制御を行う場合の宅内機器管理システムの各部間のデータの流れを示す図である。 図１２は、標準規格対応の機器であるエアーコンディショナ（以下、エアコン略記する。）を制御する際の各部間でのデータ通信を示すシーケンス図である。 図１３は、Ａ社独自仕様の機器であるエアコンを制御する場合のデータ通信を示すシーケンス図である。 図１４は、本発明の第２の実施形態における宅内機器管理システムの全体構成並びにユーザ宅内の機器の制御を行う場合の宅内機器管理システムの各部間のデータの流れを示す図である。 図１５は、Ａ社独自仕様の機器であるエアコンを制御する場合のデータ通信を示すシーケンス図である。 図１６は、本発明の第３の実施形態における宅内機器管理システムの全体構成並びに拡張モードで機器登録を行う場合の宅内機器管理システムの各部間のデータの流れを示す図である。 図１７は、機器登録を拡張モードで行う際の各部間でのデータ通信を示すシーケンス図である。
　以下、図面を参照してこの発明に係わる実施形態を説明する。　
　［第１の実施形態］　
　（構成）　
　図１は、本発明の第１の実施形態における宅内機器管理システム１００の全体構成を示す図である。図１に記載の宅内機器管理システムは、互いにインターネット等の広域ネットワークを介して接続可能な、ユーザ端末１０１と、ユーザ宅１０２と、第１の実施形態に係る宅内危機管理装置としてのＩｏＴ共通ＡＰＩ対応サーバ１０３と、を備えている。ＩｏＴ共通ＡＰＩ対応サーバ１０３は、クラウド上に構成され、ユーザ端末１０１は、このＩｏＴ共通ＡＰＩ対応サーバ１０３を介して、ユーザ宅１０２に配備された機器と通信可能である。なお、図１では、ユーザ端末１０１とユーザ宅１０２の組を一組しか示していないが、複数組を含み得ることは言うまでもない。また、一つのユーザ宅１０２に対し、複数のユーザ端末１０１が組み合わせ可能なことも勿論である。また、ユーザ宅１０２は、ユーザの住居に限定するものではなく、事務所や仕事場等のユーザが利用する施設を含み得る。
　ユーザ端末１０１は、例えば、スマートフォン、ウェアラブル端末、タブレット等の、任意のモバイルデバイスであって良い。ユーザ端末１０１では、共通ＡＰＩ対応アプリケーション（図では、共通ＡＰＩ対応アプリと記載している。）１１０が動作している。
　共通ＡＰＩ対応アプリケーション１１０は、ユーザ端末１０１が供えるＧＵＩ表示部１１１に「機器登録」ボタンおよび「機器制御」ボタンを表示させることができる。ＧＵＩ表示部１１１は、例えば、表示装置と位置入力装置とを組み合わせたタッチパネルを含み、表示した「機器登録」ボタンまたは「機器制御」ボタンの位置をタッチさせることで、ユーザにユーザ宅１０２内の機器を登録したいのか、制御したいのかを選択させることができる。
　ユーザが機器登録を選択した場合、共通ＡＰＩ対応アプリケーション１１０はさらに、ＧＵＩ表示部１１１にモード選択用のボタンを表示して、ユーザに通常モードまたは拡張モードのいずれで機器登録を行うのか選択させることが可能である。
　また、ユーザが機器制御を選択した場合、共通ＡＰＩ対応アプリケーション１１０は、ＧＵＩ表示部１１１に制御対象の機器の一覧を表示させ、制御を行う機器をユーザに選択させることが可能である。共通ＡＰＩ対応アプリケーション１１０はさらに、ＧＵＩ表示部１１１に制御項目を表示させ、ユーザに選択した機器をどのように制御するかの指示を行わせることが可能である。なお、制御項目は、例えば、制御対象の機器がエアコンである場合、温度、風量、風向き等である。共通ＡＰＩ対応アプリケーション１１０は、ユーザ端末１０１が備える無線通信ユニットにより、ユーザが選択した指示をクラウド上のＩｏＴ共通ＡＰＩ対応サーバ１０３に送信する。
　ユーザ宅１０２は、宅内ネットワークを介して互いに接続された、コントローラ１２０と、機器１２１と、機器１２２と、機器１２３と、を含む。コントローラ１２０は、機器１２１～１２３を、宅内ネットワークを介して制御する宅内制御装置である。機器１２１および機器１２２は、標準規格対応の機器であり、図１では、機器１２１は、機器１（標準）として、また、機器１２２は機器２（標準）として示されている。機器１２３は、ベンダ独自仕様の機器、例えばＡ社独自仕様の機器であり、図１では、機器３（Ａ社独自）として示される。ユーザ宅１０２内の機器およびコントローラ１２０は、図１において図示していない、宅内ネットワークと宅外の広域ネットワークとの接続を行うゲートウェイ／ルータ等を介して、クラウド上のＩｏＴ共通ＡＰＩ対応サーバ１０３と通信可能である。
　ＩｏＴ共通ＡＰＩ対応サーバ１０３は、ＧＵＩ部１３０と、機器探索部１３１と、機器情報入力部１３２と、機器管理テーブル１３３と、機器制御部１３４と、を含む。
　ＧＵＩ部１３０は、ユーザ端末１０１からの指示を受信し、その指示が機器登録か機器制御かを判定することができ、さらに、機器登録指示受信時にさらに受信した指示により機器登録が通常モードまたは拡張モードで行われるかを判定することができる。ＧＵＩ部１３０は、指示が機器登録の場合、機器探索部１３１に機器登録要求を送り、機器制御の場合、機器制御部１３４に共通ＡＰＩ対応の要求メッセージを送る。また、ＧＵＩ部１３０は、ユーザ端末１０１からの情報を機器情報入力部１３２に送ることもできる。
　機器探索部１３１は、機器登録が通常モードであるか拡張モードで行われるかに従って、通常モードまたは拡張モードで動作する。この機器探索部１３１は、通常モードで動作する場合は、クラウドを介してユーザ宅１０２のコントローラ１２０へ機器問合せ要求（通常）を送信する。また、拡張モードで動作する場合には、機器探索部１３１は、クラウドを介してユーザ宅１０２のコントローラ１２０へ機器問合せ要求（拡張）を送信する。
　機器情報入力部１３２は、ユーザ宅１０２のコントローラ１２０から、ユーザ宅１０２の各機器についての、機器情報、ＭＡＣアドレス値、ＩＰアドレス値等を受信することが可能である。機器情報入力部１３２は、これら受信した各機器についての情報またはＧＵＩ部１３０により受信したユーザ端末１０１からの情報を、機器管理テーブル１３３に入力する。
　機器管理テーブル１３３は、ＩｏＴ共通ＡＰＩ対応サーバ１０３が管理するユーザ宅１０２のそれぞれに対応して、フラッシュメモリ等の随時書き込みおよび読み出しが可能な不揮発性メモリに格納される。機器管理テーブル１３３は、図２に示すように、ユーザ宅１０２に配された機器のそれぞれについて、機種名、機器名、識別番号、ＩＰアドレス値、さらに共通／拡張フラグ、ＭＡＣアドレス値、およびベンダ名を記憶している。なお、図２では、何も機器を記憶していない場合、つまり、すべての値がブランクである場合を示している。共通／拡張フラグは、登録されている機器が標準規格対応の機器であるかベンダ独自仕様の機器であるかを判断するためのフラグ値であり、１ビットを有する。
　機器制御部１３４は、ユーザ宅１０２の機器１２１～１２３を制御するための制御を行う。機器制御部１３４は、複数のプロトコル変換テーブル１３５Ａ，１３５Ｂ，…と、機器種別判定部１３６と、コマンド変換部１３７と、プロトコル変換部１３８と、を含む。
　プロトコル変換テーブル１３５Ａ，１３５Ｂ，…は、フラッシュメモリ等随時書き込みや読み出しが可能な不揮発性メモリに格納される。プロトコル変換テーブルは、変換対象のベンダ毎に１つずつ作成されることができる。プロトコル変換テーブルは、公開されている情報または対応するベンダと技術契約を結ぶ等して取得した情報を基に、ＩｏＴ共通ＡＰＩ対応サーバ１０３の管理元または運用元があらかじめ作成し、ＩｏＴ共通ＡＰＩ対応サーバ１０３内に設置される。図３は、Ａ社用のプロトコル変換テーブル（プロトコル変換テーブル（Ａ））１３５Ａの例であり、機種名、機種コード（標準）、機種コード（Ａ社）、パラメータ名（共通ＡＰＩ）、パラメータコード（標準）、およびパラメータコード（Ａ社）を記憶している。図３では、Ａ社用のプロトコル変換テーブル１３５Ａのみを示しているが、図１で示すようなＢ社用のプロトコル変換テーブルも存在するし、その他の任意のベンダ用のプロトコル変換テーブルも存在するとする。
　機器種別判定部１３６は、機器管理テーブル１３３を参照することにより、機器制御の対象が標準規格対応の機器であるのか、ベンダ独自仕様の機器であるのかを判定する。
　コマンド変換部１３７は、機器制御の対象が標準規格対応の機器である場合に、共通ＡＰＩ対応の要求メッセージを、標準規格対応のコマンドに変換する。
　プロトコル変換部１３８は、機器制御の対象がベンダ独自仕様の機器である場合に、共通ＡＰＩ対応の要求メッセージを、ベンダ独自仕様のコマンドに変換する。例えば、共通ＡＰＩ対応の要求メッセージがＡ社の機器を制御するためのメッセージであった場合、プロトコル変換部１３８は、Ａ社用のプロトコル変換テーブル（Ａ）１３５Ａを参照して、Ａ社独自仕様の機器に対する共通ＡＰＩ対応の要求メッセージをＡ社独自仕様のコマンドに変換することが可能である。
　なお、特に図示はしていないが、ＩｏＴ共通ＡＰＩ対応サーバ１０３は、ユーザ端末１０１とユーザ宅１０２との対応関係、それらユーザ端末１０１およびユーザ宅１０２のコントローラ１２０と通信するのに必要なアドレス情報、等を含むユーザ情報を、あらかじめユーザデータベース等の形式で保持していることは勿論である。
　図４は、ユーザ端末１０１、ＩｏＴ共通ＡＰＩ対応サーバ１０３、またはコントローラ１２０に対応し得るコンピュータ構成の一例を示す模式図である。
　ユーザ端末１０１、ＩｏＴ共通ＡＰＩ対応サーバ１０３、またはコントローラ１２０は、図４に示すように、コンピュータデバイスにより構成され、ＣＰＵ等のプロセッサ４０１を有する。そして、ＩｏＴ共通ＡＰＩ対応サーバ１０３およびコントローラ１２０では、このプロセッサ４０１に対し、プログラムメモリ４０２と、データメモリ４０３と、ストレージ４０４と、入出力インターフェース（図４では入出力ＩＦと記す）４０５と、通信インターフェース４０６とが、バス４０７を介して接続される。また、ユーザ端末１０１では、プロセッサ４０１に対し、さらに通信装置４０８が接続される。
　プログラムメモリ４０２は、非一時的な有形のコンピュータ可読記憶媒体として、例えば、フラッシュメモリ等の随時書き込みおよび読出しが可能な不揮発性メモリと、ＲＯＭ（Read Only Memory）等の不揮発性メモリとが組み合わせて使用されたものである。このプログラムメモリ４０２には、プロセッサ４０１が各種制御処理を実行するために必要なプログラムが格納されている。
　データメモリ４０３は、有形のコンピュータ可読記憶媒体として、例えば、上記の不揮発性メモリと、ＲＡＭ（Random Access Memory）等の揮発性メモリとが組み合わせて使用されたものである。このデータメモリ４０３は、各種処理が行われる過程で取得および作成された各種データが記憶されるために用いられる。
　ストレージ４０４は、非一時的な有形のコンピュータ可読記憶媒体として、例えば、ＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）等の随時書き込みおよび読出しが可能な不揮発性メモリを用いた大容量の記憶媒体を有している。このストレージ４０４には、プロセッサ４０１が各種制御処理を実行するために必要な各種のプログラムやデータが格納されている。例えば、プロセッサ４０１が第１実施形態に係るユーザ端末１０１、ＩｏＴ共通ＡＰＩ対応サーバ１０３、またはコントローラ１２０としての制御処理を実行するために必要な制御プログラムが格納されている。ストレージ４０４に格納されているプログラムは、必要に応じてプロセッサ４０１によりデータメモリ４０３上に読み出されて、実行される。また、ＩｏＴ共通ＡＰＩ対応サーバ１０３のストレージ４０４は、機器管理テーブル１３３およびプロトコル変換テーブル１３５Ａ，１３５Ｂ，…を格納する。
　ユーザ端末１０１における制御プログラムは、例えば、ユーザ端末１０１のプロセッサ４０１を、共通ＡＰＩ対応アプリケーション１１０として機能させることができる。また、ＩｏＴ共通ＡＰＩ対応サーバ１０３における制御プログラムは、ＩｏＴ共通ＡＰＩ対応サーバ１０３のプロセッサ４０１を、ＧＵＩ部１３０、機器探索部１３１、機器情報入力部１３２、および機器制御部１３４として機能させることができる。またコントローラ１２０における制御プログラムは、コントローラ１２０のプロセッサ４０１に、探索モード判定部１２４、標準探索機能部１２５、および拡張探索機能部１２６として機能させることができる。なお、管理プログラムは、ストレージ４０４ではなくて、プログラムメモリ４０２に格納されていても良い。
　入出力インターフェース４０５には、入力部４０９および表示部４１０が接続されている。入力部４０９よび表示部４１０は、ユーザ端末１０１のＧＵＩ表示部１１１のように、タッチパネルを用いることができる。また、入力部４０９および表示部４１０はそれぞれ、独立するデバイスにより構成されても良い。
　通信インターフェース４０６は、ユーザ端末１０１では、例えばＢｌｕｅｔｏｏｔｈ（登録商標）などの小電力無線データ通信規格を採用したインターフェースである。通信インターフェース４０６は、コントローラ１２０では、宅内ネットワークに接続するための無線または有線の通信モジュールを含むことができる。通信インターフェース４０６は、ＩｏＴ共通ＡＰＩ対応サーバ１０３では、広域ネットワークに接続するための無線または有線の通信モジュールを含むことができる。
　ユーザ端末１０１における通信装置４０８は、広域ネットワークにアクセスするための無線アクセス網に接続するための無線通信装置である。無線アクセス網は、例えば３Ｇ、４Ｇまたは５Ｇ等の規格の下で動作する携帯電話網や、無線ＬＡＮ（Local Area Network）等を含む。
　（動作）　
　（１．機器登録）
　ＩｏＴ共通ＡＰＩ対応サーバ１０３および共通ＡＰＩ対応アプリケーション１１０に機器情報が登録されていないと、ユーザは、共通ＡＰＩ対応アプリケーション１１０による機器の制御を行うことは出来ない。そのためユーザは、最初に機器登録を行う必要がある。
　（１－１．通常モード）　
　図５は、機器登録を通常モードで行う場合の宅内機器管理システムの各部間のデータの流れを示す図である。また、図６は、機器登録を通常モードで行う際の各部間でのデータ通信を示すシーケンス図である。これらの図において、ユーザ宅１０２内に配置された機器１２１～１２３は、エアコン５０１～５０３であるとして説明する。すなわち、標準規格対応の機器１２１（機器１（標準））および機器１２２（機器２（標準））は、標準規格対応のエアコン５０１（図５ではエアコン１（標準）として示され、図６ではエアコン１として示される。）およびエアコン５０２（図５ではエアコン２（標準）として示され、図６ではエアコン２として示される。）であるものとする。また、Ａ社独自仕様の機器１２３（機器３（Ａ社独自））は、Ａ社独自仕様のエアコン５０３（図５ではエアコン３（Ａ社独自）として示され、図６ではエアコン３として示される。）であるものとする。
　先ず、ユーザ端末１０１の共通ＡＰＩ対応アプリケーション１１０において、ユーザは、ＧＵＩ表示部１１１を通じて機器登録を選択し、さらに、通常モードを選択する（ＳＴ１）。
　これに応じて、ユーザ端末１０１の共通ＡＰＩ対応アプリケーション１１０は、機器登録を通常モードで行うことを示す機器登録要求（通常）をＩｏＴ共通ＡＰＩ対応サーバ１０３に送信する（Ｓ１）。
　機器登録要求（通常）を受信したＩｏＴ共通ＡＰＩ対応サーバ１０３は、ＧＵＩ部１３０において、受信した機器登録要求（通常）に基づいて、機器登録が通常モードで行われると判定する（ＳＴ２）。ＧＵＩ部１３０は、機器探索部１３１へ、機器探索部１３１が通常モードで動作するための指示を送信する（Ｓ２）。
　指示を受信した機器探索部１３１は、通常モードで動作し、ユーザ端末１０１のユーザに対応するユーザ宅１０２のコントローラ１２０に、機器問合せ要求（通常）を送信する（Ｓ３）。
　機器問合せ要求（通常）を受信したコントローラ１２０は、探索モード判定部１２４において、受信した機器問合せ要求（通常）が通常モードであると判定する（ＳＴ３）。探索モード判定部１２４は、標準規格対応の機器探索要求コマンドを出す指示を標準探索機能部１２５に送信する（Ｓ４）。
　標準探索機能部１２５は、当該指示を受信すると、宅内のネットワークを介してエアコン５０１～５０３の全てに標準規格対応の機器探索要求コマンドを送信する（Ｓ５）。
　標準規格対応の機器であるエアコン５０１およびエアコン５０２は、当該標準規格対応の機器探索要求を認識することが可能である。そこで、エアコン５０１およびエアコン５０２はそれぞれ、機種名、機器名、識別番号、ＩＰアドレス値等を含む機器情報を標準探索機能部１２５に返信する（Ｓ６）。しかしながら、ベンダ独自仕様の機器であるエアコン５０３は、この標準規格対応の機器探索要求を認識できないため、反応しない。
　機器情報を受信した標準探索機能部１２５は、標準規格対応の機器であることが判別したエアコン５０１およびエアコン５０２に、追加でＭＡＣアドレス取得要求を送信する（Ｓ７）。標準探索機能部１２５は、エアコン５０１およびエアコン５０２それぞれから返信されてくるＭＡＣアドレス値を取得する（Ｓ８）。
　その後、コントローラ１２０は、取得した機器情報およびＭＡＣアドレス値をＩｏＴ共通ＡＰＩ対応サーバ１０３に送信する。ＩｏＴ共通ＡＰＩ対応サーバ１０３は、受信した機器情報およびＭＡＣアドレス値を機器情報入力部１３２に送る（Ｓ９）。
　機器情報入力部１３２は、機器管理テーブル１３３に標準規格対応の機器の機器情報およびＭＡＣアドレス値を入力すると共に、共通／拡張フラグ値を「０」として、それぞれの機器を登録する（ＳＴ４）。
　図７は、図５および図６を参照しながら説明した機器登録を通常モードで行った後の機器管理テーブル１３３の例である。以上で説明したように、機器登録を通常モードで行うことにより、標準規格対応の機器であるエアコン５０１，５０２についての情報を機器管理テーブル１３３に登録することができる。一方、Ａ社独自仕様の機器であるエアコン５０３についての情報は、機器管理テーブル１３３に登録することができない。なお、ベンダ名は、機器情報から取得できないため、登録されず、Ｎ／Ａとなっている。
　なお、図６では示していないが、ＩｏＴ共通ＡＰＩ対応サーバ１０３は、機器についての情報を機器管理テーブル１３３に登録した後、ユーザ端末１０１の共通ＡＰＩ対応アプリケーション１１０に、機器管理テーブル１３３に登録された機器が制御対象になっていることを示す情報を送信する。当該情報を受信したユーザ端末１０１の共通ＡＰＩ対応アプリケーション１１０は、ユーザが機器制御を選択した際、制御対象の機器として表示するものとする。
　（１－２．拡張モード）　
　ここで、標準モードで機器登録を行っただけでは、制御対象に、ユーザ宅１０２の機器の全てが機器管理テーブル１３３に登録されて、ユーザ端末１０１の共通ＡＰＩ対応アプリケーション１１０において制御対象の機器として表示されない場合がある。例えば、上記の例では、エアコン５０３が登録されず、制御対象の機器として表示されない。よって、このような場合には、機器登録を拡張モードで行うことが必要である。
　図８は、機器登録を拡張モードで行う場合の宅内機器管理システムの各部間のデータの流れを示す図である。また、図９は、機器登録を拡張モードで行う際の各部間でのデータ通信を示すシーケンス図である。ここで説明する例では、既に図５および図６を用いて説明した機器登録を通常モードで行った後に動作するものとする。したがって、機器管理テーブル１３３には、図７で示したエアコン５０１およびエアコン５０２に関する情報が登録されているとする。
　機器登録を拡張モードで行う場合、機器探索部１３１は、拡張モードで動作し、機器問合せ要求（拡張）をコントローラ１２０に送信することが可能である。コントローラ１２０は、機器問合せ要求（拡張）の受信に応じて、拡張探索機能部１２６から、マルチキャストでＭＡＣアドレス取得要求を送信することが可能である。
　すなわち、ユーザ端末１０１の共通ＡＰＩ対応アプリケーション１１０において、ユーザがＧＵＩ表示部１１１を通じて機器登録を選択し、さらに、拡張モードを選択する（ＳＴ２１）。
　これに応じて、ユーザ端末１０１の共通ＡＰＩ対応アプリケーション１１０は、機器登録を拡張モードで行うことを示す機器登録要求（拡張）をＩｏＴ共通ＡＰＩ対応サーバ１０３に送信する（Ｓ２１）。
　機器登録要求（拡張）を受信したＩｏＴ共通ＡＰＩ対応サーバ１０３は、ＧＵＩ部１３０において、受信した機器登録要求（拡張）に基づいて、機器登録が拡張モードで行われると判定する（ＳＴ２２）。ＧＵＩ部１３０は、機器探索部１３１に、機器探索部１３１が拡張モードで動作するための指示を送信する（Ｓ２２）。
　指示を受信した機器探索部１３１は、拡張モードで動作し、ユーザ端末１０１のユーザに対応するユーザ宅１０２のコントローラ１２０に、機器問合せ要求（拡張）を送信する（Ｓ２３）。
　このように、機器探索部１３１は、ユーザ端末からの登録要求に応じて、宅内制御装置であるコントローラ１２０に対し、ベンダ独自仕様の機器の情報を問合せる問合部として機能する。
　機器問合せ要求（拡張）を受信したコントローラ１２０は、探索モード判定部１２４において、受信した機器問合せ要求（拡張）が拡張モードであると判定する（ＳＴ２３）。探索モード判定部１２４は、ＭＡＣアドレス取得要求を行うための指示を拡張探索機能部１２６に送信する（Ｓ２４）。
　拡張探索機能部１２６は、当該指示を受信すると、宅内のネットワークを介してエアコン５０１～５０３にＭＡＣアドレス取得要求をマルチキャストで送信する（Ｓ２５）。
　ＭＡＣアドレス取得要求を受信したエアコン５０１～５０３は、それぞれのＭＡＣアドレス値およびＩＰアドレス値を拡張探索機能部１２６に返信する（Ｓ２６）。
　その後、コントローラ１２０は、取得したＭＡＣアドレス値およびＩＰアドレス値をＩｏＴ共通ＡＰＩ対応サーバ１０３に送信する。ＩｏＴ共通ＡＰＩ対応サーバ１０３は、受信したＭＡＣアドレス値およびＩＰアドレス値を機器情報入力部１３２に送る（Ｓ２７）。
　機器情報入力部１３２は、機器管理テーブル１３３に登録されたＭＡＣアドレス値で受信したＭＡＣアドレス値それぞれを照合する。その結果、例えば、エアコン５０１およびエアコン５０２のＭＡＣアドレス値は登録済みであり、エアコン５０３のＭＡＣアドレス値が未登録あると判明する。そこで、機器情報入力部１３２は、未登録の機器がベンダ独自仕様の機器であると判断し、機器管理テーブル１３３にＭＡＣアドレス値およびＩＰアドレス値を入力すると共に、共通／拡張フラグ値を「１」に設定することで、エアコン５０３を登録する（ＳＴ２４）。
　このように、機器情報入力部１３２は、問合部としての機器探索部１３１からの問合せに応答して宅内制御装置としてのコントローラ１２０から送られてくる、少なくともベンダ独自仕様の機器のアドレス情報を含むベンダ独自仕様の機器であるエアコン５０３の情報を、ベンダ独自仕様の機器であることを示す識別情報である共通／拡張フラグ値と共に機器管理テーブル１３３に登録する登録部として機能する。
　続いて、機器情報入力部１３２は、ＧＵＩ部１３０に、機器管理テーブル１３３に今回登録したベンダ独自仕様の機器それぞれ、この例ではエアコン５０３、のＭＡＣアドレス値およびＩＰアドレス値を送る（Ｓ２８）。
　ＧＵＩ部１３０は、このＭＡＣアドレス値およびＩＰアドレス値をユーザ端末１０１の共通ＡＰＩ対応アプリケーション１１０に送信する（Ｓ２９）。
　ユーザ端末１０１の共通ＡＰＩ対応アプリケーション１１０は、ユーザ端末１０１のＧＵＩ部１３０に、送信されてきた機器のＭＡＣアドレス値およびＩＰアドレス値と共に、その機器の機種名、機器名、およびベンダ名を含む機器情報の入力を行わせる機器情報入力画面を表示する。ユーザは、この機器情報入力画面において、機種名、機器名、およびベンダ名を含む機器情報を入力する（ＳＴ２５）。そして、ユーザ端末１０１の共通ＡＰＩ対応アプリケーション１１０は、これらの入力された機器情報をＩｏＴ共通ＡＰＩ対応サーバ１０３に送信する（Ｓ３０）。
　ＩｏＴ共通ＡＰＩ対応サーバ１０３のＧＵＩ部１３０は、当該機器情報を受信し、それを機器情報入力部１３２に送信する（Ｓ３１）。
　以上のように、ＧＵＩ部１３０および機器情報入力部１３２は、登録部としての機器情報入力部１３２によって機器管理テーブル１３３に登録したベンダ独自仕様の機器の情報であるアドレス情報をユーザ端末１０１に送り、ユーザ端末１０１によって追加された結果である機器情報を取得する確認部として機能する。
　そして、機器情報入力部１３２は、未登録の機器の機器管理テーブル１３３に、ＧＵＩ部１３０から送られてきた当該機器情報を入力する。ここで、機器管理テーブル１３３に登録される識別番号は、通常、メーカーコード＋ＩＰアドレス値が利用されるため、機器情報入力部１３２は、機器情報の入力後、この識別番号を自動生成し、それを機器管理テーブル１３３に登録する（ＳＴ２６）。
　このように、機器情報入力部１３２は、確認部としてのＧＵＩ部１３０および機器情報入力部１３２が取得したユーザ端末１０１による追加結果である機器情報により、機器管理テーブル１３３におけるベンダ独自仕様の機器の登録内容を更新する更新部として機能する。
　図１０は、図８および図９を参照しながら説明した機器登録を拡張モードで行った後の機器管理テーブル１３３の例である。以上で説明したように、機器登録を拡張モードで行うことにより、機器登録を通常モードでは登録されなかったベンダＡ社独自仕様の機器であるエアコン５０３についての情報が機器管理テーブル１３３に登録されることになる。そして、機器管理テーブル１３３において、標準規格対応の機器は、共通／拡張フラグの値が「０」として、ベンダ独自仕様の機器は、共通／拡張フラグの値が「１」として登録される。
　以上のようにして、通常モードで機器登録を行っただけでは機器管理テーブル１３３に登録されずにユーザ端末１０１の共通ＡＰＩ対応アプリケーション１１０に制御対象の機器として表示されなかったベンダ独自仕様の機器についても、機器管理テーブル１３３に登録され、ユーザ端末１０１の共通ＡＰＩ対応アプリケーション１１０において制御対象の機器として表示されるようになる。
　（２．機器制御）　
　図１１は、ユーザがユーザ宅１０２内の機器の制御を行う場合の宅内機器管理システムの各部間のデータの流れを示す図である。機器制御は、上で説明した機器登録を通常モードおよび拡張モードで行った後に実行される。そのため、機器管理テーブル１３３には、例えば、図１０で示したように各エアコンについての情報が登録されているとする。さらに、プロトコル変換テーブル（Ａ）１３５Ａおよび（Ｂ）１３５Ｂは、あらかじめＩｏＴ共通ＡＰＩ対応サーバ１０３の運用元が作成し、ＩｏＴ共通ＡＰＩ対応サーバ１０３内に保存されているものとする。
　機器制御部１３４は、ユーザ端末１０１の共通ＡＰＩ対応アプリケーションからの機器の制御情報を含む機器制御要求メッセージに基づいて、機器種別判定部１３６により、機器管理テーブル１３３から制御対象の機器を検索することが可能である。機器制御部１３４は、検索した制御対象の機器の共通／拡張フラグが「０」である場合、制御対象の機器は標準規格対応の機器であると判定する。これに対して、検索した制御対象の機器の共通／拡張フラグの値が「１」である場合、機器制御部１３４は、さらに機器管理テーブル１３３のベンダ名を確認し、例えば、ベンダ名がＡ社である場合、制御対象の機器がＡ社独自仕様の機器であると判定することが可能である。
　そして、機器種別判定部１３６は、制御対象の機器が標準規格対応の機器であると判定した場合、機器制御要求メッセージをコマンド変換部１３７に送信する。コマンド変換部１３７は、機器制御要求メッセージに含まれる制御情報をバイナリ形式の標準規格対応のコマンドに変換し、コントローラ１２０に送ることが可能である。コントローラ１２０は、標準規格対応のコマンドを制御対象の機器に送ることにより、制御対象の機器を制御することが可能である。
　また、機器種別判定部１３６は、制御対象の機器がベンダ独自仕様、例えばＡ社独自仕様の機器であると判定した場合、機器制御要求メッセージおよび制御対象の機器がＡ社の独自仕様の機器であるという情報をプロトコル変換部１３８に送信することが可能である。プロトコル変換部１３８は、対応するプロトコル変換テーブル、例えばプロトコル変換部１３８（Ａ）を参照し、機器制御要求メッセージに含まれる制御情報をバイナリ形式のＡ社独自仕様のコマンドに変換する。そして、プロトコル変換部１３８は、制御対象の機器に直接このコマンドを送信することにより、制御対象の機器を制御することが可能である。
　（２－１．標準規格対応機器（エアコン５０１））　
　図１２は、標準規格対応の機器であるエアコン５０１を制御する際の各部間でのデータ通信を示すシーケンス図である。
　ユーザ端末１０１の共通ＡＰＩ対応アプリケーション１１０を通じて制御機器を選択する際、ＧＵＩ表示部１１１には、制御対象機器の一覧が表示される。例えば、ユーザがエアコン５０１を選択する。さらにＧＵＩ表示部１１１には、温度、風量、風向き等をどのように制御するかの項目が表示されるので、例えば、ユーザが設定温度を２０度と入力する（ＳＴ４１）。
　共通ＡＰＩ対応アプリケーション１１０は、これらのユーザが選択し入力した制御情報を含む共通ＡＰＩ対応の機器制御要求メッセージを作成する。そして、ユーザ端末１０１の共通ＡＰＩ対応アプリケーション１１０は、当該共通ＡＰＩ対応の機器制御要求メッセージをＩｏＴ共通ＡＰＩ対応サーバ１０３のＧＵＩ部１３０に送信する（Ｓ４１）。
　ＧＵＩ部１３０は、ユーザ端末１０１の共通ＡＰＩ対応アプリケーション１１０から受信したメッセージが制御情報を含む機器制御要求メッセージであると判定し、その共通ＡＰＩ対応の機器制御要求メッセージを機器制御部１３４の機器種別判定部１３６に送信する（Ｓ４２）。
　機器種別判定部１３６は、共通ＡＰＩ対応の機器制御要求メッセージがエアコン５０１を対象としたものであると判定し、機器管理テーブル１３３に登録されたエアコン５０１を検索して共通／拡張フラグの値を確認する。図７に示すように、エアコン５０１の共通／拡張フラグの値が「０」であるので、機器種別判定部１３６は、エアコン５０１が標準規格対応の機器であると判定する（ＳＴ４２）。
　機器種別判定部１３６は、エアコン５０１が標準規格対応のエアコンであるとの判定により、制御情報を含む共通ＡＰＩ対応の機器制御要求メッセージをコマンド変換部１３７に送信する（Ｓ４３）。
　コマンド変換部１３７は、受信した共通ＡＰＩ対応の機器制御要求メッセージに含まれる制御情報をバイナリ形式の標準規格対応のコマンドに変換する（ＳＴ４３）。そして、コマンド変換部１３７は、この標準規格対応のコマンドを、ユーザ端末１０１に対応するユーザ宅１０２のコントローラ１２０に送信する（Ｓ４４）。
　コントローラ１２０は、受信した当該コマンドを制御対象の機器であるエアコン５０１に送信する（Ｓ４５）。エアコン５０１は、当該コマンドに従って、温度設定を２０度に設定する（ＳＴ４４）。
　（２－２．Ａ社独自仕様機器（エアコン５０３））　
　図１３は、Ａ社独自仕様の機器であるエアコン５０３を制御する際の各部間でのデータ通信を示すシーケンス図である。
　ユーザ端末１０１の共通ＡＰＩ対応アプリケーション１１０を通じて制御機器を選択する際、ＧＵＩ表示部１１１には、制御対象機器の一覧が表示される。例えば、ユーザがエアコン５０３を選択する。さらにＧＵＩ表示部１１１には、温度、風量、風向き等をどのように制御するかの項目が表示されるので、例えば、ユーザが設定温度を２０度と入力する（ＳＴ５１）。
　共通ＡＰＩ対応アプリケーション１１０は、これらのユーザが選択し入力した制御情報を含む共通ＡＰＩ対応の機器制御要求メッセージを作成する。そして、ユーザ端末１０１の共通ＡＰＩ対応アプリケーション１１０は、当該共通ＡＰＩ対応の機器制御要求メッセージをＩｏＴ共通ＡＰＩ対応サーバ１０３のＧＵＩ部１３０に送信する（Ｓ５１）。
　ＧＵＩ部１３０は、ユーザ端末１０１の共通ＡＰＩ対応アプリケーション１１０から受信したメッセージが制御情報を含む機器制御要求メッセージであると判定し、その共通ＡＰＩ対応の機器制御要求メッセージを機器制御部１３４の機器種別判定部１３６に送信する（Ｓ５２）。
　このように、ＧＵＩ部１３０は、ユーザ端１０１末から、ユーザ宅１０２内の制御対象の機器とその制御内容とを含む制御要求である機器制御メッセージを受信する要求受信部として機能する。
　機器種別判定部１３６は、共通ＡＰＩ対応の機器制御要求メッセージがエアコン５０３を対象としたものであると判定し、機器管理テーブル１３３に登録されたエアコン５０３を検索して共通／拡張フラグの値を確認する。図７に示すように、エアコン５０３の共通／拡張フラグの値が「１」であるので、機器種別判定部１３６はさらに、機器管理テーブル１３３に登録されたベンダ名を確認する。登録されているベンダ名がＡ社であるため、機器種別判定部１３６は、エアコン５０３がＡ社独自仕様の機器であると判定する（ＳＴ５２）。
　このように、機器種別判定部１３６は、要求受信部としてのＧＵＩ部１３０が受信した制御要求に含まれる制御対象の機器が標準規格対応の機器とベンダ独自仕様の機器とのいずれであるかを、機器管理テーブル１３３を参照して判別する判別部として機能する。
　機器種別判定部１３６は、エアコン５０３がＡ社独自仕様のエアコンであるとの判定により、制御情報を含む共通ＡＰＩ対応の機器制御要求メッセージおよびエアコン５０３がＡ社独自仕様の機器であるという情報をプロトコル変換部１３８に送信する（Ｓ５３）。
　プロトコル変換部１３８は、受信したＡ社独自仕様の機器であるという情報に基づいて、対応するプロトコル変換テーブル（Ａ）１３５Ａを参照し、共通ＡＰＩ対応の機器制御要求メッセージに含まれる制御情報をバイナリ形式のＡ社独自仕様のコマンドに変換する（ＳＴ５３）。
　さらにプロトコル変換部１３８は、当該Ａ社独自仕様のコマンドを、ユーザ端末１０１に対応するユーザ宅１０２の制御対象であるエアコン５０３に、コントローラ１２０を介すことなく直接、送信する（Ｓ５４）。
　このように、プロトコル変換部１３８は、プロトコル変換テーブルを参照して制御要求に含まれる制御内容をベンダ独自仕様のコマンドに変換し、当該コマンドを制御対象の機器であるエアコン５０３に送信する変換部として機能する。
　プロトコル変換部１３８からのコマンドを受信したエアコン５０３は、当該コマンドに従って、温度設定を２０度に設定する（ＳＴ５４）。
　（作用効果）　
　以上のように第１の実施形態によれば、独自仕様機器を持つベンダが、自社製品に対して、特段の改造を加えることなく、ＩｏＴ共通ＡＰＩ対応サーバ１０３が、ベンダ独自仕様機器を認識可能となり、共通ＡＰＩ対応アプリケーション１１０から、ベンダ独自仕様の機器へのアクセスが可能となる。さらに、プロトコル変換テーブルをＩｏＴ共通ＡＰＩ対応サーバ１０３に保持しておくことで、共通ＡＰＩ仕様をベンダ独自仕様に変換することができ、共通ＡＰＩ対応アプリケーション１１０を用いて、ベンダ独自仕様機器の参照・制御が可能となる。
　その結果、ユーザは、共通ＡＰＩ対応アプリケーション１１０のみを用いて、標準規格対応の機器とベンダ独自仕様の機器を、一律に参照・制御可能となる。そのため、ユーザは、ユーザ端末１０１に共通ＡＰＩ対応アプリケーション１１０のみをインストールすれば良く、制御対象機種毎に、共通ＡＰＩ対応アプリケーション１１０とベンダ独自アプリケーションと切り替えて使用する必要が無くなり、利便性が向上する。
　［第２の実施形態］　
　（構成）　
　図１４は、本発明の第２の実施形態における宅内機器管理システムの全体構成並びにユーザ宅内の機器の制御を行う場合の宅内機器管理システムの各部間のデータの流れを示す図である。本実施形態における宅内機器管理システムは、以下の点が、第１実施形態と異なっている。すなわち、本実施形態では、プロトコル変換機能がＩｏＴ共通ＡＰＩ対応サーバ１０３になく、クラウド１４０２上の共用プロトコル変換サーバ１４０１に存在する。
　共用プロトコル変換サーバ１４０１は、プロトコル変換受付部１４１０と、プロトコル変換部１４１１と、複数のプロトコル変換テーブル１４１２Ａ，１４１２Ｂ，…と、を備える。この共用プロトコル変換サーバ１４０１は、第三者機関が運用するものとし、参画しているベンダ（例えば、Ａ社およびＢ社）の登録機器について、共通ＡＰＩをベンダ独自ＡＰＩにプロトコル変換することができる。また、プロトコル変換テーブル１４１２Ａ，１４１２Ｂ，…は、あらかじめ、参画しているベンダまたは共用プロトコル変換サーバ１４０１の運用機関が作成し、共用プロトコル変換サーバ１４０１内に保存されているものとする。また、共用プロトコル変換サーバ１４０１は、図４で示したようなコンピュータ構成により実現されることができる。
　また、この第２の実施形態においては、ＩｏＴ共通ＡＰＩ対応サーバ１０３は、機器制御部１３４に、プロトコル変換部１３８に代えて、プロトコル変換問合部１４３８を供えている。プロトコル変換問合部１４３８は、クラウド１４０２を介して共用プロトコル変換サーバ１４０１のプロトコル変換受付部１４１０と通信可能となっている。プロトコル変換問合部１４３８は、機器種別判定部１３６において、制御対象の機器がベンダ独自仕様の機器、例えばエアコン５０３である場合、クラウド１４０２を介して共用プロトコル変換サーバ１４０１に、機器の制御情報を含む共通ＡＰＩ対応の機器制御要求メッセージおよびエアコン５０３がＡ社独自仕様の機器であるという情報を送信することが可能である。
　共用プロトコル変換サーバ１４０１は、プロトコル変換受付部１４１０により、プロトコル変換問合部１４３８からの共通ＡＰＩ対応の機器制御要求メッセージおよび情報を受信し、それらの情報をプロトコル変換部１４１１に転送することが可能である。
　プロトコル変換部１４１１は、当該情報を元にプロトコル変換テーブル１４１２Ａ，１４１２Ｂ，…を参照し、共通ＡＰＩ対応の機器制御要求メッセージに含まれる制御情報をバイナリ形式のベンダ独自仕様のコマンドに変換することが可能である。プロトコル変換部１４１１は、このコマンドを、プロトコル変換受付部１４１０を介して、クラウド１４０２上のＩｏＴ共通ＡＰＩ対応サーバ１０３のプロトコル変換問合部１４３８に返信することが可能である。
　（動作）　
　第２の実施形態において、機器登録の動作および標準規格対応の機器の制御は、第１の実施形態と同じ動作なため、説明を省略する。そのため、ベンダ独自仕様の機器である例えばエアコン５０３を制御する場合の動作についてのみ説明する。ここで、機器制御は、第１の実施形態で説明した機器登録を通常モードおよび拡張モードで行った後に実行されるものとする。そのため、機器管理テーブル１３３には、図１０で示したように各エアコン５０１～５０３についての情報が登録されているとする。
　図１５は、図１４のように構成された宅内機器管理システムにおいて、Ａ社独自仕様の機器であるエアコン５０３を制御する場合のデータ通信を示すシーケンス図である。
　ユーザ端末１０１の共通ＡＰＩ対応アプリケーション１１０を通じて制御機器を選択する際、ＧＵＩ表示部１１１には、制御対象機器の一覧が表示される。例えば、ユーザがエアコン５０３を選択する。さらにＧＵＩ表示部１１１には、温度、風量、風向き等をどのように制御するかの項目が表示されるので、例えば、ユーザが設定温度を２０度と入力する（ＳＴ６１）。
　共通ＡＰＩ対応アプリケーション１１０は、これらのユーザが選択し入力した制御情報を含む共通ＡＰＩ対応の機器制御要求メッセージを作成する。そして、ユーザ端末１０１の共通ＡＰＩ対応アプリケーション１１０は、この共通ＡＰＩ対応の機器制御要求メッセージをＩｏＴ共通ＡＰＩ対応サーバ１０３のＧＵＩ部１３０に送信する（Ｓ６１）。
　ＧＵＩ部１３０は、ユーザ端末１０１の共通ＡＰＩ対応アプリケーション１１０から受信したメッセージが制御情報を含む機器制御要求メッセージであると判定し、その共通ＡＰＩ対応の機器制御要求メッセージを機器制御部１３４の機器種別判定部１３６に送信する（Ｓ６２）。
　機器種別判定部１３６は、共通ＡＰＩ対応の機器制御要求メッセージがエアコン５０３を対象としたものであると判定し、機器管理テーブル１３３に登録されたエアコン５０３を検索して共通／拡張フラグの値を確認する。図７に示すように、エアコン３５０３の共通／拡張フラグの値が「１」であるので、機器種別判定部１３６はさらに、機器管理テーブル１３３に登録されたベンダ名を確認する。登録されているベンダ名がＡ社であるため、機器種別判定部１３６は、エアコン５０３がＡ社独自仕様の機器であると判定する（ＳＴ６２）。
　機器種別判定部１３６は、エアコン５０３がＡ社独自仕様のエアコンであるとの判定により、制御情報を含む共通ＡＰＩ対応の機器制御要求メッセージおよびエアコン５０３がＡ社独自仕様の機器であるという情報をプロトコル変換問合部１４３８に送信する（Ｓ６３）。
　プロトコル変換問合部１４３８は、制御情報を含む共通ＡＰＩ対応の機器制御要求メッセージおよびエアコン５０３がＡ社独自仕様の機器であるという情報、例えば機器管理テーブル１３３に登録されたベンダを示すベンダ名等を、クラウド１４０２上の共用プロトコル変換サーバ１４０１に送信する（Ｓ６４）。共用プロトコル変換サーバ１４０１では、当該要求メッセージおよび情報をプロトコル変換受付部１４１０にて受信し、プロトコル変換受付部１４１０は、それらをプロトコル変換受付部に転送する（Ｓ６５）。
　プロトコル変換部１４１１は、Ａ社独自仕様の機器であるという情報に基づいて、対応するプロトコル変換テーブル（Ａ）１４１２Ａを参照し、共通ＡＰＩ対応の機器制御要求メッセージに含まれる制御情報をバイナリ形式のＡ社独自仕様のコマンドに変換する（ＳＴ６３）。
　プロトコル変換部１４１１は、当該コマンドをプロトコル変換受付部１４１０に送信する（Ｓ６６）。プロトコル変換受付部１４１０は、当該コマンドをクラウド１４０２上のＩｏＴ共通ＡＰＩ対応サーバ１０３に送信する（Ｓ６７）。
　ＩｏＴ共通ＡＰＩ対応サーバ１０３では、当該コマンドをプロトコル変換問合部１４３８により受信する。プロトコル変換問合部１４３８は、この受信したＡ社独自仕様のコマンドを、ユーザ端末１０１に対応するユーザ宅１０２の制御対象であるエアコン５０３に、コントローラ１２０を介すことなく直接、送信する（Ｓ６８）。
　以上のように、プロトコル変換問合部１４３８は、ユーザ端末１０１からの制御要求に含まれる制御内容と、判別部としての機器種別判定部１３６が判別した制御対象の機器について機器管理テーブル１３３に登録された機器情報に含まれるベンダを示す情報とを、制御内容をベンダ独自仕様のコマンドに変換する変換サーバである共用プロトコル変換サーバ１４０１に広域ネットワークを介して送信し、当該変換サーバによって変換されたコマンドを受信することによって、制御内容をベンダ独自仕様のコマンドに変換し、制御対象の機器であるエアコン５０３にベンダ独自仕様のコマンドを送信する変換部として機能する。
　プロトコル変換問合部１４３８からのコマンドを受信したエアコン５０３は、当該コマンドに従って、温度設定を２０度に設定する（ＳＴ６４）。
　（作用効果）　
　以上のように第２の実施形態によれば、独自仕様の機器を持つベンダが、自社製品に対して、特段の改造を加えることなく、ＩｏＴ共通ＡＰＩ対応サーバ１０３が、ベンダ独自仕様の機器を認識可能となり、共通ＡＰＩ対応アプリから、ベンダ独自仕様の機器へのアクセスが可能となる。さらに、プロトコル変換テーブルを共用プロトコル変換サーバ１４０１に保持しておくことで、共通ＡＰＩ仕様をベンダ独自仕様に変換することができ、共通ＡＰＩ対応アプリケーション１１０を用いて、ベンダ独自仕様の機器の参照・制御が可能となる。
　その結果、ユーザは、共通ＡＰＩ対応アプリケーション１１０のみを用いて、標準規格対応の機器とベンダ独自仕様の機器を、一律に参照・制御可能となる。そのため、ユーザは、ユーザ端末１０１に共通ＡＰＩ対応アプリケーション１１０のみをインストールすれば良く、制御対象機種毎に、共通ＡＰＩ対応アプリケーション１１０とベンダ独自アプリケーションと切り替えて使用する必要が無くなり、利便性が向上する。
　また、第三者機関が運用する共用プロトコル変換サーバ１４０１がプロトコル変換機能を提供するため、ＩｏＴ共通ＡＰＩ対応サーバ１０３は、それを準備する必要が無い。第三者機関が共用プロトコル変換サーバ１４０１に適切な時点に適切なプロトコル変換テーブルを提供さえすれば、ユーザ宅１０２内の様々な機器を管理することが可能となる。
　［第３の実施形態］　
　（構成）　
　図１６は、本発明の第３の実施形態における宅内機器管理システムの全体構成並びに拡張モードで機器登録を行う場合の宅内機器管理システムの各部間のデータの流れを示す図である。第１の実施形態では、機器登録を拡張モードで行う場合、ＭＡＣアドレス値をすべての機器から取得していた。ネットワーク内の機器名を推定する方式の１つとしてＨＴＩＰ（Home-network Topology Identifying Protocol）方式がある（例えば、JJ-300.00「ホームNW接続構成特定プロトコル」https://www.ttc.or.jp/application/files/5815/5321/8935/JJ-300.00v3.pdf参照）。この第３の実施形態では、このＨＴＩＰ方式を使用して機器登録を拡張方式で行う方法を説明する。
　この第３の実施形態では、ユーザ宅１０２内のコントローラ１２０およびＢ社独自機器であるエアコン５０４（図１６ではエアコン４（標準）として示され、図１７ではエアコン４として示される。）がＨＴＩＰ方式に対応しているとする。そのため、コントローラ１２０は、ＨＴＩＰマネージャ１６１０を有し、エアコン５０４は、ＨＴＩＰエージェント１６２０を備える。ＨＴＩＰマネージャ１６１０とＨＴＩＰエージェント１６２０は、宅内ネットワークを介して通信可能となっている。ＨＴＩＰエージェント１６２０は、ＨＴＩＰマネージャ１６１０と任意のタイミングで通信し、エアコン５０４の機器情報を含むＨＴＩＰ情報をＨＴＩＰマネージャ１６１０に送信することが可能である。また、ＨＴＩＰマネージャ１６１０は、当該機器情報を記憶しておくことが可能である。なお、その他の構成は、第１実施形態のそれと同じであるとする。
　（動作）　
　第３の実施形態において、機器登録の通常モードでの動作および機器制御の動作は、第１の実施形態と同じ動作なため、説明を省略する。
　図１７は、機器登録を拡張モードで行う際の各部間でのデータ通信を示すシーケンス図である。
　ユーザ宅１０２に配置されたエアコン５０４において、ＨＴＩＰエージェント１６２０は、任意のタイミングで、コントローラ１２０内のＨＴＩＰマネージャ１６１０と通信し、エアコン５０４のＩＰアドレス値およびＭＡＣアドレス値と、機種名、機器名、およびメーカーコードを含む機器情報とを、ＨＴＩＰ情報としてＨＴＩＰマネージャ１６１０に送信する（Ｓ１０１）。その結果、ＨＴＩＰマネージャ１６１０は、エアコン５０４の機器情報を含むＨＴＩＰ情報を記憶する（ＳＴ１０１）。
　そして、ユーザ端末１０１の共通ＡＰＩ対応アプリケーション１１０において、ユーザがＧＵＩ表示部１１１を通じて機器登録を選択し、さらに、拡張モードを選択する（ＳＴ７１）。
　これに応じて、ユーザ端末１０１の共通ＡＰＩ対応アプリケーション１１０は、機器登録を拡張モードで行うことを示す機器登録要求（拡張）をＩｏＴ共通ＡＰＩ対応サーバ１０３に送信する（Ｓ７１）。
　機器登録要求（拡張）を受信したＩｏＴ共通ＡＰＩ対応サーバ１０３は、ＧＵＩ部１３０において、受信した機器登録要求（拡張）に基づいて、機器登録が拡張モードで行われると判定する（ＳＴ７２）。ＧＵＩ部１３０は、機器探索部１３１に、機器探索部１３１が拡張モードで動作するための指示を送信する（Ｓ７２）。
　指示を受信した機器探索部１３１は、拡張モードで動作し、ユーザ端末１０１のユーザに対応するユーザ宅１０２のコントローラ１２０に、機器問合せ要求（拡張）を送信する（Ｓ７３）。
　機器問合せ要求（拡張）を受信したコントローラ１２０は、探索モード判定部１２４において、受信した機器問合せ要求（拡張）が拡張モードであると判定する（ＳＴ７３）。探索モード判定部１２４は、ＭＡＣアドレス取得要求を行うための指示を拡張探索機能部１２６に送信する（Ｓ７４）。
　拡張探索機能部１２６は、当該指示を受信すると、宅内のネットワークを介してＨＴＩＰマネージャ１６１０に問合せる（Ｓ７５）。ＨＴＩＰマネージャ１６１０は、この問合せを受けると、ＨＴＩＰ方式に対応しているベンダ独自機器、この例ではエアコン５０４について記憶しているＩＰアドレス値およびＭＡＣアドレス値と、機種名、機器名、およびメーカーコードを含む機器情報と、を含むＨＴＩＰ情報を拡張探索機能部１２６に返す（Ｓ７６）。これにより、拡張探索機能部１２６は、ユーザ宅１０２内のＨＴＩＰ方式に対応しているベンダ独自機器についてのＩＰアドレス値、ＭＡＣアドレス値、および機器情報を取得することができる。
　コントローラ１２０は、この拡張探索機能部１２６が取得したＩＰアドレス値、ＭＡＣアドレス値、および機器情報を、ＩｏＴ共通ＡＰＩ対応サーバ１０３に送信する。ＩｏＴ共通ＡＰＩ対応サーバ１０３は、受信した情報を機器情報入力部１３２に送る（Ｓ７７）。
　機器情報入力部１３２は、機器管理テーブル１３３に登録されたＭＡＣアドレス値で受信した情報に含まれるＭＡＣアドレス値を照合する。その結果、例えば、エアコン５０４のＭＡＣアドレス値が未登録あると判明する。そこで、機器情報入力部１３２は、受信した情報に含まれる機器情報のメーカーコードよりベンダ名を推定し、また、機器情報入力部１３２は、このメーカーコードと同じく受信した情報に含まれるＩＰアドレス値とから、識別番号を作成する。そして、機器情報入力部１３２は、機器管理テーブル１３３に、これらの受信した情報に含まれる、推定した、または作成した、エアコン５０４の機種名、機器名、識別番号、ＩＰアドレス値、ＭＡＣアドレス値、ベンダ名を入力する。さらに機器情報入力部１３２は、エアコン５０４の共通／拡張フラグの値を「１」に設定する。こうして、機器情報入力部１３２は、エアコン５０４を機器管理テーブル１３３に登録する（ＳＴ７４）。
　その後、機器情報入力部１３２は、機器管理テーブル１３３において今回登録したベンダ独自仕様の機器それぞれ、この例ではエアコン５０４のＩＰアドレス値、ＭＡＣアドレス値、ベンダ名、機種名、および機器名を含む情報をＧＵＩ部１３０に送る（Ｓ７８）。
　ＧＵＩ部１３０は、これらの情報をユーザ端末１０１の共通ＡＰＩ対応アプリケーション１１０に送信する（Ｓ７９）。
　ユーザ端末１０１の共通ＡＰＩ対応アプリケーション１１０は、ユーザ端末１０１のＧＵＩ部１３０に、送信されてきた当該情報を表示し、正しいかどうかの確認をユーザに促すための確認画面を表示する。ユーザは、これらの情報が正しいか確認し、正しければ確認画面において承認操作を行い、また、誤りがあればその部分を修正する修正操作を行う（ＳＴ７５）。ユーザ端末１０１の共通ＡＰＩ対応アプリケーション１１０は、このユーザによる確認による結果を示す確認結果情報をＩｏＴ共通ＡＰＩ対応サーバ１０３に送信する（Ｓ８０）。
　ＩｏＴ共通ＡＰＩ対応サーバ１０３のＧＵＩ部１３０は、ユーザ端末１０１からの確認結果情報を受信し、それを機器情報入力部１３２に転送する（Ｓ８１）。
　以上のように、ＧＵＩ部１３０および機器情報入力部１３２は、登録部としての機器情報入力部１３２によって機器管理テーブル１３３に登録したベンダ独自仕様の機器の情報であるアドレス情報および機器情報をユーザ端末１０１に送り、ユーザ端末１０１による機器情報の承認結果または修正結果を取得する確認部として機能する。
　機器情報入力部１３２は、ＧＵＩ部１３０から送られてきた確認結果情報に基づいて、エアコン５０４の機器管理テーブル１３３に入力された情報を確定または修正する（ＳＴ７６）。
　このように、機器情報入力部１３２は、確認部としてのＧＵＩ部１３０および機器情報入力部１３２が取得したユーザ端末１０１による確認結果である確認結果情報により、機器管理テーブル１３３におけるベンダ独自仕様の機器の登録内容を確定または修正する更新部として機能する。
　（作用効果）　
　以上のように第３の実施形態によれば、第１および第２の実施形態と同様に、独自仕様機器を持つベンダが、自社製品に対して、特段の改造を加えることなく、ＩｏＴ共通ＡＰＩ対応サーバ１０３が、ベンダ独自仕様の機器を認識可能となる。
　その結果、ユーザは、共通ＡＰＩ対応アプリケーション１１０のみを用いて、標準規格対応の機器とベンダ独自仕様の機器を、一律に参照・制御可能となる。そのため、ユーザは、ユーザ端末１０１に共通ＡＰＩ対応アプリケーション１１０のみをインストールすれば良く、制御対象機種毎に、共通ＡＰＩ対応アプリケーション１１０とベンダ独自アプリケーションと切り替えて使用する必要が無くなり、利便性が向上する。
　また、ベンダ独自機器がＨＴＩＰ方式に対応している場合でも機器管理テーブル１３３に登録できるだけでなく、機器から機器情報を取得できるので、ユーザによる機器情報の入力の手間を省くことができる。
　［その他の実施形態］　
　なお、この発明は上記実施形態に限定されるものではない。　
　例えば、第１の実施形態と第３の実施形態を組み合わせることが可能である。コントローラ１２０は、ＨＴＩＰ方式に対応していない、標準規格対応の機器であるエアコン５０１およびエアコン５０２と、ベンダ独自仕様の機器であるエアコン５０３とのＭＡＣアドレス値およびＩＰアドレス値それぞれをＩｏＴ共通ＡＰＩ対応サーバ１０３に送り、ＨＴＩＰ方式に対応するベンダ独自仕様の機器であるエアコン５０４のＭＡＣアドレス値およびＩＰアドレス値と機器情報とをＩｏＴ共通ＡＰＩ対応サーバ１０３に送ることができる。この場合、ユーザは、ユーザ端末１０１の共通ＡＰＩ対応アプリケーション１１０により、エアコン５０３について必要な情報を入力するとともに、エアコン５０４の取得情報の確認を行うことができる。
　また、前記実施形態に記載した手法は、計算機（コンピュータ）に実行させることができるプログラム（ソフトウェア手段）として、例えば磁気ディスク（フロッピー（登録商標）ディスク、ハードディスク等）、光ディスク（ＣＤ－ＲＯＭ、ＤＶＤ、ＭＯ等）、半導体メモリ（ＲＯＭ、ＲＡＭ、フラッシュメモリ等）等の記録媒体に格納し、また通信媒体により伝送して頒布することもできる。なお、媒体側に格納されるプログラムには、計算機に実行させるソフトウェア手段（実行プログラムのみならずテーブル、データ構造も含む）を計算機内に構成させる設定プログラムをも含む。本装置を実現する計算機は、記録媒体に記録されたプログラムを読み込み、また場合により設定プログラムによりソフトウェア手段を構築し、このソフトウェア手段によって動作が制御されることにより上述した処理を実行する。なお、本明細書で言う記録媒体は、頒布用に限らず、計算機内部或いはネットワークを介して接続される機器に設けられた磁気ディスク、半導体メモリ等の記憶媒体を含むものである。
　要するにこの発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除しても良い。さらに、異なる実施形態に亘る構成要素を適宜組み合わせても良い。
　１００…宅内機器管理システム
　１０１…ユーザ端末
　１０２…ユーザ宅
　１０３…ＩｏＴ共通ＡＰＩ対応サーバ
　１１０…共通ＡＰＩ対応アプリケーション
　１１１…ＧＵＩ表示部
　１２０…コントローラ
　１２１～１２３…機器
　１２４…探索モード判定部
　１２５…標準探索機能部
　１２６…拡張探索機能部
　１３０…ＧＵＩ部
　１３１…機器探索部
　１３２…機器情報入力部
　１３３…機器管理テーブル
　１３４…機器制御部
　１３５Ａ，１３５Ｂ，１４１２Ａ，１４１２Ｂ…プロトコル変換テーブル
　１３６…機器種別判定部
　１３７…コマンド変換部
　１３８，１４１１…プロトコル変換部
　４０１…プロセッサ
　４０２…プログラムメモリ
　４０３…データメモリ
　４０４…ストレージ
　４０５…入出力インターフェース
　４０６…通信インターフェース
　４０７…バス
　４０８…通信装置
　４０９…入力部
　４１０…表示部
　５０１～５０４…エアーコンディショナ（エアコン）
　１４０１…共用プロトコル変換サーバ
　１４０２…クラウド
　１４１０…プロトコル変換受付部
　１４３８…プロトコル変換問合部

Claims (8)

  1. 　ユーザ端末と前記ユーザ端末に対応するユーザ宅の宅内制御装置とに広域ネットワークを介して接続される宅内機器管理装置であって、
    　前記ユーザ宅の宅内ネットワークに接続された標準規格対応の機器それぞれについて、前記宅内ネットワークにおけるアドレス情報と、ベンダ名を含む前記機器を特定する機器情報と、を登録した機器管理テーブルと、
    　前記ユーザ端末からの登録要求に応じて、前記宅内ネットワークに接続された前記標準規格対応の機器およびベンダ独自仕様の機器を制御する前記宅内制御装置に対し、前記ベンダ独自仕様の機器の情報を問合せる問合部と、
    　前記問合部からの前記問合せに応答して前記宅内制御装置から送られてくる、少なくとも前記ベンダ独自仕様の機器のアドレス情報を含む前記ベンダ独自仕様の機器の情報を、ベンダ独自仕様の機器であることを示す識別情報と共に前記機器管理テーブルに登録する登録部と、
    　前記登録部によって前記機器管理テーブルに登録した前記ベンダ独自仕様の機器の前記情報を前記ユーザ端末に送り、前記ユーザ端末による承認、修正または追加された結果を取得する確認部と、
    　前記確認部が取得した前記ユーザ端末による承認、修正または追加された結果により、前記機器管理テーブルにおける前記ベンダ独自仕様の機器の登録内容を更新する更新部と、
    　を備える、宅内機器管理装置。
  2. 　前記アドレス情報は、前記機器のＭＡＣアドレス値を含み、
    　前記機器情報は、前記機器の機種名、機器名、およびベンダ名を含む、請求項１に記載の宅内機器管理装置。
  3. 　前記問合部からの前記問合せに応答して前記宅内制御装置から送られてくる前記ベンダ独自仕様の機器の情報は、前記ベンダ独自仕様の機器のアドレス情報のみを含み、
    　前記登録部は、前記機器管理テーブルに、ベンダ独自仕様の機器であることを示す識別情報と共に前記ベンダ独自仕様の機器の前記アドレス情報を登録し、
    　前記確認部は、前記ベンダ独自仕様の機器の前記アドレス情報を前記ユーザ端末に送り、前記ユーザ端末による前記ベンダ独自仕様の機器の前記機器情報の追加結果を取得し、
    　前記更新部は、前記確認部が取得した前記ユーザ端末による前記追加結果より、前記機器管理テーブルにおける前記ベンダ独自仕様の機器について前記機器情報を追加登録する、請求項１に記載の宅内機器管理装置。
  4. 　前記ユーザ端末から、前記ユーザ宅内の制御対象の機器とその制御内容とを含む制御要求を受信する要求受信部と、
    　前記ユーザ端末からの前記制御要求に含まれる前記制御内容と前記ベンダ独自仕様の機器を制御するためのベンダ独自仕様のコマンドとの関係を登録した変換テーブルと、
    　前記要求受信部が受信した前記制御要求に含まれる前記制御対象の機器が前記標準規格対応の機器と前記ベンダ独自仕様の機器とのいずれであるかを、前記機器管理テーブルを参照して判別する判別部と、
    　前記判別部が、前記制御対象の機器が前記ベンダ独自仕様の機器であると判断した場合、前記変換テーブルを参照して前記制御要求に含まれる前記制御内容を前記ベンダ独自仕様のコマンドに変換し、前記制御対象の機器に前記ベンダ独自仕様のコマンドを送信する変換部と、
    　をさらに備える、請求項１に記載の宅内機器管理装置。
  5. 　前記ユーザ端末から、前記ユーザ宅内の制御対象の機器とその制御内容とを含む制御要求を受信する要求受信部と、
    　前記要求受信部が受信した前記制御要求に含まれる前記制御対象の機器が前記標準規格対応の機器と前記ベンダ独自仕様の機器とのいずれであるかを、前記機器管理テーブルを参照して判別する判別部と、
    　前記判別部が、前記制御対象の機器が前記ベンダ独自仕様の機器であると判断した場合、前記ユーザ端末からの前記制御要求に含まれる前記制御内容と、前記判別部が判別した前記制御対象の機器について前記機器管理テーブルに登録された前記機器情報に含まれるベンダを示す情報とを、制御内容をベンダ独自仕様のコマンドに変換する変換サーバに前記広域ネットワークを介して送信し、前記変換サーバによって変換されたコマンドを受信することによって、前記制御内容を前記ベンダ独自仕様のコマンドに変換し、前記制御対象の機器に前記ベンダ独自仕様のコマンドを送信する変換部と、
    　をさらに備える、請求項１に記載の宅内機器管理装置。
  6. 　前記問合部からの前記問合せに応答して前記宅内制御装置から送られてくる前記ベンダ独自仕様の機器の情報は、前記ベンダ独自仕様の機器のアドレス情報と機器情報とを含み、
    　前記登録部は、前記機器管理テーブルに、ベンダ独自仕様の機器であることを示す識別情報と共に前記ベンダ独自仕様の機器の前記アドレス情報および前記機器情報を登録し、
    　前記確認部は、前記ベンダ独自仕様の機器の前記アドレス情報および前記機器情報を前記ユーザ端末に送り、前記ユーザ端末による前記機器情報の承認結果または修正結果を取得し、
    　前記更新部は、
    　　前記確認部が前記ユーザ端末による前記承認結果を取得した場合、前記機器管理テーブルにおける前記ベンダ独自仕様の機器について登録された前記機器情報を確定し、
    　　前記確認部が前記ユーザ端末による前記修正結果を取得した場合、前記修正結果より、前記機器管理テーブルにおける前記ベンダ独自仕様の機器について登録された前記機器情報を修正する、請求項１に記載の宅内機器管理装置。
  7. 　プロセッサとストレージとを備え、ユーザ端末と前記ユーザ端末に対応するユーザ宅の宅内制御装置とに広域ネットワークを介して接続される宅内機器管理装置における宅内制御装置方法であって、
    　前記プロセッサにより、前記ストレージに設けた機器管理テーブルに、前記ユーザ宅の宅内ネットワークに接続された標準規格対応の機器それぞれについて、前記宅内ネットワークにおけるアドレス情報と、ベンダ名を含む前記機器を特定する機器情報と、を登録し、
    　前記プロセッサにより、前記ユーザ端末からの登録要求に応じて、前記宅内ネットワークに接続された前記標準規格対応の機器およびベンダ独自仕様の機器の情報を問合せ、
    　前記プロセッサにより、前記問合せに応答して前記宅内制御装置から送られてくる、少なくとも前記ベンダ独自仕様の機器のアドレス値情報を含む前記ベンダ独自仕様の機器の情報を、ベンダ独自仕様の機器であることを示す識別情報と共に前記機器管理テーブルに登録し、
    　前記プロセッサにより、前記機器管理テーブルに登録した前記ベンダ独自仕様の機器の前記情報を前記ユーザ端末に送り、前記ユーザ端末による承認、修正または追加された結果を取得し、
    　前記プロセッサにより、前記取得した前記ユーザ端末による承認、修正または追加された結果により、前記機器管理テーブルにおける前記ベンダ独自仕様の機器の登録内容を更新する、
    　宅内機器管理方法。
  8. 　請求項１乃至６のいずれかに記載の宅内機器管理装置の前記各部としてプロセッサを機能させる宅内機器管理プログラム。
PCT/JP2020/023570 2020-06-16 2020-06-16 宅内機器管理装置、方法およびプログラム WO2021255826A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2022531141A JP7414138B2 (ja) 2020-06-16 2020-06-16 宅内機器管理装置、方法およびプログラム
US18/008,382 US11824676B2 (en) 2020-06-16 2020-06-16 Apparatus, method, and program for home device management
PCT/JP2020/023570 WO2021255826A1 (ja) 2020-06-16 2020-06-16 宅内機器管理装置、方法およびプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2020/023570 WO2021255826A1 (ja) 2020-06-16 2020-06-16 宅内機器管理装置、方法およびプログラム

Publications (1)

Publication Number Publication Date
WO2021255826A1 true WO2021255826A1 (ja) 2021-12-23

Family

ID=79268652

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2020/023570 WO2021255826A1 (ja) 2020-06-16 2020-06-16 宅内機器管理装置、方法およびプログラム

Country Status (3)

Country Link
US (1) US11824676B2 (ja)
JP (1) JP7414138B2 (ja)
WO (1) WO2021255826A1 (ja)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013207705A (ja) * 2012-03-29 2013-10-07 Mitsubishi Electric Corp 制御装置
JP2016139190A (ja) * 2015-01-26 2016-08-04 西日本電信電話株式会社 通信装置
JP2017108471A (ja) * 2017-03-24 2017-06-15 東芝ライテック株式会社 通信機器、通信中継機器、通信方法および通信システム
JP2018032917A (ja) * 2016-08-23 2018-03-01 シャープ株式会社 ネットワークシステム、情報処理方法、サーバ、電気機器、通信端末、およびプログラム

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9294575B1 (en) * 2014-06-04 2016-03-22 Grandios Technologies, Inc. Transmitting appliance-specific content to a user device
US11429802B2 (en) * 2019-09-12 2022-08-30 MobileIron, Inc. Obtaining device posture of a third party managed device

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013207705A (ja) * 2012-03-29 2013-10-07 Mitsubishi Electric Corp 制御装置
JP2016139190A (ja) * 2015-01-26 2016-08-04 西日本電信電話株式会社 通信装置
JP2018032917A (ja) * 2016-08-23 2018-03-01 シャープ株式会社 ネットワークシステム、情報処理方法、サーバ、電気機器、通信端末、およびプログラム
JP2017108471A (ja) * 2017-03-24 2017-06-15 東芝ライテック株式会社 通信機器、通信中継機器、通信方法および通信システム

Also Published As

Publication number Publication date
US11824676B2 (en) 2023-11-21
JPWO2021255826A1 (ja) 2021-12-23
US20230291599A1 (en) 2023-09-14
JP7414138B2 (ja) 2024-01-16

Similar Documents

Publication Publication Date Title
CN1332541C (zh) 允许有效地访问家庭网络设备的控制点服务器系统和方法
CN101184063B (zh) 控制非通用即插即用UPnP设备的方法、装置及其系统
JP6502330B2 (ja) ネットワークにおけるプロファイル間コミッショニングのための方法及び装置
CN107566229A (zh) 智能家居系统的分组控制方法
JP6473743B2 (ja) コンフィギュレーション接続装置
RU2584499C2 (ru) Способ функционирования и ввода в действие устройств в сети zigbee
JP2009135783A (ja) 通信アダプタ及びその接続情報設定方法
JP2018019313A (ja) 制御システム、通信機器、制御方法、およびプログラム
WO2023138285A1 (zh) 一种智能家居设备的绑定方法和终端
JPWO2017150642A1 (ja) ネットワークシステム、制御装置、仮想ネットワーク機能の構築方法及びプログラム
US7440775B2 (en) Method for controlling printer using portable terminal for mobile communication in home network system
CN105791454A (zh) 一种智能终端的绑定方法及装置
JP4589696B2 (ja) ネットワーク家電機器制御システム
JP2006227825A (ja) 情報家電管理システム、情報家電制御管理システム、情報家電制御管理方法、及び、情報家電操作方法
CN104918302A (zh) 一种构建无线网格网络的方法及无线音箱
CN113132958B (zh) 融合组网方法、设备、系统及计算机可读存储介质
JP6579257B2 (ja) ネットワークシステム、制御装置、仮想ネットワークの構築方法及びプログラム
CN104954449A (zh) 物联网控制方法及装置
WO2024183449A1 (zh) 楼宇协议数据处理方法、装置及系统
WO2021255826A1 (ja) 宅内機器管理装置、方法およびプログラム
JP2013207705A (ja) 制御装置
KR102320027B1 (ko) 음성 전달 방법, 이를 구현하는 음성 전달 장치 및 이를 포함하는 시스템
JP2016192706A (ja) 情報収集システム、中継端末、中継端末のセンタシステムへの接続制御方法、センサ端末、センサ端末のセンタシステムへの接続制御方法
JP5845459B2 (ja) 機器登録方法、および機器登録システム
JP2006350502A (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: 20940683

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2022531141

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20940683

Country of ref document: EP

Kind code of ref document: A1