WO2016102408A1

WO2016102408A1 - Pos terminal and systems for interfacing with a wearable device

Info

Publication number: WO2016102408A1
Application number: PCT/EP2015/080682
Authority: WO
Inventors: John Cronin; Christopher Michael HUFFINES
Original assignee: Koninklijke Philips N.V.
Priority date: 2014-12-22
Filing date: 2015-12-18
Publication date: 2016-06-30

Abstract

Various embodiments descried herein relate to a merchant device, such as a point-of-sale device, and related method and machine-readable medium including: a short- range wireless communication interface; a network interface for communicating via a network; a display device; a memory; and a processor configured to: process transactions with customers; receive a token-rule identifying sensor criteria and a token specifying at least one effect on the processing of a transaction; store the token-rule; receive, via the short-range wireless communication from a wearable device, sensor data that includes at least one physiological parameter descriptive of the user of the wearable device; compare the sensor criteria to the received at least one physiological parameter to determine whether the token- rule is currently applicable; and based on the token-rule being applicable, apply the effect to a current transaction of the merchant POS device.

Description

POS TERMINAL AND SYSTEMS FOR INTERFACING WITH A WEARABLE

DEVICE

TECHNICAL FIELD

Various embodiments described herein relate to a wearable device communicating with a point of sale terminal or other devices. More specifically, but not exclusively, various embodiments relate to a point of sale terminal utilizing physiological data retrieved from a wearable device. BACKGROUND

Wearable technology is a new class of electronic systems that can provide data acquisition through a variety of unobtrusive sensors that may be worn by a user. The sensors gather information, for example, about the environment, the user's activity, or the user's health status. However, there are significant challenges related to the coordination, computation, communication, privacy, security, and presentation of the collected data.

Additionally, there are challenges related to power management given the current state of battery technology. Furthermore, analysis of the data is needed to make the data gathered by the sensors useful and relevant to end-users. In some cases, additional sources of information may be used to supplement the data gathered by the sensors. The many challenges that wearable technology presents require new designs in hardware and software.

Presently available electronic sensors coupled to a wearable device are used to collect and manipulate sensed data. In such wearable devices, the sensor data may be stored in memory, and a processor running an algorithm may identify patterns in the data. Near field data communications (NFC), in turn, are currently being used by consumers to make secure financial transactions when purchasing goods or services. NFC is a standardized wireless data communication technology that communicates information over short distances.

SUMMARY

Various embodiments disclosed herein aim at providing an improved architecture for enabling merchant devices, such as point-of-sale (POS) devices, to obtain and make use of physiological data obtained by a customer's wearable device(s) through, for example, providing a token offer to a user. Existing wearable devices do not trigger a token offering associated with a wearable device when the wearable device has been identified by a point of sale terminal using NFC data communications, other short range wireless communications, or other communications.

Various embodiments described herein relate to a point-of-sale (POS) device including: a short-range wireless communication interface; a network interface for communicating via a network; a display device; a memory; and a processor configured to: process transactions with customers; receive, via the network interface from a token server, a token-rule associated with the merchant, the token-rule identifying sensor criteria and a token specifying at least one effect on the processing of a transaction when the token-rule is applicable; store the token-rule in the memory after receipt for later evaluation; receive, via the short-range wireless communication from a wearable device worn by a nearby user, sensor data gathered by the wearable device, wherein the sensor data includes at least one physiological parameter descriptive of the user of the wearable device; compare the sensor criteria to the received at least one physiological parameter to determine whether the token- rule is currently applicable to the user; and based on a determination that the token-rule is applicable, apply the effect to a current transaction of the merchant POS device with respect to the user.

Various embodiments described herein relate to a method for interfacing a merchant point-of-sale (POS) device with a wearable device, the method including:

receiving, at the merchant POS device from a token server, a token-rule associated with the merchant, the token-rule identifying sensor criteria and a token specifying at least one effect on the merchant POS device when the token-rule is applicable; receiving, at the merchant POS device from the wearable device via short-range wireless communication, sensor data gathered by the wearable device, wherein the sensor data includes at least one physiological parameter descriptive of the user of the wearable device; comparing the sensor criteria to the received at least one physiological parameter to determine whether the token-rule is currently applicable to the user; and based on a determination that the token-rule is applicable applying the effect to a current operation of the merchant POS device with respect to the user.

Various embodiments described herein relate to a non-transitory machine- readable storage medium encoded with instructions for execution by a merchant device, the non-transitory machine-readable storage medium including: instructions for receiving a token-rule associated with the merchant, the token-rule identifying sensor criteria and a token specifying at least one effect on a transaction with a customer when the token-rule is applicable; instructions for receiving, at the merchant device from the wearable device via short-range wireless communication, sensor data gathered by the wearable device, wherein the sensor data includes at least one physiological parameter descriptive of the user of the wearable device; instructions for comparing the sensor criteria to the received at least one physiological parameter to determine whether the token-rule is currently applicable to the user; and instructions for, based on a determination that the token-rule is applicable applying the effect to a current transaction of the merchant with respect to the user.

Various embodiments are described wherein the processor is further configured to: in displaying the explanation of the at least one effect of the token to the user, prompt the user for input accepting or rejecting the effect; and perform the step of applying the effect is performed in response to the user accepting the effect.

Various embodiments are described wherein the processor is further configured to: in displaying the explanation of the at least one effect of the token to the user, prompt the user for input as to whether to apply the effect immediately; and in response to the user declining to apply the effect immediately, transmit the token via the short-range wireless communication to at least one of the wearable device and a user device of the user.

Various embodiments are described wherein the processor is further configured to, prior to receiving sensor data: transmit, to the wearable device via the short- range wireless communication, a request to read sensor data and an identifier of at least one of the merchant device and the merchant.

Various embodiments are described wherein the token is a coupon token and, in applying the effect, the processor is configured to apply a discount defined by the coupon token to a current transaction of the user.

Various embodiments are described wherein the token is a money token associated with a monetary value and, in applying the effect, the processor is configured to: reduce a current transaction amount based on the monetary value; and transmit the token to a remote device to effect payment of the monetary value to the merchant.

Various embodiments are described wherein the token is a message token and is associated with a textual, audio, or visual message and, in applying the effect, the processor is configured to display the message to the user via the display of the POS device.

Various embodiments are described wherein, before applying the effect, the processor is configured to display an explanation of the at least one effect of the token to the user via the display.

Various embodiments relate to a computer implemented method for providing token offerings is recited. The method involves receiving information over a near field data communication interface from a wearable device at a point of sale terminal in communication with a computer at a merchant, wherein the information received includes a type of the wearable device and an activity measure; storing the transmitted information in a memory at the merchant computer; and displaying, by the merchant computer, the token offer on the point of sale terminal that corresponds to the wearable device type and to the activity measure.

