DESC:EARLIEST PRIORITY DATE:
This Application claims priority from a provisional patent application filed in India having Patent Application No. 202441072626, filed on September 25, 2024, and titled “A SYSTEM AND A METHOD FOR ZERO-TOUCH DEPLOYMENT AND OVER-THE-AIR UPGRADES FOR INTEGRATED DEVICES”.
FIELD OF INVENTION
[0001] Embodiments of the present disclosure relate to a field of artificial intelligence and more particularly to a system and method for dynamic multi-dimensional fusion of cognitive data for synthetic intelligence.

BACKGROUND
[0002] With the proliferation of Internet of Things (IoT) ecosystems, there is a growing need for efficient and scalable methods for deploying and managing large numbers of interconnected devices. Traditionally, onboarding and configuring IoT devices requires manual firmware installation, hardware compatibility checks, and repeated technician intervention. This process is time-consuming, error-prone, and not well-suited for dynamic or large-scale environments where rapid device activation is essential.
[0003] In many IoT deployment scenarios, devices are pre-loaded with limited or placeholder firmware, which must then be updated based on the type and specifications of one or more hardware devices. Identifying the correct firmware image often depends on accurate detection of the hardware's make, model, and version. When this identification is not automated, it may involve labour-intensive manual processes or require prior knowledge from the user or technician.
[0004] Furthermore, storage constraints on IoT devices and differences in hardware capabilities necessitate selective firmware deployment to avoid system overload and to ensure performance optimization. Failure in flashing processes due to firmware mismatch or hardware misidentification can result in operational delays, increased support costs, and device malfunction.
[0005] Hence, there is a need for an improved system and method for zero-touch deployment for Internet of Things based devices to address the aforementioned issue(s).
OBJECTIVES OF THE INVENTION
[0006] The primary objective of the invention is to enable a zero-touch deployment system for a plurality of Internet of Things (IoT)-based devices configured with a generic code base, allowing them to autonomously identify connected hardware and retrieve appropriate firmware images from a centralized repository
[0007] Another objective of the invention is to facilitate the identification of make, model, and version of one or more hardware devices through automatic detection or manual user input, thereby ensuring compatibility with available firmware.
[0008] Yet another objective of the invention is to enable a hierarchical firmware matching process wherein the system provides a firmware image based on an exact match, falls back to a model-level match, or resorts to a make-level match in the absence of the former, thus ensuring uninterrupted device setup.
[0009] Yet another objective of the invention is to allow selective downloading and flashing of firmware images so as to prevent overloading the storage capacity of IoT-based devices, enabling faster boot times and improving system efficiency.
[0010] Yet another objective of the invention is to maintain a centralized repository containing firmware images and associated metadata, organized by make, model, and version, to support intelligent and efficient firmware management.
SUMMARY
[0011] In accordance with an embodiment of the present disclosure, a system for zero-touch deployment for Internet of Things based devices is disclosed. The system includes a plurality of IoT-based devices each configured with a generic code base. The system includes a centralized repository comprising a plurality of firmware images of the plurality of IoT-based devices organized by make, model, and version of one or more hardware devices. The system includes a processor. The system includes a memory coupled to the processor, wherein the memory comprises instructions that, when executed by the processor, cause the processor to: receive a plurality of data inputs from one or more hardware devices in the event of the one or more hardware devices establishing a connection with the IoT based devices, wherein the plurality of data inputs comprises a metadata of one or more hardware devices; identify a make, a model, and a version of the one or more hardware devices by using the generic code base automatically or via a user input; transmit the identified make, model, and version of the one or more hardware devices to the centralized repository for a firmware update; compare the identified make, model and version of the one or more hardware devices with the plurality of firmware images in the centralized repository to cause the centralized repository to perform one of provide a firmware image in the event of one of an exact image match, fall back to a firmware image that matches the model of the one or more hardware devices in the event of absence of an exact image match and resort to a firmware image associated with the make of the one or more hardware devices in the event of absence of both the exact match and the model; download the firmware image and display the firmware image onto the plurality of IoT-based devices; and replace the generic code base with a specialized code required for the identified one or more hardware devices.
[0012] In accordance with an embodiment of the present disclosure, a method for zero-touch deployment for Internet of Things based devices is disclosed. The method includes deploying a plurality of IoT-based devices each configured with a generic code base. The method includes organizing a plurality of firmware images in a centralized repository based on make, model, and version of one or more hardware devices in step. The method includes receiving, by a processor, a plurality of data inputs from the one or more hardware devices in the event of the one or more hardware devices establishing a connection with the IoT-based devices, wherein the plurality of data inputs comprises a metadata of the one or more hardware devices. The method includes identifying, by using the generic code base, a make, a model, and a version of the one or more hardware devices automatically or via a user input. The method includes transmitting the identified make, model, and version of the one or more hardware devices to the centralized repository for a firmware update. The method includes comparing the identified make, model, and version with the plurality of firmware images in the centralized repository, causing the centralized repository to perform one of: providing a firmware image in the event of an exact image match, falling back to a firmware image that matches the model of the one or more hardware devices in the event of absence of the exact image match, and resorting to a firmware image associated with the make of the one or more hardware devices in the event of absence of both the exact match and the model. The method includes downloading the firmware image to the IoT-based device. The method includes flashing the firmware image onto the IoT-based device by replacing the generic code base with a specialized code required for the identified one or more hardware devices.
[0013] To further clarify the advantages and features of the present disclosure, a more particular description of the disclosure will follow by reference to specific embodiments thereof, which are illustrated in the appended figures. It is to be appreciated that these figures depict only typical embodiments of the disclosure and are therefore not to be considered limiting in scope. The disclosure will be described and explained with additional specificity and detail with the appended figures.
BRIEF DESCRIPTION OF THE DRAWINGS
[0014] The disclosure will be described and explained with additional specificity and detail with the accompanying figures in which:
[0015] FIG. 1 illustrates a network environment for zero-touch deployment for Internet of Things based devices in accordance with an embodiment of the present disclosure;
[0016] FIG. 2 illustrates a schematic diagram of a system for zero-touch deployment for Internet of Things based devices FIG. 1, in accordance with an embodiment of the present disclosure;
[0017] FIG. 3 is a flow chart representing the steps involved in a method for zero-touch deployment for Internet of Things based devices, in accordance with an embodiment of the present disclosure.
[0018] Further, those skilled in the art will appreciate that elements in the figures are illustrated for simplicity and may not have necessarily been drawn to scale. Furthermore, in terms of the construction of the device, one or more components of the device may have been represented in the figures by conventional symbols, and the figures may show only those specific details that are pertinent to understanding the embodiments of the present disclosure so as not to obscure the figures with details that will be readily apparent to those skilled in the art having the benefit of the description herein.

