Method and apparatus for performing automatic firmware update of wearable device

Abstract

An operation method of a first server for performing automatic firmware update of a smart all-in-one cardiac patch may comprise the steps of: generating a security firmware code for controlling the operation of a plurality of smart all-in-one cardiac patches and transmitting the security firmware code to a second server; transmitting unique number information of a first smart all-in-one cardiac patch to the second server; transmitting an open firmware code related to the plurality of smart all-in-one cardiac patches to the second server; transmitting information related to the first smart all-in-one cardiac patch to the second server; and obtaining validity verification result information from the second server.

Description

Method and device for automating firmware updates of wearable devices

[0001] The present invention relates to a method and apparatus for performing automated firmware updates on a wearable device. Specifically, the present invention relates to a method and apparatus for performing automated firmware updates on a wearable device programmed through a software development kit (SDK).

[0002]

[0003] The use of wearable devices has been increasing recently, and their technology is continuously evolving as they relate to healthcare. Furthermore, the growing aging population is fueling the need for wearable device utilization, leading to active development of wearable device technology.

[0004] Wearable devices are being developed in a variety of forms, from wearable devices like smartwatches to devices attached to the body. Developing a wearable device requires consideration of both hardware and software aspects. Software can be programmed using an SDK, based on the developed hardware, to perform the unique functions of the wearable device.

[0005] However, when wearable devices are developed using an SDK, the unique source code of the wearable device is disclosed to the manufacturer, and since each wearable device must be verified, mass production may be limited. Considering the aforementioned issues, the following describes a method for mass producing wearable devices based on an SDK and performing automated firmware updates.

[0006]

[0007] The present specification may provide a method for automating firmware updates of a wearable device.

[0008] The present specification may provide a method for automating firmware updates of a smart all-in-one patch.

[0009] The present specification may provide a method for transmitting secure firmware code and open firmware code by distinguishing between them.

[0010] The present specification may provide a method for performing automated firmware updates of multiple wearable devices.

[0011]

[0012] According to one embodiment of the present specification, a method for operating a first server for performing automated firmware update of a smart all-in-one heart patch may include the steps of generating a secure firmware code for controlling the operation of a plurality of smart all-in-one heart patches and transmitting the generated secure firmware code to a second server, transmitting unique number information of the first smart all-in-one heart patches to the second server, transmitting open firmware codes related to the plurality of smart all-in-one heart patches to the second server, transmitting information related to the first smart all-in-one heart patch to the second server, and obtaining validation result information from the second server. Here, a mixed code is generated based on the secure firmware code, the unique number information of the first smart all-in-one heart patch, and the open firmware code, and code validation of the first smart all-in-one heart patch is performed, and when sensor validation of the first smart all-in-one heart patch is performed through the information related to the first smart all-in-one heart patch based on the code validity of the first smart all-in-one heart patch, the firmware update of the first smart all-in-one heart patch is completed, and the validation result may be transmitted from the second server to the first server.

[0013] In addition, according to one embodiment of the present specification, in a first server that performs automation of firmware update of a smart all-in-one heart patch, a memory, a transceiver, and a processor that controls the memory and the transmitter, the processor generates a security firmware code that controls the operation of a plurality of smart all-in-one heart patches and transmits the security firmware code to a second server, transmits unique number information of the first smart all-in-one heart patch to the second server, transmits open firmware codes related to the plurality of smart all-in-one heart patches to the second server, transmits information related to the first smart all-in-one heart patch to the second server, and obtains validation result information from the second server, wherein a mixed code is generated based on the security firmware code, the unique number information of the first smart all-in-one heart patch, and the open firmware code, and code validation of the first smart all-in-one heart patch is performed, and when sensor validation of the first smart all-in-one heart patch is performed through the information related to the first smart all-in-one heart patch based on the code validity of the first smart all-in-one heart patch, the firmware update of the first smart all-in-one heart patch is completed, and the validation result is transmitted from the second server to the first server. Can be.

[0014] Additionally, the following may be commonly applied:

[0015] According to one embodiment of the present specification, the information related to the first smart all-in-one heart patch may include product information, logging information, and a sensor validation code of the first smart all-in-one heart patch.

[0016] In addition, according to one embodiment of the present specification, when the first server obtains the validation result of the first smart all-in-one heart patch, the first server verifies the second smart all-in-one heart patch as the next smart all-in-one heart patch, and transmits the unique number information of the second smart all-in-one heart patch to the second server, wherein the second server can perform code validation of the second smart all-in-one heart patch through the security firmware code, the unique number information of the second smart all-in-one heart patch, and the open firmware code.

[0017] Additionally, according to one embodiment of the present specification, the first server transmits information related to the second smart all-in-one heart patch to the second server, and when sensor validation of the second smart all-in-one heart patch is performed through the information related to the second smart all-in-one heart patch based on the code validity of the second smart all-in-one heart patch, the firmware update of the second smart all-in-one heart patch is completed, and the validation result can be received from the second server.

[0018] Additionally, according to one embodiment of the present specification, the first server may sequentially provide a plurality of pieces of smart all-in-one patch information to the second server based on the validation results.

[0019] Additionally, according to one embodiment of the present specification, firmware updates may be performed through the MCU's (micro controller unit) application layer, library / security layer, RTOS (Real-Time Operating System) / stack / middle driver layer, connection protocol layer, and configuration board layer based on a software development kit (SDK).

[0020] Additionally, according to one embodiment of the present specification, code validation may be performed in the MCU's application layer, and sensor validation may be performed in the configuration board layer.

[0021] Additionally, according to one embodiment of the present specification, the security firmware code may be a code including information for controlling a heart-related signal sensing operation in a smart all-in-one patch, and the sensor validation code may be a code including information for controlling the operation of at least one sensor and an integrated circuit (IC) chip configured in the smart all-in-one patch.

[0022]

[0023] The present specification has the effect of providing a method for automating firmware updates of a wearable device.

[0024] The present specification has the effect of providing a method for automating firmware updates of a smart all-in-one patch.

[0025] This specification has the effect of providing a method for transmitting secure firmware code and open firmware code by distinguishing between them.

[0026] The present specification has the effect of providing a method for performing automated firmware updates of a plurality of wearable devices.

[0027] The problem to be solved by this specification is not limited to what has been described above, and can be expanded to various matters that can be derived from the embodiments of the invention described below.

[0028]

[0029] FIG. 1 is a diagram illustrating an example of an operating environment of a system according to one embodiment of the present specification.

[0030] FIG. 2 is a block diagram for explaining the internal configuration of a computing device (200) in one embodiment of the present specification.

[0031] FIG. 3 is a diagram illustrating a smart all-in-one cardiac patch device and multiple user devices according to one embodiment of the present disclosure.

