Electronic device for managing internet of things device and storage medium therefor

Abstract

Disclosed is an electronic device comprising a communication circuit, at least one processor, and a memory for storing instructions. The instructions may cause the electronic device to: establish a D2D connection with an IoT device on the basis of identifying that the IoT device is in an offline state; receive, from the IoT device through the D2D connection, diagnostic data including an error code related to the offline state; on the basis of the diagnostic data and a recovery policy related to the IoT device, determine whether or not automatic recovery of the IoT device from the offline state is possible; on the basis that the automatic recovery is possible, transmit, to the IoT device through the D2D connection, an automatic recovery command determined on the basis of the recovery policy; and when the automatic recovery is not possible, transmit the diagnostic data of the IoT device to a server.

Description

Electronic devices for managing Internet of Things devices and their storage media

[0001] The present disclosure relates to an electronic device for managing an Internet of Things (IoT) device and a storage medium thereof.

[0002] The variety of services and additional features offered through user terminals, such as smartphones, is steadily increasing. To enhance the utility of these electronic devices and satisfy the diverse needs of users, telecommunications service providers and electronic device manufacturers are competitively developing electronic devices offering a variety of functions. Consequently, the various functions offered through these devices are also becoming increasingly sophisticated.

[0003] As wireless communication technology advances, devices utilizing artificial intelligence (AI) are becoming more widely adopted. For example, home appliances connected to the Internet of Things (IoT) can utilize AI. IoT technology can collect and analyze data generated by these devices to provide intelligent Internet technology services that create new value in human lives. Through the convergence and integration of existing Internet technologies with various industries, IoT technology can be applied to areas such as smart homes, smart buildings, smart cities, smart cars, and smart appliances.

[0004] Homes are equipped with a variety of home appliances for the convenience of users. Various services are being proposed to utilize IoT technology to facilitate the operation and control of these appliances. Home network technology can provide various services to users within the home via the home network. For example, users can control various controlled devices (e.g., IoT-enabled home appliances) that make up the home network using personal electronic devices (e.g., smartphones). Users may desire a wider range of services to control these controlled devices. Accordingly, there is a growing demand for the development of various technologies that manage controlled devices in a way that reflects user intent.

[0005] Embodiments of the present disclosure can provide Internet of Things (IoT) services.

[0006] Embodiments of the present disclosure relate to an electronic device for managing an IoT device and a storage medium thereof.

[0007] Embodiments of the present disclosure relate to an electronic device for recovering an offline state of an IoT device and a method of operating the same.

[0008] Embodiments of the present disclosure relate to an electronic device and an operating method thereof that automatically detect and reconnect an offline state of an IoT device.

[0009] The technical problems to be achieved in the present disclosure are not limited to the technical problems mentioned above, and other technical problems not mentioned will be clearly understood by a person having ordinary skill in the technical field to which the present disclosure belongs from the description below.

[0010] An electronic device according to one embodiment of the present disclosure may include a communication circuit, at least one processor including a processing circuit, and a memory storing instructions. The instructions, when individually or collectively executed by the at least one processor, may cause the electronic device to establish a device-to-device (D2D) connection with an Internet of Things (IoT) device through the communication circuit based on identifying that the IoT device is in an offline state where the IoT device is disconnected from a server. The instructions, when individually or collectively executed by the at least one processor, may cause the electronic device to receive diagnostic data from the IoT device through the D2D connection, the diagnostic data including an error code associated with the offline state. The instructions, when individually or collectively executed by the at least one processor, may cause the electronic device to determine whether automatic recovery of the offline state by the IoT device is possible based on the diagnostic data and a recovery policy associated with the IoT device. The recovery policy may include information indicating whether automatic recovery by the IoT device is possible for the error code. The instructions, when individually or collectively executed by the at least one processor, may cause the electronic device to transmit an automatic recovery command determined based on the recovery policy to the IoT device via the D2D connection based on whether the automatic recovery is possible. The instructions, when individually or collectively executed by the at least one processor, may cause the electronic device to transmit the diagnostic data of the IoT device to the server via the communication circuit if the automatic recovery is not possible.

[0011] An electronic device according to one embodiment of the present disclosure may include a communication circuit, at least one processor including a processing circuit, and a memory storing instructions. The instructions, when individually or collectively executed by the at least one processor, may cause the electronic device to receive, from a server through the communication circuit, first diagnostic data including connection status information indicating that an Internet over Things (IoT) device is offline and a first error code related to the offline status. The first diagnostic data may be collected by an external electronic device (330) located in the same local network as the IoT device and reported to the server. The instructions, when individually or collectively executed by the at least one processor, may cause the electronic device to establish a device-to-device (D2D) connection with the IoT device through the communication circuit based on identifying that the IoT device is offline. The instructions, when individually or collectively executed by the at least one processor, may cause the electronic device to receive second diagnostic data from the IoT device via the D2D connection, the second diagnostic data including a second error code associated with the offline state. The instructions, when individually or collectively executed by the at least one processor, may cause the electronic device to determine an automatic recovery command for recovering the offline state of the IoT device based on the second diagnostic data and a recovery policy associated with the IoT device, based on identifying that the first error code and the second error code are identical.The instructions, when individually or collectively executed by the at least one processor, may cause the electronic device to transmit the automatic recovery command to the IoT device via the D2D connection. The instructions, when individually or collectively executed by the at least one processor, may cause the electronic device to transmit the second diagnostic data to the server via the communication circuit based on identifying that the first error code and the second error code are not identical.

[0012] In accordance with one embodiment of the present disclosure, a non-transitory computer-readable storage medium storing one or more programs may include instructions that, when individually or collectively executed by at least one processor of an electronic device, cause the electronic device to: establish a D2D connection with the IoT device based on identifying that the IoT device is in an offline state where it is disconnected from a server; receive diagnostic data including an error code related to the offline state from the IoT device through the D2D connection; determine whether automatic recovery of the offline state by the IoT device is possible based on the diagnostic data and a recovery policy related to the IoT device; the recovery policy includes information indicating whether automatic recovery by the IoT device is possible for the error code; transmit an automatic recovery command determined based on the recovery policy to the IoT device through the D2D connection based on whether the automatic recovery is possible; and transmit the diagnostic data of the IoT device to the server through the communication circuit if the automatic recovery is not possible.

[0013] According to one embodiment of the present disclosure, a non-transitory computer-readable storage medium storing one or more programs, wherein the one or more programs, when individually or collectively executed by at least one processor of an electronic device, cause the electronic device to: receive first diagnostic data including connection status information indicating that an IoT device is in an offline state and a first error code related to the offline state, wherein the first diagnostic data is collected by an external electronic device (330) located in the same local network as the IoT device and reported to the server, establish a D2D connection with the IoT device based on identifying that the IoT device is in the offline state, receive second diagnostic data including a second error code related to the offline state from the IoT device through the D2D connection, determine an automatic recovery command for recovering the offline state of the IoT device based on the second diagnostic data and a recovery policy related to the IoT device based on identifying that the first error code and the second error code are the same, transmit the automatic recovery command to the IoT device through the D2D connection, and determine that the first error code and the second error code are not the same, and transmit the second diagnostic data based on identifying that the first error code and the second error code are not the same. It may include instructions that cause transmission to the above server.

[0014] The above and other aspects, features and advantages of specific embodiments of the present disclosure will become more apparent from the following detailed description taken in conjunction with the accompanying drawings.

[0015] FIG. 1 illustrates an IoT (internet of things) system according to various embodiments.

[0016] FIG. 2 is a block diagram of an electronic device within a network environment according to various embodiments.

[0017] FIG. 3 is a diagram illustrating a network including controlled devices according to one embodiment of the present disclosure.

[0018] FIG. 4A is a block diagram illustrating the configuration of a first electronic device performing IoT control according to one embodiment of the present disclosure.

[0019] FIG. 4b is a block diagram illustrating the configuration of a second electronic device performing IoT control according to one embodiment of the present disclosure.

[0020] FIG. 4c is a block diagram illustrating the configuration of a server that performs IoT control according to one embodiment of the present disclosure.

[0021] FIG. 5 is a drawing for explaining an execution screen of an IoT client application according to one embodiment.

[0022] FIGS. 6A, 6B, and 6C are diagrams illustrating user interfaces (UIs) that display an offline status according to one embodiment of the present disclosure.

[0023] FIG. 7a, FIG. 7b, FIG. 7c, FIG. 7d, and FIG. 7e are diagrams for explaining the flow of an offline diagnostic service according to one embodiment of the present disclosure.

[0024] FIG. 8 is a diagram for explaining an offline type of an IoT device due to an AP change according to one embodiment of the present disclosure.

[0025] FIG. 9A is a diagram illustrating an offline type of an IoT device due to a device problem according to one embodiment of the present disclosure.

[0026] FIG. 9b is a diagram illustrating an offline type of an IoT device due to a server failure according to one embodiment of the present disclosure.

[0027] FIG. 10 is a diagram for explaining a connection recovery procedure according to one embodiment of the present disclosure.

[0028] FIG. 11 is a diagram illustrating a procedure for discovering an IoT device according to one embodiment of the present disclosure.

[0029] FIG. 12 is a flowchart illustrating a procedure for performing automatic recovery of an offline state according to one embodiment of the present disclosure.

[0030] FIG. 13 is a flowchart illustrating a procedure for performing automatic recovery in an offline state based on a recovery policy according to one embodiment of the present disclosure.

[0031] FIGS. 14A and 14B are flowcharts illustrating a peripheral search procedure for discovering an offline device according to one embodiment of the present disclosure.

[0032] FIG. 15 is a flowchart illustrating a procedure for updating a recovery policy according to one embodiment of the present disclosure.

[0033] FIG. 16 is a flowchart illustrating a recovery procedure utilizing a recovery pop-up according to one embodiment of the present disclosure.

[0034] FIG. 17 is a flowchart illustrating a procedure for performing automatic recovery through user notification according to one embodiment of the present disclosure.

[0035] FIG. 18 is a flowchart illustrating a procedure for performing automatic recovery of an offline state based on diagnostic data according to one embodiment of the present disclosure.

[0036] FIGS. 19a, 19b, 19c, 19d, 19e, 19f, 19g, and 19h illustrate user interfaces (UIs) for restoring connection of an offline device according to one embodiment of the present disclosure.

[0037] FIGS. 20A and 20B illustrate user interfaces (UIs) for restoring connection to an offline device based on a user notification according to one embodiment of the present disclosure.

[0038] FIGS. 21A and 21B illustrate user interfaces (UIs) for setting up automatic recovery of an IoT device according to one embodiment of the present disclosure.

[0039] Hereinafter, embodiments of the present disclosure will be described in detail with reference to the attached drawings. In describing the embodiments of the present disclosure, detailed descriptions of related known functions or configurations will be omitted if they are determined to unnecessarily obscure the gist of the present disclosure. Furthermore, the terms described below are defined based on their functions in the embodiments of the present disclosure and may vary depending on the intentions or practices of users and operators. Therefore, their definitions should be based on the overall content of the present disclosure.

[0040] It should be noted that the technical terms used in this disclosure are used merely to describe one embodiment and are not intended to limit the present disclosure. Alternatively, unless specifically defined otherwise in this disclosure, the technical terms used in this disclosure should be interpreted as having a meaning generally understood by those skilled in the art to which this disclosure pertains, and should not be interpreted in an excessively broad or narrow sense. Alternatively, the technical terms used in this disclosure may be understood and replaced with other technical terms that are understandable to those skilled in the art. General terms used in the embodiments of this disclosure should be interpreted as defined in the dictionary or according to the context, and should not be interpreted in an excessively narrow sense.

[0041] As used herein, singular expressions may include plural expressions unless the context clearly dictates otherwise. In this disclosure, terms such as "consist of" or "include" should not necessarily be construed to include all components or operations described in the specification, and should be construed to mean that some of the components or operations may not be included, or that additional components or operations may be included.

[0042] While terms including ordinal numbers, such as "first" and "second," used herein may be used to describe various components, these components should not be limited by these terms. These terms may only be used to distinguish one component from another. For example, without departing from the scope of the present disclosure, a first component could be referred to as a "second component," and similarly, a second component could also be referred to as a "first component."

[0043] When a component is referred to as being "connected" or "connected" to another component, it may be directly connected or connected to that other component, but there may also be other components intervening. Conversely, when a component is referred to as being "directly connected" or "connected" to another component, it should be understood that there are no other components intervening.

[0044] Hereinafter, embodiments according to the present disclosure will be described with reference to the attached drawings. Regardless of the drawing numbers, identical or similar components will be given the same reference numbers and redundant descriptions thereof will be omitted. In describing embodiments of the present disclosure, if a detailed description of a related known technology is determined to obscure the gist of the present disclosure, the detailed description thereof will be omitted. It should be noted that the attached drawings are only intended to facilitate easy understanding of embodiments of the present disclosure and should not be construed as limiting the present disclosure by the attached drawings. The present disclosure should be construed to extend to all modifications, equivalents, and substitutes other than the attached drawings.

[0045] In the present disclosure, embodiments will be described using an electronic device as an example, but the electronic device may also be referred to as a terminal, a mobile station, mobile equipment (ME), user equipment (UE), a user terminal (UT), a subscriber station (SS), a wireless device, a handheld device, or an access terminal (AT). In the embodiments of the present disclosure, the electronic device may be a device having a communication function, such as a mobile phone, a personal digital assistant (PDA), a smart phone, a wireless MODEM, or a laptop.

[0046] FIG. 1 illustrates an Internet of Things (IoT) system (100) according to various embodiments. Meanwhile, at least some of the components of FIG. 1 may be omitted, and the system may be implemented to include additional components not illustrated.

[0047] Referring to FIG. 1, an IoT system (100) according to one embodiment includes a plurality of electronic devices connectable to a data network (116 or 146). For example, the IoT system (100) may include at least one of a first IoT server (110), a first node (120), a voice assistance server (130), a second IoT server (140), a second node (150), or devices (121, 122, 123, 124, 125, 136, 137, 151, 152, 153).

[0048] According to one embodiment, the first IoT server (110) may include at least one of a communication interface (111), a processor (112), or a storage (113). The second IoT server (140) may include at least one of a communication interface (141), a processor (142), or a storage (143). The “IoT server” in this document may remotely control and / or monitor one or more devices (e.g., devices (121, 122, 123, 124, 125, 151, 152, 153)) via a relay device (e.g., the first node (120) or the second node (150)) or directly without a relay device, for example, based on a data network (e.g., the data network (116) or the data network (146)). Here, a "device" is not limited to a sensor, home appliance, office electronic device, or process-performing device that is deployed (or located) within a local environment, such as a home, office, factory, building, external branch, or other type of site. A device that receives a control command and performs an action corresponding to the control command may be referred to as a "target device." An IoT server may also be referred to as a central server, as it selects a target device from among multiple devices and provides control commands.

[0049] According to one embodiment, the first IoT server (110) may communicate with devices (121, 122, 123) via a data network (116). The data network (116) may mean a network for long-distance communication, such as the Internet or a computer network (e.g., a LAN or WAN), or may include a cellular network.