Offering tokens at a point of sale terminal corresponding to a wearable device type offers several advantages, including but not limited to the delivery of targeted incentives to particular users, groups of users, classes of users, etc. This enables vendors, retailers, device manufacturers, etc. to collaborate on the targeting of particular users, encouraging them to engage in particular commercial transactions. Various embodiments also permit the incentivization of particular behaviors. For example, offering incentives to the user based on wearable device activity helps a user to remain motivated and thereby maintain his health. For instance, the system may provide a token that can be used at a sports store based on the activity measure of the user. Elaborating further, if the user has taken enough steps, he might be provided with a token at a store to buy a lunch on the coming Sunday.

In further embodiment, the token offer is displayed when the activity measure exceeds a predetermined value.

In further embodiment, the method includes receiving the token offer from an advertiser via a network connection with the merchant computer.

In further embodiments, the method includes receiving payment information from the wearable device.

In further embodiments, the token offered corresponds to the particular wearable device worn by the user.

In further embodiments, the method includes transmitting the token to at least one of the wearable device and a user device.

In further embodiments, the method includes receiving an indication that the user of the wearable device accepted the token offer.

Various embodiments relate to a non-transitory computer readable storage medium having embodied thereon a program executable by at least one processor to perform a method for providing token offerings. The method involves, as a part of the executable program, receiving information over a near field data communication interface from a wearable device at a point of sale terminal in communication with a computer at a merchant. The information received includes a type of the wearable device and an activity measure. The information transmitted is stored in a memory at the merchant computer, which may display a token offer that corresponds to the wearable device type and to the activity measure. A user of the wearable device may then accept the token offer at the point of sale terminal. Another example of implementing the method and system may be a vending machine or (other POS terminal) that outputs the products or completes transactions based on the data collected from one or more sensors of the wearable device. A user receiving the product based on the data collected from the sensors may provide a much friendlier way in contrast to arranging the coins or currency cards (e.g. , debit/ credit) to receive the product.

Various embodiments relate to a system for providing token offerings. The system includes a wearable device, a point of sale terminal in communication with a computer at a merchant, wherein information is transmitted over a near field data

communication interface from the wearable device to the point of sale terminal. Further, the information transmitted includes a type of the wearable device and an activity measure. The system also includes a memory at the merchant computer configured for storing the transmitted information and a display on the point of sale terminal configured to display a token offer. The token offer corresponds to the wearable device type and to the activity measure.

Various embodiments of the disclosure are set forth in the dependent claims. It should be understood that the claimed system and the claimed non-transitory computer readable storage medium can have similar preferred embodiments and the corresponding advantages as the claimed method and as defined in the dependent method claims.

The foregoing and other features and advantages of the embodiments described herein will be made more apparent from the descriptions, drawings, and claims that follow. One of ordinary skill in the art, based on this disclosure, would understand that other aspects and advantages exist. BRIEF DESCRIPTION OF THE DRAWINGS

In order to better understand various example embodiments, reference is made to the accompanying drawings, wherein:

FIG. 1 illustrates an exemplary system that may perform a method for providing token offers;

FIG. 2 illustrates an exemplary graphical user interface (GUI) that identifies tokens that may be selected;

FIG. 3 illustrates an exemplary method of a wearable base software that may be executed on a wearable device; FIG. 4 illustrates an example of wearable data that may be saved in a memory;

FIG. 5 illustrates an exemplary table of wearable sensor data that may be stored in memory;

FIG. 6 illustrates a mobile device architecture that may be utilized to implement the various features and processes described herein;

FIG. 7 illustrates an exemplary method for evaluating, delivering, and applying tokens;

FIG. 8 illustrates exemplary entries in a merchant device database;

FIG. 9 illustrates exemplary entries in a token-rule database;

FIG. 10 illustrates an exemplary methodology for providing computer offers; and

FIG. 11 illustrates an example interface for creating token-rules.

DETAILED DESCRIPTION

The description and drawings presented herein illustrate various principles. It will be appreciated that those skilled in the art will be able to devise various arrangements that, although not explicitly described or shown herein, embody these principles and are included within the scope of this disclosure. As used herein, the term, "and/or," as used herein, refers to a non-exclusive or (i.e., or), unless otherwise indicated (e.g., "or else" or "or in the alternative"). Additionally, the various embodiments described herein are not necessarily mutually exclusive and may be combined to produce additional embodiments that incorporate the principles described herein.

Various embodiments include a system and a method where a wearable device receives sensor data from a sensor at the wearable device that corresponds to an activity measure. The wearable device may send the sensor data, data that identifies the wearable device, and other information to a merchant point of sale terminal. The merchant point of sale terminal may then display a token offering on a point of sale terminal when the information sent from the wearable device includes a wearable device type and includes sensor data that corresponds to an activity measure. A computer at the merchant may make a determination that a token should be offered or the merchant computer may communicate with a token server that makes a determination that a token should be offered. The merchant computer may communicate with a credit card payment system that processes transactions. In some instances the credit card payment system provides credits/payments to the merchant that correspond to the token offer.

Wearable devices, a mobile device, and the merchant device may communicate using any data communication technology known in the art. In some instances a wearable device may communicate with a mobile device using a first type of wireless data communication technology, and the mobile device may communicate with the wearable using a second type of wireless data communication technology; in other words, the wearable device may communicate with the merchant device via the mobile device as an intermediary. Data communication interfaces used in various embodiments include, but are not limited to cellular 3G-4G LTE, Wi-Fi (802.11), infrared, optical, near field communication (NFC), and Bluetooth data communication interfaces. In some instances, a wearable device may include a plurality of data communication interfaces, a processor, a memory, a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), etc.

Mobile electronic devices discussed herein include, but are not limited to smartphones, IPHONE devices, ANDROID phones, IP AD tablets, and notebook computers. Communications communicated by a wearable device or by a mobile device may be communicated over any data communication technology known in the art, including, but not limited to Bluetooth, Cellular 3G 4G LTE, and Wi-Fi (802.11). In some instances, a mobile device may include a plurality of data communication interfaces, a processor, a memory, a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), etc.

The various methods may be performed by software operating in conjunction with hardware. The software may include, for example, instructions executed by a processor, the instructions otherwise stored in a non-transitory computer readable medium such as memory. Various interfaces may be implemented— communications and otherwise. One skilled in the art will appreciate the various requisite components of a mobile device and integration of the same with one or more of the figures and/or descriptions included herein. Further, while various embodiments are described herein in relation to software components "performing" various functionalities, it will be apparent that such functionality is actually performed by hardware such, for example, a processor {e.g., a microprocessor, FPGA, ASIC, or other device capable of processing data) executing the instructions defining the software, which may be stored in a non-transitory machine-readable medium {e.g. , a memory such as L1/L2/L3 cache, system memory, or storage). It will be understood that in some

