Array of secure elements in internet of things system

Abstract

To provide a method for transmitting data using a collision-tolerant full-duplex communication protocol via a half-duplex connection.SOLUTION: A method includes the steps of: terminating a data receiving mode of a first device that transmits data; the first device transmitting a data frame via a half-duplex connection for reception by a second device; the first device monitoring for an acknowledgment from the second device; determining that the acknowledgment includes a cyclic redundancy check value and that the data frame needs to be re-transmitted; identifying a device role of the first device; and retransmitting the data frame at a time corresponding to the identification of the device role.SELECTED DRAWING: Figure 6

Description

[Technical field]

[0001] This specification relates generally, but not exclusively, to Internet-of-things (IoT) systems, and more particularly, but not exclusively, to a transparent architecture for IoT systems. [Background technology]

[0002] Internet of Things (IoT) systems often include edge devices that include various sensors or other methods of collecting and communicating data. Some of these edge devices may not have direct network connectivity or may be otherwise resource constrained. In addition, these edge devices often need to store key material and perform secure processing. However, edge devices in IoT systems often lack processing resources and security capabilities, and the physical location of the edge device may not be conducive for the edge device to store key material. These edge devices may also implement software that requires periodic updates. Due to limited network connectivity to some of these edge devices, this may require a technician to access each individual edge device each time a software update is needed. This can be time and resource consuming in a system with many edge devices. Summary of the Invention

[0003] The present invention provides a system and method for providing secure execution of system functions on edge devices, a non-transitory computer readable medium, and a physical access control system, as recited in the claims. [Brief description of the drawings]

[0004] In the drawings, which are not necessarily drawn to scale, like reference numbers may describe like components in different figures. Like reference numbers with different suffixes may represent different instances of the like components. Some embodiments are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings. [Figure 1] FIG. 1 illustrates an exemplary physical access control system. [Diagram 2] FIG. 1 is a block diagram illustrating an example Internet of Things (IoT) architecture including an array of secure elements. [Diagram 3] FIG. 1 is a block diagram illustrating an exemplary secure IoT gateway. [Figure 4A] 1 illustrates an exemplary workflow for authenticating an array of secure elements by a controller. [Figure 4B] 1 illustrates an exemplary workflow for authenticating a policy and / or controller by a sister board of a secure element. [Figure 5A-5C] FIG. 2 illustrates an exemplary transmission frame for a full-duplex protocol for use in a half-duplex system. [Figure 6] 4 is a flowchart illustrating an exemplary method for transmitting messaging over a half-duplex communication line using a full-duplex protocol. [Figure 7] FIG. 1 is a block diagram illustrating an example of a machine in which one or more embodiments may be implemented. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0005] Disclosed herein are systems and methods for implementing a transparent architecture for Internet of Things (IoT) systems using an array of secure elements. An exemplary IoT architecture includes a gateway equipped with a built-in or connectable array of secure elements. The secure elements include hardware and / or software for performing cryptographic functions or processes, such as encryption, decryption, signature generation, signature verification, and / or key generation. The secure elements are contained within an explicitly defined perimeter that establishes the physical boundary of the cryptographic module and includes any processors and / or other hardware components that store and protect any software and firmware components of the cryptographic module. The secure elements can take the form of (or include) a secure crypto processor, a smart card, a secure digital (SD) card, a micro SD card, a SIM card, and / or any other cryptographic module.

[0006] A secure element (SE) is a tamper-resistant platform capable of securely hosting multiple applications and their secret and cryptographic data, in accordance with the rules and security requirements prescribed by a set of duly identified trusted authorities. An SE can be thought of as a chip that provides a dynamic environment for securely storing data, securely processing data, and securely communicating with external entities.

