Enrolling an enrollee device into a wireless network

Abstract

Accordingly, the proposed concepts are directed to schemes, solutions, concepts, designs, methods, and systems for device provisioning protocol onboarding wireless networks. In particular, embodiments are directed to reducing the total onboarding time of multiple enrollee devices by controlling the enrollment of the enrollee devices based on the status (e.g., availability, readiness, workload, etc.) of the provisioning device.

Description

Technical Field

[0001] This invention relates generally to wireless communication, and more specifically to controlling the registration of multiple registrant devices to a wireless network according to a device provisioning protocol (DPP). Background Technology

[0002] The device setup protocol defines the device role during device setup (configuration) and connection (introduction) to the wireless network.

[0003] There are two types of roles: the configurer and registerer, and the initiator and responder.

[0004] The configurator supports the registrant's settings. Both the configurator and registrant participate in DPP bootstrapping, DPP authentication, and the DPP configuration protocol.

[0005] Either the configurator or the registrant can act as the initiator in the DPP bootstrapping protocol and the DPP authentication protocol. However, only the registrant initiates the DPP configuration protocol and the DPP introductory protocol.

[0006] The DPP authentication protocol requires the initiator to obtain the responder's bootstrap key as part of the preceding bootstrap mechanism. Optionally, the two devices in the DPP authentication protocol can obtain each other's bootstrap keys to provide mutual authentication. After authentication is complete, the configurator sets up device-to-device or infrastructure communication for the registrant. As part of this setup, the configurator enables the registrant to establish secure associations with other peers in the network.

[0007] In practice, setting up a single registrant can be completed within three seconds, which is usually sufficient for the user. However, given the asynchronous communication and retry policies designed in the DPP specification, there may be exceptions to the registrant setup process (e.g., due to some unknown issues), and the entire DPP authentication and configuration process can extend to more than twenty seconds.

[0008] In practice, it is usually necessary to register more than one device to the wireless network. For example, the number of devices to be registered may range from a few to dozens (e.g., 3 to 36). Moreover, there may be situations where some devices cannot be configured (e.g., due to unknown technical issues) or some devices can only register after multiple retries.

[0009] Therefore, batch registration of multiple devices based on DPP can be difficult, time-consuming, and / or problematic, especially when a large number of devices need to be registered. Thus, there is a need to improve the device registration process for wireless networks, particularly regarding batch registration of large numbers of devices.

[0010] US 201801094 A1 discloses a DPP mechanism that uses an intermediary device (e.g., a legacy mobile device) to facilitate bootstrapping between a registrant and a configuration party. Such an intermediary device can acquire bootstrapping data associated with the registrant and forward it to the configuration party, and the configuration party can provide an indicator to the intermediary device so that its user is aware that the registrant's configuration has been correctly completed. The inventors of this invention recognized that using such an intermediary device could create an efficient way to achieve bulk registration of multiple registrants. Summary of the Invention

[0011] This invention is defined by the claims.

[0012] According to an example of one aspect of the present invention, an intermediary device is provided for controlling the registration of multiple registering devices to a wireless network according to a Device Configuration Protocol (DPP), the intermediary device comprising:

[0013] An interface configured to acquire authentication data associated with each of the plurality of registrant devices;

[0014] A status component, configured to determine the status of the device configuring the Wi-Fi network; and

[0015] A communication component configured to transmit authentication data associated with one or more of the registering devices to the configuring device based on the determined state of the configuring device.

[0016] Therefore, the proposed concept aims to provide schemes, solutions, ideas, designs, methods, and systems for loading DPP into a wireless network. Specifically, embodiments aim to reduce the total loading time of multiple registering devices by controlling the registration of registering devices based on the status of the configuring device (e.g., availability, readiness, workload, etc.). For example, embodiments can check the status of the configuring device and queue new device registration / configuration tasks if the configuring device is busy or unavailable. If the configuring device is available for new device configuration, embodiments can release the new device registration / configuration task from the queue and send authentication data to the configuring device to begin a new device registration / configuration process.

[0017] Modifying the device configuration protocol to support the use of an intermediary device that controls the delivery of authentication data to the configuration device can enable the simple and / or efficient bulk registration of multiple devices to a wireless network.

[0018] Using an intermediary device to assist with device registration can reduce complexity and ensure that registration requests are delivered to the configurator device only at the appropriate time. Therefore, embodiments can reduce the number of failed registration attempts that might occur due to the configurator device being unavailable or occupied.

