Multi-modal encrypted messaging system

A multi-modal encrypted messaging platform to provide HIPAA compliant messaging and interfaces to provide access to electronic data records. The proposed invention discloses example embodiments that comprise a server-system, a client device in communication with the server-system, and an auxiliary device coupled to the client device.

TECHNICAL FIELD

The present invention relates to encrypted messaging systems.

BACKGROUND

The Health Insurance Portability and Accountability Act (HIPAA), as well as a number of other compliance standards, exist to define and provide communication and privacy rules and definitions for various fields and industries. Such compliance standards seek to allow for the modernization of the flow of information, while addressing the potential of fraud, theft, and privacy.

For example, HIPAA set out strict requirements for the control and transmission of electronic medical data over networks, wherein the transfer of such data must be encrypted if transferred over an open network, or alternatively, much be accessed and transferred on a closed and secured system or network, if the data is to remain un-encrypted. HIPAA therefore benefits patients and doctors alike, by providing requirements to ensure the privacy and security of medical information.

A system to provide a platform to facilitate access to electronic medical data, while maintaining full compliance to HIPAA requirement would therefore prove to be a beneficial improvement in existing messaging technologies.

DETAILED DESCRIPTION

Reference will now be made in detail to specific example embodiments for carrying out the inventive subject matter. Embodiments may be practiced without some or all of these details. It will be understood that the forgoing disclosure is not intended to limit the scope of the claims to the described embodiments. On the contrary, it is intended to cover alternatives, modifications, and equivalents as may be included within the scope of the disclosure as defined by the appended claims. In addition, well known features may not have been described in detail to avoid unnecessarily obscuring the subject matter.

Disclosed embodiments discuss systems and methods for a multi-modal encrypted messaging platform to provide HIPAA compliant messaging and interfaces to provide access to electronic data records. The proposed invention discloses example embodiments that comprise a server-system, a client device in communication with the server-system, and an auxiliary device coupled to the client device. As used herein, “coupled to” generally refers to a connection between components, which can be an indirect communicative connection or direct communicative connection (e.g., without intervening components), whether wired or wireless, including connections such as electrical, optical, magnetic, etc.

According to certain embodiments, the system is configured to perform operations that include: receiving a request at a server system, wherein the request includes a set of request attributes that include a user or device identifier; generating an encryption key in response to the receiving the request, wherein the encryption key may be generated based on at least a portion of the request attributes; assigning the encryption key to a request instance associated with the request at a user account identified by the user or device identifier; encrypting a data record based on the encryption key responsive to the request; and communicating a presentation of the encrypted data record to the client device associated with the user account, whereby the client device may decrypt the encrypted data record based on the encryption key.

The system may employ a Diffie-Hellman key exchange protocol, wherein a public portion of the encryption key is generated in response to requests received at the server-system from one or more client devices. Responsive to generating an encryption key based on request attributes of a request, the system may be configured to transmit the public portion of the encryption key to an auxiliary device coupled with the client device. In some embodiments, transmitting the public portion of the encryption key may include transmitting the public portion of the encryption key through a specific communication channel specified by a preselected frequency (e.g., in the VHF or UHF bands). The client device may thereby retrieve the public portion of the encryption key from the auxiliary device to decrypt the data record.

From a user perspective, a user of a client device may generate and provide a request to a server system, wherein the request comprises an identification of a data record stored within the server system. Responsive to receiving the request to access the data record at the server system, the system parses the request to extract a set of request attributes that may include a user identifier associated with the client device. The system applies one or more encryption protocols, including but not limited to a Diffie-Hellman key exchange protocol, to generate an encryption key, and delivers the encryption key to an auxiliary device coupled to the client device, where the encryption key is indexed and stored at a memory location corresponding with the request instance. The system may then encrypt the data object, and either save a copy of the encrypted data object at a memory location at the server system, or deliver the encrypted data object to the client device itself

