IoT device provisioning

Abstract

A computer-implemented method for provisioning an Internet of Things (IoT) device includes receiving an event pattern for an IoT device at a device provisioning system. The method also includes comparing one or more event types from the event pattern with multiple combinations of one or more event types in a device type pattern list to identify a match between the one or more event types in the event pattern from the IoT device and one of the multiple combinations of one or more event types in the device type pattern list; in response to identifying a match, assigning a device type to the IoT device based on a relevance for the device type in the device type pattern list and the matched combination of one or more event types; and provisioning the IoT device with a verified credential based on the assigned device type.

Description

Technical Field

[0001] The present disclosure relates to Internet of Things device provisioning. Background Art

[0002] The Internet of Things (IoT) is a system of related computing devices, mechanical or digital machines, objects, animals, and / or people that are provided with unique identifiers (UIDs). The IoT allows data to be transmitted over a computer network without the need for human-to-human or human-to-computer interaction. Devices or objects (i.e., "things") in the IoT can include, for example, heart monitor implants, household appliances, light bulbs, cars with built-in sensors, and / or any device that can be assigned an IP address capable of transmitting data over a computer network.

[0003] The IoT ecosystem can include internet-enabled devices that use embedded processor sensors and communication hardware to collect, send, and act on data acquired from the IoT device's surroundings. IoT devices can share the data they collect by connecting to an IoT gateway or other edge device, where the data can be sent to a cloud computing environment or analyzed by a local operating computer system. IoT devices can communicate with another IoT device or other related devices on a computer network. The connectivity, networking, and communication protocols used can allow IoT devices to interact without much, if any, human interaction, and can be used to monitor business processes, improve customer experience, enhance productivity, influence business decisions, and integrate or adapt business models. Summary of the Invention

[0004] Aspects of the present disclosure may include computer-implemented methods, computer program products, and systems. One example of a computer-implemented method for provisioning an Internet of Things (IoT) device includes receiving an event schema for an IoT device at a device provisioning system. The event schema includes one or more event types collected by the IoT device. The method also includes comparing one or more event types from the event schema with multiple combinations of one or more event types in a device type pattern list to identify a match between the one or more event types in the event schema from the IoT device and one of the multiple combinations of one or more event types in the device type pattern list; in response to identifying a match, assigning a device type to the IoT device based on a relevance for the device type in the device type pattern list and the matched combination of the one or more event types; and provisioning verified credentials to the IoT device based on the assigned device type. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] Understanding that the drawings depict only exemplary embodiments and are therefore not to be considered limiting of scope, exemplary embodiments will be described with additional specificity and detail through use of the accompanying drawings, in which:

[0006] Figure 1 is a block diagram of an example embodiment of an example computing environment capable of automating IoT device registration based on sample event data received from the IoT device.

[0007] Figure 2 is a high-level block diagram of one embodiment of an example device provisioning system.

[0008] Figure 3 is a high-level block diagram of one embodiment of an example IoT device.

[0009] Figure 4 is a flow chart depicting one embodiment of an example method of provisioning an IoT device.

[0010] Figure 5 is a flow chart depicting another embodiment of an example method 500 for provisioning an IoT device.

[0011] Figure 6 A cloud computing environment according to an embodiment of the present disclosure is depicted.

[0012] Figure 7 Abstract model layers according to an embodiment of the present disclosure are depicted.

[0013] According to common practice, the various described features are not drawn to scale, but rather are drawn to emphasize specific features relevant to the exemplary embodiments. DETAILED DESCRIPTION

[0014] In the following detailed description, reference is made to the accompanying drawings, which form a part hereof, and in which specific illustrative embodiments are shown by way of illustration. However, it should be understood that other embodiments may be utilized, and that logical, mechanical, and electrical changes may be made. Furthermore, the methods presented in the drawings and the description should not be construed as limiting the order in which the various steps may be performed. Therefore, the following detailed description should not be construed as limiting.

[0015] Figure 1 Depicted is a block diagram of one example embodiment of an example computing environment 100 capable of automating IoT device registration based on sample event data received from the IoT devices, according to embodiments of the present disclosure. Figure 1The illustrated embodiment of the computing environment 100 includes multiple computer systems and devices interconnected via a computer network 102. The network 102 can be implemented using any number of suitable physical and / or logical communication topologies. The network 102 can include one or more private or public computing networks. For example, the network 102 can include a private network associated with a workload (e.g., a network with a firewall that prevents unauthorized external access). Alternatively, or in addition, the network 102 can include a public network, such as the Internet. Thus, the network 102 can form part of a packet-based network, such as a local area network, a wide area network, and / or a global network such as the Internet. The network 102 can include one or more servers, networks, or databases, and can use one or more communication protocols to transmit data between the devices and systems interconnected via the network 102. Thus, examples of the network 102 can include a local area network (LAN), a home area network (HAN), a wide area network (WAN), a backbone network (BBN), a peer-to-peer network (P2P), a campus network, an enterprise network, the Internet, a cloud computing network, and / or any other network known to those skilled in the art.

[0016] In addition, despite Figure 1 1 is shown as a single entity, but in other examples, network 102 may include multiple networks, such as a combination of public and / or private networks. Communication network 102 may include various types of physical communication channels or "links." The links may be wired, wireless, optical, or any other suitable medium. In addition, communication network 102 may include various network hardware and software for performing routing, switching, and other functions, such as routers, switches, base stations, bridges, or any other devices that may facilitate communication of data.

