Connection framework with unified stack and messaging protocol for embedded secure connections

Abstract

An apparatus includes a computing device including one or more processors, a plurality of peripheral communication devices having different communication protocol types operably connected to the one or more processors, and a memory to store processor executable instructions including an application layer protocol stack. The processor executable instructions cause, when executed by the one or more processors, the one or more processors to perform operations for respective ones of the messages communicated to and from the computing device via respective ones of the plurality of peripheral communication devices. The operation includes communicating, via the respective one of the plurality of peripheral communication devices, the respective one of the messages according to a unified messaging protocol common to the plurality of peripheral communication devices.

Description

[0001] Priority Statement

[0002] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 489,828, filed March 13, 2023, entitled “Connectivity Framework Having Unified Stack And Messaging Protocol For Embedded Secure Connectivity”, pursuant to 35 USC §119(e), the entire disclosure of which is incorporated herein by reference. Technical Field

[0003] The examples as a whole relate to a connectivity framework for providing connectivity between computing devices for communication. More specifically, some examples relate to a connectivity framework with a unified application layer stack and messaging protocol to facilitate connectivity for a variety of connectivity technologies, including, but not limited to, embedded peripheral technologies, for network communication. Background Technology

[0004] Various types of computing devices utilize a variety of different connectivity technologies. The number of different connectivity technologies used by various types of computing devices is growing, as is the number of device types themselves. Each connectivity technology has its own communication protocols and security features. Given these differences in connectivity technologies, providing an appropriate connectivity framework solution for connecting computing devices in a shared network so that they can "talk" or communicate with each other is quite challenging. Attached Figure Description

[0005] Although this disclosure concludes with claims that specifically point out and clearly claim particular examples, the various features and advantages of the examples within the scope of this disclosure can be more readily identified by the following description when read in conjunction with the accompanying drawings:

[0006] Figure 1 It is an illustrative representation of a system of computing devices with different communication protocols used for communication, based on conventional practice;

[0007] Figure 2 It is based on conventional practice Figure 1 A block diagram of the software framework of an example computing device in multiple computing devices;

[0008] Figure 3 It is an illustrative representation of a system for communication of a computing device according to one or more examples of this disclosure;

[0009] Figure 4AIt is a block diagram depicting a connection frame system including a connection frame for a computing device, based on one or more examples;

[0010] Figure 4B yes Figure 4A The connectivity framework system, which instantiates the connectivity framework as including processing associated with the session layer and processing associated with the message queue management layer;

[0011] Figure 4C It is a block diagram of the software framework of an example computing device based on one or more examples;

[0012] Figure 5 It is a block diagram depicting a system for communication of a computing device, based on one or more examples;

[0013] Figure 6A It is a method for communication-related processing of the connection framework based on one or more examples;

[0014] Figure 6B It is a method for communication-related processing of the connection framework based on one or more examples;

[0015] Figure 7A It is a block diagram depicting the message format for a message to be communicated according to a connection framework messaging, based on one or more examples;

[0016] Figure 7B It describes based on one or more examples. Figure 7A A diagram showing the header of the news report;

[0017] Figure 7C It is a description based on one or more examples having Figure 7B A diagram showing the header fields and the information associated with the source ID and destination ID;

[0018] Figure 7D It is a diagram depicting the fields of a record (e.g., a buffer structure) of an open session based on one or more examples;

[0019] Figure 7E It is a diagram defined based on one or more examples of instruction message types or commands and their examples;

[0020] Figure 8A It is a block diagram depicting a connection frame system including connection frames based on one or more examples;

[0021] Figure 8B , Figure 8C and Figure 8D It describes based on one or more examples. Figure 8AThe diagram illustrates a connection framework system with a session layer and a message queue management layer, serving as an example of the processing associated with message sending and receiving.

[0022] Figure 9 It is a method for handling the operation of the connection framework module based on one or more examples;

[0023] Figure 10 It is a method for handling message transmission functionality in the connection framework processing module, based on one or more examples;

[0024] Figure 11A It is a method for handling the functionality used to establish a communication session in the connection framework processing module, based on one or more examples;

[0025] Figure 11B It is a method for performing message exchange according to mutual authentication and key exchange protocols in the connection framework processing module, based on one or more examples;

[0026] Figure 12 It is a method, based on one or more examples, for processing the functionality in the connection framework processing module for writing data portions to peripheral devices (for data transmission);

[0027] Figure 13 It is a method for processing the data receiving portion (for reading data from peripheral devices) in the connection framework processing module, based on one or more examples;

[0028] Figure 14A It is a flowchart of a data / message flow for transmitting messages using a connectivity framework processing module of a computing device, based on one or more examples;

[0029] Figure 14B It is a flowchart of a data / message flow for receiving messages using a connectivity framework processing module of a computing device, based on one or more examples;

[0030] Figure 15A , Figure 15B , Figure 15C and Figure 15D It is a message queue processing diagram based on one or more examples, which depicts the message queue processing performed by the message queue management layer on messages received in the message queue;

[0031] Figure 16 It is a flowchart of the data / message flow for establishing a secure communication session using a connectivity framework processing module that uses a computing device, based on one or more examples.

[0032] Figure 17A It is a block diagram depicting thumbprints and credentials for secure connection frameworks, based on one or more examples;

[0033] Figure 17B It is a message flow diagram of message flows associated with message exchanges according to one or more examples based on mutual authentication and key exchange protocols;

[0034] Figure 17C It is a block diagram depicting example message passing of the handshake message passing phase of a protocol for mutual authentication and key exchange, based on one or more examples;

[0035] Figure 17D It is a message flow diagram depicting a protocol (e.g., an authentication protocol or a mutual authentication and key exchange protocol) based on one or more examples;

[0036] Figure 18 This is a block diagram illustrating, based on one or more examples, the channel types used for networking using a connection framework;

[0037] Figure 19A It is an illustrative representation of a system for communication of a computing device according to one or more examples of this disclosure;

[0038] Figure 19B It is based on one or more examples Figure 19A The system diagram includes message passing for end nodes registering with the gateway node and message passing for the gateway node distributing routing tables.

[0039] Figure 19C It is based on one or more examples Figure 19A and Figure 19B Example routing table for gateway nodes;

[0040] Figure 20 It is a message flow diagram based on one or more examples of message flow for gateway registration and message routing via gateway nodes using the Unified Messaging Protocol.

[0041] Figure 21 It is a method for routing messages between end nodes via a gateway node, which is used to adapt nodes to a connectivity framework for a unified messaging protocol, based on one or more examples.

[0042] Figure 22 This is a quick overview of the system startup process for an embedded system utilizing a connectivity framework, based on one or more examples.

[0043] Figure 23A It is a network diagram depicting an example mesh network formed by one or more available gateway nodes and end nodes;

[0044] Figure 23B , Figure 23C and Figure 23DIt describes based on one or more examples. Figure 23A The corresponding network diagram for the establishment of the mesh network;

[0045] Figure 23E It is based on the instructions of one or more examples and Figure 23D The formation of a mesh network is represented by a table of related actions;

[0046] Figure 23F It is a network diagram based on one or more examples of mesh networks, which depicts two end nodes joining the mesh network;

[0047] Figure 24 It is an illustrative representation of a cloud networking architecture based on one or more examples, which includes a cloud with a connectivity-enabled framework suitable for providing connectivity for multiple computing devices;

[0048] Figure 25 It is based on one or more examples Figure 24 An example representation of the basic cloud architecture of a cloud with an enabled connectivity framework;

[0049] Figure 26 It is an illustrative representation of a cloud architecture, based on one or more examples, for connecting two clusters, each associated with a different gateway node, to a cloud with a connectivity framework enabled.

[0050] Figure 27 Depicting the relationship based on one or more examples Figure 26 Information associated with the first gateway node;

[0051] Figure 28 Depicting the relationship based on one or more examples Figure 26 Information associated with the second gateway node;

[0052] Figure 29A It is a method for processing messages based on cloud-based connections of computing devices, according to one or more examples;

[0053] Figure 29B It is a method for processing messages based on cloud-based connections of computing devices, according to one or more examples;

[0054] Figure 30 It is a message flow diagram of message flow for cloud-based connectivity to processing computing devices, based on one or more examples;

[0055] Figure 31 The message format, including header and payload, is described based on one or more examples;

[0056] Figure 32 Describes the basis based on one or more examples Figure 31 The message format for publishing messages;

[0057] Figure 33 It is a block diagram of a cloud software architecture for a cloud with an enabled connectivity framework, based on one or more examples; and

[0058] Figure 34 It is a block diagram of a circuit that can be used in some examples to implement the various functions, operations, actions, processes and / or methods disclosed herein. Detailed Implementation

[0059] In the following detailed description, reference is made to the accompanying drawings, which form part of this disclosure, and specific examples of practices in which this disclosure may be practiced are shown by way of illustration in the drawings. These examples are described in sufficient detail to enable those skilled in the art to practice this disclosure. However, other examples may be utilized, and changes in structure, materials, and processes may be made without departing from the scope of this disclosure.

[0060] The illustrations presented herein are not intended to be actual views of any particular method, system, device, or structure, but are merely idealized representations used to describe examples of this disclosure. The accompanying drawings are not necessarily drawn to scale. For the reader's convenience, similar structures or components in the drawings may retain the same or similar numbering; however, similarity in numbering does not imply that the structure or component must be identical in size, composition, configuration, or any other property.

[0061] The following description may include examples to help enable those skilled in the art to practice the disclosed examples. The use of the terms “exemplary,” “by example,” and “for example” indicates that the related description is illustrative, and while the scope of this disclosure is intended to cover examples and legal equivalents, the use of such terms is not intended to limit the scope of the examples of this disclosure to the specified components, steps, features, or functions, etc.

[0062] It should be readily understood that the components of the examples, as generally described herein and illustrated in the accompanying drawings, can be arranged and designed in a variety of different configurations. Therefore, the following description of various examples is not intended to limit the scope of this disclosure, but rather to represent various examples only. While various aspects of the examples may be presented in the accompanying drawings, the drawings are not necessarily drawn to scale unless specifically indicated.

[0063] Furthermore, the specific embodiments shown and described are merely examples and should not be construed as the only way to implement this disclosure unless otherwise indicated herein. Components, circuits, and functions can be shown in block diagram form so as not to obscure this disclosure with unnecessary detail. Rather, the specific embodiments shown and described are merely exemplary and should not be construed as the only way to implement this disclosure unless otherwise indicated herein. Additionally, block definitions and logical partitioning between blocks are examples of specific embodiments. It will be apparent to those skilled in the art that this disclosure can be practiced with many other partitioning solutions. In most cases, details regarding timing considerations, etc., have been omitted, where such details do not require a full understanding of this disclosure and are within the capabilities of those skilled in the art.

[0064] Those skilled in the art will understand that information and signals can be represented using any of a variety of different techniques and methods. For example, data, instructions, commands, information, signals, bits, and symbols, which may be referenced throughout this specification, can be represented by voltage, current, electromagnetic waves, magnetic fields or particles, light fields or particles, or any combination thereof. For clarity of presentation and description, some figures may illustrate signals as a single signal. Those skilled in the art will understand that a signal can represent a signal bus, wherein the bus can have multiple bit widths, and this disclosure can be implemented on any number of data signals, including a single data signal. Those skilled in the art will understand that this disclosure covers the transmission of quantum information and qubits used to represent quantum information.

[0065] The various exemplary logic blocks, modules, and circuits described in conjunction with the examples disclosed herein may be implemented or performed using a general-purpose processor, a special-purpose processor, a digital signal processor (DSP), an integrated circuit (IC), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic elements, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor (which may also be referred to herein as a host processor or simply host) may be a microprocessor, but in alternative embodiments, the processor may be any conventional processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors combined with a DSP core, or any other such configuration. When a general-purpose computer is configured to execute computational instructions (e.g., software code) related to the examples of this disclosure, the general-purpose computer including the processor is considered a special-purpose computer.

[0066] Examples can be described based on processes depicted as flowcharts, schematic diagrams, structural diagrams, or block diagrams. While a flowchart may describe operable actions as a continuous process, many of these actions may be performed in another sequence, in parallel, or substantially simultaneously. Furthermore, the order of actions can be rearranged. A process may correspond to, but is not limited to, a method, thread, function, procedure, subroutine, or subroutine. Moreover, the methods disclosed herein can be implemented in hardware, software, or both. If implemented in software, functions may be stored or transmitted as one or more instructions or code onto a computer-readable medium. Computer-readable media includes both computer storage media and communication media, which includes any medium that facilitates the transfer of a computer program from one location to another.

[0067] Various types of computing devices utilize a variety of different connectivity technologies. The number of different connectivity technologies used by various types of computing devices is growing, as is the number of device types. Each connectivity technology has its own communication protocol and security features. Connectivity technologies may include Universal Asynchronous Receiver-Transmitter (UART), Internal Integrated Circuit (I2C), Serial Peripheral Interface (SPI), Controller Area Network (CAN), T1S, Bluetooth or Bluetooth Low Energy (BLE), IEEE 802.15.4 or Low Rate Wireless Personal Area Network (LR-WPAN), IEEE 802.11 or Wi-Fi, Ethernet, and Universal Serial Bus (USB).

[0068] UART, BLE, T1S, and CAN are typically associated with embedded peripherals, while Wi-Fi and USB are typically not. At least some or all of the connectivity technologies associated with embedded peripherals (e.g., UART, I2C, SPI, CAN, and 802.15.4 or LR-WPAN) can be considered relatively low-end, low-speed (e.g., slow), and / or low-bandwidth technologies, while other connectivity technologies (e.g., Wi-Fi, USB, and Ethernet) can be considered relatively high-end, high-speed (e.g., fast), and / or high-bandwidth technologies.

[0069] Figure 1 This is an example representation of a system 100 with a computing device 120 having different communication protocols for communication, based on conventional practice. Figure 1 The plurality of computing devices 120 includes computing devices 102, 104, 106, 108, 110, and 112. Each computing device within computing device 120 includes peripheral communication devices associated with a specific communication protocol. In other words, the plurality of peripheral communication devices used by computing device 120 are associated with different communication protocols.

[0070] according to Figure 1In the examples, computing device 102 may be a laptop computer including peripheral communication devices for Wi-Fi communication; computing device 104 may be a smartphone including peripheral communication devices for BLE communication; computing device 106 may include peripheral communication devices for T1S communication; computing device 108 may include peripheral communication devices for CAN communication; computing device 110 may be a laptop computer including peripheral communication devices for USB communication; and computing device 112 may be a laptop computer including a debug console that includes peripheral communication devices for UART communication. Other types of computing devices include desktop personal computers (PCs), tablets or tablet PCs, personal digital assistants (PDAs), etc.

[0071] Some computing devices in computing device 120 may include multiple peripheral communication devices with different communication protocols. For example, computing device 104, which is a laptop computer, may include not only peripheral communication devices for Wi-Fi communication, but also peripheral communication devices for BLE communication and peripheral communication devices for USB communication.

[0072] Given the differences in connectivity technologies, a suitable connectivity framework solution (such as...) is designed to connect computing devices 120 in a shared network so that they can "talk" or communicate with each other. Figure 1 The question mark at the center of the group of computing devices 120 (indicated by the question mark) is quite challenging.

[0073] Figure 2 It is based on conventional practice Figure 1 A block diagram of the software framework 200 of an example computing device in multiple computing devices. The computing device includes multiple peripheral communication devices for communication. The software framework 200 includes an application 202 and middleware and driver components 206 residing between the application 202 and the hardware components 204 of the computing device. Here, the application 202 of the computing device needs to handle and manage different data communications 208 according to the different communication protocols of its multiple peripheral communication devices. For example, the application 202 of the computing device may need to handle and manage different communications 208 associated with TIS, CAN, USB, etc.

[0074] Typical methods known to the inventors of this disclosure for cross-peripheral device connectivity attempt to port the Transmit Control Protocol / Internet Protocol (TCP / IP) and Transport Layer Security (TLS) stack to peripheral devices (e.g., relatively slow or low-speed embedded peripherals, but not limited thereto). If this is successful (e.g., for relatively fast or high-speed peripherals, but not limited thereto), the cost is a persistent memory footprint, which often renders the entire application unusable. It should be noted that the TCP / IP approach requires relatively demanding processing and a relatively large footprint (e.g., typically >100kB for all services and standards-compliant implementations of those services under TLS).

[0075] Return to reference Figure 1 The connectivity of computing device 120 can be facilitated by a service provider (such as cloud service provider 150). Depending on the connectivity technology, cloud service provider 150 may use a software development kit (SDK) to facilitate connectivity. The SDK includes a set of software building tools for a specific platform to allow cloud service provider 150 to provide connectivity services. Once the software is built using the SDK, customers are typically “locked in” to cloud service provider 150 for their connectivity services. Moreover, because each peripheral device has its own protocols and security, data may be exposed somewhere on the network (e.g., within cloud service provider 150 or at the gateway), thus end-to-end encryption cannot be guaranteed.

[0076] It is evident that current networking protocols cannot guarantee true end-to-end encryption between two nodes when utilizing multiple protocols, gateways, and / or the cloud. Furthermore, the need for customers to use vendor SDKs and their security infrastructure hinders easy migration and increases costs.

[0077] According to one or more examples of this disclosure, the connectivity framework includes an application layer stack for a general secure connection for multiple connectivity technologies. In one or more examples, the connectivity framework includes a software stack running in the application layer, on top of specific drivers that handle communication peripherals. This stack collects data from lower-level interfaces of the peripherals' input / output buffers according to a common networking protocol. In one or more examples, this stack helps abstract the specific details of any communication stack and provides a unique interface to the application for communicating messages to and from any peripheral device. This stack may be a common software stack utilized at corresponding computing devices in computing devices utilizing different communication peripherals. In one or more examples, the stack may also be utilized at the gateway of the plurality of computing devices or nodes in an interconnected network.

[0078] In one or more examples, the connectivity framework utilizes a lightweight protocol that is easily portable to virtually any peripheral device (e.g., low-end, low-throughput embedded peripherals) and also uses a security protocol compliant with relevant standards to ensure end-to-end encryption. In one or more examples, the connectivity framework natively features routing, addressing, network formation, and mesh networking and cloud connectivity capabilities.

[0079] Similarly, in one or more examples, the connectivity framework's processing resides in the application layer. In other words, the connectivity framework's processing runs on top of the computing device's driver / middleware / operating system (OS) layer. This configuration makes the connectivity framework highly portable to, for example, any existing architecture that provides a way for each channel to pass data (bytes) from the peripheral device's output buffer and receive data (bytes) from the peripheral device's input buffer. Applications can easily access the application programming interfaces (APIs) and services provided by the connectivity framework.

[0080] Figure 3 This is an illustrative representation of a system 300 for communication with a computing device 120 according to one or more examples of this disclosure. The computing device 120 may be related to... Figure 1 The devices described are the same, but adapted according to one or more examples of this disclosure. In one or more examples, the respective computing devices in computing device 120 can communicate with other devices directly or through one or more gateways (such as gateway 302).

[0081] According to one or more examples, computing device 120 is adapted to communicate with each other via multiple peripheral communication devices according to a unified messaging protocol. The unified messaging protocol used by computing device 120 is shared by the various peripheral communication devices of computing device 120. According to one or more examples, computing device 120 is also adapted to establish secure communication sessions with each other through message exchange based on a mutual authentication and key exchange protocol. The mutual authentication and key exchange protocol used by computing device 120 is shared by the various peripheral communication devices of computing device 120.

[0082] Figure 4A This is a block diagram depicting a connection frame system 400 including a connection frame 404 for a computing device, according to one or more examples. The connection frame 404 of the connection frame system 400 may be made of... Figure 3 The corresponding computing devices and / or gateways in computing device 120 and / or gateway 302 are used to facilitate unified messaging protocols and / or mutual authentication and key exchange protocols.

[0083] Figure 4AThe connectivity framework system 400 includes an application 402 of a computing device, a connectivity framework 404, and multiple peripheral communication devices 410. In one or more examples, the connectivity framework 404 may be, include, and / or be referred to as a connectivity framework processing module, and / or include connectivity framework processing instructions or connectivity framework processing. In one or more examples, the connectivity framework 404 includes processor-executable instructions stored in a processor-readable medium (e.g., a data storage device or memory) of the computing device. The processor-executable instructions can be executed by one or more processors of the computing device.

[0084] The connection frame 404 may be positioned between the application 402 and the driver / middleware / MAC layer component 408 (“layer component 408”) of the respective peripheral communication devices in the plurality of peripheral communication devices 410. The respective layer component in the layer component 408 is located above the respective physical layer component in the physical layer component of the plurality of peripheral communication devices 410.

[0085] Therefore, in one or more examples, the processor-executable instructions of the connection frame 404 include an application layer protocol stack to be executed by the one or more processors of the computing device. For example... Figure 4A As illustrated, application 402 can operate in the upper or lower layers of the application layer, and connection frame 404 can reside in the lower layer of the application layer.

[0086] exist Figure 4A In a specific, non-limiting example, the computing device's peripheral communication devices 410 include a T1S interface 412, a Wi-Fi interface 414, a USB interface 416, a BLE interface 418, and a CAN interface 420. The corresponding layer components in layer component 408 may include the following components from bottom to top: For T1S interface 412, which includes a T1S PHY component: T1S MAC, TCP / IP stack, and UDP and TCP sockets; for Wi-Fi interface 414, which includes a Wi-Fi PHY component: Wi-Fi MAC, TCP / IP stack, and UDP and TCP sockets; for USB interface 416, which includes a USB PHY component: USB MAC and USB stack; for BLE interface 418, which includes a BLE PHY component: BLE MAC, transparent UART protocol specification, and BLE sockets; for CAN interface 420, which includes a CAN PHY component: CAN MAC and CAN driver.

[0087] Multiple peripheral communication devices 410 include input / output (I / O) buffers 406 exposed to the connection frame 404 (on the layer component 408). Figure 4AIn a specific, non-limiting example, the I / O buffers 406 of the plurality of peripheral communication devices 410 include: an I / O buffer 422 for a T1S interface 412 (e.g., each buffer being 1500 bytes in size); an I / O buffer 424 for a Wi-Fi interface 414 (e.g., each buffer being 1500 bytes in size); an I / O buffer 426 for a USB interface 416 (e.g., each buffer being 512 bytes in size); an I / O buffer 428 for a BLE interface 418 (e.g., each buffer being 20 bytes in size); and an I / O buffer 430 for a CAN interface 420 (e.g., each buffer being 8 bytes in size). The size associated with each buffer may represent a typical buffer size for each buffer and / or may be associated with the maximum transmittable unit (MTU) of the peripheral communication device.

[0088] although Figure 3 The connection technologies differ, but... Figure 4A The connection framework 404 facilitates communication between computing devices 120 in a shared network, specifically for corresponding computing devices and / or gateways in computing device 120 and / or gateway 302. The connection framework 404 facilitates data communication in message form via corresponding peripheral communication devices among the multiple peripheral communication devices 410, according to a unified messaging protocol shared by the multiple peripheral communication devices 410. In one or more examples, the connection framework 404 is used to cooperate with application 402 to facilitate data communication in message form according to the unified messaging protocol.

[0089] In addition, the connection framework 404 is used to: facilitate message exchange according to a mutual authentication and key exchange protocol shared by multiple peripheral communication devices 410, and establish a secure communication session between the respective peripheral communication device and the respective destination device via the respective peripheral communication device 410. In one or more examples, the connection framework 404 is used to: cooperate with the application 402 to facilitate the establishment of a secure communication session by message exchange according to the mutual authentication and key exchange protocol.