DETAILED DESCRIPTION
[0019] For the purpose of promoting an understanding of the principles of the disclosure, reference will now be made to the embodiment illustrated in the figures and specific language will be used to describe them. It will nevertheless be understood that no limitation of the scope of the disclosure is thereby intended. Such alterations and further modifications in the illustrated system, and such further applications of the principles of the disclosure as would normally occur to those skilled in the art are to be construed as being within the scope of the present disclosure.
[0020] The terms “comprises”, “comprising”, or any other variations thereof, are intended to cover a non-exclusive inclusion, such that a process or method that comprises a list of steps does not include only those steps but may include other steps not expressly listed or inherent to such a process or method. Similarly, one or more devices or subsystems or elements or structures or components preceded by "comprises... a" does not, without more constraints, preclude the existence of other devices, sub-systems, elements, structures, components, additional devices, additional sub-systems, additional elements, additional structures or additional components. Appearances of the phrase "in an embodiment", "in another embodiment" and similar language throughout this specification may, but not necessarily do, all refer to the same embodiment.
[0021] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the art to which this disclosure belongs. The system, methods, and examples provided herein are only illustrative and not intended to be limiting.
[0022] In the following specification and the claims, reference will be made to a number of terms, which shall be defined to have the following meanings. The singular forms “a”, “an”, and “the” include plural references unless the context clearly dictates otherwise.
[0023] FIG. 1 illustrates a network environment for zero-touch deployment for Internet of Things based devices in accordance with an embodiment of the present disclosure.
[0024] Referring to FIG. 1, Further, the user may access the system (100) over a network (102). The network (102) may be a single communication network or a combination of multiple communication networks and may use a variety of different communication protocols. The personalized network (102) may be a wireless network, a wired network, or a combination thereof. Examples of such individual personalized networks include, but are not limited to, Global System for Mobile Communication (GSM) network, Universal Mobile Telecommunications System (UMTS) network, Personal Communications Service (PCS) network, Time Division Multiple Access TDMA) network, Code Division Multiple Access (CDMA) network, Next Generation Network (NON), Public Switched Telephone Network (PSTN). Depending on the technology, the personalized network (102) may include various network entities, such as gateways and routers; however, such details have been omitted for the sake of brevity of the present description.
[0025] In one embodiment, the system (100) is operatively coupled to a plurality of IoT-based devices (104) each configured with a generic code base. The term plurality of IoT-based devices (104) refers to multiple embedded computing units deployed across various environments, wherein each of the plurality of IoT-based devices (104) is capable of interfacing with one or more hardware devices (108) such as sensors, meters, dispensers, actuators, or control systems, without requiring prior configuration specific to the hardware type. The plurality of IoT-based devices (104) are designed to support plug-and-play deployment by relying on an adaptable firmware architecture.
[0026] In an embodiment, the generic code base configured on each of the plurality of IoT-based devices (104) refers to a modular, lightweight software framework that contains baseline routines, communication protocols, interface detection mechanisms, and identification logic. The generic code base is designed to operate independently of any specific hardware make or model, thus allowing each of the plurality of IoT-based devices (104) to intelligently detect, identify, and adapt to one or more hardware devices (108) upon installation or boot-up. The generic code includes functional libraries that enable the device to perform automated diagnostics, interpret metadata from one or more hardware devices (108), and determine protocol compatibility in real time.
[0027] In one embodiment, the generic code base further comprises a library of known device command-response patterns, which are used during initial interface testing. For example, the generic code may initiate a handshake with the one or more hardware devices (108) by sending low-level commands and analysing the corresponding responses.
[0028] In one embodiment, the system (100) is operatively coupled to a centralized repository (110) comprising a plurality of firmware images of the plurality of IoT-based devices (104) organized by make, model, and version of one or more hardware (108). The centralized repository (110) is configured to support seamless identification, retrieval, and provisioning of device-specific firmware, thereby enabling remote and automated deployment across diverse hardware ecosystems.
[0029] The centralized repository (108) refers to a structured storage system, implemented on a cloud-based or on-premise server infrastructure, that securely hosts firmware binaries, metadata files, device compatibility matrices, and associated configuration packages. This repository is logically segmented and indexed to facilitate efficient lookup and retrieval operations based on incoming device information.
[0030] The plurality of firmware images within the centralized repository (108) are software builds specifically compiled to suit unique combinations of hardware characteristics. Each of the plurality of firmware images is associated with a specific make, model, and version of one or more hardware devices (108). The centralized repository (108) is organized using a hierarchical or key-value structure such that, upon receiving identification data from the connecting plurality IoT-based devices (104), the system (100) can dynamically match and serve the most appropriate firmware.
[0031] In another embodiment, the centralized repository (110) comprises the metadata for classifying the plurality of firmware images based on functional compatibility across the version, the model, and the make. The metadata is structured in a hierarchical classification schema based on functional compatibility across hardware make, model, and version. The metadata enables the system (100) to efficiently query and retrieve firmware images by matching incoming hardware identifiers to the most suitable firmware profile available in the repository.
[0032] The metadata associated with each of the plurality of firmware images includes but is not limited to hardware vendor name (make), product line or feature set (model), firmware version, supported hardware revisions, date of release, compatibility notes, and checksum values for validation.
[0033] In accordance with an embodiment of the present disclosure, a system for zero-touch deployment for Internet of Things based devices is provided. The system comprises a processor and a machine-readable storage medium comprising instructions that, when executed by the processor, cause the processor to: receive a plurality of data inputs from one or more hardware devices in the event of the one or more hardware devices establishing a connection with the IoT based devices, wherein the plurality of data inputs comprises a metadata of one or more hardware devices; identify a make, a model, and a version of the one or more hardware devices by using the generic code base automatically or via a user input; transmit the identified make, model, and version of the one or more hardware devices to the centralized repository for a firmware update; compare the identified make, model and version of the one or more hardware devices with the plurality of firmware images in the centralized repository to cause the centralized repository to perform one of provide a firmware image in the event of one of an exact image match, fall back to a firmware image that matches the model of the one or more hardware devices in the event of absence of an exact image match and resort to a firmware image associated with the make of the one or more hardware devices in the event of absence of both the exact match and the model; download the firmware image and display the firmware image onto the plurality of IoT-based devices; and replace the generic code base with a specialized code required for the identified one or more hardware devices
[0034] It may be noted that the foregoing system is an exemplary system and may be implemented as computer executable instructions in any computing or processing environment, including in digital electronic circuitry or in computer hardware, firmware, device driver, or software. As such, the system is not limited to any specific hardware or software configuration.
[0035] FIG. 2 illustrates a schematic diagram of a system for zero-touch deployment for Internet of Things based devices of FIG. 1, in accordance with an embodiment of the present disclosure. Referring to FIG. 1, the system (100) includes a processor(s) (202), a memory(s) (204) coupled to and accessible by the processor(s) (202), and a database (250) coupled to the memory(s) (204).
[0036] The system (100) disclosed herein is the same as the system (100) described in FIG. 1. The functions of various elements shown in the figs., including any functional blocks labelled as "processor(s)", may be provided through the use of dedicated hardware as well as hardware capable of executing instructions. When provided by a processor, the functions may be provided by a single dedicated processor, by a single shared processor, or by a plurality of individual processors, some of which may be shared. Moreover, explicit use of the term "processor" would not be construed to refer exclusively to hardware capable of executing instructions, and may implicitly comprise, without limitation, digital signal processor (DSP) hardware, network processor, application specific integrated circuit (ASIC), field programmable gate array (FPGA). Other hardware, standard and/or custom, may also be coupled to the processor(s) (202). The system (100) may further include other components such as, but not limited to, keyboard, sensors, logic circuits, input/output interfaces etc. Further, the system (100) may include data (not shown) which may include data that may be stored, utilized or generated during the operation of the computer implemented system (100).
[0037] The memory(s) (204) may be a computer-readable medium, examples of which comprise volatile memory (e.g., RAM), and/or non-volatile memory (e.g., Erasable Programmable read-only memory, i.e. EPROM, flash memory, etc.). The memory(s) (204) may be an external memory, or internal memory, such as a flash drive, a compact disk drive, an external hard disk drive, or the like.
[0038] The system (100) may be provided with a database (250) to store a generic code, a plurality of firmware images and a specialised code. In an example implementation of the system (100) including one or more servers, the databases may databases local to the server or may be remote to the server. It may be noted that the data in the databases may be stored as a table or may be pre-stored as a mapping with the other. This application is not limited thereto.
[0039] The system (100) may include module(s). The module(s) may include a receiving module (206), an identification module (208), transmitting module (210), a comparison module (212), a downloading module (214), and a flashing module (216). In one example, the module(s) may be implemented as a combination of hardware and firmware. In an example described herein, such combinations of hardware and firmware may be implemented in several different ways. For example, the firmware for module(s) may be processor (202) executable instructions stored on a non-transitory machine-readable storage medium and the hardware for the module(s) may include a processing resource (for example, implemented as either single processor or combination of multiple processors), to execute such instructions. Further, the hardware for the module(s) may include communication apparatuses, control circuitries involving electrical and electronics components, sensors, and interface devices, which may be in communication with each other for multi-directional communication therebetween.
[0040] Further, the system includes data. The data may include data that is either stored or generated as a result of functions implemented by the system. In an example, data may include a metadata (222), a make (224), a model (226), and a version (228). It may be noted that such examples of the various functions are only indicative. The present approaches may be applicable to other examples without deviating from the scope of the present subject matter.
[0041] In the present examples, the non-transitory machine-readable storage medium may store instructions that, when executed by the processing resource, implement the functionalities of modules(s). In such examples, the system (100) may include the machine-readable storage medium storing the instructions and the processing resource to execute the instructions. In other examples of the present subject matter, the machine-readable storage medium may be located at a different location but accessible to the system (100) and the processor(s) (202).
[0042] In operation, the receiving module (206) is configured to receive a plurality of data inputs from one or more hardware devices in the event of the one or more hardware devices (108) establishing a connection with the plurality of IoT based devices (104, FIG. 1), wherein the plurality of data inputs comprises a metadata of one or more hardware devices (108, FIG. 1). This connection may be wireless (e.g., Bluetooth, Wi-Fi) or wired (e.g., USB, serial, GPIO), depending on the physical configuration and intended application.
[0043] The plurality of data inputs refers to structured and unstructured device-level communication that is captured, parsed, and interpreted by the plurality of IoT-based devices (104, FIG. 1) in real time. The one or more data inputs are used to initiate a handshake protocol that forms the basis of device identification and provisioning.
[0044] An example of the plurality of data inputs includes, but is not limited to, input/output identification strings, interface signatures, plug-and-play device descriptors, serial bus responses, electric signal responses, device uptime information, and diagnostic codes. The plurality of data inputs may be passively received or actively polled based on the capabilities of the generic code base.
[0045] In one embodiment, the identification module (208) is configured to identify a make, a model, and a version of the one or more hardware devices (108, FIG. 1) by using the generic code base automatically or via a user input (106, FIG. 1). This identification may be carried out in two modes that is automatically via the generic code base or manually via the user input (106, FIG. 1).
[0046] The make refers to the manufacturer or brand associated with the one or more hardware devices (108, FIG. 1), the model indicates the product family or category under which the device is marketed or structured, and the version refers to the hardware or firmware iteration or revision number. These identifiers are necessary to map the one or more hardware devices (109, FIG. 1) to an appropriate firmware image in the centralized repository.
[0047] In an embodiment, the generic code base is designed to interpret the received metadata from the connected one or more hardware devices (108, FIG. 1) and extract parameters that correspond to standard identification markers. This may involve parsing manufacturer IDs, interpreting version control tags, or analysing product codes embedded in the metadata.
[0048] An example of identifying make, model, and version includes, but is not limited to, analysing a USB descriptor to retrieve vendor ID and product ID; reading I²C address space to interpret the part number and revision code of a sensor; or parsing serial communication headers to extract firmware version tags from embedded controllers.
[0049] In another embodiment, the identification module (208) is configured to perform the identification of the make, model, and version by executing a sequence of automated tests on an interface of the one or more hardware devices (108, FIG. 1). These tests are executed by the processor in conjunction with the generic code base resident on the plurality of IoT-based devices (104, FIG. 1), targeting the hardware interface of the one or more hardware devices (108, FIG. 1).
[0050] The automated tests are systematically performed to extract low-level and high-level operational responses from the hardware, such as protocol handshake behaviour, response delay, configuration register content, peripheral availability, voltage signatures, and firmware-level metadata. These parameters are then analysed to match preconfigured patterns or signatures stored locally or within the centralized repository, which correspond to known hardware configurations.
[0051] An example of the automated tests includes, but is not limited to a serial interface probing test that checks baud rate and parity settings; a GPIO toggling routine that measures latency and pin configuration; an I2C address sweep to detect memory or sensor modules; an embedded command response test that verifies bootloader strings; and a voltage/current profiling test used to determine power characteristics of the hardware. These tests provide key indicators which, when correlated, enable the processor to deduce the identity of the hardware without manual intervention.
[0052] In another embodiment, the identification module (208) is configured to receive the user input (106, FIG. 1) from a technician or the user indicative of the make, model, and version of the one or more hardware devices (108, FIG. 1) when automated testing fails. Upon failure of the automated testing to conclusively determine the make, model, or version of the one or more hardware devices (108, FIG. 1), the identification module (208) may trigger an interface for receiving manual inputs. This allows the technician or user to directly input identifying details necessary for completing the zero-touch deployment process.
[0053] The manual input may be provided via a user interface that includes, but is not limited to a touchscreen panel, a connected mobile application, a web dashboard, or a command-line interface. The interface is designed to prompt the user to select or enter relevant identifiers such as manufacturer name (make), product line (model), and hardware/software revision (version). This information is then validated and used to query the centralized repository for a compatible firmware image, thereby enabling continuation of the firmware provisioning workflow.
[0054] In one embodiment, the transmitting module (210) is configured to transmit the identified make, model, and version of the one or more hardware devices (108, FIG. 1) to the centralized repository (110, FIG. 1) for a firmware update. The transmission is facilitated by the processor embedded within the plurality of IoT-based devices (104, FIG. 1), which packages the identified data into a structured format, such as JSON, XML, or a proprietary lightweight communication protocol. This package includes key metadata fields representing the identified make (e.g., “ABC Technologies”), model (e.g., “XYZ-200”), and version (e.g., “v1.3.5”) of the hardware device.
[0055] An example of transmitting the identified information includes, but is not limited to, establishing an HTTP or MQTT connection with the centralized repository, constructing a payload with the identification parameters, and securely sending it via TLS/SSL encryption to an API endpoint exposed by the repository service.
[0056] In one embodiment, the comparison module (212) is configured to compare the identified make, model and version of the one or more hardware devices (108, FIG. 1) with the plurality of firmware images in the centralized repository (110, FIG. 1) to cause the centralized repository (110, FIG. 1) to perform one of: provide a firmware image in the event of one of an exact image match, fall back to a firmware image that matches the model of the one or more hardware devices (108, FIG. 1) in the event of absence of an exact image match and resort to a firmware image associated with the make of the one or more hardware devices in the event of absence of both the exact match and the model. The comparison module (212) compares the identified metadata with a plurality of firmware images stored in a centralized repository (110, FIG. 1). The centralized repository (110, FIG. 1) is structured to organize firmware images according to the metadata fields such as make, model, and version, thereby enabling precise classification and hierarchical access. This hierarchical classification ensures that the system (100) can attempt to locate the most accurate firmware match for the one or more hardware devices (108, FIG. 1), with fallback strategies in place if a precise match is unavailable.
[0057] To initiate the comparison process, the processor (202) retrieves the metadata associated with the identified one or more hardware devices (108, FIG. 1) including device manufacturer name (make), product category or configuration (model), and the specific release or revision identifier (version). These parameters are cross-referenced against corresponding metadata attributes associated with each of the plurality of firmware images stored in the centralised repository (110, FIG. 1).
[0058] In one embodiment, if an exact match is located wherein the firmware metadata exactly matches the identified make, model, and version the centralized repository causes the selected firmware image to be provided to the plurality of IoT-based devices (104, FIG. 1) for download and flashing. This step ensures optimal firmware compatibility, performance, and hardware utilization.
[0059] In another embodiment, in the event that the centralised repository (110, FIG. 1) does not contain the firmware image that matches all three parameters (make, model, and version), the processor triggers the fallback mechanism to locate the firmware image that matches only the model of the one or more hardware devices (108, FIG. 1). This model-based fallback is suitable in cases where version-level specificity is unavailable, but where firmware designed for the same hardware model remains functionally compatible.
[0060] In yet another embodiment, if the centralized repository (110, FIG. 1) fails to identify the firmware image that matches either the full specification or the model alone, the comparison module (212) then resorts to the firmware image that is associated only with the make of the one or more hardware devices (108, FIG. 1). This last-tier fallback mechanism ensures that at least a base-level firmware image validated for the manufacturer’s hardware standards can be provisioned to the plurality of IoT-based devices (104, FIG. 1), enabling it to function with minimal essential capabilities.
[0061] An example of a make, model, and version includes, but is not limited to, one or more hardware device (108, FIG. 1) identified as follows: make “Acme Tech”, model “SmartNode V4”, and version “3.1.7”. The centralized repository would attempt to locate a firmware image with identical metadata tags. If no such image exists, it would seek any firmware tagged with model “Smart Node V4”, and failing that, any generic firmware under make “Acme Tech”.
[0062] In one embodiment, the downloading module (214) is configured to download the firmware image and display the firmware image onto the plurality of IoT-based devices (104, FIG. 1). The downloading process is initiated by the processor (202), which establishes a secure communication session with the centralized repository, typically using protocols such as HTTPS, MQTT, or a proprietary secure channel, ensuring that the firmware transfer maintains integrity and confidentiality.
[0063] In one embodiment, the flashing module (216) is configured to replace the generic code base with a specialized code required for the identified one or more hardware devices (108, FIG. 1). Upon verification of the firmware image, the flashing module (216) executes an update protocol that overwrites or supplements the existing generic code with a more functionally rich and hardware-aware specialized code. The specialized code includes specific drivers, protocols, and configuration parameters required for the optimal operation of the identified hardware, such as sensor calibration, peripheral integration, network stack configuration, and control logic.
[0064] An example of the specialized code includes but is not limited to a hardware-specific device driver for a thermal imaging sensor; a communication stack tailored for LoRaWAN or Zigbee protocols based on the device’s connectivity module; a machine learning module for edge processing of sensor data; or a custom power management routine designed for solar-powered nodes.
[0065] It must be noted that the replacement of the generic code base with a specialized code is a critical transformation step that marks the completion of zero-touch provisioning. It ensures that each of the plurality of IoT-based devices (104, FIG. 1) is no longer operating in a universal fallback mode but instead behaves as a fully integrated unit customized for the one or more hardware devices (108, FIG. 1) it is connected to.
[0066] In another embodiment, the flashing module (216) is configured to initiate a retry logic to update the plurality of firmware image in the event of a mismatch or failure during the flash. The retry logic is embedded as part of the control flow in the memory and operates to ensure that the firmware update process completes reliably, especially in environments where connectivity, power, or data integrity may be inconsistent.
[0067] The retry logic includes, but is not limited to checksum validation failures, hash mismatches, incomplete download errors, interrupted flash cycles, and corrupted binary image detection. In each instance, the processor is adapted to either attempt re-download of the firmware image from the centralized repository or revert to a previous known stable version stored in a secure local cache for rollback.
[0068] In another embodiment, the flashing module (216) is configured to a selective downloading and flashing of the firmware image prevents overloading a storage capacity of the plurality of IoT-based devices (104, FIG. 1), thereby enabling a faster boot time and improving operational efficiency. The processor (202) uses metadata associated with the identified make, model, and version of the one or more hardware devices (108, FIG. 1) to determine the minimum viable firmware segment needed for proper operation. This selective approach ensures that the one or more hardware devices (104, FIG. 1) is not burdened with unnecessary code modules or features not applicable to its configuration, thereby conserving onboard storage.
[0069] An example of the selective downloading process includes but is not limited to downloading only device drivers compatible with a specific hardware interface, excluding diagnostic or development modules not required for deployment, or retrieving compressed firmware segments that are later unpacked and applied locally.
[0070] Consider a non-limiting example wherein a technician “T” is installing one or more hardware devices (108, FIG. 1), such as smart controllers and connected sensors, in an industrial facility. Each of the plurality of IoT-based devices (104, FIG. 1) is preloaded with a generic code base to support initial operation. As technician “T” connects a new temperature control module (a hardware device) to one of the IoT-based devices (104, FIG. 1), the device automatically initiates a zero-touch deployment process. A set of data inputs including the metadata such as hardware serial number, manufacturer code, model identifier, and firmware version are detected and transmitted to the processor. The processor, upon executing the embedded instructions, identifies the make, model, and version of the connected temperature control module. This information is then transmitted to a centralized repository (110, FIG. 1), which searches for a suitable firmware image. In this instance, there is no exact image match for the hardware version, so the repository falls back to a firmware image matching the model. The firmware image is downloaded and flashed onto the plurality of IoT-based devices (104, FIG. 1), replacing the generic code base with specialized code optimized for the connected temperature module.
[0071] Upon successful firmware installation, then verifies the operational readiness through a set of automated interface tests. If the flashing fails, the processor automatically triggers a retry logic until a successful flash is confirmed. To optimize performance and storage, only relevant components of the firmware image are downloaded and applied, ensuring efficient use of device resources. This prevents overloading the storage capacity, accelerates boot time, and enhances the overall operational efficiency of the plurality of IoT-based devices (FIG. 1). During the process, the metadata and firmware mapping are logged and sent to a cloud-based management portal. This portal tracks firmware versioning, functional compatibility, and historical deployment records across the facility. As a result, technician “T” is able to deploy and configure devices rapidly without manual firmware setup, thereby saving time and reducing the risk of configuration errors
[0072] FIG. 3 is a flow chart representing the steps involved in a method for zero-touch deployment for Internet of Things based devices, in accordance with an embodiment of the present disclosure. The method (300) includes deploying a plurality of IoT-based devices each configured with a generic code base in step 305.
[0073] The method (300) includes organizing a plurality of firmware images in a centralized repository based on make, model, and version of one or more hardware devices in step 310.
[0074] The method (300) includes receiving, by a processor, a plurality of data inputs from the one or more hardware devices in the event of the one or more hardware devices establishing a connection with the IoT-based devices, wherein the plurality of data inputs comprises a metadata of the one or more hardware devices in step 315.
[0075] The method (300) includes identifying, by using the generic code base, a make, a model, and a version of the one or more hardware devices automatically or via a user input in step 320.
[0076] The method (300) includes transmitting the identified make, model, and version of the one or more hardware devices to the centralized repository for a firmware update in step 325.
[0077] The method (300) includes comparing the identified make, model, and version with the plurality of firmware images in the centralized repository, causing the centralized repository to perform one of: providing a firmware image in the event of an exact image match, falling back to a firmware image that matches the model of the one or more hardware devices in the event of absence of the exact image match, and resorting to a firmware image associated with the make of the one or more hardware devices in the event of absence of both the exact match and the model in step 330.
[0078] The method (300) includes downloading the firmware image to the IoT-based device in step 335.
[0079] The method (300) includes flashing the firmware image onto the IoT-based device by replacing the generic code base with a specialized code required for the identified one or more hardware devices in step 340.
[0080] Thus, various embodiments of the system and method for zero-touch deployment for Internet of Things based devices provides several benefits. By utilizing a generic code base initially embedded in each of the plurality of IoT-based devices (104, FIG. 1) and using a centralized repository (110, FIG. 1) comprising the plurality of firmware images organized by make, model, and version of the one or more hardware devices (108, FIG. 1), the system (100) eliminates the need for manual firmware flashing or configuration during deployment. The identification module (208) intelligently analyses a plurality of data inputs including the metadata from the hardware, identifies the hardware profile, and performs comparison operations with the stored firmware images to ensure accurate matching. In cases where an exact match is not found, the system (100) seamlessly falls back to model-based or make-based firmware images, thereby ensuring operational continuity. This layered fallback logic, combined with selective downloading and flashing of firmware images, prevents overloading the plurality of IoT-based devices (104, FIG. 1) storage capacity and results in faster boot times and improved operational efficiency, making the system highly scalable and efficient for large-scale IoT deployments.
[0081] The techniques described in this disclosure may be implemented, at least in part, in hardware, software, firmware, or any combination thereof. For example, various aspects of the described techniques may be implemented within one or more processors, including one or more microprocessors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or any other equivalent integrated or discrete logic circuitry, as well as any combinations of such components. The term “processor” or “processing subsystem” may generally refer to any of the foregoing logic circuitry, alone or in combination with other logic circuitry, or any other equivalent circuitry. A control unit including hardware may also perform one or more of the techniques of this disclosure.
[0082] Such hardware, software, and firmware may be implemented within the same device or within separate devices to support the various techniques described in this disclosure. In addition, any of the described units, modules, or components may be implemented together or separately as discrete but interoperable logic devices. Depiction of different features as modules or units is intended to highlight different functional aspects and does not necessarily imply that such modules or units must be realized by separate hardware, firmware, or software components. Rather, functionality associated with one or more modules or units may be performed by separate hardware, firmware, or software components, or integrated within common or separate hardware, firmware, or software components.
[0083] It will be understood by those skilled in the art that the foregoing general description and the following detailed description are exemplary and explanatory of the disclosure and are not intended to be restrictive thereof.
[0084] While specific language has been used to describe the disclosure, any limitations arising on account of the same are not intended. As would be apparent to a person skilled in the art, various working modifications may be made to the method in order to implement the inventive concept as taught herein.
[0085] The figures and the foregoing description give examples of embodiments. Those skilled in the art will appreciate that one or more of the described elements may well be combined into a single functional element. Alternatively, certain elements may be split into multiple functional elements. Elements from one embodiment may be added to another embodiment. For example, the order of processes described herein may be changed and are not limited to the manner described herein. Moreover, the actions of any flow diagram need not be implemented in the order shown; nor do all of the acts need to be necessarily performed. Also, those acts that are not dependent on other acts may be performed in parallel with the other acts. The scope of embodiments is by no means limited by these specific examples.
,CLAIMS:1. A system for zero-touch deployment for Internet of Things based devices, comprising:
a plurality of IoT-based devices each configured with a generic code base;
a centralized repository comprising a plurality of firmware images of the plurality of IoT-based devices organized by make, model, and version of one or more hardware devices;
a processor; and
a memory coupled to the processor, wherein the memory comprises instructions that when executed by the processor, cause the processor to:
receive a plurality of data inputs from one or more hardware devices in the event of the one or more hardware devices establishing a connection with the IoT based devices, wherein the plurality of data inputs comprises a metadata of one or more hardware devices;
identify a make, a model, and a version of the one or more hardware devices by using the generic code base automatically or via a user input;
transmit the identified make, model, and version of the one or more hardware devices to the centralized repository for a firmware update;
compare the identified make, model and version of the one or more hardware devices with the plurality of firmware images in the centralized repository to cause the centralized repository to perform one of provide a firmware image in the event of one of an exact image match, fall back to a firmware image that matches the model of the one or more hardware devices in the event of absence of an exact image match and resort to a firmware image associated with the make of the one or more hardware devices in the event of absence of both the exact match and the model;
download the firmware image and display the firmware image onto the plurality of IoT-based devices; and
replace the generic code base with a specialized code required for the identified one or more hardware devices.
2. The system as claimed in claim 1, to cause the processor to perform the identification of the make, model, and version by executing a sequence of automated tests on an interface of the one or more hardware devices.