[0007] Physical Access Control Systems (PACS) include readers (edge ​​devices) and controllers (intermediate servers / devices). In a traditional PACS system, the reader is a smart device that hosts and runs software to securely communicate with cards or mobile phones that come within the reader's communication range. A successful PACS system focuses on both user experience and security. Thus, the reader device must have enough processing power to address both latency issues and hardware-based and software-based security primitives. The reader device has support for authenticating and reading data from a wide range of card devices that have different protocols (both at the transport and application levels) and have different data modalities. This results in a lot of software implemented by the reader device that must be updated to support new card modalities, bug fixes, etc. Since the reader device often does not have a network connection, the reader device needs to be physically accessed by a technician to perform these updates. Furthermore, this results in a secure element that is physically located on the reader, which stores the secure software and key material. Some readers are physically located, for example, in exterior portions of a building, which may raise security concerns for businesses, authentication entities, or other users of the PACS system who may desire or require that substantially all of the secure storage of keys be physically located within a secure perimeter, such as the perimeter of a building.

[0008] To improve the above situation, an array of secure elements separate from the reader may be used to execute security and application software for the reader device. The array of secure elements may be integrated with or attached to the PACS controller and configured to handle multiple parallel requests and connections to multiple edge devices (readers). The PACS controller may have a network connection to one or more remote devices that may store and provide software or firmware updates for the secure elements. In this way, the secure elements can be updated without a technician having to access each individual edge device (reader). The PACS controller may also be physically located within a building or other secure perimeter, eliminating security concerns about having multiple secure elements located on several readers.

[0009] In one example, an array of secure elements may be placed on a sister board that may connect to a host device using one or more buses having bus protocols such as serial peripheral interface (SPI), inter-integrated circuit (I2C), universal serial bus (USB), etc. The secure element may be used for several functions. For example, the secure element may operate as a crypto-processor that provides security algorithms and provides secure storage of sensitive key material. In another example, the secure element may be used as an application platform that runs application specific software along with storage of security algorithms and key material. For example, in a PACS system, the secure element may be used to perform authentication of users that present authentication credentials to a PACS reader. In this way, software functionality to perform user authentication is not required in the reader device itself.

[0010] Figure 1 illustrates an exemplary scenario 100 in which a PACS may be used. As shown in Figure 1, a wall 102 has a door 104 disposed therein. In the exemplary situation, a secured area is behind the door 104, and the door has a lockable handle 106 that allows access to the secured area when in an unlocked state and prevents access to the secured area when in a locked state.

[0011] The reader device 108 is positioned proximate to the handle 106 of the door 104. In one example, the handle 106 is locked in a default state. The reader system 108 is operable to selectively place the handle 106 in an unlocked state in response to presentation of approved authentication credentials contained in a credential device 112 that can communicate with the reader device 108 via a wireless interface 110. In various examples, the credential device 112 can be a key card, a fob, a mobile device (e.g., a smartphone), or any other suitable credential device having communication capabilities and authentication credentials.

[0012] In conventional systems, application software for authenticating a user may be implemented in the reader device 108 itself. For example, a user presents a credential device 112 that communicates with the reader device 108 and provides authentication credentials to the reader device 108. The reader device 108 then uses the received authentication credentials to securely authenticate the user and unlock the handle 106. In other conventional examples, part of this functionality is included in the reader device 108 and part in a remotely located PACS controller. For example, the reader device may perform a secure transaction with the credential device 112 and then send the data to the PACS controller to authenticate the user. The controller may then communicate to unlock the handle 106.

[0013] Software or firmware updates may be required for the reader device 108 to perform secure transactions and / or authentication. In some examples, the reader device 108 does not include a network connection and is only connected to the PACS controller via a single wired connection, such as an RS-485 or other connection. This requires a technician to physically go to the reader device 108 to update the software or firmware of each reader device 108 in the PACS system. It is desirable to move some of this functionality away from the reader for ease of maintenance while still providing the user with the same or better user experience as the reader device 108.

[0014] To achieve this, an array of secure elements may be implemented in a PACS controller, with each secure element configured to implement secure software execution for an individual reader device 108. These PACS controllers often include one or more network connections to allow remote updates of the software executed by the secure elements, eliminating the need for technicians to physically travel to each reader device 108. It should be understood that the present disclosure is applicable to many types of IoT systems in addition to PACS systems. The system 100 shown in FIG. 1 is presented merely as an example and not as a limitation.