[0032] FIG. 4 is a diagram illustrating a smart all-in-one cardiac patch system according to one embodiment of the present disclosure.

[0033] FIG. 5 is a diagram illustrating the structure of a smart all-in-one cardiac patch according to one embodiment of the present specification.

[0034] FIG. 6 is a diagram illustrating a layer structure within a device according to one embodiment of the present specification.

[0035] FIG. 7 is a diagram showing the relationship between a first server, a second server, and a wearable device according to one embodiment of the present specification.

[0036] FIGS. 8 and 9 are diagrams showing each layer within the SDK according to one embodiment of the present specification.

[0037] FIG. 10 is a diagram illustrating a method for transmitting secure firmware code and open firmware code according to one embodiment of the present specification.

[0038] FIG. 11 is a diagram illustrating a method for performing automated firmware updates according to one embodiment of the present specification.

[0039] FIG. 12 is a diagram illustrating a mixed code according to one embodiment of the present specification.

[0040] FIG. 13 is a flowchart illustrating a method for performing firmware update automation according to one embodiment of the present specification.

[0041]

[0042] In describing the embodiments of this specification, if a detailed description of a known configuration or function is judged to obscure the gist of the embodiments of this specification, a detailed description thereof will be omitted. In addition, parts of the drawings that are not related to the description of the embodiments of this specification have been omitted, and similar parts have been designated with similar drawing reference numerals.

[0043] In the embodiments of this specification, when a component is said to be "connected," "coupled," or "connected" to another component, this may include not only a direct connection, but also an indirect connection in which another component exists in between. Furthermore, when a component is said to "include" or "have" another component, unless otherwise specifically stated, this does not exclude the other component, but rather implies that the other component may be included.

[0044] In the embodiments of this specification, the terms first, second, etc. are used only for the purpose of distinguishing one component from another component, and do not limit the order or importance between components unless specifically stated otherwise. Therefore, within the scope of the embodiments of this specification, a first component in an embodiment may be referred to as a second component in another embodiment, and similarly, a second component in an embodiment may be referred to as a first component in another embodiment.

[0045] In the embodiments of this specification, distinct components are used to clearly illustrate their respective characteristics and do not necessarily imply separation. That is, multiple components may be integrated into a single hardware or software unit, or a single component may be distributed into multiple hardware or software units. Therefore, even if not specifically mentioned, such integrated or distributed embodiments are also included within the scope of the embodiments of this specification.

[0046] In this specification, the term "network" may encompass both wired and wireless networks. In this case, the term "network" may refer to a communications network that enables data exchange between devices, systems, and devices, and is not limited to a specific network.

[0047] Embodiments described herein may be entirely hardware, partially hardware and partially software, or entirely software. As used herein, "unit," "device," or "system" refers to a computer-related entity such as hardware, a combination of hardware and software, or software. For example, a unit, module, device, or system as used herein may be, but is not limited to, a running process, a processor, an object, an executable, a thread of execution, a program, and / or a computer. For example, both an application running on a computer and the computer itself may correspond to a unit, module, device, or system as used herein.

[0048] Additionally, in this specification, a device may be a mobile device such as a smartphone, tablet PC, wearable device, or HMD (Head Mounted Display), as well as a fixed device such as a PC or home appliance with display functions. Furthermore, as an example, a device may be an in-vehicle cluster or an IoT (Internet of Things) device. In other words, in this specification, a device may refer to any device capable of operating an application, and is not limited to a specific type. For convenience of explanation, the device on which an application operates is referred to as a device below.

[0049] In this specification, the network communication method is not limited, and connections between each component may not be made using the same network method. The network may include not only communication methods utilizing communication networks (e.g., mobile communication networks, wired Internet, wireless Internet, broadcasting networks, satellite networks, etc.), but also short-range wireless communication between devices. For example, the network may include all communication methods that enable objects to network with each other, and is not limited to wired communication, wireless communication, 3G, 4G, 5G, or other methods. For example, wired and / or networks include Local Area Network (LAN), Metropolitan Area Network (MAN), Global System for Mobile Network (GSM), Enhanced Data GSM Environment (EDGE), High Speed ​​Downlink Packet Access (HSDPA), Wideband Code Division Multiple Access (W-CDMA), Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Bluetooth, Zigbee, Wi-Fi, VoIP (Voice over Internet Protocol), LTE Advanced, IEEE802.16m, WirelessMAN-Advanced, HSPA+, 3GPP Long Term Evolution (LTE), Mobile WiMAX (IEEE 802.16e), UMB (formerly EV-DO Rev. C), Flash-OFDM, iBurst and MBWA (IEEE 802.20) It may refer to a communication network using one or more communication methods selected from the group consisting of systems, HIPERMAN, Beam-Division Multiple Access (BDMA), Wi-MAX (World Interoperability for Microwave Access), and ultrasonic communication, but is not limited thereto.

[0050] The components described in various embodiments are not necessarily essential components, and some may be optional. Therefore, embodiments comprising a subset of the components described in the embodiments are also included within the scope of the embodiments of the present disclosure. Furthermore, embodiments including other components in addition to the components described in various embodiments are also included within the scope of the embodiments of the present disclosure.

[0051] Hereinafter, embodiments of the present specification will be described in detail with reference to the drawings.

[0052] FIG. 1 is a diagram illustrating an example of the operating environment of a system according to one embodiment of the present specification. Referring to FIG. 1, one or more user devices (110-1, 110-2) and one or more servers (120, 130, 140) are connected via a network (1). FIG. 1 is merely an example for explaining the invention, and the number of user devices or servers is not limited to that shown in FIG. 1.

[0053] One or more user devices (110-1, 110-2) may be fixed or mobile terminals implemented as a computer system. The one or more user devices (110-1, 110-2) may be, for example, a smart phone, a mobile phone, a navigation device, a computer, a laptop, a digital broadcasting terminal, a PDA (Personal Digital Assistants), a PMP (Portable Multimedia Player), a tablet PC, a game console, a wearable device, an IoT (Internet of Things) device, a VR (Virtual Reality) device, an AR (Augmented Reality) device, etc. For example, in the embodiments, the user device (110) may mean one of various physical computer systems that can communicate with other servers (120 to 140) through a network (1) using a wireless or wired communication method.

[0054] Each server may be implemented as a computer device or multiple computer devices that communicate with one or more user devices (110-1, 110-2) via a network (1) to provide commands, codes, files, contents, services, etc. For example, the server may be a system that provides each service to one or more user devices (110-1, 110-2) connected via the network (1). As a more specific example, the server may be a computer program that is installed and run on one or more user devices (110-1, 110-2), and may provide a service (e.g., provision of information, etc.) intended by the application to one or more user devices (110-1, 110-2). As another example, the server may distribute a file for installing and running the above-described application to one or more user devices (110-1, 110-2) and receive user input information to provide a corresponding service.