[0050] According to one embodiment, the first IoT server (110) may be connected to a data network (116) via a communication interface (111). The communication interface (111) may include a communication device (or communication module) for supporting communication of the data network (116), and may be integrated into a single component (e.g., a single chip) or implemented as a plurality of separate components (e.g., multiple chips). The first IoT server (110) may communicate with devices (121, 122, 123) via a first node (120). The first node (120) may receive data from the first IoT server (110) via the data network (116) and transmit the received data to at least some of the devices (121, 122, 123). Alternatively, the first node (120) may receive data from at least some of the devices (121, 122, 123) and transmit the received data to the first IoT server (110) via the data network (116). The first node (120) may function as a bridge between the data network (116) and the devices (121, 122, 123). Meanwhile, although FIG. 1 illustrates one first node (120), this is merely exemplary and there is no limitation on the number.

[0051] A "node" in this document may be an edge computing system or a hub device. According to one embodiment, the first node (120) supports wired and / or wireless communication with the data network (116), and may also support wired and / or wireless communication with devices (121, 122, 123). For example, the first node (120) may be connected to the devices (121, 122, 123) via a short-range communication network such as at least one of Bluetooth, Wi-Fi, Wi-Fi direct, Z-wave, Zig-bee, INSETEON, X10, or IrDA (infrared data association), but there is no limitation on the type of communication. The first node (120) may be deployed (or located) within an environment such as, for example, a home, an office, a factory, a building, an external branch, or other types of sites. Accordingly, the devices (121, 122, 123) may be monitored and / or controlled by services provided by the first IoT server (110), and the devices (121, 122, 123) may not be required to have the capability of full network communication (e.g., Internet communication) for direct connection to the first IoT server (110). The devices (121, 122, 123) are illustrated as being implemented as electronic devices within a home environment, such as light switches, proximity sensors, temperature sensors, etc., but this is by way of example only and is not limiting.

[0052] According to one embodiment, the first IoT server (110) may support direct communication with devices (124, 125). Here, "direct communication" may mean communication that does not pass through an intermediary device, such as the first node (120), for example, communication via a cellular communication network and / or a data network.

[0053] According to one embodiment, the first IoT server (110) may transmit a control command to at least some of the devices (121, 122, 123, 124, 125). Here, the “control command” may mean data that causes a controllable device to perform a specific operation, and the specific operation is an operation performed by the device, and may include outputting information, sensing information, reporting information, and managing (e.g., deleting or creating) information, and there is no limitation on its type. For example, the processor (112) may obtain information (or a request) for generating a control command from an external source (e.g., a voice assistant server (130), the second IoT server (140), an external system (160), or at least some of the devices (121, 122, 123, 124, 125)), and generate the control command based on the obtained information. Alternatively, the processor (112) may generate a control command based on whether the monitoring results of at least some of the devices (121, 122, 123, 124, 125) satisfy a specified condition. The processor (112) may control the communication interface (111) to transmit the control command to the target device.

[0054] According to one embodiment, the processor (112), or the processor (132), or the processor (142) may be implemented as a combination of one or more of a general-purpose processor such as a central processing unit (CPU), a digital signal processor (DSP), an application processor (AP), a communication processor (CP), a graphics-only processor such as a graphical processing unit (GPU), a vision processing unit (VPU), or an artificial intelligence-only processor such as a neural processing unit (NPU). The above-described processing units are merely exemplary, and those skilled in the art will understand that the processor (112) is not limited to any computational means that can execute instructions stored in the memory (113), for example, and output the executed results.

[0055] According to one embodiment, the processor (112) may configure a web-based interface based on the API (114) or expose resources managed by the first IoT server (110) to the outside. The web-based interface may, for example, support communication between the first IoT server (110) and an external web service. The processor (112) may also allow, for example, an external system (160) to control and / or access the devices (121, 122, 123). The external system (160) may be an independent system that is not associated with or is not a part of the system (100), for example. The external system (160) may be, for example, an external server or a website. However, security is required for access to the devices (121, 122, 123) or the resources of the first IoT server (110) from the external system (160). According to one embodiment, the processor (112) may externally expose an API endpoint (e.g., a URL (universal resource locator)) based on the API (114) of the automation application. As described above, the first IoT server (110) may transmit a control command to a target device among the devices (121, 122, 123). Meanwhile, the description of the communication interface (141), the processor (142), the API (144) of the storage (143), and the database (145) of the second IoT server (140) may be substantially the same as the description of the communication interface (111), the processor (112), the API (114) of the storage (113), and the database (115) of the first IoT server (110). In addition, the description of the second node (150) may be substantially the same as the description of the first node (120). The second IoT server (140) can transmit control commands to a target device among the devices (151, 152, 153).The first IoT server (110) and the second IoT server (140) may be operated by the same service provider in one embodiment, but may be operated by different service providers in another embodiment.

[0056] According to one embodiment, the voice assistant server (130) can transmit and receive data with the first IoT server (110) via a data network (116). The voice assistant server (130) according to one embodiment can include at least one of a communication interface (131), a processor (132), or a storage (133). The communication interface (131) can communicate with a smart phone (136) or an AI speaker (137) via a data network (not shown) and / or a cellular network (not shown). The smart phone (136) or the AI ​​speaker (137) can include a microphone, acquire a user voice, convert it into a voice signal, and transmit the voice signal to the voice assistant server (130). The processor (132) can receive a voice signal from the smart phone (136) or the AI ​​speaker (137) via the communication interface (131). The processor (132) can process the received voice signal based on the stored model (134). The processor (132) can generate (or confirm) a control command using the processing result based on information stored in the database (135).According to one embodiment, the storage unit (113, 133, 143) may include a non-transitory storage medium of at least one type among a flash memory type, a hard disk type, a multimedia card micro type, a card type memory (e.g., SD or XD memory, etc.), a RAM (Random Access Memory), a SRAM (Static Random Access Memory), a ROM (Read-Only Memory), an EEPROM (Electrically Erasable Programmable Read-Only Memory), a PROM (Programmable Read-Only Memory), a magnetic memory, a magnetic disk, and an optical disk, and the type thereof is not limited.

[0057] FIG. 2 is a block diagram of an electronic device (201) within a network environment (200) according to various embodiments.

[0058] Referring to FIG. 2, in a network environment (200), an electronic device (201) may communicate with an electronic device (202) via a first network (298) (e.g., a short-range wireless communication network), or may communicate with at least one of an electronic device (204) or a server (208) via a second network (299) (e.g., a long-range wireless communication network). According to one embodiment, the electronic device (201) may communicate with the electronic device (204) via the server (208). According to one embodiment, the electronic device (201) may include a processor (220), a memory (230), an input module (250), an audio output module (255), a display module (260), an audio module (270), a sensor module (276), an interface (277), a connection terminal (278), a haptic module (279), a camera module (280), a power management module (288), a battery (289), a communication module (290), a subscriber identification module (296), or an antenna module (297). In some embodiments, the electronic device (201) may omit at least one of these components (e.g., the connection terminal (278)), or may have one or more other components added. In some embodiments, some of these components (e.g., the sensor module (276), the camera module (280), or the antenna module (297)) may be integrated into one component (e.g., the display module (260)).

[0059] The processor (220) may, for example, execute software (e.g., a program (240)) to control at least one other component (e.g., a hardware or software component) of the electronic device (201) connected to the processor (220) and perform various data processing or operations. According to one embodiment, as at least a part of the data processing or operations, the processor (220) may store commands or data received from other components (e.g., a sensor module (276) or a communication module (290)) in a volatile memory (232), process the commands or data stored in the volatile memory (232), and store result data in a non-volatile memory (234). According to one embodiment, the processor (220) may include a main processor (221) (e.g., a central processing unit or an application processor) or an auxiliary processor (223) (e.g., a graphics processing unit, a neural processing unit (NPU), an image signal processor, a sensor hub processor, or a communication processor) that can operate independently or together with the main processor (221). For example, when the electronic device (201) includes the main processor (221) and the auxiliary processor (223), the auxiliary processor (223) may be configured to use less power than the main processor (221) or to be specialized for a given function. The auxiliary processor (223) may be implemented separately from the main processor (221) or as a part thereof.

[0060] The auxiliary processor (223) may control at least a portion of functions or states associated with at least one component (e.g., a display module (260), a sensor module (276), or a communication module (290)) of the electronic device (201), for example, on behalf of the main processor (221) while the main processor (221) is in an inactive (e.g., sleep) state, or together with the main processor (221) while the main processor (221) is in an active (e.g., application execution) state. In one embodiment, the auxiliary processor (223) (e.g., an image signal processor or a communication processor) may be implemented as a part of another functionally related component (e.g., a camera module (280) or a communication module (290)). In one embodiment, the auxiliary processor (223) (e.g., a neural network processing unit) may include a hardware structure specialized for processing artificial intelligence models. The artificial intelligence models may be generated through machine learning. This learning can be performed, for example, on the electronic device (201) itself where the artificial intelligence model is executed, or can be performed through a separate server (e.g., server (208)). The learning algorithm can include, for example, supervised learning, unsupervised learning, semi-supervised learning, or reinforcement learning, but is not limited to the examples described above. The artificial intelligence model can include multiple artificial neural network layers.The artificial neural network may be one of a deep neural network (DNN), a convolutional neural network (CNN), a recurrent neural network (RNN), a restricted Boltzmann machine (RBM), a deep belief network (DBN), a bidirectional recurrent deep neural network (BRDNN), a deep Q-network, or a combination of two or more of the above, but is not limited to the examples described above. In addition to, or alternatively to, a hardware structure, an artificial intelligence model may include a software structure.

[0061] The memory (230) can store various data used by at least one component (e.g., the processor (220) or the sensor module (276)) of the electronic device (201). The data can include, for example, software (e.g., the program (240)) and input data or output data for commands related thereto. The memory (230) can include a volatile memory (232) or a non-volatile memory (234).

[0062] The program (240) may be stored as software in the memory (230) and may include, for example, an operating system (242), middleware (244), or an application (246).

[0063] The input module (250) can receive commands or data to be used in a component of the electronic device (201) (e.g., a processor (220)) from an external source (e.g., a user) of the electronic device (201). The input module (250) can include, for example, a microphone, a mouse, a keyboard, a key (e.g., a button), or a digital pen (e.g., a stylus pen).

[0064] The audio output module (255) can output audio signals to the outside of the electronic device (201). The audio output module (255) can include, for example, a speaker or a receiver. The speaker can be used for general purposes, such as multimedia playback or recording playback. The receiver can be used to receive incoming calls. In one embodiment, the receiver can be implemented separately from the speaker or as part of the speaker.

[0065] The display module (260) can visually provide information to an external party (e.g., a user) of the electronic device (201). The display module (260) may include, for example, a display, a holographic device, or a projector and a control circuit for controlling the device. In one embodiment, the display module (260) may include a touch sensor configured to detect a touch, or a pressure sensor configured to measure the intensity of a force generated by the touch.

[0066] The audio module (270) can convert sound into an electrical signal, or vice versa, convert an electrical signal into sound. According to one embodiment, the audio module (270) can acquire sound through the input module (250), output sound through the sound output module (255), or an external electronic device (e.g., electronic device (202)) (e.g., speaker or headphone) directly or wirelessly connected to the electronic device (201).

[0067] The sensor module (276) can detect the operating status (e.g., power or temperature) of the electronic device (201) or the external environmental status (e.g., user status) and generate an electrical signal or data value corresponding to the detected status. According to one embodiment, the sensor module (276) can include, for example, a gesture sensor, a gyro sensor, a barometric pressure sensor, a magnetic sensor, an acceleration sensor, a grip sensor, a proximity sensor, a color sensor, an IR (infrared) sensor, a biometric sensor, a temperature sensor, a humidity sensor, or an illuminance sensor.

[0068] The interface (277) may support one or more designated protocols that may be used to directly or wirelessly connect the electronic device (201) to an external electronic device (e.g., the electronic device (202)). In one embodiment, the interface (277) may include, for example, a high definition multimedia interface (HDMI), a universal serial bus (USB) interface, an SD card interface, or an audio interface.

[0069] The connection terminal (278) may include a connector through which the electronic device (201) may be physically connected to an external electronic device (e.g., the electronic device (202)). According to one embodiment, the connection terminal (278) may include, for example, an HDMI connector, a USB connector, an SD card connector, or an audio connector (e.g., a headphone connector).

[0070] A haptic module (279) can convert electrical signals into mechanical stimuli (e.g., vibration or movement) or electrical stimuli that a user can perceive through tactile or kinesthetic sensations. According to one embodiment, the haptic module (279) can include, for example, a motor, a piezoelectric element, or an electrical stimulation device.

[0071] The camera module (280) can capture still images and moving images. According to one embodiment, the camera module (280) may include one or more lenses, image sensors, image signal processors, or flashes.

[0072] The power management module (288) can manage the power supplied to the electronic device (201). According to one embodiment, the power management module (288) can be implemented as, for example, at least a part of a power management integrated circuit (PMIC).

[0073] A battery (289) may power at least one component of the electronic device (201). In one embodiment, the battery (289) may include, for example, a non-rechargeable primary battery, a rechargeable secondary battery, or a fuel cell.

[0074] The communication module (290) may support the establishment of a direct (e.g., wired) communication channel or a wireless communication channel between the electronic device (201) and an external electronic device (e.g., electronic device (202), electronic device (204), or server (208)), and the performance of communication through the established communication channel. The communication module (290) may operate independently from the processor (220) (e.g., application processor) and may include one or more communication processors that support direct (e.g., wired) communication or wireless communication. According to one embodiment, the communication module (290) may include a wireless communication module (292) (e.g., a cellular communication module, a short-range wireless communication module, or a global navigation satellite system (GNSS) communication module) or a wired communication module (294) (e.g., a local area network (LAN) communication module, or a power line communication module). Any of these communication modules may communicate with an external electronic device (204) via a first network (298) (e.g., a short-range communication network such as Bluetooth, wireless fidelity (WiFi) direct, or infrared data association (IrDA)) or a second network (299) (e.g., a long-range communication network such as a legacy cellular network, a 5G network, a next-generation communication network, the Internet, or a computer network (e.g., a LAN or WAN)). These various types of communication modules may be integrated into a single component (e.g., a single chip) or implemented as multiple separate components (e.g., multiple chips). The wireless communication module (292) may use subscriber information (e.g., an international mobile subscriber identity (IMSI)) stored in the subscriber identification module (296) to verify or authenticate the electronic device (201) within a communication network such as the first network (298) or the second network (299).

[0075] The wireless communication module (292) can support 5G networks and next-generation communication technologies following the 4G network, such as NR access technology (new radio access technology). The NR access technology can support high-speed transmission of high-capacity data (eMBB (enhanced mobile broadband)), minimization of terminal power and connection of multiple terminals (mMTC (massive machine type communications)), or high reliability and low latency (URLLC (ultra-reliable and low-latency communications)). The wireless communication module (292) can support, for example, a high-frequency band (e.g., mmWave band) to achieve a high data transmission rate. The wireless communication module (292) can support various technologies for securing performance in a high-frequency band, such as beamforming, massive multiple-input and multiple-output (MIMO), full dimensional MIMO (FD-MIMO), array antenna, analog beam-forming, or large scale antenna. The wireless communication module (292) can support various requirements specified in the electronic device (201), an external electronic device (e.g., the electronic device (204)), or a network system (e.g., the second network (299)). According to one embodiment, the wireless communication module (292) can support a peak data rate (e.g., 20 Gbps or more) for realizing eMBB, a loss coverage (e.g., 164 dB or less) for realizing mMTC, or a U-plane latency (e.g., 0.5 ms or less for downlink (DL) and uplink (UL), or 1 ms or less for round trip) for realizing URLLC.