[0090] Figure 4B yes Figure 4A The connectivity framework system 400, which executors connectivity framework 404, includes processing (e.g., processor-executable instructions) associated with session layer 450 and processing (e.g., processor-executable instructions) associated with message queue management layer 460. In one or more examples, message queue management layer 460 may be and / or referred to as message pool abstraction layer.

[0091] Figure 4C This is a block diagram of the software framework 400C for an example computing device based on one or more examples. Figure 4CThe 400C software framework is provided for use with, according to conventional practice Figure 2 The software framework 200 is compared. Figure 4C In one or more examples, the computing device having software framework 400C includes multiple peripheral communication devices for communication. Software framework 400C includes a connectivity framework 404 residing between application 402 and middleware and driver components 206, which reside on top of the hardware components 204 of the computing device. In one or more examples, software framework 400C is configured as part of an application layer protocol stack in a lower or sub-layer of the application layer, while application 402 is configured in an upper or sub-layer of the application layer. Figure 4C In this configuration, the connection frame 404 is used to provide data communication 440 via messages from the respective peripheral communication devices, based on a unified messaging protocol shared by the plurality of peripheral communication devices. For example, the connection frame 404 can provide data communication 440 via messages from the respective interfaces of the T1S interface, CAN interface, and USB interface, based on a unified messaging protocol shared by the T1S interface, CAN interface, and USB interface.

[0092] exist Figure 4A In certain non-restrictive examples, it is possible to use Code Configurator (MCC) in Build a connectivity framework system for computing devices on Harmony. Harmony is a layered framework of modular libraries that provides flexible and interoperable software "building blocks" for developing embedded applications. Harmony is part of a broad and scalable ecosystem offering demo applications, third-party products, and development tools, such as...

[0093] Harmony Configurator (MHC). "[Trademark Name]" is a registered trademark of Microchip Technologies Incorporated, located at 2355 West Chandler Boulevard, Chandler, Arizona, USA, 85224-6199. In one or more other examples, other tools and / or other suitable programming environments may be used to build a connectivity framework system for computing devices, such as those available from NXP Semiconductors NV, STMicroelectronics NV (STM), Silicon Labs, Texas Instruments Incorporated (TI), etc.

[0094] Figure 5 It is a block diagram depicting a system 500 for communication of a computing device according to one or more examples. Figure 5 The computing devices of system 500 include computing device 502 and computing device 504. The corresponding computing devices in computing device 502 and computing device 504 can be configured according to... Figure 4A and Figure 4B Configure the connection frame 404.

[0095] Computing device 502 includes application 510, a layer component 515 of peripheral communication device 514, and a connection frame 512 between application 510 and the layer component 515 of peripheral communication device 514. In one or more examples, peripheral communication device 514 may be or include one or more of the following: UART interface, I2C interface, SPI interface, USB interface, IEEE 802.15.4 interface, Bluetooth interface, Ethernet interface, T1S interface, and Wi-Fi interface. In one or more examples, peripheral communication device 514 is a single low-throughput embedded peripheral device. According to one or more examples, layer component 515 may be or include a driver / middleware / MAC layer component of peripheral communication device 514, and Figure 5 It is indicated as a component including the data link layer, network layer, and transport layer.

[0096] For computing device 502, connection frame 512 serves as an interface between application 510 and peripheral communication device 514 to facilitate a unified messaging protocol and / or a mutual authentication and key exchange protocol. In one or more examples, connection frame 512 prepares and / or encodes messages (e.g., messages including data from application 510 and / or messages for mutual authentication and key exchange protocols) on behalf of application 510 for transmission from computing device 502 via peripheral communication device 514. In one or more examples, connection frame 512 receives and decodes messages received via peripheral communication device 514 on behalf of application 510 (e.g., messages including data for application 510 and / or messages for mutual authentication and key exchange protocols). Peripheral communication device 514 includes an input buffer 516 and an output buffer 518 exposed to connection frame 512. Connection frame 512 is used to write data to input buffer 516 to send data / messages via peripheral communication device 514 and to read data from output buffer 518 to receive data / messages via peripheral communication device 514.

[0097] Similarly, computing device 504 includes application 520, a layer component 525 of peripheral communication device 524, and a connection frame 522 between application 520 and the layer component 525 of peripheral communication device 524. In one or more examples, peripheral communication device 524 may be or include one or more of the following: UART interface, I2C interface, SPI interface, USB interface, IEEE 802.15.4 interface, Bluetooth interface, Ethernet interface, T1S interface, and Wi-Fi interface. In one or more examples, peripheral communication device 524 is a single low-throughput embedded peripheral device. In one or more examples, peripheral communication device 524 of computing device 504 is different from peripheral communication device 514 of computing device 502. According to one or more examples, layer component 525 may be or include a driver / middleware / MAC layer component of peripheral communication device 524, and Figure 5 It is indicated as a component including the data link layer, network layer, and transport layer.

[0098] For computing device 504, connection frame 522 serves as an interface between application 520 and peripheral communication device 524 to facilitate a unified messaging protocol and / or a mutual authentication and key exchange protocol. In one or more examples, connection frame 522 prepares and / or encodes messages (e.g., messages including data from application 520 and / or messages for mutual authentication and key exchange protocols) on behalf of application 520 for transmission from computing device 504 via peripheral communication device 524. In one or more examples, connection frame 522 receives and decodes messages received via peripheral communication device 524 on behalf of application 520 (e.g., messages including data for application 520 and / or messages for mutual authentication and key exchange protocols). Peripheral communication device 524 includes an input buffer 526 and an output buffer 528 exposed to connection frame 522. Connection frame 522 is used to write data to input buffer 526 to send data / messages via peripheral communication device 524 and to read data from output buffer 528 to receive data / messages via peripheral communication device 524.

[0099] Given the arrangement described above, computing devices 502 and 504 can communicate with each other according to a unified messaging protocol. Here, a low-level connection 530 can be established between computing devices 502 and 504, and a networking channel 532 for secure channel networking can also be established between computing devices 502 and 504.

[0100] Return to reference Figure 4A and Figure 4B Given that the I / O buffer 406, handled by traditional driver / firmware / peripheral interfaces, is exposed, the connectivity framework 404, as part of the application layer, can run on existing hardware and even on existing peripheral drivers / stacks. In one or more examples, the connectivity framework 404 "hook" to the I / O buffer 406, prepares data (bytes) to be transferred by the lower layer, and processes incoming data (bytes). In one or more examples, the connectivity framework 404 is completely abstracted from the hardware and low-level firmware. In one or more examples, the connectivity framework 404 includes a built-in Hardware Abstraction Layer (HAL). In one or more examples, the connectivity framework 404 is simpler and lighter (>30kB) than available methods, yet still provides the necessary features to run secure and universal networks usable with all peripherals.

[0101] exist Figure 4A and Figure 4BIn this context, the size of I / O buffer 406 indicates the typical buffer size associated with the transport layer of the corresponding peripheral device, with each standard driver associated with the corresponding peripheral device. The buffer represents the "contact point" between the connection frame 404 and the existing lower layers. Once a message from the connection frame 404 needs to be communicated on a given peripheral device, the connection frame 404 allocates its memory access capacity for memory accesses associated with its message queue in multiples of this buffer size. In one or more examples, this operation is performed to maintain conformity with the underlying standard driver / MAC implementation. For example, regardless of the hardware or driver used, etc., the CAN bus will accept data portions of 8 bytes each, the BLE 4.0 implementation will always have a 20-byte MTU, etc. Given that the connection frame 404 conforms to these buffer sizes, the connection frame can always be securely implemented on top of any hardware / driver / MAC layer component. This implementation makes the connection frame 404 highly portable to (most) any microcontroller unit and (most) any peripheral hardware.

[0102] In one or more examples, the connectivity framework of this disclosure may include processor-executable instructions stored in a processor-readable medium (e.g., a data storage device or memory). The processor-executable instructions may be executed by one or more processors of a computing device that includes one or more peripheral communication devices. In one or more examples, the processor-executable instructions include an application-layer protocol stack to be executed by the one or more processors of the computing device.

[0103] In one or more examples, the computing device may include multiple peripheral communication devices with different communication protocol types. In one or more examples, the multiple peripheral communication devices include three or more (e.g., even five or more) of the following: UART interface, I2C interface, SPI interface, CAN interface, T1S interface, Bluetooth or BLE interface, IEEE 802.15.4 or LR-WPAN interface, Wi-Fi interface, Ethernet interface, and USB interface. In one or more examples, the multiple peripheral communication devices include one or more embedded peripheral communication devices and one or more non-embedded peripheral communication devices. In one or more other examples, the computing device includes only a single peripheral communication device, such as an embedded peripheral communication device (e.g., UART interface, I2C interface, SPI interface, CAN interface, T1S interface, Bluetooth or BLE interface, or IEEE 802.15.4, or LR-WPAN interface).

[0104] In one or more examples, the processor-executable instructions of the connection frame processing module are adapted to cause, when executed by the one or more processors, the one or more processors to perform actions related to... Figure 6A and / or Figure 6B The described operation.

[0105] Figure 6A This refers to method 600A, which is a communication-related processing method for connecting frames, based on one or more examples. The communication-related processing of method 600A can be used... Figure 4A , Figure 4B and Figure 5 404 connection frame and / or used for Figure 5 The connection frames 512 and 522. At action 602, operations are performed on corresponding messages in messages to be transmitted to and from the computing device via the respective peripheral communication devices among the plurality of peripheral communication devices. These operations may include: at action 604, transmitting the corresponding messages in messages via the respective peripheral communication devices among the plurality of peripheral communication devices according to a unified messaging protocol shared by the plurality of peripheral communication devices. These operations may also include: at action 606, using a shared message queue to (temporarily) store the corresponding messages in messages transmitted to and from the computing device via the respective peripheral communication devices among the plurality of peripheral communication devices. In one or more examples, these operations may also include according to Figure 6B Method 600B communication-related processing.

[0106] Figure 6B This refers to method 600B, which is a communication-related processing method for connecting frames, based on one or more examples. The communication-related processing of method 600B can be used... Figure 4A , Figure 4B and Figure 5 404 connection frame and / or used for Figure 5 The connection frames 512 and 522. At action 610, operations are performed on the corresponding secure communication session in the secure communication session to be established between the corresponding peripheral communication device and the corresponding destination device via the respective peripheral communication device among the plurality of peripheral communication devices. These operations may include, at action 612, establishing the corresponding secure communication session in the secure communication session between the corresponding peripheral communication device and the corresponding destination device via message exchange according to a mutual authentication and key exchange protocol shared by the plurality of peripheral communication devices. In one or more examples, these operations may further include, according to Figure 6A Method 600A for communication-related processing.

[0107] The connection framework messaging is now described. Networking and sessions can be established through message exchange, with all messages referring to a unique message structure. In one or more examples, the same message structure can be used throughout the network, propagating unmodified across any peripheral device (even on cloud connections).

[0108] Figure 7AThis is a block diagram depicting message format 706 of message 700 for communication according to a connection framework messaging, based on one or more examples. Message format 706 of message 700 includes a header 702 and a payload 704. In one or more examples, header 702 is a fixed-length header with a predefined length (e.g., 32 bytes). In one or more examples, payload 704 has a maximum payload length of N < 1056 bytes.

[0109] Figure 7B It describes based on one or more examples. Figure 7A A diagram of message header 702 is shown. Header 702 is shown as including header field 708. Header field 708 includes a synchronization preamble (SYN), source interface (SRC IF), source ID (SRC ID), destination interface (DST IF), destination ID (DST ID), acknowledgment request (AR), type (TYP), and payload length (LEN). The source interface and destination interface can each indicate the appropriate peripheral device interface, such as Ethernet, CAN, Wi-Fi, USB, etc. In one or more examples, the synchronization preamble is 4 bytes long, the source interface can be 1 byte long, the source ID can be 11 bytes long, the destination interface can be 1 byte long, the destination ID can be 11 bytes long, the acknowledgment request can be 1 byte long, the type can be 1 byte long, and the payload length can be 2 bytes long.

[0110] Figure 7C It is a description based on one or more examples having Figure 7B The diagram illustrates header field 708, header 702, and information associated with the source ID and destination ID. In one or more examples, at indication 710, for direct communication, the node ID of the end node may include the end node's sequence number (e.g., 9 bytes) and a value (e.g., 2 bytes) "0000" appended to that sequence number. In one or more examples, at indication 712, for communication via a gateway node, a node is assigned a registration ID upon registration to the gateway node. The registration ID includes a cluster ID (e.g., 9 bytes) and a sub-ID (e.g., 2 bytes) appended to that cluster ID. The cluster identified by the cluster ID is a group of nodes that includes the gateway node and one or more end nodes connected to the gateway node and / or registered with the gateway node. In one or more examples, the cluster ID is the gateway node's sequence number, and the sub-ID is a unique selected value (e.g., "0002") for each node registered to the gateway node. The sequence number of the end node or gateway node is a unique number assigned by the node's manufacturer.

[0111] Figure 7DThis is a diagram depicting field 720 of a record (e.g., a buffer structure) of an open session based on one or more examples. Figure 7D The message structure field 720 includes a session ID as the destination ID, session state (STATUS), interface (IFACE) as the destination interface, channel (CHANNEL) (socket or other), key negotiation (ECDH PRIVATE) (temporary private key), transmitted temporary key (MY NONCE), received temporary key (HIS NONCE), destination device public key (HIS PUBLIC), key negotiation (HIS EPHEMERAL) (temporary public key), pre-master key (PREMASTER), incremental HMAC for transmission (HMAC TX), and incremental HMAC for reception. In one or more examples, field 720 may include... Figure 7D The indicated byte length. In one or more examples, all information is not the responsibility of the user (application), but is automatically managed and allocated by the connectivity framework. The user may need to know that, given 2KB of memory, a maximum of N communication sessions can be opened simultaneously. For example, if 2KB is available, then 2*N sessions are available; if 334 bytes are freed, then even more sessions can be made available.

[0112] Figure 7E This is a diagram defining instruction message type 730 or commands and their examples based on one or more examples. Message type 730 includes types for establishing secure communication sessions, including introductory type, introductory response type, intermediate type, intermediate response type, key exchange type, and key exchange response type. Message type 730 also includes registration request type, general encryption and authentication data type, routing table type, session closure type, acknowledgment message type, check channel activity type, and subscribe topic type.

[0113] Figure 8A This is a block diagram depicting a connection frame system 800 including a connection frame 404, according to one or more examples. Figure 8A In the diagram, the connection frame 404 of the connection frame system 800 is shown as including a connection frame processing module 802. The connection frame processing module 802 may include processor-executable instructions (e.g., including an application layer protocol stack) adapted to cause, when executed by one or more processors of a computing device, the one or more processors to perform the various operations described herein. Although in Figure 8A While depicted as a single module, the connection framework processing module 802 may include multiple processing modules, depending on one or more examples. Figure 8AIn the diagram, the corresponding I / O buffers in the I / O buffers 406 of the various peripheral communication devices 410 are shown separately as input buffers (indicated as "I") and output buffers (indicated as "O"). It should be noted that in... Figure 8A In the following figures, multiple peripheral communication devices 410 of the computing device are shown, but their corresponding physical layers are not shown to simplify the illustration.

[0114] In one or more examples, the connection framework processing module 802 operates to provide a set of functions or services to the application 402. This set of functions is associated with a set of APIs 804 exposed to the application 402, which invokes function calls to these functions. These function calls can be received and processed by the connection framework processing module 802. In one or more examples, this set of functions includes one or more functions (including communication-related functions) for conveying messages / data and / or one or more functions (including security session-related functions) for opening or closing secure communication sessions. In one or more examples, this set of functions includes features to be discussed later. Figure 9 , Figure 10 , Figure 11A , Figure 11B , Figure 12 and Figure 13 At least some of the functions described.

[0115] In one or more examples, the connection frame processing module 802 and the application 402 may each interface with the memory cache 806 to pass data and / or messages to each other. Additionally, the connection frame processing module 802 may interface with a message queue 808 for (temporarily) storing messages to be transmitted to and from the computing device via multiple peripheral communication devices 410.

[0116] In one or more examples, the connection framework processing module 802 may perform operations for transmitting corresponding messages in messages via corresponding peripheral communication devices among a plurality of peripheral communication devices 410 according to a predetermined messaging protocol. In one or more examples, the predetermined messaging protocol may be a unified messaging protocol shared by the plurality of peripheral communication devices 410. In one or more examples, the connection framework processing module 802 may use message queue 808 as a shared message queue to perform operations, the shared message queue being used to (temporarily) store corresponding messages in messages transmitted to and from the computing device via the corresponding peripheral communication devices among the plurality of peripheral communication devices.