[0015] FIG. 2 illustrates an IoT system 200. The system 200 includes multiple edge device clusters 210 and a secure IoT gateway (SIG) 220. The multiple edge device clusters 210 may each include one or more edge devices 230, such as the reader device 108 of FIG. 1. The SIG 220 may communicate with a remote source 240 over a local area network or a wide area network 280, such as the Internet. The SIG 220 may include a controller 250 and a sister board 260 that includes multiple secure elements 270. In one example, the controller 250 may be a PACS controller. Although illustrated as two clusters 210 of five edge devices 230 each and four secure elements 270, any number of clusters 210 with any number of edge devices 230 and any number of secure elements 270 may be implemented for the system 200. Although illustrated as separate controller 250 and sister board 260, in some examples, multiple secure elements 270 may be integrated with controller 250. Controller 250 may be connected to communicate with sister board 260 using any bus protocol, such as SPI, I2C, USB, etc.

[0016] The SIG 220 is connected via a network connection 280 to communicate with remote source(s) 240 and via individual connections 290 to communicate with individual edge devices 230. For example, the connection 280 may be a local area network connection or a wide area network connection such as an Internet connection. The individual connections 290 may be wired or wireless connections such as Ethernet, Wi-Fi, USB, RS-485, etc. Although illustrated as a single connection 290 for each cluster 210, a connection 290 may be provided for each individual edge device 230. The remote source 240 may be one or more servers or other computing devices and may store firmware files or other software updates for multiple secure elements 270. In some examples, the SIG 220 communicates with the remote source 240 to obtain firmware files or other software updates to update one or more secure elements 270 implemented by the SIG 220.

[0017] In a PACS system as shown in FIG. 1, the reader device 108 may be an edge device 230 connected to communicate with a controller 250, such as a PACS controller. The connection 290 may be a wired full-duplex connection, a wired half-duplex connection such as an RS-485 connection, or any other connection. The secure element 270 may be configured to execute software that performs functions using application-specific hardware for the reader 108. For example, when a user approaches the reader device 108 and presents authentication credentials using the credential device 112, the secure element 270 may be assigned to the transaction to perform security algorithms, secure storage of confidential key material, as well as user authentication. In some examples, the reader device 108 may only obtain authentication credentials from the credential device 112 and provide the authentication credentials to the controller, and the secure element 270 performs all of the application-specific functions to authenticate the user and unlock the door handle 106. In other examples, some of the application-specific functions may be performed by the reader device 108 and some by the secure element 270.

[0018] When a user approaches the reader device 108, or when the reader device 108 receives the user's authentication credentials, the controller 250 or other electronic circuitry may select and assign a secure element 270 for use with the reader device 108. This may be any secure element 270 that is currently available to the running software for the reader device 108.

[0019] In one example, each edge device 230 may dynamically receive a reference to a secure element 270 that the individual edge device 230 is assigned for an individual session. For example, when an edge device 230 requires a secure element 270, the controller 250 may identify an available secure element 270 that can provide the required functionality for the individual edge device 230. The controller 250 may also be implemented as a "dispatcher" responsible for dispatching messages or data to the individual secure elements 270, shielding the array of secure elements from the individual edge devices 230. This allows for a high level of modularity in code development and management, while protecting against crashes or termination of the edge devices 230 or other actors in the system.

[0020] Other devices or circuitry for monitoring the lifecycle of edge device 230 or secure element 270 and implementing policies, for example, to either regenerate individual devices or keep the devices in a terminated state and notify a system administrator, may also be implemented in system 200. In other examples, one or more of edge device 230, controller 250, or secure element 270 may monitor the lifecycle of multiple devices in the system, which may be used in cleaning up or resetting the individual states of multiple devices in the system.