embodiments, a processor may be hard- wired {e.g. , an ASIC) to perform some or all of the functions described as being performed by software; in such embodiments, software instructions for defining such hard- wired functionality (and possibly memory for storing such instructions) may be omitted from the device. As used herein, the term "non-transitory machine-readable media" will be understood to include both volatile (e.g., DRAM and SRAM) and non-volatile (e.g., flash memory, magnetic storage, and optical storage) memories, but to exclude transitory signals.

FIG. 1 illustrates an exemplary system 100 that may perform a method for providing token offerings based on physiological data from a wearable device. FIG. 1 includes a wearable device 110 in communication with a merchant device 120 and a user device 130. The merchant device 120 is depicted as communicating with a token network 140 over the data network 150, which may be virtually any network or grouping thereof for enabling the communications described herein such as, for example, a LAN, WAN, carrier network, Internet, or network within a cloud computing architecture. The merchant device 120 is also depicted as communicating with a credit card payment system including a merchant bank 164, a customer bank 166, and a credit card processor 168 when processing credit cards. Credit card transactions may be coordinated by a trusted service manager (TSM) 162. The TSM 162 may be an entity that may serve a trusted intermediary among mobile devices 130, networks that service mobile devices 130, and software applications. The TSM 162 may coordinate secure payments from a financial institution to a merchant that have been authorized by a mobile device 130.

The example wearable device 110 includes a communications interface 11 1, wearable sensor data 113 (an example of which will be described in greater detail with respect to FIG. 5), sensors 1-N 115, wearable base software 117 (an example of instructions belonging to such software 117 will be described in greater detail below with respect to FIG. 3), a clock 118, and wearable data 119 (an example of which will be described in greater detail below with respect to FIG. 4). The communications interface 111 may include one or more wired or wireless interfaces such as WiFi, NFC, Bluetooth, 3G/4G/LTE, Ethernet, USB, proprietary, or other interfaces for communicating with other devices such as the user device 130, merchant device 120, token server 140, point of sale terminal 180, point of sale printer 185, either directly or via the data network 150. The sensors 115 may include one or more sensors for obtaining physiological data from the user, such as accelerometers, conductance sensors, optical sensors, temperature sensors, etc. These or other sensors may be useful for sensing, computing, estimating, or otherwise acquiring physiological parameters descriptive of the wearer such as, for example, steps taken, walking/running distance, standing hours, heart rate, respiratory rate, blood pressure, stress level, body temperature, calories burned, resting energy expenditure, active energy expenditure, height, weight, sleep metrics, etc. Although not illustrated, it will be apparent that the wearable device 110 (as well as other devices 120, 130, 140 depicted in FIG. 1) may include additional hardware such as, for example, a processor, memory, user interface {e.g., a display, touchscreen, buttons, dials camera, microphone, speaker, etc.).

The merchant device 120 may be any device operated by a merchant for facilitating monetary transactions. For example, the merchant device 120 may be a point of sale terminal such as a retail point of sale, gas pump, cash register, vending machine, web server, etc. As another example, the merchant device may be a token-providing kiosk available for consultation of available tokens and, in some embodiments, printing of paper tokens associated with available token. Alternatively, the merchant device 120 may be a central server {e.g., a personal computer, server, blade, or virtual machine hosted in a cloud- computing environment) operated by a merchant for coordinating the operation of one or more separate points of sale terminals 180 or printers 185. Accordingly, while the wearable device 110 is depicted as communicating directly with the merchant device, in some such embodiments, such communication may occur via a point of sale terminal 180 (and possibly the user device 130) as an intermediary. The example merchant device 120 includes a communication interface 121 which, like the communication interface 111 of the wearable device 110, may include one or more wired or wireless interfaces such as WiFi, NFC, Bluetooth, 3G/4G/LTE, Ethernet, USB, proprietary, or other interfaces for communicating with other devices. The example merchant device 120 also includes a merchant device database (an example of which will be described in greater detail below with respect to FIG. 8) and token presentation software 125 (an example of instructions belonging to such software 125 will be described in greater detail below with respect to FIG. 7). Although not illustrated, it will be apparent that the user device 130 may include additional hardware such as, for example, a processor, memory, user interface {e.g., a display, touchscreen, buttons, dials camera, microphone, speaker, etc.).

The user device 130 may be any device operated by the wearer of the wearable device such as, for example, a mobile phone, tablet, personal computer, laptop, or another wearable device. As shown, the user device includes a pass through application program interface (API) 132, a communication interface 134, and a graphical user interface 136. The API 132 may be embodied in instructions executed by a processor for facilitating the forwarding of messages between the wearable device 110 and other devices such as the merchant device 120 or token server 140 in various embodiments such as those embodiments wherein the communication interface 1 1 1 of the wearable device 1 10 is only capable of or configured to communicating with the user device 130. The communication interface 134, like the communication interface 1 1 1 of the wearable device 1 10, may include one or more wired or wireless interfaces such as WiFi, NFC, Bluetooth, 3G/4G/LTE, Ethernet, USB, proprietary, or other interfaces for communicating with other devices. The GUI 136 may be embodied in instructions executed by a processor for interacting with a user via one or more UI hardware components including a display. An example GUI for display on the user device 130 (or directly via a UI of the wearable device 1 10) will be described in greater detail below with respect to FIG. 2. Although not illustrated, it will be apparent that the user device 130 may include additional hardware such as, for example, a processor, memory, user interface (e.g. , a display, touchscreen, buttons, dials camera, microphone, speaker, etc.).

The token server 140 in FIG. 1 may be a device for distributing tokens and, in some embodiments, associated rules to the merchant device 120 for potential presentation to the wearer of the wearable device 1 10. In some embodiments, the token server 140 may be operated by the same entity as the merchant device 120 and, in some embodiments, the token server 140 and merchant device 120 may be the same device.

As illustrated, the token server 140 includes a token rule database 142 (an example of which will be described in greater detail below with respect to FIG. 9) and an API 144 which may be embodied in software instructions executed by a processor for providing wearable manufacturers 170 and third parties 172 (or devices operated thereby or otherwise under the control thereof) to modify the contents of the token rule database 142, thereby creating, modifying, or deleting tokens available for presentation to users. For example, wearable device manufacturers may define token rules for delivering tokens to customers using one or more of their products. As another example, product advertisers may define token-rules for delivering tokens that discount the advertiser's products. As yet another example, parties may create token-rules specifically to server as an incentive to the wearer. Coaching programs, friends (e.g., via social media), or even the wearer of the device may create token rules to be delivered to specific wearable devices. For example, one or more of the wearable device user's friends on a social network site may contribute a total of $200 to a prepaid card which is then associated with a payment token that, via a token-rule created by the friends, will be released to the user upon the user attaining 10,000 steps for at least 25 days in a month. Once the token is released, the user may use the token as payment at a merchant. Alternatively, in some embodiments, alternative recipients for a token may be defined in a token rule. For example, the token may be provided to a relative (e.g., grandchild) or a charity upon the wearer attaining the criteria. Although not illustrated, it will be apparent that the user device 130 may include additional hardware such as, for example, a processor, memory, user interface (e.g. , a display, touchscreen, buttons, dials camera, microphone, speaker, etc.).