In some example embodiments, administrators may assign access restrictions and criteria to data records, such that the access restrictions and criteria define rules and credentials to access the data record. For example, in such embodiments, the data records may include reference identifiers, and the system may perform operations that include: retrieving access restrictions associated with the data record from a repository based on the reference identifier that identifies the data record, wherein the access restriction includes at least a condition; applying the access restriction to the encryption key at the request instance associated with a request to access the data record at the user account identified by the user identifier; detecting an occurrence of the condition; and denying subsequent requests to access the data record from the client device.

For example, the access condition may include one or more of: temporal constraints that define periods of time that the data record may be accessed or viewed; user attributes required to receive access to the data record; certain security credentials; as well as geo-location conditions. The system may thereby manage access to each data record based on the associated access conditions of the data record.

In some embodiments, to remove access to a data record for a client device, the system deletes the encryption key from the request instance within the user account identified by the user identifier, in response to detecting (or detecting an absence of) the one or more access conditions associated with a given data record.

As an illustrative example from a user perspective, a user may provide an input that comprises a request for a data record via an interface presented at a client device. The request to access the data record may include contextual data that includes one or more of a user identifier associated with the user, an identification of the requested data record, device information (i.e., MAC addresses, specific hardware codes, RFID code), biometric data, time and date information, geolocation information, barometric pressure, acceleration and device orientation, as well as compass positioning.

Responsive to receiving the request to access the data record, the system generates an encryption key based on at least a portion of the contextual data from the request to access the data record. By utilizing a diverse pool of contextual data, a much stronger encryption key may be generated. For example, in certain embodiments, the system may apply a predefined hash function to a portion of the contextual data in order to generate the encryption key.

As discussed above, the encryption key may be generated using a Diffie-Hellman key-exchange, whereby the system and the client device maintain corresponding sets of private variables and utilize a public variable to generate and exchange encryption keys. The system may then assign the encryption key to a request instance associated with the request to access the data record, at a user account identified by the user identifier at a database of the system and transmit the encryption key to the auxiliary device coupled with the client device.

The system may then encrypt the data record using the encryption key assigned to the request instance from the user account identified by the user identifier and communicate the encrypted data record to the client device. The client device may then receive the encrypted data record and access the auxiliary device to retrieve the corresponding encryption key. Responsive to retrieving the encryption key from the auxiliary device, the client device may cause display of a presentation of the data record. The data record is therefore encrypted before and during transmission, maintaining full HIPAA compliance.

As discussed above, in certain instances, the data records may include an associated set of access conditions or restrictions. For example, a data record may be assigned certain access conditions that limit or restrict access to the data record to users/devices located within a defined geo-fence, as well as certain temporal constraints that limit access to the data record to a period of time, time of day, or duration of event. Responsive to detecting (or detecting an absence of) one or more of the above conditions, the system deletes the encryption key at the request instance associated with the request to access the data record within the user account identified by the user identifier. Subsequent requests to access or view the data record may thereby be denied.

In some embodiments, communications to the auxiliary device from the server-system may be transmitted in a specified band of the radio spectrum, including the Very High Frequency (VHF), and in some instances Ultra High Frequency (UHF) bands. VHF, and in some instances, UHF, bands of the radio spectrum offer higher signal penetration and range that higher frequency bands typically used in Wi-Fi and cellular networks. Accordingly, communications between the server-system and the auxiliary device may be sent using 4-bit Binary-coded decimal (BCD) values, as well as 7-bit American Standard Code for Information Interchange (ASCII). Communications to the auxiliary device may therefore be encoded at the server-system based on the frequency relied upon, which may in some embodiments be variable based on attributes of the requests from the client device.

FIG. 1is an example embodiment of a high-level client-server-based network architecture100. A networked system102, in the example form of a pager network, provides server-side functionality via a network104(e.g., the Internet or wide area network (WAN), Bluetooth) to one or more client devices110.FIG. 1illustrates, for example, a web client112(e.g., a browser, such as the Internet Explorer® browser developed by Microsoft® Corporation of Redmond, Wash. State), client application(s)114, and an enhanced paging application116executing on the client device110.