[0076] The antenna module (297) can transmit or receive signals or power to or from an external device (e.g., an external electronic device). In one embodiment, the antenna module (297) may include an antenna including a radiator formed of a conductor or a conductive pattern formed on a substrate (e.g., a PCB). In one embodiment, the antenna module (297) may include a plurality of antennas (e.g., an array antenna). In this case, at least one antenna suitable for a communication method used in a communication network, such as the first network (298) or the second network (299), may be selected from the plurality of antennas, for example, by the communication module (290). A signal or power may be transmitted or received between the communication module (290) and an external electronic device via the at least one selected antenna. In some embodiments, in addition to the radiator, another component (e.g., a radio frequency integrated circuit (RFIC)) may be additionally formed as a part of the antenna module (297).

[0077] According to various embodiments, the antenna module (297) may form a mmWave antenna module. In one embodiment, the mmWave antenna module may include a printed circuit board, an RFIC disposed on or adjacent a first side (e.g., a bottom side) of the printed circuit board and capable of supporting a designated high-frequency band (e.g., a mmWave band), and a plurality of antennas (e.g., an array antenna) disposed on or adjacent a second side (e.g., a top side or a side side) of the printed circuit board and capable of transmitting or receiving signals in the designated high-frequency band.

[0078] At least some of the above components can be interconnected and exchange signals (e.g., commands or data) with each other via a communication method between peripheral devices (e.g., a bus, GPIO (general purpose input and output), SPI (serial peripheral interface), or MIPI (mobile industry processor interface)).

[0079] According to one embodiment, commands or data may be transmitted or received between the electronic device (201) and an external electronic device (204) via a server (208) connected to a second network (299). Each of the external electronic devices (202 or 204) may be the same or a different type of device as the electronic device (201). According to one embodiment, all or part of the operations executed in the electronic device (201) may be executed in one or more of the external electronic devices (202, 204, or 208). For example, when the electronic device (201) is to perform a certain function or service automatically or in response to a request from a user or another device, the electronic device (201) may, instead of or in addition to executing the function or service itself, request one or more external electronic devices to perform the function or at least a part of the service. One or more external electronic devices that receive the request may execute at least a portion of the requested function or service, or an additional function or service related to the request, and transmit the result of the execution to the electronic device (201). The electronic device (201) may process the result as is or additionally and provide it as at least a portion of a response to the request. For this purpose, cloud computing, distributed computing, mobile edge computing (MEC), or client-server computing technology may be used, for example. The electronic device (201) may provide an ultra-low latency service by using distributed computing or mobile edge computing, for example. In another embodiment, the external electronic device (204) may include an Internet of Things (IoT) device. The server (208) may be an intelligent server utilizing machine learning and / or a neural network. According to one embodiment, the external electronic device (204) or the server (208) may be included in the second network (299).The electronic device (201) can be applied to intelligent services (e.g., smart home, smart city, smart car, or healthcare) based on 5G communication technology and IoT-related technology.

[0080] FIG. 3 is a diagram illustrating a network including controlled devices according to one embodiment of the present disclosure.

[0081] Referring to FIG. 3, a network (300) (e.g., an IoT network) may include a server (350) operating as an IoT cloud, a first electronic device (310) (e.g., electronic device (201)), a second electronic device (330), and one or more controlled devices (e.g., IoT devices (320a, 320b, 320c, and 320d)) within a local network (345). The first electronic device (310) may be configured to communicate with the server (350) via long-range wireless communication (e.g., the second network (299)). At least one of the IoT devices (320a, 320b, 320c, and 320d) supports IoT technology and may be configured to connect to an access point (AP) (340) using short-range wireless communication (e.g., Bluetooth or Wi-Fi) and communicate with a server (350) via the AP (350).

[0082] In one embodiment, a second electronic device (330) (e.g., a TV, a home automation panel, a personal computer (PC), a smartphone, or a tablet) may be configured to have a hub function configured to manage the connection and status of IoT devices (320a, 320b, 320c, and 320d). The second electronic device (330) may be onboarded by registering with a server (350) similarly to the IoT devices (320a, 320b, 320c, and 320d), connect to an AP (340) via short-range wireless communication (e.g., Bluetooth or Wi-Fi), and communicate with the server (350) via the AP (350).

[0083] The first electronic device (310) can communicate with (e.g., control or manage) IoT devices (320a, 320b, 320c, 320d) via a server (350), via long-range wireless communication (e.g., a second network (299)), or via short-range wireless communication (e.g., a first network (298)).

[0084] The IoT devices (320a, 320b, 320c, 320d) can be controlled (e.g., to report status and / or perform specified actions) by remote commands (e.g., control commands from the first electronic device (310) or the second electronic device (330)) and may include, for example, at least one of a television, an air conditioner, an air purifier, a refrigerator, a washing machine, a light (bulb), a security camera, a sensor, or a window treatment. The IoT devices (320a, 320b, 320c, 320d) may communicate with the first electronic device (310) via a hub device (330) or an AP (340) within a local network (345), communicate with the first electronic device (310) via a server (350), and / or communicate directly with the first electronic device (310) (e.g., without going through the server (350), the AP (340), or the hub device (330)). In one embodiment, the IoT devices (320a, 320b, 320c, 320d) may be configured to communicate with the first electronic device (310) via long-range wireless communication (e.g., the second network (299)) or via short-range wireless communication (e.g., the first network (298)). In one embodiment, IoT devices (320a, 320b, 320c, 320d) may be configured to communicate with a server (350) via long-range wireless communication (e.g., a second network (299)) or via short-range wireless communication (e.g., a first network (298)).

[0085] In one embodiment, at least one of the IoT devices (320a, 320b, 320c, 320d) may be a hub-connected device configured to establish a device-to-device (D2D) connection (e.g., a Bluetooth connection, a Bluetooth low energy (BLE) connection, a ZigBee connection, a ZWave connection, or a Wi-Fi connection) with a hub device and receive control commands or report status from a server (350) via the hub device (e.g., the first electronic device (310), the second electronic device (330), or an external electronic device). In one embodiment, at least one of the IoT devices (320a, 320b, 320c, 320d) may be a cloud-connected device configured to establish a Wi-Fi connection with an AP (340) and receive control commands or report status from the server (350) via the AP (340). In one embodiment, at least one of the IoT devices (320a, 320b, 320c, 320d) may be registered with a third-party cloud and may be a cloud-to-cloud type device via a cloud-to-cloud application programmable interface (API).

[0086] In one embodiment, the first electronic device (310) may be a personal electronic device, such as a smart phone or tablet, or an electronic device having a display and user interface, such as a television or a control console. In one embodiment, the first electronic device (310) may be connected to (e.g., paired with) at least one external electronic device (e.g., a wearable device such as a smart watch) that is configured to perform at least some of the functions described below of the first electronic device (310) directly or through the first electronic device (310).

[0087] In one embodiment, the first electronic device (310) can discover at least one of the IoT devices (320a, 320b, 320c, 320d) (e.g., IoT device (320a)) or the second electronic device (330) and can execute a registration procedure (e.g., onboarding) to register the discovered IoT device (320a) or the second electronic device (330) with the server (350). The IoT devices (320a, 320b, 320c, 320d) and the second electronic device (330) can be registered with the server (350) to be associated with a user account. The first electronic device (310) can monitor and control IoT devices (320a, 320b, 320c, 320d) registered in the server (350) and the second electronic device (330) based on a user account.

[0088] The first electronic device (310) can check the status of IoT devices (320a, 320b, 320c, 320d) and the second electronic device (330) to be used by the user for the IoT service, or control the IoT devices (320a, 320b, 320c, 320d) and the second electronic device (330) (for example, transmit a control command instructing to perform a specific action). The first electronic device (310) can be an owner device of the local network (350). At least one member device (for example, another smartphone or wearable device) that includes at least some capabilities and / or control rights of the first electronic device (310) can be included in the network (300). In one embodiment, the member device may not execute a registration procedure for IoT devices (320a, 320b, 320c, 320d) or a second electronic device (330), but may execute a function of checking or controlling the status of IoT devices (320a, 320b, 320c, 320d) and / or a second electronic device (330) registered with the server (350).

[0089] FIG. 4A is a block diagram illustrating the configuration of a first electronic device performing IoT control according to one embodiment of the present disclosure.

[0090] Referring to FIG. 4A, the first electronic device (310) may be a device that implements an IoT service (e.g., an event-based IoT service) in an IoT network (e.g., the network (300)). For example, the IoT network may be a smart home network, and the IoT service may be an automation service. The first electronic device (310) may include at least one processor (402) including a processing circuit (e.g., the processor (220)), a communication circuit (404) (e.g., the communication module (290)), a memory (406) (e.g., the memory (230)) that stores instructions, and / or a display (408) (e.g., the display module (260)).

[0091] The first electronic device (310) may include a communication circuit (404) (e.g., the communication module (290) of FIG. 2) that transmits and receives signals using one or more antennas (not shown) with an external electronic device (e.g., at least one of the server (350), the AP (340), the IoT devices (320a, 320b, 320c, 320d), or the second electronic device (330) of FIG. 3). In one embodiment, the one or more antennas may be implemented as part of the antenna module (297) of FIG. 2. The first electronic device (310) may support at least one of long term evolution (LTE), 5G / NR (new radio), Zigbee, Z-Wave, ultra wide-band (UWB), Wi-Fi, or Bluetooth (e.g., Bluetooth legacy (BT) and / or Bluetooth low energy (BLE)) via a communication circuit (404). The communication circuit (404) may include one or more communication circuits based on LTE, 5G / NR, Zigbee, Z-Wave, UWB, Wi-Fi, BT, and / or BLE.

[0092] The first electronic device (310) may include a display (408) for interfacing with a user (e.g., the display module (260) of FIG. 2). The first electronic device (310) may display information related to an IoT service (e.g., status of the IoT devices (320a, 320b, 320c, 320d) and / or the second electronic device (330) and / or control objects of the IoT devices (320a, 320b, 320c, 320d) and the second electronic device (330)) through the display (408) and / or receive user input related to the IoT service (e.g., commands for controlling the IoT devices (320a, 320b, 320c, 320d) and / or the second electronic device (330)). In one embodiment, the first electronic device (310) may receive user input via the display (408) or voice user input via an audio module (not shown).

[0093] The first electronic device (310) may include a processor (402) (e.g., processor (220) of FIG. 2) that may be implemented as one or more single-core processors or one or more multi-core processors, and a memory (406) (e.g., memory (230) of FIG. 2) that stores instructions and data for the operation of the first electronic device (310). The memory (406) may store applications (e.g., widgets), user information, device information, connection information, or related data for executing an IoT service.

[0094] The processor (402) manages the status and operation of controlled devices (e.g., IoT devices (320a, 320b, 320c, 320d)) and / or the second electronic device (330) related to the IoT service, and can transmit a control command for at least one controlled device based on a user input to the at least one controlled device directly through the communication circuit (404) or through the server (340), AP (340), or the second electronic device (330).

[0095] At least one of the IoT devices (320a, 320b, 320c, 320d) registered with the server (350) or the second electronic device (330) can periodically or aperiodically report its status information to the server (350), the first electronic device (310), and / or the second electronic device (330). The first electronic device (310) (330) can output (e.g., display) the status information of at least one IoT device through a display (408).

[0096] In one embodiment, the first electronic device (310) may be configured to execute a client application for an IoT service by the processor (402). In one embodiment, the client application may include a function to execute a designated action of the IoT devices (320a, 320b, 320c, and 320d) or the second electronic device (330) and a function to display information related to a status of the IoT devices (320a, 320b, 320c, and 320d) or the second electronic device (330).

[0097] In one embodiment, the processor (402) can discover an IoT device (e.g., at least one of the IoT devices (320a, 320b, and 320c)) or a second electronic device (330) by receiving advertising data (e.g., a BLE advertising (ADV) packet) via the communication circuit (404) while the client application is running, and control the display (408) to output information (e.g., a device name, a model name, and / or a device image) of the IoT devices (320a, 320b, and 320c) or the second electronic device (330). The processor (408) can receive a user input for selecting a device (e.g., at least one of the IoT devices (320a, 320b, and 320c) or the second electronic device (330)) that is desired to be onboarded through the displayed information.

[0098] FIG. 4b is a block diagram illustrating the configuration of a second electronic device performing IoT control according to one embodiment of the present disclosure.

[0099] Referring to FIG. 4B, the second electronic device (330) may be a device that manages an IoT service (e.g., an event-based IoT service) in an IoT network (e.g., the network (300)). For example, the IoT network may be a smart home network, and the IoT service may be an automation service. The second electronic device (330) may be located within a local network (345) or in an external network (e.g., the Internet). The second electronic device (330) may include at least one processor (412) including a processing circuit, a communication circuit (414), and / or a memory (416) that stores instructions. In one embodiment, the second electronic device (330) may further include a module that performs a native function. In one embodiment, when the second electronic device (330) is a TV, the module may include a TV receiving circuit and a display.

[0100] The second electronic device (330) may include a communication circuit (414) for transmitting and receiving wireless signals with an external electronic device (e.g., at least one of the first electronic device (310), the AP (340), the server (350), and / or the IoT devices (320a, 320b, 320c, 320d)). The second electronic device (330) may support a designated short-range wireless communication technology (e.g., at least one of Zigbee, Z-Wave, ultra wide-band (UWB), or Wi-Fi) through the communication circuit (414). The communication circuit (404) may include one or more communication circuits based on the designated short-range wireless communication technology (e.g., Zigbee, Z-Wave, UWB, and / or Wi-Fi).

[0101] The second electronic device (330) may include a processor (412) (e.g., processor (220) of FIG. 2) that may be implemented as one or more single-core processors or one or more multi-core processors, and a memory (416) (e.g., memory (230) of FIG. 2) that stores instructions and data for the operation of the second electronic device (330).

[0102] The memory (416) may store user information, device information, connection information, or related data for managing IoT services. In one embodiment, the memory (416) may store a mapping table that maps executable actions, device capabilities, and current status of controlled devices (e.g., IoT devices (320a, 320b, 320c, 320d)) related to the IoT service.

[0103] The processor (412) can control or manage the status and actions of controlled devices (e.g., IoT devices (320a, 320b, 320c, 320d)) related to the IoT service. The processor (412) can receive command information related to the control of at least one of the controlled devices (e.g., IoT device (320a)) from the first electronic device (310) and / or the server (350), and transmit a control command generated based on the command information to at least one of the controlled devices (e.g., IoT device (320a)) through the communication circuit (414). The control command can be transmitted to the corresponding controlled device (e.g., IoT device (320a)) through the AP (340). The command information can instruct the IoT device (320a) on an action to be executed.

[0104] FIG. 4c is a block diagram illustrating the configuration of a server that performs IoT control according to one embodiment of the present disclosure.

[0105] Referring to FIG. 4C, the server (350) can control and manage components (e.g., IoT devices (320a, 320b, 320c, 320d), the first electronic device (310), and the second electronic device (330)) that perform IoT services (e.g., event-based IoT services) in an IoT network (e.g., the network (300)). The server (350) can be configured to communicate with the IoT devices (320a, 320b, 320c, 320d), the first electronic device (310), and the second electronic device (330) via an external network (e.g., the Internet). The server (350) can include at least one processor (422) including a processing circuit, a communication circuit (424), and / or a memory (426) that stores instructions.