The token server 140 may, in various embodiments, distribute token-rules among merchant devices for evaluation. For example, the token server may locate any token- rules that are applicable to a merchant, and then send those token-rules to one or more merchant devices 120 operated by that merchant such that those token-rules may be evaluated by the merchant device 120 to determine whether the associated token should be offered or otherwise delivered to the a customer. In other embodiments, the token server 140 may be responsible for evaluating token-rules and, as such, may include the token

presentation software 125 (or portions thereof). For example, the token server 140 may receive sensor data in association with a merchant, user or device from a requesting device such as the wearable device 1 10, merchant device 120, or user device 130; evaluate token- rules to identify one or more tokens for delivery; and transmit the identified tokens to a receiving device such as the wearable device 1 10, merchant device 120, or user device 130. Accordingly, depending on which device includes the token presentation software 125 or otherwise evaluates token-rule criteria for applicability, the token server 140, merchant device 120, user device 130, wearable device 1 10, or other device may be considered a token presentment device,

Having described an exemplary system and (some but not all variations thereof), and example of the operation of the system will now be provided. Further details relating to the example implementations will be described in greater detail below with respect to FIGS. 2-10.

According to one specific example, a user wears a pedometer 1 10 on their wrist which counts the number of steps the user takes each day. A grocery store's central server 121 is in communication with multiple point of sale terminals 180 within the grocery store. Periodically, the merchant device 120 receives multiple token-rules from the token server and stores these token-rules locally for future evaluation. One such token-rule indicates that, if a customer's steps in the current or previous day exceeds 10,000 steps, that a token offering a $2.00 off a particular brand of health shake should be provided to the customer. The user approaches the point of sale terminal 180 (e.g., to check out or for the purpose of identifying available tokens), which requests and receives, using NFC, the current step count from the pedometer 1 10, which is currently 10,343 steps. The point of sale terminal 180 forwards this information to the central server 121 which, evaluating the available token-rules, determines that the user has passed 10,000 steps and the token for $2.00 of the health shake is available. The merchant device sends the token to the point of sale terminal 180 for display to and acceptance by the user. The token is then delivered to the user electronically or via the point of sale printer 185. Alternatively, if the user is currently checking out and has scanned the health shake for purchase, the discount may be applied immediately to the total amount owed.

Various alternatives to this specific operation will be apparent in view of the present disclosure. For example, in some embodiments, the wearable device 110 or user device 130 may communicate with the token server 140 to receive token-rules for local evaluation or may send physiological data to the token server 140 and may receive tokens in response. Thereafter, the user device 130 or wearable device 110 may present the previously received tokens to the merchant device 120 or point of sale terminal 180 (e.g., via NFC during checkout). The merchant device 120 or point of sale terminal 180 may then forward the token to the token server for verification before applying the token to the present transaction. In various embodiments, different methods for token delivery may be used and, further, may be provided as options to the user. For example, tokens may be delivered by printing a physical token (e.g., via a printer of the POS device), displaying the token to the user (e.g., via a display device of the POS device, with or without a touchscreen), electronically transmitting the token to a device of the user (e.g., via NFC to the user wearable 110 or user device 130), or by applying the token to the present transaction (e.g., by submitting the token to the credit card payment system 160 or other system for

reimbursement to the merchant).

In some devices, data used by the merchant device 120 or otherwise used to determine token-rule applicability (e.g., wearable sensor data 113 or wearable data 119) may be additionally or alternatively available from a device (e.g., a virtual machine) in a cloud computing architecture. For example, in some embodiments, the wearable device 110 may periodically transmit sensor data to a wearable device/Internet of things (IoT) management framework in a cloud computing architecture. In some such embodiments, the merchant device 120 or token server 140 may request the sensor data from the management framework (which may or may not be deployed in a cloud architecture) and use that received data to assess token applicability. For example, the wearable device 110 may receive the wearer's permission to share data with the merchant and transmit to the merchant device 120 its identifier within the management framework. The merchant device 120 may then use the identifier to retrieve the sensor data for use in evaluating token rules. In some embodiments where the token server 140 evaluates token-rule applicability, the token server 140 may be deployed as part of or otherwise within the management framework.

FIG. 2 illustrates an exemplary graphical user interface (GUI) 200 that identifies tokens that may be selected by a user of the wearable device. The GUI 200 may correspond to the GUI 136 of FIG. 1 or may be a GUI (not shown) displayed on the wearable device 110, merchant device 120, POS terminal 180, or POS printer 185. The GUI 200 of FIG. 2 depicts that a user using wearable device identifier as "Your Pedometer" 210 is eligible to receive tokens relating to two different retail establishments: Stephenson's and Simply Baroque 220. FIG. 2 also indicates that a token 230 from Insurance Coffee has been refused. The GUI 200 is representative of how a GUI may be used to display token offerings for selection by a user. Various modifications to the GUI 200 will be apparent within the scope of the present disclosure. For example, rather than displaying a listing of acquired tokens for selection, each token may be displayed individually for acceptance or rejection (e.g., as acquired). In some embodiments,

In some embodiments, the GUI 200 may also show tokens that may be obtained in the future but have not yet been achieved. For example, where the device displaying the GUI 200 stores or otherwise has access to token-rules, such token-rules may be displayed to the user. As an example 240, the GUI 200 shows that a token for "XYZ Grocery" is available if the user exceeds 10,000 steps today. Another example 250 shows that another token, this one for "Electronics Store," will be eligible when the user exceeds 10,000 steps per day for seven consecutive days.

It will be apparent that additional information may be displayed on the GUI such as, for example, associated products, discount amount, token expiration date, conditions that led to eligibility, source of the token (eg., a merchant, product source, device

manufacturer, social contact, wearable user, etc.), token-rule expiration date, etc. It will also be apparent that in some embodiments, the GUI 200 may not display only tokens associated with a specific device 210. For example, if the user wears multiple devices (e.g., a pedometer and heart rate monitor), offers related to either or both may be displayed on the same page. Further, in some embodiments, the physiological data used to determine token eligibility may not be directly related to a specific wearable but, rather, computed from values sensed by one or more wearables. For example, a "stress level" may be computed by the wearable device, user device, a cloud device, or another device using sensor data and, such stress level indicator may be used to select between a token for low stress individuals and a token for high stress individuals. In other words, virtually any sensor data, parameters computed therefrom, or combinations thereof may serve as determining criteria for token eligibility.

FIG. 3 illustrates an exemplary method 300 that may be executed on a wearable device. In some embodiments, the method 300 may describe instructions belonging to the wearable device base software 1 17 of FIG. 1. FIG. 3 depicts a series of steps that receive sensor and clock information 310, write the received sensor data and time