The client device110may comprise, but is not limited to, a wearable device, mobile phone, desktop computer, laptop, portable digital assistant (PDA), smart phone, tablet, ultra-book, netbook, laptop, multi-processor system, microprocessor-based or programmable consumer electronics, game console, set-top box, or any other communication device that a user may utilize to access the networked system102. In some embodiments, the client device110comprises a display module (not shown) to display information (e.g., in the form of user interfaces). In further embodiments, the client device110comprises one or more of touch screens, accelerometers, gyroscopes, cameras, microphones, global positioning system (GPS) devices, and so forth. The client device110may be a device of a user configured to facilitate communication within the networked system102. One or more portions of the network104may be an ad hoc network, an intranet, an extranet, a virtual private network (VPN), a local area network (LAN), a wireless LAN (WLAN), a wide area network (WAN), a wireless WAN (WWAN), a metropolitan area network (MAN), a portion of the Internet, a portion of the public switched telephone network (PSTN), a cellular telephone network, a wireless network, a WiFi network, a WiMax network, a Wireless Mesh Network (WMN), or a combination of two or more such networks.

The client device110may include one or more client applications114(also referred to as “apps”) such as, but not limited to, a web browser, messaging application, electronic mail (email) application, a navigation application, and the like. In some embodiments, the client application(s)114is configured to locally provide the user interface and at least some of the functionalities with the client application(s)114configured to communicate with the networked system102, on an as needed basis, for data or processing capabilities not locally available (e.g., access to a database of items available for sale, to authenticate a user, to verify a method of payment). Conversely, the client device110may use its web browser to access data hosted on the networked system102to generate and provide various user interfaces.

One or more users106may be a person, a machine, or other means of interacting with the client device110. In example embodiments, the user106is not part of the network architecture100, but may interact with the network architecture100via the client device110or other means. For instance, the user106provides input (e.g., touch screen input, alphanumeric input, text-to-speech, or speech-to-text) to the client device110and the input is communicated to the networked system102via the network104. In this instance, the networked system102, in response to receiving the input from the user106, communicates information to the client device110via the network104to be presented to the user106. In this way, the user106can interact with the networked system102using the client device110.

An application program interface (API) server120and a web server122are coupled to, and provide programmatic and web interfaces respectively to, one or more application servers140. The application server(s)140may host an encrypted messaging system150, for providing encrypted communications between an application server140(e.g., a server system), and the client device110. For example, the encrypted messaging system150may generate encryption keys in response to requests from the client device110and transmit the encryption keys, or portions of the encryption keys, to an auxiliary device (e.g., the pager module130) coupled to the client device110. The client device110may then access the pager module130to retrieve the appropriate encryption keys received from the encrypted messaging system150. For example, in some embodiments, the pager module130may include one or more memory components to host a key table160, wherein the key table160is configured to maintain a list of encryption keys, which may be sorted or labeled based on a request instance, or an identifier of a data object (e.g., a message, media content, etc.). In such embodiments, the client device110may access the key table160of the pager module130to retrieve an encryption key that corresponds with an encrypted data object accessed by the client device110.

While the client-server-based network architecture100shown inFIG. 1employs a client-server architecture, the present inventive subject matter is of course not limited to such an architecture, and could equally well find application in a distributed, or peer-to-peer, architecture system, for example. The encrypted messaging system150could also be implemented as standalone software programs, which do not necessarily have networking capabilities.

The web client112may access the various publication and payment systems142and144via the web interface supported by the web server122. Similarly, the enhanced paging application116accesses the various services and functions provided by the encrypted messaging system150via the programmatic interface provided by the API server120. The enhanced paging application116may, for example, generate and cause display of notifications in response to receiving message data from an associated pager module130.