[0021] In some cases, it may be desirable to implement applications and key material on edge devices that are not accessible by the remote device 240 or other entities. For example, in a PACS system, an entity may desire to program the controller 250 or secure element 270 with a particular authentication code that is not accessible by other entities, such as via the remote device 240. To allow this, the secure element 270 may be configured such that the secure element 270 is programmable in a high-level language. In some examples, a runtime capable of running a language runtime for the secure element 270 may be implemented, even if the secure element 270 is a resource-constrained device. Thus, an entity may develop an application and install the application on the secure element 270.

[0022] In the above scenario, it is desirable to restrict who can install these applications on the secure element 270. In one example, applications installed on the secure element 270 must be signed by an entity, and then a higher-level entity or other entity double-signs the application with a corresponding key. If the application is double-signed, one or more of the secure elements 270 or the embedded secure element of the controller 250 allows the application to be installed on an individual secure element 270. This allows entities to independently develop applications and load them onto the secure element 270. In some examples, a virtual firewall may also be implemented by the secure element 270 to prevent applications installed by the secure element 270 from interfering with each other.

[0023] 3 is a block diagram illustrating an example implementation of the SIG 220. The gateway 220 includes control circuitry 300, a processing element 310, and one or more secure elements 320, which may be the secure element 270 of FIG. 2. In some cases, the gateway 220 includes four secure elements 320. Each secure element 320 of the gateway 220 may be configured to perform the same function. In some implementations, the secure element 320 is implemented (in both hardware and software) to provide a higher level of security assurance than a typical general-purpose microprocessor. In some implementations, the secure element 320 is implemented as a general-purpose microprocessor without providing a higher level of security assurance.

[0024] The control circuitry 300 and processing elements 310 may be configured to implement an allocation protocol for allocating secure elements 320 to individual edge devices 230. The control circuitry 300 and processing elements 310 may be implemented by the controller 250 and / or on the sister board 260. To enable the use of secure elements 320 with edge devices 230, the edge devices 230, secure elements 320, protocols, etc. may be implemented as actors that manage their own state and communicate only with other actors in the system using intra-process messaging. These actors maintain the configuration state of their individual devices and dynamically receive references to the secure elements 320 that they have been assigned to a given session. Similarly, actors may be connected / registered with actors with which they are able to communicate using the desired transport and application protocols.

[0025] The control circuitry 300 and / or processing elements 310 may execute software acting as a dispatcher actor responsible for dispatching messages / data to the appropriate associated secure elements 320, thereby shielding the entire array of secure elements 320 from, for example, an actor representing the edge device 230. The use of actors and intra-process messaging allows for a high level of modularity in code development and maintenance, superior performance due to zero overhead in interactions between components since they are all part of the same process, and protection from malfunction of any component. Typically, a failure or bug in a software component of a process leads to a crash of the entire process. The actor model allows the system to contain failures within individual actors, thereby protecting the process from failures. This mechanism ultimately provides near 100% uptime and resilience from misbehaving components / actors in the process.

[0026] The remote source 240 may provide updates for the secure element 320 via the network connection 280. For example, the firmware of the first secure element 320 may be updated via a security enclave, such as a trusted execution environment, implemented by the processing element 310. In such a case, the security enclave may execute applications that utilize crypto support and provide isolation from the overall computing environment. In some implementations, the security enclave implemented by the processing element 310 includes symmetric or asymmetric key material used by the security enclave to communicate with another device. The cryptographic processes and techniques used by the security enclave to communicate with multiple devices are different from the cryptographic processes implemented by the multiple secure elements of the gateway 220.

[0027] The number of secure elements 320 may be less than the number of edge devices 230 served by the secure elements 320. This may be advantageous when not all edge devices 230 are expected to be active at the same time. Furthermore, this facilitates the ability to interleave requests to one secure element. In some examples, one secure element actor may be associated with two edge device actors. Even if the two edge device actors are active at the same time, the two edge device actors may be in different communication stages. Requests from each edge device actor may be interleaved to a single secure element actor. For example, a transaction may include several command-response pairs between an edge device and a secure element. By the time the secure element returns a response to a particular command from a first edge device, the controller may receive a different command from a second edge device. In this situation, interleaving communications from the two edge devices allows for efficient use of a single secure element.