[0017] In this example, multiple computer systems and devices interconnected via a network 102 include a device provisioning system 106 configured to implement a provisioning service, an IoT platform 108, and multiple IoT devices 104-1...104-N (hereinafter generally referred to as "IoT devices 104"), where N represents the total number of IoT devices. Although only one IoT platform is depicted in this example for ease of explanation, it is understood that in other embodiments, more than one IoT platform 108 may be utilized. Similarly, it should be understood that the number of IoT devices 104 is not limited to the number depicted in the figures. That is, although Figure 1 104, but it will be appreciated that more than two IoT devices may be used in other embodiments. Specifically, the number of IoT devices 104, IoT platform 108, or any other repeating components or systems presented in the figures may be any number supported by the network 102 and computing environment.

[0018] Embodiments of the IoT device 104, the IoT platform 108, and the device provisioning system 106 can each be a dedicated computer system comprising a dedicated configuration of hardware, software, or a combination thereof as shown and described herein. Embodiments of the device provisioning system 106, the IoT platform 108, and other network-accessible systems can be desktop computers, laptop computers, tablet computers, smartphones, server computers, or any other computer systems known in the art. In some embodiments, the IoT platform 108, the device provisioning system 106, and / or other network-accessible systems can represent computer systems that utilize clustered computers and components to act as a single seamless resource pool when accessed through the network 102. For example, such embodiments can be used in data centers, cloud computing, storage area networks (SANs), and network attached storage (NAS) applications.

[0019] In some embodiments, the IoT platform 108, the device provisioning system 106, and / or other network-accessible systems can represent virtual machines provisioned by a host computer on the network 102. For example, the device provisioning system 106 and / or the IoT platform 108 can host multiple virtual machines that access and / or provision each IoT device 104. In some embodiments, the IoT device 104 can have embedded virtualization features, allowing the IoT device 104 to be provisioned with a management layer and separate sockets to which one or more types of functionality can be assigned. An IoT device 104 with virtualization capabilities can be provisioned with multiple functions on the original hardware of the IoT device 104.

[0020] The IoT device 104 can be any physical device or object embedded with electronic devices, circuits, software, sensors, actuators and / or connection hardware that can enable the IoT device 104 to connect to the computer network 102, collect data, or exchange data. For example, an IoT device may include a refrigerator, a microwave oven, a conventional oven, a light switch, a doorbell, an air conditioning system, a water heater, a temperature sensor, or any other device configured to communicate and / or send data via the network 102. In many cases, a specific device is able to communicate on the network by embedding a general-purpose communication chip into the device. That is, the same type of communication chip or module can be embedded in different types of devices. For example, both a refrigerator and a microwave oven can be embedded with the same type of communication chip. In some embodiments, the communication chip can be manufactured by a third party to be placed in a device manufactured by another manufacturer.

[0021] The modularity of communication chips that can be used in different types of devices offers cost and manufacturing efficiencies. However, it's impossible to track or know in advance which type of device a given communication chip will be embedded in. This presents technical challenges in properly provisioning the communication chip to enable it to communicate with the IoT platform 108. As those skilled in the art will appreciate, device provisioning is the process of attaching credentials to a device identity. The device identity uniquely identifies a specific device and can be used for features such as, but not limited to, providing push notifications and performance reporting. For example, the system uses the device identity to identify which device a notification is being sent to or how many devices are using a server. Knowing the device identity also enables numerous security integration possibilities, such as determining which IoT devices are allowed to communicate with a given IoT platform. Furthermore, knowing the device identity enables more specific and relevant reporting and processing of data from the device. Furthermore, security updates can be relevant only to certain device types. However, without knowing which device type the communication module / chip is embedded in, updates can be rolled out to more devices than necessary.

[0022] Some traditional techniques for addressing this provisioning problem involve manual intervention in the device provisioning process. However, the number of IoT devices currently stands in the billions and is expected to grow exponentially. Given the volume of devices, manually provisioning devices proportionally is ineffective. Other traditional techniques oversimplify the device provisioning process, for example by assigning all devices from a given manufacturer to the same device type. However, the embodiments described herein enable an automated device provisioning process while also enabling a more sophisticated process that more accurately provisions devices based on the actual device type.

[0023] Specifically, as described herein, the device provisioning system 106 enables automatic detection of device type based on sample event data provided by a given IoT device 104. Sample event data refers to actual events published by an IoT device. The event data published by an IoT device will depend on the type of device. For example, a refrigerator may publish event data related to temperature readings, pressure measurements in the condenser, etc. However, a microwave oven may collect and publish event data related to, for example, electromagnetic (EM) radiation levels. Therefore, the specific event data collected and published by an IoT device will vary based on the type of device.

[0024] The device provisioning system 106 is configured to analyze sample event data from the IoT devices 104 to identify a corresponding device type for each of the IoT devices. The identified device types are then provided to the IoT platform 108 for use in provisioning the IoT devices 104 based on their identified device types.

[0025] In operation, one or more of the IoT devices 104 request to connect to the IoT platform 108 by submitting a request for registration of the IoT device 104 via the network 102. As described above, embodiments of the IoT device 104 may refer to a physical object that may be embedded with technology that allows network communications with other IoT devices 104, computer systems, servers, gateways, and the environment external to the IoT device 104. The IoT device 101 may be connected to the Internet and may include features, parameters, and properties that may be typical of a network-enabled computer system, such as an IP address and a MAC address. Examples of IoT devices 104 may include, but are not limited to, security systems, speakers, home appliances, toys, televisions, thermostats, smoke alarms, cameras, sensors, lighting systems, cars, or any other object that may be embedded with network-enabled communication technology. Reference Figure 3 An example IoT device is discussed in more detail.