[0106] The server (350) may include a communication circuit (424) for transmitting and receiving control messages and data with an external electronic device (e.g., at least one of the first electronic device (310), the second electronic device (330), the AP (340), and / or the IoT devices (320a, 320b, 320c, 320d)). The server (350) may include a processor (422) that may be implemented as one or more single-core processors or one or more multi-core processors, and a memory (426) that stores instructions and data for the operation of the server (350).

[0107] The memory (426) may store user information, device information, connection information, or related data (e.g., recovery policy information) for managing the IoT service. In one embodiment, the memory (426) may store a mapping table that maps executable actions, device capabilities, and current status of controlled devices (e.g., IoT devices (320a, 320b, 320c, 320d)) related to the IoT service.

[0108] The processor (422) can control or manage the status and actions of controlled devices (e.g., IoT devices (320a, 320b, 320c, 320d)) related to the IoT service. The processor (422) can receive information (e.g., diagnostic data) related to the control of at least one of the controlled devices (e.g., IoT device (320a)) from the first electronic device (310) and / or the second electronic device (330), and transmit a control command (e.g., an automatic recovery command) generated based on the diagnostic data to at least one of the controlled devices (e.g., IoT device (320a)) through the communication circuit (414). The control command can be transmitted to the corresponding controlled device (e.g., IoT device (320a)) through the AP (340). The command information can instruct the IoT device (320a) to perform an action (e.g., restart, reboot, or Wi-Fi update).

[0109] FIG. 5 is a drawing for explaining an execution screen of an IoT client application according to one embodiment.

[0110] Referring to FIG. 5, the first electronic device (310) may execute a client application for an IoT control service and display an execution screen (500) provided by the client application through a display module (e.g., the display module (260)). The execution screen (500) may include states (e.g., at least one of an image, a location, a name, or a connection status) of at least one external electronic device (e.g., IoT devices (320a, 320b, 320c, and 320d) and / or the second electronic device (330)) registered for a user account. The connection status may include online or offline. When the IoT devices (320a, 320b, 320c, and 320d) are normally connected to the server (350), the connection status may indicate an online status. If the IoT devices (320a, 320b, 320c, and 320d) are not normally connected to the server (350), the connection status may indicate an offline status. In one embodiment, at least one of the IoT devices (320a, 320b, 320c, and 320d) may be in an offline status based on a disconnection with the Wi-Fi AP (340), the second electronic device (330), and / or the first electronic device (310).

[0111] In one embodiment, if at least one of the IoT devices (320a, 320b, 320c, and 320d) (e.g., IoT device (320b)) is disconnected from the Internet, the execution screen (500) may include status information (e.g., status object (510)) indicating that the IoT device (320b) is offline. In one embodiment, the status information of the IoT device (320b) that is offline may be displayed in black and white. Although not shown, the status objects of the controlled device(s) that are online may be displayed in color. Although not shown, when a user input (e.g., a touch) is received for the status object (510), the electronic device (201) may display an offline guide pop-up notifying that the corresponding IoT device (e.g., IoT device (320b)) is offline. In one embodiment, the offline guide pop-up may include text guiding a method (e.g., a recovery method) for recovering an offline state of an IoT device (320b) (e.g., switching to an online state).

[0112] FIGS. 6A, 6B, and 6C are diagrams illustrating user interfaces (UIs) that display an offline status according to one embodiment of the present disclosure.

[0113] Referring to FIG. 6A, the first electronic device (310) may display a device list (600) including information of IoT devices (e.g., IoT devices (320a, 320b, 320c, and 320d)) through a display module (e.g., display module (260)). At least one of the IoT devices may be offline due to various reasons such as a device problem, an AP problem, a server failure, an application problem, etc. The device list (600) may include objects corresponding to each of the plurality of IoT devices. An object corresponding to an IoT device that is offline (e.g., device C) may include a phrase indicating that it is offline, or may be displayed in black and white, for example.

[0114] Referring to FIG. 6B, the first electronic device (310) may detect an offline state of at least one (e.g., device C) among IoT devices (e.g., IoT devices (320a, 320b, 320c, and 320d)) and display a notification message (620) indicating that device C is offline. In one embodiment, the notification message (620) may include information indicating that device C is offline and information indicating a cause (e.g., offline cause) of device C becoming offline (e.g., “Hub connection has been disconnected”). In one embodiment, the notification message (620) may include a recovery guide based on the cause of device C being offline (e.g., “Check if the hub is connected to the network”).

[0115] Referring to FIG. 6c, the first electronic device (310) can display status information (630) indicating that at least one (e.g., a smart air conditioner) among the IoT devices (e.g., IoT devices (320a, 320b, 320c, and 320d)) is offline through a client application.

[0116] In one embodiment, when an offline problem occurs in an IoT device, the first electronic device (310) displays information indicating the offline status of the IoT device, thereby allowing a user to recognize the offline status of the IoT device, analyze the cause of the offline status, and directly execute an offline diagnostic service to perform recovery through a client application.

[0117] In one embodiment, the first electronic device (310) may connect to an IoT device that is offline to perform an offline diagnostic service. For the offline diagnostic service, the first electronic device (310) may display a guide screen that prompts the user to change the IoT device to join mode (e.g., soft-AP mode), and may perform a local network search (e.g., discovery procedure) and / or a BLE scan to connect to the IoT device that has switched to join mode according to the guide screen. In one embodiment, for certain IoT devices, the method of manipulating the IoT device to change to join mode may be difficult or cumbersome. For example, if the IoT device is a refrigerator or a washing machine, the user may have to check the guide text on the back of the refrigerator or the bottom of the washing machine to change to join mode, which may cause significant inconvenience to the user.

[0118] In one embodiment, even after the user manipulates the IoT device to change it to join mode, the first electronic device (310) may fail to establish a D2D connection with the IoT device due to a high connection failure rate of soft-AP search or BLE scan.

[0119] In one embodiment, if the IoT device is normally connected to the AP (340) but the session establishment related to the IoT device between the AP (340) and the server (350) fails, the IoT device may disconnect the Wi-Fi connection with the AP (340) to operate in soft-AP mode for D2D connection with the first electronic device (310).

[0120] FIG. 7a, FIG. 7b, FIG. 7c, FIG. 7d, and FIG. 7e are diagrams for explaining the flow of an offline diagnostic service according to one embodiment of the present disclosure.

[0121] Referring to FIG. 7A, the first electronic device (310) may display a device preparation screen (710) for performing an offline diagnostic service. The device preparation screen (710) may include text guiding a user's operation for performing an offline diagnostic service, for example, "Move near the device and then turn on the device." While displaying the device preparation screen (710), the first electronic device (310) may discover an IoT device through a local network search (e.g., a discovery procedure).

[0122] Referring to FIG. 7B, the first electronic device (310) may initiate a D2D connection establishment procedure with the IoT device based on the discovery of the IoT device. While establishing the D2D connection, the first electronic device (310) may display a connection screen (720). Once the D2D connection with the IoT device is established, the first electronic device (310) may display an analysis screen (730) of FIG. 7C while analyzing diagnostic data through an offline diagnostic service. For example, it may take approximately 16 seconds to prepare the IoT device and connect to the IoT device.

[0123] Referring to FIG. 7C, the first electronic device (310) can analyze the cause of an offline state through a D2D connection with an IoT device while displaying an analysis screen (730). In one embodiment, the first electronic device (310) can receive diagnostic data including the cause of an offline state (e.g., an error code) and the device status of the IoT device through the D2D connection, and analyze the diagnostic data. Analyzing the cause of an offline state through the diagnostic data may take a relatively long time (e.g., approximately 36 seconds) during the entire flow.

[0124] Referring to FIG. 7D , the first electronic device (310) may display a connection confirmation screen (740) while waiting for the IoT device to recover based on the results of analyzing the diagnostic data. In one embodiment, the first electronic device (310) may directly transmit information necessary for connection recovery, such as a service set identification (SSID) and / or password associated with the AP (340), to the IoT device, thereby allowing the IoT device to connect to the AP (340). For example, it may take approximately 28 seconds to confirm the connection recovery of the IoT device.

[0125] Referring to FIG. 7E, the first electronic device (310) can confirm that the IoT device is online and display a diagnostic result screen (750). In one embodiment, the first electronic device (310) can provide the diagnostic result screen (750) based on receiving a response from the server (350) indicating that the IoT device has successfully connected. In one embodiment, the diagnostic result screen (750) can include identification information (e.g., SSID) of the AP (340) to which the IoT device is connected.

[0126] FIG. 8 is a diagram for explaining an offline type of an IoT device due to an AP change according to one embodiment of the present disclosure.

[0127] Referring to FIG. 8, IoT devices (e.g., device A (810a), device B (810b), device C (810c), device D (810d), and device E (810e)) may collectively go offline due to moving, changing the AP password, replacing the AP due to changing the carrier, AP failure, or server failure. In one embodiment, if AP1 (802) stops operating and a new AP (e.g., AP2 (804)) is installed in a house while device A (810a), device B (810b), device C (810c), device D (810d), and device E (810e) are connected to AP1 (802), the server connections of device A (810a), device B (810b), device C (810c), device D (810d), and device E (810e) may all be disconnected.

[0128] FIG. 9A is a diagram illustrating an offline type of an IoT device due to a device problem according to one embodiment of the present disclosure.

[0129] Referring to FIG. 9a, when device A (910a), device B (910b), device C (910c), device D (910d), and device E (910e) belonging to a local network (900) are connected to a server (350) via an AP (340), the Wi-Fi connection between the AP (340) and device E (910e) may be terminated (902) due to a problem of device E (910e). For example, if device E (910e) is moved out of the service range of the local network AP (340), device E (910e) can no longer maintain a Wi-Fi connection with the AP (340). As a result, device E (910e) may be detected as being offline.

[0130] FIG. 9b is a diagram illustrating an offline type of an IoT device due to a server failure according to one embodiment of the present disclosure.

[0131] Referring to FIG. 9b, when devices A (910a), B (910b), C (910c), D (910d), and E (910e) belonging to a local network (900) are connected to a server (350) via an AP (340), session establishment related to device E (910e) between the AP (340) and the server (350) may fail (904). For example, device E (910e) may fail to establish a session with the server (350) via the AP (340) due to a server problem or a network problem. For example, the server (350) may terminate the session with device E (910e) based on the session being unused for a specified period of time. As a result, device E (910e) may be detected as being offline.

[0132] Embodiments of the present disclosure can diagnose offline causes of IoT devices in detail through an offline diagnosis service based on a D2D connection between a first electronic device (310) and an IoT device in order to identify various offline types of IoT devices, and restore the connection of the IoT device according to the offline cause.

[0133] Embodiments of the present disclosure can automatically detect an offline state of an IoT device through an electronic device (e.g., a second electronic device (330)) located within a local network, so that even when a user is not located within a local network, the offline state of the IoT device can be recognized and the offline state of the IoT device can be recovered through an offline diagnostic service, and the network connection of the IoT device can be recovered quickly and easily without additional action by the user.

[0134] FIG. 10 is a diagram for explaining a connection recovery procedure according to one embodiment of the present disclosure.

[0135] Referring to FIG. 10, a first electronic device (310) includes a client application for an IoT service, and can register an IoT device (e.g., an IoT device (320)) with a server (350) through the client application and remotely control the registered IoT device (320). In one embodiment of the present disclosure, a second electronic device (330) can register an IoT device (320) with a server (350) and detect and diagnose an offline state of the IoT device (320) to enable the IoT device (320) to perform automatic recovery. The second electronic device (330) is a fixed (e.g., non-mobile) device located within the same local network as the IoT device (e.g., a local network (345)), and can include, for example, a hub function for registering and controlling a hub-connected device (e.g., an IoT device (320)).

[0136] In one embodiment, the first electronic device (310) or the second electronic device (330) may perform an onboarding procedure to register the IoT device (320) with the server (350). After the IoT device is onboarded, if the connection between the IoT device (320) and the server (350) is lost, the first electronic device (310) may determine that the IoT device (320) is offline and may diagnose the cause of the offline state of the IoT device (320) and perform connection recovery through an offline diagnostic service provided through a client application. In operation 1002, the second electronic device (330) may detect that the IoT device (320) is offline and perform diagnosis of the cause of the offline state and connection recovery for the IoT device (320).

[0137] In one embodiment, at operation 1004, the second electronic device (330) may log diagnostic data (e.g., error code and information on whether recovery was successful) of an IoT device (320) that is offline. In one embodiment, the logging operation may include transmitting a diagnostic result including the diagnostic data to a server (350) so that the server (350) stores the diagnostic data.

[0138] In one embodiment, the server (350) can manage a recovery policy indicating a response method for each error code specified for the IoT device (320) and / or a diagnostic capability of the IoT device (320). The first electronic device (310) or the second electronic device (330) can receive information about the recovery policy from the server (350). The first electronic device (310) or the second electronic device (330) can guide the user on a recovery method for resolving an offline state of the IoT device (320) based on the recovery policy. Whenever the recovery policy is updated, the first electronic device (310) or the second electronic device (330) can receive information about the updated recovery policy from the server (350).

[0139] In one embodiment, the second electronic device (330) can diagnose an IoT device (320) that is offline. The diagnosis can include an operation of identifying an offline cause that caused the IoT device (320) to be offline. Depending on the offline cause, the second electronic device (330) can cause the IoT device (320) to perform automatic recovery, or if automatic recovery is not possible, can notify the user that the IoT device (320) is offline. In one embodiment, the second electronic device (330) can notify the first electronic device (310) that the IoT device (320) is offline, and can cause the first electronic device (310) to perform connection recovery of the IoT device (320) through a client application when the first electronic device (310) returns to a local network (e.g., home).

[0140] In one embodiment, automatic recovery of the IoT device (320) may include at least one of: restarting the IoT device (320), establishing a D2D connection with the first electronic device (310), updating Wi-Fi connection information (e.g., a password of the AP (340)), or providing the user with information guiding a recovery method of the IoT device (320). In one embodiment, if the server (350) deletes a session associated with the IoT device (320) due to the IoT device (320) being inactive for a specified period of time, the IoT device (320) may go offline. If the IoT device (320) goes offline due to a policy of the server (350), the second electronic device (330) may not perform automatic recovery of the IoT device (320) and may transmit reminder information to the first electronic device (310) to notify the user that the IoT device (320) has gone offline. In one embodiment, the second electronic device (330) may transmit the reminder information to the first electronic device (310) via the server (350).

[0141] In one embodiment, the second electronic device (330) can discover an offline IoT device (320) by performing a local network search (e.g., a discovery procedure) and / or a BLE scan. In one embodiment, the local network search can be performed using at least one of multicast domain name service (mDNS), DNS service discovery (DNS-SD), simple service discovery protocol (SSDP), or universal plug and play (UPNP).

[0142] FIG. 11 is a diagram illustrating a procedure for discovering an IoT device according to one embodiment of the present disclosure. Depending on the embodiments, at least one of the operations described below may be omitted, modified, or executed in a different order.

[0143] Referring to FIG. 11, in operation 1102, an IoT device (320) may be onboarded to a server (350). In one embodiment, the IoT device (320) may establish a Wi-Fi connection with an AP (340) based on connection information provided through a first electronic device (310) or a second electronic device (330) and transmit an onboarding request to the server (350) through the AP (340). In one embodiment, the IoT device (320) may establish a D2D connection with a second electronic device (330) and transmit an onboarding request to the server (350) through the second electronic device (330). The server (350) may register the IoT device (320) based on the onboarding request and notify the first electronic device (310) and / or the second electronic device (330) of the completion of onboarding of the IoT device (320).