[0055] FIG. 2 is a block diagram illustrating the internal configuration of a computing device (200) according to one embodiment of the present specification. This computing device (200) may be applied to one or more user devices (110-1, 110-2) or servers (120-140) described above with reference to FIG. 1, and each device and server may have the same or similar internal configuration by adding or excluding some components.

[0056] Referring to FIG. 2, a computing device (200) may include a memory (210), a processor (220), a communication module (230), and a transceiver (240). The memory (210) is a non-transitory computer-readable recording medium and may include a non-permanent mass storage device such as a random access memory (RAM), a read only memory (ROM), a disk drive, a solid state drive (SSD), a flash memory, etc. Here, the non-permanent mass storage device such as a ROM, an SSD, a flash memory, a disk drive, etc. may be included in the above-described device or server as a separate permanent storage device distinct from the memory (210). In addition, the memory (210) may store an operating system and at least one program code (for example, a browser installed and operated on a user device (110), or a code for an application installed on a user device (110) to provide a specific service). These software components may be loaded from a computer-readable recording medium separate from the memory (210). This separate computer-readable recording medium may include a computer-readable recording medium such as a floppy drive, a disk, a tape, a DVD / CD-ROM drive, a memory card, etc.

[0057] In another embodiment, the software components may be loaded into the memory (210) via a communication module (230) rather than a computer-readable recording medium. For example, at least one program may be loaded into the memory (210) based on a computer program (e.g., the application described above) that is installed by files provided by developers or a file distribution system (e.g., the server described above) that distributes the installation files of the application via a network (1).

[0058] The processor (220) may be configured to process instructions of a computer program by performing basic arithmetic, logic, and input / output operations. Instructions may be provided to the processor (220) by the memory (210) or the communication module (230). For example, the processor (220) may be configured to execute instructions received according to program code stored in a storage device such as the memory (210).

[0059] The communication module (230) can provide a function for the user device (110) and the server (120 - 140) to communicate with each other via the network (1), and can provide a function for each of the device (110) and / or the server (120 - 140) to communicate with other electronic devices.

[0060] The transceiver (240) may be a means for interfacing with an external input / output device (not shown). For example, external input devices may include devices such as a keyboard, mouse, microphone, camera, etc., and external output devices may include devices such as a display, speaker, haptic feedback device, etc. As another example, the transceiver (240) may be a means for interfacing with a device that integrates input and output functions, such as a touchscreen.

[0061] In addition, in other embodiments, the computing device (200) may include more components than the components of FIG. 2 depending on the nature of the device to which it is applied. For example, when the computing device (200) is applied to a user device (110), it may be implemented to include at least some of the above-described input / output devices, or may further include other components such as a transceiver, a Global Positioning System (GPS) module, a camera, various sensors, a database, etc. As a more specific example, when the user device is a smartphone, it may be implemented to further include various components that are generally included in a smartphone, such as an acceleration sensor or a gyro sensor, a camera module, various physical buttons, buttons using a touch panel, input / output ports, and a vibrator for vibration.

[0062] As an example, the following describes a wearable device that performs automated firmware updates. The wearable device may be a smartwatch, a smart ring, or any other type of accessory that can be worn by a user. As another example, the wearable device may be an attachment type that is attached to the human body and senses signals. Attached wearable devices may be attached to the upper body, lower body, shoulder, wrist, or other locations, and may be devices that sense signals generated from the human body through sensors. Furthermore, the wearable device may take other forms and may not be limited to a specific form.

[0063] Here, as an example, a smart all-in-one cardiac patch can be considered as a specific form of wearable device. A smart all-in-one cardiac patch can be a wearable device attached to the human body to measure cardiac signals and can operate based on a smart all-in-one cardiac patch system.

[0064] As a specific example, the smart all-in-one cardiac patch system described below may operate through the computing device (200) of FIG. 2 based on the network of FIG. 1. More specifically, the smart all-in-one cardiac patch system may include a smart all-in-one cardiac patch that acquires cardiac-related signals, a user device that acquires signals measured through the cardiac patch, and a smart all-in-one cardiac patch server that acquires and processes signals measured from a plurality of user devices. Here, each device may be a device that operates based on the computing device (200) of FIG. 2, but is not limited to the embodiment. In addition, each device may exchange signals based on the network of FIG. 1, but is not limited to the embodiment. For convenience of explanation, the following description will be based on the smart all-in-one cardiac patch, the user device, and the smart all-in-one cardiac patch server, but may not be limited to the names.

[0065] FIG. 3 is a diagram illustrating a smart all-in-one cardiac patch device and a plurality of user devices according to one embodiment of the present disclosure. Referring to FIG. 3, the smart all-in-one cardiac patch (310) can be attached to a human body. The smart all-in-one cardiac patch (310) can be attached to a human body to acquire cardiac-related signals. Here, the cardiac-related signals acquired by the smart all-in-one cardiac patch (310) can include at least one of an electrocardiogram (ECG), a seismocardiogram (SCG), and a phonocardiogram (PCG). Here, the ECG can be an electrical signal related to a heartbeat, the SCG can be a low-frequency vibration signal of the heart, and the PCG can be a cardiac sound wave. In other words, the smart all-in-one cardiac patch (310) can acquire at least one or more of an electrical signal, a vibration signal, and an acoustic signal related to a heartbeat.

[0066] Here, as an example, the smart all-in-one heart patch (310) can be attached to a heart location on the front of the human body to acquire heart-related signals. As another example, the smart all-in-one heart patch (310) can be attached to a heart location on the back of the human body to acquire heart-related signals. As another example, a plurality of smart all-in-one heart patches (310) can be attached to the human body. Specifically, the smart all-in-one heart patches (310) can be attached to both the heart locations on the front of the human body and the back of the human body. Here, heart-related signals can be acquired from each of the plurality of smart all-in-one heart patches (310) and compared, and heart-related signals can be acquired based on the compared signals, thereby increasing the accuracy of heart-related signal measurement.

[0067] As another example, the smart all-in-one heart patch (310) can obtain additional information related to heartbeat or the human body. For example, the smart all-in-one heart patch (310) can obtain additional information on the user's body temperature or the amount of moisture in the skin. The user's body temperature or the amount of moisture in the skin may be information that can affect the acquisition of heart-related signals through the smart all-in-one heart patch (310), and the smart all-in-one heart patch (300) can obtain additional information on this. As a specific example, in low temperatures such as in winter, when the user's body temperature decreases, the heartbeat may slow down, and the smart all-in-one heart patch (310) can obtain additional information on body temperature, external temperature, and other information.