3. The system as claimed in claim 1, to cause the processor to receive the user input from a technician or the user indicative of the make, model, and version of the one or more hardware devices when automated testing fails.

4. The system as claimed in claim 1, wherein the centralized repository comprises the metadata for classifying the plurality of firmware images based on functional compatibility across the version, the model, and the make.

5. The system as claimed in claim 1, to cause the processor to initiate a retry logic to update the plurality of firmware image in the event of a mismatch or failure during the flash.

6. The system as claimed in claim 1, to cause the processor to a selective downloading and flashing of the firmware image prevents overloading a storage capacity of the plurality of IoT-based devices, thereby enabling a faster boot time and improving operational efficiency.

7. A method for zero-touch deployment for Internet of Things based devices, the method comprising:
deploying a plurality of IoT-based devices each configured with a generic code base;
organizing a plurality of firmware images in a centralized repository based on receiving, by a processor, a plurality of data inputs from the one or more hardware devices in the event of the one or more hardware devices establishing a connection with the IoT-based devices, wherein the plurality of data inputs comprises metadata of the one or more hardware devices;
receiving, by a processor, a plurality of data inputs from the one or more hardware devices in the event of the one or more hardware devices establishing a connection with the IoT-based devices, wherein the plurality of data inputs comprises metadata of the one or more hardware devices;
identifying, by using the generic code base, a make, a model, and a version of the one or more hardware devices automatically or via a user input;
transmitting the identified make, model, and version of the one or more hardware devices to the centralized repository for a firmware update;
comparing the identified make, model, and version with the plurality of firmware images in the centralized repository, causing the centralized repository to perform one of: providing a firmware image in the event of an exact image match, falling back to a firmware image that matches the model of the one or more hardware devices in the event of absence of the exact image match, and resorting to a firmware image associated with the make of the one or more hardware devices in the event of absence of both the exact match and the model;
downloading the firmware image to the IoT-based device; and
flashing the firmware image onto the IoT-based device by replacing the generic code base with a specialized code required for the identified one or more hardware devices.

Dated this 06th day of August 2025
Signature

Prakriti Bhattacharya
Patent Agent (IN/PA-5178)
Agent for the Applicant