[0026] In addition to the provisioning request, the IoT device 104 is also configured to provide an event schema document (also referred to herein as an "event schema" or "schema") to the device provisioning system 106. The event schema document defines the attributes of the event data, such as the event name and type. Specifically, the event schema document is used to define the attributes of the event data provided to the device provisioning system 106. Therefore, the event schema document functions similarly to an XML schema document (XSD), but is used for event data in the IoT ecosystem. In some embodiments, sample event data may be provided as part of the event schema document. In other embodiments, the event data and the event schema are provided separately. In addition, as used herein, the term event type refers to the type of event rather than a specific value of the data. Example event types include, but are not limited to, state, reading, measurement, etc. For example, a state may refer to the state of a component (e.g., operation, standby, etc.), while a reading or measurement may indicate that the value was measured at a given point in time (such as a temperature reading). In addition, in some embodiments, the type may be more specific, such as a temperature reading, a pressure reading, an ambient light measurement, etc.

[0027] Based on the specific event types and event patterns provided by the IoT device 104, the device provisioning system 106 is able to identify the device type of a given IoT device. In particular, the device provisioning system 106 maintains a pattern list 110 that associates different combinations of event types with different device types. For example, the pattern list 110 may indicate that an event type of a condenser pressure reading along with a temperature reading is associated with a device type of refrigerator. Thus, the device provisioning system 106 is configured to identify a match between an event type provided with an event pattern from the IoT device 104 and the grouping of event types in the pattern list 110 to identify the device type of a given IoT device. If a match is found, the IoT device is classified as that device type. The device type classification is provided to the IoT platform 108 for use in verifying the credentials of the IoT device 104. In some embodiments, the device provisioning system is configured to verify the credentials of the IoT device 104. For example, in some such embodiments, the IoT platform 108 and the device provisioning system 106 are implemented as a single system, rather than Figure 1 The separate system depicted in .

[0028] The IoT platform 108 may refer to supporting software that connects hardware (such as IoT devices 104), access points, and networks to end-user applications accessible via the IoT platform 108. The IoT platform 108 may handle management tasks and data visualization, allowing users to automate the physical environment and the computing environment 100. Embodiments of the IoT platform 108 may perform multiple functions within the computing environment 100, including the functions of a data controller, a gateway device, a communication network, a data analyzer, a data converter, and / or an application service (including, in some embodiments, the functions of an end-user application or device provisioning system 106). Embodiments of the IoT platform 108 may act as middleware between remotely connected IoT devices 104 and one or more applications or devices that may be connected or accessed via the IoT platform 108.

[0029] In this embodiment, the IoT platform 108 is also responsible for issuing or maintaining a database 112 containing authenticated credentials. The IoT platform 108 can compare the credentials received from the IoT device 104 with the authenticated credentials in the credentials database 112 and confirm to the device provisioning system 106 whether the credentials presented by the IoT device 104 are in fact authentic. As described above, in some embodiments, the device provisioning system 106 can be responsible for maintaining the credentials database 112.

[0030] Embodiments of the IoT platform 108 may be responsible for implementing one or more functionalities of IoT devices 104 registered with the IoT platform 108. For example, the IoT platform 108 may equip or enable real-time monitoring capabilities, remote control capabilities, configurable alerts, notifications, and pluggable cloud services for IoT devices 101. Embodiments of the IoT platform 108 may also integrate IoT devices 104 with mobile computing devices, smartphone technologies, and applications. Additional examples of IoT platform applications within the context of IoT devices 104 may include remote monitoring of IoT devices 104 and vehicles equipped with them, predictive maintenance for equipment, and the collection of sensor data for real-time analysis in various sectors such as, but not limited to, healthcare, hospitality, and travel, including monitoring the end-to-end movement of physical goods / products. The IoT platform 108 can leverage large networks of registered IoT devices 104 for large-scale solutions, including leveraging networks of IoT devices 104 for smart city infrastructure and public services, including grid metering, air quality monitoring, and controlling the functionality of "smart" buildings.

[0031] When the IoT platform 108 operates using a cloud computing environment such as the example cloud computing environment described below, embodiments of the IoT platform 108 may also be referred to as an IoT cloud. The IoT platform 108 operating as an IoT cloud may be used as a platform as a service (PaaS). An IoT PaaS may allow users and clients to rent cloud infrastructure, the IoT platform 108, and even IoT devices 104 all from a single technology provider.

[0032] Therefore, by enabling the device provisioning system 106 to automatically identify the device type of the IoT device 104 based on event data, the embodiments described herein can improve the efficiency and security of provisioning and registering the IoT device 104 with the IoT platform 108. Figure 2 An example device provisioning system is described in more detail.

[0033] Figure 2 is a high-level block diagram of one embodiment of an example device provisioning system 200. The device provisioning system 200 may be implemented as Figure 1 The device provisioning system 106 in Figure 2 In the example shown, the device provisioning system 200 includes a memory 225, a storage device 230, one or more processors 205 (also referred to herein as CPU 205), and a network interface 215 communicatively coupled via an interconnect (e.g., BUS) 220. It should be understood that the device provisioning system 200 is provided as an example only, and in other embodiments, the device provisioning system 200 may be implemented in different ways. For example, in other embodiments, the CPU 205 may be omitted. Figure 2 Some of the components shown and / or may include other components.

[0034] Each CPU 205 retrieves and executes programming instructions stored in memory 225 and / or storage 230. Interconnect 220 is used to move data, such as programming instructions, between CPU 205, storage 230, network interface 215, and memory 225. Interconnect 220 can be implemented using one or more buses. In various embodiments, CPU 205 can be a single CPU, multiple CPUs, or a single CPU with multiple processing cores. In some embodiments, processor 205 can be a digital signal processor (DSP). Memory 225 is generally included to represent random access memory (e.g., static random access memory (SRAM), dynamic random access memory (DRAM), or flash memory). Storage 230 is generally included to represent non-volatile memory, such as a hard drive, solid-state device (SSD), removable memory card, optical storage, or flash memory device. In alternative embodiments, storage 230 can be replaced by a storage area network (SAN) device, the cloud, or other device communicatively coupled to device provisioning system 200 via a communication network coupled to network interface 215.