[0068] As another example, the smart all-in-one heart patch (310) can acquire location information, environmental information, and other information. Specifically, the heart-related signal pattern of a user using the smart all-in-one heart patch (310) may differ depending on whether the user is indoors or outdoors. Alternatively, the heart-related signal may differ depending on whether the user is at home, where they feel mentally stable, or in an office space where they work. Here, the smart all-in-one heart patch (310) can measure the user's location information and transmit it to the user device. As another example, the smart all-in-one heart patch (310) can acquire information about the user's surroundings as environmental information. For example, the environmental information may be information that affects the heartbeat, such as temperature, humidity, airflow, and other information about the user's surroundings. In other words, the smart all-in-one heart patch (310) can acquire additional heartbeat-related information, but is not limited thereto.

[0069] Thereafter, the smart all-in-one heart patch (310) can transmit the acquired signal to the user device (410, 420, 430). For example, the user device (410, 420, 430) may be a smartphone (410), a tablet (420), a smart watch (430), or other devices used by a user who has the smart all-in-one heart patch (310) attached, and is not limited to a specific form. However, for the convenience of explanation, the following description will be based on the tablet (420) among the user devices, but may not be limited thereto. Thereafter, the user device (410, 420, 430) can perform monitoring based on the signal acquired from the smart all-in-one heart patch (310). In addition, the user device (410, 420, 430) can transmit the signal acquired from the smart all-in-one heart patch (310) to a server. As another example, the user device may be a device that operates within a preset distance from the smart all-in-one heart patch (310). As a specific example, the user device may be a smart watch (430). Here, the user device may obtain the above-described location information and environmental information within a preset distance from the smart all-in-one heart patch (310), and is not limited to the above-described embodiment. As an example, the smart watch (430) among the user devices may measure the above-described location information and environmental information within a preset distance from the smart all-in-one heart patch (310) and transmit the measured information to another user device (e.g., tablet, 420). That is, the tablet (420) may obtain a heart-related signal from the smart all-in-one heart patch (310) and obtain additional user-related information through the smart watch (430), but may not be limited to the above-described embodiment.

[0070] FIG. 4 is a diagram illustrating a smart all-in-one cardiac patch system according to one embodiment of the present disclosure. Referring to FIG. 4, the smart all-in-one cardiac patch system may include a smart all-in-one cardiac patch (310), a user device (420), and a cloud (or server, 500). In addition, the smart all-in-one cardiac patch system may further include other components and may not be limited to a specific form. Referring to FIG. 4(a), the user device (420) may obtain the above-described signals from the smart all-in-one cardiac patch (310). As an example, the signals may further include ECG, SCG, PCG, and other information, and are not limited to a specific embodiment. Here, as an example, the smart all-in-one cardiac patch (310) may be attached to a cardiac location on the front of the human body to obtain cardiac signals. As another example, the smart all-in-one cardiac patch (310) may be attached to a cardiac location on the back of the human body to obtain cardiac signals, as described above.

[0071] As another example, multiple smart all-in-one cardiac patches (310) can be attached to the human body. Specifically, the smart all-in-one cardiac patches (310) can be attached to both the front and back of the human body at the heart locations. Here, cardiac signals can be acquired and compared from each of the multiple smart all-in-one cardiac patches (310), and the cardiac signals can be acquired based on the compared signals, thereby increasing the accuracy of cardiac signal measurement.

[0072] In addition, the user device (420) may obtain additional information. For convenience of explanation, the user device (420) may refer to heart-related information including signals and additional information obtained from the smart all-in-one heart patch (310), but may not be limited thereto. When the user device (420) obtains heart-related information from the smart all-in-one heart patch (310), the user device (420) may display and provide the heart-related information to the user. In addition, as an example, the user device (420) may obtain heart-related information from the smart all-in-one heart patch (310) in real time or based on a preset cycle. The user device (420) may analyze and monitor at least one of user status information and disease information through the heart-related information obtained in real time or based on a preset cycle. Here, the user device (420) may display and provide the analysis information to the user. As an example, the user device (420) may provide the analysis information based on a preset cycle. As a specific example, the user device (420) may provide at least one of daily information, weekly information, monthly information, and long-term information, and is not limited to a specific form. That is, the user device (420) may obtain heart-related information from the smart all-in-one heart patch (310) in real time or based on a preset cycle, derive analysis information from the heart-related information, and provide the information to the user.

[0073] As another example, referring to FIG. 4(b), the user device (420) can transmit heart-related information acquired from the smart all-in-one heart patch (310) to the cloud (500). Here, the cloud (500) can acquire signals from each of the plurality of user devices (420) that acquire signals from the smart all-in-one heart patch (310), perform analysis, and transmit the analyzed information to the user device (420). As another example, the cloud (500) can perform learning on a condition monitoring learning model based on the heart-related information acquired from the plurality of user devices (420). Thereafter, the cloud (500) can transmit the learned condition monitoring learning model to each user device (420). Each user device (420) can provide the heart-related information acquired from the user as input to the condition monitoring learning model to perform inference, and automatically derive whether the user's condition is abnormal as an output value, which will be described later.

[0074] FIG. 5 is a diagram illustrating the structure of a smart all-in-one cardiac patch according to one embodiment of the present disclosure. Referring to FIG. 5, the smart all-in-one cardiac patch may be any one of the first type (310), the second type (320), and the third type (330). In addition, the smart all-in-one cardiac patch may be of other types or shapes and is not limited to a specific shape. For example, referring to FIG. 5(a), the smart all-in-one cardiac patch may include silicone gel and silicone elastomer. The silicone gel is a deformable material that allows the smart all-in-one cardiac patch to adhere to the shape of the human body surface and not be detached. The silicone elastomer may be a material with excellent elasticity, absorbency, and tensile strength, and may allow the smart all-in-one cardiac patch to adhere to and remain on the human body. That is, the part attached to the human body surface may be composed of silicone gel and silicone elastomer, thereby allowing the smart all-in-one cardiac patch to remain attached to the human body. In addition, electrodes and a wireless charging coil may be included inside the silicone gel and silicone elastomer. Here, the electrodes may be ECG electrodes and may be gold electrodes made of gold, but are not limited thereto and electrodes of other materials may be configured. In addition, the wireless charging coil may be configured to perform battery charging, and the smart all-in-one cardiac patch may be charged based on the same. In addition, polyimide and copper traces may be included inside the silicone gel and silicone elastomer. Here, the polyimide may be a polymer material having thermal stability and high mechanical strength. For example, the first type (310) smart all-in-one cardiac patch may be identically configured in the form of polyimide.This allows the polyimide to be deformed together with the smart all-in-one heart patch when the smart all-in-one heart patch is stretched or bent when attached to the human body, and allows the smart all-in-one heart patch to remain attached without falling off from the human body.