[0028] In examples where the secure element 320 is located on a sister board that is physically separable from the controller 250, it may be desirable to authenticate the sister board when it is plugged or otherwise connected to the controller 250. To accomplish this, the controller 250 may include an additional secure element that is embedded in the controller 250 and has the functionality to both authenticate the array of secure elements 320 and verify policy compatibility with an individual controller 250. In another embodiment, rather than including an embedded secure element on the controller 250, a secure enclave provided by a microprocessor may be used.

[0029] FIG. 4A illustrates an exemplary workflow for authenticating an array of secure elements 320 by the controller 250. In one example, the enclave secure element or embedded secure element of the controller 250 includes an asymmetric key pair with a signed root digital certificate. Having the signed digital certificate allows the enclave secure element or embedded secure element in the controller 250 to send a random number to the secure array of secure elements. The secure element 320 in the array then sends back the signed random number along with the certificate used by the secure element 320. Note that each secure element in the array has a different certificate and key, but all certificates have the same parent (root) certificate. The enclave secure element or embedded secure element in the controller 250 then verifies the signature of the random number as well as the certificate of the secure element 320. This process, which is similar to a public key infrastructure (PKI), can be used by the controller 250 to authenticate the secure element 320. This process may be run when a sister board is connected to the controller and then run again, or alternatively at random intervals, for example to protect against vulnerabilities caused by man-in-the-middle attacks.

[0030] Although the above process only verifies the authenticity of the sister board, it may also be desired for the sister board to authenticate the controller 250 and / or the system policy. FIG. 4B shows an example workflow for authenticating the policy and / or the controller 250 by the sister board of the secure element 320. The policy may be authenticated with the assistance of one or more remote devices 240. The enclave secure element or embedded secure element in the controller 250 may authenticate with the remote device 240 and obtain a signed cryptogram that is unique to that controller 250. This signed cryptogram is then sent to the array of secure elements 320 in the sister board. Only if the signature is correct, the secure element 320 will function. In some examples, the secure element may also include the functionality of only parsing the policy and providing some functionality to the controller 250 based on the parsed policy.

[0031] Some PACS systems are connected using a full-duplex connection to communicate between the reader and the PACS controller. However, in some conventional systems, communication between the secure element 320 and the edge device 230 uses a half-duplex connection 290. In these systems, it is desirable to implement a full-duplex communication protocol for the legacy half-duplex connection to ensure the desired user experience. For example, some conventional PACS systems may include an RS-485 connection for the connection 290. In these conventional systems, one of the reader or controller acts as a primary communicator and the other acts as a secondary communicator. To facilitate communication between the edge device 230 and the secure element 320, a full-duplex protocol may be implemented for the half-duplex connection such that all devices may act as primary communicators.

[0032] The full-duplex protocol can be designed such that the protocol can be used on common universal asynchronous receiver-transmitter (UART) hardware present in modern microcontrollers without requiring hardware modifications to existing devices. Along with resolving data collisions, the protocol helps to mitigate data corruption that can occur due to noisy or otherwise poor quality RS-485 lines. The protocol is intended to be used in conjunction with higher level protocols without imposing significant restrictions on them. In the open systems interconnection (OSI) model, the protocol can be implemented at the data link layer. All data transmitted by the sender is acknowledged by the receiver. If the proper acknowledgement is not received in time by the sender, the protocol incorporates a collision resolution algorithm that results in successful data delivery, as described with respect to FIG. 6.

[0033] 5A-5C are diagrams illustrating exemplary data frame formats for a full-duplex protocol for use in a half-duplex system. FIG. 5A illustrates a data frame 500 used to communicate data over a half-duplex connection. Data frame 500 is shown as including 37 bytes, but may include any number of bytes. Data frame 500 includes an option byte (FIG. 5B), a data payload, and a 4-byte cyclic redundancy check (CRC). Although illustrated as 32 bytes, data frame 500 may be configured to have a data payload of any size. The CRC may be used to detect errors in the transmission of the data in data frame 500.