[0144] In operation 1104, the IoT device (320) may be managed as being online based on the fact that the IoT device (320) is connected to the server (350). In one embodiment, the server (350) may periodically notify the first electronic device (310) and / or the second electronic device (330) that the IoT device (320) is online. In one embodiment, the first electronic device (310) and / or the second electronic device (330) may determine that the IoT device (320) is online based on not receiving information from the server (350) indicating that the IoT device (320) is offline.

[0145] In one embodiment, when the IoT device (320) is onboarded via the first electronic device (310), the second electronic device (330) may discover the IoT device (320) via operations 1106 and 1108. In operation 1106, the second electronic device (330) may transmit (e.g., broadcast) a domain name service (DNS) service discovery request to the IoT device (320). In one embodiment, the DNS service discovery request may include service type information indicating whether the IoT device (320) supports auto-recovery. In operation 1108, the IoT device (320) may transmit a DNS service discovery response to the second electronic device (330). In one embodiment, the DNS service discovery response may include status information indicating a connection status (e.g., an online status) of the IoT device (320) and / or optionally a last error code.

[0146] In operation 1110, the IoT device (320) may be disconnected from the server (350). In operation 1112, the server (350) may detect that the IoT device (320) is offline based on the disconnection of the IoT device (320). In one embodiment, the server (350) may transmit information indicating that the offline state of the IoT device (320) is detected to the first electronic device (310) and / or the second electronic device (330).

[0147] In one embodiment, when an offline state of the IoT device (320) is detected, the second electronic device (330) may discover the IoT device (320) through operations 1114 and 1116 to restore the connection of the IoT device (320). In operation 1114, the second electronic device (330) may transmit (e.g., broadcast) a DNS service discovery request to the IoT device (320). In one embodiment, the DNS service discovery request may include service type information indicating whether the IoT device (320) supports automatic recovery. In operation 1116, the IoT device (320) may transmit a DNS service discovery response to the second electronic device (330). In one embodiment, the DNS service discovery response may include status information indicating the connection state (e.g., offline state) of the IoT device (320) and / or optionally a recent error code. In one embodiment, the recent error code may indicate a disconnection to the server (350).

[0148] In one embodiment, when the IoT device (320) supports BLE, the IoT device (320) may broadcast a BLE advertising packet based on detecting an offline state, for example, detecting a failure in connection with an AP (340), so that the second electronic device (330) may discover the IoT device (320). In one embodiment, the IoT device (320) may include information indicating that the IoT device (320) is offline in the BLE advertising packet. The second electronic device (330) may confirm ownership of the IoT device (320) based on receiving the BLE advertising packet and then establish a D2D connection (for example, a BLE connection) with the IoT device (320).

[0149] In one embodiment, the second electronic device (330) may determine that the ownership of the IoT device (320) has been confirmed based on whether the owner information (e.g., owner ID) of the IoT device (320) matches the owner information of the second electronic device (330). In one embodiment, the second electronic device (330) may confirm the ownership of the IoT device (320) through at least one of the owner information or the BLE medium access control (MAC). In one embodiment, the second electronic device (330) may discover the IoT device (320), receive the owner information (e.g., owner ID) from the IoT device (320), and confirm that the owner information matches the owner information of the second electronic device (330). In one embodiment, the second electronic device (330) may discover the IoT device (320), and confirm the ownership of the IoT device (320) based on the BLE medium access control (MAC) address of the IoT device (320).

[0150] FIG. 12 is a flowchart illustrating a procedure for performing automatic recovery from an offline state according to one embodiment of the present disclosure. Depending on the embodiments, at least one of the operations described below may be omitted, modified, or executed in a different order. In one embodiment, at least one of the operations described below may be executed by the processor (412) of the second electronic device (330). In one embodiment, at least one of the operations described below may be implemented as one or more instructions stored in the memory (416) of the second electronic device (330).

[0151] Referring to FIG. 12, in operation 1202, the second electronic device (330) (e.g., processor 412) may identify (e.g., detect) that an IoT device (e.g., IoT device 320) is offline. In one embodiment, the second electronic device (330) (e.g., processor 412) may detect the offline state by receiving information (e.g., an offline device list or a registered device list including connection status information) from an external electronic device (e.g., the first electronic device (310) or a server (350)) indicating that the IoT device (320) is offline. In one embodiment, the second electronic device (330) (e.g., processor 412) may detect the offline state based on a loss of Wi-Fi connection with an AP (e.g., AP1 (802)) associated with the IoT device (320). In one embodiment, the second electronic device (330) (e.g., processor (412)) may detect the offline state based on a change in Wi-Fi connection information (e.g., password) of an AP (e.g., AP (340)) associated with the IoT device (320).

[0152] In operation 1204, the second electronic device (330) (e.g., processor 412) may establish a D2D connection (e.g., Wi-Fi connection or BLE connection) with the IoT device (320). In one embodiment, the second electronic device (330) (e.g., processor 412) may discover the IoT device (320) through a local network search (e.g., a discovery procedure based on mDNS, DNS-SD, SSDP, or UPNP) prior to establishing the D2D connection, or may discover the IoT device (320) based on receiving a BLE advertising packet broadcast from the IoT device (320). In one embodiment, the second electronic device (330) (e.g., processor 412) may periodically perform a discovery procedure to discover an IoT device (320) that is offline within the local network, or may periodically perform a BLE scan to receive a BLE advertising packet.

[0153] In operation 1206, the second electronic device (330) (e.g., processor 412) may receive diagnostic data from the IoT device (320) via the D2D connection. In one embodiment, the diagnostic data may include offline cause and / or device status information of the IoT device (320). In one embodiment, the diagnostic data may include information about the device status collected by the IoT device (320) within a range supported by the IoT device (320). In one embodiment, the offline cause may include at least one of specified error codes. In one embodiment, the second electronic device (330) (e.g., processor 412) may obtain information about the connection status of the IoT device (320) (e.g., offline status) and the diagnostic data (e.g., recent error code) while performing a local network search and / or a BLE scan.

[0154] In operation 1208, the second electronic device (330) (e.g., the processor 412) may determine whether the offline state of the IoT device (320) is automatically recoverable based on the diagnostic data. In one embodiment, the second electronic device (330) (e.g., the processor 412) may determine that automatic recovery is possible based on identifying that the error code in the diagnostic data acquired from the IoT device (320) is a value indicating an automatically recoverable error (e.g., CE20, NE11-1, or NE11-4 of Table 1). If the offline state of the IoT device (320) corresponds to an error that is not automatically recoverable, the second electronic device (330) (e.g., the processor 412) may proceed to operation 1212. If it is determined that the offline state of the IoT device (320) is automatically recoverable, the second electronic device (330) (e.g., the processor 412) may proceed to operation 1210.

[0155] In operation 1210, the second electronic device (330) (e.g., processor 412) may perform automatic recovery for the IoT device (320). In one embodiment, the second electronic device (330) (e.g., processor 412) may transmit a command (e.g., automatic recovery command) via the D2D connection, instructing the IoT device (320) to perform automatic recovery including a specified operation. In one embodiment, the specified operation may include a restart, a reboot, or a Wi-Fi update. The Wi-Fi update may include an operation of changing Wi-Fi connection information (e.g., an SSID and / or password). The IoT device (320) may perform the specified operation (e.g., restart, reboot, or Wi-Fi update) based on the automatic recovery command, and transmit the result to the second electronic device (330) via the D2D connection. In one embodiment, the second electronic device (330) (e.g., processor (412)) may inquire of the server (350) whether the IoT device (320) has been normally connected to the server (350) (e.g., switched to an online state) after transmitting the automatic recovery command. The second electronic device (330) (e.g., processor (412)) may receive a response from the server (350) notifying that the IoT device (320) has been normally recovered.

[0156] In operation 1212, the second electronic device (330) (e.g., processor (412)) may log the diagnostic data obtained from the IoT device (320). In one embodiment, the logging operation may include storing the diagnostic data in a memory (e.g., memory (416)) of the second electronic device (330) and / or transmitting the diagnostic data to a server (350) and / or the first electronic device (310).

[0157] FIG. 13 is a flowchart illustrating a procedure for performing automatic recovery in an offline state based on a recovery policy according to one embodiment of the present disclosure. At least one of the operations described below may be omitted, modified, or executed in a different order depending on the embodiments. In one embodiment, at least one of the operations described below may be executed by the processor (412) of the second electronic device (330). In one embodiment, at least one of the operations described below may be implemented as one or more instructions stored in the memory (416) of the second electronic device (330). In one embodiment, operations 1306, 1308, 1310, 1314, 1316, and 1320 may correspond to operations 1202, 1204, 1206, 1208, 1210, and 1212, respectively.

[0158] Referring to FIG. 13, in operation 1302, the second electronic device (330) (e.g., processor 412) may determine whether a recovery policy associated with the IoT device (320) has been updated. In one embodiment, the second electronic device (330) (e.g., processor 412) may check whether update information of the recovery policy is received from the server (350). If information indicating that the recovery policy is updated is received from the server (350), the second electronic device (330) (e.g., processor 412)) may proceed to operation 1304. In operation 1304, the second electronic device (330) (e.g., processor 412)) may receive the updated recovery policy from the server (350). On the other hand, if the recovery policy does not need to be updated, the second electronic device (330) (e.g., processor 412)) may proceed to operation 1306. In one embodiment, the recovery policy may include a recovery method corresponding to an offline cause (e.g., an error code) of the IoT device (320).

[0159] In operation 1306, the second electronic device (330) (e.g., processor (412)) may detect that the IoT device (e.g., IoT device (320)) is offline. In one embodiment, the second electronic device (330) (e.g., processor (412)) may detect the offline state by receiving information (e.g., an offline device list or a registered device list including connection status information) from an external electronic device (e.g., the first electronic device (310) or the server (350)) indicating that the IoT device (320) is offline. In one embodiment, the second electronic device (330) (e.g., processor (412)) may detect the offline state based on a loss of Wi-Fi connection with an AP (e.g., AP1 (802)) associated with the IoT device (320). In one embodiment, the second electronic device (330) (e.g., processor (412)) may detect the offline state based on a change in Wi-Fi connection information (e.g., password) of an AP (e.g., AP (340)) associated with the IoT device (320).

[0160] In operation 1308, the second electronic device (330) (e.g., processor (412)) can discover the IoT device (320) and establish a D2D connection (e.g., Wi-Fi connection or BLE connection) with the IoT device (320). In one embodiment, the second electronic device (330) (e.g., processor (412)) can discover the IoT device (320) and establish a D2D connection (e.g., BLE connection) with the IoT device (320) by periodically performing a discovery procedure or a BLE scan.

[0161] In operation 1310, the second electronic device (330) (e.g., processor (412)) may receive diagnostic data from the IoT device (320) via the D2D connection. In one embodiment, the second electronic device (330) (e.g., processor (412)) may transmit a request message to request diagnostic data from the IoT device (320) via the D2D connection and receive the diagnostic data from the IoT device (320) in response to the request message.

[0162] In operation 1312, the second electronic device (330) (e.g., processor (412)) may determine a recovery method for recovering an offline state of the IoT device (320) by performing an offline diagnostic service based on the diagnostic data and a recovery policy. In one embodiment, the second electronic device (330) (e.g., processor (412)) may identify an offline cause (e.g., an error code) included in the diagnostic data, and identify a recovery method corresponding to the error code from the recovery policy. In one embodiment, the recovery method may include automatic recovery by the IoT device (320).

[0163] In operation 1314, the second electronic device (330) (e.g., processor (412)) may determine whether the offline cause (e.g., error code) included in the diagnostic data indicates an error that is capable of automatic recovery. In one embodiment, the second electronic device (330) (e.g., processor (412)) may determine that automatic recovery is possible based on identifying that the error code is a value indicating an error that is capable of automatic recovery. In one embodiment, the second electronic device (330) (e.g., processor (412)) may determine whether the offline cause indicates an error that is capable of automatic recovery based on the recovery policy.

[0164] If it is determined in operation 1314 that automatic recovery is possible, in operation 1316, the second electronic device (330) (e.g., the processor 412) may perform automatic recovery for the IoT device (320). In one embodiment, the second electronic device (330) (e.g., the processor 412) may transmit a command (e.g., an automatic recovery command) to the IoT device (320) via the D2D connection, instructing the IoT device (320) to perform automatic recovery including a specified operation. In one embodiment, the specified operation may include a restart or a reboot. In one embodiment, the automatic recovery command may include Wi-Fi connection information (e.g., an SSID and / or a password) related to an AP to which the IoT device (320) is to reconnect. The IoT device (320) may perform a specified operation (e.g., a restart or a reboot) based on the automatic recovery command, and transmit the result to the second electronic device (330) via the D2D connection.

[0165] If automatic recovery is not determined to be possible in operation 1314, the second electronic device (330) (e.g., processor 412) may provide a user notification related to the offline state of the IoT device (320) in operation 1218. In one embodiment, the second electronic device (330) (e.g., processor 412) may provide reminder information indicating that the IoT device (320) is offline to the user through the server (350) and / or the first electronic device (310). In one embodiment, the reminder information may be transmitted to the first electronic device (310) through the server (350), and the first electronic device (310) may display information indicating that the IoT device (320) is offline based on receiving the reminder information.

[0166] In operation 1320, the second electronic device (330) (e.g., processor (412)) may log the diagnostic data. In one embodiment, the logging operation may include storing the diagnostic data in a memory (e.g., memory (416)) of the second electronic device (330) and / or transmitting the diagnostic data to a server (350) and / or the first electronic device (310).

[0167] In one embodiment, designated offline causes for various types of errors that may occur in an IoT device (320) may be defined as error codes, respectively. The second electronic device (330) may determine whether an error is capable of automatic recovery based on the error code in the diagnostic data received from the IoT device (320).

[0168] In one embodiment, error code NE11-1 indicates that the IoT device (320) has failed to connect to a Wi-Fi connection because it cannot find a connectable AP, and can respond to an error that can be automatically recovered.

[0169] In one embodiment, error code NE11-4 indicates that the IoT device (320) does not know the password of the AP to which it is trying to connect, for example, a connection to the AP fails due to a password mismatch, and can respond to an error that can be automatically recovered.

[0170] In one embodiment, the second electronic device (330) may provide the IoT device (320) with Wi-Fi connection information related to the AP to which the second electronic device (330) is connected and / or other APs in an automatic recovery command. In one embodiment, the second electronic device (330) may receive Wi-Fi connection information related to an AP to which another IoT device (e.g., another IoT device associated with a user account, or another IoT device within the same local network) is connected from a server (350) and include the Wi-Fi connection information in the automatic recovery command.

[0171] FIGS. 14A and 14B are flowcharts illustrating a peripheral search procedure for discovering an offline device according to one embodiment of the present disclosure. Depending on the embodiments, at least one of the operations described below may be omitted, modified, or executed in a different order. In one embodiment, at least one of the operations described below may be executed by the processor (412) of the second electronic device (330). In one embodiment, at least one of the operations described below may be implemented as one or more instructions stored in the memory (416) of the second electronic device (330).