FIG. 2is a block diagram illustrating components of the encrypted messaging system150that configure the encrypted messaging system150to receive a request to access a data object from a client device110, generate an encryption key in response to the request to access the data object, identify an auxiliary device (e.g., the pager module130) associated (i.e., coupled with) the client device110, transmit the encryption key or a portion of the encryption key to the pager module130, encrypt the data object based on the encryption key (i.e., at the networked system102), and communicate the encrypted data object to the client device110, according to certain example embodiments. The encrypted messaging system150is shown as including a communication module202, an encryption module204, and a presentation module206, all configured to communicate with each other (e.g., via a bus, shared memory, or a switch). Any one or more of these modules may be implemented using one or more processors210(e.g., by configuring such one or more processors210to perform functions described for that module) and hence may include one or more of the processors210. In some embodiments, the modules of the encrypted messaging system150may be in coupled with the databases126.

Any one or more of the modules described may be implemented using hardware alone (e.g., one or more of the processors210of a machine) or a combination of hardware and software. For example, any module described of the encrypted messaging system150may physically include an arrangement of one or more of the processors210(e.g., a subset of or among the one or more processors of the machine) configured to perform the operations described herein for that module. As another example, any module of the encrypted messaging system150may include software, hardware, or both, that configure an arrangement of one or more processors210(e.g., among the one or more processors of the machine) to perform the operations described herein for that module. Accordingly, different modules of the encrypted messaging system150may include and configure different arrangements of such processors210or a single arrangement of such processors210at different points in time. Moreover, any two or more modules of the encrypted messaging system150may be combined into a single module, and the functions described herein for a single module may be subdivided among multiple modules. Furthermore, according to various example embodiments, modules described herein as being implemented within a single machine, database, or device may be distributed across multiple machines, databases, or devices.

FIG. 3is a flowchart illustrating operations of the encrypted messaging system150in performing a method300of encrypting a data object, according to some example embodiments.

At operation302, the communication module202receives a request to access a data object. The request may include an identification of a client device110, and request data that includes one or more data objects that may include references to media content and message data. For example, the request may be received from the client device110itself, or from a third-party device or system in communication with the networked system102.

At operation304, the encryption module204generates one or more encryption keys in response to receiving the request, based on contextual data of the request. For example, as discussed above, the contextual data includes one or more of a user identifier, an identification of the requested data record, device information (i.e., MAC addresses, specific hardware codes, RFID code), biometric data, time and date information, geolocation information, barometric pressure, acceleration and device orientation, as well as compass positioning.

In some embodiments, the encryption module204may generate a single encryption key responsive to a request, while in further embodiments, the encryption module204generates a plurality of encryption keys. By doing so, a single communication exchange may provide a batch of future keys. For example, by providing a plurality of keys, data transfers for the purposes of key exchanges can be limited, thereby reducing the number of communications necessary, and data usage. The plurality of keys may be used in the case of communication loss.

In some embodiments, the encryption module204may generate the one or more encryption keys based on a Diffie-Hellman key exchange protocol, wherein one or more variables to generate the encryption key may be selected based on one or more attributes of the request or the client device110.

In some embodiments, the encryption module204may define a request instance within the database126in response to receiving the request to access the data object, wherein the request instance comprises an identifier of the client device, an identification of the data object, and a record of the one or more encryption keys generated in response to the request, along with a sequence of the one or more encryption keys, such that as a first encryption key expires, a second encryption key may be selected based on the sequence.

At operation306, the communication module202identifies an auxiliary device (i.e., the pager module130) in response to the encryption module204generating the one or more encryption keys responsive to the request to access the data object. For example, the pager module130may be coupled with the client device110via one or more coupling methods that include NFC or Bluetooth, and wherein a record of the coupling of the client device110and the pager module130may be indexed and stored within a memory repository within the database126.

In some embodiments, responsive to identifying the auxiliary device coupled with the client device110, the encryption module204may update the request instance stored at the database126associated with the request from the client device110, to include an identifier of the auxiliary device.