[0075] Additionally, copper tracking can enable the smart all-in-one cardiac patch to track and transmit signals acquired through the high conductivity of copper. Furthermore, the smart all-in-one cardiac patch may further include components for acquiring signals and transmitting them to a user device, and a battery for operating the smart all-in-one cardiac patch. As an example, the components may include configurations for acquiring ECG as an electrical signal, SCG as a low-frequency vibration signal, and PCG as an acoustic signal, as described above, but are not limited to a specific form. Furthermore, as an example, the battery may serve to maintain power for transmitting the acquired signals to the user device. As an example, the smart all-in-one cardiac patch, as a low-power device, can be powered for a long period of time by the battery.

[0076] As another example, the battery may be attached to the body and recharged based on the user's movements. As described above, the smart all-in-one cardiac patch is a low-power device, so it may operate by being attached to the body and recharged based on the user's movements. However, this embodiment is not limited to this example.

[0077] The following describes a method for automating firmware updates for wearable devices. For example, the wearable devices described below may be applied to accessory-type wearable devices, attachable wearable devices, and other types of wearable devices. More specifically, the method may be applied to a wearable device equipped with a communication module capable of receiving signals from an external device and performing firmware updates, but is not limited to this type.

[0078] Below, a method for automating firmware updates is described, using the aforementioned smart all-in-one heart patch as a specific example. However, this is for convenience of explanation and can be applied equally to other attachable wearable devices and other wearable device types. In other words, while the following description focuses on the smart all-in-one heart patch, it can be extended to other wearable devices and is not limited to a specific form factor.

[0079] FIG. 6 is a diagram illustrating each layer within a device applicable to the present disclosure. Referring to FIG. 6, the device may be configured and operated based on various layers. For example, the device may include hardware, a network layer, a transport layer, and an application layer. Here, the hardware may be a configuration that performs the physical transmission of actual signals, and data generated within the application layer may be transferred to the hardware and transmitted via the network layer and the transport layer. In addition, as an example, the application layer may include a Project CHIP (Connected Home over IP) layer and a Zephyr integration layer, but this is only one example and may not be limited thereto.

[0080] The Project CHIP (Connected Home over IP) layer can be a layer that considers interoperability and security between devices, and can be a layer that enables devices from various manufacturers to interact on a single network. For example, Project CHIP can define a standard protocol for interoperability between various platforms and devices. As a specific example, it can enable communication between devices using various communication protocols such as Wi-Fi, Ethernet, Thread, and Bluetooth Low Energy (BLE). Furthermore, Project CHIP can provide privacy protection and device security behavior, and can also provide various types of connections that comply with the Project CHIP protocol. In other words, Project CHIP can be a layer that considers compatibility between devices.

[0081] Additionally, as an example, the Zephyr layer can be a layer for an open-source real-time operating system (RTOS). The Zephyr integration layer, as part of the Zephyr RTOS, can be used to effectively integrate Zephyr into various hardware platforms. This layer can simplify development and ensure uniformity across various hardware architectures and boards by providing hardware abstraction and a standardized application programming interface (API). In other words, the Zephyr integration layer can help developers develop embedded systems and devices quickly and efficiently.

[0082] Additionally, the Zephyr network layer may be a layer that implements various networking protocols and facilitates communication between embedded devices. Specifically, the Zephyr network layer may provide an Internet Protocol version 6 (IPv6) protocol stack to enable embedded devices to communicate with the Internet. As another example, Zephyr may implement the I-wireless communication standard to support the establishment of a local network between low-power embedded devices, or may support the Bluetooth wireless communication stack. Furthermore, Zephyr may be used to establish an IP-based network between embedded devices by implementing the wireless networking standard defined by the Thread group. In other words, the Zephyr network layer may provide various protocols and technologies to meet various networking requirements and may enable efficient processing of network communication in embedded systems and IoT devices, but may not be limited to the above embodiments.

[0083] Additionally, the MCU (microcontroller unit) bootloader may be a layer that updates the MCU's firmware and performs initialization tasks to start programs. Specifically, the bootloader may acquire firmware information from an external source (e.g., UART, USB, Ethernet, etc.) and perform firmware updates. Furthermore, the bootloader may have other functions and may not be limited to a specific form. mbedTLS may be an open-source implementation of the Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols and may perform various functions.

[0084] Here, as an example, firmware updates for the aforementioned device can be performed via the device's SDK. The SDK may provide various libraries, example code, tools, and documentation related to embedded applications, but may not be limited thereto. Furthermore, the SDK may support various wireless protocols (e.g., BLE, Zigbee, Thread, LTE-M, and NB-IoT) and may include libraries and example code for each protocol. Furthermore, the SDK may provide various software stacks, such as a Bluetooth stack based on the Zephyr RTOS, but is not limited to this embodiment.

[0085] As an example, the following describes a method for configuring a smart all-in-one patch (310) based on SDK and performing automated firmware updates.

[0086] FIG. 7 is a diagram illustrating a method for programming a smart all-in-one patch and performing automated firmware updates via an SDK according to one embodiment of the present disclosure. Referring to FIG. 7 , the smart all-in-one patch (310) can be configured and manufactured based on a first server (710) and a second server (720). Additionally, the firmware of the smart all-in-one patch (310) can be automatically updated based on the first server (710) and the second server (720).

[0087] As a specific example, the first server (710) may be a server of a company developing a smart all-in-one patch (310). However, the present invention may not be limited thereto. Furthermore, the second server (720) may be a server of a process company manufacturing the smart all-in-one patch (310). However, the present invention may not be limited thereto.

[0088] Here, the first server (710) may receive an SDK from the second server (720). That is, the second server (720) may provide the SDK to the first server (710) as a kit for programming in connection with the manufacturing of the smart all-in-one patch (310). The first server (710) may perform programming for the smart all-in-one patch (310) based on the provided SDK and configure an embedded program. For example, the SDK may provide an API (Application Programming Interface) as an interface for communicating with software, and may provide tools, libraries, documents, utilities, and other kits for performing specific functions.

[0089] That is, the first server (710) may generate code information through programming related to the unique function or special function of the smart all-in-one patch (310) based on the SDK provided from the second server (720) to enable the smart all-in-one patch (310) to operate. As a more specific example, the first server (710) may generate code information for a series of operations, based on the SDK, in which the smart all-in-one patch (310) senses the aforementioned heart-related signal through a sensor and transmits the sensed information to a user device through a communication module. As another example, the first server (710) may generate code information, based on the SDK, for performing the unique functions of the smart all-in-one patch (310) with an awake cycle, a sensing cycle, and other operations that enable the smart all-in-one patch (310) to operate on a low-power basis, but may not be limited to the above-described embodiment. Here, as an example, the second server (720) may be a server of a process company that manufactures the smart all-in-one patch (310). As a specific example, the first server (710) may transmit code information related to the operation of the smart all-in-one patch (310) to the second server (720) based on the SDK provided from the second server (720), and the second server (720) may program the smart all-in-one patch (310) based on the SDK to which the code information has been applied to configure the firmware.