[0172] Referring to FIGS. 14A and 14B , at operation 1402, the second electronic device (330) (e.g., processor (412)) may obtain a list of offline devices associated with a user account. In one embodiment, the second electronic device (330) (e.g., processor (412)) may receive the list of offline devices from the server (350) by periodically transmitting a request for the list of offline devices to the server (350). In one embodiment, the second electronic device (330) (e.g., processor (412)) may detect an offline state of the IoT device (320) based on identifying that the list of offline devices includes a specified IoT device (e.g., IoT device (320)).

[0173] In operation 1404, the second electronic device (330) (e.g., processor (412)) may identify a diagnostic support capability of at least one IoT device (e.g., IoT device (320)) included in the offline device list. In one embodiment, the second electronic device (330) (e.g., processor (412)) may identify the diagnostic support capability of the IoT device (320) based on a pre-obtained recovery policy. In one embodiment, the diagnostic support capability may include information indicating whether the second electronic device (330) is capable of performing an offline diagnostic service for the IoT device (320).

[0174] In operation 1406, the second electronic device (330) (e.g., processor (412)) may determine whether there is at least one IoT device (e.g., IoT device (320)) capable of providing an offline diagnostic service based on the identification of the diagnostic support capability. If there is at least one IoT device capable of providing an offline diagnostic service, the second electronic device (330) (e.g., processor (412)) may proceed to operation 1408. If there is not at least one IoT device capable of providing an offline diagnostic service, the second electronic device (330) (e.g., processor (412)) may terminate the procedure.

[0175] In operation 1408, the second electronic device (330) (e.g., processor (412)) may discover the IoT device (320) by performing a local network search (e.g., discovery procedure) and establish a D2D connection with the IoT device (320).

[0176] In operation 1410, the second electronic device (330) (e.g., processor (412)) may perform an offline diagnostic service for the IoT device (320). In one embodiment, the offline diagnostic service may include an operation of receiving diagnostic data from the IoT device (320), an operation of analyzing an offline cause (e.g., an error code) included in the diagnostic data, and / or an operation of determining a recovery method corresponding to the error code based on a recovery policy.

[0177] In operation 1412, the second electronic device (330) (e.g., processor 412) may determine whether the same offline cause has been diagnosed for the IoT device (320) within a specified time T (e.g., T = 24 hours). In one embodiment, the second electronic device (330) (e.g., processor 412) may determine whether two or more diagnostic data including the same offline cause (e.g., same error code) have been received from the IoT device (320) within 24 hours. If the same offline cause has not been diagnosed within the specified time, the second electronic device (330) (e.g., processor 412) may proceed to operation 1414. If the same offline cause has been diagnosed, the second electronic device (330) (e.g., processor 412) may proceed to operation 1416.

[0178] In operation 1414, the second electronic device (330) (e.g., processor (412)) may perform automatic recovery for the IoT device (320) based on the results analyzed through the offline diagnostic service. In one embodiment, the second electronic device (330) (e.g., processor (412)) may transmit an automatic recovery command, which instructs a recovery method corresponding to the offline cause determined based on a recovery policy, to the IoT device (320) via a D2D connection. After transmitting the automatic recovery command, the second electronic device (330) (e.g., processor (412)) may proceed to operation 1416. In one embodiment, operation 1414 may correspond to operation 1210. In operation 1416, the second electronic device (330) (e.g., processor (412)) may log the diagnostic data related to the IoT device (320). In one embodiment of the above logging, the logging operation may include an operation of transmitting a diagnostic result including diagnostic data to a server (350) so that the server (350) stores the diagnostic data.

[0179] In operation 1418, the second electronic device (330) (e.g., processor (412)) may determine whether the offline diagnostic service for all of the IoT devices identified in operation 1404 has been completed. If the offline diagnostic service for all of the IoT devices has been completed, the second electronic device (330) (e.g., processor (412)) may terminate the procedure. If the offline diagnostic service for all of the IoT devices has not been completed, the second electronic device (330) (e.g., processor (412)) may proceed to operation 1420.

[0180] In operation 1420, the second electronic device (330) (e.g., processor (412)) may perform a BLE scan to discover an offline IoT device (e.g., IoT device (320) supporting BLE). In one embodiment, the second electronic device (330) (e.g., processor (412)) may perform a BLE scan to receive a BLE advertising packet broadcast from an IoT device (320) supporting BLE. If an IoT device (320) supporting BLE is discovered through the BLE scan, the second electronic device (330) (e.g., processor (412)) may proceed to operation 1422.

[0181] In operation 1422, the second electronic device (330) (e.g., processor 412) can verify ownership of the IoT device (320). In one embodiment, the second electronic device (330) (e.g., processor 412) can verify ownership of the IoT device (320) based on owner information or BLE MAC address received from the IoT device (320). If ownership of the IoT device (320) cannot be verified, the second electronic device (330) (e.g., processor 412) can terminate the procedure. If ownership of the IoT device (320) is verified, the second electronic device (330) (e.g., processor 412) can proceed to operation 1424.

[0182] In operation 1424, the second electronic device (330) (e.g., processor (412)) may establish a D2D connection (e.g., BLE connection) with the IoT device (320) and perform an offline diagnostic service for the IoT device (320) through the D2D connection. In one embodiment, the offline diagnostic service may include an operation of receiving diagnostic data from the IoT device (320), an operation of analyzing an offline cause (e.g., an error code) included in the diagnostic data, and / or an operation of determining a recovery method corresponding to the error code based on a recovery policy.

[0183] At operation 1426, the second electronic device (330) (e.g., processor 412) may determine whether the same offline cause has been diagnosed for the IoT device (320) within a specified time T (e.g., T = 24 hours). In one embodiment, the second electronic device (330) (e.g., processor 412) may determine whether two or more diagnostic data including the same offline cause (e.g., same error code) have been received from the IoT device (320) within 24 hours. If the same offline cause has not been diagnosed within the specified time, the second electronic device (330) (e.g., processor 412) may proceed to operation 1430. If the same offline cause has been diagnosed, the second electronic device (330) (e.g., processor 412) may proceed to operation 1428.

[0184] In operation 1430, the second electronic device (330) (e.g., processor (412)) may perform automatic recovery for the IoT device (320) based on the results analyzed through the offline diagnostic service. In one embodiment, the second electronic device (330) (e.g., processor (412)) may transmit an automatic recovery command, which instructs a recovery method corresponding to the offline cause determined based on a recovery policy, to the IoT device (320) through a D2D connection. After transmitting the automatic recovery command, the second electronic device (330) (e.g., processor (412)) may proceed to operation 1428. In one embodiment, operation 1430 may correspond to operation 1210. In operation 1428, the second electronic device (330) (e.g., processor (412)) may log the diagnostic data related to the IoT device (320). In one embodiment of the above logging, the logging operation may include an operation of transmitting a diagnostic result including diagnostic data to a server (350) so that the server (350) stores the diagnostic data.

[0185] below shows examples of recovery methods for each error code according to one embodiment of the present disclosure.

[0186] Error Code Offline Cause Automatic Recovery Recovery Method Guide DS01-1 Long-term inactivity X Diagnostic information logging The connection to the server has been lost due to long-term inactivity. CE20 Sign-in failure O Device reboot CE90 Device initialization X Add again NE11-1 AP not found OWi-Fi update The connection has been lost due to a change in the router information. Please check the router status. NE11-4 AP connection failure (e.g., password mismatch) OWi-Fi update The connection has been lost due to a change in the router information. Please check the router status.

[0187] In one embodiment, the second electronic device (330) can obtain information on the offline cause, whether to automatically recover, and recovery method for each error code, such as in Table 1, from the recovery policy received from the server (350). In one embodiment, when the recovery policy is manually changed by an administrator, the server (350) can transmit update information of the recovery policy to the first electronic device (310) and / or the second electronic device (330). In one embodiment, the server (350) can automatically update the recovery policy according to the accumulated recovery success rate for each error code corresponding to a user account, and the server (350) can transmit update information of the recovery policy to the first electronic device (310) and / or the second electronic device (330).

[0188] FIG. 15 is a flowchart illustrating a procedure for updating a recovery policy according to one embodiment of the present disclosure. Depending on the embodiments, at least one of the operations described below may be omitted, modified, or executed in a different order. In one embodiment, at least one of the operations described below may be executed by the server (350). In one embodiment, at least one of the operations described below may also be performed by the first electronic device (310) (e.g., processor (402)) and / or the second electronic device (330) (e.g., processor (412)).

[0189] Referring to FIG. 15, in operation 1502, the server (350) may collect diagnostic data related to at least one IoT device (e.g., IoT device (320)). In one embodiment, the diagnostic data may be reported to the server (350) from the first electronic device (310) and / or the second electronic device (330). In one embodiment, the diagnostic data may include an offline cause (e.g., a recent error code) transmitted from the IoT device (320) to the first electronic device (310) and / or the second electronic device (330), and a result of performing a recovery method for the recent error code (e.g., recovery success or recovery failure).

[0190] In operation 1504, the server (350) may update the cumulative recovery success rate for each error code based on the diagnostic data. In one embodiment, the server (350) may accumulate the recovery success rate for each error code based on the results of performing the recovery method for each error code included in the recovery policy (e.g., the recovery method or recovery failure).

[0191] At step 1506, the server (350) may determine whether to update the recovery policy based on the cumulative recovery success rate. In one embodiment, the server (350) may change the recovery method for a specific error code based on identifying that the recovery success rate of the specified recovery method for the specific error code is below a specified threshold. If the recovery policy is updated, the server (350) may proceed to step 1508. If the recovery policy is not updated, the server (350) may terminate the process.

[0192] In operation 1508, the server (350) may update the recovery policy based on the determination result. In one embodiment, the server (350) may include information in the recovery policy that enables a new recovery method to be performed for the specific error code. In one embodiment, the server (350) may transmit update information indicating that the recovery policy has been updated to the first electronic device (310) and / or the second electronic device (330), thereby allowing the first electronic device (310) and / or the second electronic device (330) to obtain the updated recovery policy.

[0193] FIG. 16 is a flowchart illustrating a recovery procedure utilizing a recovery pop-up according to one embodiment of the present disclosure. Depending on the embodiments, at least one of the operations described below may be omitted, modified, or executed in a different order. In one embodiment, at least one of the operations described below may be executed by the processor (402) of the first electronic device (310). In one embodiment, at least one of the operations described below may be implemented as one or more instructions stored in the memory (416) of the first electronic device (310).

[0194] Referring to FIG. 16, in operation 1602, a first electronic device (310) (e.g., processor (402)) may receive a list of registered devices associated with a user account from a server (350). In one embodiment, the list of registered devices may include device information (e.g., at least one of a device name, a model name, or a serial number) and connection status information (e.g., online or offline) of at least one IoT device (e.g., IoT device (320)) registered for the user account. In one embodiment, the first electronic device (310) (e.g., processor (402)) may transmit a message requesting the list of registered devices to the server (350) when a client application for an IoT service is executed or when a user input requesting the list of registered devices is received through the client application.

[0195] In operation 1604, the first electronic device (310) (e.g., processor (402)) may determine whether the list of registered devices includes at least one IoT device that is offline. If there is no IoT device that is offline, the first electronic device (310) (e.g., processor (402)) may terminate the procedure. If at least one IoT device that is offline (e.g., IoT device (320)) is included in the list of registered devices, the first electronic device (310) (e.g., processor (402)) may proceed to operation 1606.

[0196] At step 1606, the first electronic device (310) (e.g., processor 402) may perform a D2D discovery (e.g., local network discovery and / or BLE scan) to discover an IoT device (e.g., IoT device 320) that is offline. If an IoT device (320) is discovered through the D2D discovery, the first electronic device (310) (e.g., processor 402)) may proceed to step 1608. If no IoT device is discovered through the D2D discovery that is offline, the first electronic device (310) (e.g., processor 402) may terminate the procedure. In one embodiment, the first electronic device (310) (e.g., processor 402) may establish a D2D connection with the IoT device (320) discovered through the D2D discovery. In one embodiment, a first electronic device (310) (e.g., processor (402)) can verify ownership of an IoT device (320) discovered through D2D discovery.

[0197] In operation 1608, the first electronic device (310) (e.g., processor (402)) may determine whether valid diagnostic data related to the IoT device (320) is stored in the server (350). In one embodiment, the diagnostic data may be collected by the second electronic device (330) and reported to the server (350). In one embodiment, the first electronic device (310) (e.g., processor (402)) may transmit a message to the server (350) requesting a user account or valid diagnostic data related to the IoT device (320).

[0198] In one embodiment, the first electronic device (310) (e.g., processor (402)) may determine that the diagnostic data is valid if the diagnostic data was collected or reported within a specified time period (e.g., 24 hours). If no valid diagnostic data exists, the first electronic device (310) (e.g., processor (402)) may terminate the procedure. If valid diagnostic data exists, the first electronic device (310) (e.g., processor (402)) may proceed to operation 1610.

[0199] In operation 1610, the first electronic device (310) (e.g., processor (402)) may display a recovery pop-up related to the IoT device (320) based on the diagnostic data and the recovery policy acquired from the server (350). In one embodiment, the first electronic device (310) (e.g., processor (402)) may display the recovery pop-up based on identifying that the error code included in the diagnostic data is a value indicating an automatically recoverable error (e.g., CE20, NE11-1, or NE11-4 of Table 1). In one embodiment, the recovery pop-up may include information (e.g., guide text) indicating a recovery method acquired from the recovery policy.

[0200] In operation 1612, the first electronic device (310) (e.g., processor (402)) may establish a D2D connection with an offline IoT device (320) based on a user input through the recovery pop-up, and perform automatic recovery for the IoT device (320) through the D2D connection. In one embodiment, the first electronic device (310) (e.g., processor (402)) may transmit a command (e.g., automatic recovery command) through the D2D connection, instructing the IoT device (320) to perform a specified operation for automatic recovery. In one embodiment, the specified operation may include a restart, a reboot, or a Wi-Fi update. The IoT device (320) may perform a specified operation (e.g., a restart, a reboot, or a Wi-Fi update) based on the automatic recovery command, and transmit the result to the first electronic device (310) through the D2D connection.

[0201] In operation 1614, the first electronic device (310) (e.g., processor (402)) may log the recovery result obtained from the IoT device (320). In one embodiment, the logging operation may include an operation of storing the recovery result in a memory (e.g., memory (406)) of the first electronic device (310) and / or an operation of transmitting the recovery result to a server (350).

[0202] FIG. 17 is a flowchart illustrating a procedure for performing automatic recovery through user notification according to one embodiment of the present disclosure. Depending on the embodiments, at least one of the operations described below may be omitted, modified, or executed in a different order. In one embodiment, at least one of the operations described below may be executed by the processor (402) of the first electronic device (310). In one embodiment, at least one of the operations described below may be implemented as one or more instructions stored in the memory (416) of the first electronic device (310).

[0203] Referring to FIG. 17, in operation 1702, the first electronic device (310) (e.g., the processor (402)) may receive notification reminder information indicating that an offline state of the IoT device (320) has been detected from the server (350) or the second electronic device (330). In one embodiment, the first electronic device (310) (e.g., the processor (402)) may display an offline notification (e.g., the offline notification (2002) of FIG. 20A) based on the reminder information. In one embodiment, the first electronic device (310) (e.g., the processor (402)) may proceed to operation 1704 based on a user input (e.g., a touch) through the offline notification.