[0035] In some embodiments, memory 225 stores provisioning instructions 211, and storage 230 stores provisioning log 209 and device type pattern list 217. However, in various embodiments, provisioning instructions 211, provisioning log 209, and device type pattern list 217 are stored partially in memory 225 and partially in storage 230, or they are stored entirely in memory 225 or entirely in storage 230. Additionally, while storage 230 is depicted as a single monolithic entity and memory 225 is depicted as a single monolithic entity, it should be understood that in other embodiments, storage 230 and / or memory 225 may each include multiple separate memory devices.

[0036] When executed by CPU 205, provisioning instructions 211 cause CPU 205 to automatically identify the device type of each IoT device based on event data provided by the IoT device, as described herein. In particular, provisioning instructions 211 include instructions for pattern engine 213. Pattern engine 213 is configured to compare the event type received from the IoT device with the event types stored in device type pattern list 217. When a match is found, provisioning instructions 211 classifies the IoT device as the device type indicated in the match identified from device type pattern list 217. In addition, provisioning instructions 211 cause CPU 205 to maintain entries in provisioning log 209 during the provisioning process. For example, in some embodiments, provisioning instructions 211 cause CPU 205 to perform methods such as method 400 and / or method 500 during provisioning of the IoT device.

[0037] Furthermore, as described above, in some embodiments, Figure 2 One or more components and data shown in include instructions or statements that execute on the processor 205, or that are interpreted by instructions or statements that execute on the processor 205 to perform functions as described herein. In other embodiments, instead of or in addition to a processor-based system, Figure 2 One or more components shown in the drawings may be implemented in hardware via semiconductor devices, chips, logic gates, circuits, circuit cards, and / or other physical hardware devices.

[0038] Figure 3 is a high-level block diagram of one embodiment of an example IoT device 300. The IoT device 300 may be implemented as Figure 1 104 in the example IoT device 300. The example IoT device 300 includes a communication module 360. As described above, in some embodiments, the communication module 360 ​​can be manufactured as a general-purpose module that can be included in many different types of devices. In this example, the communication module 360 ​​includes a processor 362, a network interface 364, and a memory 366. The network interface 364 is configured to enable communication with an IoT platform and device provisioning system such as the IoT platform 108 and the device provisioning system 106 over a network such as the network 102.

[0039] In this example, memory 366 includes credentials 370, address 372, and mode 374. Credentials 370 are network connection information and authentication documents. Figure 3 In the illustrated example, credentials 370 are stored within memory 366 on IoT device 300. However, in other embodiments, credentials 370 may be accessible via a network-accessible storage device. Embodiments of credentials 370 may store authentication information that can be used to access the IoT platform. Examples of credentials may include a user / password combination, a security token, or a digital certificate. One or more combinations of credentials may be implemented to increase security.

[0040] The credentials 370 can allow computing systems, platforms, and networks to verify the authenticity of the IoT device 300 to ensure that unauthorized devices do not impersonate legitimate IoT devices 300. For example, the digital certificate can use a public key, a private key, or a digital signature issued by a digital certificate manager responsible for maintaining the credentials 370 of the IoT device 300. The digital key and / or digital signature can be matched with the digital certificate presented by the IoT device 300 when the IoT device 300 is registered to verify the authenticity of the credentials 370. Examples of digital certificates can include server or client certificates that can communicate securely using a secure socket layer (SSL), object signing certificates that include digitally signed objects, and signature verification certificates. The most common format of public key certificates that can be used can be digital certificates issued in the X.509 format.

[0041] Credentials 370, primarily consisting of digital certificates, security tokens, and default usernames / passwords, can be pre-loaded onto the IoT device 300 by the manufacturer of the communication module 360, the distributor of the IoT device 300, or an administrator. The pre-loaded credentials 370 allow the IoT device 300 to register with the IoT platform for the first time and prove that the IoT device 300 is trustworthy. In some embodiments, during the registration of the IoT device 300, the credentials 370 can be modified by the device provisioning system or the IoT platform. For example, during the registration of the IoT device 300, a new username / password combination can be set to access the IoT platform. Alternatively, during the registration of the IoT device 300, as part of the registration process, the device provisioning system can issue new credentials by issuing a new digital certificate or security token to the IoT device 300.

[0042] In some embodiments, such as Figure 3 As depicted in the example of , the IoT device 300 is pre-programmed or embedded with a URL or other network address protocol 372 (generally referred to herein as "address 372"). In some embodiments, the address 372 may direct the IoT device 300 to a device provisioning system or IoT platform associated with the use of the IoT device 300. After navigating to the URL or network address embedded in the IoT device 300, the IoT device 300 may connect to the device provisioning system and initiate automatic registration of the IoT device 300. For example, the IoT device 101 may initially be directed to the URL of the IoT platform. However, the IoT device 300 may be identified as an unregistered device and subsequently redirected to the device provisioning system to first complete the registration process before accessing the IoT platform.