[0019] Furthermore, the proposed concept can support multiple intermediary devices, thus improving deployment scalability. In some implementations, a remote network can be used to couple the intermediary devices while still assisting with device configuration for networks managed by the configuration device.

[0020] According to some embodiments, a concept has been proposed in which multiple registrant devices send their authentication data (e.g., bootstrap data) to an intermediary device (e.g., an intermediary controller). The authentication data from the different registrant devices can then be stored (e.g., queued) at the intermediary device while the intermediary device determines the status of the configuration device in the wireless network. Then, when the configuration device is in a state where it is available and / or ready to receive and process authentication data, the intermediary device sends only the selected authentication data (e.g., data at the front of the queue) to the configuration device. In this way, time delays caused by failed registration attempts can be reduced or minimized, thereby reducing the time required to load multiple registrant devices into the wireless network.

[0021] In some embodiments, the status component may include a monitoring component adapted to monitor the operational status of the configurator device to determine when the configurator device is in an available state, during which the configurator device can be used to register registrant devices to the wireless network. The communication component may then be configured to transmit authentication data associated with one or more registrant devices to the configurator device in response to the monitoring component determining that the configurator device is in an available state.

[0022] Additionally, the communication component can be configured to prevent the transmission of authentication data associated with one or more of the registering devices to the configuration device in response to a monitoring component determining that the configuration device is not available.

[0023] In some embodiments, the interface component is configured to intercept authentication data transmitted from the registrant device to the configurator device of the wireless network.

[0024] The interface component can be configured to receive authentication data from a mobile computing device (e.g., a smartphone or desktop computer). For example, the mobile computing device can be configured to receive authentication data from a user (e.g., via a user input interface) or from a registration device (e.g., via a short-range communication link or by capturing Quick...). (QR code image) to obtain authentication data.

[0025] Some embodiments may also include a queuing component configured to store the acquired authentication data in a sorted queue. The communication component may then be configured to transmit the authentication data from the sorted queue based on the order of the authentication data in the queue.

[0026] Additionally, the queuing component can be configured to position the first authentication data associated with the first registrant device in the sorted queue based on the attributes of the first registrant device or a time value associated with the first authentication data. This allows for the concept of controlling the priority of registration tasks in the sorted queue. Priority setting rules for authentication data in the queue can be defined based on one or more factors such as device type, device group, and number of failures. Default rules can be established based on one or more of these (or other) factors. Alternatively or additionally, the user can manually adjust the priority. Furthermore, embodiments can be adapted to pause, resume, and cancel some registration tasks as needed. Special cases can also be provided to handle the number of device setup failures. For example, generally, the more registration failures (i.e., failure to load / set up an instance to the network) there are, the lower the priority. A threshold can be configured that, exceeding which, the device registration task can be paused or canceled. In this way, these tasks can be skipped in subsequent device registration processes.

[0027] The authentication data associated with the registrant device may include bootstrapping information. This facilitates control over the bootstrapping process, where out-of-band techniques (which typically involve proximity or physical association with the registrant device) are used. For example, bootstrapping may include scanning a Quick key that encodes a public bootstrapping key. (QR) codes. By supporting this form of authentication, the proposed embodiments can still allow certain devices without a user interface (e.g., Internet of Things (IoT) devices, wearable accessories, home automation devices, etc.) to be authenticated and registered via the configurator device.

[0028] In some embodiments, the intermediary device may include legacy devices that do not natively support the Device Configuration Protocol (DPP), and the communication components may be configured to transmit authentication data via the application layer at the intermediary device. Such embodiments can therefore support the use of legacy devices as ( wholly or partially) intermediary devices, thereby encouraging the adoption of DPP. For example, because the intermediary device can include legacy devices while still facilitating control over the registration of multiple registrant devices, users with legacy devices can easily adopt DPP.

[0029] According to another example of one aspect of the present invention, a method is provided for controlling the registration of multiple registering devices to a wireless network according to a Device Configuration Protocol (DPP), the method comprising:

[0030] At the intermediary device, obtain authentication data associated with each of the plurality of registrant devices;

[0031] Determine the status of the configuration device of the wireless network; and

[0032] Based on the determined state of the configuration device, authentication data associated with one or more of the registration devices will be transmitted to the configuration device.

[0033] According to another aspect, a computer program product is provided, wherein the computer program product includes a computer-readable storage medium having computer-readable program code embodied thereon, the computer-readable program code being configured to perform all the steps of the proposed embodiments.