[0090] In addition, the second server (720) can update the firmware of the smart all-in-one patch (310) based on the SDK. Here, the first server (710) provides code information for firmware update to the second server (720), and the second server (720) can update the firmware of the smart all-in-one patch (310) based on the code information for firmware update. Thereafter, the second server (720) can transmit information related to the smart all-in-one patch (310) whose firmware has been updated from the first server (710). Here, as an example, when configuring or updating firmware for a plurality of smart all-in-one patches (310), the first server (710) may need to provide specific code information and authority for code change for the smart all-in-one patches (310) to the second server (720) for firmware update automation. In the above-described situation, the first server (710) cannot recognize the code information applied to the smart all-in-one patch (310) by the second server (720), and thus cannot confirm how the product is configured. In addition, there may also be a problem in which specific code information is exposed to the second server (720).

[0091] In addition, since the firmware of each smart all-in-one patch (310) is configured by the second server (720), the first server (710) must obtain firmware configuration information or update information from the second server (720) to recognize the current status of the smart all-in-one patch (310), and thus may have to depend on the second server (720). In addition, as an example, the first server (710) may be a server of a company developing a smart all-in-one patch (310), and as described above, there may be a problem that the technology is exposed or product production cannot be managed. Here, it may be possible to standardize the development process through an integrated server and other devices so that the related technology is not exposed to the second server (720). However, in the above-described case, an integrated server and other devices may be required, and thus there may be limitations when considering product production costs, etc.

[0092] Considering the above, the following describes a method in which a first server (710) configures the firmware of a smart all-in-one patch (310) through an SDK provided from a second server (720) to perform automatic updates, but does not provide specific source code information to the second server (720).

[0093] For example, referring to FIG. 7, the second server (720) may provide the first server (710) with an SDK for updating the firmware of each smart all-in-one patch (310). The first server (710) may provide the second server (720) with code information for updating the firmware of each smart all-in-one patch (310) based on the SDK. Thereafter, the second server (720) may perform a firmware update for each smart all-in-one patch (310). Here, the firmware update may be performed based on the MCU's application (721), library / security (722), RTOS / stack / middle driver (723), connection protocol (724), and setting board (725) layers of each layer of FIG. 7. That is, the firmware update may be performed based on information included in each layer. Here, the library / security (722), RTOS / stack / middle driver (723), and connection protocol (724) may be configured as open information as layers including information shared through the second server (720). On the other hand, the MCU's application (721) may be a layer including specific code information related to the operation of the actual smart all-in-one patch (310). The smart all-in-one patch (310) may perform a unique function such as heart signal sensing or signal transmission to a user device based on the code included in the MCU's application (721) layer. That is, the special function of the smart all-in-one patch (310) may be set by the MCU's application (721) as a specific operation. Here, referring to FIG. 8, the MCU's application (721) may be a layer in which the special function of the smart all-in-one patch (310) is set through an operation file provided by the first server (710).

[0094] In addition, the setting board (725) may be a part related to verifying the sensor operation of the smart all-in-one patch (310). The setting board (725) may be a layer that verifies whether the operation of the sensor is operating correctly based on code information in the smart all-in-one patch (310), and may be a layer in which actual verification is performed based on the code set in the smart all-in-one patch (310). Specifically, the setting board (725) may be a layer that verifies whether the sensor or IC chip is operating for each board in the smart all-in-one patch (310), and may check the sensor and other functions that operate based on the code developed by the first server (710). On the other hand, the library / security (722), RTOS / stack / middle driver (723), and connection protocol (724) layers may be layers that operate in an integrated manner based on the OS, and may be layers that do not include information on special functions of the smart all-in-one patch (310).

[0095] That is, the MCU's application (721) layer and the configuration board (725) layer may be layers containing confidential information, and the library / security (722), RTOS / stack / middle driver (723) and connection protocol (724) layers may be layers containing open information, as illustrated in FIG. 9.

[0096] Here, in the past, in order to generate an operation file (e.g. ".hex") in the MCU's application (721) layer of the second server (720), the first server (710) had to share all developed code packages to enable automation, which could be vulnerable to security. In addition, the configuration board (725) also had to share all developed code packages to perform verification as described above, which could be vulnerable to security. In the following, considering the above-described points, the first server (710) can be configured to automatically perform firmware updates without providing all code information. In addition, the integrated server or other devices described above may not be used, which may result in cost savings. Specifically, referring to FIG. 10, the first server (710) can set a security code part and a shared code part in relation to the firmware developed for each sensor. For example, the security code part and the shared code part can be generated based on information related to the operation of the smart all-in-one patch (310) such as basic firmware code, log type information, cloud system, and security key information.

[0097] Here, the security code part may include information that enables the special functions performed by each sensor in the smart all-in-one patch (310) to operate in the first server (710). That is, the security code part may be a code configured to perform a unique function of the smart all-in-one patch (310) developed by an electronics company. The security code part may be configured as an operable input in the MCU's application (721) by the SDK provided from the second server (720). Specifically, the operable input may refer to an input encoded in the form of an RTOS and decoded by the MCU's application (721) when updating firmware, but may not be limited thereto. Here, the security code part may be generated as a secure operating input. That is, the first server (710) may change the security code part developed for the smart all-in-one patch (310) into a non-public confidential operating input based on the SDK. The second server (720) can perform operations for automated mass production based on the confidential operation input described above. In addition, the first server (710) can generate open operation inputs based on the SDK for the shared code part and transmit them to the second server (720). The open operation inputs can include information about each smart all-in-one patch (310), and can include a changed name, a device ID, an independent number assigned by the first server, and other information. In other words, the open operation inputs can be code information that can be made public, and the information can be information required by the MCU's application (721). In addition, the first server (710) can transmit logging system information to the second server (720) based on the independent number information of the smart all-in-one patch (310).For example, the logging system information can be managed and supervised by the log system for the creation of a smart all-in-one patch (310) managed by the first server (710), such as the unique number of a newly produced smart all-in-one patch (310) or the unique number of an already produced smart all-in-one patch (310).