[0043] exist Figure 3In the example shown, the memory 366 also stores a schema 374. As described above, the schema 374 includes information about the types of events collected and published by the IoT device 300. In this embodiment, the IoT device 300 also includes one or more input / output (I / O) devices 376 and one or more sensors 378. The one or more I / O devices 376 enable the IoT device to interact with a user and / or other IoT devices in the environment surrounding the IoT device. For example, the I / O devices 376 may include, but are not limited to, a display screen, a speaker, a microphone, a control panel, etc. The one or more sensors 378 are each configured to collect data about the IoT device. For example, the sensors 378 may include, but are not limited to, a temperature sensor, a pressure sensor, a light sensor, a timer, etc. The sensors 378 and / or the I / O devices 376 provide event data related to the schema 374 of the IoT device 300, which is provided to the device provisioning system for automatic identification of the device type of the IoT device 300.

[0044] It should be understood that the IoT device 300 is provided as an example only and that the IoT device 300 may be implemented differently in other embodiments. For example, it should be understood that in other embodiments, other components may be used in addition to or in place of the components shown, and other components may be omitted. Figure 3 For example, in some embodiments, the I / O device 376 may be omitted. Additionally, in some other embodiments, the processor 362 is not implemented as part of the communication module 360.

[0045] Figure 4 is a flow chart depicting one embodiment of an example method 400 for provisioning an IoT device. Method 400 can be implemented by a device provisioning system, such as device provisioning system 106 or 200. For example, method 400 can be implemented by a CPU, such as CPU 205 in device provisioning system 200, executing instructions, such as provisioning instructions 211. It should be understood that the order of actions in example method 400 is provided for illustrative purposes and that the method can be performed in a different order in other embodiments. Similarly, it should be understood that in other embodiments, some actions can be omitted or additional actions can be included.

[0046] At 402, a provisioning or registration request is received at a device provisioning service (DPS) from an unprovisioned IoT device along with an event pattern containing event type data. In some embodiments, the uniform resource locator (URL) or other network address of the device provisioning service is burned or preloaded into the IoT device by the IoT device manufacturer. In this way, the IoT device can send the request and event pattern directly to the device provisioning service. In other embodiments, the URL or other network address of the device manufacturer is preloaded into the IoT device. In such embodiments, the device manufacturer can redirect the request and event pattern to the device provisioning service. Similarly, in other embodiments, the IoT device is preloaded with the URL or other network address of the IoT platform, and the IoT platform redirects the initial request and pattern to the device provisioning service.

[0047] At 404, the device provisioning service logs the received request in a file such as Figure 2 's provisioning log 209. At 406, the device provisioning service executes a provisioning engine that is configured to compare the event type data in the received event pattern with the contents of a device type pattern list, such as device type pattern list 217, to identify a match. In some embodiments, the device type pattern list may be pre-populated with different combinations of event type data and corresponding device types. In other embodiments, the device provisioning service is configured to build and / or update the device type pattern list based on the event pattern received from the IoT device, such as described in the example method 500 below. Furthermore, it should be understood that in some embodiments, the device provisioning system may be implemented via multiple distributed devices. In such embodiments, the pattern engine may be implemented on a device that is different from the device that is configured to communicate with the IoT device.

[0048] At 408, in response to identifying a pattern match, the pattern statement is returned to the device provisioning system. As used herein, returning a pattern statement to the device provisioning service may refer to generating and / or providing a pattern statement from one component of the device provisioning system to another component of the device provisioning system. For example, as described above, one device may be configured to implement a pattern engine, while another may be configured to communicate with an IoT device. The identified pattern match is an indication that a combination of one or more event types in the device type pattern list matches one or more event types in an event pattern received from the IoT device. Thus, based on this match, the device provisioning system can classify the IoT device type in the pattern statement.

[0049] At 410, the pattern statement is recorded in the provisioning log. At 412, the provisioning request is sent to the IoT platform (also known as the IoT cloud service). In addition, along with the provisioning request, the device provisioning system sends the device type identified in the pattern statement to the IoT platform. In this way, the IoT platform can verify the credentials as described above and register the IoT device based on the identified device type. As described above, this achieves various advantages, such as, but not limited to, improved reporting based on device type, improved tracking and rollout of updates / fixes, improved security to prevent device impersonation, etc.

[0050] At 414, the device provisioning service receives the verified credentials from the IoT platform, as described above. For example, in response to verifying the credentials received from the IoT device, the IoT platform may return a signed certificate to the device provisioning system to send to the IoT device. At 416, the response from the IoT platform is logged without recording the verified credentials. In other words, the event of receiving the verified credentials is logged, but the device provisioning system does not record the actual verified credentials in the provisioning log. At 418, the verified credentials, device ID, token, etc. are returned to the IoT device being provisioned. At 420, a success return code is received and recorded from the IoT device without recording the exact credentials.

[0051] It should be understood that method 400 is provided by way of example, and in other embodiments, modifications to method 400 may be implemented. For example, one or more logging actions may be omitted or modified. Similarly, in some embodiments, the device provisioning system may be implemented as part of an IoT platform, and thus, the device provisioning system may perform verification of received credentials.

[0052] Figure 5 is a flow chart depicting another embodiment of an example method 500 for provisioning an IoT device. Method 500 can be implemented by a device provisioning system, such as device provisioning system 106 or 200. For example, method 500 can be implemented by a CPU, such as CPU 205 in device provisioning system 200, executing instructions such as provisioning instructions 211. It should be understood that the order of actions in example method 500 is provided for illustrative purposes and that the method can be performed in a different order in other embodiments. Similarly, it should be understood that in other embodiments, some actions can be omitted or additional actions can be included.

[0053] Example method 500 enables a device provisioning system to create and / or update a device type pattern list based on event data received from an IoT device. For example, as described above, in some embodiments, the device type pattern list can be pre-populated with associations between device types and combinations of one or more event types. In the event that a combination or pattern of event types received from an IoT device does not match an event type combination stored in the device type pattern list, method 500 enables the device type to be identified and the device type pattern list to be updated. Additionally, if the device type pattern list is not pre-populated, method 500 enables the device type pattern list to be created.