[0034] Therefore, a computer system may also be provided, the computer system comprising: a computer program product according to the proposed embodiments; and one or more processors adapted to perform the method according to the proposed concept by running the computer-readable program code of the computer program product.

[0035] These and other aspects of the invention will become apparent and elucidated with reference to one or more embodiments described below. Attached Figure Description

[0036] To better understand the invention and to more clearly illustrate how it can be practiced, reference will now be made to the accompanying drawings by way of example only, in which:

[0037] Figure 1 This is a simplified diagram of an exemplary embodiment of an intermediary device for registering multiple registration party devices to a wireless network according to DPP control;

[0038] Figure 2This is a flowchart illustrating a method for registering multiple registrant devices to a wireless network according to DPP control; and

[0039] Figure 3 This is a simplified block diagram of a computer in which one or more parts of the embodiments may be incorporated. Detailed Implementation

[0040] The invention will be described with reference to the accompanying drawings.

[0041] It should be understood that while the detailed description and specific examples indicate exemplary embodiments of the apparatus, system, and method, they are for illustrative purposes only and are not intended to limit the scope of the invention. These and other features, aspects, and advantages of the apparatus, system, and method of the invention will be better understood from the following description, claims, and drawings. Although certain measures are recited in dissimilar dependent claims, this does not imply that combinations of these measures cannot be advantageously used.

[0042] Those skilled in the art, through studying the accompanying drawings, the disclosure, and the claims, will be able to understand and implement variations of the disclosed embodiments when practicing the claimed invention. In the claims, the word "comprising" does not exclude other elements or steps, and the words "a" or "an" do not exclude a plurality.

[0043] It should be understood that the accompanying drawings are schematic only and are not drawn to scale. It should also be understood that the same reference numerals are used in all the accompanying drawings to denote the same or similar parts.

[0044] The embodiments of this disclosure relate to various techniques, methods, schemes, and / or solutions for controlling the registration of multiple registration devices for use in DPP-loaded wireless networks. Based on the proposed concepts, many possible solutions can be implemented individually or in combination. That is, while these possible solutions may be described individually below, two or more of these possible solutions may be implemented in one combination or another.

[0045] The term "DPP-based Wi-Fi network" refers to a network consisting of multiple Wi-Fi devices that enables at least one Wi-Fi repeater to act as or otherwise serve as a DPP configurator.

[0046] The term "smart" refers to a device capable of reading QR code information present on a Wi-Fi repeater and connecting to a wireless access point (AP). Examples of smart devices can include smartphones (or "mobile phones"), smartwatches, tablets, and portable computing devices (e.g., personal digital assistants).

[0047] The terms "configured device" or "registered device" refer to a device that loads / registers to a wireless network (e.g., a DPP-based Wi-Fi repeater network or MAP-R2 network) using the DPP mechanism. A configured (or registered) device can act as, or otherwise serve as, a DPP initiator.

[0048] The terms "unconfigured device" and "registering device" refer to devices that have not yet been loaded / registered to the wireless network. Therefore, a new device that has not yet been configured for the network can be referred to as a registering device.

[0049] DPP can be used to facilitate the configuration of registering devices introduced into a network. For example, DPP can provide authentication and authenticated key establishment between the registering device and the configuring device. The configuring device provides the configuration used by the registering device to join the network. Each of the registering and configuring devices can have associated authentication data (e.g., a public bootstrap key, sometimes also called a "public identity key") that is trusted between the devices and can be used for initial authentication. In some implementations, the authentication data is used to generate a temporary setup key.

[0050] When out-of-band technology is used to obtain the public boot key of another device, the process of obtaining the public boot key is called "bootstrapping." Bootstrapping provides trust in the public boot key because out-of-band technology typically involves proximity or physical association with the registrant's device. For example, bootstrapping may include scanning a Quick key that encodes the public boot key. (QR) codes. Supporting this form of authentication allows certain devices without a user interface (e.g., IoT devices, wearable accessories, home automation devices, etc.) to authenticate using the configurator device.

[0051] Based on the proposed concept(s), DPP can be enhanced to utilize an intermediary device. This intermediary device can act as an intermediary between a registrant device and a configuration device. For example, the intermediary device can facilitate and control "bootstrapping" between the registrant device and the configuration device. The intermediary device can acquire registrant authentication data (e.g., a public boot key) associated with the registrant device and set the registrant authentication data to the configuration device based on the configuration device's state control.