[0034] FIG. 5B illustrates an exemplary options field 510 for a data frame 500. The options field 510 includes an error indicator bit, six bits that are reserved for future use (RFU), and a toggle bit. The RFU bit may be assigned for any purpose. The error indicator is a single bit that indicates an error in the transmission protocol. If set to 0, the frame transfers data. If set to 1, the frame indicates that a critical error has occurred on a device, such as the edge device 230, and other devices, such as the controller 250, need to act accordingly. The error indication may be used in addition to error detection at a higher level layer than the protocol is implemented. The toggle bit is used when transmitting a data frame and is toggled for every successive frame. The toggle bit is used to distinguish between two successive frames with the same data and a retransmission of a single frame.

[0035] 5C illustrates an exemplary acknowledgment frame 520 provided by the receiver when a data frame is successfully received from the sender. In this example, the acknowledgment frame includes a CRC field that is a copy of the CRC frame of the data frame 500. Although shown as using a CRC for the acknowledgment frame 520, any data may be used for the acknowledgment that allows the sender to verify with reasonable certainty that the data frame 500 was received by the receiver. For example, any bit pattern that associates an acknowledgment with the data frame 500 and is large enough and random enough so that the probability of random noise or a corrupted frame being identified as a valid acknowledgment is very small.

[0036] In implementing the communication protocol, two different roles may be statically assigned to the two devices as role "A" and role "B". For example, the controller 250 may be assigned role "A" and the edge device 230 may be assigned role "B". The baud rate, the number of stop bits used, and the bit order may be pre-agreed between the devices. An estimated time unit (ETU) value for the protocol may also be defined. The ETU value may generally be chosen to be greater than the time required to transmit a data frame 500 and receive an acknowledgment frame 520 with some additional margin. For example, for a baud rate of 115200 bits per second (bps), a value of 5 milliseconds may be used.

[0037] FIG. 6 is a flow chart illustrating a method 600 for transmitting data according to a full-duplex protocol over a half-duplex connection. When transmitting a data frame 500, the device must wait until the line is idle. When the line is idle, the data frame is transmitted with a specified number of bytes. When receiving a frame, the specified number of bytes is received and then the device waits for the line to become idle. When idle, both nodes are in receive mode (step 602) and waiting to receive data. Once received, the CRC of the received data frame 500 is checked. If the CRC is not correct, the node starts receiving another data frame. If the CRC is correct, the node sends a corresponding acknowledgement and starts receiving another data frame. When a new data frame is received, it is checked whether the CRC of the frame is equal to the CRC of the last received frame. If they match, the frame is considered a duplicate and is not reported to the upper layers. An acknowledgement is also sent for duplicate frames.

[0038] When transmitting the data frame 500, in step 604 the device stops the receive mode. In step 606 the data frame 500 is transmitted using the specified number of bytes. Following transmission of the data frame 500 the device waits until an acknowledgment is received (step 608) or the ETU expires (step 610). If the ETU expires before receiving an acknowledgment, the method 600 proceeds to step 614. If the acknowledgment is successfully received, the method 600 proceeds to step 612 and checks the CRC of the acknowledgment frame 520. If the CRC does not match that of the transmitted data frame 500, the method 600 proceeds to step 614. If the CRCs match, the data frame 500 is successfully transmitted and the method returns to step 602 and the device re-enters the receive mode. In step 614 the role of the device is checked. If the device is a role "A" device, the method 600 proceeds to step 606 and retransmits the data frame 500. If the device is a role "B" device, the device proceeds to step 616 and enters a receive mode for two ETUs to minimize collisions on the line, then returns to step 606 to retransmit the data frame 500. The method 600 provides a full-duplex protocol with collision resolution for use on a half-duplex line.