[0054] At 502, as described above, a provisioning request and an event pattern are received at a device provisioning system from a communication module of an IoT device to be provisioned. The communication module enables the IoT device to communicate with the device provisioning system. For the first event pattern and provisioning request received from the device, information about where to direct the event pattern can be hardwired or preloaded to the device manufacturer, IoT platform, or device provisioning system, as described above. In the case where it is hardwired to the device manufacturer's site, the site redirects the request to the IoT platform or device provisioning system. At 504, the device provisioning system compares the event data from the event pattern to determine whether there is a match in a list of device type patterns. In other words, determine whether the device type associated with the event data has been previously identified.

[0055] If it is determined at 506 that the device type of the received event data has been previously identified (e.g., the event type combination described above), then at 508, the IoT device is classified with the corresponding device type and the given credentials returned to the IoT device are provided to the IoT device, as described above. If it is determined at 506 that the device type of the received event data has not been previously identified, then at 510, the device provisioning system directs the event pattern and credentials received from the IoT device to the IoT device's original equipment manufacturer (OEM) to determine the device type. The information used to direct events to the OEM can be hardwired or pre-loaded. In the example of a communication module manufactured by a third party and embedded in an IoT device, the OEM referred to is the OEM of the IoT device, not the manufacturer of the communication module. The OEM can check the hard-coded credentials, assign a device type, and return it to the device provisioning system. For example, the hard-coded credentials may include the serial number of the device provided by the OEM. In this case, the OEM can provide the device type based on the serial number communicated to it by the device provisioning system. At 512, the device provisioning system updates the device type pattern list based on the response from the OEM. DPS now has the correlation between the type of events received from IoT devices and the device type for future processing.

[0056] Method 500 then proceeds to 508, where the IoT devices are classified and provisioned based on the identified device types as described above. Method 500 then returns to 502 for receiving subsequent event data from the same or other IoT devices. Therefore, the IoT device is provisioned only the first time an event pattern and request are sent. The IoT platform then identifies the IoT device as the IoT device sending the request using the verified credentials provided by the IoT platform during the provisioning process. In addition, the DPS ensures that the first event is retained and, if necessary, forwarded to the IoT platform after checking the device type with the OEM. If more than one IoT device sends a similar event type, the device type will be the same for different IoT devices, while the device ID will be returned uniquely. Therefore, the updated device type pattern list can be used to identify subsequent IoT devices with the same device type but not necessarily from the same manufacturer.

[0057] It should be understood that although the present disclosure includes detailed descriptions about cloud computing, the implementation of the teachings set forth herein is not limited to cloud computing environments. Rather, embodiments of the present invention can be implemented in conjunction with any other type of computing environment now known or later developed.

[0058] Cloud computing is a service delivery model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be quickly provisioned and released with minimal management effort or interaction with the service provider. The cloud model can include at least five characteristics, at least three service models, and at least four deployment models.

[0059] Features are as follows:

[0060] On-demand self-service: Cloud consumers can unilaterally and automatically provision computing capabilities, such as server time and network storage, as needed without manual interaction with the service provider.

[0061] Wide Area Network Access: Capabilities are available over the network and accessed through standard mechanisms that facilitate use by heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and PDAs).

[0062] Resource pooling: A provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, where different physical and virtual resources are dynamically allocated and reallocated based on demand. This is location-independent in the sense that consumers typically do not control or know the exact location of the provided resources, but are able to specify the location at a higher level of abstraction (e.g., country, state, or data center).

[0063] Rapid elasticity: In some cases, the ability to scale out quickly and in quickly can be provided quickly and elastically. To the consumer, the capacity available for provisioning often appears unlimited and can be purchased in any quantity at any time.

[0064] Metered Services: Cloud systems automatically control and optimize resource usage by leveraging metering capabilities at a level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency to both the provider and consumer of the utilized service.

[0065] The service model is as follows:

[0066] Software as a Service (SaaS): The ability provided to consumers is to use the provider's applications running on a cloud infrastructure. Applications are accessible from a variety of client devices through a thin-client interface such as a web browser (e.g., web-based email). Consumers do not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.

[0067] Platform as a Service (PaaS): The capability provided to consumers is to deploy consumer-created or acquired applications onto cloud infrastructure. These applications are built using programming languages ​​and tools supported by the provider. Consumers do not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, or storage, but do have control over the deployed applications and possibly the configuration of the application hosting environment.

[0068] Infrastructure as a Service (IaaS): The capabilities provided to consumers are processing, storage, networking, and other basic computing resources on which consumers can deploy and run arbitrary software, including operating systems and applications. Consumers do not manage or control the underlying cloud infrastructure, but do have control over the operating system, storage, deployed applications, and possibly limited control over selected networking components (e.g., host firewalls).

[0069] The deployment model is as follows:

[0070] Private cloud: The cloud infrastructure is operated solely for the organization. It can be managed by the organization or a third party and can exist inside or outside the building.

[0071] Community cloud: Cloud infrastructure is shared by several organizations and supports a specific community with shared concerns (e.g., mission, security requirements, policies, and compliance considerations). It can be managed by the organization or a third party and can exist on-premises or off-premises.

[0072] Public cloud: Cloud infrastructure is available to the general public or large industrial groups and is owned by the organization that sells cloud services.

[0073] Hybrid cloud: A cloud infrastructure is a combination of two or more clouds (private, community, or public) that remain a unique entity but are bound together by standardized or proprietary technologies that enable data and application portability (e.g., cloud bursting for load balancing between clouds).