information to a memory 320, and poll a communication interface (e.g., for NFC input signals) 330. A determination step in FIG. 3 determines whether a communication request has been received 340; when a communication has been received, the wearable data saved in the memory may be sent to a merchant device 350. The wearable data saved in the memory may be marked with a sent status indicating that that data has been sent to a merchant. When a communication has not been received or after the wearable data has been sent to a merchant the method repeats beginning with step 310 where sensor data and clock information are received.

The method 300 may be useful in embodiments wherein the merchant device

120 or POS terminal 180 are responsible for determining token eligibility. As described, the method 300 provides an interface for these devices 120, 180 to retrieve sensor data from a wearable device 1 10 (or user device 130). In some embodiments, the sensor data may be secured against unwanted access. For example, in some embodiments, another step (not shown) may be inserted between steps 340, 350 wherein the user is informed of the access attempt and is prompted to input approval or disapproval to share the data. As such, step 350 may be executed only when the user has approved access. In other embodiments, a step may be inserted between steps 340, 350 to verify a key received from the requesting device and, if the key is verified, proceed to step 350. As yet another alternative, step 350 may be modified to transmit the wearable data in an encrypted form such that only approved parties to which the encryption key was previous distributed are able to decrypt the data into a usable form. In some embodiments wherein the wearable device 1 10 or user device 130 stores tokens, step 350 may be replaced with a step for transmitting tokens to the requesting device (e.g. all token rules, token rules selected by the user, all eligible tokens, or eligible tokens selected by the user).

FIG. 4 illustrates an example of wearable data 400 that may be saved in a memory and transmitted to another device such as, for example, through operation of step 350 for method 300. In some embodiments, the data 400 may correspond to the wearable data 1 19 of FIG. 1. As shown, the example data 400 includes device identifier (ID) 24601 410, device type "Pedometer" (though it will be apparent that more specific or other type descriptions, such as a specific brand or model, may be used) 410, a list of acquired and accepted tokens 430, a list of tokens acquired but rejected by the user 440, and a set of sensor data 450. For example, as shown, the sensor data includes data from multiple recent days including a step count, a number of calories burned, and a classification of the activity level for that day. It will be apparent that, in some embodiments, the device may transmit all available data for analysis by the other device (e.g., the merchant device 120) while, in other embodiments, the device may only transmit sensor and other data that is specifically requested or may send only sensor data known to be relevant to evaluating applicability of tokens or token-rules transmitted therewith. It will be apparent that, while the tokens are illustrated as strings (e.g., "Stephenson's" and "Simply Baroque"), that the actual data transmitted may include information sufficient to identify the token or identify its effect on a transaction. For example, the token may be a data structure including identifiers of a merchant, item, discount, and user identifier for verifying the token. As another example, the token may be an identifier known to a token authenticating server (e.g., token server 140). Various other approaches to representing a token will be apparent and modifications for adoption within the presently described system will be apparent.

FIG. 5 illustrates an exemplary table of wearable sensor data 500 that may be stored in memory. For example, the data 500 may correspond to the wearable sensor data 1 13 of FIG. 1. Each record in FIG. 5 includes fields such as sensor ID 510, sensor type 520, time 530, data 540, and an indication that a specific set of data has been sent 550 to another device. FIG. 5 illustrates exemplary sensor data including a pulse of a person and steps stepped as detected by an accelerometer. A first row in the table indicates that sensor 1 recorded a pulse rate of 60 beats per minute on December 8, 2014 at 12:55 pm. A second row of the table indicates that on December 8, 2014 at 12:55 pm a total of 1568 steps had been detected since the wearable was initialized. The table indicates that the data from the first and second rows has already been sent to another device. The table also indicates that data from rows three and four have not yet been sent. Data from the table may be sent to a token server when the token server is providing tokens. Various embodiments may allow wearable sensor data 500 to be viewed by third parties when making decisions regarding types of promotions that may be sent to a wearable device or to a user device coupled with a wearable device.

In some embodiments, the wearable sensor data 500 may overlap to some extent with the wearable data 400 which is to be transmitted to another device. For example, in some embodiments, the sensor data 450 may be a subset of the wearable sensor data 500 or may be a digested version of the wearable sensor data 500 (e.g., wearable sensor data 500 may include all stored sensor data while sensor data 450 may include only that sensor data deemed relevant for transmission to another device). In other embodiments, the wearable data 400 may not include the sensor data 450 and, instead, the wearable sensor data 500 may be transmitted to other devices as appropriate.

FIG. 6 illustrates a mobile device architecture that may be utilized to implement the various features and processes described herein. Architecture 600 can be implemented in any number of portable devices including but not limited to smart wearable devices. Architecture 600 as illustrated in FIG. 6 includes memory interface 602, processors 604, and peripheral interface 606. Memory interface 602, processors 604 and peripherals interface 606 can be separate components or can be integrated as a part of one or more integrated circuits. The various components can be coupled by one or more communication buses or signal lines.

Processors 604 as illustrated in FIG. 6 are meant to be inclusive of data processors, image processors, central processing units, or any variety of multi-core processing devices. Any variety of sensors, external devices, and external subsystems can be coupled to peripherals interface 606 to facilitate any number of functionalities within the architecture 600 of the exemplar mobile device. For example, motion sensor 610, light sensor 612, and proximity sensor 614 can be coupled to peripherals interface 606 to facilitate orientation, lighting, and proximity functions of the mobile device. For example, light sensor 612 could be utilized to facilitate adjusting the brightness of touch surface 646. Motion sensor 610, which could be implemented as an accelerometer or gyroscope, could be utilized to detect movement and orientation of the mobile device. Display objects or media could then be presented according to a detected orientation (e.g., portrait or landscape).

Other sensors could be coupled to peripherals interface 606, such as a temperature sensor, another vitals sensor, or other sensing device to facilitate corresponding functionalities. Location processor 616 (e.g., a global positioning transceiver) can be coupled to peripherals interface 606 to allow for receipt of geo-location data thereby facilitating geo- positioning. An electronic magnetometer 616 such as an integrated circuit chip could in turn be connected to peripherals interface 606 to provide data related to the direction of true magnetic North whereby the mobile device could enjoy compass or directional functionality. Camera subsystem 620 and an optical sensor 622 such as a charged coupled device (CCD) or a complementary metal-oxide semiconductor (CMOS) optical sensor can facilitate camera functions such as recording photographs and video clips. Communication functionality can be facilitated through one or more communication subsystems 624, which may include one or more wireless communication subsystems. Wireless communication subsystems 624 can include 802.5 or Bluetooth transceivers as well as optical transceivers such as infrared. Wired communication system can include a port device such as a Universal Serial Bus (USB) port or some other wired port connection that can be used to establish a wired coupling to other computing devices such as network access devices, personal computers, printers, displays, or other processing devices capable of receiving or transmitting data. The specific design and implementation of communication subsystem 624 may depend on the communication network or medium over which the device is intended to operate. For example, a device may include wireless communication subsystem designed to operate over a global system for mobile