[0039] FIG. 7 illustrates a block diagram of an example machine 700 on which any one or more of the techniques (e.g., methods) described herein may be performed. For example, the machine 700 may be any one or more of the edge device 230, the controller 250, or the secure element 270. Examples may include or operate by a logical component or several components or mechanisms within the machine 700 as described herein. Circuitry (e.g., processing circuitry) is a collection of circuits embodied in a tangible entity of the machine 700 that includes hardware (e.g., simple circuits, gates, logic, etc.). Elements of the circuitry may flexibly change over time. Circuitry includes components that may perform specified operations alone or in combination when operating. In one example, the hardware of the circuitry may be invariably designed (e.g., hardwired, etc.) to perform specific operations. In one example, the hardware of the circuitry may include variably connected physical components (e.g., execution units, transistors, simple circuits, etc.) that include machine-readable media that have been physically altered (e.g., magnetically, electrically, movable arrangements of immutable mass particles, etc.) to encode instructions for a particular operation. In connecting the physical components, the underlying electrical properties of the hardware construct change, e.g., from insulator to conductor (or vice versa). The instructions enable the embedded hardware (e.g., execution units or loading mechanisms) to create elements of the circuitry in the hardware through the variable connections to perform some of the particular operations when in operation. Thus, in one example, the machine-readable media elements are part of the circuitry or are communicatively connected to other components of the circuitry when the device is in operation. In one example, any of the physical components may be used in two or more elements of two or more circuitry. For example, during operation, an execution unit may be used in a first circuit of a first circuitry at one time and reused by a second circuit of the first circuitry or used by a third circuit of the second circuitry at a different time. Additional examples of these components with respect to machine 700 are given below.

[0040] In alternative embodiments, machine 700 may operate as a standalone device or may be connected (e.g., networked) to other machines. In a networked configuration, machine 700 may operate as a server machine, a client machine, or both in a server-client network environment. In one example, machine 700 may operate as a peer machine in a peer-to-peer (P2P) (or other distributed) network environment. Machine 700 may be a personal computer (PC), tablet PC, set-top box (STB), personal digital assistant (PDA), mobile phone, web appliance, network router, switch or bridge, or any machine capable of executing instructions (sequential or otherwise) that specify operations to be performed by the machine. Furthermore, although only a single machine is illustrated, the term "machine" should be construed to include any collection of machines that individually or collectively execute a set (or sets) of instructions to perform any one or more of the methods described herein, such as cloud computing, software as a service (SaaS), other computer cluster configurations, etc.

[0041] The machine (e.g., computer system) 700 may include a hardware processor 702 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), a hardware processor core, or any combination thereof), a main memory 704, a static memory 706 (e.g., memory or storage for firmware, microcode, basic input / output (BIOS), unified extensible firmware interface (UEFI), etc.), and mass storage 708 (e.g., hard drive, tape drive, flash storage, or other block device), some or all of which may communicate with each other via an interlink (e.g., bus) 730. The machine 700 may further include a display unit 710, an alphanumeric input device 712 (e.g., a keyboard), and a user interface (UI) navigation device 714 (e.g., a mouse). In one example, the display unit 710, the input device 712, and the UI navigation device 714 may be touch screen displays. The machine 700 may further include a storage device 708 (e.g., a drive unit), a signal generation device 718 (e.g., a speaker), a network interface device 720, one or more sensors 716, such as a Global Positioning System (GPS) sensor, a compass, an accelerometer, or other sensor. The machine 700 may include an output controller 728, such as a serial (e.g., Universal Serial Bus (USB)), parallel, or other wired or wireless (e.g., infrared (IR), near field communication (NFC), etc.) connection, for communicating with or controlling one or more peripheral devices (e.g., a printer, a card reader, etc.).

[0042] The registers of the processor 702, the main memory 704, the static memory 706, or the mass storage 708 may be or include a machine-readable medium 722 on which is stored one or more sets of data structures or instructions 724 (e.g., software) that embody or are utilized by any one or more of the techniques or functions described herein. The instructions 724 may also reside, completely or at least partially, within any of the registers of the processor 702, the main memory 704, the static memory 706, or the mass storage 708 during its execution by the machine 700. In one example, one or any combination of the hardware processor 702, the main memory 704, the static memory 706, or the mass storage 708 may constitute the machine-readable medium 722. Although the machine-readable medium 722 is illustrated as a single medium, the term "machine-readable medium" may include a single medium or multiple media (e.g., a centralized or distributed database, and / or associated caches and servers) configured to store one or more instructions 724.