[0074] The cloud computing environment is service-oriented, with a focus on statelessness, low coupling, modularity, and semantic interoperability. At the core of cloud computing is the infrastructure consisting of a network of interconnected nodes.

[0075] Now refer to Figure 6 , depicts an illustrative cloud computing environment 50. As shown, the cloud computing environment 50 includes one or more cloud computing nodes 10 with which a local computing device used by a cloud consumer can communicate, such as a personal digital assistant (PDA) or cellular phone 54A, a desktop computer 54B, a laptop computer 54C, and / or an automobile computer system 54N. The nodes 10 can communicate with each other. They can be physically or virtually grouped (not shown) in one or more networks, such as a private cloud, community cloud, public cloud, or hybrid cloud, or a combination thereof, as described above. This allows the cloud computing environment 50 to provide infrastructure, platform, and / or software as a service for which the cloud consumer does not need to maintain resources on a local computing device. It should be understood that Figure 6 The types of computing devices 54A-N shown in are intended for illustration only, and computing node 10 and cloud computing environment 50 may communicate with any type of computing device over any type of network and / or network-addressable connection (eg, using a web browser).

[0076] Now refer to Figure 7 , showing the cloud computing environment 50 ( Figure 6 ) provides a set of functional abstraction layers. It should be understood in advance that Figure 7 The components, layers, and functions shown in are intended to be illustrative only, and embodiments of the present invention are not limited thereto. As depicted, the following layers and corresponding functions are provided:

[0077] The hardware and software layer 60 includes hardware and software components. Examples of hardware components include: host 61; server 62 based on RISC (Reduced Instruction Set Computer) architecture; server 63; blade server 64; storage device 65; and network and network components 66. In some embodiments, software components include network application server software 67 and database software 68.

[0078] Virtualization layer 70 provides an abstraction layer from which the following examples of virtual entities can be provided: virtual servers 71 ; virtual storage 72 ; virtual networks 73 , including virtual private networks; virtual applications and operating systems 74 ; and virtual clients 75 .

[0079] In one example, the management layer 80 may provide the functionality described below. Resource provisioning 81 provides dynamic procurement of computing and other resources for performing tasks within a cloud computing environment. Metering and pricing 82 provides cost tracking when utilizing resources in a cloud computing environment, as well as billing or invoicing for the consumption of those resources. In one example, these resources may include application software licenses. Security provides authentication for cloud consumers and tasks, as well as protection for data and other resources. A user portal 83 provides access to the cloud computing environment for consumers and system administrators. Service level management 84 provides allocation and management of cloud computing resources so that required service levels are met. Service level agreement (SLA) models and fulfillment 85 provides pre-scheduling and procurement of cloud computing resources, where future demand is anticipated based on the SLA.

[0080] The workload layer 90 provides examples of functions that can take advantage of the cloud computing environment. Examples of workloads and functions that can be provided from this layer include: mapping and navigation 91; software development and lifecycle management 92; virtual classroom education delivery 93; data analysis processing 94; transaction processing 95; and device provisioning processing 96.

[0081] The present invention may be a system, method and / or computer program product at any possible level of technical detail integration. The computer program product may include a computer-readable storage medium (or multiple media) having computer-readable program instructions thereon, the computer-readable program instructions being used to cause a processor to perform various aspects of the present invention.

[0082] A computer-readable storage medium can be a tangible device that can retain and store instructions used by an instruction execution device. A computer-readable storage medium can be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanical encoding device such as a punch card or a raised structure in a groove on which instructions are recorded, and any suitable combination thereof. As used herein, a computer-readable storage medium should not be interpreted as a temporary signal itself, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagated by a waveguide or other transmission medium (e.g., a light pulse by an optical fiber cable), or an electrical signal transmitted by a wire.

[0083] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to a corresponding computing / processing device, or downloaded to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network can include copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. The network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions to be stored in a computer-readable storage medium within the corresponding computing / processing device.

[0084] The computer-readable program instructions for performing the operations of the present invention may be assembly instructions, instruction set architecture (ISA) instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for an integrated circuit, or source code or object code written in any combination of one or more programming languages ​​(including object-oriented programming languages, such as Smalltalk, C++, etc.) and procedural programming languages ​​(such as "C" programming language or similar programming languages). The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as an independent software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an internet service provider). In some embodiments, to perform various aspects of the present invention, an electronic circuit comprising, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) may execute the computer-readable program instructions to personalize the electronic circuit by utilizing the state information of the computer-readable program instructions.

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

[0086] These computer-readable program instructions can be provided to a processor of a computer or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device create a device for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium, which can direct the computer, programmable data processing device and / or other equipment to operate in a specific manner, so that the computer-readable storage medium having the instructions stored therein includes an article of manufacture, which includes instructions for implementing various aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0087] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus, or other device to produce a computer-implemented process, so that the instructions executed on the computer, other programmable apparatus, or other device implement the functions / actions specified in one or more boxes of the flowchart and / or block diagram.

[0088] The flow charts and block diagrams in the accompanying drawings illustrate the possible architecture, functions and operations of the system, method and computer program product according to various embodiments of the present invention. In this regard, each frame in the flow chart or block diagram can represent a module, segment or part of an instruction, which includes one or more executable instructions for realizing the specified logical function. In some alternative embodiments, the functions noted in the frame may not occur in the order noted in the figure. For example, the two frames shown in succession can actually be implemented as a step, simultaneously, substantially simultaneously, in a manner that overlaps part or all of the time, or these frames can sometimes be performed in reverse order, depending on the functions involved. It will also be noted that each frame of the block diagram and / or flow chart illustration and the combination of the frames in the block diagram and / or flow chart illustration can be implemented by a dedicated hardware-based system that performs a specified function or action or performs a combination of dedicated hardware and computer instructions.