[0117] Figure 8B , Figure 8C and Figure 8D It describes based on one or more examples. Figure 8AThe connection framework system 800 has a session layer 450 and a message queue management layer 460 (e.g., Figure 4B The block diagram of connection frame 404 is used to illustrate example processing associated with the transmission and reception of messages.

[0118] In one or more examples, the session layer 450 is used to process inbound messages and create outbound messages. Each message belongs to a session; the session is identified by a destination ID. If a message marked as inbound does not belong to any existing session, the message is assumed to be a session initiator message; otherwise, the message may be discarded. The session layer 450 maintains a record of each open session (e.g., a buffer structure allocated in RAM). In one or more examples, the message queue management layer 460 is used to check message queue 808 for outbound messages. For example, when an interface middleware task is "fired," the message queue management layer 460 may check if an outbound message is available, and if so, it may send it out (e.g., based on a header-destination interface). The message queue management layer 460 is used to populate message queue 808 with data (bytes) received on a given peripheral interface. For example, when a receive interrupt or polling task for a peripheral interface is "fired," the message queue management layer collects data (bytes) to populate message queue 808.

[0119] Therefore, in order to transmit messages, the connection frame processing module 802 can perform operations on the corresponding messages in the messages to be transmitted from the computing device via multiple peripheral communication devices 410. Figure 8C Operations of session layer 450 may include preparing a message based on data from application 402 (e.g., stored in memory cache 806) and storing the message in message queue 808 (output message), wherein the message is prepared in a message format according to the Unified Messaging Protocol. In one or more examples, these operations may include encrypting the data and / or encoding the message according to the Unified Messaging Protocol. Operations of message queue management layer 460 may include writing one or more data portions of a message from message queue 808 to the input buffer of an indicated peripheral communication device (e.g., peripheral communication device 412) among a plurality of peripheral communication devices 410 until the message is sent via the indicated peripheral communication device. The same or similar operations may be performed to transmit the message regardless of which of the plurality of peripheral communication devices 410 is used.

[0120] In order to receive messages, the connection frame processing module 802 can perform operations on the corresponding messages in the messages to be received at the computing device via multiple peripheral communication devices 410. Figure 8DThe operations of the message queue management layer 460 may include: reading one or more data portions of a message from the output buffer of an indicated peripheral communication device (e.g., peripheral communication device 412) among the plurality of peripheral communication devices 410, and storing the one or more data portions of the message in message queue 808 until the entire message (input message) is received via the indicated peripheral communication device. In one or more examples, the message has a message format according to the Unified Messaging Protocol. In one or more examples, these operations may include decrypting data, unpacking messages, and / or decoding messages according to the Unified Messaging Protocol. In one or more examples, the message includes a header and a payload including data, wherein the session layer 450 reads the message from message queue 808 and processes the message according to the type indicated in the header (e.g., for further processing by session layer 450 or application 402). The same or similar operations may be performed to receive messages regardless of which of the plurality of peripheral communication devices 410 is used.

[0121] Therefore, in one or more examples, users only need to learn a single simple protocol when designing application 402, thus abstracting away all the complexity associated with the hardware.

[0122] Figure 9 This is a method 900 based on the operation of a connection framework processing module according to one or more examples. At action 902, function calls to at least some of a set of functions of the connection framework processing module are received and processed. This set of functions is associated with a set of APIs exposed to an application that invokes the function calls. In one or more examples, the set of functions includes function 904, which includes: function 910 for transmitting a message, function 912 for establishing a communication session (e.g., a secure communication session), function 914 for writing a portion of data to a peripheral device (for data transmission), and function 916 for receiving a portion of data from the peripheral device (for data reception).

[0123] According to one or more examples, the processing associated with a function call to function 910 used for message transmission can be performed via connector A to... Figure 10 To execute. According to one or more examples, the processing associated with a function call to function 912 used to establish a communication session (e.g., a secure communication session) can be performed via connector B. Figure 11A and / or Figure 11B To execute. According to one or more examples, the processing associated with the function call to function 914, used to write data portions to a peripheral device (for data transmission), can be performed via the connector C to... Figure 12To execute. According to one or more examples, the processing associated with a function call to function 916, which is used to read data from a peripheral device (for data reception), can be performed via the connector D. Figure 13 To execute.

[0124] Figure 10 This refers to method 1000, which, according to one or more examples, handles functions for transmitting messages within the connection framework processing module. In one or more examples, function calls to this function may originate from the connection symbol A. Figure 9 (For example, as function 910 for transmitting messages). At action 1002, a function call for a function used to transmit a message to a destination device is received. This function call indicates input parameters for identifying one or more data items. In one or more examples, the function call indicates input parameters for identifying the following: the data to be transmitted, the destination identifier of the destination device, and the interface identifier of the peripheral communication device through which the message is to be transmitted. In one or more examples, additional and / or alternative input parameters may be used as described elsewhere herein.

[0125] At least in part in response to receiving a function call for a function, at action 1004, a message with a message format according to a predetermined messaging protocol is prepared. This message may include data. In one or more examples, according to... Figure 7A , Figure 7B , Figure 7C , Figure 7D and / or Figure 7E The message is formatted and may include a header and a payload containing data. In one or more examples, the message data may be encrypted based on one or more session keys before transmission. In action 1006, the message is stored in a message queue.

[0126] At action 1008 (e.g., it could be one or more actions), one or more data portions of a message from the message queue are written to a peripheral communication device associated with an interface identifier until the message is sent via that peripheral communication device. In one or more examples, action 1008 for writing the one or more data portions of the message to the peripheral communication device can use a... Figure 9 The function call 914, used to write part of the data to the peripheral device (for data transmission), is transmitted via the connector C to... Figure 12 To execute, as described below later.

[0127] In one or more examples, messages are transmitted via corresponding other peripheral communication devices among the plurality of peripheral communication devices in one or more additional function calls (e.g., Figure 9The corresponding function call of the function 910 for transmitting messages repeats the preparation (in action 1004), storage (in action 1006), and writing (in action 1008) until the (entire) message is sent via the peripheral communication device.

[0128] In one or more examples, the predetermined messaging protocol used to transmit messages includes a unified messaging protocol. This unified messaging protocol is shared by messages transmitted via the multiple peripheral communication devices. In one or more examples, the message queue includes a shared message queue for (temporarily) storing messages transmitted via the multiple peripheral communication devices.

[0129] Figure 11A This refers to method 1100A, which, according to one or more examples, handles functions for establishing communication sessions within the connection framework processing module. In one or more examples, function calls to this function may originate via the connector A. Figure 9 (For example, as function 912 for establishing a communication session). At action 1102, a function call for a function used to establish a communication session with a destination device is received. This function call indicates input parameters for identifying one or more data items. In one or more examples, the function call indicates input parameters for identifying the destination device's destination identifier and the interface identifier of the peripheral communication device through which the communication session is to be established. In one or more examples, additional and / or alternative input parameters may be used as described elsewhere herein.

[0130] At least in part in response to receiving a function call for a function, at action 1104, a message exchange with the destination device is performed via a peripheral communication device associated with the interface identifier, according to a mutual authentication and key exchange protocol. The message exchange is used to establish a communication session with the destination device via the peripheral communication device. The communication session can be a secure communication session. In one or more examples, action 1104 may be based on… Figure 11B Method 1100B is used to execute this.

[0131] In one or more examples, the receiver establishes other communication sessions with other destination devices via other peripheral communication devices among the plurality of peripheral communication devices (e.g., ...). Figure 9One or more additional function calls are made for function 912 (used to establish a communication session). In one or more examples, for the corresponding function call in the one or more additional function calls, message exchange with another destination device is repeatedly performed according to the mutual authentication and key exchange protocol (in action 1104). That is, message exchange is repeatedly performed via another peripheral communication device to establish another communication session with the other destination device via that other peripheral communication device. In one or more examples, the mutual authentication and key exchange protocol used is the same, regardless of which of the plurality of peripheral communication devices the message is exchanged through.

[0132] Figure 11B This refers to method 1100B, which executes message exchange according to a mutual authentication and key exchange protocol within a connection framework processing module, based on one or more examples. In one or more examples, method 1100B may, as follows: Figure 11A The method is performed as in action 1104 of method 1100A. At action 1110, a message including first identity information of the computing device is transmitted to the destination device. The first identity information is used to authenticate the computing device at the destination device. At action 1112, a message including second identity information of the destination device is received from the destination device. The second identity information is used to authenticate the destination device at the computing device. At action 1114, a message including first signed key exchange information of the computing device is transmitted to the destination device. The first signed key exchange information is used to obtain or derive a session key at the destination device. At action 1116, a message including second signed key exchange information of the destination device is received from the destination device. The second signed key exchange information is used to obtain or derive a session key at the computing device.

[0133] In one or more examples, for a corresponding message in a message transmitted according to a mutual authentication and key exchange protocol (e.g., in actions 1110 and 1114), the method may further include: preparing a message of the mutual authentication and key exchange protocol in a message format according to a predetermined messaging protocol; storing the message in a message queue; and writing one or more data portions of the message from the message queue to a peripheral communication device associated with an interface identifier until the message is transmitted via the peripheral communication device.

[0134] In one or more examples, for a corresponding message in a message received according to a mutual authentication and key exchange protocol (e.g., in actions 1112 and 1116), the method further includes: reading one or more data portions from a peripheral communication device, and storing the one or more data portions in a message queue until a message including the one or more data portions is received via the peripheral communication device and stored in the message queue; storing the message in a memory cache of a computing device, the message having a message format according to a predetermined messaging protocol; and processing the message according to the mutual authentication and key exchange protocol.

[0135] In one or more examples, one or more additional function calls are received and processed to establish additional communication sessions with other destination devices via other peripheral communication devices among the plurality of peripheral communication devices. In one or more examples, for the corresponding function call in the one or more additional function calls, the preparation, storage, and writing of the corresponding message in the messages transmitted according to the mutual authentication and key exchange protocol are repeated. In addition, in one or more examples, for the corresponding function call in the one or more additional function calls, the reading, storage, and processing of the corresponding message in the messages received according to the mutual authentication and key exchange protocol are repeated. In one or more examples, the predetermined messaging protocol includes a unified messaging protocol shared by messages transmitted and received through the plurality of peripheral communication devices. In one or more examples, the message queue includes a shared message queue for storing messages transmitted and received through the plurality of peripheral communication devices.

[0136] Figure 12 This refers to method 1200, which, according to one or more examples, handles a function in the connection framework processing module for writing data portions to a peripheral device (for data transmission). In one or more examples, the function call to this function may originate via the connector C. Figure 9 (For example, function 914 for writing a data portion to a peripheral device). At action 1202, a function call for a function to write a data portion of a message to a peripheral communication device is received. This function call indicates input parameters for identifying one or more data items. In one or more examples, the function call indicates input parameters for identifying the data portion and the location of the input buffer of the peripheral communication device for writing the data portion. In one or more examples, additional and / or alternative input parameters may be used as described elsewhere herein. At least in part in response to receiving the function call for the function, at action 1204, the data portion of a message from the message queue is written to the location of the input buffer of the peripheral communication device.

[0137] In one or more examples, the receiver writes the (next) data portion of the message to a peripheral communication device (e.g., Figure 9 One or more additional function calls are made in the function 914 for writing the data portion. At least in part in response to the corresponding function call in the one or more additional function calls, the corresponding data portion of the next data portion of the message from the message queue is repeatedly written to the input buffer of the peripheral communication device at that location (in action 1204).

[0138] Figure 13 This refers to method 1300, which, according to one or more examples, handles the function for reading data from a peripheral device (for data reception) within the connection framework processing module. In one or more examples, the function call to this function may originate via the connector D. Figure 9 (For example, function 916 for reading data from a peripheral device). At action 1302, a function call for the function for reading data from a peripheral communication device is received. This function call indicates input parameters for identifying one or more data items. In one or more examples, the function call indicates input parameters for identifying the location of the output buffer of the peripheral communication device from which the data is read. In one or more examples, additional and / or alternative input parameters may be used as described elsewhere herein. At least in part in response to receiving the function call, at action 1304, the data portion is read from the output buffer of the peripheral communication device at that location and stored in memory.

[0139] In one or more examples, the data portion includes at least a header containing a message with a message format according to a predetermined messaging protocol. In one or more examples, according to... Figure 7A , Figure 7B , Figure 7C , Figure 7D and / or Figure 7E The message formatting includes a header and a payload. The payload may include the message data. In one or more examples, in response to reading the (initial) data portion of the message, a portion of the message queue is allocated or reserved according to the payload length indicated in the header.

[0140] In one or more examples, receiving the next portion of data read from a peripheral communication device (e.g., Figure 9One or more additional function calls are made in the function 916 for reading the data portion. At least in part in response to the corresponding function call in the additional function calls, the corresponding data portion of the next data portion is repeatedly read from the output buffer of the peripheral communication device (in action 1304) for storage at the next consecutive position in the message queue. In one or more examples, reading and storing are repeated until the (entire) message, including the data portion and the next data portion, is received in the message queue. In one or more examples, a signal or indication is provided in response to the data portion filling the message queue to the payload length, indicating "message complete" or "message ready".

[0141] In one or more examples, the message is processed according to the type indicated in the header. For example, when the type indicates session layer processing, the message may be processed by the session layer of the connection framework processing module (e.g., processing associated with the establishment of a communication session). As another example, when the type does not indicate session layer processing and / or indicates application layer processing, the message may be processed by the application. In one or more examples, the message data may be stored in the memory cache of the computing device, and the application may be provided with a signal or indication that the data stored in the memory cache has been received.

[0142] Upon completion of message processing, the allocated memory for the message queue is released. If an error occurs (e.g., unexpected or unknown destination, timeout, synchronization failure, etc.), the element is deleted and the allocated memory is released.

[0143] Figure 14A This is a flowchart of method 1400A according to one or more examples, illustrating a data / message stream for transmitting messages using a connectivity framework processing module of a computing device. At action 1420, application 402 obtains the data to be transmitted to the node. At action 1422, application 402 may insert or store the data to be transmitted in memory cache 806. Here, in one or more examples, application 1420 invokes a function for transmitting a message including data to the destination device (e.g., ...). Figure 9 The function call (910) is used to transmit messages. In one or more examples, the function call indicates input parameters for identifying the following: the data to be transmitted, the destination identifier of the destination device, and the interface identifier of the peripheral communication device (e.g., peripheral communication device 1402) through which the message is to be transmitted among the plurality of peripheral communication devices of the computing device.

[0144] Connection frame 404 is used to receive function calls for functions used to transmit messages. At action 1428, session layer 450 identifies whether a communication session with the destination device has been opened. In this case, a communication session between the computing device and the destination device has been opened. In response, at action 1430, session layer 450 begins processing to transmit the message. More specifically, session layer 450 prepares a message with a message format according to a pre-defined messaging protocol. In one or more examples, the message may include messages according to... Figure 7A , Figure 7B , Figure 7C , Figure 7D and / or Figure 7E The message formatting prepares a header and a payload including the data. In one or more examples, at action 1432, the message data can be encrypted based on one or more session keys 1434. At action 1438, the message 1436 with the encrypted data in memory cache 806 is inserted or stored in a queue position in message queue 808.

[0145] At actions 1442, 1443, 1444, 1445, 1446, 1447, 1448, and 1449, one or more data portions of a message from message queue 808 are written to the peripheral communication device 1402 associated with the interface identifier until the message is transmitted via the peripheral communication device 1402, as indicated at message transmission indication 1450. In one or more examples, the actions described above for writing the one or more data portions of the message to the peripheral communication device may include using an interface identifier... Figure 9 The function call 914, used to write a portion of the data to a peripheral device (for data transmission), is transmitted via the connector C to... Figure 12 To proceed.

[0146] In one or more examples, in action 1442, application 402 may detect the availability of peripheral communication device 1402 for sending data (e.g., by monitoring or interruption). In response to availability, at action 1443, application 402 may invoke a function call to a function for writing data portions to peripheral communication device 1402 (e.g., to...). Figure 9 (Function call 914). In response, message queue management layer 460 obtains data portion 1444 from message queue 808 and writes data portion 1444 to the location of the input buffer of peripheral communication device 1402 to send the data portion. Actions 1442, 1443, and 1445 can be repeated in actions 1446, 1447, and 1449 for one or more additional data portions of the message (e.g., data portion 1448) until the entire message is sent, as indicated at message sent indication 1450.

[0147] Figure 14B This is a flowchart of method 1400B according to one or more examples, illustrating a data / message stream for receiving messages using a connectivity framework processing module of a computing device. At action 1452, application 402 may detect the availability of data received at peripheral communication device 1402 (e.g., by monitoring or interruption). In response to data availability, at action 1453, application 402 may invoke a function call to the portion of the function used to read data from peripheral communication device 1402 (e.g., to...). Figure 9 (Function call 916). In response, at action 1454, message queue management layer 460 reads data portion 1455 from the output buffer of peripheral communication device 1402 and inserts data portion 1455 into queue position 1456 in message queue 808.

[0148] In one or more examples, data portion 1455 is (only) the initial data portion of the message to be received. For example, the message to be received may be larger than the size of the output buffer of peripheral communication device 1402. In one or more examples, data portion 1455 includes at least a header of a message having a message format according to a predetermined messaging protocol. In one or more examples, according to Figure 7A , Figure 7B , Figure 7C , Figure 7D and / or Figure 7E The message formatting allows the entire message to be received to include a header and a payload. In one or more examples, the header includes the payload length of the payload, and at action 1457, the message queue management layer 460 reserves or allocates a memory portion of the message queue 808 equal to or equivalent to the payload length indicated in the header.

[0149] Subsequently, at action 1458, application 402 may detect the availability of additional data received at peripheral communication device 1402 (e.g., by monitoring or interruption). In response to the availability of the additional data, at action 1459, application 402 may invoke an additional function call to the portion of the function used to read data from peripheral communication device 1402 (e.g., ...). Figure 9 (The function call to function 916). In response, at action 1460, message queue management layer 460 reads data portion 1461 from the output buffer of peripheral communication device 1402 and inserts data portion 1461 into the next position in message queue 808. Actions 1458, 1459, and 1460 may be repeated in actions 1462, 1463, and 1464 for one or more additional data portions of the message (e.g., data portion 1465) until the entire message is received, as indicated at message received indication 1466.

[0150] Therefore, message 1468 with encrypted data is stored in message queue 808. At action 1469, message queue management layer 460 may provide a signal or indication to session layer 450 that a message has been received. At action 1470, session layer 450 may pass the message to memory cache 806 for processing. At action 1472, session layer 450 may decrypt the data in the message based on one or more session keys 1474. At action 1476, session layer 450 may unpack and / or process the message based on the message format according to a predetermined messaging protocol (e.g., based on header fields and type). Similarly, in one or more examples, according to... Figure 7A , Figure 7B , Figure 7C , Figure 7D and / or Figure 7E The message is formatted and may include a header and a payload. At least the data 1478 (decrypted) of the message will be stored in memory cache 806. At action 1480, session layer 450 may determine the appropriate processing to be performed on the message based on the type indicated in the header. At action 1482, if the type indicated in the header is for session processing, session layer 450 may perform session layer processing. On the other hand, at action 1484, if the indicated type is for application processing rather than session processing, session layer 450 may provide a signal or indication (e.g., "Data / message received") to application 402.

[0151] Figure 15A , Figure 15B , Figure 15C and Figure 15D The following are examples of message queue processing diagrams 1500A, 1500B, 1500C, and 1500D, illustrating message queue processing performed by the message queue management layer on received messages in message queue 808. In one or more examples, at least a portion of the heap memory is used to construct an efficient message queue (or pool) that ensures smooth, reliable, and ordered processing of data. In one or more examples, the connectivity framework utilizes message queue 808, a mechanism for filling a queue with memory on demand, which is shared by all peripheral devices and technologies.

[0152] exist Figure 15AIn this process, data portions are received and read from the output buffer of peripheral communication device 414. The data portion, stored as data portion 1504, is located at a queue position in message queue 808. In this example, data portion 1504 is only the initial data portion of the message because the message to be received is larger than the size of the output buffer of peripheral communication device 414. Data portion 1504 includes at least a message header (e.g., 32 bytes), where the header includes the payload length of the payload. Based on the payload length indicated in the header, message queue management layer 460 allocates or reserves an allocated memory portion 1502 in message queue 808 equal to or equivalent to that payload length. Available memory portion 1506 of the allocated memory portion 1502 holds the remaining data portion of the message to be received. Figure 15A As shown, the payload length is N bytes.

[0153] exist Figure 15B Then, additional data portions are received and read from the output buffer of peripheral communication device 414 and stored in message queue 808, thereby filling more available memory portions 1506 of the allocated memory portion 1502 of message queue 808. Figure 15C In the process, the remaining data portion of a message is received and read from the output buffer of the peripheral communication device 414 and stored in the available memory portion 1506 of the allocated memory portion 1502 of the message queue 808, such that the total number of bytes received equals the payload length. The message queue management layer 460 may mark a message as complete, ready to be processed, or otherwise provide signals or indications for processing the message (e.g., by the session layer or application).

[0154] exist Figure 15D In this context, insert 1510 indicates that multiple context values ​​can be associated with a message such as message 1508. Context values ​​may include a boundary 1512 (for input / output), a processed value 1514, a timestamp 1516, and a channel 1518. In one or more examples, the processed value 1514 may be the number of bytes processed for message 1508 and is used to identify message completion for message 1508. In one or more examples, the timestamp 1516 may indicate the last time message queue 808 was updated for message 1508 (i.e., the last time bytes were received) and may be based on the system time base. In one or more examples, the channel 1518 (e.g., 0, 1, 2, etc.) may indicate on which channel two nodes are communicating and may include socket or other interface-specific information.

[0155] Figure 16This is a flowchart 1600 illustrating the data / message flow for establishing a secure communication session using a connectivity framework processing module employing a computing device, based on one or more examples. At action 1602, application 402 obtains the data to be transmitted to the node. At action 1604, application 402 may insert or store the data to be transmitted in memory cache 806. Here, in one or more examples, application 402 invokes a function for transmitting a message including data to the destination device (e.g., ...). Figure 9 The function call (910) is used to transmit messages. In one or more examples, the function call indicates input parameters for identifying the following: the data to be transmitted, the destination identifier of the destination device, and the interface identifier of the peripheral communication device (e.g., peripheral communication device 1402) through which the message is to be transmitted among the plurality of peripheral communication devices of the computing device.

[0156] Connection frame 404 is used to receive function calls for functions used to transmit messages. At action 1606, session layer 450 may receive an indication of the message to be transmitted. At action 1608, session layer 450 identifies whether a secure communication session with the destination device is open. In this case, a secure communication session between the computing device and the destination device is not open. At action 1610, session layer 450 may provide an indication that the secure communication session is not open and / or an indication of application waiting. In response, session layer 450 begins processing to establish a secure communication session. More specifically, session layer 450 may initiate message exchange with the destination device according to a mutual authentication and key exchange protocol. In one or more examples, this may be based on... Figure 11B , Figure 17B , Figure 17C or Figure 17D Any of the methods described can be used to perform mutual authentication and key exchange protocols.

[0157] Here, at action 1612, session layer 450 prepares the introductory message and inserts it into message queue 808 as INTRODUCTION MSG OUT 1614. At action 1616, the data portion of the introductory message is retrieved from message queue 808 and written to peripheral communication device 1402 so that a message can be sent from computing device at action 1618 (e.g., according to...). Figure 14A Method 1400A includes actions 1442, 1443, 1444, and 1445, etc. The introduction message is received and processed by the destination device for authentication / verification. In response, the introduction message from the destination device is received at the computing device via peripheral communication device 1402 (e.g., INTRO MSG IN 1620). At action 1622, the data portion of the introduction message is read from peripheral communication device 1402 and inserted into message queue 808 (e.g., according to...). Figure 14B Method 1400B actions 1452, 1453, 1454, and 1455, etc. Session layer 450 receives a signal or indication that an introduction message has been received.

[0158] In response, at action 1626, session layer 450 performs authentication / verification and prepares a key exchange message, inserting it as KEYEX MSG OUT 1628 into message queue 808. At action 1630, the data portion of the introductory message is retrieved from message queue 808 and written to peripheral communication device 1402 to send a message from computing device at action 1632 (e.g., according to...). Figure 14A Method 1400A includes actions 1442, 1443, 1444, and 1445, etc. The key exchange message is received and processed by the destination device for authentication / verification and to derive one or more session keys. In response, a key exchange message (e.g., KEYEX MSG IN 1634) from the destination device is received at the computing device via peripheral communication device 1402. At action 1636, the data portion of the key exchange message is read from peripheral communication device 1402 and inserted into message queue 808 (e.g., according to...). Figure 14B Method 1400B actions 1452, 1453, 1454, and 1455, etc. Session layer 450 receives a signal or indication that an introduction message has been received. In response, at action 1640, session layer 450 performs authentication / verification and derives one or more session keys 1644.

[0159] Subsequently, at action 1642, session layer 450 prepares a message including data (in memory cache 806) for transmission to the destination device (e.g., according to...). Figure 14A Method 1400A includes actions 1430, 1432, 1436, and 1438, etc. One or more session keys 1644 can be used to encrypt the data. A message 1646, including encrypted data in memory cache 806, is inserted or stored in message queue 808. At action 1650, the data portion of the message is retrieved from message queue 808 and written to peripheral communication device 1402 to send the message from computing device at action 1652 (e.g., according to...). Figure 14A Method 1400A (actions 1442, 1443, 1444, and 1445, etc.). In response to the transmission of a message, an acknowledgment signal or indication may be provided at action 1654, and this signal or indication is received by application 402 at action 1656.

[0160] Therefore, secure communication sessions for computing devices can be facilitated by using the session layer 450 of the connection frame 404. In one or more examples, a session between nodes is created during authentication and secured using encryption with a key obtained according to a key negotiation protocol and key derivation function. In one or more examples, authentication can be performed based on an Elliptic Curve Digital Signature Algorithm (ECDSA) signature. In one or more examples, key negotiation and key derivation can conform to National Institute of Standards and Technology (NIST) SP80-56a and -56c.

[0161] In one or more examples, each session is (essentially) equivalent to a Secure Sockets Layer (SSL) / TLS socket. Session keys can be used to encrypt data messages using AES128CBC, and each session key can be signed with an incremental hash-based Message Authentication Code (HMAC).

[0162] According to one or more examples, the connectivity framework 404 provides message structures, compact protocols, and custom cryptographic libraries to offer a minimal memory footprint (e.g., 30KB). In one or more examples, the connectivity framework allows the use of any peripheral driver and any cryptographic device / accelerator. In one or more examples, for smaller microcontroller units, the connectivity framework 404 can be used with secure elements or cryptographic chips (e.g., ECC608) or hardware acceleration. In one or more examples, on personal computers (PCs), servers, or smartphones, the connectivity framework 404 can be distributed as a library (+source) for ease of maintenance. In one or more examples, the connectivity framework uses standard libraries from different operating systems to minimize the impact of continuous or ongoing changes.

[0163] In certain non-restrictive examples, the security of end-to-end encryption can be based on "simpleMAP," an enhancement of compliance with NIST SP800-56a and SP800-56c. TM It is a trademark of Microchip Technology Inc., whose address is 2355 West Chandler Blvd., Chandler, Arizona, USA, 85224-6199.

[0164] In another specific, non-limiting example, connection frame 404 is used to facilitate message exchange according to the mutual authentication and key exchange protocol now described. In one or more specific examples, connection frame 404 may utilize one or more techniques described in U.S. Patent Application Serial No. 16 / 948,101, entitled “Mutual Authentication for Systems With Low-Throughput Communication Links, And Devices For Performing The Same,” published as U.S. Publication No. US20210184869 A1, the entire contents of which are incorporated herein by reference for all purposes. For completeness, some of the techniques associated with the applications mentioned above are described herein.

[0165] When two or more parties wish to communicate, each party's identity is verified through an Elliptic Curve Digital Signature Algorithm (ECDSA) verification process. As part of the ECDSA verification process, the parties exchange identity information in a limited manner (i.e., in terms of the number of messages exchanged and the data size (in bytes)). Although limited, the identity information itself, or in combination with other information known to the parties, is sufficient to successfully perform the ECDSA verification process. Once verified, the parties exchange (e.g., by performing a key exchange negotiation protocol, but not limited to) an appropriately signed Elliptic Curve Diffie-Hellman (ECDH) session key, which is used to derive a session key for communication. The session key can be used to encrypt communications (e.g., messages, certificates, codes, but not limited to) according to cryptographic ciphers such as symmetric encryption algorithms (e.g., Advanced Encryption Standard (AES) 128, AES 256, but not limited to), stream ciphers (e.g., Salsa 20, Rivest Cipher (RC) 4, RC5, or RC6, but not limited to), or symmetric-key adjustable block ciphers (e.g., ThreeFish, but not limited to), but not limited to these.

[0166] Figure 17AThis is a block diagram depicting the structure 1700A of a thumbprint 1702 and credential 1708 for connection frame security according to one or more examples. In one or more examples, the thumbprint 1702 may be referred to as a connection frame (CF) thumbprint, and the credential 1708 may be referred to as a CF credential. The thumbprint 1702 includes a public key 1704 and a digital signature 1706 (e.g., total size 150 bytes). The public key 1704 may include a serial number (SN) associated with the owner and an SN associated with the issuer. In one or more examples, the credential 1708 includes a device thumbprint 1710 (e.g., 150 bytes), an intermediate thumbprint 1712 (e.g., 150 bytes), a server thumbprint 1714 (e.g., 150 bytes), and a Certificate Authority (CA) thumbprint 1716 (e.g., 150 bytes) (e.g., where the total size of the credential 1708 may be 600 bytes).

[0167] Figure 17B This is a message flow diagram 1700B associated with message exchange according to a mutual authentication and key exchange protocol, based on one or more examples. In one or more examples, end node 1720 may be associated with a first party, and end node 1722 may be associated with a second party. At action 1724, end node 1720 prepares an introduction message including first identity information of end node 1720. In one or more examples, the first identity information may be or include the CF thumbprint of end node 1720, which may be signed by an intermediate CA. At action 1726, end node 1720 transmits the introduction message including the CF thumbprint to end node 1722. End node 1722 receives the introduction message from end node 1720. At action 1728, end node 1722 verifies the CF thumbprint of end node 1720. At action 1730, end node 1722 prepares an introduction message including second identity information of end node 1722. In one or more examples, the second identity information may be or include the CF thumbprint of end node 1722, which may be signed by an intermediate CA. At action 1732, end node 1722 transmits an introduction message including the CF thumbprint to end node 1720. End node 1720 receives the introduction message from end node 1722. At action 1734, end node 1720 verifies the CF thumbprint of end node 1722.

[0168] At action 1736, end node 1720 prepares a key exchange message including an ECDH public key signed with its CF thumbprint. ECDH is a key agreement protocol that allows two parties (each with an elliptic curve public-private key pair) to establish a shared secret over an otherwise insecure channel. At action 1738, end node 1720 transmits the key exchange message including the signed ECDH public key to end node 1722. End node 1722 receives the key exchange message from end node 1720. At action 1740, end node 1722 verifies the key exchange message from end node 1720. At action 1742, end node 1722 prepares a key exchange message including an ECDH public key signed with its CF thumbprint. At action 1744, end node 1722 transmits the key exchange message including the signed ECDH public key to end node 1720. End node 1720 receives the key exchange message from end node 1722. At action 1746, end node 1722 verifies the key exchange message from end node 1722. At action 1748, end node 1720 derives one or more session keys 1750 based on the key exchange for secure communication with end node 1722. Similarly, at action 1752, end node 1722 derives one or more session keys 1754 based on the key exchange for secure communication with end node 1720.

[0169] Figure 17C This is a block diagram depicting example message passing 1700C for a handshake message passing phase of a mutual authentication and key exchange protocol according to one or more examples. As part of the identity information exchange, a first message 1726 and a second message 1732 are transmitted. As depicted, each message includes a device certificate portion signed by the "signer," a signer certificate signed by a certificate authority, and a cryptographic temporary number (e.g., a 32-byte random number). As part of the exchange of key negotiation information via a signed key negotiation exchange protocol, a third message 1738 and a fourth message 1744 are transmitted. As described, each message includes a signed temporary public key (e.g., signed with a digital signature generated using the sender's temporary private key and the received cryptographic temporary number). In one or more examples, the signed temporary public key can be signed with a digital signature generated using the sender's temporary public key and the received cryptographic temporary number.

[0170] Figure 17D It is a message flow diagram depicting Protocol 1700D (e.g., an authentication protocol or a mutual authentication and key exchange protocol) according to one or more examples. Figure 17DIn a specific, non-limiting example, the first-party end node 1720 and the second-party end node 1722 execute protocol 1700D, which may include two phases: a handshake messaging phase 1760 and an encrypted communication phase 1774 executed upon successful execution of the handshake messaging phase 1760.

[0171] During the handshake message passing phase 1760, as part of an attempt to agree on a set (or more) of encryption keys that will be used by the parties to encrypt and decrypt messages during a secure communication session between them, the first end node 1720 and the second end node 1722 exchange information. Such encryption keys may be referred to herein as “session keys.” More specifically, the parties attempt to agree on an intermediate key from which multiple session keys can be derived; such intermediate keys are referred to herein as “session secrets.” Performing the handshake message passing phase 1760 may also be characterized herein as the exchange of messages between the parties (here, the first party associated with the first end node 1720 and the second party associated with the second end node 1722) for “establishing a secure communication session.”

[0172] In operation 1762, end node 1720 and end node 1722 exchange corresponding identity information by performing a first message pass in the handshake message passing phase 1760. The first message pass may include each of the first end node 1720 and the second end node 1722 transmitting a message (the first message and the second message, respectively) containing its corresponding identity information (which may include optional cryptographic temporary numbers), which is received by the other party. The identity information may include one or more digital certificates, or may be in the form of such digital certificates, for sharing information about the party, its public key, the signer of the party's certificate, and the certificate authority that authenticated the signer. A public key certificate is a digital certificate that authenticates ownership of a public key. A party's public key certificate may be referred to herein as a "device certificate." The use of digital certificates for authenticating entity identity for reasons other than authenticating public key ownership is not beyond the scope of this disclosure.

[0173] Typically, the signer's role is to introduce an entity that has been certified (signed) by a certificate authority, thereby enabling devices (such as first end node 1720 and second end node 1722) to sign (certify) using a private key provided by the signer. This private key is carried by such devices (e.g., stored, but not limited to), which carries less risk than carrying the certificate authority's private key, as carrying the certificate authority's private key would require significant effort to protect and secure it. The signer's certificate can be signed (i.e., certified) by a certificate authority, and the device certificate can be signed (i.e., certified) by the signer. In one or more examples, the identity information may include a signed device certificate portion and the signer's signed public key certificate arranged in the certificate chain.

[0174] The identity information exchanged by the parties may include a portion of a device certificate signed by a signer certified by a certificate authority. As a non-limiting example, identity information may be included in a certificate corresponding to a portion of the device certificate and formatted in X.509. X.509 is currently defined by the ITU Telecommunication Standardization Sector (ITU-T). In one or more examples, the signed device certificate portion may include some, but not all, of the information used in TLS certificates, Secure Sockets Layer (SSL) certificates, or similar types of certificates. The signed or unsigned device certificate portion may have a public key certificate format such as that according to X.509 (including its extensions). Such public key certificate formats may include a specific certificate structure that defines specific fields for specific information and the size of the corresponding fields in bytes. While some or all of the information in the signed device certificate portion exchanged by the parties may be compressed, unlike a compressed public key certificate, the signed or unsigned device certificate portion can only be recovered by decoding the bits of the compressed public key certificate. Each party can recover the other party's device certificate based on the signed device certificate portion, and as a non-limiting example, the ECDSA verification process can be used to verify the identity of the other party using the corresponding recovered device certificate.

[0175] In one or more examples, a signed or unsigned device certificate or a portion of a device certificate may include instructions for requesting a public key from the sender. Specifically, the portion of the device certificate provided by end node 1720 may include instructions for requesting a public key from end node 1720, and the portion of the device certificate provided by end node 1722 may include instructions for requesting a public key from end node 1722. In one or more examples, these instructions may be encoded using a device certificate or a portion of a device certificate, and may be recovered and / or executed (non-limiting example) as part of an ECDSA verification process.

[0176] In Operations 1764 and 1766, each party uses the ECDSA verification process to verify the identity of the other party using the exchanged identity information (as a non-limiting example). Where the device certificate and signer certificate are arranged in a certificate chain, for each party, the verification process in Operations 1764 and 1766 may include: verifying the signer signature applied to the signed device certificate portion using ECDSA verification and the signer's public key included in the signer's public key certificate signed by the certificate authority. The certificate authority signature applied to the signer's public key certificate may be verified using ECDSA verification and the certificate authority's public key delivered separately from Protocol 1700D via a trusted delivery process.

[0177] If both end nodes 1720 and 1722 verify the other, they obtain the other's corresponding public key (which is transmitted in the other's signed device certificate portion) and can proceed to operation 1768. If neither party verifies the other, operations 1762, 1764, and 1766 of protocol 1700D can be re-executed until the corresponding identities of both parties are verified (e.g., or a certain threshold number of verification attempts have been performed) or protocol 1700D can be terminated.

[0178] In operation 1768, via a second message pass in the handshake message passing phase 1760, end nodes 1720 and 1722 exchange signed key negotiation exchange information. The second message pass may include each party transmitting messages containing its signed key negotiation exchange information (a third message and a fourth message, respectively), which are received by the other party. The signed key negotiation exchange information may include each party's signed temporary public key.

[0179] In one or more examples, the first and second encrypted temporary numbers exchanged in operation 1762 may be used by the parties to perform some operations in the operation of the exchanged signed key. As a non-limiting example, the encrypted temporary numbers (including, but not limited to, the first and second encrypted temporary numbers) may be one-time use numbers (e.g., arbitrary numbers, such as time-varying numbers, random numbers, pseudo-random numbers, or combinations thereof, but not limited to) provided by end node 1720 and end node 1722, respectively. End node 1720 and end node 1722 use the first and second encrypted temporary numbers, respectively, to identify a specific authentication session (i.e., an authentication session corresponding to a specific execution of protocol 1700D), a specific communication, or a specific secure communication session, and associate messages with them. An attacker cannot, or at least finds it much more difficult to, copy and retransmit the encrypted messages that one party will receive, a so-called "replay attack," in which the receiver treats the attacker's message as if it were transmitted by an authenticated sender.

[0180] In one or more examples, an encoded digital signature can be generated by encoding the generated digital signature with the other party's cryptographic random number (i.e., a cryptographic temporary number received in a previous message), and the encoded digital signature can be used to sign a temporary public key.

[0181] In operations 1770 and 1772, end nodes 1720 and 1722 each perform one or more computations for the protocol of the signed key negotiation exchange. In one or more examples, the computations of operations 1770 and 1772 include obtaining a session secret. In various implementations, the session secret may be usable by one or both parties to obtain or recover a session key. In a particular non-limiting example, the session secret can be obtained using the ECDH algorithm and is referred to as an "ECDH session key". A particular non-limiting example of an ECDH session key class session secret is a pre-master key, which can be obtained by performing a particular ECDH algorithm using a combination of the signed temporary public key exchanged by end nodes 1720 and 1722 in operation 1768 and the temporary private key generated by end nodes 1720 and 1722.

[0182] In one or more examples, Protocol 1700D obtains one or more session keys by performing a specific ECDH algorithm (e.g., an ECDH key negotiation protocol) at end nodes 1720 and 1722 using a combination of a signed public key and a corresponding private key. Non-limiting examples of session keys that can be obtained from an ECDH session key include: a 32-byte AES key obtained by performing an HKDF derivation function on the ECDH session key; 16-byte AES and 16-byte AESIV keys derived from the 32-byte AES key; and a 32-byte HMAC key.

[0183] In one or more examples, each of the end nodes 1720 and 1722 used to implement Protocol 1700D can be configured to obtain a hash-based Message Authentication Code (HMAC) key or a salted HMAC key by applying a hash-based Simple Key Derivation Function (HKDF) to a session secret (e.g., an ECDH session key) and one or both of a first and a second encrypted temporary. Upon obtaining one or more of the session key and the HMAC key, each of end nodes 1720 and 1722 can use these session key and HMAC key to encrypt data and perform encrypted communication as part of a secure communication session.

[0184] It is worth noting that the operation of the handshake message passing phase 1760 of protocol 1700D can be performed by exchanging a specific number or a maximum number of messages and bytes between end node 1720 and end node 1722. In a particular non-limiting example, four messages (i.e., each party transmits a message including identity information and a cryptographic temporary, and each party transmits a message including a signed temporary public key), totaling 960 bytes (the first and second messages, each: 320 bytes of certificate chain + 32 bytes of cryptographic temporary; and the second and third messages, each: 64 bytes of temporary public key and 64 bytes of digital signature—together forming the signed temporary public key), are exchanged between end node 1720 and end node 1722 during operations 1762 and 1768. Typical TLS protocols known to the inventors of this disclosure use several gigabytes of data to perform a handshake phase equivalent to handshake message passing phase 1760.

[0185] As discussed above, operations 1762, 1764, 1766, 1768, 1770, and 1772 form some or all of the handshake message passing phase 1760 of protocol 1700D. Operations 1776 and 1778 to be described include some or all of the operations in the encrypted communication phase 1774 of protocol 1700D.

[0186] In operation 1774, protocol 1700D establishes a secure communication session between end node 1720 and end node 1722. As a non-limiting example, the secure communication session can be considered to be established in response to end node 1720 and end node 1722 successfully performing the handshake message passing phase 1760. In operation 1778, end node 1720 and end node 1722 communicate using a secure communication link, and more specifically, using messages encrypted by an encryption algorithm and a session key derived by performing operations 1768, 1770, and 1772. Each party can use the derived session key to decrypt encrypted messages received from the other party.

[0187] As described in one or more examples in this paper, the connectivity framework utilizes a messaging system that allows address distribution, network formation, routing, and secure peer-to-peer (P2P) sessions. This includes authenticated address distribution, routing and message forwarding, clustering and mesh networking, secure P2P sessions compliant with NIST standards (SP80-56a and -56c) (e.g., similar to TLS), and cloud connectivity.

[0188] The connectivity framework networking is now described in more detail. Based on one or more examples, a common protocol is provided for use with virtually any peripheral device. In one or more examples, the common protocol significantly reduces the complexity of bridging and / or message routing in multi-technology networks. In one or more examples, the common protocol ensures end-to-end encryption and authentication for nodes, as well as lightweight secure communication. In one or more examples, the common protocol facilitates the use of different network topologies and natively provides mesh networking support. In one or more examples, the common protocol allows customers to extend connectivity to the cloud without modifying the protocol to use any suitable messaging protocol broker (e.g., an MQTT broker, as described later in this document), thereby enabling the use of any service provider.

[0189] Figure 18 This is a block diagram illustrating channel type 1800 for networking using a connectivity framework, based on one or more examples. Channel type 1800 includes a Local Area Network (LAN) channel 1802, a Gateway (GWY) channel 1804, and a Wide Area Network (WAN) channel 1806. LAN channel 1802 is a channel established between a gateway node and an end node. GWY channel 1804 is a channel established between gateway nodes. WAN channel 1806 is a channel established between a gateway node and one or more remote gateway nodes (e.g., with an intermediary network, such as a cloud service provider, connecting them).

[0190] Figure 19A This is an illustrative representation of a system 1900 for communication with a computing device 1905 according to one or more examples of this disclosure. The computing device 1905 may be or include communication with... Figure 3 The devices described are some of the same devices that have been adapted according to one or more examples of this disclosure.

[0191] In one or more examples, a corresponding computing device in computing device 1905 can communicate with other devices via gateway node 1902. In one or more examples, computing device 1905 is adapted to communicate with each other via gateway node 1902 according to a unified messaging protocol. The unified messaging protocol used by computing device 1905 is shared by different peripheral devices of computing device 1905. In one or more examples, computing device 1905 is also adapted to establish secure communication sessions with each other via gateway node 1902 based on message exchange according to a mutual authentication and key exchange protocol. The mutual authentication and key exchange protocol used by computing device 1905 is shared by multiple different peripheral communication devices of computing device 1905.

[0192] exist Figure 19A In this context, computing device 1905 includes end node 1904 and end node 1906. Figure 19AIn a specific, non-limiting example, end node 1904 includes a peripheral communication device for Wi-Fi communication, and end node 1906 includes a peripheral communication device for T1S communication. Gateway node 1902, end node 1904, and end node 1906 form a cluster of devices or nodes associated with a cluster ID.

[0193] In one or more examples, gateway node 1902 includes multiple peripheral communication devices for various different communication protocols. In one or more examples, gateway node 1902 includes at least peripheral communication devices for Wi-Fi communication and T1S communication. In one or more other examples, gateway node 1902 includes multiple peripheral communication devices for most or all (e.g., supported) communication protocols (e.g., see [link to relevant documentation]). Figure 3 Regardless of whether a particular interface is currently being used by an end node.

[0194] Figure 19B It is based on one or more examples Figure 19A The system 1900 block diagram includes message passing for end nodes registering with gateway node 1902 and message passing for gateway node 1902 distributing routing tables.

[0195] End nodes or gateway nodes can register with a gateway node. In one or more examples, registering from an end node to a gateway node may include: being authenticated and receiving the gateway node's routing table, and receiving an ID as part of the cluster (e.g., ID = <gateway sequence number>child ID>). In one or more examples, registering from a gateway node to another gateway node may include: establishing a GWY channel with the gateway node, and receiving a routing table containing all GWY and WAN channels existing on the gateway node. Gateway nodes are used to maintain and distribute routing tables, which include a list of all connected nodes and channels. In one or more examples, gateway nodes are used to periodically check the status of their connections to keep the routing table updated regularly. For example, a gateway node may be operable to send periodic "sanitycheck" messages to ensure that the connection remains active.

[0196] Therefore, for communication via gateway node 1902, the end node is assigned a registration ID upon registering with gateway node 1902. The registration ID includes a cluster ID and a sub-ID appended to the cluster ID (see, for example, [link to relevant documentation]). Figure 7CA cluster, identified by a cluster ID, is a group of nodes, including gateway node 1902 and one or more end nodes registered to gateway node 1902 for communication. In one or more examples, the cluster ID is the sequence number of gateway node 1902, and the sub-ID is a selected value unique to each node registered to gateway node 1902 (e.g., "0002"). In one or more examples, the sequence number of the end node or gateway node is a unique number assigned by the node's manufacturer.

[0197] exist Figure 19B In the example, the sequence number of gateway node 1902 is "A1B1C1", the sequence number of end node 1904 is "A2B2C2", and the sequence number of end node 1906 is "A3B3C3". For direct communication, end nodes 1904 and 1906 can use their respective sequence numbers for identification. For communication via gateway node 1902, end nodes 1904 and 1906 will use their respective registration IDs assigned by gateway node 1902. Here, end node 1904 can send a message to register with gateway node 1902. In response, gateway node 1902 can select or generate a registration ID for end node 1904 and send a message including its registration ID to end node 1904. Similarly, end node 1906 can send a message to register with gateway node 1902. In response, gateway node 1902 can select or generate a registration ID for end node 1906 and send a message including its registration ID to end node 1906. exist Figure 19B In the example, the registration ID of end node 1906 can be "A1B1C10002".

[0198] Figure 19C It is based on one or more examples Figure 19A and Figure 19B Example routing table 1910 for gateway node 1902. Gateway node 1902 is used to generate and maintain (e.g., periodically update) routing table 1910, which includes a list 1920 of routing table entries. In one or more examples, gateway node 1902 may distribute routing table 1910 to its end nodes, enabling each end node to communicate with other nodes. In one or more examples, gateway node 1902 may periodically or periodically distribute updated routing tables to its end nodes, enabling each end node to communicate with other nodes.

[0199] Figure 20 This is a message flow diagram of message flow 2000 for gateway registration and message routing via gateway node 1902 using the Unified Messaging Protocol, based on one or more examples. Message flow 2000 and about Figure 19A and Figure 19BThe described device cluster is associated. At action 2002, end node 1904 sends a registration message to gateway node 1902. In response, at action 2004, gateway node 1902 selects or generates a registration ID for end node 1904. At action 2006, gateway node 1902 sends a message including its registration ID to end node 1904. Figure 20 In the example, the registration ID of end node 1904 could be "A1B1C10001". In one or more examples, the registration ID may be included in the payload of the response message. At action 2008, end node 1904 sets its ID to the registration ID to communicate via gateway node 1902. At action 2010, end node 1906 sends a message to register with gateway node 1902. In response, at action 2012, gateway node 1902 selects or generates a registration ID for end node 1906. At action 2014, gateway node 1902 sends a message including its registration ID to end node 1906. Figure 20 In the example, the registration ID of end node 1906 could be "A1B1C10002". In one or more examples, the registration ID may be included in the payload of the response message. At action 2016, end node 1906 sets its ID to the registration ID to communicate via gateway node 1902. At action 2018, gateway node 1902 may distribute its routing table to end nodes 1904 and 1906.

[0200] Return to reference Figure 19C The list 1920 of routing table entries in routing table 1910 includes the registration ID of the end node, which is stored in association with the corresponding sequence number and peripheral device interface of the end node. Figure 19C In the example, the list 1920 of routing table entries includes entry 1922 associated with gateway node 1902, entry 1924 associated with end node 1904, and entry 1926 associated with end node 1906. Entry 1922 for gateway node 1902 is associated with ID “A1B1C10000”, serial number “A1B1C1”, and all interfaces. Entry 1924 for end node 1904 is associated with registration ID “A1B1C10001”, serial number “A2B2C2”, and the Wi-Fi interface used for routing. Entry 1926 for end node 1906 is associated with registration ID “A1B1C10002”, serial number “A3B3C3”, and the T1S interface used for routing.

[0201] Return to Figure 20In message flow 2000, after the routing table is distributed in action 2018, at action 2020, end node 1904 prepares the message and transmits it to end node 1906 via gateway node 1902. In one or more examples, the destination ID may be the registration ID of end node 1906 (“A1B1C10002”), and the source ID may be the registration ID of end node 1904 (“A1B1C10001”). Gateway node 1902 receives the message from end node 1904. At action 2022, gateway node 1902 looks up the routing table. In one or more examples, gateway node 1902 may perform a lookup in the routing table based at least on the destination ID in the message. In one or more examples, gateway node 1902 identifies the interface identifier based at least on the destination ID, where the interface identifier corresponds to the peripheral device interface through which the message is transmitted. At action 2024, gateway node 1902 forwards the message to end node 1906 via the peripheral device interface corresponding to the interface identifier. End node 1906 receives messages from gateway node 1902, as indicated at message received indication 2026.

[0202] Figure 21 This is a method 2100 for routing messages between end nodes via a gateway node, according to one or more examples, the gateway node being adapted to nodes within a connectivity framework for a unified messaging protocol. In one or more examples, the actions or operations of method 2100 may be performed at a gateway node comprising multiple peripheral communication devices with different communication protocols. In one or more specific examples, method 2100 may be performed by a computing device including one or more processors, multiple peripheral communication devices with different communication protocol types operatively connected to the one or more processors, and a memory for storing processor-executable instructions that, when executed by the one or more processors, cause the one or more processors to perform the operations of the gateway node according to method 2100.

[0203] At action 2102, a message can be received from a first end node via a first peripheral communication device among the plurality of peripheral communication devices. The message includes a source identifier and a destination identifier, the source identifier including a first end node identifier assigned to the first end node, and the destination identifier including a second end node identifier assigned to a second end node. At action 2104, a routing table can be consulted at least in part in response to the receipt of the message. At action 2106, the message can be forwarded to a second end node via a second peripheral communication device among the plurality of peripheral communication devices, at least in part based on an entry in the routing table. This entry includes an interface identifier stored in association with a second end node identifier, wherein the interface identifier corresponds to the second peripheral communication device among the plurality of peripheral communication devices.

[0204] In one or more examples, the message has a message format according to a predetermined messaging protocol. In one or more examples, the predetermined messaging protocol includes a unified messaging protocol shared by messages received and forwarded through the plurality of peripheral communication devices. The message may include a header and a payload including data, and the header may include a source identifier and a destination identifier.

[0205] In one or more examples, Figure 21 At instruction 2108, the first end node identifier includes a cluster identifier and a first number appended to that cluster identifier, and the second end node identifier includes a cluster identifier and a second number appended to that cluster identifier. In one or more examples, the cluster identifier matches the sequence number of the gateway node (action 2108). In one or more examples, the first end node identifier assigned to the first end node for routing messages via the gateway node is different from the sequence number of the first end node, and the second end node identifier assigned to the second end node for routing messages via the gateway node is different from the sequence number of the second end node.

[0206] Prior to the action or operation of method 2100, a first registration message may be received from a first end node. At least in part in response to receiving the first registration message, a first end node identifier may be assigned to the first end node, and a first response message including the first end node identifier may be transmitted to the first end node. Additionally, a second registration message may be received from a second end node. At least in part in response to receiving the second registration message, a second end node identifier may be assigned to the second end node, and a second response message including the second end node identifier may be transmitted to the second end node. In one or more examples, copies of the routing table may be distributed to the corresponding end nodes in the first and second end nodes.

[0207] Connectivity Framework Embedded Library. This section describes a user guide for the Connectivity Framework embedded library. Connectivity Framework is characterized by a set of libraries and tools for implementing general-purpose messaging systems. Secure connectivity in embedded systems is increasingly becoming a requirement for any project. However, the lack of common standards among the most commonly used peripherals often makes implementation very complex. The purpose of Connectivity Framework is to simplify communication within networks composed of different technologies and to allow even the smallest MCUs to communicate securely with any peripheral device.

[0208] The Connection Framework is a secure networking protocol that runs at the application layer. This makes the Connection Framework portable to any project, any controller, and / or any peripheral device. Each peripheral device has its own stack and its own operating mechanism, but each peripheral device shares a common end goal: receiving and transmitting data bytes. The Connection Framework is hooked into the low-level functions of each peripheral device that is ultimately responsible for passing data bytes into or out of buffers. Once the function that transmits bytes out is associated with the data that the Connection Framework will inject into those buffers, and once the function that receives bytes from that peripheral device presents those bytes to the Connection Framework, the complete connection on that peripheral device will be fully managed by the Connection Framework. This means that the user (application) will no longer interface with the peripheral device's API to send and receive messages, but will rely entirely on the Connection Framework to do so. Memory and queue management, synchronization, network addressing, etc., are all managed entirely by the Connection Framework. The user (application) can simply instruct the Connection Framework to send data to a specific node in the network, providing its identifier and data. All other operations (e.g., opening secure, authenticated, and encrypted sessions, routing, decryption, timing, etc.) will be handled by the library.

[0209] Connected-frame networks can take various forms, from P2P to multi-mesh structures, and can be extended via a connected-frame "cloud" to propagate over the Internet and reach remote nodes. Definitions and / or names are now provided in one or more examples in this disclosure.

[0210] Node. A device (controller / PC / server / smartphone) equipped with a connection framework stack and uniquely identified by an ID.

[0211] ID. The ID is an identifier that each node must use to participate in the connection framework network. It consists of 11 bytes.

[0212] Serial Number (SN) (9 bytes): A unique identifier, typically taken from the SN of the onboard security element. Sub-ID (SID) (2 bytes): A unique identifier assigned to a node joining the network. The sub-ID defaults to 0x00,0x00 until the node is registered by the gateway (the gateway will assign different IDs to nodes).

[0213] When the ID consists of the device’s actual SN and has two zeros as sub-IDs, the ID is defined as ORIGINAL-ID.

[0214] An ID is defined as a registration ID when it consists of the SN of the gateway that registers the device in its subnet and has a sub-ID assigned by that gateway.

[0215] When a device wants to communicate with a node belonging to a subnet, the device must use a registration ID assigned by the gateway of that subnet.

[0216] Channels. A channel is a logical communication channel, defined by the underlying stack that manages a particular peripheral device (e.g., a socket on a TCP / IP stack, a connection with a specific address on CAN / RS485 / 802.15.4, a specific endpoint on USB, etc.). Ultimately, a channel can be defined as an integer assigned by the user to a specific connection that can be distinguished within its system. For example, consider a device with an Ethernet interface and a CAN interface: the user can assign channel-0 to a socket facing IP x, channel-2 to a socket facing IP y, and channel-3 to a CAN endpoint connected at address 0x399. In other words, channel information (this integer) is used within the connection framework to distinguish which logical channel data bytes enter or exit on that peripheral device.

[0217] Interface. An interface is a physical peripheral device on which a node communicates (e.g., within a specific session). In the connectivity framework, interfaces can be listed in the enumerator as:

[0218]

[0219] Queues. This term is used to refer to queues of connection frame messages that the library creates and manages in RAM at runtime. Only one message queue exists in the connection frame stack, which contains either input (inbound) or output (outbound) data.

[0220] A session. A session, or communication session, is a time-limited, bidirectional link between two nodes on a communication channel. A session begins with a predefined exchange of messages designed to define a shared set of keys (or a "handshake phase") and continues with all subsequent message exchanges that use these keys to encrypt and authenticate the communication (or "chat phase"). A session can be closed at any time by either of the two nodes. To resume communication, a new session needs to be reopened with a completely new set of session keys. The primary reference to a session in the connection frame stack is the session ID. The session identifier consists of an 11-byte node ID of the corresponding party in the communication. Therefore, for each node in a session, one node will refer to the session using the identifier of the other node. The session ID may not be unique, as nodes can communicate with the same receiver through different peripherals. Therefore, to uniquely identify a session, the interface and channel should be specified.

[0221] End node. This term is used to define which of two possible roles a node can play in a network. An end node is a node that can open sessions and receive requests to open sessions, but it does not route messages to other nodes. Each received message is examined to determine which node it is addressed to: if the message is not addressed to that node, it is simply discarded.

[0222] Gateway node. This term is used to define which of two possible roles a node can play in a network. A gateway node is a node that can open sessions and receive requests to open sessions, and it actually routes messages to other nodes. The gateway node registers other nodes to its subnet. The gateway node accepts authenticated registration requests and responds with a new node ID on success, which the registered node should use to communicate within the subnet. This new registration ID will consist of the gateway node's serial number (SN) followed by a 16-bit integer (e.g., 2 bytes) assigned to the node. Each node wanting to register with the gateway needs to open a connection frame session with the gateway and, upon authentication, present its own registration request. Within the connection frame session between the gateway and the registered node, the gateway can distribute a (encrypted) routing table listing all nodes in the subnet and their IDs to enable connections to those nodes.

[0223] Routing table. A routing table is a list of specific information about a node. Each entry in the list consists of 32 bytes containing information about the node. The routing table is managed by the gateway node and distributed to all members of the subnet.

[0224] Cluster. A cluster is a sub-network defined by a gateway and its registered nodes.

[0225] A thumbprint is a connection framework certificate (e.g., 150 bytes long) that identifies a node. A thumbprint contains information about the device's serial number (SN), the device's public key, the device's signer's serial number (SN), the expiration date, and the signer's signature.

[0226] Credentials. Credentials are a set of thumbprints from its own certificate to the CA's thumbprint, which defines the device's complete identity and lists all intermediate CAs and signers that make up its complete chain of trust.

[0227] Security layer. The security layer consists of simpleMAP. TM The protocol is described. In one or more examples, elliptic curve-based public-key cryptography is used, which completes authentication and key exchange using only two messages per node. The first message exchanged contains the identities of the nodes involved in the session (introduction message), while the second message represents key negotiation (key exchange message). In one or more examples, the method may conform to: ECDSA-FIPS186-3 elliptic curve digital signature; ECDH-FIPS SP800-56A elliptic curve Diffie-Hellman; HKDF-FIPS SP800-56C key derivation; and AES128-FIPS197.

[0228] Networking principles. Connecting networks allows for the formation and management of different kinds of network topologies through their stack. The simplest is the P2P type, where each of the two peer devices has the same role in the network. All other topologies require one or more gateways that can register end nodes into the network and route messages between different channels / interfaces.

[0229] Peer-to-peer (P2P). In this type of network, a single connection allows two devices to exchange data with each other. A session is opened by one of the two, and the other joins the session. To begin a secure session with another node, a user only needs to know the original ID of the node they wish to connect to, and their own original ID will be presented in the introductory message.

[0230] Star / mesh networks. In these types of networks, nodes are grouped into clusters. Each cluster is defined by a gateway that registers its end nodes, accepts authenticated registration requests from these end nodes, and assigns a registration ID to each end node. Each node introduces itself within that ID in sessions toward external nodes (outside its own cluster) using the registration ID, which contains the gateway's SN for the cluster. This message is what the node needs to respond to and to let all intermediate devices know which path to follow. This is possible because once each end node registers with its gateway and each gateway registers with another gateway on the network, the end node and gateways all share the same routing table. What changes in each copy of the routing table for each node is the channel associated with the listed entries, which will contain different channels depending on which node has received the routing table. To point to a specific device, a node can route messages on the channel indicated on the routing table.

[0231] Figure 22 This is a quick overview of the system startup process 2200 for an embedded system utilizing the connectivity framework 2204, based on one or more examples. A typical application architecture for an embedded system using the connectivity framework 2204 as its communication stack with the application 2202 is described. Once the system is initialized at action 2210, the connectivity framework 2204 can also be initialized at action 2212. During this phase, at action 2214, the user should indicate to the connectivity framework library where to find the device identity credentials and set callback functions to receive data and status messages from the stack. At action 2216, further initialization can be performed on all cryptographic authentication functions that the library needs to execute externally, regardless of what resources are available on the given system. During this phase, the user should map each required function to an appropriate implementation.

[0232] Subsequently, at action 2218, the user code should initialize all peripheral devices, define its own API at action 2220, and define the API that will be used to open the communication channel at action 2222. During this phase, at actions 2224 and 2226, the channel's input and output buffers should be associated with the Connection Framework library, giving the library the ability to acquire data and prepare responses for transmission. Then, when the application actually starts at action 2228, either inside the main loop or in a task periodically run by the system, at action 2230, the user can insert periodic calls to the CF_SESSIONS_TASK API, which will manage the entire communication, handling all necessary operations at lower levels. When the application runs, the user code can open the channel and use the Connection Framework API to initiate a session with the node. Inside the callback function, various session states can be monitored and data, routing tables, acknowledgments, etc., can be received in plaintext.

[0233] Available library files. The embedded connectivity framework library may include the following files: CFlib <vv>The files are .a (vv = 2-bit version); cf.h; and cf_config.c. The ".a" file is a pre-compiled C library, which should be selected based on the linker framework core it will run on. It should be included as a library in the project. "cf.h" is a header file that is included in any C source file using the linker framework. "cf_config.c" is a C source file that is included in the project and modified in the first part (named "USER CONFIG") for user convenience to configure the library.

[0234] Library configuration. Once the library and files have been included in the project, you can configure the expected behavior of the library by modifying the first part of "cf_config.c" (named "USER CONFIG").

[0235] Memory Model. Options—Dynamic or Static. This option defines whether you want to use a static or dynamic memory model for the structures and variables of the linker library. Static memory will instruct the library to define global variables of the required size and use static memory. Conversely, dynamic memory will instruct the library to allocate memory as needed and release memory when finished.

[0236] Message size. Options—Full or Reduced. This defines the maximum message length (for pure payload) in bytes. Full: Maximum 1024 bytes per message; or Reduced: Maximum 432 bytes per message. Information about the maximum message size is delivered to the counterparty in the session by introducing the message.

[0237] Credential location. Options—flash or external device. Each of these settings is expected to be defined such that the user makes the credential bytes available at the referenced pointer. Flash: const uint8_tcredentials

[600] ; External device: uint8_t*ext_dev_inter_cred. In the case of flash, credentials are expected to be defined in the cf_config.c file. When the external device holds the credentials, the user is expected to retrieve those bytes from memory and make them available at the ext_dev_inter_cred pointer.

[0238] Session authentication. If CF_SESSION_VALIDATE is defined, the library will request permission from the user to complete a session handshake with the specific device. If this macro is defined, inside the callback, the user will receive the entire trust chain of the introductory message and can decide whether to allow the connection.

[0239] Maximum array value. Macros should be defined to set limits for various arrays in order to balance memory usage and performance.

[0240] The connection framework uses a 100-millisecond time base. A macro called CF_DEF_100MS_TICK should be defined, containing the system time base (the number of times a timer callback is fired or the task time base) required to count 100 milliseconds. This is bundled with the CF_tick_increment API and the uint32_tCF_TICKS_FROM_START variable. The CF_tick_increment API should be periodically called by the application to update the CF_TICKS_FROM_START variable, which holds the time base value since system startup and is used by the connection framework to measure elapsed time to calculate timeouts.

[0241] Message timeout. These macros define timeouts that the connection framework will use to account for messages still valid in the queue. `CF_DEF_MSG_INCOMPLETE_MAX_PENDING_TICK` defines the maximum time base for a message to remain in the queue in an incomplete state. `CF_DEF_MSG_COMPLETE_MAX_PENDING_TICK` defines the maximum time base for a complete message to remain in the queue without being processed.

[0242] Callbacks. Callbacks are the primary method the connectivity framework uses to notify user code (application) what has happened at the connectivity framework. If the macro CF_DEF_USER_CALLBACK_ACTIVE is defined, the connectivity framework expects the user to define and register cf_user_callback in their code. The possible callback types are as follows: User data arrives in the session and is delivered to the user in decrypted form; the connectivity framework receives data acknowledgment; a session is about to open and authentication is required; a security firmware update request has been received; a security firmware update block has been received; the session changes its state; the message queue is ready to receive new data; the connectivity framework receives a new routing table.

[0243] Secure Firmware Update. A macro named CF_DEF_INCLUDE_SFU should be defined to include secure firmware update code within the connectivity framework. With this macro defined, the connectivity framework expects the user to define a serial number (a nine-byte buffer) defined as CF_SECURE_FIRMWARE_VALID_SN, which contains a reference to a unique SN from which firmware updates are received.

[0244] Device type. One of the following two macros should be defined to explicitly set the device's role: CF_DEF_DEVICE_TYPE_ENDNODE (for the role of an end node) or CF_DEF_DEVICE_TYPE_GATEWAY (for the role of a gateway node). There are four possible device types:

[0245] #define DEVICE_TYPE_WAN

[0246] #define DEVICE_TYPE_GATEWAY

[0247] #define DEVICE_TYPE_ENDNODE

[0248] #define DEVICE_TYPE_GATEWAYW

[0249] Even if the embedded device can initially only be a gateway or end node, the general-purpose device can also serve as one of two other types: (1) WAN: which is a connection framework cloud; (2) GATEWAYW: which is a gateway with a connection to the WAN network (attached to the cloud). Depending on the presence of this connection, at runtime, the gateway device can change its type from GATEWAY to GATEWAYW, and vice versa. This information is used by the connection framework stack to route messages for IDs not included in the local routing table. This information is included in the introductory message.

[0250] Credentials. The following constant should be defined using data bytes containing a thumbprint of the trust chain overriding the device identity: const uint8_t credentials

[600] ={…}.

[0251] The Connection Framework API is divided into two groups to simplify the experience for programmers using the library for the first time. The first group, the Basic API, lists the APIs that users should implement in their first project. These APIs provide basic functionality and allow for the implementation of simple network or P2P connections. The second group of APIs is defined as the High-Level API, which is required to implement gateways with multiple interfaces and channels or to manage more complex networks in general.

[0252] The basic APIs include the settings API, session management API, and channel queue API.

[0253] The API settings include CF_LIBRARY_INIT, CF_Set_Introduction_Iface, CF_tick_increment, and CF_getorinsertnew_channel.

[0254] CF_LIBRARY_INIT initializes the library, setting up all structures and memory. It should be called once the system has been initialized and all peripherals are ready.

[0255] CF_Set_Introduction_Iface. Input parameter: ifa: An interface value from the APP_INTERFACES enum. Sets an internal global variable representing the next interface that will be used to deliver the introduction message.

[0256] CF_tick_increment. Incrementing time base. Should be called periodically and requires other global settings to count elapsed time in 100-millisecond increments.

[0257] `CF_getorinsertnew_channel`. Input parameters: `iface`: An interface value from the `APP_INTERFACES` enum; Options: A pointer to a 6-byte buffer used to store information on this channel; `tcpsocket`: An integer representing the socket in the TCP stack; Return value: The channel number assigned by the connection frame. Inserts a new channel or retrieves an existing channel carrying information as its interface, options, or TCP socket. If the channel already exists, it returns its number.

[0258] The session management API includes CF_SESSION_TASK, CF_start_session_to_node, and CF_close_session_to_node.

[0259] CF_SESSION_TASK. This is the API that manages all state machines, which create and maintain all sessions, process all messages in the queue, create appropriate responses to each connection frame event, and provide feedback to the user via connection frame callbacks. Applications should call this API periodically at a maximum frequency of 1kHz. For lower frequencies, users should consider the balance between desired performance levels and power / processing resource consumption.

[0260] `CF_start_session_to_node`. Input parameters: `id`: a pointer to an 11-byte buffer containing the destination ID; `iface`: an interface value from the `APP_INTERFACES` enum; `channel`: the channel on which the session begins; `options`: a pointer to a 6-byte buffer used to store information on this channel; and `tcpsocket`: an integer representing the socket in the TCP stack. This function begins a new session toward the specified ID on the specified interface and channel.

[0261] CF_close_session_to_node. Input parameters: id: a pointer to an 11-byte buffer with the destination ID; iface: an interface value from the APP_INTERFACES enum; channel: the channel on which the session begins; options: a pointer to a 6-byte buffer used to store information on this channel; and tcpsocket: an integer representing the socket in the TCP stack. This function closes an existing session toward the specified ID on the specified interface and channel.

[0262] The channel queue API includes CF_get_channel_of_available_outbound, CF_message_queue_insert_inbound_data, and CF_message_queue_get_outbound_data.

[0263] CF_get_channel_of_available_outbound. Input parameter: iface: An interface value from the APP_INTERFACES enum. Retrieves the channel number on which messages are ready to be sent on the specified interface and are in the queue. If no messages are ready to be sent on the specified interface, the function returns 0xFF.

[0264] CF_message_queue_insert_inbound_data. Input parameters: iface: An interface value from the APP_INTERFACES enum; channel: The channel on which inbound data is received; p_data: A pointer to the buffer on which data is to be inserted into the queue; and l_data: The size of the data. Return value: Returns 0 on success and -1 on error. This is the API that should be called when bytes are received on any channel. Specifying which interface and channel the message was received on will allow the connection framework to correctly set the message in the queue.

[0265] `CF_message_queue_get_outbound_data`. Input parameters: `iface`: An interface value from `APP_INTERFACESenum`; `channel`: The channel on which we want to retrieve outbound data; `p_data`: A pointer to the buffer we want to fill with available data; and `l_data`: The maximum size of the data to retrieve. Return value: The size of the available data copied in the `p_data` buffer. This API retrieves the maximum number of bytes available on the channel / interface to send. The return value indicates how many bytes have been copied in the `p_data` buffer.

[0266] The data API includes CF_user_code_data_message and CF_user_code_data_message_ack.

[0267] CF_user_code_data_message. Input parameters: idifacechannel: a pointer to a 13B buffer containing the ID, iface, and channel; p_data: a pointer to the buffer we want to send to; and l_data: the size of the data to be sent. Return value: Returns 0 on success and -1 on error. This function inserts a data message for the specified receiver into the queue. If a session with the intended receiver is not already open, it will start a new session and send the data when the session is ready.

[0268] CF_user_code_data_message_ack. Input parameters: idifacechannel: a pointer to a 13B buffer containing the ID, iface, and channel; p_data: a pointer to the buffer containing the data to be transmitted; l_data: the size of the data to be transmitted. Return value: Returns 0 on success, -1 on error. This function inserts a data message into the queue for the specified receiver, containing a request for an acknowledgment message to be returned upon receipt from the destination. If a session with the intended receiver is not already open, it will start a new session and transmit the data when the session is ready.

[0269] High-level APIs include CF_Set_Device_Type, CF_get_channel_tcp, CF_get_tcp_of_channel, CF_get_channel_options, CF_get_channel_cts, CF_set_channel_cts, CF_send_subscription_message_on_session, CF_send_subscription_message_for_gateways_in_RT, and CF_send_enrollment_to_gateway.

[0270] CF_Set_Device_Type. Input parameter: devicetype: An interface value from the APP_INTERFACES enum. Changes the device type. This is useful, for example, when a system connects to the connectivity framework cloud at some point and becomes a GATEWAY WAN device. This should be communicated to the rest of the network. Setting the device type allows the connectivity framework to include information about the routing table.

[0271] CF_get_channel_tcp. Input parameter: tcpsocket: The TCP socket associated with the channel. Return value: The channel. Retrieves the channel associated with the specified TCP socket.

[0272] CF_get_tcp_of_channel. Input parameter: Channel: The channel associated with the TCP socket. Return value: A reference to the TCP socket. Retrieves the TCP socket associated with the specified channel.

[0273] CF_get_channel_options. Input parameters: iface: an interface value from the APP_INTERFACES enum; channel: the channel for which we want to retrieve the options; options: a pointer to the buffer to be filled with the option data. Return value: the size of the available data copied in the p_data buffer. This function is used to retrieve a six (6) byte buffer called "options", which the user can store together with other channel information in the connection frame. The user is free to store any data here, such as information about the address or port of the physical channel.

[0274] CF_get_channel_cts. Input parameter: Channel: The channel from which to obtain the allowed transmission value. Return value: The allowed transmission value. This function returns data bytes indicating the allowed transmission status, which was previously set by CF_set_channel_cts.

[0275] CF_set_channel_cts. Input parameters: Channel: The channel whose allowed transmission value is to be set; Value: A value indicating the allowed transmission status to be set. This function sets the allowed transmission status for the specified channel.

[0276] CF_send_subscription_message_on_session. Input parameters: id: a pointer to an 11-byte buffer containing the destination ID; iface: an interface value from the APP_INTERFACES enum; channel: the channel on which the subscription message is sent; subscriptionid: a pointer to a 9-byte buffer containing the SN to subscribe to. Return value: Returns 0 on success and -1 on error. This function is only for GATEWAYW device types that need to subscribe their corresponding MQTT client in the cloud to an additional SN.

[0277] CF_send_subscription_message_for_gateways_in_RT. Input parameters: id: A pointer to an 11B buffer with the cloud server's ID; iface: An interface value from the APP_INTERFACES enum; channel: The channel for which we have opened a server session. Return value: Returns 0 on success and -1 on error. This function is only for the GATEWAYW device type, which needs to subscribe all gateways in its routing table to the cloud.

[0278] CF_send_enrollment_to_gateway. Input parameters: id: A pointer to an 11B buffer containing the gateway's ID; iface: An interface value from the APP_INTERFACES enum; channel: The channel for which we have opened a gateway session. Return value: Returns 0 on success and -1 on error. This function can be called by any device type that wants to register with the gateway. Upon successfully accepting the request to send, the gateway will respond with its routing table.

[0279] As previously described, the connectivity framework provides a messaging system that allows for address distribution, network formation, routing, clustering, mesh networking, and cloud connectivity.

[0280] Figure 23A This is a network diagram depicting an example mesh network 2300A formed according to one or more examples of available gateway nodes 2303 and end nodes 2305. Gateway nodes 2303 include gateway node 1.0, gateway node 2.0, gateway node 3.0, gateway node 4.0, and gateway node 5.0. In one or more examples, some gateway nodes 2303 (e.g., gateway node 1.0) may be connected to one or more remote gateway nodes (e.g., gateway node 5.0) via a cloud service provider 2302.

[0281] Figure 23B , Figure 23C and Figure 23D It describes based on one or more examples. Figure 23A The corresponding network diagram for the establishment of the 2300A mesh network. Figure 23A The establishment of the 2300A mesh network from Figures 23B to 23D Depicted sequentially. In Figure 23B In some parts of the 2300B network, network formation begins with gateway nodes 1.0, 2.0, 3.0, and 4.0, and then with gateway node 5.0, which is far from the other nodes. Figure 23C In certain parts of the 2300C network, each gateway node (1.0, 2.0, 3.0, 4.0, and 5.0) is described as including its ID and its interface. Figure 23C In the diagram, gateway node 1.0 includes interfaces IF0, IF1, IF2, and IF3; gateway node 2.0 includes interfaces IF0, IF1, and IF2; gateway node 3.0 includes interfaces IF0 and IF1; gateway node 4.0 includes interface IF0; and gateway node 5.0 includes interface IF0.

[0282] exist Figure 23D In the 2300D mesh network, a mesh network is basically formed. Figure 23E Table 2300E is provided, indicating the actions associated with the formation of the mesh network 2300D. (See reference...) Figure 23D The GWY channel is established between gateway nodes. For example, the GWY channel is established between gateway node 1.0 and gateway node 2.0; between gateway node 1.0 and gateway node 3.0; between gateway node 1.0 and gateway node 4.0; and between gateway node 2.0 and gateway node 3.0. The WAN channel is established between gateway node 2.0 and cloud service provider 2302; and between gateway node 5.0 and cloud service provider 2302.

[0283] Also in Figure 23D In the above, gateway node 1.0 includes routing table 2356, which has entries including the following: 1.0 associated with ME; 2.0 associated with IF0 W (i.e., WAN connection); 3.0 associated with IF1; 3.0 associated with IF0; and 4.0 associated with IF2. Gateway node 2.0 includes routing table 2352, which has entries including the following: 2.0 associated with ME; 1.0 associated with IF0; 1.0 associated with IF1; 4.0 associated with IF0; and 3.0 associated with IF1. Gateway node 3.0 includes routing table 2354, which has entries including the following: 3.0 associated with ME; 1.0 associated with IF0; 1.0 associated with IF1; 4.0 associated with IF1; and 2.0 associated with IF0 W (i.e., WAN connection). Gateway node 4.0 includes routing table 2358, which has entries including the following: 4.0 associated with ME; 1.0 associated with IF0; 2.0 associated with IF0 W (i.e., WAN connection); 3.0 associated with IF0; and 3.0 associated with IF0. Gateway 5.0 includes routing table 2350, which has entries including the following: 5.0 associated with ME; and 5.1 associated with IF1.

[0284] In one or more examples, cloud service provider 2302 is a cloud or cloud service that enables the connectivity framework. Here, network messaging may utilize a publish-subscribe protocol associated with cloud service provider 2302, such as Message Queuing Telemetry Transport (MQTT). Here, the node identifier or address of the message may be presented as the topic (or topic name) to be published. In one or more examples, the published message is received by subscribers (e.g., gateway nodes) whose associated identifiers or addresses are subscribed to by the end nodes of their connections. In one or more examples, the following information may be utilized... Figure 24 , Figure 25 , Figure 26 , Figure 27 , Figures 29A to 29B , Figure 30 , Figure 31 , Figure 32 and Figure 33 The architecture and technologies shown and described.

[0285] exist Figure 23D In this context, gateway node 5.0 enables subscription to "5.0" from cloud service provider 2302 to receive (e.g., remotely transmitted) messages via cloud service provider 2302. Additionally, gateway node 2.0 enables subscription to "2.0", "1.0", "4.0", and "3.0" from cloud service provider 2302 to receive (e.g., remotely transmitted) messages via cloud service provider 2302.

[0286] Figure 23F This is a network diagram based on one or more examples of a mesh network 2300F, depicting two end nodes 1.1 and 5.1 joining the mesh network at two location areas 2364 and 2360. Here, LAN channels are established between gateway node 1.0 and end node 1.1; and between gateway node 5.0 and end node 5.1. End node 1.2 includes routing table 2366, which has entries including: 1.1 associated with ME; 1.0 associated with IF0; 2.0 associated with IF0 W (i.e., WAN connection); 3.0 associated with IF1; 3.0 associated with IF0; and 4.0 associated with IF2. End node 5.1 includes routing table 2362, which has entries including: 5.1 associated with ME; and 5.0 associated with IF0 W (i.e., WAN connection).

[0287] The message flow during the example joining of the mesh network 2300F includes the following: End node 5.1 transmits message M containing a destination ID corresponding to end node 1.1. Message M arrives at gateway node 5.0 at IF1 via end node 5.1 at IF0. Gateway node 5.0 has a WAN channel, so it will route message M via IF0. Gateway node 5.0 will use the WAN channel of the Message Queuing Telemetry Transport (MQTT) client of cloud service provider 2302 to publish message M on topic 1.0. Gateway node 2.0, which has a WAN connection, will receive the message via IF2. Gateway node 2.0 has two (2) routes for messages directed to gateway node 1.0; the gateway node will select the first route (both routes are valid if connection "sanity" is properly managed; however, the first route will usually be selected). Gateway node 2.0 routes message M via IF0. Gateway node 1.0 routes message M via IF3. Message M arrives at end node 1.1. When End Node 1.1 sends a message back to End Node 5.1, it knows that for gateways not listed in the routing table, those messages need to be delivered on the available WAN. In this case, its gateway node 2.0 is associated with IF0 W (WAN channel). Therefore, it will send the message via the interface that reaches gateway node 1.0 at IF3. In the same way, the message will travel its journey to the WAN, then be published on topic 5.0, then reach gateway node 5.0 at IF0, and then reach end node 5.1.

[0288] Figure 24 This is an illustrative representation of a cloud networking architecture 2400 based on one or more examples, which includes a cloud 2402 (or cloud computing service) with a connectivity-enabled framework suitable for providing connectivity to multiple computing devices 2404. The computing devices 2404 may be or include information about... Figure 3 Some of the devices described are from the same device. When using a connectivity framework, a corresponding computing device in computing device 2404 (e.g., computing device 2410) can use a shared messaging protocol to communicate messages to other computing devices, which may be a lightweight secure networking protocol 2412. In one or more examples, this messaging between computing devices 2404 is facilitated via a connectivity-enabled cloud 2402. In one or more examples, one or more gateway nodes can connect computing devices 2404 to the connectivity-enabled cloud 2402 for connectivity.

[0289] Therefore, connection framework messages can be communicated between computing devices via one or more networks using the cloud. In one or more examples, standard messaging protocols (such as MQTT) can be used to communicate connection framework messages between computing devices via the cloud, through one or more networks. In one or more examples, connection framework messages are communicated using a compact message format that includes headers that are relatively easy for applications (e.g., applications running in the cloud, but not limited to) to parse. In one or more examples, an application in the cloud can extract the destination identifier of the message and use it as the topic name to publish the message at a messaging protocol broker (e.g., a standard MQTT broker).

[0290] Therefore, in one or more examples, in MQTT, connection-frame messaging utilizes network addresses as topics. The cloud front-end operation that enables connection-frame extracts the destination ID and uses it as the topic, effectively transforming the MQTT protocol into a transport protocol rather than an application protocol. Using this approach, connection-frame remains agnostic and highly portable. In one or more examples, another different internet protocol or mechanism could be used to serve the same purpose, providing yet another way to transport connection-frame packets.

[0291] Therefore, in one or more examples, connection framework messaging utilizes standard messaging protocols (e.g., MQTT, but not limited to) at the transport layer, rather than using those standard messaging protocols in their usual way at the application layer. While MQTT is typically used for dispatching application data, in connection frameworks, MQTT can be used to dispatch stack packets at the transport layer rather than the application layer. Here, MQTT can be considered as operating as a "stack packet dispatcher" for connection framework messaging.

[0292] In one or more examples, the network architecture and operations allow the same messages to be routed over the cloud to virtually any remote node. In one or more examples, the network architecture and operations allow each node to avoid implementing the messaging protocol (e.g., MQTT, but not limited to) itself on the board, thereby reducing the memory required by the application. In one or more examples, the network architecture and operations provide customers with the ability to run cloud applications from any service provider, or even on a private cloud or on-premises server.

[0293] Figure 25 It is based on one or more examples Figure 24 This is an example of the cloud architecture 2500 with the cloud 2402 enabled by the connectivity framework. Figure 25 In one or more examples, a cloud 2402 with the connectivity framework enabled is shown as including a cloud front-end server 2420 and a proxy server 2424. The front-end server 2420 of the cloud 2402 with the connectivity framework enabled may include a client for standard messaging protocols (such as MQTT), referred to as MQTT client 2422. MQTT client 2422 may interface with the proxy server 2424 of the cloud 2402 with the connectivity framework enabled. In one or more examples, the front-end server 2420 may be referred to as a connectivity framework cloud front-end.

[0294] In one or more examples, the gateway node is able to open a WAN channel toward a cloud 2402 with a connectivity framework enabled, on behalf of an end node (such as computing device 2410). In one or more examples, the WAN channel may be a TCP socket connected to a front-end server 2420 of the cloud 2402 with a connectivity framework enabled. In one or more examples, the purpose of the WAN channel is to route all messages to IDs belonging to the cluster but not appearing in the routing table of the gateway node. In one or more examples, the front-end server 2420 is an application in the cloud (e.g., a relatively small application) that accepts authenticated connections and opens a Message Passing Protocol Broker client subscription (e.g., an MQTT client subscription) to a specific topic or topic name. The topic is the ID of the gateway node reachable by the gateway that opened the channel. The front-end server 2420 is able to route all messages published on subscribed topics to the gateway node and vice versa, to publish messages from the gateway on a topic equal to the destination ID.

[0295] In one or more examples, when a node (e.g., a gateway node) has a TCP / IP connection to establish a connection with a framework cloud instance (see example...), Figure 33 Upon connection, the node will begin establishing a new secure session with the cloud. The frontend in the cloud is adapted to process and respond to connection frame messages, so it will receive and respond until a secure channel is established. Once this is achieved, the frontend will automatically create an MQTT client and subscribe to a topic from the broker consisting of the node ID (e.g., the first 9 bytes of its ID). The frontend is open to each node and responds to any queries as a TCP socket server, but it will only keep the socket connection open if a secure session is successfully established; otherwise, the frontend will discard the connection. For example, imagine that within three (3) seconds after the socket connection has been opened, the node is able to be authenticated and a secure session is established. At this point, the frontend keeps the channel (socket) open and creates an MQTT client to subscribe to the node ID. Thereafter, the frontend expects to receive valid connection frame messages (e.g., specific header and payload formats) through this channel. The frontend will deliver virtually any message. Messages encapsulated in a higher protocol (e.g., MQTT publish messages) are published and eventually reach the subscriber, where they are decapsulated and returned to their connection frame message format (e.g., unmodified during their journey). Only connection frame messages with a subscriber type are intercepted by the frontend, which, once authenticated, processes the connection frame message, creating another MQTT client that subscribes to the specific topic contained in the message. Typically, these messages originate from another gateway on the same network attached to the cloud, which needs to be designated as a reachable destination on the exact same socket in the cloud.

[0296] Figure 26 It is an illustrative representation of a cloud architecture 2600 based on one or more examples for connecting two clusters, each associated with a different gateway node, to a cloud 2602 (or cloud computing service) with a connectivity framework enabled. Figure 26 The two gateway nodes depicted in the cloud architecture 2600 include gateway node 2604 and gateway node 2606. Figure 27 The document provides information associated with gateway node 2604. Figure 27 Information includes information related to previous information Figure 19C The routing table information shown and described is the same. In short, the cluster ID associated with gateway node 2604 is "A1B1C1", and the gateway ID is "A1B1C10000". Figure 28 The information provided is related to gateway node 2606. In short, the cluster ID associated with gateway node 2606 is "D1E1F1", and the gateway ID is "D1E1F10000".

[0297] Return to reference Figure 26 According to one or more examples, the Cloud 2602 with the connectivity framework enabled is used to provide communication between devices via a cloud messaging protocol broker. Figure 26 The cloud 2602 with its enabled connectivity framework includes a front-end server 2612 to communicate with a broker server 2610 (or an MQTT broker) for processing. The front-end server 2612 may include an MQTT client (e.g., ...). Figure 25 The MQTT client 2422 can be used with the gateway node 2604. The cloud 2602, which enables the connectivity framework, also includes a front-end server 2614 to communicate with the broker server 2610 for processing. The front-end server 2614 may also include an MQTT client (e.g., ...). Figure 25 The MQTT client 2622 can be used with gateway node 2606. In one or more examples, front-end server 2614 can communicate with the same proxy server as front-end server 2612 (i.e., proxy server 2610) or a different proxy server.

[0298] exist Figure 26 In operation 2632, the gateway node 2604 associated with cluster ID "A1B1C1" may send a registration message to the front-end server 2612. For example, the registration message may indicate registration to "D1E1F1" associated with gateway node 2606. The front-end server 2612 may perform operations to register gateway node 2604. In operation 2624, in response, the front-end server 2612 may prepare a subscription message and send it to the proxy server 2610. The subscription message indicates subscription to a topic matching the cluster ID "A1B1C1" or "A1B1C10000" associated with the same gateway node 2604. In this way, gateway node 2604 will receive messages published to topics matching the cluster ID, and will forward these messages to its connected end nodes. In one or more examples, any suitable message type may be used to trigger the preparation of the subscription message and the transmission of the subscription message to the proxy server 2610.

[0299] In operation 2622, the gateway node 2606 associated with cluster ID "D1E1F1" may send a registration message to the front-end server 2614. For example, the registration message may indicate registration to "A1B1C1" associated with gateway node 2604. The front-end server 2614 may perform operations to register gateway node 2606. In operation 2624, in response, the front-end server 2614 may prepare a subscription message and send it to the proxy server 2610. The subscription message indicates subscription to a topic matching either cluster ID "D1E1F1" or "D1E1F10000" associated with gateway node 2606. In this way, gateway node 2606 will receive messages published to topics matching the cluster ID, and will forward these messages to its connected end nodes. In one or more examples, any suitable message type can be used to trigger the preparation of the subscription message and the transmission of the subscription message to the proxy server 2610.

[0300] Subsequently, a message can be transmitted from one of the end nodes connected to gateway node 2604, the message intended for a destination device connected to gateway node 2606. Front-end server 2612 can receive the message, and in operation 2630, can prepare to publish the message and transmit it to proxy server 2610. The publish message indicates publication to a topic matching the cluster ID "D1E1F1" or "D1E1F10000" associated with gateway node 2606. In response, proxy server 2610 can forward the message to gateway node 2606 (e.g., via front-end server 2614) for the destination device to receive.

[0301] Figure 29A This is method 2900A for processing messages on a cloud-based connection to a computing device, according to one or more examples. In one or more examples, method 2900A may be executed at a front-end server of a cloud computing service, wherein the cloud computing service includes a server adapted to a publish-subscribe messaging protocol.

[0302] exist Figure 29A In method 2900A, at action 2902, a message is received. The received message includes a header and a payload. At action 2904, a published message is prepared based at least in part on the received message. The published message includes one or more headers and a payload. The one or more headers of the published message include a subject, and the subject includes at least a portion of a destination identifier from the header of the received message. The payload of the published message includes the received message. In one or more examples, at action 2904, the published message is prepared according to the MQTT message format.

[0303] At action 2906, a publish message including the received message is transmitted to the server to convey the received message to the computing device identified by at least a portion of the destination identifier. In one or more examples, the method may be performed at a front-end server of a cloud computing service, wherein the cloud computing service includes a server adapted to a publish-subscribe messaging protocol. Here, in response to a subscription to a topic including at least a portion of the destination identifier, the received message may be conveyed to the computing device identified by at least a portion of the destination identifier.

[0304] In one or more examples, preparing to publish a message in action 2902 includes inserting a copy of at least a portion of the destination identifier as the subject into the one or more headers of the published message. In one or more examples, preparing to publish a message in action 2902 includes inserting a publication type indicator as the grouping type into the one or more headers.

[0305] In one or more examples, the subject includes a destination identifier, and the computing device includes an end node identified by the destination identifier. In one or more other examples, the subject includes a portion of a destination identifier, the computing device includes a gateway node identified by that portion of the destination identifier, and the end node connected to the gateway node is identified by the destination identifier.

[0306] Figure 29B This is method 2900B for processing messages on cloud-based connections of computing devices, based on one or more examples. In one or more examples, method 2900B may be executed on a server (e.g., a proxy server) of a cloud computing service, wherein the server is adapted to a publish-subscribe messaging protocol. Figure 29B Method 2900B can continue to process from Figure 29A Method 2900A (e.g., received from the front-end server of a cloud computing service) publishes messages.

[0307] exist Figure 29A In method 2900A, at action 2912, a publishing message is received from a front-end server. The publishing message includes the received message in its payload. At action 2914, a subscription list associated with the topic is checked. At action 2916, in response to at least a portion of the destination identifier being identified in the subscription list, the publishing message is forwarded to deliver the received message to the computing device identified by at least a portion of the destination identifier. In one or more examples, at another front-end server of the cloud computing service, the forwarded publishing message including the received message is received, such that the received message can be forwarded to the computing device identified by at least a portion of the destination identifier.

[0308] Figure 30 This is a message flow diagram of message flow 3000 for processing cloud-based connections to computing devices, based on one or more examples. Figure 30 In one or more examples, the front-end server 2612 includes a TCP component 3010 and an MQTT client 3012. In addition, the cloud 2602 with the connectivity framework enabled includes a database 3016, which includes a subscription list 3014 associated with subscriptions across multiple topics. Figure 30 In one or more alternative examples, the cloud 2602 with the connectivity framework enabled can provide or supply different types of services other than cloud computing services.

[0309] exist Figure 30 At action 3020, end node 3002 transmits a message to gateway node 2604 to deliver the message to the destination device identified by the destination identifier. In one or more examples, the message is formatted using a message format according to the Uniform Messaging Protocol. In one or more specific examples, based on... Figure 7A , Figure 7B , Figure 7C , Figure 7D and / or Figure 7E The described message format, a message with a unified messaging protocol, may include a header and a payload. First, refer to... Figure 31 The message format 3100 of this message 3102, including header 3104 and payload 3106, is shown.

[0310] Return to reference Figure 30 At action 3022, gateway node 2604 forwards the message to cloud 2602 with the connectivity framework enabled. The TCP component 3010 of frontend server 2612 receives and processes the message. At action 3024, the TCP component 3010 of frontend server 2612 forwards the message to MQTT client 3012 of frontend server 2612. MQTT client 3012 prepares a published message based at least in part on the received message. The published message includes one or more headers and a payload. The one or more headers of the published message include a subject, wherein the subject includes at least a portion of a destination identifier from the headers of the received message. The payload of the published message includes the received message. In one or more examples, the published message is prepared according to the MQTT message format.

[0311] First refer to Figure 32 This describes the message format 3200 of such a release message 3202, including a header 3204 and a payload 3206. The release message 3202 includes a release type indicator 3210 ("release flag") in the header 3204, which serves as the packet type. The payload 3206 of the release message 3202 also includes a message 3102 received for transmission to a destination device (see also...). Figure 31 The published message 3202 also includes a copy 3212 of the destination identifier from the header 3204 as a subject. This may be, for example, when the destination device (e.g., an end node) receiving the message (i.e., message 3102) is identified by the destination identifier. In one or more other examples, the published message 3202 includes a copy 3212 of (only) a portion of the destination identifier from the header 3204. This may be, for example, when a receiving gateway node is identified by that portion of the destination identifier, and the destination device (e.g., an end node) receiving the message (i.e., message 3102) is connected to that receiving gateway node and is identified by that (complete) destination identifier.

[0312] Return to reference Figure 30 At action 3026, the MQTT client 3012 will publish a message (e.g., Figure 32 The published message (3202) is forwarded to the broker server 2610 of the cloud 2602 with the connectivity framework enabled. The broker server 2610 receives the published message from the MQTT client 3012. The published message includes the received message in its payload. At action 3028, the subscription list 3014 associated with the topic is checked. At action 3030, in response to the at least part of the destination identifier being identified in the subscription list, the published message is forwarded to deliver the received message to the computing device identified by the at least part of the destination identifier. In one or more examples, at another front-end server of the cloud 2602 with the connectivity framework enabled, the forwarded published message including the received message is received and processed such that the received message can be forwarded to the computing device identified by the at least part of the destination identifier.

[0313] Figure 33 This is a block diagram of a cloud software architecture 3300 that enables a connectivity framework for the cloud, based on one or more examples. Figure 33 In the diagram, cloud software architecture 3300 is shown as including a load balancer 3304, multiple instances 3306 of a connection-enabled proxy service, and a database 3308. In one or more examples, the load balancer 3304 is used to more evenly balance and distribute processing associated with incoming messages. In one or more examples, appropriate instances of the multiple instances 3306 of the connection-enabled proxy service can be instantiated on demand and / or deinstantiated when not in use or underutilized.

[0314] In one or more examples, multiple instances 3306 of the proxy service with the connection framework enabled include proxy service 3310 ("Instance 1"), proxy service 3320 ("Instance 2"), and so on, up to proxy service 3330 ("Instance N"). Figure 33 In this context, the corresponding proxy service in the connection-enabled proxy service includes a front-end server and a proxy server (MQTT broker), where the front-end server includes a TCP component and an MQTT client. For example, connection-enabled proxy service 3310 includes a load balancer 3304 and an MQTT broker 3314, where the front-end server 3312 includes a TCP component 3316 and an MQTT client 3318; and connection-enabled proxy service 3320 includes a front-end server 3322 and an MQTT broker 3324, where the front-end server 3322 includes a TCP component 3326 and an MQTT client 3328. In one or more examples, the use of a front-end server (e.g., a TCP component plus an MQTT client) in the connection-enabled proxy service is an additional feature to enable the cloud to enable the connection framework.

[0315] As previously described, a gateway node is capable of opening a channel (e.g., a WAN channel) to the cloud on behalf of an end node. In one or more examples, the channel may be a TCP socket connected to a front-end server (e.g., front-end server 3312 including a TCP component) in the cloud. Each broker service with a connection-enabled framework includes a front-end server, which may be associated with one or more different gateway nodes. In one or more examples, the purpose of the channel is to route all messages to IDs belonging to the cluster but not appearing in the routing table of the gateway node. In one or more examples, front-end server 2420 is an application in the cloud (e.g., a relatively small application) that accepts (e.g., authenticates) connections and opens a Message Passing Protocol Broker Client Subscription (e.g., an MQTT Client Subscription) to a specific topic or topic name. Again, the topic is the ID of a gateway node reachable by the gateway that opened the channel. The front-end server is capable of routing all messages published on subscribed topics to the gateway node and vice versa, to publish messages from the gateway on a topic equal to the destination ID.

[0316] Many novel and practical features and the advantages they bring have been described, and these features and advantages will be realized when used in a specific design configuration, which will be selected according to specific operating conditions (as a non-limiting example).

[0317] In one or more examples, the connectivity frame can operate with a variety of different peripheral device interfaces, including UART, I2C, SPI, CAN, USB, Ethernet, T1S, Wi-Fi, Bluetooth, IEEE 802.15.4, etc.

[0318] In one or more examples, the connectivity framework provides a "stack on top of all other stacks" (e.g., at the application layer) to achieve high portability and minimize changes to existing architectures. Furthermore, the connectivity framework utilizes message queues (or pools), a mechanism that uses memory on demand to simultaneously populate queues shared by all peripherals and technologies. Going further, the connectivity framework uniquely provides session data structures and message structures, as well as short command sets.

[0319] In one or more examples, the size of the connectivity framework can be relatively small (e.g., 30kB, but not limited to this). In one or more examples, the connectivity framework is a low-cost and low-power connectivity framework (e.g., for low-end, low-throughput embedded peripherals). Smaller memory and resource requirements reduce the overall cost of the hardware. In one or more examples, development costs are also reduced by using a single stack for all peripherals (which simplifies code and testing). In one or more examples, cloud costs can be reduced and kept manageable due to the ease of system migration.

[0320] In one or more examples, the connectivity framework can leverage processing in the application layer without requiring modifications to low-level drivers, making the connectivity framework highly portable.

[0321] In one or more examples, the connection frame can be resized to fit a small microcontroller unit (MCU), but it can also be developed in C, Java, and Javascript, and porting has been done on PCs, Linux servers, and Android.

[0322] In one or more examples, the connectivity framework can be integrated with its own cryptographic library (e.g., an interface for secure elements or cryptographic chips (e.g., ECC608) and microcontroller unit hardware accelerators).

[0323] In one or more examples, the connectivity framework can be applied to the following areas: Internet of Things (IoT), industrial, home and building automation, medical, aerospace and defense, automotive and computing.

[0324] In one or more examples, the connectivity framework can be utilized in any connected system (from P2P, star, or mesh network topologies, but not limited to) to simplify communication over different connectivity technologies.

[0325] In one or more examples, end-to-end encryption allows a client to have (full) ownership of his / her certificate chain, permissions, encryption algorithms, and keys used for all connections, including those over the cloud. In one or more examples, this approach essentially guarantees complete privacy of data on the network. In one or more examples, the simpleMAP-based security protocol allows the creation of connection sessions protected according to NIST standards with minimal memory and resource usage.

[0326] In one or more examples, the connectivity framework reduces or eliminates the need for lock-in to a specific service provider. The protocol can be easily interfaced with standard MQTT brokers via (e.g., small) front-end applications in the cloud. Therefore, there is no need for a specific SDK for cloud connectivity, and this allows for easy migration from one cloud service provider to another, or even potentially to a private, on-premises server.

[0327] In one or more examples of Connectivity Framework Messaging, MQTT can be used as a transport layer protocol (compared to application layer protocols). Furthermore, Connectivity Framework Messaging can leverage the front end of the Connectivity Framework cloud as a scalable application in the cloud space, which alleviates the heavy lifting of microcontroller units and reduces the large space required for managing Internet protocols (e.g., using MQTT).

[0328] In one or more examples, connection frame messaging may include addressing and routing capabilities based on MAC address extensions. The connection frame ID can be compared to a TCP / IP ID as if a MAC address with other numeric extensions (e.g., in the format "XX:XX:XX:XX:XX:XX") were used as the counterpart to an IP address. This addressing facilitates the use of a small number of established commands and / or services (e.g., registration commands, routing table broadcasts, etc.) to simplify all services used for routing / DHCP / meshing / pinging, etc.

[0329] Figure 34 This is a block diagram of circuitry 3400 that can be used in some examples to implement the various functions, operations, actions, processes, and / or methods disclosed herein. In one or more examples, circuitry 3400 may be included (partially or entirely) in the computing device described herein. Circuitry 3400 includes one or more processors 3402 (sometimes referred to herein as "processor 3402") operatively coupled to one or more data storage devices (sometimes referred to herein as "storage device 3404"). Storage device 3404 includes machine-executable code 3408 stored thereon, and processor 3402 includes logic circuitry 3406. Machine-executable code 3408 includes information describing functional elements that can be implemented (e.g., executed) by logic circuitry 3406. Logic circuitry 3406 is adapted to implement (e.g., execute) the functional elements described by machine-executable code 3408. When executing the functional elements described by machine-executable code 3408, circuitry 3400 should be considered as dedicated hardware for executing the functional elements disclosed herein. In some examples, processor 3402 may execute the functional elements described by machine-executable code 3408 sequentially, concurrently (e.g., on one or more different hardware platforms), or in one or more parallel process flows.

[0330] When implemented by the logic circuitry 3406 of the processor 3402, the machine-executable code 3408 adapts the processor 3402 to perform the operations of the examples disclosed herein. For example, the machine-executable code 3408 may adjust the processor 3402 to perform at least a portion or all of the methods or processes described herein.

[0331] Processor 3402 may include a general-purpose processor, special-purpose processor, central processing unit (CPU), microcontroller, programmable logic controller (PLC), digital signal processor (DSP), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic device, discrete hardware component, other programmable device, or any combination thereof, designed to perform the functions disclosed herein. A general-purpose computer including a processor is considered a special-purpose computer when it executes functional elements corresponding to machine-executable code 3408 (e.g., software code, firmware code, hardware description) associated with the examples of this disclosure. It should be noted that the general-purpose processor (also referred to herein as a host processor or simply host) may be a microprocessor, but in alternative embodiments, processor 3402 may include any conventional processor, controller, microcontroller, or state machine. Processor 3402 may also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors combined with a DSP core, or any other such configuration.

[0332] In some examples, storage device 3404 includes volatile data storage devices (e.g., random access memory (RAM)), non-volatile data storage devices (e.g., flash memory, hard disk drive, solid-state drive, erasable programmable read-only memory (EPROM), etc.). In some examples, processor 3402 and storage device 3404 may be implemented as a single device (e.g., semiconductor device product, system-on-a-chip (SOC), etc.). In some examples, processor 3402 and storage device 3404 may be implemented as separate devices.

[0333] In some examples, the machine-executable code 3408 may include computer-readable instructions (e.g., software code, firmware code). As a non-limiting example, the computer-readable instructions may be stored in storage device 3404, directly accessed by processor 3402, and executed by processor 3402 using at least logic circuitry 3406. Also as a non-limiting example, the computer-readable instructions may be stored on storage device 3404, passed to a memory device (not shown) for execution, and executed by processor 3402 using at least logic circuitry 3406. Therefore, in some examples, the logic circuitry 3406 includes logic circuitry 3406 that can be configured electrically.

[0334] In some examples, machine-executable code 3408 may describe hardware (e.g., circuitry) to be implemented in logic circuitry 3406 to perform functional elements. This hardware may be described at any level of abstraction, from low-level transistor layout to high-level description languages. At high-level abstractions, hardware description languages ​​(HDLs), such as the IEEE standard hardware description language (HDL), may be used. As a non-limiting example, Verilog may be used. TM SYSTEMVERILOG TM Or Very Large Scale Integration (VLSI) Hardware Description Language (VHDL) TM ).

[0335] HDL descriptions can be converted into descriptions at any of a variety of other levels of abstraction as needed. As a non-limiting example, a high-level description can be converted into a logic-level description such as Register Pass Language (RTL), Gate-level (GL) description, Placement-level description, or Mask-level description. As a non-limiting example, micro-operations performed by the hardware logic circuitry of logic circuitry 3406 (e.g., gates, flip-flops, registers, but not limited thereto) can be described in RTL, then converted into a GL description by a synthesis tool, and the GL description can be converted into a placement-level description by a placement and routing tool, which corresponds to the physical layout of an integrated circuit, discrete gate or transistor logic element, discrete hardware component, or a combination thereof for a programmable logic device. Therefore, in some examples, machine-executable code 3408 may include HDL, RTL, GL descriptions, Mask-level descriptions, other hardware descriptions, or any combination thereof.

[0336] In an example where machine-executable code 3408 includes a hardware description (at any level of abstraction), a system (not shown, but including storage device 3404) may implement the hardware description described by machine-executable code 3408. As a non-limiting example, processor 3402 may include a programmable logic device (e.g., an FPGA or PLC), and logic circuitry 3406 may be electrically controlled to implement circuitry corresponding to the hardware description as logic circuitry 3406. Again, as a non-limiting example, logic circuitry 3406 may include hardwired logic manufactured by a manufacturing system (not shown, but including storage device 3404) according to the hardware description of machine-executable code 3408.

[0337] Regardless of whether the machine-executable code 3408 includes computer-readable instructions or a hardware description, the logic circuit 3406 is adapted to execute the functional elements described by the machine-executable code 3408 when implementing the functional elements of the machine-executable code 3408. It should be noted that although the hardware description may not directly describe the functional elements, it indirectly describes the functional elements that the hardware elements described by the hardware description can execute.

[0338] As used in this disclosure, the terms "module" or "component" can refer to a specific hardware implementation for performing the actions of a module or component and / or a software object or software routine that can be stored on and / or executed by general-purpose hardware of a computing system (e.g., a computer-readable medium, processing device, etc.). In some examples, the different components, modules, engines, and services described in this disclosure may be implemented as objects or processes (e.g., as separate threads) that execute on a computing system. While some of the systems and methods described in this disclosure are generally described as being implemented in software (stored on and / or executed by general-purpose hardware), specific hardware implementations or combinations of software and specific hardware implementations are also possible and contemplated.

[0339] As used in this disclosure, the term "combination" referring to multiple elements can include any combination of all elements or any combination of various different sub-combinations of certain elements. For example, the phrase "A, B, C, D or combinations thereof" can refer to any one of A, B, C, or D; a combination of each of A, B, C, and D; and any sub-combination of A, B, C, or D, such as A, B, and C; A, B, and D; A, C, and D; B, C, and D; A and B; A and C; A and D; B and C; B and D; or C and D.

[0340] Terms used in this disclosure, and especially in the appended claims (e.g., the body of the appended claims), are generally intended to be "open" terms (e.g., the term "comprising" should be interpreted as "including but not limited to", the term "having" should be interpreted as "at least having", the term "comprising" should be interpreted as "including but not limited to", etc.).

[0341] Furthermore, if a specific number of introduced claim statements are anticipated, such an intent will be explicitly stated in the claims, and without such statements, such an intent does not exist. For example, as an aid to understanding, the appended claims may contain the use of the introductory phrases "at least one" and "one or more" to introduce claim statements. However, the use of such phrases should not be construed as implying that a claim statement introduced by the indefinite article "a" or "an" limits any particular claim containing such an introduced claim statement to an example containing only one such statement, even when the same claim includes the introductory phrase "one or more" or "at least one" and indefinite articles such as "a" or "an" (e.g., "a" and / or "an" can be interpreted as referring to "at least one" or "one or more"); the same applies to the use of definite articles to introduce claim statements.

[0342] In addition, even when a specific number of the introduced claims are explicitly stated, those skilled in the art will recognize that such statements should be interpreted as meaning at least the number stated (e.g., the unmodified statement "two statements" means at least two statements, or two or more statements, in the absence of other modifying elements). Furthermore, in those instances where conventional phrases such as "at least one of A, B, and C" or "one or more of A, B, and C" are used, such constructions are generally intended to include A alone, B alone, C alone, A and B together, A and C together, B and C together, or A, B, and C together, etc.

[0343] Any separate word or phrase presenting two or more alternative terms in the specification, claims, or drawings should be understood to include the possibility of including one term, any one term, or both terms. For example, the phrase "A or B" should be understood to include the possibility of including "A" or "B" or "A and B".

[0344] While this disclosure describes the invention with respect to certain illustrative examples, those skilled in the art will recognize and understand that the invention is not limited thereto. Rather, many additions, deletions, and modifications may be made to the illustrative examples and the examples themselves without departing from the scope of the invention as claimed below and its legal equivalents. Furthermore, features from one example may be combined with features from another example while still being included within the scope of the invention as contemplated by the inventors.

[0345] The following is a non-exhaustive and non-limiting list of embodiments. Not every embodiment listed below is explicitly and individually indicated to be combinable with all other embodiments listed below and discussed above. However, it is intended that these embodiments be combinable with all other embodiments unless it would be obvious to those skilled in the art that these embodiments are not combinable.

[0346] Example 1: An apparatus comprising: a computing device including one or more processors, a plurality of peripheral communication devices of different communication protocol types operatively connected to the one or more processors, and a memory for storing processor-executable instructions including an application layer protocol stack, the processor-executable instructions being adapted to cause, when executed by the one or more processors, the one or more processors to perform operations on a corresponding message in a message to be transmitted to and from the computing device via a respective peripheral communication device among the plurality of peripheral communication devices, the operations including: transmitting the corresponding message in the message via the respective peripheral communication device among the plurality of peripheral communication devices according to a unified messaging protocol shared by the plurality of peripheral communication devices.

[0347] Example 2: According to the apparatus of Example 1, wherein the processor executable instructions are configured to cause the one or more processors of the computing device to perform an operation including: using a shared message queue to store the corresponding message in messages transmitted to and from the computing device via the respective peripheral communication devices among the plurality of peripheral communication devices.

[0348] Example 3: According to the apparatus described in Examples 1 and 2, the processor of the computing device executes instructions to cause the one or more processors to perform further operations to establish a corresponding secure communication session in a secure communication session with a corresponding destination device via a corresponding peripheral communication device among the plurality of peripheral communication devices, the further operations including: establishing the corresponding secure communication session in a secure communication session with the corresponding destination device via the corresponding peripheral communication device among the plurality of peripheral communication devices according to message exchange based on a mutual authentication and key exchange protocol shared by the plurality of peripheral communication devices.

[0349] Example 4: The apparatus according to any one of Examples 1 to 3, wherein the processor-executable instructions of the application layer protocol stack are used to process function calls to a set of functions associated with a set of application programming interfaces (APIs) exposed to the computing device, the set of functions including communication functions invoked by the application.

[0350] Example 5: The apparatus according to any one of Examples 1 to 4, wherein the processor executes instructions to cause the one or more processors of the computing device to perform the operation relative to the plurality of peripheral communication devices, the plurality of peripheral communication devices including three or more of the following: Universal Asynchronous Receiver-Transmitter (UART) interface, Internal Integrated Circuit (I2C) interface, Serial Peripheral Interface (SPI) interface, Controller Area Network (CAN) interface, T1S interface, Bluetooth or Bluetooth Low Energy (BLE) interface, IEEE 802.15.4 or Low Rate Wireless Personal Area Network (LR-WPAN) interface, Wi-Fi interface, Ethernet interface, and Universal Serial Bus (USB) interface.

[0351] Example 6: A non-transitory processor-readable medium, comprising: processor-executable instructions stored on the non-transitory processor-readable medium, the processor-executable instructions including an application layer protocol stack to be executed by one or more processors of a computing device comprising a plurality of peripheral communication devices having different communication protocol types, the processor-executable instructions being adapted to cause, when executed by the one or more processors, to perform an operation on a corresponding message in a message to be conveyed to and from the computing device via a corresponding peripheral communication device among the plurality of peripheral communication devices, the operation including: conveying the corresponding message in the message via the corresponding peripheral communication device among the plurality of peripheral communication devices according to a unified messaging protocol shared by the plurality of peripheral communication devices.

[0352] Example 7: A non-transitory processor-readable medium according to Example 6, wherein the processor-executable instructions are configured to cause the one or more processors of the computing device to perform an operation including: using a shared message queue to store the corresponding message in messages transmitted to and from the computing device via the respective peripheral communication devices among the plurality of peripheral communication devices.

[0353] Example 8: A non-transitory processor-readable medium according to Examples 6 and 7, wherein the processor-executable instructions cause the one or more processors to perform further operations to establish a corresponding secure communication session in a secure communication session with a corresponding destination device via a corresponding peripheral communication device among the plurality of peripheral communication devices, the further operations including: establishing the corresponding secure communication session in a secure communication session with the corresponding destination device via the corresponding peripheral communication device among the plurality of peripheral communication devices according to message exchange of a mutual authentication and key exchange protocol shared by the plurality of peripheral communication devices.

[0354] Example 9: A non-transitory processor-readable medium according to any one of Examples 6 to 8, wherein the processor-executable instructions are used to cause one or more processors of the computing device to perform the operation relative to the plurality of peripheral communication devices, the plurality of peripheral communication devices including three or more of the following: Universal Asynchronous Receiver-Transmitter (UART) interface, Internal Integrated Circuit (I2C) interface, Serial Peripheral Interface (SPI) interface, Controller Area Network (CAN) interface, T1S interface, Bluetooth or Bluetooth Low Energy (BLE) interface, IEEE 802.15.4 or Low Rate Wireless Personal Area Network (LR-WPAN) interface, Wi-Fi interface, Ethernet interface, and Universal Serial Bus (USB) interface.

[0355] Example 10: A non-transitory processor-readable medium for storing processor-executable instructions, which, when executed by one or more processors of a computing device comprising a plurality of peripheral communication devices with different communication protocol types, cause the one or more processors to perform operations comprising: receiving and processing function calls to at least some of a set of functions of the processor-executable instructions, the set of functions being associated with a set of application programming interfaces (APIs) of an application exposed to the computing device, the application invoking the function calls; and at least partially responding to receiving a function call for transmitting a message to a destination device, the function call indicating input parameters for identifying: data to be transmitted, a destination identifier of the destination device, and an interface identifier of the peripheral communication device through which the message is to be transmitted; preparing a message having a message format according to a predetermined messaging protocol, the message including the data; storing the message in a message queue; and writing one or more data portions of the message from the message queue to the peripheral communication device associated with the interface identifier until the message is transmitted via the peripheral communication device.

[0356] Example 11: The non-transitory processor-readable medium according to Example 10, wherein the processor-executable instructions include an application layer protocol stack for execution in the application layer of the computing device.

[0357] Example 12: A non-transitory processor-readable medium according to Examples 10 and 11, wherein the processor-executable instructions are configured to cause the one or more processors of the computing device to perform operations including: repeating the preparation, the storage, and the writing for a corresponding additional function call in one or more additional function calls to transmit a message through a corresponding other peripheral communication device among the plurality of peripheral communication devices.

[0358] Example 13: A non-transitory processor-readable medium according to any one of Examples 10 to 12, wherein the predetermined messaging protocol includes a unified messaging protocol, which is shared by messages sent via the plurality of peripheral communication devices.

[0359] Example 14: A non-transitory processor-readable medium according to any one of Examples 10 to 13, wherein the message queue includes a shared message queue for storing the messages sent via the plurality of peripheral communication devices.

[0360] Example 15: A non-transitory processor-readable medium according to any one of Examples 10 to 14, wherein the processor-executable instructions are used to cause the one or more processors of the computing device to perform the operation relative to the plurality of peripheral communication devices, the plurality of peripheral communication devices including one or more embedded peripheral communication devices and one or more non-embedded peripheral communication devices.

[0361] Example 16: A non-transitory processor-readable medium according to any one of Examples 10 to 15, wherein the processor-executable instructions are used to cause the one or more processors of the computing device to perform the operation relative to the plurality of peripheral communication devices, the plurality of peripheral communication devices including three or more of the following: Universal Asynchronous Receiver-Transmitter (UART) interface, Internal Integrated Circuit (I2C) interface, Serial Peripheral Interface (SPI) interface, Controller Area Network (CAN) interface, T1S interface, Bluetooth or Bluetooth Low Energy (BLE) interface, IEEE 802.15.4 or Low Rate Wireless Personal Area Network (LR-WPAN) interface, Wi-Fi interface, Ethernet interface, and Universal Serial Bus (USB) interface.

[0362] Example 17: A non-transitory processor-readable medium according to any one of Examples 10 to 16, wherein the processor-executable instructions are configured to cause the one or more processors of the computing device to perform an operation including: encrypting the data of the message based on one or more session keys before transmitting the message.

[0363] Example 18: A non-transitory processor-readable medium according to any one of Examples 10 to 17, wherein the processor-executable instructions are configured to cause the one or more processors of the computing device to perform an operation including: at least in part in response to receiving a function call for a function to write a data portion of the message to a peripheral communication device, the function call indicating input parameters for identifying the data portion, and the location of the input buffer of the peripheral communication device for writing the data portion: writing the data portion of the message from the message queue to the input buffer of the peripheral communication device at the location.

[0364] Example 19: A non-transitory processor-readable medium according to any one of Examples 10 to 18, wherein the processor-executable instructions are configured to cause the one or more processors of the computing device to perform an operation including: at least in part responding to a corresponding function call in an additional function call for writing the data portion of the message to the peripheral communication device: repeatedly writing the corresponding data portion of the next data portion of the message from the message queue to the location of the input buffer of the peripheral communication device.

[0365] Example 20: A non-transitory processor-readable medium according to any one of Examples 10 to 19, wherein the processor-executable instructions are configured to cause the one or more processors of the computing device to perform operations including: at least in part in response to receiving a function call for a function to read a portion of data from a peripheral communication device, the function call indicating input parameters for identifying: the location of the output buffer of the peripheral communication device from which the data portion is to be read; and reading and storing the data portion from the location of the output buffer of the peripheral communication device.

[0366] Example 21: A non-transitory processor-readable medium according to any one of Examples 10 to 20, wherein the data portion includes a header having a message format according to the predetermined messaging protocol, and the processor-executable instructions cause the one or more processors of the computing device to perform an operation including: reserving a portion of the message queue according to the payload length indicated in the header; and at least in part in response to a corresponding function call in an additional function call for reading the data portion from the peripheral communication device: repeatedly reading a corresponding data portion from the output buffer of the peripheral communication device for storage in the message queue until the message including the data portion and the next data portion is received in the message queue.

[0367] Example 22: A non-transitory processor-readable medium according to any one of Examples 10 to 21, wherein the message has a payload including data, and wherein the processor-executable instructions are configured to cause the one or more processors of the computing device to perform operations including: processing the message according to a type indicated in the header; storing the data of the message in a memory cache of the computing device; and providing the application with an indication of receiving the data stored in the memory cache.

[0368] Example 23: An apparatus comprising: a computing device including one or more processors, a plurality of peripheral communication devices operatively connected to the one or more processors and having different communication protocol types, and a memory for storing processor-executable instructions, which, when executed by the one or more processors, cause the one or more processors to perform operations, the operations including: receiving and processing function calls to at least some of a set of functions of the processor-executable instructions, the set of functions being associated with a set of application programming interfaces (APIs) of an application exposed to the computing device, the application invoking the function calls; and at least partially responding to receiving a function call for transmitting a message to a destination device, the function call indicating input parameters for identifying: data to be transmitted, a destination identifier of the destination device, and an interface identifier of the peripheral communication device through which the message is to be transmitted; preparing a message having a message format according to a predetermined messaging protocol, the message including the data; storing the message in a message queue; and writing one or more data portions of the message from the message queue to the peripheral communication device associated with the interface identifier until the message is transmitted via the peripheral communication device.

[0369] Example 24: The apparatus according to Example 23, wherein the processor executable instructions include an application layer protocol stack.

[0370] Example 25: The apparatus according to Examples 23 and 24, wherein the processor executable instructions are configured to cause the one or more processors of the computing device to perform operations including: repeating the preparation, the storage, and the writing for a corresponding additional function call in one or more additional function calls to transmit a message through a corresponding other peripheral communication device among the plurality of peripheral communication devices.

[0371] Example 26: The apparatus according to any one of Examples 23 to 25, wherein the message format according to the predetermined messaging protocol is shared by messages sent via the plurality of peripheral communication devices.

[0372] Example 27: The apparatus according to any one of Examples 23 to 26, wherein the message queue includes a shared message queue for storing the messages sent via the plurality of peripheral communication devices.

[0373] Example 28: The apparatus according to any one of Examples 23 to 27, wherein the plurality of peripheral communication devices includes one or more embedded peripheral communication devices and one or more non-embedded peripheral communication devices.

[0374] Example 29: The apparatus according to any one of Examples 23 to 28, wherein the plurality of peripheral communication devices includes three or more of the following: Universal Asynchronous Receiver-Transmitter (UART) interface, Internal Integrated Circuit (I2C) interface, Serial Peripheral Interface (SPI) interface, Controller Area Network (CAN) interface, T1S interface, Bluetooth or Bluetooth Low Energy (BLE) interface, IEEE 802.15.4 or Low Rate Wireless Personal Area Network (LR-WPAN) interface, Wi-Fi interface, Ethernet interface, and Universal Serial Bus (USB) interface.

[0375] Example 30: A non-transitory processor-readable medium comprising: processor-executable instructions stored on the non-transitory processor-readable medium, the processor-executable instructions including an application layer protocol stack to be executed by one or more processors of a computing device including one or more peripheral communication devices, the processor-executable instructions being adapted to cause, when executed by the one or more processors, to perform operations on a corresponding message in a message to be transmitted from the computing device via the one or more peripheral communication devices, the operations including: preparing a message based on data from an application of the computing device via a first processor-executable instruction of a session layer, and storing the message in a message queue, the message having a message format according to a predetermined messaging protocol; and writing one or more data portions of the message from the message queue to an input buffer of a designated peripheral communication device in the one or more peripheral communication devices, via a second processor-executable instruction of a message queue management layer, until the message is transmitted via the designated peripheral communication device.

[0376] Example 31: A non-transitory processor-readable medium according to Example 30, wherein the processor-executable instructions are adapted to cause, when executed by the one or more processors, the one or more processors to perform operations on a corresponding message in a message to be received at the computing device via the one or more peripheral communication devices, the operations comprising: reading one or more data portions of a message from an output buffer of an indication of a peripheral communication device in the one or more peripheral communication devices via second processor-executable instructions of the message queue management layer, and storing the one or more data portions of the message in the message queue until the message is received via the indication of a peripheral communication device, the message having the message format according to the predetermined messaging protocol, the message including a header and a payload including data; and reading the message from the message queue via first processor-executable instructions of the session layer, and processing the message according to the type indicated in the header.

[0377] Example 32: A non-transitory processor-readable medium according to Examples 30 and 31, wherein: the one or more peripheral communication devices include a plurality of peripheral communication devices with different communication protocol types, the operation is performed on a corresponding message in a message transmitted from the computing device and received at the computing device via a corresponding peripheral communication device among the plurality of peripheral communication devices, the predetermined messaging protocol includes a unified messaging protocol shared by messages sent and received via the plurality of peripheral communication devices, and the message queue includes a shared message queue for storing the messages sent and received via the plurality of peripheral communication devices.

[0378] Example 33: A non-transitory processor-readable medium according to any one of Examples 30 to 32, wherein the processor-executable instructions are used to cause one or more processors of the computing device to perform the operation relative to the plurality of peripheral communication devices, the plurality of peripheral communication devices including three or more of the following: Universal Asynchronous Receiver-Transmitter (UART) interface, Internal Integrated Circuit (I2C) interface, Serial Peripheral Interface (SPI) interface, Controller Area Network (CAN) interface, T1S interface, Bluetooth or Bluetooth Low Energy (BLE) interface, IEEE 802.15.4 or Low Rate Wireless Personal Area Network (LR-WPAN) interface, Wi-Fi interface, Ethernet interface, and Universal Serial Bus (USB) interface.

[0379] Example 34: A non-transitory processor-readable medium according to any one of Examples 30 to 33, wherein the processor-executable instructions are used to cause the one or more processors of the computing device to perform the operation relative to the one or more peripheral communication devices including embedded peripheral communication devices, the embedded peripheral communication devices being one of the following: a Universal Asynchronous Receiver / Transmitter (UART) interface, an Internal Integrated Circuit (I2C) interface, a Serial Peripheral Interface (SPI) interface, a Controller Area Network (CAN) interface, a T1S interface, a Bluetooth or Bluetooth Low Energy (BLE) interface, an IEEE 802.15.4 or Low Rate Wireless Personal Area Network (LR-WPAN) interface.

[0380] Example 35: An apparatus comprising: a computing device including one or more processors, one or more peripheral communication devices operatively connected to the one or more processors, and a memory for storing processor-executable instructions for an application layer protocol stack, the processor-executable instructions causing, when executed by the one or more processors, to cause the one or more processors to perform operations on a corresponding message in a message to be transmitted from the one or more peripheral communication devices via the one or more peripheral communication devices, the operations including: preparing a message based on data from an application of the computing device and storing the message in a message queue, the message having a message format according to a predetermined messaging protocol; and writing one or more data portions of the message from the message queue to an input buffer of a designated peripheral communication device among the one or more peripheral communication devices until the message is transmitted via the designated peripheral communication device among the one or more peripheral communication devices.

[0381] Example 36: The apparatus of Example 35, wherein the processor-executable instructions are adapted to cause, when executed by the one or more processors, to perform operations on a corresponding message in a message to be received at the computing device via the one or more peripheral communication devices, the operations comprising: reading one or more data portions of a message from an output buffer of one of the one or more peripheral communication devices indicating a peripheral communication device, and storing the one or more data portions of the message in a message queue until the message is received via the one or more peripheral communication devices indicating a peripheral communication device, the message having the message format according to the predetermined messaging protocol, the message including a header and a payload including data; and reading the message from the message queue and processing the message according to a type indicated in the header, including: storing the data of the message in a memory cache of the computing device, and providing an indication to the application that the data stored in the memory cache has been received.

[0382] Example 37: The apparatus according to Examples 35 and 36, wherein: the one or more peripheral communication devices include a plurality of peripheral communication devices with different communication protocol types, the operation is performed on a corresponding message in a message transmitted from the computing device and received at the computing device via a corresponding peripheral communication device among the plurality of peripheral communication devices, the predetermined messaging protocol includes a unified messaging protocol shared by messages sent and received via the plurality of peripheral communication devices, and the message queue includes a shared message queue for storing the messages sent and received via the plurality of peripheral communication devices.

[0383] Example 38: The apparatus according to any one of Examples 35 to 37, wherein the processor executes instructions to cause the one or more processors of the computing device to perform the operation relative to the plurality of peripheral communication devices, the plurality of peripheral communication devices including three or more of the following: Universal Asynchronous Receiver-Transmitter (UART) interface, Internal Integrated Circuit (I2C) interface, Serial Peripheral Interface (SPI) interface, Controller Area Network (CAN) interface, T1S interface, Bluetooth or Bluetooth Low Energy (BLE) interface, IEEE 802.15.4 or Low Rate Wireless Personal Area Network (LR-WPAN) interface, Wi-Fi interface, Ethernet interface, and Universal Serial Bus (USB) interface.

[0384] Example 39: The apparatus according to any one of Examples 35 to 38, wherein the one or more peripheral communication devices are embedded peripheral communication devices, and the embedded peripheral communication device is one of the following: Universal Asynchronous Receiver-Transmitter (UART) interface, Internal Integrated Circuit (I2C) interface, Serial Peripheral Interface (SPI) interface, Controller Area Network (CAN) interface, T1S interface, Bluetooth or Bluetooth Low Energy (BLE) interface, IEEE 802.15.4 or Low Rate Wireless Personal Area Network (LR-WPAN) interface.

[0385] Example 40: A computing device including an embedded peripheral communication device, the computing device comprising: one or more processors; a memory for storing processor-executable instructions including an application-layer protocol stack; receiving the processor-executable instructions for transmitting a message from an application of the computing device to a destination device, adapted to cause the one or more processors, when executed by the one or more processors, to perform operations including: receiving a function call for a function for transmitting a message from an application of the computing device to a destination device, the function being provided in a set of application programming interfaces (APIs) exposed to the application, the function call indicating one or more input parameters for identifying: data to be transmitted, and a destination identifier of the destination device; and in response to receiving the function call for transmitting the message: preparing a message having a message format according to a unified messaging protocol, the message including the data; and transmitting the message including the data via the embedded peripheral communication device.< / vv>

Claims

1. An apparatus comprising: A computing device, the computing device including one or more processors, a plurality of peripheral communication devices having different communication protocol types operatively connected to the one or more processors, and a memory for storing processor-executable instructions including an application-layer protocol stack, the processor-executable instructions being adapted to cause, when executed by the one or more processors, the one or more processors to perform operations on corresponding messages in messages to be transmitted to and from the computing device via corresponding peripheral communication devices of the plurality of peripheral communication devices, the operations including: According to the unified messaging protocol shared by the multiple peripheral communication devices, the corresponding message in the message is transmitted via the corresponding peripheral communication device among the multiple peripheral communication devices.

2. The apparatus of claim 1, wherein the processor-executable instructions are configured to cause the one or more processors of the computing device to perform operations including: A shared message queue is used to store the corresponding messages in the messages transmitted from the respective peripheral communication devices to and from the computing device via the plurality of peripheral communication devices.

3. The apparatus of claim 2, wherein the processor of the computing device is executable instructions that cause the one or more processors to perform further operations to establish a corresponding secure communication session in a secure communication session with a corresponding destination device via a corresponding peripheral communication device of the plurality of peripheral communication devices, the further operations including: The corresponding secure communication session is established between the corresponding peripheral communication device and the corresponding destination device through message exchange based on the mutual authentication and key exchange protocol shared by the multiple peripheral communication devices.

4. The apparatus of claim 1, wherein the processor-executable instructions of the application layer protocol stack are configured to process function calls to a set of functions associated with a set of application programming interfaces (APIs) exposed to the computing device, the set of functions including communication functions invoked by the application.

5. The apparatus of claim 1, wherein the processor is executable instructions for causing the one or more processors of the computing device to perform the operation relative to the plurality of peripheral communication devices, the plurality of peripheral communication devices including three or more of the following: Universal Asynchronous Receiver-Transmitter (UART) interface, Internal Integrated Circuit (I2C) interface, Serial Peripheral Interface (SPI) interface, Controller Area Network (CAN) interface, T1S interface, Bluetooth or Bluetooth Low Energy (BLE) interface, IEEE 802.15.4 or Low Rate Wireless Personal Area Network (LR-WPAN) interface, Wi-Fi interface, Ethernet interface, and Universal Serial Bus (USB) interface.

6. A non-transitory processor-readable medium, comprising: Processor-executable instructions stored on the non-transitory processor-readable medium, the processor-executable instructions including an application layer protocol stack to be executed by one or more processors of a computing device comprising a plurality of peripheral communication devices having different communication protocol types, the processor-executable instructions being adapted to cause, when executed by the one or more processors, to perform operations on corresponding messages in messages to be conveyed to and from the computing device via corresponding peripheral communication devices among the plurality of peripheral communication devices, the operations including: According to the unified messaging protocol shared by the multiple peripheral communication devices, the corresponding message in the message is transmitted via the corresponding peripheral communication device among the multiple peripheral communication devices.

7. The non-transitory processor-readable medium of claim 6, wherein the processor-executable instructions are configured to cause the one or more processors of the computing device to perform operations including: A shared message queue is used to store the corresponding messages in the messages transmitted from the respective peripheral communication devices to and from the computing device via the plurality of peripheral communication devices.

8. The non-transitory processor-readable medium of claim 6, wherein the processor-executable instructions cause the one or more processors to perform further operations to establish a corresponding secure communication session in a secure communication session with a corresponding destination device via a corresponding peripheral communication device among the plurality of peripheral communication devices, the further operations comprising: The corresponding secure communication session is established between the corresponding peripheral communication device and the corresponding destination device through message exchange based on the mutual authentication and key exchange protocol shared by the multiple peripheral communication devices.

9. The non-transitory processor-readable medium of claim 6, wherein the processor-executable instructions are used to cause the one or more processors of the computing device to perform the operation relative to the plurality of peripheral communication devices, the plurality of peripheral communication devices including three or more of the following: Universal Asynchronous Receiver-Transmitter (UART) interface, Internal Integrated Circuit (I2C) interface, Serial Peripheral Interface (SPI) interface, Controller Area Network (CAN) interface, T1S interface, Bluetooth or Bluetooth Low Energy (BLE) interface, IEEE 802.15.4 or Low Rate Wireless Personal Area Network (LR-WPAN) interface, Wi-Fi interface, Ethernet interface, and Universal Serial Bus (USB) interface.

10. A non-transitory processor-readable medium for storing processor-executable instructions, which, when executed by one or more processors of a computing device including a plurality of peripheral communication devices having different communication protocol types, cause the one or more processors to perform operations, the operations including: Receive and process function calls to at least some of a set of functions executable by the processor, the set of functions being associated with a set of application programming interfaces (APIs) of an application exposed to the computing device, the application invoking the function calls; and At least in part, in response to receiving a function call for a function to transmit a message to a destination device, the function call indicating input parameters for identifying the following: the data to be transmitted, the destination identifier of the destination device, and the interface identifier of the peripheral communication device through which the message is to be transmitted among the plurality of peripheral communication devices: Prepare a message having a message format according to a predetermined messaging protocol, the message including the data; Store the message in a message queue; as well as One or more data portions of the message from the message queue are written to the peripheral communication device associated with the interface identifier until the message is sent via the peripheral communication device.

11. The non-transitory processor-readable medium of claim 10, wherein the processor-executable instructions include an application layer protocol stack for execution in the application layer of the computing device.

12. The non-transitory processor-readable medium of claim 10, wherein the processor-executable instructions are configured to cause the one or more processors of the computing device to perform operations including: The preparation, storage, and writing are repeated for the corresponding additional function call in one or more additional function calls to transmit messages through the corresponding other peripheral communication devices among the plurality of peripheral communication devices.

13. The non-transitory processor-readable medium of claim 12, wherein the predetermined messaging protocol includes a unified messaging protocol shared by messages sent via the plurality of peripheral communication devices.

14. The non-transitory processor-readable medium of claim 13, wherein the message queue includes a shared message queue for storing the messages sent via the plurality of peripheral communication devices.

15. The non-transitory processor-readable medium of claim 14, wherein the processor-executable instructions are configured to cause the one or more processors of the computing device to perform the operation relative to the plurality of peripheral communication devices, the plurality of peripheral communication devices including one or more embedded peripheral communication devices and one or more non-embedded peripheral communication devices.

16. The non-transitory processor-readable medium of claim 14, wherein the processor-executable instructions are used to cause the one or more processors of the computing device to perform the operation relative to the plurality of peripheral communication devices, the plurality of peripheral communication devices including three or more of the following: Universal Asynchronous Receiver-Transmitter (UART) interface, Internal Integrated Circuit (I2C) interface, Serial Peripheral Interface (SPI) interface, Controller Area Network (CAN) interface, T1S interface, Bluetooth or Bluetooth Low Energy (BLE) interface, IEEE 802.15.4 or Low Rate Wireless Personal Area Network (LR-WPAN) interface, Wi-Fi interface, Ethernet interface, and Universal Serial Bus (USB) interface.

17. The non-transitory processor-readable medium of claim 10, wherein the processor-executable instructions are configured to cause the one or more processors of the computing device to perform operations including: Before transmitting the message, the data of the message is encrypted based on one or more session keys.

18. The non-transitory processor-readable medium of claim 10, wherein the processor-executable instructions are configured to cause the one or more processors of the computing device to perform operations including: At least in part, in response to receiving a function call for writing a data portion of the message to a peripheral communication device, the function call indicating input parameters for identifying the data portion and the location of the input buffer of the peripheral communication device for writing the data portion. The data portion of the message is written from the message queue to the location of the input buffer of the peripheral communication device.

19. The non-transitory processor-readable medium of claim 18, wherein the processor-executable instructions are configured to cause the one or more processors of the computing device to perform operations including: At least partially in response to a corresponding function call in an additional function call for writing the data portion of the message to the peripheral communication device: The corresponding data portion of the next data portion of the message is repeatedly written from the message queue to the location of the input buffer of the peripheral communication device.

20. The non-transitory processor-readable medium of claim 10, wherein the processor-executable instructions are configured to cause the one or more processors of the computing device to perform operations including: At least in part, in response to receiving a function call for a function to read data from a peripheral communication device, the function call indicating input parameters for identifying the location of the output buffer of the peripheral communication device from which the data portion is to be read: The data portion is read from the location of the output buffer of the peripheral communication device and the data portion is stored.

21. The non-transitory processor-readable medium of claim 20, wherein the data portion includes a header having a message format according to the predetermined messaging protocol, and the processor-executable instructions cause the one or more processors of the computing device to perform operations including: A portion of the message queue is reserved according to the payload length indicated in the header; and At least in part, it responds to a corresponding function call in an additional function call for reading the data portion from the peripheral communication device: The corresponding data portion of the next data portion is repeatedly read from the output buffer of the peripheral communication device and stored in the message queue until the message including the data portion and the next data portion is received in the message queue.

22. The non-transitory processor-readable medium of claim 21, wherein the message has a payload comprising data, and wherein the processor-executable instructions are configured to cause the one or more processors of the computing device to perform operations comprising: The message is processed according to the type indicated in the header; The data of the message is stored in the memory cache of the computing device; as well as Provide the application with an indication that the data stored in the memory cache has been received.

23. An apparatus comprising: A computing device, comprising one or more processors, a plurality of peripheral communication devices operatively connected to the one or more processors and having different communication protocol types, and a memory for storing processor-executable instructions, which, when executed by the one or more processors, cause the one or more processors to perform operations, the operations including: Receive and process function calls to at least some of a set of functions executable by the processor, the set of functions being associated with a set of application programming interfaces (APIs) of an application exposed to the computing device, the application invoking the function calls; and At least in part, in response to receiving a function call for a function to transmit a message to a destination device, the function call indicating input parameters for identifying the following: the data to be transmitted, the destination identifier of the destination device, and the interface identifier of the peripheral communication device through which the message is to be transmitted among the plurality of peripheral communication devices: Prepare a message having a message format according to a predetermined messaging protocol, the message including the data; Store the message in a message queue; and One or more data portions of the message from the message queue are written to the peripheral communication device associated with the interface identifier until the message is sent via the peripheral communication device.

24. The apparatus of claim 23, wherein the processor executable instructions include an application layer protocol stack.

25. The apparatus of claim 23, wherein the processor-executable instructions are configured to cause the one or more processors of the computing device to perform operations including: The preparation, storage, and writing are repeated for the corresponding additional function call in one or more additional function calls to transmit messages through the corresponding other peripheral communication devices among the plurality of peripheral communication devices.

26. The apparatus of claim 25, wherein the message format according to the predetermined messaging protocol is shared by messages sent via the plurality of peripheral communication devices.

27. The apparatus of claim 26, wherein the message queue includes a shared message queue for storing the messages sent via the plurality of peripheral communication devices.

28. The apparatus of claim 27, wherein the plurality of peripheral communication devices includes one or more embedded peripheral communication devices and one or more non-embedded peripheral communication devices.

29. The apparatus of claim 27, wherein the plurality of peripheral communication devices comprises three or more of the following: a Universal Asynchronous Receiver-Transmitter (UART) interface, an Internal Integrated Circuit (I2C) interface, a Serial Peripheral Interface (SPI) interface, a Controller Area Network (CAN) interface, a T1S interface, a Bluetooth or Bluetooth Low Energy (BLE) interface, an IEEE 802.15.4 or Low Rate Wireless Personal Area Network (LR-WPAN) interface, a Wi-Fi interface, an Ethernet interface, and a Universal Serial Bus (USB) interface.

30. A non-transitory processor-readable medium, comprising: Processor-executable instructions stored on the non-transitory processor-readable medium, the processor-executable instructions including an application layer protocol stack to be executed by one or more processors of a computing device including one or more peripheral communication devices, the processor-executable instructions being adapted to cause, when executed by the one or more processors, to cause the one or more processors to perform operations on corresponding messages in messages to be transmitted from the computing device via the one or more peripheral communication devices, the operations including: Instructions executable by a first processor in the session layer prepare a message based on data from an application of the computing device and store the message in a message queue, the message having a message format according to a predetermined messaging protocol; and The second processor-executable instructions of the message queue management layer write one or more data portions of the message from the message queue to the input buffer of a designated peripheral communication device in the one or more peripheral communication devices until the message is sent via the designated peripheral communication device.

31. The non-transitory processor-readable medium of claim 30, wherein the processor-executable instructions are adapted to cause, when executed by the one or more processors, the one or more processors to perform operations on a corresponding message in a message to be received at the computing device via the one or more peripheral communication devices, the operations comprising: The second processor of the message queue management layer executes instructions to read one or more data portions of a message from the output buffer of the one or more peripheral communication devices that indicates a peripheral communication device, and to store the one or more data portions of the message in the message queue until the message is received via the indicated peripheral communication device, the message having the message format according to the predetermined messaging protocol, the message including a header and a payload including data; as well as The first processor in the session layer can execute instructions to read the message from the message queue and process the message according to the type indicated in the header.

32. The non-transitory processor-readable medium according to claim 31, wherein: The one or more peripheral communication devices include multiple peripheral communication devices with different communication protocol types. The operation is performed on the corresponding message in the messages transmitted from the computing device via the corresponding peripheral communication device among the plurality of peripheral communication devices and received at the computing device. The predetermined message passing protocol includes a unified message passing protocol shared by messages sent and received via the multiple peripheral communication devices, and The message queue includes a shared message queue for storing messages sent and received via the plurality of peripheral communication devices.

33. The non-transitory processor-readable medium of claim 32, wherein the processor-executable instructions are used to cause the one or more processors of the computing device to perform the operation relative to the plurality of peripheral communication devices, the plurality of peripheral communication devices including three or more of the following: Universal Asynchronous Receiver-Transmitter (UART) interface, Internal Integrated Circuit (I2C) interface, Serial Peripheral Interface (SPI) interface, Controller Area Network (CAN) interface, T1S interface, Bluetooth or Bluetooth Low Energy (BLE) interface, IEEE 802.15.4 or Low Rate Wireless Personal Area Network (LR-WPAN) interface, Wi-Fi interface, Ethernet interface, and Universal Serial Bus (USB) interface.

34. The non-transitory processor-readable medium of claim 30, wherein the processor-executable instructions are used to cause the one or more processors of the computing device to perform the operation relative to the one or more peripheral communication devices including embedded peripheral communication devices, said embedded peripheral communication devices being one of: a Universal Asynchronous Receiver-Transmitter (UART) interface, an Internal Integrated Circuit (I2C) interface, a Serial Peripheral Interface (SPI) interface, a Controller Area Network (CAN) interface, a T1S interface, a Bluetooth or Bluetooth Low Energy (BLE) interface, an IEEE 802.15.4 or Low Rate Wireless Personal Area Network (LR-WPAN) interface.

35. An apparatus comprising: A computing device, the computing device including one or more processors, one or more peripheral communication devices operatively connected to the one or more processors, and a memory for storing processor-executable instructions for an application layer protocol stack, the processor-executable instructions causing, when executed by the one or more processors, to cause the one or more processors to perform operations on a corresponding message in a message to be transmitted from the computing device via the one or more peripheral communication devices, the operations including: Prepare messages based on data from the application of the computing device, and store the messages in a message queue, the messages having a message format according to a predetermined messaging protocol; and One or more data portions of the message are written from the message queue to the input buffer of a designated peripheral communication device in the one or more peripheral communication devices until the message is sent via the designated peripheral communication device in the one or more peripheral communication devices.

36. The apparatus of claim 35, wherein the processor-executable instructions are adapted to cause, when executed by the one or more processors, the one or more processors to perform operations on a corresponding message in a message to be received at the computing device via the one or more peripheral communication devices, the operations comprising: One or more data portions of a message are read from the output buffer of the one or more peripheral communication devices that indicate a peripheral communication device, and the one or more data portions of the message are stored in the message queue until the message is received via the one or more peripheral communication devices that indicate a peripheral communication device, the message having the message format according to the predetermined messaging protocol, the message including a header and a payload including data; as well as Reading the message from the message queue and processing the message according to the type indicated in the header includes: storing the message data in the memory cache of the computing device, and providing the application with an indication that the data stored in the memory cache has been received.

37. The apparatus of claim 36, wherein: The one or more peripheral communication devices include multiple peripheral communication devices with different communication protocol types. The operation is performed on the corresponding message in the messages transmitted from the computing device via the corresponding peripheral communication device among the plurality of peripheral communication devices and received at the computing device. The predetermined message passing protocol includes a unified message passing protocol shared by messages sent and received via the multiple peripheral communication devices, and The message queue includes a shared message queue for storing messages sent and received via the plurality of peripheral communication devices.

38. The apparatus of claim 36, wherein the processor is executable instructions for causing the one or more processors of the computing device to perform the operation relative to the plurality of peripheral communication devices, the plurality of peripheral communication devices including three or more of the following: Universal Asynchronous Receiver-Transmitter (UART) interface, Internal Integrated Circuit (I2C) interface, Serial Peripheral Interface (SPI) interface, Controller Area Network (CAN) interface, T1S interface, Bluetooth or Bluetooth Low Energy (BLE) interface, IEEE 802.15.4 or Low Rate Wireless Personal Area Network (LR-WPAN) interface, Wi-Fi interface, Ethernet interface, and Universal Serial Bus (USB) interface.

39. The apparatus of claim 35, wherein the one or more peripheral communication devices are embedded peripheral communication devices, the embedded peripheral communication device being one of the following: a Universal Asynchronous Receiver-Transmitter (UART) interface, an Internal Integrated Circuit (I2C) interface, a Serial Peripheral Interface (SPI) interface, a Controller Area Network (CAN) interface, a T1S interface, a Bluetooth or Bluetooth Low Energy (BLE) interface, an IEEE 802.15.4 or Low Rate Wireless Personal Area Network (LR-WPAN) interface.

40. A computing device including an embedded peripheral communication device, the computing device comprising: One or more processors; The memory is used to store processor-executable instructions, including an application layer protocol stack; The processor-executable instructions are adapted to cause, when executed by the one or more processors, the one or more processors to perform operations, the operations including: Receive a function call for a function for transmitting messages from an application of the computing device to a destination device, the function being provided in a set of application programming interfaces (APIs) exposed to the application, the function call indicating one or more input parameters for identifying the following: the data to be transmitted, and the destination identifier of the destination device; as well as In response to receiving the function call for the function used to transmit the message: Prepare a message having a message format according to a unified messaging protocol, the message including the data; and The message, including the data, is transmitted via the embedded peripheral communication device.

Images