[0204] At step 1704, the first electronic device (310) (e.g., processor 402) may determine whether direct recovery for the IoT device (320) is possible. In one embodiment, the first electronic device (310) (e.g., processor 402) may perform a D2D search (e.g., local network search and / or BLE scan) to discover the offline IoT device (320) and verify ownership of the IoT device (320) to determine whether direct recovery for the IoT device (320) is possible. If it is determined that direct recovery for the IoT device (320) is not possible, the first electronic device (310) (e.g., processor 402) may proceed to step 1706. If it is determined that direct recovery for the IoT device (320) is possible, the first electronic device (310) (e.g., processor 402)) may proceed to step 1708.

[0205] At step 1706, the first electronic device (310) (e.g., the processor (402)) may transmit a message to the server (350) requesting automatic recovery of the offline state of the IoT device (320). In one embodiment, the server (350) may transmit a message to the second electronic device (330) instructing automatic recovery of the IoT device (320) based on receiving the message. The second electronic device (330) may discover the IoT device (320) through D2D search based on receiving the message and establish a D2D connection with the IoT device (320). The second electronic device (330) may transmit an automatic recovery command to the IoT device (320) through the D2D connection instructing it to perform a designated action (e.g., restart, reboot, or Wi-Fi update) to recover from the offline state. The second electronic device (330) can report the execution result of automatic recovery (e.g., recovery result) to the server (350).

[0206] In operation 1708, the first electronic device (310) (e.g., processor (402)) may discover the IoT device (320) through D2D search and establish a D2D connection with the IoT device (320). The first electronic device (310) (e.g., processor (402)) may transmit an auto-recovery command to the IoT device (320) through the D2D connection, instructing the IoT device (320) to perform a designated action (e.g., restart, reboot, or Wi-Fi update) to recover from an offline state. In one embodiment, after transmitting the auto-recovery command, the first electronic device (310) (e.g., processor (402)) may inquire of the server (350) whether the IoT device (320) has been normally connected to the server (350) (e.g., switched to an online state). The first electronic device (310) (e.g., processor (402)) may receive a response from the server (350) notifying that the IoT device (320) has been normally recovered. In operation 1710, the first electronic device (310) (e.g., processor (402)) may log (e.g., report to server (350)) the execution result of the automatic recovery (e.g., recovery result) based on the confirmation that the IoT device (320) has been recovered through the response.

[0207] FIG. 18 is a flowchart illustrating a procedure for performing automatic recovery from an offline state based on diagnostic data according to one embodiment of the present disclosure. Depending on the embodiments, at least one of the operations described below may be omitted, modified, or executed in a different order. In one embodiment, at least one of the operations described below may be executed by the processor (402) of the first electronic device (310). In one embodiment, at least one of the operations described below may be implemented as one or more instructions stored in the memory (406) of the first electronic device (310).

[0208] Referring to FIG. 18, in operation 1802, the first electronic device (310) (e.g., processor 402) may determine whether a recovery policy associated with the IoT device (320) has been updated. In one embodiment, the first electronic device (310) (e.g., processor 402) may check whether update information of the recovery policy is received from the server (350). If information indicating that the recovery policy is updated is received from the server (350), the first electronic device (310) (e.g., processor 402)) may proceed to operation 1804. In operation 1804, the first electronic device (310) (e.g., processor 402)) may receive the updated recovery policy from the server (350). On the other hand, if the recovery policy does not need to be updated, the first electronic device (310) (e.g., processor 402)) may proceed to operation 1806. In one embodiment, the recovery policy may include a recovery method corresponding to an offline cause (e.g., an error code) of the IoT device (320).

[0209] In operation 1806, the first electronic device (310) (e.g., processor 402) may obtain diagnostic data (e.g., first diagnostic data) related to the IoT device (320). In one embodiment, the first electronic device (310) (e.g., processor 402) may transmit a message requesting a user account or first diagnostic data related to the IoT device (320) to the server (350) and receive the first diagnostic data from the server (350). In one embodiment, the first diagnostic data may be collected by the second electronic device (330) and reported to the server (350). In one embodiment, the first electronic device (310) (e.g., processor 402) may transmit the message requesting the first diagnostic data to the server (350) based on identifying that the IoT device (320) is offline. In one embodiment, the server (350) may transmit the first diagnostic data to the first electronic device (310) based on identifying that the IoT device (320) has gone offline.

[0210] At operation 1808, the first electronic device (310) (e.g., processor (402)) may discover the IoT device (320) through D2D discovery and establish a D2D connection (e.g., Wi-Fi connection and / or BLE connection) with the IoT device (320). At operation 1810, the first electronic device (310) (e.g., processor (402)) may receive diagnostic data (e.g., second diagnostic data) related to an offline cause from the IoT device (320) through the D2D connection.

[0211] At operation 1812, the first electronic device (310) (e.g., processor 402) may determine whether the second diagnostic data is valid. In one embodiment, the first electronic device (310) (e.g., processor 402) may determine that the second diagnostic data is valid if the second error code included in the second diagnostic data is the same as the first error code included in the first diagnostic data. If the second diagnostic data is determined to be invalid, the first electronic device (310) (e.g., processor 402) may proceed to operation 1818 to log (e.g., store and report to the server (350)) the second diagnostic data. If the second diagnostic data is determined to be valid, the first electronic device (310) (e.g., processor 402) may proceed to operation 1814.

[0212] In operation 1814, the first electronic device (310) (e.g., processor 402) may analyze the diagnostic data to determine a recovery method for automatic recovery. The recovery method may include a designated operation for automatic recovery (e.g., restart, reboot, or Wi-Fi update). In operation 1816, the first electronic device (310) (e.g., processor 402) may perform automatic recovery for the IoT device (320) by transmitting an automatic recovery command to the IoT device (320) via the D2D connection, which instructs the IoT device to perform the designated operation. In one embodiment, after transmitting the automatic recovery command, the first electronic device (310) (e.g., processor 402) may inquire of the server (350) whether the IoT device (320) is normally connected to the server (350) (e.g., switched to an online state). The first electronic device (310) (e.g., processor (402)) may receive a response from the server (350) notifying that the IoT device (320) has been restored normally.

[0213] At operation 1818, the first electronic device (310) (e.g., processor (402)) may log (e.g., store and report to server (350)) second diagnostic data after transmitting the automatic recovery command.

[0214] FIGS. 19a, 19b, 19c, 19d, 19e, 19f, 19g, and 19h illustrate user interfaces (UIs) for restoring connection of an offline device according to one embodiment of the present disclosure.

[0215] Referring to FIG. 19A, the first electronic device (310) may display an offline notification UI (1902) through the display module (260) based on identifying that an IoT device (e.g., an air purifier) ​​is offline. In one embodiment, the first electronic device (310) may display the offline notification UI (1902) based on receiving information indicating that the IoT device is offline (e.g., a list of offline devices, or a list of registered devices including connection status information) from the server (350), or executing a client application after receiving the information. In one embodiment, the offline notification UI (1902) may include at least one of a device name of the IoT device that is offline, a device image, a phrase indicating the offline status (e.g., "Would you like to reconnect?"), or an input object for requesting reconnection (e.g., "Reconnect"). In one embodiment, the offline notification UI (1902) may be displayed through a pop-up message or a client application.

[0216] Referring to FIG. 19b, based on receiving a user input (e.g., a touch) for an input object in the offline notification UI (1902), the first electronic device (310) can display the connection UI (1904) of FIG. 19b through the display module (260). The first electronic device (310) can display the connection UI (1904) while discovering an IoT device through D2D search and establishing a D2D connection with the IoT device.

[0217] Referring to FIG. 19c, the first electronic device (310) may display a recovery UI (1906) after completing the establishment of a D2D connection with the IoT device. In one embodiment, the recovery UI (1906) may include an input object (e.g., “Run App”) for requesting execution of a client application for an IoT service.

[0218] Referring to FIG. 19D, based on receiving a user input (e.g., a touch) for an input object in the recovery UI (1906), the first electronic device (310) may execute a client application and display a connection recovery UI (1908) through the client application. The connection recovery UI (1908) may include a phrase (e.g., “connection recovery”) guiding that the connection of the IoT device is recovered. In one embodiment, while the first electronic device (310) displays the connection recovery UI (1908), the first electronic device (310) may transmit an automatic recovery command instructing the IoT device to perform a specified operation, and may execute operations in the background to determine whether the automatic recovery of the IoT device is successful through the server (350).

[0219] Referring to FIG. 19e, the first electronic device (310) may display a connection success UI (1910) through the display module (260) based on the successful automatic recovery of the IoT device. In one embodiment, the connection success UI (1910) may include a phrase notifying that a D2D connection with the IoT device has been established (e.g., “The device is connected”) and an input object for requesting execution of an offline diagnosis service (e.g., “Offline diagnosis”).

[0220] Referring to FIG. 19f, the first electronic device (310) may display a connection failure UI (1912) through the display module (260) based on the success of automatic recovery of the IoT device. In one embodiment, the connection failure UI (1912) may include a phrase notifying that the D2D connection with the IoT device has failed (e.g., “Connection cannot be recovered”) and an input object for requesting to retry the connection with the IoT device (e.g., “Run again”).

[0221] Referring to FIG. 19g, the first electronic device (310) may display an offline diagnosis UI (1914) through the display module (260) based on receiving a user input (e.g., a touch) for an input object in the connection success UI (1910). In one embodiment, the offline diagnosis UI (1914) may include status display objects corresponding to one or more IoT devices that support offline diagnosis. Each status display object may include information (e.g., a name and / or an image) of the corresponding IoT device, and an input object (e.g., “run”) for requesting execution of offline diagnosis. The first electronic device (310) may execute an offline diagnosis (e.g., analysis of diagnostic data) for the corresponding IoT device based on receiving a user input (e.g., a touch) for an input object in the offline diagnosis UI (1914).

[0222] Referring to FIG. 19h, the first electronic device (310) may display an offline device list UI (1916) through the display module (260) based on receiving a user input (e.g., a touch) to an input object in the connection success UI (1910). In one embodiment, the offline device list UI (1916) may include information (e.g., a name and / or an image) of each of one or more IoT devices that are offline, and an input object (e.g., “run diagnosis”) for requesting to perform offline diagnosis on one or more IoT devices in batches. The first electronic device (310) may perform offline diagnosis (e.g., analysis of diagnosis data) on one or more IoT devices based on receiving a user input (e.g., a touch) to an input object in the offline device list UI (1916).

[0223] FIGS. 20A and 20B illustrate user interfaces (UIs) for restoring connection to an offline device based on a user notification according to one embodiment of the present disclosure.

[0224] Referring to FIG. 20A, the first electronic device (310) may display an offline notification UI (2002) through the display module (260) based on identifying that an IoT device (e.g., an air purifier) ​​is offline. In one embodiment, the first electronic device (310) may display the offline notification UI (2002) based on receiving information indicating that the IoT device is offline from the server (350) (e.g., a list of offline devices or a list of registered devices including connection status information). In one embodiment, the offline notification UI (2002) may be displayed through a pop-up message.

[0225] Referring to FIG. 20B, the first electronic device (310) may display an offline diagnosis UI (2004) through the display module (260) based on receiving a user input (e.g., a touch) for the offline notification UI (2002). In one embodiment, the offline diagnosis UI (2004) may include information (e.g., a name and / or an image) of each IoT device that is offline, and a diagnosis progress object. Each diagnosis object may include an input object (e.g., “run”) for requesting to run an offline diagnosis, or a status object indicating that an offline diagnosis is being run.

[0226] According to embodiments of the present disclosure, the first electronic device (310) can automatically perform background recovery of an offline IoT device without user intervention. Accordingly, the first electronic device (310) can omit the time required to analyze diagnostic data through an offline diagnostic service (e.g., the time required to display the analysis screen (730) of FIG. 7C ) and reduce the time required to connect to the IoT device and perform diagnostics.

[0227] FIGS. 21A and 21B illustrate user interfaces (UIs) for setting up automatic recovery of an IoT device according to one embodiment of the present disclosure.

[0228] Referring to FIG. 21a, the first electronic device (310) can recover the offline state of the IoT device through an offline diagnostic service and then display the diagnostic result UI (2102).

[0229] Referring to FIG. 21B, upon receiving a user input (e.g., a touch) for the diagnostic result UI (2102), the first electronic device (310) may display an auto-recoverable device list UI (2102) through the display module (260) to allow auto-recovery of the IoT device. In one embodiment, the first electronic device (310) may allow the second electronic device (330) to perform auto-recovery of the IoT device through the auto-recoverable device list UI (2102).

[0230] An electronic device (330) according to one embodiment of the present disclosure may include a communication circuit (414), at least one processor (412) including a processing circuit, and a memory (416) storing instructions. The instructions, when individually or collectively executed by the at least one processor, may cause the electronic device to establish a device-to-device (D2D) connection with an Internet over things (IoT) device (320) through the communication circuit based on identifying that the IoT device is in an offline state where the IoT device is disconnected from a server (350). The instructions, when individually or collectively executed by the at least one processor, may cause the electronic device to receive diagnostic data including an error code related to the offline state from the IoT device through the D2D connection. The instructions, when individually or collectively executed by the at least one processor, may cause the electronic device to determine whether automatic recovery of the offline state by the IoT device is possible based on the diagnostic data and a recovery policy associated with the IoT device. The recovery policy may include information indicating whether automatic recovery by the IoT device is possible for the error code. The instructions, when individually or collectively executed by the at least one processor, may cause the electronic device to transmit an automatic recovery command determined based on the recovery policy to the IoT device via the D2D connection based on whether the automatic recovery is possible. The instructions, when individually or collectively executed by the at least one processor, may cause the electronic device to transmit the diagnostic data of the IoT device to the server via the communication circuit if the automatic recovery is not possible.

[0231] In one embodiment, the instructions may cause the electronic device to receive a list of offline devices from the server, including at least one device that has lost connection with the server among devices registered with the server for an IoT service, and to identify that the IoT device is offline based on identifying that the IoT device is included in the list of offline devices.

[0232] In one embodiment, the instructions may cause the electronic device to receive information regarding the recovery policy from the server. In one embodiment, the recovery policy may include at least one of one or more error codes associated with the IoT device, an offline cause corresponding to each error code, information indicating whether automatic recovery is possible for each error code, or a recovery method corresponding to each error code. In one embodiment, the information regarding the recovery policy may be updated according to a cumulative recovery success rate for each error code associated with the IoT device.

[0233] In one embodiment, the auto-recovery command may be configured to instruct at least one of a restart, reboot, or Wi-Fi update of the IoT device.

[0234] In one embodiment, the electronic device may be a stationary device located within a local network where the IoT device is located.

[0235] In one embodiment, the instructions may cause the electronic device to discover the IoT device through D2D search and establish the D2D connection with the discovered IoT device based on identifying that the IoT device is in the offline state.

[0236] In one embodiment, the D2D search may include at least one of multicast domain name service (mDNS) service discovery (SD), DNS service discovery (SD), simple service discovery protocol (SSDP) discovery, universal plug and play (UPNP) discovery, or Bluetooth low energy (BLE) scan.