[0052] For example, the intermediary device can receive authentication data associated with the registrant device from a user's smartphone or tablet, and then store the received authentication data in a sorted queue. The intermediary device can then send the authentication data to the registrant device only when the authentication data is at the front of the sorted queue and the registrant device's status allows it to be available and ready to use the authentication data.

[0053] The authentication data associated with the registrant device can be transmitted to the configuration device in the registration request on behalf of the registrant device. Additionally, according to some embodiments, the intermediary device can use a configuration device's private signature key obtained from the configuration device to sign the registration request. In this way, the configuration device can use a configuration device's public verification key corresponding to the configuration device's private signature key to verify the authenticity of the registration request.

[0054] In some implementations, the intermediary device may include legacy equipment. Legacy equipment refers to any device that does not natively support DPP or cannot use DPP for its own network configuration. However, legacy equipment may be able to run client applications capable of communicating with the host service of the registrant device. Therefore, even if the legacy equipment does not implement DPP, client applications running on the legacy equipment can still be used to facilitate control over the registration of the registrant device.

[0055] By way of example only, the proposed embodiments can provide a method for bulk registration of multiple devices based on DPP using an intermediary device such as an intermediary smartphone. The method may include the following main steps at the intermediary device:

[0056] (a) Receive authentication data (e.g., bootstrap key) from the registrant device and queue the associated registration tasks. That is, the intermediary device accepts device registration tasks by receiving authentication data from the registrant and then places the device registration tasks into a task queue.

[0057] (b) Check the status of the configuration device. The intermediary device checks the status of the configuration device by querying the status of the configuration device and / or receiving notifications sent by the configuration device.

[0058] (c) Send authentication data to the configuration device based on the configuration device's status. For example, if the configuration device is in a "completed" or "terminated" state, the intermediary device selects a task from the task queue (if it exists) according to a predefined queuing policy and sends the authentication data of that task to the configuration device.

[0059] (d) If the configuring device is in a state other than "completed" or "terminated", then it enters a hibernation / wait state. For example, if no device has registered a task in the queue, the intermediary device enters a hibernation (e.g., low power) mode.

[0060] (e) When in hibernation mode, the intermediary device wakes up in response to the detection of any predefined event. For example, depending on the event handling policy, the intermediary device may wake up and check the task queue status. If there are pending device registration tasks (i.e., the task queue is not empty), the intermediary device restarts the entire process from step (b) – for example, a new device registration task occurs, the hibernation mode expires, or the configuring device notifies the intermediary device of a status change, etc.

[0061] Instead of the proposed embodiments, the intermediary device may not include an intermediary smartphone, but may instead be implemented as a dedicated device (e.g., a portable registrant device) configured to obtain authentication data directly from multiple registrant devices (i.e., without via an intermediary smartphone / tablet). For example, the interface of the intermediary device may include a short-range communication interface adapted to establish a communication link with and receive authentication data from the registrant devices via the established communication link. Additionally, in some examples, the intermediary device may be integrated into a router (i.e., a network router may include the intermediary device according to the proposed embodiments).

[0062] As can be understood from the above, the proposed embodiments can employ the concept of monitoring the state of the configuration device. Typically, checking the state of the configuration device can be done in two modes: active and passive. Assuming the configuration device provides a state query / check interface, the proposed intermediary device can actively query the state of the configuration device. Alternatively or additionally, the configuration device can broadcast its state change (e.g., via broadcast notification), and the intermediary device can passively listen for this state change.

[0063] Now for reference Figure 1 A simplified diagram depicts an exemplary embodiment of an intermediary device 100 for registering multiple registration devices to a wireless network according to DPP control.

[0064] The intermediary device 100 is configured to enable bulk registration of the registrant device 110 based on DPP. Specifically, in this example, the intermediary device includes an interface 134, a status component 140, and a communication component 144.

[0065] Interface 134 is configured to acquire authentication data associated with each of the plurality of registrant devices 110. More specifically, interface 134 is provided by legacy device 130 (i.e., portable computing device 130 (e.g., smartphone or tablet)) and is configured to capture authentication data via an out-of-band method. For example, the camera of smartphone 130 is configured to act as interface 134 controlled to capture a corresponding QR code 105 of registrant device 110. Such a QR code 105 of the registrant device includes boot information (e.g., boot key) in a machine-readable format.