At operation308, the communication module202transmits the one or more encryption keys, or a portion of the one or more encryption keys, to the auxiliary device coupled with the client device110. In certain embodiments, the communication module202may transmit the one or more encryption keys or a portion of the one or more encryption keys to the auxiliary device via a specific range of radio frequency that the auxiliary device is specially configured to recognize and communicate through. In some embodiments the communication module202may communicate with the auxiliary device via one or more protocols that include a Simple Network Paging Protocol (SNPP), a Telelocator Alphanumeric Protocol (TAP), FLEX, ReFLEX, Post Office Code Standardisation Advisory Group (POCSAG), GOLAY, Enhanced Radio Messaging System (ERMS), and NTT. For example, the communication module202may transmit the one or more encryption keys to the auxiliary device via a VHF or UHF signal, and wherein the auxiliary device contains one or more antenna(s)406configured to receive and recognize signals in the VHF and UHF frequency range, as depicted inFIG. 4.

At operation310, the encryption module204encrypts the data object based on at least one encryption key form among the one or more encryption keys generated in response to the message to access the data object. For example, a first encryption key from among the one or more encryption keys may be selected based on a sequence of the one or more encryption keys. In some embodiments, responsive to encrypting the data object based on the encryption key, the encryption module204stores a copy of the encrypted data object with the request instance associated with the request from the client device110at the databases126.

At operation312, the presentation module206communicates a presentation of the encrypted data object to the client device110. The client device110may then retrieve the corresponding encryption key associated with the encrypted data object from the auxiliary device to decrypt the data object and display the presentation of the data object.

FIG. 4is a diagram400illustrating various functional components of a pager module130. As seen in the diagram400, the pager module130may comprise a demodulator402, a transmitter404, antenna(s)406, an inductive charging coil408, and a battery410, all enclosed within an enclosure412.

In some example embodiments, the demodulator402includes a Frequency Shift Keying (FSK) Demodulator, configured to transmit digital information (e.g., message data) through discrete frequency changes of a carrier signal.

In some example embodiments, the transmitter404includes a short wave radio frequency transmitter (e.g., Bluetooth), configured to forward message data between the pager module130and a paired client device110.

In some example embodiments the antenna(s)406include any one or a combination of a loop antenna consisting of a loop of wire, and fully enclosed by the enclosure412. In some example embodiments, the antenna(s)406are integrated into a portion of the enclosure412. For example, the enclosure412may comprise multiple components that come together to form the enclosure412. In some embodiments, the antenna(s)406may be molded or formed into one or more of the components of the enclosure412.

In some example embodiments, the antenna(s)406may be formed into a frame that encompasses a perimeter of a surface of the enclosure412.

In some example embodiments, the charging coil408includes one or more exposed charging leads to enable a use to plug the pager module130into an outlet (e.g., USB).

In some example embodiments, the enclosure412is the form of a proximity card, such as a contactless smart card.

FIG. 5is a diagram illustrating various embodiments of a pager module130. As seen inFIG. 5, the enclosure412of the pager module130may include a number of different forms. In some example embodiments, the pager module130itself may comprise a modular unit which may be inserted within a number of distinct enclosures (e.g., the enclosure412ofFIG. 4).

In some example embodiments, the enclosure412that houses the pager module130(as seen inFIG. 4) may include the tethered enclosure502, wherein the tethered enclosure502may be communicatively coupled to the client device110via a cable. In some embodiments, the tethered enclosure502may include an extended battery unit to provide power to both the client device110, as well as the pager module130.

For example, the tethered enclosure502may comprise a metallic, or non-metallic housing that includes a connection port to receive a cable, such as a Universal Serial Bus Type-A (USB A) cable, USB Type-B, Mini-USB, Micro-USB, and USB Type-C. A user106of a client device110may connect the pager module130to the client device110via the tethered enclosure502, through the integrated connection port.

In some example embodiments, the enclosure412that houses the pager module130(as seen inFIG. 6) may include a key-fob504. The key-fob504may comprise a hook or loop to detachably receive a key-ring.