communications (GSM) network, a GPRS network, an enhanced data GSM environment (EDGE) network, 802.5 communication networks, code division multiple access (CDMA) networks, or Bluetooth networks. Communication subsystem 624 may include hosting protocols such that the device may be configured as a base station for other wireless devices. Communication subsystems can also allow the device to synchronize with a host device using one or more protocols such as TCP/IP, HTTP, or UDP.

Audio subsystem 626 can be coupled to a speaker 628 and one or more microphones 630 to facilitate voice-enabled functions. These functions might include voice recognition, voice replication, or digital recording. Audio subsystem 626 in conjunction may also encompass traditional telephony functions.

I/O subsystem 640 may include touch controller 642 and/or other input controller(s) 644. Touch controller 642 can be coupled to a touch surface 646. Touch surface 646 and touch controller 642 may detect contact and movement or break thereof using any of a number of touch sensitivity technologies, including but not limited to capacitive, resistive, infrared, or surface acoustic wave technologies. Other proximity sensor arrays or elements for determining one or more points of contact with touch surface 646 may likewise be utilized. In one implementation, touch surface 646 can display virtual or soft buttons and a virtual keyboard, which can be used as an input/output device by the user.

Other input controllers 644 can be coupled to other input/control devices 648 such as one or more buttons, rocker switches, thumb-wheels, infrared ports, USB ports, and/or a pointer device such as a stylus. The one or more buttons (not shown) can include an up/down button for volume control of speaker 628 and/or microphone 630. In some implementations, device 600 can include the functionality of an audio and/or video playback or recording device and may include a pin connector for tethering to other devices.

Memory interface 602 can be coupled to memory 650. Memory 650 can include high-speed random access memory or non-volatile memory such as magnetic disk storage devices, optical storage devices, or flash memory. Memory 650 can store operating system 652, such as Darwin, RTXC, LINUX, UNIX, OS X, ANDROID, WINDOWS operating systems, or an embedded operating system such as VXWorks. Operating system 652 may include instructions for handling basic system services and for performing hardware dependent tasks. In some implementations, operating system 652 can include a kernel.

Memory 650 may also store communication instructions 654 to facilitate communicating with other mobile computing devices or servers. Communication instructions 654 can also be used to select an operational mode or communication medium for use by the device based on a geographic location, which could be obtained by the GPS/Navigation instructions 668. Memory 650 may include graphical user interface instructions 656 to facilitate graphic user interface processing such as the generation of an interface; sensor processing instructions 658 to facilitate sensor-related processing and functions; phone instructions 660 to facilitate phone-related processes and functions; electronic messaging instructions 662 to facilitate electronic-messaging related processes and functions; web browsing instructions 664 to facilitate web browsing-related processes and functions; media processing instructions 666 to facilitate media processing-related processes and functions; GPS/Navigation instructions 668 to facilitate GPS and navigation-related processes, camera instructions 670 to facilitate camera-related processes and functions; instructions 672 for coordinating pedometer functions; and activation record or IMEI 674 for identifying the device 600 to other devices (e.g., a carrier network); and instructions for any other application that may be operating on or in conjunction with the mobile computing device. Memory 650 may also store other software instructions for facilitating other processes, features and applications, such as applications related to navigation, social networking, location-based services or map displays.

FIG. 7 illustrates an example method 700 or evaluating, delivering, and applying tokens that may be executed at a computer at a merchant, a token server, or other device. In various embodiments, the method 700 may be embodied in instructions belonging to the token presentation software 125 of the merchant device. In other embodiments wherein the user device or wearable device is responsible for evaluating token rules, various modifications for adapting the method 700 to those device will be apparent. The method 700 includes a series of steps where a point of sale terminal at a merchant may poll for a request 705 (e.g., via NFC), receive wearable data 400 and sensor data from a wearable device 710, and recognize a wearable device from the wearable data 400 and data from a merchant data base 715. The method 700 extracts sensor data 720 (e.g., 1735 steps), compares the sensor data (e.g., number of steps walked) to the token-rule criteria (e.g., 1600 steps) in step 725, and determines that a token may be offered as the sensor data indicates that the token-rule criteria is met (e.g., the individual walked more than 1600 steps) in step 730. Next the merchant displays a token offer on a point of sale terminal 735. The token may be rejected 740 or accepted 745. When the token is accepted the token may be printed in step 750 (e.g., as paper coupon), or sent to a memory in the wearable device 755 (electronically printed), or the token may be used immediately 760. When the token is used immediately the token may be sent to the point of sale terminal 770 where it may be credited to the credit card payment system. When the token is stored in memory of the wearable device, the wearer may select the token for application at a future time as part of a future transaction. For example, in some embodiments, the wearable device may provide the user with an interface for selecting tokens to be sent to a merchant device while, in some embodiments, the merchant device may also request, from the wearable device, any previously earned but not redeemed tokens at each transaction and, in a manner similar to that described above, present the tokens to the user for selection. In an instance where the sensor data indicates that the token-rule criteria is not met (e.g., the individual has not walked more than 1600 steps) in step 730, the program flow may end without offering a token. It will be apparent that some steps may be performed multiple times when multiple token-rules are available for evaluation. For example, the method 700 may loop through steps 720, 725, 730 for each active token-rule and proceed to step 735 or to step after all such token-rules are evaluated, dependent on whether at least one token-rule is associated with criteria that is met by the sensor data. The program flow may also end when the token is rejected or after the token is used. Various embodiments may motivate a user of a wearable device to meet a goal or to perform more of a particular activity. For example, an advertiser may send a message to the user wearable device or user device encouraging the user to continue an activity when the user is close to reaching a threshold for receiving a token.

FIG. 8 illustrates exemplary entries in a merchant device database 800 which may correspond to the merchant device database 123 of FIG. 1. In various embodiments, the database 800 may be used by the merchant to track which devices (or customers) have been offered which tokens and whether they have been redeemed. Such information may be useful for example for reporting to the token server or credit card processing servers. A table 800 in the figure includes a device ID field 805 for identifying the device (or, alternatively, the customer via a device identifier or another customer identifier), a token field 810 for storing the offered token(s) or identifications thereof, an accepted field 815 for indicating whether the token(s) were accepted, and a redemption transaction field 820 for storing an identifier of a transaction in which the token was redeemed, if any. A first record 840 in the table indicates that device 24601 was offered and accepted a token 0x34A3, which was redeemed in transaction 1025401 (which, in some embodiments, may cross reference a transaction database of the merchant, including additional details describing the transaction). A second example record 850 indicates that device AA23 was offered but declined token 0xFE3D. A third example record 860 indicates that device TK21 was offered and accepted token 0x3D55, but has not redeemed it yet (e.g., the user may have printed or electronically received the token for later use).

