(19)
(11)EP 3 764 622 B1

(12)EUROPEAN PATENT SPECIFICATION

(45)Mention of the grant of the patent:
27.07.2022 Bulletin 2022/30

(21)Application number: 20181211.2

(22)Date of filing:  19.06.2020
(51)International Patent Classification (IPC): 
H04L 67/00(2022.01)
H04W 12/04(2021.01)
H04W 12/06(2021.01)
H04L 67/12(2022.01)
H04L 9/08(2006.01)
(52)Cooperative Patent Classification (CPC):
H04L 9/0833; H04L 67/12; H04L 67/34; H04W 12/06; H04L 2209/805

(54)

MULTIPLE CLIENT SUPPORT ON DEVICE-BASED LWM2M

UNTERSTÜTZUNG MEHRERER CLIENTS AUF VORRICHTUNGSBASIERTEM LWM2M

SUPPORT À PLUSIEURS CLIENTS SUR LWM2M BASÉ SUR UN DISPOSITIF


(84)Designated Contracting States:
AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

(30)Priority: 11.07.2019 US 201916509209

(43)Date of publication of application:
13.01.2021 Bulletin 2021/02

(73)Proprietor: T-Mobile USA, Inc.
Bellevue, WA 98006 (US)

(72)Inventor:
  • SHARMA, Nandita
    Issaquah, Washington 98029 (US)

(74)Representative: Forresters IP LLP 
Skygarden Erika-Mann-Straße 11
80636 München
80636 München (DE)