In some example embodiments, the enclosure412that houses the pager module130(as seen inFIG. 4) may include a cell-phone case506, wherein the client device110may be inserted into the cell-phone case506. In further embodiments, the cell-phone case506may include an integrated extended battery that supplies battery power to both the pager module130as well as the client device110.

The cell-phone case506may comprise a semi-flexible housing to enclose a device, such as the client device110, wherein the semi-flexible housing encases the client device110, while exposing a screen of the client device110.

In some example embodiments, the enclosure412that houses the pager module130(as seen inFIG. 6) may include a bi-fold case508, wherein the client device110may be inserted into the bi-fold case508. The bi-fold case508may comprise a housing to encase the client device110, as well as a flap to cover a screen of the client device110.

In some example embodiments, the enclosure412that houses the pager module130(as seen inFIG. 4) may include a band510(e.g., a wrist-band, an arm-band), wherein the band510may be worn by a user106. The band510may comprise a fastener, such as a Velcro strap, an elastic band, buckle, tang buckle, deployment clasp, or pushbutton deployment clasp.

FIG. 6is an interaction diagram600illustrating a flow of data, and various interactions between the encrypted messaging system150, the pager module130, and a client device110, according to some example embodiments.

At operation602, the encrypted messaging system150receives a request. For example, the request may include a message from a third-party, and may include message content, media content, and an identification of the client device110. In further embodiments, the request may be from the client device110to access a data object hosted at a third party media repository, and may include an identification of the third party media repository and an identification of the data object.

At operation604, responsive to receiving the request, the encrypted messaging system generates an encryption key. The encryption key may be generated based on one or more attributes of the client device110, or based on one or more attributes of the pager module130. For example, the user106may provide an input that defines public variables to be used by the encrypted messaging system150to generate an encryption key, and store the public variables at the pager module130.

At operation606, responsive to generating the encryption key, the encrypted messaging system150identifies an auxiliary device coupled with the client device110, based on the request including the identification of the client device110. In some embodiments, the database126may include a reference table that comprises associations between auxiliary devices and client device. The encrypted messaging system150may reference the table and identify an auxiliary device (e.g., the pager module130) associated with the identifier of the client device110.

At operation608, the encrypted messaging system150transmits the encryption key to the pager module130(i.e., the auxiliary device). In certain embodiments, the encrypted messaging system150may transmit the encryption key to the pager module130via a predefined frequency associated with the pager module130. For example, the reference table referenced by the encrypted messaging system150may include an identification of one or more transmission frequencies associated with the pager module130, which may include frequencies in the VHF and UHF bands.

At operation610, the encrypted messaging system150encrypts a data object based on the encryption key. In some embodiments, the encrypted messaging system150may access a third party repository to retrieve the data object, and store an encrypted copy of the data object locally. In further embodiments, the encrypted messaging system150may simply receive the data object (such as a message) and encrypt and store the data object with the databases126.

At operation612, the client device110receives a notification that comprises an identification of the data object. For example, the identification may include a reference to a location of the data object (or copy of the data object) at the encrypted messaging system150.

At operation614, the client device110accesses the pager module130coupled to the client device110to retrieve the encryption key that corresponds with the encrypted data object. For example, in certain embodiments, the pager module130may store a plurality of encryption keys, where each encryption key is associated with a particular request instance, such that the client device110may identify a particular encryption key for a data object based on an identifier of the request instance.

At operation616, the client device110decrypts the data object based on the encryption key and displays a presentation of the decrypted data object. In some embodiments, functionality to decrypt the data object may also reside within the pager module130, such that the pager module130acts as a “decryption tunnel,” to provide encrypted communications between the client device110and the encrypted messaging system150.

Modules, Components and Logic

Electronic Apparatus and System

Example Machine Architecture and Machine-Readable Medium