[0098] Here, as an example, referring to FIG. 11, the firmware update of the smart all-in-one patch (310) may be automatically performed based on the first server (710) and the second server (720). Specifically, the first server (710) may provide a secure firmware code to the second server (720). Here, the secure firmware code may be the above-described secure code part. That is, the secure firmware code may be a code that is not disclosed in relation to the unique function of the smart all-in-one patch (310). As an example, the secure firmware code may be provided to the second server (720) as a secure operating input. As a specific example, the secure operating input may be a secure hex file. Thereafter, the first server (710) may transmit product unique number information assigned to each smart all-in-one patch (310) to the second server (720) based on product logging information for each smart all-in-one patch (310). In addition, the first server (710) can transmit open firmware code to the second server (720). Here, the open firmware code may be a shared code part. For example, the open firmware code may be provided to the second server (720) as an open operating input. As a specific example, the open operating input may be an open hex file. Thereafter, the second server (720) can verify the validity of the code in the MCU's application layer (721) based on the security firmware code and the open firmware code for a specific smart all-in-one patch (310) based on the product unique number information of the smart all-in-one patch (310). For example, the second server (720) can obtain the security firmware code and the open firmware code to generate a mixed code, and apply it to the MCU's application layer (721) to verify the validity of the code.As a more specific example, referring to FIG. 12, the second server (720) may generate a mixed code based on the product unique number information, security firmware code, and open firmware code of the smart all-in-one patch (310). That is, the mixed code may include shared code portions (1211, 1212) and a security code portion, and the mixed code may be run in the MCU's application (721) layer of the second server (720). Thereafter, the first server (710) may transmit product information (production info), logging information, and sensor validation code of the smart all-in-one patch (310) to the second server (720). The product information and the logging information may be information related to a specific smart all-in-one patch (310), and the sensor validation code may be code that validates the validity of the sensor and IC chip within the board in each smart all-in-one patch (310) specified based on the product information and the logging information. The second server (720) can perform sensor validation on the setting board (725) layer using product information, logging information, and sensor validation code, and return the validation result to the first server (710). As described above, the firmware update of a specific smart all-in-one patch (310) can be completed. Thereafter, the first server (710) can check the product unique number information for the next device after the specific smart all-in-one patch (310) for which the firmware update has been completed, and transmit it to the second server (720). The second server (720) can validate the code for the smart all-in-one patch (310) to the next device based on the product unique number information, the security firmware code, and the open firmware code for the next device. Thereafter, the second server (720) can obtain product information, logging information, and sensor validation code information for the next device from the first server (710), perform sensor validation, and return the validation result to the first server (710).Thereafter, the first server (710) can perform a firmware update operation for a plurality of smart all-in-one patches (310) by performing the same operation for the next device.

[0099] FIG. 13 is a diagram illustrating an operation method of a first server applicable to the present disclosure. Referring to FIG. 13, a first server that performs automated firmware update of a smart all-in-one heart patch can be provided. Here, the first server may be a server of an electronics company, as described above, and may be a server of a company developing wearable devices. That is, code related to the operation of the smart all-in-one heart patch may be generated as a wearable device by the first server. As a specific example, the first server may generate a security firmware code that controls the operation of a plurality of smart all-in-one heart patches and transmit it to a second server. (S1310) Here, the security firmware code may be generated based on an SDK as a code related to a unique function of the smart all-in-one heart patch, and may be a non-public code. Thereafter, the first server may transmit the unique number information of the first smart all-in-one heart patch to the second server as a specific smart all-in-one heart patch. (S1320) Here, the unique number information may be a number assigned by the first server to distinguish each smart all-in-one heart patch. Thereafter, the first server may transmit open firmware codes related to the plurality of smart all-in-one heart patches to the second server. (S1330) Here, the open firmware code may be an open source code required for firmware update based on an SDK and may be a publicly disclosed code. The second server may generate a mixed code based on the security firmware code, the open firmware code, and the unique number of the first smart all-in-one heart patch, and may verify the code validity of the first smart all-in-one heart patch based on the mixed code. In addition, the first server may transmit information related to the first smart all-in-one heart patch to the second server. (S1340) Here, the information related to the first smart all-in-one heart patch may include product information, logging information, and sensor validity verification code information.That is, the first server can transmit product information and logging information about the first smart all-in-one heart patch to the second server using a specific smart all-in-one heart patch. In addition, the first server can transmit a sensor validation code for verifying the validity of the sensor and IC chip within the board of the first smart all-in-one heart patch to the second server, and the sensor validation code may be a private code. The second server can verify the sensor validity through the product information, logging information, and sensor validation code acquired from the first server, and when the sensor validation is completed, the firmware update can be completed. Thereafter, the second server can transmit the validation result information to the first server. That is, the first server can obtain the validation result information from the second server. (S1350) Here, as an example, the first server and the second server described above may be devices that operate including a memory, a transceiver, and a processor, and may not be limited to a specific form.

[0100] For example, when the first server completes the firmware update for the first smart all-in-one heart patch as described above, the first server can identify the second smart all-in-one heart patch as the next smart all-in-one heart patch and transmit the unique number information of the second smart all-in-one heart patch to the second server. The second server can generate a mixed code using the secure firmware code, the unique number information of the second smart all-in-one heart patch, and the open firmware code, and perform code validation of the second smart all-in-one heart patch using the mixed code. In addition, the first server can transmit information related to the second smart all-in-one heart patch to the second server, and when sensor validation of the second smart all-in-one heart patch is performed using the information related to the second smart all-in-one heart patch based on the code validity of the second smart all-in-one heart patch, the firmware update of the second smart all-in-one heart patch is completed and the validation result can be received from the second server.

[0101] That is, based on the validation results, the first server can sequentially provide multiple smart all-in-one patch information to the second server to perform a firmware update. For example, the firmware update may be performed based on the SDK, as described above. For example, code validation may be performed in the MCU's application layer, and sensor validation may be performed in the configuration board layer.

[0102] Additionally, as an example, the security firmware code may be a code including information for controlling a heart-related signal sensing operation in a smart all-in-one patch, and the sensor validation code may be a code including information for controlling the operation of at least one sensor and IC chip configured in the smart all-in-one patch.

[0103] As another example, the first server may generate different security firmware codes based on the type or version of the smart all-in-one patch. As another example, the first server may generate different security firmware codes based on the type or version of the wearable device. Here, the unique number of the smart all-in-one patch (or wearable device) may be assigned based on the type or version of the smart all-in-one patch. In other words, the unique number may be assigned based on a group of devices having the same type or version. As an example, the first server may generate a security firmware code based on each device group and perform automated firmware updates based on each device group. Here, the open firmware code may be the same code regardless of the device group, but is not limited thereto. As another example, the open firmware code may also be set separately for each device group, and is not limited to a specific form.