[0066] The status component 140 is configured to determine the status of the configuration device 120 of the wireless network. In this example, the status component includes a monitoring component (in... Figure 1 (Not visible in the image), the monitoring component monitors the operating status of the configuration device 120 in order to determine when the configuration device 120 is in an available state (during which the configuration device 120 can be used to register the registration device 110 to the wireless network).

[0067] Communication component 144 is configured to transmit authentication data associated with one or more of the registrant devices 110 to configuration device 120 based on the determined state of configuration device 120. More specifically, in response to monitoring component 140 determining that configuration device 120 is available, communication component 144 transmits authentication data associated with one or more of the registrant devices 110 to configuration device 120. Conversely, in response to monitoring component 140 determining that configuration device 120 is not available, communication component 144 prevents the transmission of authentication data associated with one or more of the registrant devices 110 to configuration device 120.

[0068] To control which authentication data is transmitted, an exemplary embodiment of the intermediary device 100 may include a queuing component (not shown) configured to store the acquired authentication data in a sorted queue. For example, the queuing component may position the first authentication data associated with the first registrant device in the sorted queue based on one or more factors such as device type, device group, number of failures, etc. That is, queuing rules may be established based on one or more of these (or other) factors. Alternatively or additionally, the user may manually adjust the queuing priority.

[0069] The communication component 144 can then transmit authentication data from the sorted queue based on the order of the authentication data in the queue.

[0070] This method introduces a device registration task queue managed by the intermediary device 100.

[0071] By using the proposed embodiments (e.g., Figure 1 In one embodiment, a user can perform bulk registration of multiple devices 110 simply by providing boot data to the intermediary device 100 without waiting. The intermediary device 100 will then be responsible for (e.g., via smartphone interface 134) receiving the device boot data in bulk and coordinating the configuration device 120 to perform device setup tasks. In other words, the user can simply feed multiple boot data to the intermediary device 100 as quickly as possible without waiting.

[0072] Users will still have the opportunity to check the status of bulk registration for multiple devices at any time in the future.

[0073] It will also be appreciated that the proposed embodiments enable the intermediary device 100 to capture the authentication data of the registrant device 110 via any out-of-band method specified in the DPP specification (e.g., QR code, NFC, and Bluetooth).

[0074] Some embodiments may require the development of communication protocols and the accompanying software and / or hardware for implementing such communication protocols: (a) a first set of communication protocols that define communication between a device and an intermediary device, including (but not limited to) sending authentication data in bulk or in a single transaction and querying the status of bulk registrations of multiple devices; (b) a second set of protocols that regulate communication between an intermediary device and a configuration device, including (but not limited to) sending authentication data and querying or notifying the configuration device of its status.

[0075] To give another example, Figure 2 A flowchart is depicted for a method of registering multiple registrant devices to a wireless network according to DPP control.

[0076] refer to Figure 2 The method begins at step 210: using a smartphone to capture bulk authentication data associated with multiple registrant devices.

[0077] Then, according to the proposed embodiment, in step 220, the captured authentication data is provided from the smartphone to the intermediary device.

[0078] In step 230, the acquired authentication data is stored in a sorted queue according to a predetermined queuing strategy.

[0079] Next, in step 240, the status of the configuration device of the wireless network is determined. This can be done, for example, by sending a status query to the configuration device and / or listening to status signals transmitted by the configuration device.

[0080] Based on the determined state of the configuration device (obtained in step 240), in step 250 it is determined whether the configuration device is in an available state (in which the configuration device can be used to register the registration device to the wireless network). In response to determining that the configuration device is in an available state, the method proceeds to step 260, where authentication data associated with one or more registration devices is selected (based on a queue) and transmitted to the configuration device. Subsequently, in step 270, the configuration device uses the authentication data transmitted to the configuration device in step 260 to perform the registration of the registration device.

[0081] In response to determining that the configuration device is in an available state, the method proceeds from step 250 to step 280, wherein the intermediary device blocks the transmission of authentication data to the configuration device, and the intermediary device enters a sleep mode.

[0082] To return from hibernation mode (i.e., leave), the method includes step 290 of receiving a hibernation expiration event (e.g., after a predetermined amount of time has elapsed and / or after a predetermined event has occurred). In response to receiving the hibernation expiration event in step 290, the method proceeds to step 294, where the state of the queue is determined. Based on the queue state determined (from step 294), it is determined in step 296 whether the queue is empty.

[0083] In response to determining that the queue is empty, the method returns to step 280, where the intermediary device (re-)enters sleep mode. In response to determining that the queue is not empty, the method returns again to step 240.

[0084] In the aforementioned exemplary methods, communication may preferably be configured to be protected using appropriate communication security technologies. The implementation of appropriate secure communication can depend on the deployment relationship between the communication pairs and can be any suitable technology. For example, if the intermediary device and the configuration device are built into the AP's module, then any communication between them that does not leak data to the outside of the AP can be considered an appropriate secure communication mechanism, and remote deployments typically require higher security controls than local deployments.

[0085] Communication between components can utilize local communication technologies, remote communication technologies, or any combination of both. Local communication technologies include, but are not limited to, inter-process communication (IPC), shared memory, and shared data files. Remote communication technologies include, but are not limited to, TCP / IP, HTTP / HTTPS, SMTP, and FTP / FTPS. Any remote communication network can be communicatively coupled to the communication network through one or more gateway devices.

[0086] Therefore, it will be appreciated that there are many different ways to implement the present invention. For example, an AP can be upgraded by incorporating the proposed intermediary device. Moreover, IoT platform operators can implement a cloud-based intermediary device according to the proposed embodiments. Furthermore, smartphones can be configured to include or implement some or all of the proposed intermediary device.

[0087] To give another example, Figure 3An example of computer 300 is illustrated, in which one or more portions of the embodiments may be employed. The various operations discussed above can utilize the capabilities of computer 300. For example, one or more portions of a system for registering multiple registrant devices to a wireless network according to DPP control can be incorporated into any elements, modules, applications, and / or components discussed herein. In this regard, it will be appreciated that system functional blocks can operate on a single computer or can be distributed across multiple computers and locations (e.g., via an Internet connection).

[0088] Computer 300 includes, but is not limited to, PCs, workstations, laptops, PDAs, handheld devices, servers, storage devices, etc. Typically, in terms of hardware architecture, computer 300 may include one or more processors 310, memory 320, and one or more I / O devices 330 communicatively coupled via a local interface (not shown). The local interface can be, for example, but not limited to, one or more buses or other wired or wireless connections as known in the art. The local interface may have additional elements (e.g., controllers, buffers (cache memory), drivers, repeaters, and receivers) to enable communication. Additionally, the local interface may include addressing, control, and / or data connections to enable appropriate communication between the aforementioned components.

[0089] Processor 310 is a hardware device for running software that can be stored in memory 320. Processor 310 can actually be any custom or commercial processor, central processing unit (CPU), digital signal processor (DSP), or auxiliary processor among several processors associated with computer 300, and processor 310 can be a semiconductor-based microprocessor (in the form of a microchip) or microprocessor.

[0090] Memory 320 may include any or a combination of volatile memory elements (e.g., random access memory (RAM), such as dynamic random access memory (DRAM), static random access memory (SRAM), etc.) and non-volatile memory elements (e.g., ROM, erasable programmable read-only memory (EPROM), electronically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic tape, CD-ROM, magnetic disk, floppy disk, cassette, cassette tape, etc.). Furthermore, memory 320 may contain electronic, magnetic, optical, and / or other types of storage media. Note that memory 320 may have a distributed architecture, where various components are geographically separated but accessible by processor 310.

[0091] The software in memory 320 may include one or more individual programs, each of which includes an ordered list of executable instructions for implementing logical functions. According to an exemplary embodiment, the software in memory 320 includes a suitable operating system (O / S) 340, a compiler 340, source code 330, and one or more application programs 370. As shown, the application program 370 includes numerous functional components for implementing the features and operations of the exemplary embodiment. According to an exemplary embodiment, the application program 370 of computer 300 may represent various applications, computing units, logical units, functional units, processes, operations, virtual entities, and / or modules, but the application program 370 is not intended to be limiting.

[0092] Operating system 340 controls the execution of other computer programs and provides scheduling, input-output control, file and data management, memory management, communication control, and related services. The inventors envision that application program 370, used to implement exemplary embodiments, can be applied to all commercial operating systems.

[0093] Application 370 can be a source program, an executable program (object code), a script, or any other entity including a set of instructions to be executed. When it is a source program, the program is typically translated by a compiler (e.g., compiler 340), assembler, interpreter, etc. (these devices may or may not be included in memory 320) to operate correctly with operating O / S 340. Furthermore, application 370 can be written in an object-oriented programming language (with data classes and method classes) or a procedural programming language (with routines, subroutines, and / or functions, such as, but not limited to, C, C++, C#, Pascal, BASIC, API calls, HTML, XHTML, XML, ASP scripts, JavaScript, FORTRAN, COBOL, Perl, Java, ADA, .NET, etc.).

[0094] I / O device 330 may include input devices, such as, but not limited to, a mouse, keyboard, scanner, microphone, camera, etc. Furthermore, I / O device 330 may also include output devices, such as, but not limited to, a printer, monitor, etc. Finally, I / O device 330 may also include devices for transmitting both input and output, such as, but not limited to, a NIC or modulator / demodulator (for accessing remote devices, other files, devices, systems, or networks), radio frequency (RF) or other transceivers, telephone interfaces, bridges, routers, etc. I / O device 330 also includes components for communication over various networks such as the Internet or intranets.

[0095] If the computer 300 is a PC, workstation, intelligent device, etc., then the software in the memory 320 may also include a Basic Input / Output System (BIOS) (omitted for simplicity). The BIOS is a set of basic software routines that initialize and test the hardware at startup, boot the O / S 340, and support data transfer between hardware devices. The BIOS is stored in some type of read-only memory (e.g., ROM, PROM, EPROM, EEPROM, etc.) so that the BIOS can run when the computer 300 starts.

[0096] When the computer 300 is in operation, the processor 310 is configured to run software stored in the memory 320 to transfer data to and from the memory 320, and typically controls the operation of the computer 300 according to the software. Application programs 370 and operating systems 340 are read, possibly cached, and then executed by the processor 310, either wholly or partially.

[0097] When application 370 is implemented in software, it should be noted that application 370 can be stored on virtually any computer-readable medium for use or in conjunction with any computer-related system or method. In the context of this document, a computer-readable medium can be an electronic, magnetic, optical, or other physical device or apparatus capable of containing or storing a computer program for use or in conjunction with a computer-related system or method.

[0098] Application 370 can be implemented on any computer-readable medium for use or in connection with an instruction execution system, apparatus, or device (e.g., a computer-based system, a processor-containing system, or other system capable of retrieving and executing instructions from and from the instruction execution system, apparatus, or device). In the context of this document, "computer-readable medium" can be any means capable of storing, transmitting, disseminating, or transporting a program for use or in connection with an instruction execution system, apparatus, or device. Computer-readable media can be, for example, but not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, devices, or propagation media.

[0099] This invention can be a system, method, and / or computer program product. A computer program product may include a computer-readable storage medium having computer-readable program instructions thereon for causing a processor to execute aspects of the invention.

[0100] A computer-readable storage medium can be a tangible device capable of retaining and storing instructions for use by an instruction execution device. A computer-readable storage medium can be, for example, but not limited to, electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination of the foregoing.

[0101] Aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0102] A single processor or other unit can perform the functions of several items as described in the claims.

[0103] It should be understood that the disclosed methods are computer-implemented methods. Therefore, the concept of a computer program is also proposed, which includes code units for implementing any of the described methods when the program is run on a processing system.

[0104] Technicians will be able to easily develop processors for performing any of the methods described herein. Therefore, each step of the flowchart can represent a different action performed by the processor, and can be executed by the corresponding module of the processor.

[0105] As discussed above, this system utilizes a processor to perform data processing. A processor can be implemented in various ways, using software and / or hardware, to perform a wide range of required functions. A processor typically employs one or more microprocessors, which can be programmed using software (e.g., microcode) to perform the desired functions. A processor can be implemented as a combination of dedicated hardware for performing some functions and one or more programmed microprocessors and associated circuitry for performing other functions.

[0106] Examples of circuits that may be used in various embodiments of this disclosure include, but are not limited to, conventional microprocessors, application-specific integrated circuits (ASICs), and field-programmable gate arrays (FPGAs).

[0107] In various implementations, the processor may be associated with one or more storage media (e.g., volatile and non-volatile computer memories, such as RAM, PROM, EPROM, and EEPROM). The storage media may be encoded with one or more programs that, when run on one or more processors and / or controllers, perform the required functions. The various storage media may be fixed within the processor or controller, or may be portable, allowing one or more programs stored thereon to be loaded into the processor.

[0108] Those skilled in the art, through studying the accompanying drawings, disclosure, and claims, will understand and implement variations of the disclosed embodiments when practicing the claimed invention. In the claims, the word "comprising" does not exclude other elements or steps, and the words "a" or "an" do not exclude multiple. A single processor or other unit can perform the functions of several items recited in the claims. Although certain measures are recited in dissimilar dependent claims, this does not imply that combinations of these measures cannot be advantageously used. Computer programs can be stored / distributed on suitable media (e.g., optical storage media or solid-state media) provided with or as part of other hardware, but can also be distributed in other forms, such as via the Internet or other wired or wireless telecommunications systems. If the term "suitable" is used in the claims or description, it should be noted that the term "suitable" is intended to be equivalent to the term "configured as." No reference numerals in the claims should be construed as limiting the scope.

Claims

1. An intermediary device for controlling the registration of multiple registering devices (110) to a wireless network according to a Device Configuration Protocol (DPP), the intermediary device comprising: Interface (134) is configured to acquire authentication data associated with each of the plurality of registrant devices; A status component (140) is configured to determine the status of the configuration device of the wireless network; as well as A communication component (144) is configured to transmit authentication data associated with one or more of the registering devices to the configuring device based on the determined state of the configuring device.

2. The apparatus according to claim 1, wherein, The status component (140) includes a monitoring component adapted to monitor the operational status of the configuration device to determine when the configuration device is in an available state, during which the configuration device can register registration devices to the wireless network, and wherein the communication component (144) is configured to transmit authentication data associated with one or more registration devices to the configuration device in response to the monitoring component determining that the configuration device is in an available state.

3. The apparatus according to claim 2, wherein, The communication component (144) is configured to prevent the transmission of authentication data associated with one or more of the registering devices to the configuration device in response to the monitoring component determining that the configuration device is not available.

4. The apparatus according to any one of claims 1 to 3, wherein, The interface (134) is configured to intercept authentication data transmitted from the registrant device to the configurator device in the wireless network.

5. The apparatus according to any one of claims 1 to 4, wherein, The interface (134) is provided by a mobile computing device (130) and configured to receive authentication data, the mobile computing device being configured to obtain authentication data from a user or registrant device via the interface.

6. The apparatus according to any one of claims 1-5, further comprising a queuing component configured to store the acquired authentication data in a sorted queue, wherein, The communication component is configured to transmit the authentication data from the sorted queue based on the order of the authentication data in the queue.

7. The apparatus according to claim 6, wherein, The queuing component is configured to locate the first authentication data associated with the first registration device in the sorted queue based on the attributes of the first registration device or a time value associated with the first authentication data.

8. The apparatus according to any one of claims 1 to 7, wherein, The authentication data associated with the registrant's device includes boot information.

9. The apparatus according to any one of claims 1 to 8, wherein, The intermediary device includes legacy devices that do not natively support the device setting protocol, and wherein the communication component is configured to transmit authentication data via the application layer at the intermediary device.

10. A method for controlling the registration of multiple registrant devices to a wireless network according to a Device Configuration Protocol (DPP), the method comprising: At the intermediary device, obtain (210) authentication data associated with each of the plurality of registrant devices; Determine the status of the configuration device of the wireless network (240); and Based on the determined state of the configuration device, authentication data associated with one or more of the registration devices is transmitted (260) to the configuration device.

11. The method according to claim 10, wherein, Determining the state of the configuration device (240) includes monitoring the operational state of the configuration device to determine when the configuration device is in an available state, during which the configuration device can be used to register registration devices to the wireless network, and wherein transmitting authentication (260) data associated with one or more registration devices includes transmitting authentication data associated with one or more registration devices to the configuration device in response to determining that the configuration device is in an available state.

12. The method according to claim 11, wherein, Transmitting (260) authentication data associated with one or more of the registrant devices includes preventing the transmission of authentication data associated with one or more of the registrant devices to the configuration device in response to a monitoring component determining that the configuration device is not in an available state.

13. The method according to any one of claims 10 to 12, further comprising storing (230) the acquired authentication data in a sorted queue, wherein, Transmitting authentication data associated with one or more of the registrant devices includes transmitting the authentication data from the ordered queue based on the order of the authentication data in the queue.

14. The method according to any one of claims 10 to 13, wherein, The intermediary device includes legacy devices that do not natively support the device setting protocol, and wherein transmitting authentication data associated with one or more of the registrant devices includes transmitting authentication data via the application layer at the intermediary device.

15. A computer program product comprising computer program code units, which, when run on a computing device having a processing system, cause the processing system to perform all the steps of the method according to any one of claims 10 to 14.

Images