FIG. 7is a block diagram illustrating components of a machine700, according to some example embodiments, able to read instructions from a machine-readable medium (e.g., a machine-readable storage medium) and perform any one or more of the methodologies discussed herein. Specifically,FIG. 7shows a diagrammatic representation of the machine700in the example form of a computer system, within which instructions716(e.g., software, a program, an application, an applet, an app, or other executable code) for causing the machine700to perform any one or more of the methodologies discussed herein may be executed. Additionally, or alternatively, the instructions may implement the modules ofFIG. 2. The instructions transform the general, non-programmed machine into a specially configured machine programmed to carry out the described and illustrated functions in the manner described. In alternative embodiments, the machine700operates as a standalone device or may be coupled (e.g., networked) to other machines. In a networked deployment, the machine700may operate in the capacity of a server machine or a client machine in a server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment.

The machine700may comprise, but not be limited to, a server computer, a client computer, a personal computer (PC), a tablet computer, a laptop computer, a netbook, a set-top box (STB), a personal digital assistant (PDA), an entertainment media system, a cellular telephone, a smart phone, a mobile device, a wearable device (e.g., a smart watch), a smart home device (e.g., a smart appliance), other smart devices, a web appliance, a network router, a network switch, a network bridge, or any machine capable of executing the instructions716, sequentially or otherwise, that specify actions to be taken by machine700. Further, while only a single machine700is illustrated, the term “machine” shall also be taken to include a collection of machines700that individually or jointly execute the instructions716to perform any one or more of the methodologies discussed herein.

The machine700includes processors710, memory730, and I/O components750, which may be configured to communicate with each other such as via a bus702. In an example embodiment, the processors710(e.g., a Central Processing Unit (CPU), a Reduced Instruction Set Computing (RISC) processor, a Complex Instruction Set Computing (CISC) processor, a Graphics Processing Unit (GPU), a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Radio-Frequency Integrated Circuit (RFIC), another processor, or any suitable combination thereof) may include, for example, processor712and processor714that may execute instructions716. The term “processor” is intended to include multi-core processor that may comprise two or more independent processors (sometimes referred to as “cores”) that may execute instructions contemporaneously. AlthoughFIG. 7shows multiple processors, the machine700may include a single processor with a single core, a single processor with multiple cores (e.g., a multi-core process), multiple processors with a single core, multiple processors with multiples cores, or any combination thereof.

The memory/storage730may include a memory732, such as a main memory, or other memory storage, and a storage unit736, both accessible to the processors710such as via the bus702. The storage unit736and memory732store the instructions716embodying any one or more of the methodologies or functions described herein. The instructions716may also reside, completely or partially, within the memory732, within the storage unit736, within at least one of the processors710(e.g., within the processor's cache memory), or any suitable combination thereof, during execution thereof by the machine700. Accordingly, the memory732, the storage unit736, and the memory of processors710are examples of machine-readable media.

Communication may be implemented using a wide variety of technologies. The I/O components750may include communication components764operable to couple the machine700to a network780or devices770via coupling782and coupling772respectively. For example, the communication components764may include a network interface component or other suitable device to interface with the network780. In further examples, communication components764may include wired communication components, wireless communication components, cellular communication components, Near Field Communication (NFC) components, Bluetooth® components (e.g., Bluetooth® Low Energy), Wi-Fi® components, and other communication components to provide communication via other modalities. The devices770may be another machine or any of a wide variety of peripheral devices (e.g., a peripheral device coupled via a Universal Serial Bus (USB)).

Transmission Medium

The instructions716may be transmitted or received over the network780using a transmission medium via a network interface device (e.g., a network interface component included in the communication components764) and utilizing any one of a number of well-known transfer protocols (e.g., hypertext transfer protocol (HTTP)). Similarly, the instructions716may be transmitted or received using a transmission medium via the coupling772(e.g., a peer-to-peer coupling) to devices770. The term “transmission medium” shall be taken to include any intangible medium that is capable of storing, encoding, or carrying instructions716for execution by the machine700, and includes digital or analog communications signals or other intangible medium to facilitate communication of such software.

Language