[0237] An electronic device (310) according to one embodiment of the present disclosure may include a communication circuit (404), at least one processor (402) including a processing circuit, and a memory (406) storing instructions. The instructions, when individually or collectively executed by the at least one processor, may cause the electronic device to receive first diagnostic data including connection status information indicating that an Internet over Things (IoT) device (320) is in an offline state and a first error code associated with the offline state. The first diagnostic data may be collected by an external electronic device (330) located in the same local network as the IoT device and reported to the server. The instructions, when individually or collectively executed by the at least one processor, may cause the electronic device to establish a device-to-device (D2D) connection with the IoT device through the communication circuit based on identifying that the IoT device is in an offline state. The instructions, when individually or collectively executed by the at least one processor, may cause the electronic device to receive second diagnostic data from the IoT device via the D2D connection, the second diagnostic data including a second error code associated with the offline state. The instructions, when individually or collectively executed by the at least one processor, may cause the electronic device to determine an automatic recovery command for recovering the offline state of the IoT device based on the second diagnostic data and a recovery policy associated with the IoT device, based on identifying that the first error code and the second error code are identical.The instructions, when individually or collectively executed by the at least one processor, may cause the electronic device to transmit the automatic recovery command to the IoT device via the D2D connection. The instructions, when individually or collectively executed by the at least one processor, may cause the electronic device to transmit the second diagnostic data to the server via the communication circuit based on identifying that the first error code and the second error code are not identical.

[0238] In one embodiment, the instructions may cause the electronic device to receive information regarding the recovery policy from the server. In one embodiment, the recovery policy may include at least one of one or more error codes associated with the IoT device, an offline cause corresponding to each error code, information indicating whether automatic recovery is possible for each error code, or a recovery method corresponding to each error code. In one embodiment, the information regarding the recovery policy may be updated according to a cumulative recovery success rate for each error code associated with the IoT device.

[0239] In one embodiment, the auto-recovery command may be configured to instruct at least one of a restart, reboot, or Wi-Fi update of the IoT device.

[0240] According to one embodiment of the present disclosure, a non-transitory computer-readable storage medium storing one or more programs may include instructions that, when individually or collectively executed by at least one processor of an electronic device (330), cause the electronic device to: establish a device-to-device (D2D) connection with an IoT (internet over things) device (320) based on identifying that the IoT device is in an offline state where the connection with a server (350) has been lost; receive diagnostic data including an error code related to the offline state from the IoT device through the D2D connection; determine whether automatic recovery of the offline state by the IoT device is possible based on the diagnostic data and a recovery policy related to the IoT device; the recovery policy includes information indicating whether automatic recovery by the IoT device is possible for the error code; transmit an automatic recovery command determined based on the recovery policy to the IoT device through the D2D connection based on the possibility of the automatic recovery; and transmit the diagnostic data of the IoT device to the server through the communication circuit if the automatic recovery is not possible.

[0241] In one embodiment, the instructions may cause the electronic device to receive a list of offline devices from the server, including at least one device that has lost connection with the server among devices registered with the server for an IoT service, and to identify that the IoT device is offline based on identifying that the IoT device is included in the list of offline devices.

[0242] In one embodiment, the instructions may cause the electronic device to receive information regarding the recovery policy from the server. In one embodiment, the recovery policy may include at least one of one or more error codes associated with the IoT device, an offline cause corresponding to each error code, information indicating whether automatic recovery is possible for each error code, or a recovery method corresponding to each error code. In one embodiment, the information regarding the recovery policy may be updated according to a cumulative recovery success rate for each error code associated with the IoT device.

[0243] In one embodiment, the auto-recovery command may be configured to instruct at least one of a restart, reboot, or Wi-Fi update of the IoT device.

[0244] In one embodiment, the electronic device may be a stationary device located within a local network where the IoT device is located.

[0245] In one embodiment, the instructions may cause the electronic device to discover the IoT device through D2D discovery and establish the D2D connection with the discovered IoT device based on identifying that the IoT device is in the offline state.

[0246] In one embodiment, the D2D search may include at least one of mDNS service discovery, DNS service discovery (SD), SSDP discovery, UPNP discovery, or BLE scan.

[0247] According to one embodiment of the present disclosure, a non-transitory computer-readable storage medium storing one or more programs, wherein the one or more programs, when individually or collectively executed by at least one processor of an electronic device (310), cause the electronic device to: receive, from a server (350), first diagnostic data including connection status information indicating that an IoT (internet over things) device (320) is in an offline state and a first error code related to the offline state, wherein the first diagnostic data is collected by an external electronic device (330) located in the same local network as the IoT device and reported to the server, establish a device-to-device (D2D) connection with the IoT device based on identifying that the IoT device is in the offline state, receive second diagnostic data including a second error code related to the offline state from the IoT device through the D2D connection, determine an automatic recovery command for recovering the offline state of the IoT device based on the second diagnostic data and a recovery policy related to the IoT device based on identifying that the first error code and the second error code are the same, and execute the automatic recovery command. It may include instructions for transmitting the second diagnostic data to the IoT device via a D2D connection and, based on identifying that the first error code and the second error code are not the same, transmitting the second diagnostic data to the server.

[0248] Electronic devices according to the various embodiments disclosed in this document may take various forms. Electronic devices may include, for example, portable communication devices (e.g., smartphones), computer devices, portable multimedia devices, portable medical devices, cameras, wearable devices, or home appliances. Electronic devices according to the embodiments of this document are not limited to the aforementioned devices.

[0249] The various embodiments of this document and the terminology used therein are not intended to limit the technical features described in this document to specific embodiments, but should be understood to include various modifications, equivalents, or substitutes of the embodiments. In connection with the description of the drawings, similar reference numerals may be used for similar or related components. The singular form of a noun corresponding to an item may include one or more of the items, unless the context clearly indicates otherwise. In this document, each of the phrases "A or B", "at least one of A and B", "at least one of A or B", "A, B, or C", "at least one of A, B, and C", and "at least one of A, B, or C" can include any one of the items listed together in the corresponding phrase among those phrases, or all possible combinations thereof. Terms such as "first," "second," or "first" or "second" may be used merely to distinguish one component from another, and do not limit the components in any other respect (e.g., importance or order). When a component (e.g., a first component) is referred to as "coupled" or "connected" to another (e.g., a second component), with or without the terms "functionally" or "communicatively," it means that the component can be connected to the other component directly (e.g., wired), wirelessly, or through a third component.

[0250] The term "module" used in various embodiments of this document may include a unit implemented in hardware, software, or firmware, and may be used interchangeably with terms such as logic, logic block, component, or circuit. A module may be an integral component, or a minimum unit or part of such a component that performs one or more functions. For example, according to one embodiment, a module may be implemented in the form of an application-specific integrated circuit (ASIC).

[0251] Various embodiments of the present document may be implemented as software (e.g., a program (240)) including one or more instructions stored in a storage medium (e.g., an internal memory (236) or an external memory (238)) readable by a machine (e.g., an electronic device (201)). For example, a processor (e.g., a processor (220)) of the machine (e.g., an electronic device (201)) may call at least one instruction among the one or more instructions stored from the storage medium and execute it. This enables the machine to operate to perform at least one function according to the at least one called instruction. The one or more instructions may include code generated by a compiler or code executable by an interpreter. The machine-readable storage medium may be provided in the form of a non-transitory storage medium. Here, 'non-transitory' simply means that the storage medium is a tangible device and does not contain signals (e.g., electromagnetic waves), and the term does not distinguish between cases where data is stored semi-permanently or temporarily on the storage medium.

[0252] According to one embodiment, the method according to various embodiments disclosed in this document may be provided as a computer program product. The computer program product may be traded between sellers and buyers as a product. The computer program product may be distributed in the form of a device-readable storage medium (e.g., compact disc read-only memory (CD-ROM)) or may be provided through an application store (e.g., Play Store). TM ) or directly between two user devices (e.g., smart phones), online distribution (e.g., downloading or uploading). In the case of online distribution, at least a portion of the computer program product may be at least temporarily stored or temporarily created in a machine-readable storage medium, such as the memory of a manufacturer's server, an application store's server, or an intermediary server.

[0253] According to various embodiments, each component (e.g., a module or a program) of the above-described components may include one or more entities, and some of the entities may be separated and placed in other components. According to various embodiments, one or more components or operations of the aforementioned components may be omitted, or one or more other components or operations may be added. Alternatively or additionally, a plurality of components (e.g., a module or a program) may be integrated into a single component. In such a case, the integrated component may perform one or more functions of each of the plurality of components identically or similarly to those performed by the corresponding component among the plurality of components prior to the integration. According to various embodiments, the operations performed by a module, program, or other component may be executed sequentially, in parallel, iteratively, or heuristically, or one or more of the operations may be executed in a different order, omitted, or one or more other operations may be added.

Claims

1. In an electronic device (330), Communication circuit (414); At least one processor (412) comprising a processing circuit; and A memory (416) for storing instructions, wherein the instructions, when individually or collectively executed by the at least one processor, cause the electronic device to: Based on identifying that the IoT (internet over things) device (320) is offline and disconnected from the server (350), a D2D (device-to-device) connection is established with the IoT device through the communication circuit, Receive diagnostic data including an error code related to the offline status from the IoT device through the D2D connection, Based on the above diagnostic data and a recovery policy related to the IoT device, it is determined whether automatic recovery from the offline state by the IoT device is possible, and the recovery policy includes information indicating whether automatic recovery by the IoT device is possible for the error code. Based on the possibility of the above automatic recovery, an automatic recovery command determined based on the above recovery policy is transmitted to the IoT device through the D2D connection, An electronic device that transmits the diagnostic data of the IoT device to the server via the communication circuit when the automatic recovery is not possible.

2. In the first paragraph, the instructions, when individually or collectively executed by the at least one processor, cause the electronic device to: Receive a list of offline devices including at least one device that has lost connection with the server among the devices registered to the server for IoT service from the server; An electronic device that identifies that the IoT device is offline based on identifying that the IoT device is included in the list of offline devices.

3. In the first or second paragraph, the instructions, when individually or collectively executed by the at least one processor, cause the electronic device to receive information on the recovery policy from the server, The above recovery policy includes at least one of one or more error codes related to the IoT device, an offline cause corresponding to each error code, information indicating whether automatic recovery is possible for each error code, or a recovery method corresponding to each error code. Information of the above recovery policy is an electronic device that is updated according to the cumulative recovery success rate by error code related to the IoT device.

4. In any one of paragraphs 1 to 3, the automatic recovery command, An electronic device configured to instruct at least one of a restart, reboot, or Wi-Fi update of the IoT device.

5. In any one of paragraphs 1 to 4, the electronic device, An electronic device that is a fixed device located within a local network where the IoT device is located.

6. In any one of paragraphs 1 to 5, the instructions, when individually or collectively executed by the at least one processor, cause the electronic device to: Based on identifying that the IoT device is in the offline state, the IoT device is discovered through D2D search, An electronic device that establishes the D2D connection with the discovered IoT device.

7. In paragraph 6, the D2D search, An electronic device including at least one of mDNS (multicast domain name service) service discovery, DNS service discovery (SD), SSDP (simple service discovery protocol) discovery, UPNP (universal plug and play) discovery, or BLE (Bluetooth low energy) scanning.

8. In the electronic device (310), Communication circuit (404); and At least one processor (402) comprising a processing circuit; and A memory (406) for storing instructions, wherein the instructions, when individually or collectively executed by the at least one processor, cause the electronic device to: The IoT (internet over things) device (320) receives first diagnostic data including connection status information indicating that the device is offline and a first error code related to the offline status from the server (350) through the communication circuit, and the first diagnostic data is collected by an external electronic device (330) located in the same local network as the IoT device and reported to the server. Establishing a D2D (device-to-device) connection with the IoT device through the communication circuit based on identifying that the IoT device is offline, Receive second diagnostic data including a second error code related to the offline state from the IoT device through the D2D connection, Based on identifying that the first error code and the second error code are the same, an automatic recovery command for recovering the offline state of the IoT device is determined based on the second diagnostic data and a recovery policy related to the IoT device, Transmitting the above automatic recovery command to the IoT device via the D2D connection, An electronic device that transmits the second diagnostic data to the server through the communication circuit based on identifying that the first error code and the second error code are not the same.

9. In the 8th paragraph, the instructions, when individually or collectively executed by the at least one processor, cause the electronic device to receive information of the recovery policy from the server, The above recovery policy includes at least one of one or more error codes related to the IoT device, an offline cause corresponding to each error code, information indicating whether automatic recovery is possible for each error code, or a recovery method corresponding to each error code. Information of the above recovery policy is an electronic device that is updated according to the cumulative recovery success rate by error code related to the IoT device.

10. In paragraph 8 or 9, the automatic recovery command, An electronic device configured to instruct at least one of a restart, reboot, or Wi-Fi update of the IoT device.

11. In a non-transitory computer-readable storage medium storing one or more programs, the one or more programs, when individually or collectively executed by at least one processor of an electronic device (330), cause the electronic device to: Based on identifying that the IoT (internet over things) device (320) is offline and disconnected from the server (350), a D2D (device-to-device) connection is established with the IoT device, Receive diagnostic data including an error code related to the offline status from the IoT device through the D2D connection, Based on the above diagnostic data and a recovery policy related to the IoT device, it is determined whether automatic recovery from the offline state by the IoT device is possible, and the recovery policy includes information indicating whether automatic recovery by the IoT device is possible for the error code. Based on the possibility of the above automatic recovery, an automatic recovery command determined based on the above recovery policy is transmitted to the IoT device through the D2D connection, A storage medium including instructions for transmitting the diagnostic data of the IoT device to the server when the automatic recovery is not possible.

12. In the 11th paragraph, the instructions, when individually or collectively executed by the at least one processor, cause the electronic device to: Receive a list of offline devices including at least one device that has lost connection with the server among the devices registered to the server for IoT service from the server; A storage medium that identifies that the IoT device is offline based on identifying that the IoT device is included in the list of offline devices.

13. In the 11th or 12th paragraph, the instructions, when individually or collectively executed by the at least one processor, cause the electronic device to receive information of the recovery policy from the server, The above recovery policy includes at least one of one or more error codes related to the IoT device, an offline cause corresponding to each error code, information indicating whether automatic recovery is possible for each error code, or a recovery method corresponding to each error code. Information of the above recovery policy is a storage medium updated according to the cumulative recovery success rate by error code related to the IoT device.

14. In a non-transitory computer-readable storage medium storing one or more programs, the one or more programs, when individually or collectively executed by at least one processor of an electronic device (310), cause the electronic device to: Receives from a server (350) first diagnostic data including connection status information indicating that an IoT (internet over things) device (320) is offline and a first error code related to the offline status, wherein the first diagnostic data is collected by an external electronic device (330) located in the same local network as the IoT device and reported to the server, Establishing a D2D (device-to-device) connection with the IoT device based on identifying that the IoT device is in the offline state; Receive second diagnostic data including a second error code related to the offline state from the IoT device through the D2D connection, Based on the identification that the first error code and the second error code are the same, an automatic recovery command for recovering the offline state of the IoT device is determined based on the second diagnostic data and a recovery policy related to the IoT device, Transmitting the above automatic recovery command to the IoT device via the D2D connection, A storage medium including instructions for transmitting the second diagnostic data to the server based on identifying that the first error code and the second error code are not the same.

15. In the 14th paragraph, the instructions, when individually or collectively executed by the at least one processor, cause the electronic device to receive information of the recovery policy from the server, The above recovery policy includes at least one of one or more error codes related to the IoT device, an offline cause corresponding to each error code, information indicating whether automatic recovery is possible for each error code, or a recovery method corresponding to each error code. Information of the above recovery policy is a storage medium updated according to the cumulative recovery success rate by error code related to the IoT device.

Images