[0089] Although specific embodiments have been illustrated and described herein, it will be appreciated by those of ordinary skill in the art that any arrangement calculated to achieve the same purpose may be substituted for the specific embodiments shown.It is manifestly intended that the present invention be limited only by the claims and the equivalents thereof.

Claims

1. A computer-implemented method for provisioning an Internet of Things (IoT) device, the method comprising: receiving, at a device provisioning system, an event pattern for the IoT device, wherein the event pattern comprises one or more event types collected by the IoT device; comparing the one or more event types from the event pattern to a plurality of combinations of one or more event types in a device type pattern list to identify a match between the one or more event types in the event pattern from the IoT device and one of the plurality of combinations of one or more event types in the device type pattern list; In response to identifying a match: assigning the device type to the IoT device based on a relevance for the device type in the device type pattern list and a matched combination of one or more event types; Provisioning verified credentials to the IoT device based on the assigned device type; In response to not identifying a match: Forwarding the credentials received from the IoT device to the device manufacturer of the IoT device; receiving a device type of the IoT device from the device manufacturer; and The device type pattern is updated based on the event pattern of the IoT device and the device type received from the device manufacturer.

2. The computer-implemented method of claim 1 , wherein: Provisioning the IoT device includes: Sending the assigned device type to the IoT platform; and The verified credentials of the IoT device are received from the IoT platform.

3. The computer-implemented method of claim 1 , wherein: Receiving the event pattern includes receiving the event pattern along with a provisioning request and credentials hardcoded in the IoT device.

4. The computer-implemented method of claim 1 , wherein: Receiving the event pattern of the IoT device includes receiving the event pattern from an IoT platform, and the IoT platform forwarding the event pattern from the IoT device to the device provisioning system.

5. The computer-implemented method of claim 1 , further comprising: Recording receipt of the event pattern for the IoT device in a provisioning log; recording a pattern statement for the identified match in the provisioning log; as well as The provisioning of the IoT device is recorded without recording the verified credentials. 6 . The computer-implemented method of claim 1 , further comprising verifying credentials of the IoT device at the device provisioning system.

7. A device provisioning system, comprising: a network interface coupled to a communication network; a memory configured to store a device type pattern list, wherein the device type pattern list associates each device type of a plurality of device types with a corresponding one of a plurality of combinations of one or more event types; and a processor communicatively coupled to the memory and the network interface, wherein the processor is configured to: receiving, via the network interface, an event pattern of an IoT device, wherein the event pattern comprises one or more event types collected by the IoT device; comparing the one or more event types from the event pattern to the plurality of combinations of one or more event types in the device type pattern list to identify a match between the one or more event types in the event pattern from the IoT device and one of the plurality of combinations of one or more event types in the device type pattern list; In response to identifying a match, assigning the device type to the IoT device based on the matched combination of a relevance for the device type in the device type pattern list and one or more event types; and In response to not identifying a match: Forwarding the credentials received from the IoT device to the device manufacturer of the IoT device; receiving a device type of the IoT device from the device manufacturer; and The device type pattern is updated based on the event pattern of the IoT device and the device type received from the device manufacturer.

8. The device provisioning system according to claim 7, wherein: The processor is configured to verify the credentials of the IoT device.

9. The device provisioning system according to claim 7, wherein: The processor is configured to perform the following operations: Sending the assigned device type to the IoT platform for use in verifying the credentials of the IoT device; and Receive verified credentials of the IoT device from the IoT platform.

10. The device provisioning system according to claim 7, wherein: The received event pattern is received along with a provisioning request and credentials hard-coded in the IoT device.

11. The device provisioning system according to claim 7, wherein: The event pattern of the IoT device comes from an IoT platform, and the IoT platform forwards the event pattern from the IoT device to the network interface of the device provisioning system.

12. The device provisioning system according to claim 7, wherein: The processor is further configured to: recording receipt of the event pattern for the IoT device in a provisioning log stored in the memory; recording the identified matching pattern statements in the provisioning log; as well as The provisioning of the IoT device is recorded without recording the verified credentials.

13. A computer program product comprising a computer-readable storage medium having a computer-readable program stored therein, wherein: The computer readable program, when executed by a processor, causes the processor to: receiving an event pattern from an IoT device, wherein the event pattern includes one or more event types collected by the IoT device; comparing the one or more event types from the event pattern to a plurality of combinations of one or more event types in the device type pattern list to identify a match between the one or more event types in the event pattern from the IoT device and one of the plurality of combinations of one or more event types in the device type pattern list; and In response to identifying a match, assigning the device type to the IoT device based on a matched combination of a relevance for the device type in the device type pattern list and one or more event types; In response to not identifying a match: Forwarding the credentials received from the IoT device to the device manufacturer of the IoT device; receiving a device type of the IoT device from the device manufacturer; and The device type pattern is updated based on the event pattern of the IoT device and the device type received from the device manufacturer.

14. The computer program product of claim 13, wherein: The computer-readable program is further configured to cause the processor to verify the credentials of the IoT device.

15. The computer program product of claim 13, wherein: The computer readable program is further configured to cause the processor to: Sending the assigned device type to the IoT platform for use in verifying the credentials of the IoT device; and Receive verified credentials of the IoT device from the IoT platform.

16. The computer program product of claim 13, wherein: The received event pattern is received along with a provisioning request and credentials hard-coded in the IoT device.

17. The computer program product of claim 13, wherein: The computer readable program is further configured to cause the processor to: recording receipt of the event pattern for the IoT device in a provisioning log stored in the memory; recording the identified matching pattern statements in the provisioning log; as well as The provisioning of the IoT device is recorded without recording the verified credentials.

Images