FIG. 9 illustrates exemplary entries in a token-rule database 900 which, in some embodiments, may correspond to the token-rule database 142 of FIG. 1. A table 900 in FIG. 9 includes a merchant field 910 for identifying one or more merchants where the token will be delivered if achieved, a discount type field 920, criteria field 930 for storing criteria for determining whether the token should be offered based on sensor data, and an effect field 940 for defining one or more effects that a delivered token will have on a transaction or at another point. The table indicates that when a user of a wearable device has met a criteria, a token having the effect described in field 940 (or, in some embodiments, a field may be defined that stored the token to be delivered itself) may be sent to the wearable device or to a mobile device communicating with the wearable device.

Criteria in FIG. 9 include, for example, a number of steps taken, a heart rate, a number of visits per week, or a type of wearable device. For example a $1 discount is offered at Insurance Coffee when the user has exceeded 1600 steps in a day. FIG. 9 illustrates that criteria for offering a token may be maintained in a token-rule database 900. A token offering may be related to various types of activities including, but not limited to a number of steps, a number of times a user visits a store, a heart rate, a number of calories burned, or a token offering could relate to a type of wearable device that a person uses. For example, a token may be offered when determination has been made that a person has burned a predetermined number of calories. In such an instance the token offering may be sent to a wearable device or a user device with a message stating: "You have burned greater than 3000 calories today. Congratulations! Here is a $2.00 off coupon for a hot fudge sundae. You have earned it." A token need not always offer a discounted (or free) product voucher (i.e., a "coupon token," used herein to refer to both discounts, including "free," on transactions and products) or bestow cash/purchasing power (i.e., a "money token,"). In some embodiments, a token may, for example, cause the POS terminal to display a message such as an encouragement message or a product recommendation. For example, if a wearer's average pulse has been recently calculated to be over 85 bpm, the token may case the POS or a kiosk to display a

recommendation that the user purchase a particular healthy food product or an album of soothing music.

FIG. 10 illustrates an exemplary method 100. The method begins in step 1020 of FIG. 10 where the method 1000 allows a user to input token preferences. Then in a second step 1030 sensor data is received from a wearable device by the merchant device. After that wearable data 400 is evaluated in a third step 1040. Then a fourth step 1060 determines whether the sensor data received is sufficient to receive a token offer; when yes, a token offer is sent to the merchant device 1070, and then the transaction is processed in step 1080. When the data is not sufficient to receive a token the transaction is processed in step 1080 without offering a token. The various methods may be performed by software operating in

conjunction with hardware. For example, instructions executed by a processor, the instructions otherwise stored in a non-transitory computer readable medium such as memory. Various interfaces may be implemented— both communications and interface. One skilled in the art will appreciate the various requisite components of a mobile device and integration of the same with one or more of the foregoing figures and/or descriptions.

Various examples of the data network 150 include but are not limited to the Internet, intranets, extranets, wired networks, wireless networks, local area networks (LANs), or other suitable networks, etc., or any combination of two or more such networks.

FIG. 11 illustrates an example interface 1100 or creating token-rules. The interface 1100 may for example be a graphical user interface (GUI) presented by the API 144 or other component (not shown) of the token server 140. Alternatively, the interface 1100 may be provided by a third party application, web site, or other user- facing service and may communicate with the token server 140 via the API 144. In various embodiments, the interface 1100 may be operated by a device manufacturer, advertiser, coaching service, or an individual such as the wearable device owner 110 (e.g., via the user device 130 orwearable device 110) or friends and relatives thereof.

As shown, the interface 110 includes a token conditions section 1110 for defining the conditions for delivering a token, a token section 1120 for defining the token to be delivered, and a create button 1 130 for submitting the form for token-rule creation so that the token-rule may be propagated for evaluation by appropriate entities and devices. It will be apparent that the interface is one example and that alternative input items and formats may be used and that multiple screens may be used to display the form as multiple parts.

As shown, the token conditions section 1 100 includes multiple sections 1 1 12,

1 1 14, 1 1 16, 1 1 18. A rule recipient field 1 12 allows the user to indicate to what users the token-rule will be delivered or otherwise applied. As shown, the user may specify one or more individuals or may identify a group of individuals (each of who will be able to receive their own toke rule). A criteria field 1 1 14 enables the user to define one or more criteria for evaluation to determine whether the token is to be offered. As shown, the token will be delivered if the recipient ("John Doe") achieves 2000 daily steps over the course of a month. A merchants field 1 1 16 allows the user to define one or more merchants where the token-rule will be evaluated or where the token will be redeemable. A rule expiration field 1 1 18 enables the user to set a date where the token-rule will no longer be applied and, as such, the token will no longer be obtainable.

As shown, the token section 1 120 also includes multiple sections 1 122, 1 124, 1 126, 1 128. A token recipient enables the user to define to whom the token will be delivered when the criteria is satisfied. For example, the token may be delivered to the same individual specified in the rule recipient field 1 1 12 (whether specifically defined or belonging to a specified group). In such a case, the token may be delivered to the recipient at the same merchant location where the sensor data was read to evaluate the rule criteria. Alternatively, various other delivery channels may be used such as, for example, text message, email, pushed to the wearable device, pushed to a wearable device app on a user device, or direct deposit to a user's bank or other account. Token recipient field 1 122 may also allow definition of another recipient such as an individual, group, or entity such as a charity.

Similar means for token delivery may be used such as text message, email, pushed to the wearable device, pushed to a wearable device app on a user device, or direct deposit to a user's bank or other account. In some embodiments, multiple entities may be specified to receive different tokens. For example, one set of criteria may be used to deliver a discount to a user and a cash amount to a charity.

A cash field 1 124 may be selectable to indicate that an amount of money should be delivered via the token and to specify a payment source for the specified amount. Similarly, a discount field 1 126 may be selectable to indicate a discount type (e.g., percentage or flat amount), amount, one or more products to which the discount applies, and a source of payment for the discount. A message field 1 128 may enable the user to specify a message to be displayed to the user upon completion of the criteria. Additional token contents for definition via the interface 1 100 will be apparent. Upon selection of the create button 1 130, the form contents may be validated, payment may be effected, and one or more token-rules may be created and stored in a token server for evaluation (and subsequent token delivery) or propagated to one or more merchant devices (e.g. , merchant devices operated by the merchants defined in the merchants field 1 1 16) for local evaluation at the merchant device. In some embodiments, prior to payment or token-rule creation or propagation of the token-rule, the proposed new token rule may be provided for review by an administrative entity which may approve or deny token-rules based on their content.

It should be apparent from the foregoing description that various exemplary embodiments of the invention may be implemented in hardware and/or firmware.

Furthermore, various exemplary embodiments may be implemented as instructions stored on a machine -readable storage medium, which may be read and executed by at least one processor to perform the operations described in detail herein. A machine-readable storage medium may include any mechanism for storing information in a form readable by a machine, such as a personal or laptop computer, a server, or other computing device. Thus, a machine-readable storage medium may include read-only memory (ROM), random-access memory (RAM), magnetic disk storage media, optical storage media, flash-memory devices, and similar storage media.