[0104] As another example, the first server can perform a firmware update on each smart all-in-one patch (or wearable device) through the above-described process and obtain a firmware update result log file and progress information for each. Here, the firmware update result log file and progress information can be generated based on the unique number of each smart all-in-one patch. In other words, the first server can obtain the firmware update result log file and progress information based on the unique number of the smart all-in-one patch.

[0105] In addition, as an example, the first server can perform a unique number tracking operation for each smart all-in-one patch. That is, the first server can check each smart all-in-one patch by tracking the unique number for each smart all-in-one patch, and can monitor the firmware update result log file and progress information based on the unique number. In addition, the first server can recognize the production status information of each smart all-in-one patch based on the unique number. In another example, the first server can check the firmware update status information of each smart all-in-one patch based on the unique number. That is, the first server can track each smart all-in-one patch based on the unique number and recognize the status information.

[0106] Additionally, for example, security information may need to be verified during the manufacturing process for each smart all-in-one patch (or wearable device). As another example, authorization information or authentication information may need to be verified for each smart all-in-one patch (or wearable device). Here, the first server can track the aforementioned security information, authorization information, and authentication information based on the unique number of each smart all-in-one patch (or wearable device), thereby managing each smart all-in-one patch (or wearable device).

[0107] That is, the first server may monitor information related to each smart all-in-one patch (or wearable device) based on a unique number, and perform the firmware update process described above in consideration of the current status of each smart all-in-one patch (or wearable device), but may not be limited to a specific embodiment.

[0108] As another example, the secure firmware code may include code that is configured identically across all smart all-in-one patch (or wearable device) types or versions, and code that is configured differently for each type or version. Here, the portion of the code that is identical regardless of the type or version may be transmitted to the second server, while the portion of the code that is configured differently for each type or version may be transmitted when a firmware update is performed for each type or version. In other words, each portion may be transmitted separately, but is not limited to a specific embodiment.

[0109] The embodiments described above may be implemented at least in part as computer programs and recorded on a computer-readable recording medium. A computer-readable recording medium on which a program for implementing the embodiments is recorded includes any type of recording device that stores data that can be read by a computer. Examples of computer-readable recording media include ROMs, RAMs, CD-ROMs, magnetic tapes, and optical data storage devices. Furthermore, the computer-readable recording medium may be distributed across network-connected computer systems, such that computer-readable codes are stored and executed in a distributed manner. Furthermore, functional programs, codes, and code segments for implementing the embodiments will be readily understood by those skilled in the art to which the embodiments pertain.

[0110] Although the present specification has been described with reference to the embodiments illustrated in the drawings, these are merely exemplary, and those skilled in the art will understand that various modifications and variations of the embodiments are possible. However, such modifications should be considered within the technical protection scope of the present specification. Therefore, the true technical protection scope of the present specification should be determined to include other implementations, other embodiments, and equivalents to the claims, based on the technical spirit of the appended claims.

[0111]

[0112] The above may also apply to other systems.

Claims

1. In the operation method of the first server that performs automation of firmware update of a smart all-in-one heart patch, A step of generating a secure firmware code that controls the operation of multiple smart all-in-one heart patches and transmitting it to a second server; A step of transmitting unique number information of the first smart all-in-one heart patch to the second server; A step of transmitting open firmware codes related to the plurality of smart all-in-one heart patches to the second server; A step of transmitting information related to the first smart all-in-one heart patch to the second server; and Including a step of obtaining validation result information from the second server, A mixed code is generated based on the security firmware code, the unique number information of the first smart all-in-one heart patch, and the open firmware code, and code validity verification of the first smart all-in-one heart patch is performed. A method of operating a first server, wherein when sensor validation of the first smart all-in-one heart patch is performed through information related to the first smart all-in-one heart patch based on the code validity of the first smart all-in-one heart patch, the firmware update of the first smart all-in-one heart patch is completed and the validation result is transmitted from the second server to the first server.

2. In paragraph 1, Information related to the first smart all-in-one heart patch includes product information, logging information, and sensor validation code of the first smart all-in-one heart patch, and a method of operation of the first server.

3. In paragraph 2, When the first server obtains the validation result of the first smart all-in-one heart patch, it verifies the second smart all-in-one heart patch as the next smart all-in-one heart patch, A method of operating a first server, wherein the unique number information of the second smart all-in-one heart patch is transmitted to the second server, and the second server performs code validation of the second smart all-in-one heart patch through the security firmware code, the unique number information of the second smart all-in-one heart patch, and the open firmware code.

4. In paragraph 3, The first server transmits information related to a second smart all-in-one heart patch to the second server, and when sensor validity of the second smart all-in-one heart patch is verified through the information related to the second smart all-in-one heart patch based on the code validity of the second smart all-in-one heart patch, the firmware update of the second smart all-in-one heart patch is completed, and the validation result is received from the second server. A method of operating a first server.

5. In paragraph 4, A method of operating a first server, wherein the first server sequentially provides a plurality of pieces of smart all-in-one patch information to the second server based on the validation results.

6. In paragraph 1, The operation method of the first server, in which firmware updates are performed through the MCU (micro controller unit)'s application layer, library / security layer, RTOS (Real-Time Operating System) / stack / middle driver layer, connection protocol layer, and configuration board layer based on the SDK (software development kit).

7. In paragraph 6, The above code validation is performed in the MCU's application layer, The above sensor validation is performed in the above setting board layer, and the first server's operation method is performed.

8. In paragraph 1, The above security firmware code is a code that includes information that controls the heart-related signal sensing operation in the smart all-in-one patch, A method of operating a first server, wherein the sensor validation code is a code that includes information for controlling the operation of at least one sensor and an IC (integrated circuit) chip configured in the smart all-in-one patch.

9. In paragraph 1, A computer program stored on a computer-readable medium that is combined with hardware and executes the operating method of the first server according to any one of claims 1 to 8.

10. In the first server that performs automation of firmware updates of the smart all-in-one heart patch, memory; Transmitter and receiver; and In the processor controlling the above memory and transmitter, The above processor, Generate a secure firmware code that controls the operation of multiple smart all-in-one heart patches and transmit it to a second server, The unique number information of the first smart all-in-one heart patch is transmitted to the second server, Transmitting the open firmware code related to the above plurality of smart all-in-one heart patches to the second server, Transmitting information related to the first smart all-in-one heart patch to the second server, and Obtain validation result information from the second server, A mixed code is generated based on the security firmware code, the unique number information of the first smart all-in-one heart patch, and the open firmware code, and code validity verification of the first smart all-in-one heart patch is performed. A first server, wherein when sensor validation of the first smart all-in-one heart patch is performed through information related to the first smart all-in-one heart patch based on the code validity of the first smart all-in-one heart patch, the firmware update of the first smart all-in-one heart patch is completed and the validation result is transmitted from the second server to the first server.

Images