[0043] The term "machine-readable medium" may include any medium capable of storing, encoding, or carrying instructions for execution by the machine 700 and enabling the machine 700 to perform any one or more of the techniques of this disclosure, or storing, encoding, or carrying data structures used by or associated with such instructions. Non-limiting examples of machine-readable media may include solid-state memory, optical media, magnetic media, and signals (e.g., radio frequency signals, other photon-based signals, audio signals, etc.). In one example, a non-transitory machine-readable medium includes a machine-readable medium having a plurality of particles having a fixed (e.g., stationary) mass, and thus is a composition of matter. Thus, a non-transitory machine-readable medium is a machine-readable medium that does not include a transitory propagating signal. Examples of non-transitory machine-readable media may include non-volatile memory such as semiconductor memory devices (e.g., electrically programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM)) and flash memory devices, magnetic disks such as internal hard disks and removable disks, magneto-optical disks, and CD-ROM disks and DVD-ROM disks.

[0044] The instructions 724 may further be transmitted or received over a communications network 726 using a transmission medium via a network interface device 720 utilizing any one of a number of transport protocols (e.g., Frame Relay, Internet Protocol (IP), Transmission Control Protocol (TCP), User Datagram Protocol (UDP), Hypertext Transfer Protocol (HTTP), etc.). Exemplary communications networks may include local area networks (LANs), wide area networks (WANs), packet data networks (e.g., the Internet), mobile phone networks (e.g., cellular networks), plain old telephone (POTS) networks, and wireless data networks (e.g., the Institute of Electrical and Electronics Engineers (IEEE) 802.11 family of standards known as Wi-Fi), the IEEE 802.16.4 family of standards, peer-to-peer (P2P) networks, among others. In one example, the network interface device 720 may include one or more physical jacks (e.g., Ethernet, coaxial, or telephone jacks) or one or more antennas for connecting to the communications network 726. In one example, the network interface device 720 may include multiple antennas for wireless communication using at least one of single-input multiple-output (SIMO), multiple-input multiple-output (MIMO), or multiple-input single-output (MISO) techniques. The term "transmission medium" is intended to include any intangible medium capable of storing, encoding, or carrying instructions for execution by the machine 700, as well as digital or analog communication signals or other intangible media for enabling communication of such software. Transmission media are machine-readable media.

[0045] The above description includes references to the accompanying drawings, which form a part of the detailed description. The drawings show, for illustrative purposes, specific embodiments in which the invention may be practiced. These embodiments are also referred to herein as "examples." Such examples may include elements in addition to those shown or described. However, the inventors also contemplate examples in which only the elements shown or described are provided. Furthermore, the inventors also contemplate examples that use any combination or permutation of the elements shown or described (or one or more aspects thereof) with respect to a particular example (or one or more aspects thereof) or with respect to other examples (or one or more aspects thereof) shown or described herein.

[0046] In this specification, the term "or" is used to mean non-exclusive unless otherwise indicated, or "A or B" includes "B but not A," "A but not B," and "A and B." The Abstract is provided for the purpose of enabling the reader to quickly ascertain the contents of the technical disclosure. The Abstract is provided with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. Also, in the above detailed description, various features may be grouped together to streamline the disclosure. This should not be construed as intending that an unclaimed disclosed feature is essential to any claim. Rather, the subject matter of the invention may reside in less than all features of a particular disclosed embodiment. Thus, the appended aspects are incorporated into the detailed description herein as examples or embodiments, with each aspect standing on its own as a separate embodiment, and it is contemplated that such embodiments can be combined with each other in various combinations or permutations. The scope of the present invention should be determined with reference to the appended aspects, along with the full scope of equivalents to which such aspects are entitled.

Claims

[Claim 1] The invention described in the specification.

Images