It should be appreciated by those skilled in the art that any block diagrams herein represent conceptual views of illustrative circuitry embodying the principles of the invention. Similarly, it will be appreciated that any flow charts, flow diagrams, state transition diagrams, pseudo code, and the like represent various processes which may be substantially represented in machine readable media and so executed by a computer or processor, whether or not such computer or processor is explicitly shown.

Although the various exemplary embodiments have been described in detail with particular reference to certain exemplary aspects thereof, it should be understood that the invention is capable of other embodiments and its details are capable of modifications in various obvious respects. As is readily apparent to those skilled in the art, variations and modifications can be affected while remaining within the spirit and scope of the invention. Accordingly, the foregoing disclosure, description, and figures are for illustrative purposes only and do not in any way limit the invention, which is defined only by the claims.

Claims

CLAIMS What is claimed is:

1. A point-of-sale (POS) device comprising:

a short-range wireless communication interface;

a network interface for communicating via a network;

a display device;

a memory; and

a processor configured to:

process transactions with customers;

receive, via the network interface from a token server, a token-rule associated with the merchant, the token-rule identifying sensor criteria and a token specifying at least one effect on the processing of a transaction when the token-rule is applicable;

store the token-rule in the memory after receipt for later evaluation;

receive, via the short-range wireless communication from a wearable device worn by a nearby user, sensor data gathered by the wearable device, wherein the sensor data includes at least one physiological parameter descriptive of the user of the wearable device;

compare the sensor criteria to the received at least one physiological parameter to determine whether the token-rule is currently applicable to the user; and

based on a determination that the token-rule is applicable, apply the effect to a current transaction of the merchant POS device with respect to the user.

2. The POS device of claim 1, wherein the processor is further configured to:

in displaying the explanation of the at least one effect of the token to the user, prompt the user for input accepting or rejecting the effect; and

perform the step of applying the effect is performed in response to the user accepting the effect.

3. The POS device of claim 1, wherein the processor is further configured to:

in displaying the explanation of the at least one effect of the token to the user, prompt the user for input as to whether to apply the effect immediately; and in response to the user declining to apply the effect immediately, transmit the token via the short-range wireless communication to at least one of the wearable device and a user device of the user.

4. The POS device of claim 1, wherein the processor is further configured to, prior to receiving sensor data:

transmit, to the wearable device via the short-range wireless communication, a request to read sensor data and an identifier of at least one of the merchant device and the merchant.

5. The POS device of claim 1, wherein the token is a coupon token and, in applying the effect, the processor is configured to apply a discount defined by the coupon token to a current transaction of the user.

6. The POS device of claim 1, wherein the token is a money token associated with a monetary value and, in applying the effect, the processor is configured to:

reduce a current transaction amount based on the monetary value; and

transmit the token to a remote device to effect payment of the monetary value to the merchant.

7. The POS device of claim 1, wherein the token is a message token and is associated with a textual, audio, or visual message and, in applying the effect, the processor is configured to display the message to the user via the display of the POS device.

8. The POS device of claim 1, wherein, before applying the effect, the processor is configured to display an explanation of the at least one effect of the token to the user via the display.

9. A method for interfacing a merchant point-of-sale (POS) device with a wearable device, the method comprising:

receiving, at the merchant POS device from a token server, a token-rule associated with the merchant, the token-rule identifying sensor criteria and a token specifying at least one effect on the merchant POS device when the token-rule is applicable; receiving, at the merchant POS device from the wearable device via short-range wireless communication, sensor data gathered by the wearable device, wherein the sensor data includes at least one physiological parameter descriptive of the user of the wearable device;

comparing the sensor criteria to the received at least one physiological parameter to determine whether the token-rule is currently applicable to the user; and

based on a determination that the token-rule is applicable, applying the effect to a current operation of the merchant POS device with respect to the user.

10. The method of claim 9, wherein:

displaying the explanation of the at least one effect of the token to the user comprises prompting the user for input accepting or rejecting the effect; and

the step of applying the effect is performed in response to the user accepting the effect.

11. The method of claim 9, wherein:

displaying the explanation of the at least one effect of the token to the user comprises prompting the user for input as to whether to apply the effect immediately;

the method further comprising, in response to the user declining to apply the effect immediately, transmitting the token via the short-range wireless communication to at least one of the wearable device and a user device of the user.

12. The method of claim 9, further comprising, prior to receiving sensor data:

transmitting, to the wearable device via the short-range wireless communication, a request to read sensor data and an identifier of at least one of the merchant device and the merchant.

13. The method of claim 9, wherein the token is a coupon token and applying the effect comprises applying a discount defined by the coupon token to a current transaction of the user.

14. The method of claim 9, wherein the token is a money token associated with a monetary value and applying the effect comprises: reducing a current transaction amount based on the monetary value; and transmitting the token to a remote device to effect payment of the monetary value to the merchant.

15. The method of claim 9, wherein the token is a message token and is associated with a textual, audio, or visual message and applying the effect comprises displaying the message to the user via the display of the POS device.

16. A non-transitory machine -readable storage medium encoded with instructions for execution by a merchant device, the non-transitory machine -readable storage medium comprising:

instructions for receiving a token-rule associated with the merchant, the token-rule identifying sensor criteria and a token specifying at least one effect on a transaction with a customer when the token-rule is applicable;

instructions for receiving, at the merchant device from the wearable device via short- range wireless communication, sensor data gathered by the wearable device, wherein the sensor data includes at least one physiological parameter descriptive of the user of the wearable device;

instructions for comparing the sensor criteria to the received at least one physiological parameter to determine whether the token-rule is currently applicable to the user; and

instructions for, based on a determination that the token-rule is applicable, applying the effect to a current transaction of the merchant with respect to the user.

17. The non-transitory machine-readable storage medium of claim 16, wherein:

the instructions for displaying the explanation of the at least one effect of the token to the user comprise instructions for prompting the user for input as to whether to apply the effect immediately;

the medium further comprising instructions for, in response to the user declining to apply the effect immediately, transmitting the token via the short-range wireless

communication to at least one of the wearable device and a user device of the user.

18. The non-transitory machine-readable storage medium of claim 16, further comprising instructions for, prior to receiving sensor data: transmitting, to the wearable device via the short-range wireless communication, a request to read sensor data and an identifier of at least one of the merchant device and the merchant.

19. The non-transitory machine-readable storage medium of claim 16, wherein the token is a coupon token and the instructions for applying the effect comprise instructions for applying a discount defined by the coupon token to a current transaction of the user.

20. The method of claim 16, wherein the token is a money token associated with a monetary value and the instructions for applying the effect comprise:

instructions for reducing a current transaction amount based on the monetary value; and

instructions for transmitting the token to a remote device to effect payment of the monetary value to the merchant.