(56)References cited: : 
US-A1- 2016 065 556
US-A1- 2018 359 621
  
      
    Note: Within nine months from the publication of the mention of the grant of the European patent, any person may give notice to the European Patent Office of opposition to the European patent granted. Notice of opposition shall be filed in a written reasoned statement. It shall not be deemed to have been filed until the opposition fee has been paid. (Art. 99(1) European Patent Convention).


    Description

    Background



    [0001] The background description provided herein is for the purpose of generally presenting the context of the disclosure. Work of the presently named inventors, to the extent it is described in this background section, as well as aspects of the description that may not otherwise qualify as prior art at the time of filing, are neither expressly nor impliedly admitted as prior art against the present disclosure.

    [0002] Internet of Things (loT) devices may use a lightweight machine-to-machine (LwM2M) protocol for communication with a server. LwM2M may be used to provide device management functionality, to transfer service data between devices and networks, and may be extended to support most applications. However, there are limitations that may impede life-cycle maintenance of certain devices.

    [0003] US2018359621 discloses a method performed in a client device for managing constrained devices, which to at least some extent fail to support a Lightweight Machine to Machine, LWM2M, protocol. The client device is compatible with a LWM2M protocol for communicating with a LWM2M server and comprises a LWM2M controller object for management of any discovered constrained device. The method comprises discovering one or more constrained devices; creating, for each discovered constrained device, a respective LWM2M connected device object, wherein the LWM2M controller object points at the one or more created LWM2M connected device objects; and exposing the LWM2M controller object to the LWM2M server. A method in a server device, client device, server device, computer programs and computer program products are also disclosed.

    [0004] US2016065556 discloses a method of bootstrapping between endpoint client and server in a low power wireless network. The method includes the steps of initiating a bootstrap request from an endpoint client to the server with the bootstrap request including an endpoint client name in an identifier, determining a registry apparatus to be assigned to the endpoint client, accepting the bootstrap request at the server and in response to the bootstrap request providing a security object and an identifier to the endpoint client to identify the assigned registry apparatus.

    Summary



    [0005] Aspects of the present invention are recited by appended independent claims 1 and 12, with the dependent claims reciting optional features.

    [0006] A first loT module bootstrapped in a device may share its credentials with a second loT module that does not have a pre-shared key (PSK) needed for registration with an operational server. The second loT module may use the shared credential along with its own identification information to register with the operational server. Because the second loT module presented the credential of the first loT module, the operational server may associate operations of the two loT modules.

    [0007] A version of the described technology provides a method of bootstrapping a non-native module in a device, the method comprising: providing the device with a native module and a non-native module; contacting a bootstrap server associated with bootstrapping the native module; bootstrapping, via the bootstrap server, the native module using a pre-shared key (PSK) present in the native module; registering the native module to an operational server; establishing communication between the native module and the non-native module; providing a credential from the native module to the non-native module; using the credential, registering the non-native module with the operational server; and placing the non-native module in service as a common endpoint of the native module.

    [0008] The bootstrap server may be a lightweight machine-to-machine (LwM2M) bootstrap server.

    [0009] The operational server may be an LwM2M server.

    [0010] Establishing communication between the native module and the non-native module may comprise activating a service in the non-native module to discover the native module.

    [0011] Establishing communication between the native module and the non-native module may comprise polling by the native module to discover the non-native module.

    [0012] Providing the credential from the native module to non-native module may comprise: requesting the credential from the native module by the non-native module; and responding, by the non-native module, to a challenge presented by the native module, the challenge requiring input from a user.

    [0013] Providing the credential from the native module to non-native module may comprise: receiving the credential from the native module responsive to discovery of the non-native module by the native module.

    [0014] Placing the non-native module in service as an extension of the native module may comprise associating, at the operational server, the native module and the non-native module as a common endpoint.

    [0015] The method may further comprise providing, by the native module, an identification message to the operational server, the identification message corresponding to the non-native module.

    [0016] The identification message may include the credential from the native module and an identifier of the non-native module.

    [0017] Placing the non-native module into service may comprise installing a key into the non-native module, the key associated with the operational server.

    [0018] A version of the described technology provides a device for use in an Internet-of-Things (IoT) application, the device comprising: a native module including: an native operational function; a native communication sub-module coupled to the native operational function that communicates with at least one external server; a native secure storage area storing at least one pre-shared key; and a sponsorship sub-module that determines a presence of a non-native module and supports bootstrapping the non-native module; the non-native module including: an operational function; a memory storing at least a non-native module identifier; a communication sub-module that communicates with the at least one external server; and a bootstrap sub-module that communicates with the sponsorship sub-module, the bootstrap sub-module receiving a credential from the native communication sub-module and communicating the credential and the non-native module identifier to the at least one external server.

    [0019] The device may further comprise a universally unique hardware identifier used by the bootstrap sub-module for communication with the at least one external server.

    [0020] The native operational function may include at least one of a sensor or an actuator.

    [0021] The non-native module may be coupled to at least one of a sensor or an actuator in the device.

    [0022] A version of the described technology provides a method of bootstrapping a non-native module in a lightweight machine-to-machine (LwM2M) device, the method comprising: providing the LwM2M device with a native module and a non-native module; contacting a bootstrap server associated with bootstrapping the native module using an LwM2M protocol; bootstrapping, via the bootstrap server, the native module using a pre-shared key (PSK) present in the native module; registering the native module to an LwM2M operational server; establishing communication between the native module and the non-native module; providing a credential from the native module to the non-native module; using the credential, registering the non-native module with the LwM2M operational server; and placing the non-native module in service in the LwM2M device as a common endpoint with the native module.

    [0023] The credential provided from the native module to the non-native module may be encrypted using a key shared between the native module and the LwM2M operational server.

    [0024] The credential provided from the native module to the non-native module may be encrypted using the PSK.

    [0025] Registering the non-native module with the LwM2M operational server may comprise sending a registration message from the non-native module to the LwM2M operational server, the registration message including the credential from the native module and an identifier of the non-native module.

    [0026] The registration message may further include a hardware identifier of the LwM2M device.

    Brief Description of the Drawings



    [0027] The figures depict a preferred embodiment, by way of example, for purposes of illustration only. One skilled in the art may readily recognize from the following discussion that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles described herein.

    Fig. 1 is a system illustration of an embodiment of an loT device having multiple functional modules in accordance with the current disclosure; and

    Fig. 2 is a flowchart of a method of multi-client support for an LwM2M device in accordance with the current disclosure.


    Detailed Description



    [0028] LwM2M is a protocol from the Open Mobile Alliance for use in machine-to-machine and Internet of Things device management. LwM2M defines an application layer communication protocol between an LwM2M server and a LwM2M client located on an LwM2M device. The protocol is well suited for resource-constrained devices, which includes many loT devices. While the descriptions below are directed to an exemplary implementation incorporating LwM2M-based protocols, the techniques described therein are equally applicable to other protocols and devices that may require multiple client support in a device.

    [0029] Bootstrapping, as defined by the IoT@Work project, is the process by which the state of the device, a subsystem, network, or an application changes from not operational to operational. For the purpose of this disclosure, bootstrapping will be considered to include obtaining and installing elements including, but not limited to, secret keys and a server URL. This provisioning process allows authentication and communication with the servers necessary so that an loT device to perform its designated function or functions. This may involve authentication of a pre-established identity or creation of a new identity. Using a non-loT example corresponding to bootstrapping, a user wishing to create and use a new email address must first navigate to the website supporting the registration process. The user must then create a unique identifier and select a password for the account. Thereafter, the user can enter the user name and password to access the email account. These two steps may be considered bootstrapping while composing, sending, and accessing emails may be considered use of the email service. Bootstrapping for an loT device may include authentication to a network as well as receiving authorization and credentials used for later secure communication during beneficial use.

    [0030] Fig. 1 illustrates an exemplary device 100 that supports operation of one or more loT modules 104, 120. A lightweight machine-to-machine (LwM2M) server 102 may support both the bootstrapping and operation of the loT modules 104, 120 via a bootstrap server 130 and an operational server 132. In an embodiment, the LwM2M server 102 may include support for one or more applications or services, such as a thermostat, a home security system, a kitchen appliance, an automobile sub-system or any of a number of commercial and industrial applications, to name a few possible examples.

    [0031] The loT native module 104 may support a client application or service (native function 106) and may bootstrap with a bootstrap server 130 using a native communication function 108. The native communication function 108 may be or include WiFi (802,11), Bluetooth, cellular data, or a combination of these or another communication network and protocol. In some embodiments, a pre-shared key (PSK) 111 may be stored in a secure memory 110. The PSK 111 may be embodied in a certificate associated with the native application 106 and may be installed in the device 100 at the time of manufacture. Presentation of the PSK 111 over a secure network connection via the communication function 108 may provide the bootstrap server 130 with a basis for a trust relationship with the native function 106 supported by the first module 104. Once the device 100 is in the field, the module 104 may use the PSK 111 to bootstrap the appropriate credentials and/or additional keys to connect to an operational server. The additional credentials provided during bootstrapping may include a URL or network address of the operational server 132. Additional keys may allow a secure network connection including authentication between the first module 104 and the operational server 132. After the bootstrapping is completed and the module 104 is connected to the operational server 132, beneficial operation may commence, such as reporting temperature and maintenance status for a kitchen refrigerator. Other examples abound.

    [0032] To expand on the bootstrapping operation, the module 104 may send a message "A1" to the bootstrap server 130 and may use the PSK 111 for authentication and establishment of a secure channel. The bootstrap server 130, after this initial protocol, may send data to the module 104 in a message "A2" that may include the necessary operational data including new keys known to or shared with the operational server 132. The A2 message may also include a URL or network address so that the module 104 knows how to contact the operational server 132. With this information and the new keys, the module 104 may contact the operational server 132, establish its identity and begin to operate in its intended mode.

    [0033] In some cases, however, a new module 120 may be introduced to the device 100, especially after the time of manufacture when a corresponding PSK would have been installed. The new module 120 may be introduced through a field update of the device 100 or activation of a latent capability post-manufacture, either at a dealership or distributor before delivery to an end-user. Alternatively, the new module 120 may be the result of the end-user installing a new feature or performing an upgrade of the device 100. Similar to the first or native module 104, the second module 120 may include an operational function 122, a communication function 124, storage 126 that may include secure storage, and a bootstrapping sub-module 128. In some cases, the new module 120 may not have a PSK to authenticate to either the bootstrap server 130 or the operational server 132. The lack of a PSK may be due to any number of reasons, including but not limited to, the second module 120 was not contemplated at the time of manufacture or the second module 120 is from another developer not associated with the original manufacturer.

    [0034] This second module 120 may have no knowledge of its surroundings at the time of installation making it difficult for the module 120 to have accurate information for bootstrapping let alone operational functions. In such a case, the first module 104 may be able to detect and support the second module 120 via a sponsorship sub-module 112. In various embodiments, the discovery of the new second module 120 may follow many forms. For example, the native first module 104 may periodically attempt to discover the second module 120 via a polling operation or other discovery technique.

    [0035] Similarly, the second module 120 may have a bootstrap sub-module 128 that supports discovery of the first module 104. This also may include polling or broadcasting over an internal bus or via a wireless network. In this regard, the device 100 may include a hardware identifier 129 or other universally unique identifier (UUID) may be used by both modules 104, 120 to identify each's actual affiliation so that modules across devices become incorrectly associated. For example, a shopping list function of a refrigerator may want to avoid affiliation with a home security system because the associated operational server 132 may not support both functions.

    [0036] After discovery, the sponsorship sub-module 112 of the native first module 104 may send a credential to the bootstrap sub-system of the new non-native module 120 via a message "B1." The credential may be encrypted with a shared key or signed with a private key of the first module 104. The B1 message may also include the URL or other address of the operational server 132 for use by the second module 120. In other embodiments, the B1 message may include a nonce or other credential that is secured using the original PSK 111 embedded in the module 104 at the time of manufacture. This other credential may be used for further authentication of the registration request message from the second module 104, discussed immediately below.

    [0037] Once the B1 message is received, the second module 120 may generate a request for registration message "B2." The B2 message may include the secured credential from the native first module 104 (and/or the other credential discussed above) and an identifier of the second module 104. The identifier may be or include a make/model number that can be used to ascertain the functions and capabilities of the second module 120. Additional information may be included in the B2 message, such as initial components for a Diffie-Hellman key exchange.

    [0038] After the receipt of the B2 message, the operational server 132 may process the message and approve the addition of the second module 120 to the device 100. The information in the B2 message may be used to determine capabilities and message protocols for the second module 120. If no capability information can be determined or if the second module is on a block list, the request for registration may be denied and further communication from the second module 120 may be ignored or blocked. Further, the operational server 132 may send a message to the first module 104 to block or ignore further communication with the second module 120.

    [0039] Because the contents of the B2 message from the second module 120 may be used as proof of association with the first module 104, the operational server 132 may treat the two modules 104, 120 as a single endpoint. In one embodiment, the second module may use the operational keys from the first module 104 for subsequent message transmissions. In another embodiment, the operational server 132 may generate new keys for the second module 120 or may request new keys from the bootstrap server 130, for example, referencing the PSK 111 optionally included in the B1 message. Once the new keys are installed in the second module 120, beneficial use of the second module may commence.

    [0040] In an embodiment, the first module 104 may optionally send a pre-registration message "B3" to the operational server 132. The B3 message may be sent securely, for example, encrypted and signed, so that the operational server 132 may expect a future registration request from the second module 120. This direct message from the first module 104 to the second module 120 may have a higher level of trust because it has not been handled by the third party second module 120. Alternatively, the B3 message may be requested by the operational server 132 after B2 message is received from the second module 120. That is, the operational server 132 may contact the first module 104 after receipt of the B2 message as a way to confirm the association of the two modules 104, 120 as a single endpoint. This may help reduce the risk of a rogue module (not depicted) from gaining unauthorized access to the device 100 via the operational server 132.

    [0041] Fig. 2 is a flowchart of an exemplary method 200 of providing multiple client support in an LwM2M environment. At block 202, a device 100 may be provided. The device 100 may include a first module 104 and a second module 120, each of which may support a function that interacts with the physical world. Such Internet of Things (IoT) devices may have sensors that collect data about an environment around them or may have actuators that interact with physical components in their environments. An loT thermostat may be an example of one such device. Sensors determine the temperature of the environment and actuators control an HVAC unit to change the temperature to a set point. In an loT device, communication with an external server may provide enhanced features such as outdoor temperatures for better modulation of temperature or data logging for determining energy usage.

    [0042] loT devices are in place or planned for an almost limitless array of real-world devices, from appliances to automobiles to cameras to industrial controllers and more. As discussed above, some devices 100 may be provisioned with a first or native loT module 104. The module 104 may support the basic function of the module 104, for example, the exemplary thermostat. The native module 104 may include a pre-shared key (PSK) 111 for use in a process called bootstrapping. Bootstrapping, as discussed above, places the loT device 100 into an operational state.

    [0043] In some cases, an additional module 120 may be added or activated in the device 100 that was not originally provisioned. For example, a camera in the thermostat that was originally used to detect motion and sun load may be re-provisioned for home security. Such a new, non-native module 120 may not have the pre-provisioned keys required for bootstrapping. The method discussed below may be used to both place a non-native module 120 into service and to associate the non-native module 120 with the native module 104.

    [0044] At block 204, the native module 104 may contact a bootstrapping server 130 using a pre-shared key (PSK) 111. The PSK 111 may be used for authentication and to secure a communication channel with the bootstrapping server 130. After authenticating and opening a communication channel, the bootstrapping server 130 may, at block 206, provide operational credentials to the native module 104. The operating credentials may include keys and an address for contacting and interacting with an operational server 132. The operational server 132, at block 208, may support beneficial use of the native module 104, for example using the thermostat, by providing external temperatures and logging HVAC cycles for cataloging energy usage. The operational server 132 may also support code updates to the native module 104.

    [0045] At block 210, the native module 104 may check for a new, non-native module 120. As discussed above, the discovery process may originate in either direction. If no new module is present, execution may continue at block 208. If a new module is detected, execution may follow the 'yes' branch to block 212 where credentials from the native module 104 may be shared with the non-native module 120. Optionally, at block 214, information about the non-native module 120 may be shared with the operational server 132.

    [0046] At block 216, the non-native module 120 may use the credentials provided by the native module 104 for registration with the operational server 132. Because the non-native module 120 uses the credentials from the native module 104 for its registration, the operational server 132 may associate the two modules 104, 120 as a single endpoint for subsequent operations, at block 218.

    [0047] At least one technical effect is the ability to install and register additional functions in an loT device 100 via a second module 120, where the second module 120 uses credentials from the first module for access to an operational server 132. This provides flexibility to expand the functions of the loT device 100 over those originally provisioned with the device 100 at the time of manufacture. This may both extend the capabilities of the loT device 100 as well as increase its service life through the post-manufacture installation of features and functions that may not have been contemplated at the time of manufacture.

    [0048] The current system and method benefit both users and system providers by allowing field upgrades to loT devices that, unlike a simple software update, allows the loT device to perform new functions potentially using modules from manufacturers other than that of the loT device itself.

    [0049] The figures depict preferred embodiments for purposes of illustration only. One skilled in the art will readily recognize from the following discussion that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles described herein.

    [0050] Upon reading this disclosure, those of skill in the art will appreciate still additional alternative structural and functional designs for the systems and methods described herein through the disclosed principles herein. Thus, while particular embodiments and applications have been illustrated and described, it is to be understood that the disclosed embodiments are not limited to the precise construction and components disclosed herein. Various modifications, changes and variations, which will be apparent to those skilled in the art, may be made in the arrangement, operation and details of the systems and methods disclosed herein without departing from the scope defined in any appended claims.

    [0051] When used in this specification and claims, the terms "comprises" and "comprising" and variations thereof mean that the specified features, steps or integers are included. The terms are not to be interpreted to exclude the presence of other features, steps or components.

    [0052] The features disclosed in the foregoing description, or the following claims, or the accompanying drawings, expressed in their specific forms or in terms of a means for performing the disclosed function, or a method or process for attaining the disclosed result, as appropriate, may, separately, or in any combination of such features, be utilised for realising the invention in diverse forms thereof.

    [0053] Although certain example embodiments of the invention have been described, the scope of the appended claims is not intended to be limited solely to these embodiments. The claims are to be construed literally, purposively, in accordance with Art. 69 EPC.


    Claims

    1. A method of bootstrapping a non-native module (120) in a device (100), the method comprising:

    providing the device (100) with a native module (104) and a non-native module (120);

    from the native module (104), contacting a bootstrap server (130) associated with bootstrapping the native module (104);

    bootstrapping, via the bootstrap server (130), the native module (104) using a pre-shared key (PSK) present in the native module (104);

    registering the native module (104) to an operational server (132);

    establishing communication between the native module (104) and the non-native module (120);

    providing a credential from the native module (104) to the non-native module (120);

    from the non-native module (120), sending a message using the credential of the native module (104) and including a non-native module identifier, to register the non-native module (120) with the operational server (132); and

    placing the non-native module (120) in service as a common endpoint of the native module (104).


     
    2. The method of claim 1, wherein the bootstrap server (130) is a lightweight machine-to-machine (LwM2M) bootstrap server (130) and wherein, optionally, the operational server (132) is an LwM2M server.
     
    3. The method of any preceding claim, wherein establishing communication between the native module (104) and the non-native (120) module comprises activating a service in the non-native module (120) to discover the native module (104).
     
    4. The method of any of claims 1-2, wherein establishing communication between the native module (104) and the non-native module (120) comprises polling by the native module (104) to discover the non-native module (120).
     
    5. The method of any of preceding claim, wherein providing the credential from the native module (104) to non-native module (120) comprises:

    requesting the credential from the native module (104) by the non-native module (120); and

    responding, by the non-native module (120), to a challenge presented by the native module (103), the challenge requiring input from a user.


     
    6. The method of any of claims 1-4, wherein providing the credential from the native module (104) to non-native module (120) comprises:
    receiving the credential from the native module (104) responsive to discovery of the non-native module (120) by the native module (104).
     
    7. The method of any preceding claim, wherein placing the non-native module (120) in service as an extension of the native module (104) comprises associating, at the operational server, the native module (104) and the non-native module (120) as a common endpoint.
     
    8. The method of any preceding claim, further comprising providing, by the native module (104), an identification message to the operational server (132), the identification message corresponding to the non-native module (120), and wherein, optionally, the identification message includes the credential from the native module and an identifier of the non-native module (120).
     
    9. The method of any preceding claim, wherein placing the non-native module (120) into service comprises installing a key into the non-native module (120), the key associated with the operational server (132).
     
    10. The method of claim 1, wherein:

    the device (100) is a lightweight machine-to-machine (LwM2M) device (100);

    contacting the bootstrap server (130) associated with bootstrapping the native module (104) comprises: contacting the bootstrap server (130) associated with bootstrapping the native module (104) using an LwM2M protocol;

    registering the native module (104) to the operational server (132) comprises: registering the native module (104) to an LwM2M operational server (132);

    from the non-native module (120), sending a message using the credential of the native module (104) and including a non-native module identifer, to register the non-native module (120) with the operational server (132) comprises: using the credential of the native module (104), registering the non-native module (120) with the LwM2M operational server (132); and

    placing the non-native module (120) in service as the common endpoint of the native module (104) comprises: placing the non-native module (120) in service in the LwM2M device (100) based on the credential of the native module (104) as the common endpoint with the native module (104).


     
    11. The method of claim 10, wherein:

    the credential provided from the native module (104) to the non-native module (120) is encrypted using a key shared between the native module (104) and the LwM2M operational server (132); AND/OR

    the credential provided from the native module (104) to the non-native module (120) is encrypted using the PSK; AND/OR

    registering the non-native module (120) with the LwM2M operational server (132) comprises sending a registration message from the non-native module (120) to the LwM2M operational server (132), the registration message including the credential from the native module (104) and an identifier of the non-native module (120); AND/OR
    registering the non-native module (120) with the LwM2M operational server (132) comprises sending a registration message from the non-native module (120) to the LwM2M operational server (132), the registration message including the credential from the native module (104) and an identifier of the non-native module (120), and wherein the registration message further includes a hardware identifier of the LwM2M device (100).


     
    12. A device (100) for use in an Internet-of-Things (IoT) application, the device comprising:

    a native module (104) including:

    an native operational function (106);

    a native communication sub-module (108) coupled to the native operational function (104) that communicates with at least one external server (102);

    a native secure storage area (110) storing at least one pre-shared key (111); and

    a sponsorship sub-module (112) that determines a presence of a non-native module (120) and supports bootstrapping the non-native module (120);

    the non-native module (120) including:

    an operational function (122);

    a memory (126) storing at least a non-native module identifier;

    a communication sub-module (124) that communicates with the at least one external server (102); and

    a bootstrap sub-module (128) that communicates with the sponsorship sub-module (112), the bootstrap sub-module (128) receiving a credential from the native communication sub-module (108) and communicating the credential and the non-native module (120) identifier to the at least one external server (102) for registration.


     
    13. The device of claim 12, further comprising a universally unique hardware identifier used by the bootstrap sub-module (128) for communication with the at least one external server (100).
     
    14. The device of claim 12 or 13, wherein the native operational function (106) includes at least one of a sensor or an actuator.
     
    15. The device of any of claims 12-14, wherein the non-native module (120) is coupled to at least one of a sensor or an actuator in the device (100).
     


    Ansprüche

    1. Verfahren zum Bootstrapping eines nicht-nativen Moduls (120) in einer Vorrichtung (100), wobei das Verfahren Folgendes umfasst:

    Bereitstellen der Vorrichtung (100) mit einem nativen Modul (104) und einem nicht-nativen Modul (120),

    von dem nativen Modul (104), Kontaktieren eines Bootstrap-Servers (130), der mit dem Bootstrapping des nativen Moduls (104) in Verbindung steht,

    Bootstrapping des nativen Moduls (104) mit Hilfe eines Pre-Shared Keys (PSK), der in dem nativen Modul (104) vorhanden ist, mittels des Bootstrap-Servers (130),

    Registrieren des nativen Moduls (104) an einem operativen Server (132),

    Einrichten einer Kommunikation zwischen dem nativen Modul (104) und dem nicht-nativen Modul (120),

    Bereitstellen eines Berechtigungsnachweises von dem nativen Modul (104) für das nicht-native Modul (120),

    von dem nicht-nativen Modul (120), Senden einer Nachricht mit Hilfe des Berechtigungsnachweises des nativen Moduls (104) und Einbinden einer Kennung des nicht-nativen Moduls, um das nicht-native Modul (120) bei dem operativen Server (132) zu registrieren, und

    In-Betrieb-Nehmen des nicht-nativen Moduls (120) als einen gemeinsamen Endpunkt des nativen Moduls (104).


     
    2. Verfahren nach Anspruch 1, wobei der Bootstrap-Server (130) LwM2M(Lightweight Machine-to-Machine)-Bootstrap-Server (130) ist und wobei der operative Server (132) optional ein LwM2M-Server ist.
     
    3. Verfahren nach einem der vorhergehenden Ansprüche, wobei das Einrichten einer Kommunikation zwischen dem nativen Modul (104) und dem nicht-nativen (120) Modul das Aktivieren eines Dienstes in dem nicht-nativen Modul (120) umfasst, um das native Modul (104) zu erkennen.
     
    4. Verfahren nach einem der Ansprüche 1 bis 2, wobei das Einrichten einer Verbindung zwischen dem nativen Modul (104) und dem nicht-nativen (120) Modul das Polling durch das native Modul (104) umfasst, um das nicht-native Modul (120) zu erkennen.
     
    5. Verfahren nach einem der vorhergehenden Ansprüche, wobei das Bereitstellen des Berechtigungsnachweises von dem nativen Modul (104) für das nicht-native Modul (120) Folgendes umfasst:

    Anfordern des Berechtigungsnachweises von dem nativen Modul (104) durch das nicht-native Modul (120) und

    Antworten auf eine von dem nativen Modul (103) gestellte Aufgabe durch das nicht-native Modul (120), wobei die Aufgabe eine Eingabe von einem Benutzer erfordert.


     
    6. Verfahren nach einem der Ansprüche 1 bis 4, wobei das Bereitstellen des Berechtigungsnachweises von dem nativen Modul (104) für das nicht-native Modul (120) Folgendes umfasst:
    Empfangen des Berechtigungsnachweises von dem nativen Modul (104) in Reaktion auf das Erkennen des nicht-nativen Moduls (120) durch das native Modul (104).
     
    7. Verfahren nach einem der vorhergehenden Ansprüche, wobei das In-Betrieb-Nehmen des nicht-nativen Moduls (120) als eine Erweiterung des nativen Moduls (104) das Verbinden des nativen Moduls (104) und des nicht-nativen Moduls (120) zu einem gemeinsamen Endpunkt an dem operativen Server umfasst.
     
    8. Verfahren nach einem der vorhergehenden Ansprüche, ferner das Bereitstellen einer Identifizierungsnachricht an den operativen Server (132) durch das native Modul (104) umfassend, wobei die Identifizierungsnachricht dem nicht-nativen Modul (120) entspricht und wobei die Identifizierungsnachricht optional den Berechtigungsnachweis von dem nativen Modul und eine Kennung des nicht-nativen Moduls (120) beinhaltet.
     
    9. Verfahren nach einem der vorhergehenden Ansprüche, wobei das In-Betrieb-Nehmen des nicht-nativen Moduls (120) das Installieren eines Schlüssels in dem nicht-nativen Modul (120) umfasst, wobei der Schlüssel mit dem operativen Server (132) in Verbindung steht.
     
    10. Verfahren nach Anspruch 1, wobei:

    die Vorrichtung (100) eine LwM2M(Lightweight Machine-to-Machine)-Vorrichtung(100) ist,

    das Kontaktieren des Bootstrap-Servers (130), der mit dem Bootstrapping des nativen Moduls (104) in Verbindung steht, Folgendes umfasst: Kontaktieren des Bootstrap-Servers (130), der mit dem Bootstrapping des nativen Moduls (104) in Verbindung steht, mit Hilfe eines LwM2M-Protokolls,

    das Registrieren des nativen Moduls (104) an dem operativen Server (132) Folgendes umfasst: Registrieren des nativen Moduls (104) an einem operativen LwM2M-Server (132),

    das Senden einer Nachricht von dem nicht-nativen Modul (120) mit Hilfe des Berechtigungsnachweises des nativen Moduls (104) und das Einbinden einer Kennung des nicht-nativen Moduls zum Registrieren des nicht-nativen Moduls (120) an dem operativen Server (132) Folgendes umfasst: Verwenden des Berechtigungsnachweises des nativen Moduls (104), Registrieren des nicht-nativen Moduls (120) an dem operativen LwM2M-Server (132), und

    das In-Betrieb-Nehmen des nicht-nativen Modul (120) als den gemeinsamen Endpunkt des nativen Moduls (104) Folgendes umfasst: In-Betrieb-Nehmen des nicht-nativen Moduls (120) in der LwM2M-Vorrichtung (100) als den gemeinsamen Endpunkt mit dem nativen Modul (104) basierend auf dem Berechtigungsnachweis des nativen Moduls (104).


     
    11. Verfahren nach Anspruch 10, wobei:

    der von dem nativen Modul (104) für das nicht-native Modul (120) bereitgestellte Berechtigungsnachweis mit Hilfe eines Schlüssels verschlüsselt wird, der von dem nativen Modul (104) und dem operativen LwM2M-Server (132) gemeinsam verwendet wird, UND/ODER

    der von dem nativen Modul (104) für das nicht-native Modul (120) bereitgestellte Berechtigungsnachweis mit Hilfe des PSK verschlüsselt wird UND/ODER das Registrieren des nicht-nativen Moduls (120) an dem operativen LwM2M-Server (132) das Senden einer Registrierungsnachricht von dem nicht-nativen Modul (120) an den operativen LwM2M-Server (132) umfasst, wobei die Registrierungsnachricht den Berechtigungsnachweis von dem nativen Modul (104) und

    eine Kennung des nicht-nativen Moduls (120) beinhaltet, UND/ODER das Registrieren des nicht-nativen Moduls (120) an dem operativen LwM2M-Server (132) das Senden einer Registrierungsnachricht von dem nicht-nativen Modul (120) an den operativen LwM2M-Server (132) umfasst, wobei die Registrierungsnachricht den Berechtigungsnachweis von dem nativen Modul (104) und

    eine Kennung des nicht-nativen Moduls (120) beinhaltet und wobei die Registrierungsnachricht ferner eine Hardware-Kennung der LwM2M-Vorrichtung (100) beinhaltet.


     
    12. Vorrichtung (100) zur Verwendung in einer Internet-der-Dinge(IoT-)Anwendung, wobei die Vorrichtung Folgendes umfasst:

    ein natives Modul (104), das Folgendes beinhaltet:

    eine native operative Funktion (106),

    ein natives Kommunikationsteilmodul (108), das mit der nativen operativen Funktion (104) gekoppelt ist, die mit mindestens einem externen Server (102) kommuniziert,

    einen nativen sicheren Speicherbereich (110), der mindestens einen Pre-Shared Key (111) speichert, und

    ein Förderungsteilmodul (112), das ein Vorhandensein eines nicht-nativen Moduls (120) bestimmt und das Bootstrapping des nicht-nativen Moduls (120) unterstützt,

    das nicht-native Modul (120), das Folgendes beinhaltet:

    eine operative Funktion (122),

    einen Kurzzeitspeicher (126), der mindestens eine Kennung des nicht-nativen Moduls speichert,

    ein Kommunikationsteilmodul (124), das mit dem mindestens einen externen Server (102) kommuniziert, und

    ein Bootstrap-Teilmodul (128), das mit dem Förderungsteilmodul (112) kommuniziert, wobei das Bootstrap-Teilmodul (128) einen Berechtigungsnachweis von dem nativen Kommunikationsteilmodul (108) empfängt und den Berechtigungsnachweis und die Kennung des nicht-nativen Moduls (120) zwecks Registrierung an den mindestens einen externen Server (102) kommuniziert.


     
    13. Vorrichtung nach Anspruch 12, ferner eine Hardware-UUID (Universally Unique Identifier) umfassend, die durch das Bootstrap-Teilmodul (128) für die Kommunikation mit dem mindestens einen externen Server (100) verwendet wird.
     
    14. Vorrichtung nach Anspruch 12 oder 13, wobei die native operative Funktion (106) einen Sensor und/oder einen Aktuator beinhaltet.
     
    15. Vorrichtung nach einem der Ansprüche 12 bis 14, wobei das nicht-native Modul (120) mit einem Sensor und/oder einem Aktuator in der Vorrichtung (100) gekoppelt ist.
     


    Revendications

    1. Un procédé d'amorçage d'un module non-natif (120) dans un dispositif (100), le procédé comprenant les étapes comprenant :

    doter le dispositif (100) d'un module natif (104) et un module non-natif (120) ;

    depuis le module natif (104), contacter un serveur d'amorçage (130) associé à l'amorçage du module natif (104) ;

    amorcer, via le serveur d'amorçage (130), le module natif (104) en utilisant une clé pré-partagée (PSK) présente dans le module natif (104) ;

    enregistrer le module natif (104) sur un serveur opérationnel (132) ;

    établir la communication entre le module natif (104) et le module non-natif (120) ;

    fournir un justificatif d'identité du module natif (104) au module non-natif (120) ;

    depuis le module non-natif (120), envoyer un message utilisant le justificatif d'identité du module natif (104) et incluant un identifiant de module non-natif, pour enregistrer le module non-natif (120) sur le serveur opérationnel (132) ; et

    mettre en service le module non-natif (120) en tant que point d'extrémité commun du module natif (104).


     
    2. Le procédé de la revendication 1, dans lequel le serveur d'amorçage (130) est un serveur d'amorçage léger de machine-à-machine (LwM2M) (130) et dans lequel, éventuellement, le serveur opérationnel (132est un serveur LwM2M.
     
    3. Le procédé de n'importe quelle revendication précédente, dans lequel l'établissement de la communication entre le module natif (104) et le module non-natif (120) comprend l'activation d'un service dans le module non-natif (120) pour découvrir le module natif (104).
     
    4. Le procédé de n'importe laquelle des revendications 1-2, dans lequel l'établissement de la communication entre le module natif (104) et le module non-natif (120) comprend une interrogation par le module natif (104) pour découvrir le module non-natif (120).
     
    5. Le procédé de n'importe quelle revendication précédente, dans lequel la fourniture du justificatif d'identité du module natif (104) au module non-natif (120) comprend :

    la demande du justificatif d'identité au module natif (104) par le module non-natif (120) ; et

    la réponse, par le module non-natif (120), à un défi présenté par le module natif (103), le défi nécessitant une entrée d'un utilisateur.


     
    6. Le procédé de n'importe laquelle des revendications 1-4, dans lequel la fourniture du justificatif d'identité du module natif (104) au module non-natif (120) comprend :
    la réception du justificatif d'identité du module natif (104) en réponse à la découverte du module non-natif (120) par le module natif (104).
     
    7. Le procédé de n'importe quelle revendication précédente, dans lequel la mise en service du module non-natif (120) en tant qu'extension du module natif (104) comprend l'association, au niveau du serveur opérationnel, du module natif (104) et du module non-natif (120) en tant que point d'extrémité commun.
     
    8. Le procédé de n'importe quelle revendication précédente, comprenant en sus la fourniture, par le module natif (104), d'un message d'identification message au serveur opérationnel (132), le message d'identification correspondant au module non-natif (120), et dans lequel, éventuellement, le message d'identification message comprend le justificatif d'identité du module natif et un identifiant du module non-natif (120).
     
    9. Le procédé de n'importe quelle revendication précédente, dans lequel la mise en service du module non-natif (120) comprend l'installation d'une clé dans le module non-natif (120), la clé étant associée au serveur opérationnel (132).
     
    10. Le procédé de la revendication 1, dans lequel

    le dispositif (100) est un dispositif léger de machine-à-machine (LwM2M) (100) ; contacter le serveur d'amorçage (130) associé à l'amorçage du module natif (104) comprend : contacter le serveur d'amorçage (130) associé à l'amorçage du module natif (104) en utilisant un protocole LwM2M ;

    enregistrer le module natif (104) sur le serveur opérationnel (132) comprend : enregistrer le module natif (104) sur un serveur opérationnel LwM2M (132) ;

    depuis le module non-natif (120), envoyer un message utilisant le justificatif d'identité du module natif (104) et comprenant un identifiant du module non-natif, pour enregistrer le module non-natif (120) sur le serveur opérationnel (132) comprend : utiliser le justificatif d'identité du module natif (104), enregistrer le module non-natif (120) sur le serveur opérationnel LwM2M (132) ; et

    mettre en service le module non-natif (120) en tant que point d'extrémité commun du module natif (104) comprend : mettre en service le module non-natif (120) dans le dispositif LwM2M (100) sur la base du justificatif d'identité du module natif (104) en tant que point d'extrémité commun avec le module natif (104).


     
    11. Le procédé de la revendication 10, dans lequel

    le justificatif d'identité fourni du module natif (104) au module non-natif (120) est crypté en utilisant une clé partagée entre le module natif (104) et le serveur opérationnel LwM2M (132) ; ET/OU

    le justificatif d'identité fourni du module natif (104) au module non-natif (120) est crypté en utilisant le PSK ; ET/OU

    l'enregistrement du module non-natif (120) sur le serveur opérationnel LwM2M (132) comprend l'envoi d'un message d'enregistrement du module non-natif (120) au serveur opérationnel LwM2M (132), le message d'enregistrement comprenant le justificatif d'identité du module natif (104) et un identifiant du module non-natif (120) ; ET/OU l'enregistrement du module non-natif (120) sur le serveur opérationnel LwM2M (132) comprend l'envoi d'un message d'enregistrement du module non-natif (120) au serveur opérationnel LwM2M (132), le message d'enregistrement comprenant le justificatif d'identité du module natif (104) et un identifiant du module non-natif (120), et dans lequel le message d'enregistrement comprend en sus un identifiant matériel du dispositif LwM2M (100).


     
    12. Un dispositif (100) pour utilisation dans une application Internet-des-Objets (loT), le dispositif comprenant :

    un module natif (104) comprenant :

    une fonction opérationnelle native (106) ;

    un sous-module de communication natif (108) couplé à la fonction opérationnelle native (104) qui communique avec au moins un serveur extérieur (102) ;

    une zone de stockage sécurisée native (110) stockant au moins une clé pré-partagée (111) ; et

    un sous-module de parrainage (112) qui détermine une présence d'un module non-natif (120) et soutient l'amorçage du module non-natif (120) ;

    le module non-natif (120) comprenant :

    une fonction opérationnelle (122) ;

    une mémoire (126) stockant au moins un identifiant de module non-natif ;

    un sous-module de communication (124) qui communique avec l'au moins un serveur extérieur (102) ; et

    un sous-module d'amorçage (128) qui communique avec le sous-module de parrainage (112), le sous-module d'amorçage (128) recevant un justificatif d'identité du module de communication natif (108) et communiquant le justificatif d'identité et l'identifiant de module non-natif (120) à l'au moins un serveur extérieur (102) pour l'enregistrement.


     
    13. Le dispositif de la revendication 12, comprenant en sus un identifiant matériel universellement unique utilisé par le sous-module d'amorçage (128) pour communiquer avec l'au moins un serveur extérieur (100).
     
    14. Le dispositif de la revendication 12 ou 13, dans lequel la fonction opérationnelle native (106) comprend au moins un d'un capteur ou un actionneur.
     
    15. Le dispositif de n'importe laquelle des revendications 12-14, dans lequel le module non-natif (120) est couplé à au moins un d'un capteur ou un actionneur dans le dispositif (100).
     




    Drawing











    Cited references

    REFERENCES CITED IN THE DESCRIPTION



    This list of references cited by the applicant is for the reader's convenience only. It does not form part of the European patent document. Even though great care has been taken in compiling the references, errors or omissions cannot be excluded and the EPO disclaims all liability in this regard.

    Patent documents cited in the description