U.S. patent application number 14/775349 was filed with the patent office on 2016-12-29 for facilitating transactions with a user account using a wireless device.
This patent application is currently assigned to APPLE INC.. The applicant listed for this patent is APPLE INC. Invention is credited to Zachary Margadoudakis.
Application Number | 20160379205 14/775349 |
Document ID | / |
Family ID | 48045098 |
Filed Date | 2016-12-29 |
![](/patent/app/20160379205/US20160379205A1-20161229-D00000.png)
![](/patent/app/20160379205/US20160379205A1-20161229-D00001.png)
![](/patent/app/20160379205/US20160379205A1-20161229-D00002.png)
![](/patent/app/20160379205/US20160379205A1-20161229-D00003.png)
![](/patent/app/20160379205/US20160379205A1-20161229-D00004.png)
![](/patent/app/20160379205/US20160379205A1-20161229-D00005.png)
![](/patent/app/20160379205/US20160379205A1-20161229-D00006.png)
![](/patent/app/20160379205/US20160379205A1-20161229-D00007.png)
![](/patent/app/20160379205/US20160379205A1-20161229-D00008.png)
![](/patent/app/20160379205/US20160379205A1-20161229-D00009.png)
![](/patent/app/20160379205/US20160379205A1-20161229-D00010.png)
View All Diagrams
United States Patent
Application |
20160379205 |
Kind Code |
A1 |
Margadoudakis; Zachary |
December 29, 2016 |
FACILITATING TRANSACTIONS WITH A USER ACCOUNT USING A WIRELESS
DEVICE
Abstract
A wireless device can store account identifiers and facilitate
transactions. The wireless device can be loaded with user account
identifiers and can be presented to various checkpoint devices.
When presented, the wireless device can transmit a selected account
identifier to the checkpoint device. In the context of a purchase
transaction, the checkpoint device can be a point-of-sale terminal
and the account data can be financial account data. In some
instances, the wireless device can also facilitate a purchase
transaction, e.g., by obtaining information about products to be
purchased, constructing a purchase order from the product
information, and transmitting the purchase order to a point-of-sale
terminal.
Inventors: |
Margadoudakis; Zachary;
(Cupertino, CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
APPLE INC |
Cupertino |
CA |
US |
|
|
Assignee: |
APPLE INC.
Cupertino
CA
|
Family ID: |
48045098 |
Appl. No.: |
14/775349 |
Filed: |
March 14, 2014 |
PCT Filed: |
March 14, 2014 |
PCT NO: |
PCT/US2014/028095 |
371 Date: |
September 11, 2015 |
Current U.S.
Class: |
705/71 |
Current CPC
Class: |
H04W 4/80 20180201; G06Q
20/204 20130101; G06Q 20/3278 20130101; H04W 12/0605 20190101; G06Q
20/3829 20130101; G06Q 20/327 20130101; G06Q 20/102 20130101; G06Q
20/20 20130101; G06Q 20/352 20130101; G06Q 20/40 20130101; G07F
7/082 20130101; H04B 1/385 20130101; H04B 2001/3861 20130101; H04W
12/0609 20190101; G06Q 30/0601 20130101 |
International
Class: |
G06Q 20/32 20060101
G06Q020/32; G06Q 20/38 20060101 G06Q020/38; G06Q 20/20 20060101
G06Q020/20; H04W 4/00 20060101 H04W004/00; G06Q 20/10 20060101
G06Q020/10; G06Q 20/34 20060101 G06Q020/34; H04B 1/3827 20060101
H04B001/3827 |
Foreign Application Data
Date |
Code |
Application Number |
Mar 15, 2013 |
US |
PCT/US2013/032529 |
Claims
1.-21. (canceled)
22. A method of managing user account data, the method comprising:
establishing, by a wearable device, a verified communication
session with a host device, the verified communication session
being established while the wearable device is being worn;
receiving, by the wearable device, user account data from the host
device during the verified communication session; storing, by the
wearable device, the received user account data in a storage medium
of the wearable device; providing a subset of the received user
account data to a checkpoint terminal; and in the event that the
wearable device ceases to be worn, deleting, by the wearable
device, the stored user account data from the storage medium.
23. The method of claim 22 wherein the user account data comprises
identifying information for a financial account of the user.
24. The method of claim 23 wherein the identifying information is
sufficient to perform a financial transaction using the financial
account of the user.
25. The method of claim 22 wherein establishing the verified
communication session comprises establishing a session key and
wherein the user account data is received in an encrypted form, the
method further comprising: decrypting the received user account
data using the session key.
26. The method of claim 22 further comprising: subsequently to
storing the received user account data, receiving, by the wearable
device, a request from the checkpoint terminal for account data;
and selecting the subset of the stored account data to be
transmitted to the checkpoint terminal based at least in part on
the request.
27. The method of claim 26 wherein the checkpoint terminal
comprises a point-of-sale terminal and the account data comprises
account identifying information that is usable by the point-of-sale
terminal to perform a purchase transaction with a payment
processor.
28. The method of claim 26 wherein the checkpoint terminal
comprises at a security barrier and the account data comprises an
authorization credential of the user.
29. The method of claim 26 wherein the wearable device transmits
account data to the checkpoint terminal using a near-field
communication channel.
30. The method of claim 22 further comprising: subsequently to
storing the received user account data, receiving, by the wearable
device, a user selection of an account for which account data is to
be sent to the checkpoint terminal; and selecting the subset of the
stored account data to be transmitted to the checkpoint terminal
based at least in part on the user selection.
31. The method of claim 22 further comprising: receiving, by the
wearable device, a user request to load account data onto the
wearable device; and transmitting, by the wearable device, a
request for user account data to the host device in response to the
user request, wherein the wearable device transmits the request
during the verified communication session.
32. A wearable device comprising: a communication interface; a
storage medium; a sensor to detect whether the wearable device is
being worn; and a processor coupled to the communication interface,
the storage medium, and the sensor, the processor configured to:
establish a verified communication session with a host device, the
verified communication session being established while the wearable
device is being worn; receive user account data from the host
device during the verified communication session; store the
received user account data in the storage medium; provide a subset
of the received user account data to a checkpoint terminal; and
delete the stored user account data from the storage medium in the
event that the wearable device ceases to be worn.
33. The wearable device of claim 32 wherein the user account data
comprises identifying information for a financial account of the
user and the identifying information is sufficient to perform a
financial transaction using the financial account of the user.
34. The wearable device of claim 32 wherein the processor is
further configured to: receive a request from the checkpoint
terminal for account data; and select the subset of the stored
account data to be transmitted to the checkpoint terminal based at
least in part on the request.
35. The wearable device of claim 34 wherein the checkpoint terminal
comprises a point-of-sale terminal and the account data comprises
account identifying information that is usable by the point-of-sale
terminal to perform a purchase transaction with a payment
processor.
36. The wearable device of claim 34 wherein the checkpoint terminal
is at a security barrier and the account data comprises an
authorization credential of the user.
37. The wearable device of claim 34 wherein the communication
interface comprises a near-field communication interface and the
account data is sent to the checkpoint via using a near-field
communication interface.
38. The wearable device of claim 32 further comprising a user
interface, wherein the processor is further configured to select
the subset of the stored account data to be transmitted to the
checkpoint terminal based at least in part on user input received
at the user interface.
39. A computer-readable storage medium having stored thereon
program instructions that, when executed by a processor in a
wearable device, cause the wearable device to execute a method
comprising: establishing a verified communication session with a
host device, the verified communication session being established
while the wearable device is being worn; receiving user account
data from the host device during the verified communication
session; storing the received user account data in a storage medium
of the wearable device; providing a subset of the received user
account data to a checkpoint terminal; and in the event that the
wearable device ceases to be worn, deleting the stored user account
data from the storage medium.
40. The computer-readable storage medium of claim 39 wherein the
user account data comprises identifying information for a financial
account of the user and the identifying information is sufficient
to perform a financial transaction using the financial account of
the user.
41. The computer-readable storage medium of claim 39 wherein
establishing the verified communication session comprises
establishing a session key and wherein the user account data is
received in an encrypted form, the method further comprising:
decrypting the received user account data using the session
key.
42. The computer-readable storage medium of claim 39 wherein the
method further comprises: subsequently to storing the received user
account data, receiving a request from the checkpoint terminal for
account data; and selecting the subset of the stored account data
to be transmitted to the checkpoint terminal based at least in part
on the request.
43. The computer-readable storage medium of claim 42 wherein the
checkpoint terminal comprises a point-of-sale terminal and the
account data comprises account identifying information that is
usable by the point-of-sale terminal to perform a purchase
transaction with a payment processor.
44. The computer-readable storage medium of claim 39 wherein the
method further comprises: subsequently to storing the received user
account data, receiving a user selection of an account for which
account data is to be sent to the checkpoint terminal; and
selecting the subset of the stored account data to be transmitted
to the checkpoint terminal based at least in part on the user
selection.
45. The computer-readable storage medium of claim 39 wherein the
method further comprises: receiving, by the wearable device, a user
request to load account data onto the wearable device; and
transmitting, by the wearable device, a request for user account
data to the host device in response to the user request, wherein
the wearable device transmits the request during the verified
communication session.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application claims priority to commonly-owned
International Application No. PCT/US/2013/032529, filed Mar. 15,
2013, entitled "Facilitating Transactions with a User Account Using
a Wireless Device," the disclosure of which is incorporated herein
by reference in its entirety.
BACKGROUND
[0002] The present disclosure relates generally to wearable
electronic devices and in particular to a wearable device that can
facilitate access to another (host) device.
[0003] Mobile electronic devices, such as mobile phones, smart
phones, tablet computers, media players, and the like, have become
quite popular. Many users carry a device almost everywhere they go
and use their devices for a variety of purposes, including making
and receiving phone calls, sending and receiving text messages and
emails, navigation (e.g., using maps and/or a GPS receiver),
purchasing items in stores (e.g., using contactless payment
systems), and/or accessing the Internet (e.g., to look up
information).
[0004] However, a user's mobile device is not always readily
accessible. For instance, when a mobile device receives a phone
call, the device may be in a user's bag or pocket, and the user may
be walking, driving, carrying something, or involved in other
activity that makes it inconvenient or impossible for the user to
reach into the bag or pocket to find the device.
SUMMARY
[0005] Certain embodiments of the present invention relate to
wearable electronic devices that can be connected (e.g., via
wireless pairing) with another device (referred to herein as a
"host device"), such as a smart phone, other mobile phone, tablet
computer, media player, laptop computer, or the like. When paired,
the wearable device can provide access to various functionalities
of the host device.
[0006] Certain embodiments relate to using a wearable device to
facilitate a purchase transaction with a point-of-sale terminal in
a store. In some embodiments, the wearable device can facilitate
creation of a purchase order, e.g., by obtaining product
information for products of interest as selected by the user. As
the user selects products to purchase, the user can operate the
wearable device to add each product to a purchase order. After
selecting one or more desired products, the user can proceed to a
point-of-sale ("POS") terminal located somewhere in the store. The
wearable device can establish communication with the POS terminal,
e.g., using a near-field communication ("NFC") transceiver. The
wearable device can provide the purchase order to the POS terminal,
which can determine a final price for the transaction.
[0007] In some embodiments, a wearable device can also facilitate
payment for products in a purchase transaction. For example, a user
can store financial account identifying information (e.g., credit
card or debit card numbers and related information) in a wearable
device, e.g., by transferring the information from a host device
during a verified session. At a POS terminal, the user can select a
financial account to be used for a purchase transaction by
interacting with the wearable device, and the wearable device can
transmit the financial account identifying information to the POS
terminal, e.g., using an NFC communication channel. The POS
terminal can send a transaction request to a payment processor
associated with the financial account and receive a response, e.g.,
an approval of the transaction.
[0008] In some embodiments, a host device that is paired with the
wearable device can also participate in the purchase transaction.
For example, a wearable device at the POS terminal can communicate
with a host device (e.g., in a verified session) to obtain
financial account identifying information in real time. As another
example, the host device can communicate with the payment processor
to verify the transaction request.
[0009] To facilitate payment transactions and/or other transactions
involving access to a user's accounts, a user can store account
identifying information (also referred to as an "account
identifier" or "account ID") in a wearable device. The account
identifying information can be obtained from a host device during a
verified session in which the wearable device is being worn while
the host device and the wearable device are confirmed to be in
proximity to each other and in communication with each other. The
wearable device can store the account identifying information,
e.g., until it ceases to be worn.
[0010] In some embodiments, a wearable device can facilitate a
purchase transaction. For instance, the wearable device can obtain
product information (e.g., product name and/or price) for one or
more products to be purchased (e.g., by reading a computer-readable
tag such as a UPC bar code. QR code, or RFID tag as described
below) and can add the product information to a purchase order. The
wearable device can transmit the purchase order to a point-of-sale
terminal (e.g., using a near-field communication channel) and can
further communicate with the point-of-sale terminal to complete a
purchase transaction for the products.
[0011] In some instances, the wearable device can provide account
information for the user's payment account to the point-of-sale
terminal. For example, the wearable device can interact with the
user to obtain a user selection of a payment account, and the
wearable device can provide the account identifying information for
the selected payment account to the point-of-sale terminal. If the
account identifying information has been pre-loaded onto the
wearable device (e.g., in a verified session as described below),
the wearable device can retrieve the stored information.
Alternatively, the wearable device can communicate with a paired
host device to obtain account identifying information on an
as-needed basis. In either case, the wearable device can provide
account identifying information to the point-of-sale terminal,
allowing the point-of-sale terminal to perform a purchase
transaction with a payment processor.
[0012] In some embodiments, a wearable device can facilitate
management of user account data. e.g., by aiding the user in making
the data available when it is needed. For example, a wearable
device that is being worn can establish a verified communication
session with a host device. During the verified communication
session, the wearable device can receive user account data from the
host device during the verified communication session and can store
the received user account data in a local storage medium. The host
device can provide the account data in an encrypted form (e.g.,
using a session key that is specific to the verified communication
session). The wearable device can continue to store the user
account data until the wearable device ceases to be worn, at which
point the data can be deleted from the wearable device's local
storage. While the data is stored, the wearable device can, upon
request, provide a selected subset of the received user account
data to a checkpoint device (which can be any electronic device
capable of reading account data provided by the wearable device).
In some instances, the selection can be based on input from the
user; for instance, the user can operate a user interface of the
wearable device to select an account for which data is to be
provided at a checkpoint. In some instances, the selection can be
based on information received from a particular checkpoint device,
and the wearable device can automatically select an account, e.g.,
based on the identity of the checkpoint device.
[0013] Various types of account data can be managed. Examples
include identifying information for any of the user's financial
accounts, membership accounts (e.g., gyms, libraries), health
insurance accounts, accounts maintained with a service provider
(e.g., a doctor's office), public transit passes or debit-based
transit accounts, security credentials that may grant the user
access to restricted areas of a facility (e.g., an office
building), and so on. Examples of checkpoint devices capable of
receiving account data can include a point-of-sale terminal at a
store, a security barrier in a facility, a check-in desk (e.g., at
a gym, doctor's office, or the like), and so on.
[0014] The following detailed description together with the
accompanying drawings will provide a better understanding of the
nature and advantages of the present invention.
BRIEF DESCRIPTION OF THE DRAWINGS
[0015] FIG. 1 shows a wearable device communicating wirelessly with
a host device according to an embodiment of the present
invention.
[0016] FIG. 2 is a simplified block diagram of a wearable device
according to an embodiment of the present invention.
[0017] FIGS. 3A and 3B illustrate a user operating a wearable
device according to an embodiment of the present invention.
[0018] FIG. 4 is a flow diagram of a process for responding to an
event notification according to an embodiment of the present
invention.
[0019] FIG. 5 illustrates an interface for alerting a user
according to an embodiment of the present invention.
[0020] FIG. 6 illustrates another interface for alerting a user
according to an embodiment of the present invention.
[0021] FIG. 7 illustrates a user interface for selecting a
predefined message according to an embodiment of the present
invention.
[0022] FIG. 8 is a flow diagram of a process for generating an
event notification and receiving a response according to an
embodiment of the present invention.
[0023] FIG. 9 is a flow diagram of a process for initiating a
phone-call functionality of a host device according to an
embodiment of the present invention.
[0024] FIG. 10 illustrates a function-selection user interface
according to an embodiment of the present invention.
[0025] FIG. 11 illustrates a user interface for placing a call
according to an embodiment of the present invention.
[0026] FIG. 12 illustrates a keypad user interface according to an
embodiment of the present invention.
[0027] FIG. 13 illustrates a contacts user interface according to
an embodiment of the present invention.
[0028] FIG. 14 is a flow diagram of a process for placing a call
using a wearable device according to an embodiment of the present
invention.
[0029] FIG. 15 is a flow diagram of a process for sending a text
message using a wearable device according to an embodiment of the
present invention.
[0030] FIG. 16 illustrates a user interface for selecting a
predefined message according to an embodiment of the present
invention.
[0031] FIG. 17 is a flow diagram of a process for establishing a
verified session according to an embodiment of the present
invention.
[0032] FIG. 18 is a flow diagram of a process for responding to a
confirmation request from a host device during a verified session
according to an embodiment of the present invention.
[0033] FIG. 19 is a flow diagram of a process for establishing a
verified session according to an embodiment of the present
invention.
[0034] FIG. 20 is a flow diagram of a process for unlocking a host
device according to an embodiment of the present invention.
[0035] FIG. 21 shows a simplified state diagram for a host device
according to an embodiment of the present invention.
[0036] FIG. 22 shows a simplified state diagram for a wearable
device according to an embodiment of the present invention.
[0037] FIG. 23 is a flow diagram of a process for establishing a
verified session and a user ID according to an embodiment of the
present invention.
[0038] FIG. 24 is a flow diagram of a process for receiving and
responding to request for a user ID assignment according to an
embodiment of the present invention.
[0039] FIG. 25 illustrates an example of an interface screen for
confirming a user ID assignment according to an embodiment of the
present invention.
[0040] FIG. 26 is a flow diagram of a process for obtaining account
identifiers that can be implemented in a wearable device according
to an embodiment of the present invention.
[0041] FIG. 27 illustrates a user interface screen according to an
embodiment of the present invention.
[0042] FIG. 28 is a flow diagram of a process for providing account
identifiers to a wearable device according to an embodiment of the
present invention.
[0043] FIG. 29 is a flow diagram of a process for defining a
purchase transaction according to an embodiment of the present
invention.
[0044] FIG. 30 illustrates an interface screen that can be used for
managing a purchase order according to an embodiment of the present
invention.
[0045] FIG. 31 illustrates an interface screen that can be used for
adding an item to a purchase order according to an embodiment of
the present invention.
[0046] FIG. 32 is a flow diagram of a process for conducting a
purchase transaction according to an embodiment of the present
invention.
[0047] FIG. 33 illustrates a payment interface screen according to
an embodiment of the present invention.
[0048] FIG. 34 is a flow diagram of a process that can be executed
by a point-of-sale terminal to complete a purchase transaction with
a wearable device according to an embodiment of the present
invention.
[0049] FIG. 35 shows a message-passing diagram for completing a
purchase according to an embodiment of the present invention.
[0050] FIG. 36 shows a message-passing diagram for completing a
purchase according to another embodiment of the present
invention.
[0051] FIG. 37 shows a message-passing diagram for completing a
purchase according to another embodiment of the present
invention.
DETAILED DESCRIPTION
[0052] Certain embodiments of the present invention relate to
wearable electronic devices that can be connected (e.g., via
wireless pairing) with another device (referred to herein as a
"host device"), such as a smart phone, other mobile phone, tablet
computer, media player, laptop computer, or the like. When paired,
the wearable device can provide access to various functionality of
the host device.
[0053] In some embodiments, a wearable device can be operated by a
user to respond to an event notification generated by a host
device. The wearable device can receive a notification of the event
from the host device and present the user with an alert and a
prompt to respond. If the user responds to the prompt, the wearable
device can transmit the response to the host device. For example, a
user can respond to a phone call, text message, or other
communication received at the host device.
[0054] In some embodiments, a wearable device can be operated by a
user to initiate a functionality of a host device, independently of
any prior event notification. For example, the wearable device can
present a user interface via which the user can select a
functionality to be invoked and further interfaces to control that
functionality. Accordingly, a user can operate a wearable device to
provide a phone number and instruct a host device to place a phone
call to that number, or a user can operate a wearable device to
send a text message to a specified recipient, or a user can operate
a wearable device to control media playback and/or any other
functionality available on a particular host device.
[0055] FIG. 1 shows a wearable device 100 communicating wirelessly
with a host device 102 according to an embodiment of the present
invention. In this example, wearable device 100 is shown as a
wristwatch-like device with a face portion 104 connected to straps
106a, 106b.
[0056] Face portion 104 can include, e.g., a touchscreen display
105 that can be appropriately sized depending on where on a user's
person wearable device 100 is intended to be worn. A user can view
information presented by wearable device 100 on touchscreen display
105 and provide input to wearable device 100 by touching
touchscreen display 105. In some embodiments, touchscreen display
105 can occupy most or all of the front surface of face portion
104.
[0057] Straps 106a, 106b can be provided to allow device 100 to be
removably worn by a user, e.g., around the user's wrist. In some
embodiments, straps 106a, 106b can be made of any flexible material
(e.g., fabrics, flexible plastics, leather, chains or flexibly
interleaved plates or links made of metal or other rigid materials)
and can be connected to face portion 104, e.g., by hinges.
Alternatively, straps 106a, 106b can be made of a rigid material,
with one or more hinges positioned at the junction of face 104 and
proximal ends 112a, 112b of straps 106a, 106b and/or elsewhere
along the lengths of straps 106a, 106b to allow a user to put on
and take off wearable device 100. Different portions of straps
106a. 106b can be made of different materials; for instance,
flexible or expandable sections can alternate with rigid sections.
In some embodiments, one or both of straps 106a, 106b can include
removable sections, allowing wearable device 100 to be resized to
accommodate a particular user's wrist size. In some embodiments,
straps 106a, 106b can be portions of a continuous strap member that
runs behind or through face portion 104. Face portion 104 can be
detachable from straps 106a. 106b; permanently attached to straps
106a, 106b; or integrally formed with straps 106a, 106b.
[0058] The distal ends of straps 106a. 106b opposite face portion
104 can provide complementary clasp members 108a, 108b that can be
engaged with each other to secure the distal ends of straps 106a,
106b to each other, forming a closed loop. In this manner, device
100 can be secured to a user's person, e.g., around the user's
wrist; clasp members 108a. 108b can be subsequently disengaged to
facilitate removal of device 100 from the user's person. The design
of clasp members 108a, 108b can be varied; in various embodiments,
clasp members 108a, 108b can include buckles, magnetic clasps,
mechanical clasps, snap closures, etc. In some embodiments, one or
both of clasp members 108a, 108b can be movable along at least a
portion of the length of corresponding strap 106a, 106b, allowing
wearable device 100 to be resized to accommodate a particular
user's wrist size.
[0059] Straps 106a, 106b can be two distinct segments, or they can
be formed as a continuous band of an elastic material (including,
e.g., elastic fabrics, expandable metal links, or a combination of
elastic and inelastic sections), allowing wearable device 100 to be
put on and taken off by stretching a band formed straps 106a, 106b.
In such embodiments, clasp members 108a, 108b can be omitted.
[0060] Straps 106a, 106b and/or clasp members 108a, 108b can
include sensors that allow wearable device 100 to determine whether
it is being worn at any given time. Wearable device 100 can operate
differently depending on whether it is currently being worn or not.
For example, wearable device 100 can inactivate various user
interface and/or RF interface components when it is not being worn.
In addition, in some embodiments, wearable device 100 can notify
host device 102 when a user puts on or takes off wearable device
100.
[0061] Host device 102 can be any device that communicates with
wearable device 100. In FIG. 1, host device 102 is shown as a smart
phone; however, other host devices can be substituted, such as a
tablet computer, a media player, any type of mobile phone, a laptop
or desktop computer, or the like. Other examples of host devices
can include point-of-sale terminals, security systems,
environmental control systems, and so on. Host device 102 can
communicate wirelessly with wearable device 100, e.g., using
protocols such as Bluetooth or Wi-Fi. In some embodiments, wearable
device 100 can include an electrical connector 110 that can be used
to provide a wired connection to host device 102 and/or to other
devices, e.g., by using suitable cables. For example, connector 110
can be used to connect to a power supply to charge an onboard
battery of wearable device 100.
[0062] In some embodiments, wearable device 100 and host device 102
can interoperate to enhance functionality available on host device
102. For example, wearable device 100 and host device 102 can
establish a pairing using a wireless communication technology such
as Bluetooth. While the devices are paired, host device 102 can
send notifications of selected events (e.g., receiving a phone
call, text message, or email message) to wearable device 100, and
wearable device 100 can present corresponding alerts to the user.
Wearable device 100 can also provide an input interface via which a
user can respond to an alert (e.g., to answer a phone call or reply
to a text message). In some embodiments, wearable device 100 can
also provide a user interface that allows a user to initiate an
action on host device 102, such as placing a phone call, sending a
text message, or controlling media playback operations of host
device 102. Techniques described herein can be adapted to allow a
wide range of host device functions to be enhanced by providing an
interface via wearable device 100.
[0063] It will be appreciated that wearable device 100 and host
device 102 are illustrative and that variations and modifications
are possible. For example, wearable device 100 can be implemented
in any wearable article, including a watch, a bracelet, a necklace,
a ring, a belt, a jacket, or the like. In some instances, wearable
device 100 can be a clip-on device or pin-on device that has a clip
or pin portion that attaches to the user's clothing. The interface
portion (including, e.g., touchscreen display 105) can be attached
to the clip or pin portion by a retractable cord, and a user can
easily pull touchscreen display 105 into view for use without
removing the clip or pin portion, then let go to return wearable
device 100 to its resting location. Thus, a user can wear device
100 in any convenient location.
[0064] Wearable device 100 can be implemented using electronic
components disposed within face portion 104, straps 106a, 106b,
and/or clasp members 108a, 108b. FIG. 2 is a simplified block
diagram of a wearable device 200 (e.g., implementing wearable
device 100) according to an embodiment of the present invention.
Wearable device 200 can include processing subsystem 202, storage
subsystem 204, user interface 206, RF interface 208, connector
interface 210, power subsystem 212, environmental sensors 214, and
strap sensors 216. Wearable device 200 can also include other
components (not explicitly shown).
[0065] Storage subsystem 204 can be implemented, e.g., using
magnetic storage media, flash memory, other semiconductor memory
(e.g., DRAM, SRAM), or any other non-transitory storage medium, or
a combination of media, and can include volatile and/or
non-volatile media. In some embodiments, storage subsystem 204 can
store media items such as audio files, video files, image or
artwork files; information about a user's contacts (names,
addresses, phone numbers, etc.); information about a user's
scheduled appointments and events; notes; and/or other types of
information, examples of which are described below.
[0066] In some embodiments, storage subsystem 204 can also store
one or more application programs to be executed by processing
subsystem 210 (e.g., video game programs, personal information
management programs, media playback programs, interface programs
associated with particular host devices and/or host device
functionalities, etc.).
[0067] User interface 206 can include any combination of input and
output devices. A user can operate input devices of user interface
206 to invoke the functionality of wearable device 200 and can
view, hear, and/or otherwise experience output from wearable device
200 via output devices of user interface 206.
[0068] Examples of output devices include display 220, speakers
222, and haptic output generator 224. Display 220 can be
implemented using compact display technologies, e.g., LCD (liquid
crystal display), LED (light-emitting diode), OLED (organic
light-emitting diode), or the like. In some embodiments, display
220 can incorporate a flexible display element or curved-glass
display element, allowing wearable device 200 to conform to a
desired shape. One or more speakers 222 can be provided using
small-form-factor speaker technologies, including any technology
capable of converting electronic signals into audible sound waves.
In some embodiments, speakers 222 can be used to produce tones
(e.g., beeping or ringing) and can but need not be capable of
reproducing sounds such as speech or music with any particular
degree of fidelity. Haptic output generator 224 can be, e.g., a
device that converts electronic signals into vibrations; in some
embodiments, the vibrations can be strong enough to be felt by a
user wearing wearable device 200 but not so strong as to produce
distinct sounds.
[0069] Examples of input devices include microphone 226, touch
sensor 228, and camera 229. Microphone 226 can include any device
that converts sound waves into electronic signals. In some
embodiments, microphone 226 can be sufficiently sensitive to
provide a representation of specific words spoken by a user; in
other embodiments, microphone 226 can be usable to provide
indications of general ambient sound levels without necessarily
providing a high-quality electronic representation of specific
sounds.
[0070] Touch sensor 228 can include, e.g., a capacitive sensor
array with the ability to localize contacts to a particular point
or region on the surface of the sensor and in some instances, the
ability to distinguish multiple simultaneous contacts. In some
embodiments, touch sensor 228 can be overlaid over display 220 to
provide a touchscreen interface (e.g., touchscreen interface 105 of
FIG. 1), and processing subsystem 202 can translate touch events
(including taps and/or other gestures made with one or more
contacts) into specific user inputs depending on what is currently
displayed on display 220.
[0071] Camera 229 can include, e.g., a compact digital camera that
includes an image sensor such as a CMOS sensor and optical
components (e.g. lenses) arranged to focus an image onto the image
sensor, along with control logic operable to use the imaging
components to capture and store still and/or video images. Images
can be stored, e.g., in storage subsystem 204 and/or transmitted by
wearable device 200 to other devices for storage. Depending on
implementation, the optical components can provide fixed focal
distance or variable focal distance; in the latter case, autofocus
can be provided. In some embodiments, camera 229 can be disposed
along an edge of face member 104 of FIG. 1, e.g., the top edge, and
oriented to allow a user to capture images of nearby objects in the
environment such as a bar code or QR code. In other embodiments,
camera 229 can be disposed on the front surface of face member 104,
e.g., to capture images of the user. Zero, one, or more cameras can
be provided, depending on implementation.
[0072] In some embodiments, user interface 206 can provide output
to and/or receive input from an auxiliary device such as a headset.
For example, audio jack 230 can connect via an audio cable (e.g., a
standard 2.5-mm or 3.5-mm audio cable) to an auxiliary device.
Audio jack 230 can include input and/or output paths. Accordingly,
audio jack 230 can provide audio to the auxiliary device and/or
receive audio from the auxiliary device. In some embodiments, a
wireless connection interface can be used to communicate with an
auxiliary device.
[0073] Processing subsystem 202 can be implemented as one or more
integrated circuits, e.g., one or more single-core or multi-core
microprocessors or microcontrollers, examples of which are known in
the art. In operation, processing system 202 can control the
operation of wearable device 200. In various embodiments,
processing subsystem 202 can execute a variety of programs in
response to program code and can maintain multiple concurrently
executing programs or processes. At any given time, some or all of
the program code to be executed can be resident in processing
subsystem 210 and/or in storage media such as storage subsystem
204.
[0074] Through suitable programming, processing subsystem 202 can
provide various functionality for wearable device 200. For example,
in some embodiments, processing subsystem 202 can execute an
operating system (OS) 232 and various applications for interfacing
with a host device, such as a phone-interface application 234, a
text-interface application 236, and/or a media interface
application 238. In some embodiments, some or all of these
application programs can interact with a host device, e.g., by
generating messages to be sent to the host device and/or by
receiving and interpreting messages from the host device. In some
embodiments, some or all of the application programs can operate
locally to wearable device 200. For example, if wearable device 200
has a local media library stored in storage subsystem 204, media
interface application 238 can provide a user interface to select
and play locally stored media items. Examples of interface
applications are described below.
[0075] In some embodiments, processing subsystem 202 can also
execute a host security process 260 that provides support for
establishing and maintaining a verified communication session with
a host device; examples of such processes are described below. A
verified communication session can provide an enhanced level of
security, and various operations of wearable device 200 and/or a
host device can be made conditional on whether a verified
communication session between the devices is in progress. For
instance, host security process 260 can facilitate unlocking a host
device when wearable device 200 is present, depending on whether a
verified session is in progress. User data 262 can include any
information specific to a user, such as identification information,
user-specified settings and preferences, customized information
(e.g., contacts, predefined text messages), and any other
user-related data. In some embodiments, executing applications and
processes can access user data 262 to facilitate operations;
examples are described below.
[0076] In some embodiments, processing subsystem 202 can also
execute a shopping module 264 that facilitates purchase of goods
and services. For example, as described below, shopping module 264
can create and manage a purchase order and can communicate with a
point-of-sale (POS) terminal to complete a purchase transaction.
Shopping module 264 can in some instances complete the purchase
transaction using financial account identifiers that can be stored
as user data 262.
[0077] RF (radio frequency) interface 208 can allow wearable device
200 to communicate wirelessly with various host devices. RF
interface 208 can include RF transceiver components such as an
antenna and supporting circuitry to enable data communication over
a wireless medium, e.g., using Wi-Fi (IEEE 802.11 family
standards), Bluetooth.RTM. (a family of standards promulgated by
Bluetooth SIG. Inc.), or other protocols for wireless data
communication. RF interface 208 can be implemented using a
combination of hardware (e.g., driver circuits, antennas,
modulators/demodulators, encoders/decoders, and other analog and/or
digital signal processing circuits) and software components. In
some embodiments, RF interface 208 can provide near-field
communication ("NFC") capability, e.g., implementing the ISO/IEC
18092 standards or the like; NFC can support wireless data exchange
between devices over a very short range (e.g., 20 centimeters or
less). Multiple different wireless communication protocols and
associated hardware can be incorporated into RF interface 208.
[0078] Connector interface 210 can allow wearable device 200 to
communicate with various host devices via a wired communication
path, e.g., using Universal Serial Bus (USB), universal
asynchronous receiver/transmitter (UART), or other protocols for
wired data communication. In some embodiments, connector interface
210 can provide a power port, allowing wearable device 200 to
receive power, e.g., to charge an internal battery. For example,
connector interface 210 can include a connector such as a mini-USB
connector or a custom connector, as well as supporting circuitry.
In some embodiments, the connector can be a custom connector that
provides dedicated power and ground contacts, as well as digital
data contacts that can be used to implement different communication
technologies in parallel; for instance, two pins can be assigned as
USB data pins (D+ and D-) and two other pins can be assigned as
serial transmit/receive pins (e.g., implementing a UART interface).
The assignment of pins to particular communication technologies can
be hardwired or negotiated while the connection is being
established. In some embodiments, the connector can also provide
connections for audio and/or video signals, which may be
transmitted to or from host device 202 in analog and/or digital
formats.
[0079] In some embodiments, connector interface 210 and/or RF
interface 208 can be used to support synchronization operations in
which data is transferred from a host device to wearable device 200
(or vice versa). For example, as described below, a user can
customize certain information for wearable device 200 (e.g., a
"favorite" contacts list and/or specific predefined text messages
that can be sent). While user interface 206 can support data-entry
operations, a user may find it more convenient to define customized
information on a separate device (e.g., a tablet or smartphone)
that has a larger interface (e.g., including a real or virtual
alphanumeric keyboard), then transfer the customized information to
wearable device 200 via a synchronization operation.
Synchronization operations can also be used to load and/or update
other types of data in storage subsystem 204, such as media items,
application programs, and/or operating system programs.
Synchronization operations can be performed in response to an
explicit user request and/or automatically, e.g., when wireless
device 200 resumes communication with a particular host device or
in response to either device receiving an update to its copy of
synchronized information.
[0080] Environmental sensors 214 can include various electronic,
mechanical, electromechanical, optical, or other devices that
provide information related to external conditions around wearable
device 200. Sensors 214 in some embodiments can provide digital
signals to processing subsystem 202, e.g., on a streaming basis or
in response to polling by processing subsystem 202 as desired. Any
type and combination of environmental sensors can be used; shown by
way of example are accelerometer 242, a magnetometer 244, a
gyroscope 246, and a GPS receiver 248.
[0081] Some environmental sensors can provide information about the
location and/or motion of wearable device 200. For example,
accelerometer 242 can sense acceleration (relative to freefall)
along one or more axes, e.g., using piezoelectric or other
components in conjunction with associated electronics to produce a
signal. Magnetometer 244 can sense an ambient magnetic field (e.g.,
Earth's magnetic field) and generate a corresponding electrical
signal, which can be interpreted as a compass direction. Gyroscopic
sensor 246 can sense rotational motion in one or more directions,
e.g., using one or more MEMS (micro-electro-mechanical systems)
gyroscopes and related control and sensing circuitry. Global
Positioning System (GPS) receiver 248 can determine location based
on signals received from GPS satellites.
[0082] Other sensors can also be included in addition to or instead
of these examples. For example, a sound sensor can incorporate
microphone 226 together with associated circuitry and/or program
code to determine, e.g., a decibel level of ambient sound.
Temperature sensors, proximity sensors, ambient light sensors, or
the like can also be included.
[0083] Strap sensors 216 can include various electronic,
mechanical, electromechanical, optical, or other devices that
provide information as to whether wearable device 200 is currently
being worn. For instance, clasp sensor 250 can be at least
partially disposed within either or both of clasp members 108a,
108b of FIG. 1 and can detect when clasp members 108a, 108b are
engaged with each other or disengaged from each other. For example,
engaging clasp members 108a, 108b to each other can complete an
electrical circuit, allowing current to flow through clasp sensor
250; disengaging clasp members 108a, 108b from each other can break
the circuit. As another example, one or more contact sensors 252
can be disposed in straps 106a, 106b and can detect contact with a
user's skin, e.g., based on capacitive sensing, galvanic skin
response, or the like. Contact sensors 252 can also include
pressure sensors (e.g., piezoelectric devices) or the like. Any
other type of sensor that indicates whether wearable device 200 is
currently being worn can be used in addition to or instead of strap
sensors 216. For instance, physiological or biometric sensors, such
as pulse sensors, ECG sensors, or the like can be provided. In some
embodiments, physiological or biometric sensors can be used in
verifying the identity of the wearer of wearable device 200.
[0084] Power subsystem 212 can provide power and power management
capabilities for wearable device 200. For example, power subsystem
212 can include a battery 240 (e.g., a rechargeable battery) and
associated circuitry to distribute power from battery 240 to other
components of wearable device 200 that require electrical power. In
some embodiments, power subsystem 212 can also include circuitry
operable to charge battery 240, e.g., when connector interface 210
is connected to a power source. In some embodiments, power
subsystem 212 can include a "wireless" charger, such as an
inductive charger, to charge battery 240 without relying on
connector interface 210. In some embodiments, power subsystem 212
can also include other power sources, such as a solar cell, in
addition to or instead of battery 240.
[0085] In some embodiments, power subsystem 212 can control power
distribution to components within wearable device 200 to manage
power consumption efficiently. For example, power subsystem 212 can
automatically place device 200 into a "hibernation" state when
strap sensors 216 indicate that device 200 is not being worn. The
hibernation state can be designed to reduce power consumption;
accordingly, user interface 206 (or components thereof), RF
interface 208, connector interface 210, and/or environmental
sensors 214 can be powered down (e.g., to a low-power state or
turned off entirely), while strap sensors 216 are powered up
(either continuously or at intervals) to detect when a user puts on
wearable device 200. As another example, in some embodiments, while
wearable device 200 is being worn, power subsystem 212 can turn
display 220 and/or other components on or off depending on motion
and/or orientation of wearable device 200 detected by environmental
sensors 214. For instance, if wearable device 200 is designed to be
worn on a user's wrist, power subsystem 212 can detect raising and
rolling of a user's wrist, as is typically associated with looking
at a wristwatch, based on information provided by accelerometer
242. In response to this detected motion, power subsystem 212 can
automatically turn display 220 and/or touch sensor 228 on;
similarly, power subsystem 212 can automatically turn display 220
and/or touch sensor 228 off in response to detecting that user's
wrist has returned to a neutral position (e.g., hanging down).
[0086] Power subsystem 212 can also provide other power management
capabilities, such as regulating power consumption of other
components of wearable device 200 based on the source and amount of
available power, monitoring stored power in battery 240, generating
user alerts if the stored power drops below a minimum level, and so
on.
[0087] In some embodiments, control functions of power subsystem
212 can be implemented using programmable or controllable circuits
operating in response to control signals generated by processing
subsystem 202 in response to program code executing thereon, or as
a separate microprocessor or microcontroller.
[0088] It will be appreciated that wearable device 200 is
illustrative and that variations and modifications are possible.
For example, strap sensors 216 can be omitted, and wearable device
200 can include a user-operable control (e.g., a button or switch)
that the user can operate to indicate when wearable device 200 is
being worn. Controls can also be provided, e.g., to turn on or off
display 220, mute or unmute sounds from speakers 222, etc. In some
embodiments, other environmental sensors (e.g., accelerometer 242)
can be used to determine whether wearable device 200 is being worn,
in addition to or instead of strap sensors 216. Wearable device 200
can include any types and combination of sensors and in some
instances can include multiple sensors of a given type.
[0089] In various embodiments, a user interface can include any
combination of any or all of the components described above, as
well as other components not expressly described. For example, in
some embodiments, the user interface can include, e.g., just a
touchscreen, or a touchscreen and a speaker, or a touchscreen and a
haptic device. Where the wearable device has an RF interface, a
connector interface can be omitted, and all communication between
the wearable device and other devices can be conducted using
wireless communication protocols. A wired power connection, e.g.,
for charging a battery of the wearable device, can be provided
separately from any data connection.
[0090] Further, while the wearable device is described with
reference to particular blocks, it is to be understood that these
blocks are defined for convenience of description and are not
intended to imply a particular physical arrangement of component
parts. Further, the blocks need not correspond to physically
distinct components. Blocks can be configured to perform various
operations. e.g., by programming a processor or providing
appropriate control circuitry, and various blocks might or might
not be reconfigurable depending on how the initial configuration is
obtained. Embodiments of the present invention can be realized in a
variety of apparatus including electronic devices implemented using
any combination of circuitry and software.
[0091] A host device such as host device 102 of FIG. 1 can be
implemented as an electronic device using blocks similar to those
described above (e.g., processors, storage media, user interface
devices, data communication interfaces, etc.) and/or other blocks
or components. Those skilled in the art will recognize that any
electronic device capable of communicating with a particular
wearable device can act as a host device with respect to that
wearable device.
[0092] Communication between a host device and a wireless device
can be implemented according to any communication protocol (or
combination of protocols) that both devices are programmed or
otherwise configured to use. In some instances, standard protocols
such as Bluetooth protocols can be used. In some instances, a
custom message format and syntax (including, e.g., a set of rules
for interpreting particular bytes or sequences of bytes in a
digital data transmission) can be defined, and messages can be
transmitted using standard serial protocols such as a virtual
serial port defined in certain Bluetooth standards. Embodiments of
the invention are not limited to particular protocols, and those
skilled in the art with access to the present teachings will
recognize that numerous protocols can be used.
[0093] In some embodiments, wearable device 200 can detect a
transition from an "idle" position to an "active" position. For
example, FIGS. 3A and 3B illustrate a user 300 wearing wearable
device 302, which in this example is a wrist-worn device. As shown
in FIG. 3A, when user 300 is not actively using wearable device
302, the user's arm 304 may hang naturally at his side. To begin
using wearable device 302, user 300 can rotate his arm to the
position 304' shown in FIG. 3B, raising the elbow to bring wearable
device 302 into his line of sight. Dashed line 306 indicates an
approximate motion path of wearable device 302. Motion sensors
(e.g., accelerometer 242 and/or gyroscopic sensor 246) can detect a
characteristic motion associated with bringing wearable device 302
into the user's line of sight; upon detecting this motion, wearable
device 302 can automatically prepare itself to be used, e.g., by
activating user interface components such as display 220 and/or
touch sensor 228. Other patterns of motion can also be detected and
can trigger activation of user interface components; for example,
shaking of the wrist or a specific motion pattern of the arm or
hand (e.g., moving in an "S" curve or circle or triangle). In some
embodiments, wearable device 302 (or other wearable devices
described herein) can have a button (e.g., on the side of face 104
in FIG. 1) that a user can toggle to turn on or off a touchscreen
interface; the button can be provided in addition to or instead of
motion-based detection of activation.
[0094] Referring again to FIG. 1, in some embodiments, host device
102 can send various event notifications to wearable device 100,
and the user can respond to the notifications via wearable device
100. For example, host device 102 can alert wearable device 100 to
incoming communications such as phone calls, text messages,
voicemail messages, email messages, and the like; upcoming meetings
or events; stock market events such as change in price of a
particular stock; location-based reminders; and/or any other event
that can be identified by host device 102. In some embodiments, the
user may be able to select which types of events should generate
notifications to wearable device 102, e.g., by interacting with a
settings menu provided on host device 102.
[0095] FIG. 4 is a flow diagram of a process 400 for responding to
an event notification according to an embodiment of the present
invention. Process 400 can be implemented in a wearable device,
e.g., wearable device 100 of FIG. 1 or wearable device 200 of FIG.
2, which can be interacting with host device 102. In some
embodiments, the implementation of process 400 can include program
code executed by a processor of wearable device 100.
[0096] At block 402, wearable device 100 can pair with a host
device, e.g., host device 102. For example, standard Bluetooth
pairing techniques can be used; other techniques for establishing a
wireless connection between two devices can be used. In some
embodiments, an initial pairing between two devices may involve
user interaction with one or both devices to confirm that the
pairing should be established. Once the initial pairing is
established, the two devices can automatically reconnect to each
other (without further user intervention) any time they come within
communication range and are operating their respective RF
transceivers.
[0097] At block 404, wearable device 100 can receive an event
notification from host device 102. For example, host device 102 can
send a notification indicating an incoming phone call, text
message, or email message. At block 406, wearable device 100 can
present an alert to the user and can prompt the user for a
response. The alert can include, e.g., an audible alert, a
vibration, a visual alert, or any combination of multiple alerts.
The prompt can include, e.g., a visual prompt on display 220, an
audio prompt (e.g., a voice prompt), or the like.
[0098] FIG. 5 illustrates an alert-and-prompt screen 500 that can
be displayed at block 406 when the event notification corresponds
to an incoming phone call. Screen 500 can show an identifier of the
caller 502; the identifier can be determined by host device 102
(e.g., based on a contacts list stored therein and/or caller
identifying information received by host device 102) and sent to
wearable device 100 as part of the event notification. Screen 500
can also prompt the user to respond to the call, e.g., by selecting
virtual button 504 to instruct the phone to answer the call,
virtual button 506 to instruct the phone to place the caller on
hold, virtual button 508 to instruct the phone to divert the call
to voicemail, and virtual button 510 to decline the call. Other
alerts and prompts can be used, depending on the type of event,
available response options, screen size of the wearable device,
user preferences, and similar design considerations.
[0099] In some embodiments, a sequence of screens can be presented
as part of prompting the user for a response. For example, FIG. 6
illustrates a prompt screen 600 that can be displayed at block 406
of process 400 when the event notification corresponds to an
incoming text message. Screen 600 shows an identifier of the sender
of the text 602; as with a phone caller, the identifier of a sender
of a text can be determined by host device 102 (e.g., based on a
contacts list stored therein and/or source identifying information
received by host device 102). Screen 600 can also show a preview of
the text message 604; in some embodiments, the user can scroll
(e.g., by sliding a finger up or down on a touchscreen) to view
more message content. Screen 600 can also prompt the user to
respond to the text, e.g., by selecting virtual button 606 to reply
to the text or virtual button 608 to exit from screen 600 without
responding.
[0100] If the user selects virtual button 606, a message selection
screen 700 as shown in FIG. 7 can be displayed, providing a menu of
predefined text messages from which the user can select. For
example, virtual button 702 can be selected to send a "yes"
message, virtual button 704 can be selected to send a "no" message;
virtual button 706 can be selected to send a "thanks" message; and
virtual button 708 can be selected to send a "later" message
indicating that the user will contact the sender later. It is to be
understood that buttons 702, 704, 706, 708 may not contain the full
text message to be sent but rather a short identifier. For example,
the "no" identifier on button 704 can be associated with a less
terse message such as "No, sorry," and the "later" identifier on
button 708 can be associated with a more specific message such as
"I'll call you later."
[0101] Referring again to FIG. 4, at block 408, wearable device 100
can receive a user input in response to the prompt. For example,
the user can select virtual buttons via one or more of screens 500,
600, or 700, depending on context and what the user desires to do.
At block 410, wearable device 100 can transmit a response message
to the host based on the received user input.
[0102] It is not required that a user actually respond to any
particular alert on wearable device 100. For example, in some
embodiments process 400 can simply time out and end at block 408 if
the user does not provide input within some fixed time period
(e.g., 1 minute, 2 minutes, 5 minutes); the time period can be
different for different types of events. As another example, a user
can select the "close" option (button 608) from a screen such as
screen 600, and this can be interpreted by wearable device 100 as
an indication that the user does not intend to respond. In some
instances, a user may instead choose to respond to an alert by
using host device 102 directly; in such cases, host device 102 can
notify wearable device 100 if a response is received directly at
host device 102.
[0103] FIG. 8 is a flow diagram of a process 800 for generating an
event notification and receiving a response according to an
embodiment of the present invention. Process 800 can be implemented
in a host device, e.g., host device 102 of FIG. 1, which can be
interacting with a wearable device 100 that executes process 400 of
FIG. 4 or similar processes. In some embodiments, the
implementation of process 800 can include program code executed by
a processor of host device 102.
[0104] At block 802, host device 102 can detect an event that
triggers a user alert, such as an incoming call or text message. At
block 804, host device 102 can determine whether a wearable device
(e.g., wearable device 100) is currently paired. If not, then at
block 806, host device 102 can wait for a user input at its local
interface to determine whether and how the user chooses to
respond.
[0105] If wearable device 100 is currently paired, then at block
808, host device 102 can send an event notification to wearable
device 100. Any communication protocol can be used, including
standard Bluetooth messages (e.g., incoming call alert), a message
that conforms to a customized serial protocol that can be
transmitted using Bluetooth's virtual serial port capability, or
messages conforming to other protocols that are mutually understood
by the host device and the wearable device. The notification can
include information identifying the type of event (e.g., incoming
phone call, text message received, stock market alert, etc.) and
additional details specific to the event (e.g., name or other
identifier of the caller, content of a text message, etc.).
[0106] At block 810, host device 102 can wait for a response, which
can come from either the wearable device or a local user interface
of host device 102. For example, a user may receive an alert of an
incoming call on wearable device 100 but choose to answer the call
using host device 102. Accordingly, host device 102 can monitor
activity on the connection to wearable device 100 to detect a
response and at the same time present a local interface (e.g., on
its own touchscreen display) and monitor that interface to detect a
response.
[0107] At block 812, host device 102 can process the received
response, regardless of whether it was received from wearable
device 100 or via a local user interface of host device 102. For
example, referring to FIG. 5, if a user selects one of virtual
buttons 504, 506, 508, 510 from screen 500 on wearable device 100,
host device 102 can receive a response from wearable device 100
indicating which button was selected. In response to answer button
504 being selected, host device 102 can answer the call; call audio
can be routed to wearable device 100 or to another audio
input/output device, such as an internal audio interface of host
device 102 or a wireless headset that is paired with or otherwise
in communication with host device 102. In response to hold button
506 being selected, host device 102 can answer the call and play a
message to the caller indicating that the caller should hold. The
user can later take the call off hold, e.g., via a local user
interface of host device 102 or via wearable device 100, allowing
the user to speak with the caller. In response to voicemail button
508 being selected, host device 102 can redirect the call to a
voicemail account associated with the user, allowing the caller to
leave a message. In response to decline button 510 being selected,
host device 102 can reject or terminate the call.
[0108] As another example, referring to FIG. 7, if a user selects
to reply to a text message with a predefined response, e.g., by
selecting one of buttons 702, 704, 706, 708 on screen 700, host
device 102 can generate and send the corresponding text message
back to the sender. In some embodiments, wearable device 100 may
provide an index or other short name as an identifier for the text
message. Host device 102 can maintain a lookup table or other data
structure that maps the identifier to the actual message to be sent
(e.g., a short-name identifier such as "later" or an index such as
"3" can be mapped to "I'll call you later," which is the message
that would be sent). In some embodiments, a user can define a set
of text messages to be included in the predefined list by
interacting with host device 102, and host device 102 can provide
short names and/or other identifiers for the user-defined messages
to wearable device 100, e.g., in a synchronization operation.
[0109] It is not required that a user actually respond to a
particular alert, either locally on host device 102 or via wearable
device 100. In some instances, process 800 can allow the alert to
time out after a specific period (e.g., 1 minute, 2 minutes, 5
minutes) if the user does not respond, in which case process 800
can end at block 806 or 810. For example, if an incoming call is
not answered within the specified time period after generating the
alert, host device 102 can take a default action such as diverting
the call to a voicemail system. In some embodiments, if the user
does not respond within the specified time period, host device 102
can discontinue the alert and/or replace the alert with an
informational notice that is visible to the user (e.g., a
missed-call notification or the like).
[0110] It will be appreciated that processes 400 and 800 are
illustrative and that variations and modifications are possible.
Steps described as sequential may be executed in parallel, order of
steps may be varied, and steps may be modified, combined, added or
omitted. For instance, in some embodiments, a host device can
present a user alert via its own local interface in addition to
sending a notification to a wearable device; in some embodiments,
the host device presents a user alert via its own local user
interface only when the wearable device is not paired; and in some
embodiments, the user can specify whether the host should send a
particular notification to the wearable device, present an alert
locally, do both, or do neither. A user alert on a host device or a
wearable device can take the form of any sensory input detectable
by a human and can include visual alerts (e.g., lights; displayed
text, icons and or images), audible alerts (e.g., tones, buzzes,
ringtones, musical sounds, and/or speech sounds), and/or tactile
alerts (e.g., a vibration).
[0111] The particular response options described above, e.g., with
reference to FIGS. 5-7, are also illustrative, and the user may
have other options for responding to a given alert. Further, while
processes 400 and 800 have been described with reference to
specific types of events (incoming call, incoming text message), it
is to be understood that notifications of other types of events can
be processed in the same manner. For any type of event, the user
can have the option to select one of a set of responses (which may
be limited) via the wearable device's user interface or to use the
host device's local user interface to respond. In some instances,
the host device's interface can offer a larger or different range
of possible response options than the wearable device (e.g.,
composing an arbitrary message as opposed to selecting from a
finite set of predefined messages).
[0112] In some embodiments, in addition to or instead of responding
to an event on the host device, a user can use a wearable device to
initiate a functionality of the host device, e.g., placing a phone
call, sending a text message that is not in response to a received
text message, or initiating any other functionality that is
available on a particular host device. FIG. 9 is a flow diagram of
a process 900 for initiating a phone-call functionality of a host
device according to an embodiment of the present invention. Process
900 can be implemented in a wearable device, e.g., wearable device
100 of FIG. 1 or wearable device 200 of FIG. 2, which can be
interacting with a host device 102 that provides a telephone
transceiver capable of communicating over a phone network (e.g., a
cellular telephony network, voice-over-IP system, or the like). In
some embodiments, the implementation of process 900 can include
program code executed by a processor of wearable device 100.
[0113] At block 902, a user can select an option to place a call
using the user interface of wearable device 100. For example,
referring to FIG. 10, a user interface of wearable device 100 can
include a function selection screen 1000. Function selection screen
1000 can be a default screen that appears when the display of
wearable device 100 is activated or it can be a different screen
that the user can access through a touch gesture or sequence of
gestures (e.g., to navigate through menus) on a touchscreen
display, a hand or arm gesture detected by motion sensors built
into wearable device 100, or other operations. Function selection
screen 1000 can include various virtual buttons that the user can
select to invoke a functionality of host device 102, such as "call"
button 1002 to place a call, "text" button 1004 to send a text
message, and "music" button 1006 to invoke a media player
functionality of host device 102. In this example, a user can
select an option to place a call by selecting button 1002.
[0114] Referring again to FIG. 9, at block 904, wearable device 100
can determine whether it is currently paired with a host device 102
that is capable of making phone calls. If not, wearable device 100
can alert the user at block 906. The user can take corrective
action, such as getting within range of host device 102, turning
host device 102 on, etc.
[0115] Assuming wearable device 100 is paired with a phone-capable
host device 102, then at block 908, wearable device 100 can present
the user with calling options, and at block 910, wearable device
100 can receive user input selecting a calling option. For example,
when a user selects call button 1002 of FIG. 10, an interface such
as screen 1100 of FIG. 11 may be displayed. FIG. 11 shows options
for placing a call, such as an emergency call button 1102 that can
be programmed to place a call to a phone number associated with an
emergency service (such as 911 in the United States or 112 in many
European countries), a keypad button 1104 to allow a user to dial a
number, and a contacts button 1106 to allow a user to look up a
contact.
[0116] If the user selects keypad button 1104, wearable device 100
can present a keypad interface, such as screen 1200 of FIG. 12.
Screen 1200 includes a virtual phone keypad 1202 (e.g., a standard
phone keypad with digits 0-9 and "star" and "pound" keys) and a
number box 1204 to show the digits entered so far. In some
embodiments, other controls can be provided (e.g., back, cancel,
and done buttons); in some embodiments, gestures can be associated
with various control functions such as erasing a digit, canceling
the operation, or indicating that entry of the number is complete.
A user can operate keypad interface screen 1200 to dial an
arbitrary number.
[0117] If, from screen 1100 of FIG. 11, the user chooses contacts
button 1106, wearable device 100 can present a selectable contacts
list, such as screen 1300 of FIG. 13. Screen 1300 can present the
names of some or all of a user's contacts, e.g., as virtual buttons
1302, 1304, 1306, 1308. If the number of contacts exceeds the
available space on screen 1300, the list can be scrollable (e.g.,
using upward or downward gestures on a touchscreen) to allow the
user to view and select from any number of contacts.
[0118] Wearable device 100 can maintain various amounts of contact
information. For example, wearable device 100 can maintain a list
of names of the user's contacts, which it can obtain, e.g., via
synchronization operations with host device 102 or with other
devices. Wearable device 100 can maintain just the name and/or
other information about each contact (e.g., phone numbers, photos)
as desired. In some embodiments, a user can designate a subset of
her contacts to be synchronized with wearable device 100, and host
device 102 can have a larger list of contacts than wearable device
100 as well as more information about each contact. Alternatively,
wearable device 100 can obtain contact information from host device
102 in real time, e.g., with user-defined favorite contacts or
most-recently-contacted contacts being presented first and various
options to retrieve additional contacts. Accordingly, a user can
operate wearable device 100 to select a contact to be called.
[0119] Referring again to FIG. 9, once the user input that
determines a number to be called has been received (block 910),
process 900 can send a call instruction to host device 102 at block
912 to instruct host device 102 to place the call. In some
instances, e.g., where keypad screen 1200 was used, the call
instruction can include a phone number. In some instances, e.g.,
where contacts screen 1300 was used to select the party to be
called, the call instruction can include the selected contact's
name (or other unique identifier), from which host device 102 can
determine the phone number to be called, e.g., by looking up the
information in a user's contact list. Host device 102 can place the
call, and at block 914, wearable device 100 can receive
confirmation that the call has been placed. This confirmation can
indicate whether the call connected, or it can be sent before the
call is actually connected.
[0120] At block 916, wearable device 100 can receive and send
call-related audio signals, allowing the user to communicate with
the caller. Call-related audio signals can include input audio
signals (e.g., speech of the user picked up by a microphone and
delivered to the host device for transmission via the phone
network) and/or output audio signals (e.g., speech of the other
caller received at the host device via the phone network and
delivered to a speaker). In some instances, output and/or input
audio signals can be sent to and/or received from a built-in
speaker and/or microphone of wearable device 100. In other
instances, wearable device 100 can send output audio to and/or
receive input audio from external devices such as a wired or
wireless headset. It is not required that all call-related audio
signals, or indeed any call-related audio signals, be routed
through wearable device 100. For example, host device 102 can route
input (or output) audio to (or from) a device other than wearable
device 100 while using wearable device 100 to route the output (or
input) audio, and wearable device 100 can process the portion of
audio for which it is in the routing path. In some instances, all
call-related audio signals can be routed to and from devices other
than wearable device 100, in which case wearable device 100 would
not receive or send call-related audio signals but may simply wait
until the call is completed. In some embodiments, wearable device
100 can make other functions available to the user while a call is
in progress.
[0121] In some embodiments, while a call is in progress, wearable
device 100 can display a control operable by the user to end the
call. At block 918, if this control is operated, then at block 920,
wearable device 100 can alert host device 102 that the call should
be ended. Host device 102 can terminate the call and return a
confirmation to wearable device 100 at block 922. Wearable device
100 can present an alert to the user at block 924 to confirm that
the call has ended.
[0122] Host device 102 can also detect a call-termination event not
originating from wearable device 100, e.g., if the other party
disconnects or if the connection is dropped by the phone network.
If this occurs, host device 102 can send an event notification to
wearable device 100. Accordingly, if the user does not end the call
at block 918, then at block 926, wearable device 100 can determine
whether host device 102 has sent a call termination notification.
If so, then wearable device 100 can alert the user at block 924.
Otherwise, the call can continue (block 1408) until either the user
terminates it or the host detects a termination event.
[0123] FIG. 14 is a flow diagram of a process 1400 for placing a
call using a wearable device according to an embodiment of the
present invention. Process 1400 can be implemented in a host
device, e.g., host device 102 of FIG. 1, which can be interacting
with a wearable device 100 that executes process 900 of FIG. 9 or
similar processes, and host device 102 can provide a telephone
transceiver capable of communicating over a phone network (e.g., a
cellular telephony network, voice-over-IP system, or the like) In
some embodiments, the implementation of process 1400 can include
program code executed by a processor of host device 102.
[0124] At block 1402, host device 102 can receive a call
instruction from a paired wearable device 100 that instructs host
device 102 to place a phone call. The call instruction can include,
e.g., a phone number to be called or an identifier of a contact. At
block 1404, host device 102 can place the call. In some
embodiments, placing the call can include using the contact
identifier received at block 1402 to look up a corresponding phone
number. At block 1406, host device 102 can send a confirmation that
the call has been placed. The confirmation can be sent, e.g., while
the call is still being connected.
[0125] At block 1408, host device 102 can route the call-related
audio signals (including input and output audio signals as
described above with reference to FIG. 9) to and from appropriate
input and output devices. Audio input and output devices can
include an internal microphone or speaker of host device 102 andior
an external microphone or speaker connected to host device 102 by
wired or wireless connections, including in some instances wearable
device 100. In some embodiments, host device 102 can determine the
routing based on what other devices are currently connected to host
device 102 and/or user-specified preferences regarding audio
routing. Accordingly, call-related audio can be routed to wearable
device 100 or to another device. In some instances, input and
output audio can be routed differently; for example, host device
102 can receive input audio from wearable device 102 while
providing output audio to a different device.
[0126] At block 1410, host device 102 can determine whether
wearable device 102 has sent a message indicating that the call
should end. If so, then host device 102 can end the call at block
1412 and send confirmation to wearable device 100 at block
1414.
[0127] If, at block 1410, wearable device 102 has not indicated
that the call should end, then at block 1416, host device 100 can
determine whether it has received notification via the phone
network that the call has ended (e.g., that the other endpoint has
terminated the call or that the connection has been dropped). In
addition, in some embodiments, a user who operated wearable device
102 to place a particular call can operate the user interface of
host device 100 to end the call. If host device 102 detects any of
these call-ending events, then host device 100 can notify wearable
device 102 that the call has ended at block 1418. In some
embodiments, the notification at block 1418 can include an
indication of how the call ended (e.g., terminated by the other
endpoint, dropped call, etc.).
[0128] If, at block 1416, host device 100 does not detect that the
call has ended, then process 1400 can return to block 1408 to
continue to route audio for the call. Accordingly, the call can
continue until it is terminated by either party.
[0129] Similar processes can be used to send other types of
communication, such as text messaging. For example FIG. 15 is a
flow diagram of a process 1500 for sending a text message using a
wearable device. e.g., wearable device 100 of FIG. 1 or wearable
device 200 of FIG. 2, which can be interacting with a host device
102 that provides a telecommunication interface capable of
communicating text messages over a network (e.g., a cellular
telephony network, cellular data network, the Internet, or the
like) In some embodiments, the implementation of process 1500 can
include program code executed by a processor of wearable device
100.
[0130] At block 1502, a user can select an option to send a text
message, e.g., by selecting text button 1004 from interface screen
1000 of FIG. 10. At block 1504, wearable device 100 can determine
whether it is currently paired with a host device 102 that is
capable of making phone calls. If not, wearable device 100 can
alert the user at block 1506. The user can take corrective action,
such as getting within range of host device 102, turning host
device 102 on, etc.
[0131] At block 1508, wearable device 100 can present the user with
options for selecting a recipient, and at block 1510, wearable
device 100 can receive the user's selection. In some instances,
interface screens similar to those shown in FIGS. 11-13 can be
used. For example, the user can send a text to an arbitrary phone
number by entering the number into keypad 1202 of screen 1200, or
the user can select a contact from screen 1300. In some
embodiments, the same list of contacts can be used for both calls
and text messages; in other embodiments, a user can define
different lists of favorite contacts for different communication
media.
[0132] At block 1512, wearable device 100 can present the user with
options for texts to send, and at block 1514, wearable device 100
can receive the user's selection. For example, similarly to process
400 described above, a user can have a predefined list of texts to
send, allowing the user to avoid entering the text
character-by-character. FIG. 16 illustrates an interface screen
1600 for selecting a predefined text message that can be used at
block 1512. The predefined text messages can be different depending
on whether the user is initiating a new text message (as in process
1500) or responding to a received text message (as in process 400).
For example, button 1602 can be associated with a text such as "I'm
leaving now" and button 1604 with a text such as "I'm running
late," which are examples of text messages that a user might send
to a person she is going to meet. Button 1606 can be associated
with a text such as "Please call me," which requests the recipient
to take a particular action. Button 1608 can be associated with a
text such as "Do you need anything from the grocery store?" which a
user might send while on the way to the store. Other options can be
provided in addition to or instead of these examples, and in some
embodiments the user can define specific text messages and short
identifiers in a manner similar to that described above with
reference to FIG. 7.
[0133] In some embodiments, wearable device 100 can provide an
option to enter an arbitrary text using alphanumeric or other
character systems. For example, each character in a character
system can be mapped to a different touch gesture, and a user can
enter text by making touch gestures on touchscreen display 105. As
another example, each character can be mapped to a different
sequence of taps (e.g., Morse code or the like), and a user can
enter text by tapping touchscreen display 105. As yet another
example, touchscreen display 105 can present a compact virtual
keypad in which a character is determined based on the key location
and number of times the user taps the key.
[0134] At block 1516, wearable device 100 can instruct the host
device to send the text message and can provide an identifier of
the intended recipient (e.g., phone number or name) and an
identifier of the text to be sent; the identifier can be, e.g., an
index, a short identifier, or the actual text entered or selected
by the user. As in process 900 described above, host device 102 can
use the recipient identifier to determine the phone number, and as
in processes 400 and 800 described above, host device 102 can use a
short identifier of the text message to identify the actual message
to be sent. In some embodiments, at block 1518, wearable device 100
can receive a confirmation from host device 102 that the text was
sent and/or received; if desired, wearable device 100 can present a
corresponding alert or informational message to the user.
[0135] It will be appreciated that the communication-initiation
processes described above are illustrative and that variations and
modifications are possible. Steps described as sequential may be
executed in parallel, order of steps may be varied, and steps may
be modified, combined, added or omitted. Messages can be sent using
various communication media and formats, including text messages
(sent, e.g., via a short messaging service (SMS) provided by a
cellular communication network that carries voice and/or data);
email messages, instant messages, social-network messages (any of
which can be sent, e.g., via an Internet interface of the host
device); and other types of messages.
[0136] In some embodiments, a user can define "quick-access"
actions, such as "call Mom" or "text Bob that I'm running late"
that can be executed with a reduced number of input actions (e.g.,
a single gesture to bring up a quick-access list, followed by
tapping on the appropriate entry). This can facilitate
communication by and with users who are in the midst of other
activities and find it inconvenient to locate their phone to send a
quick message or place a call.
[0137] Control over host device functions is not limited to
communication functions. For example, in some embodiments, a host
device 102 can have media player capabilities, allowing a user to
select and play media tracks (e.g., audio and/or video), and
wearable device 100 can provide remote control over media playback
operations of a host device.
[0138] Referring again to FIG. 10, interface screen 1000 for
wearable device 100 includes a button 1006 that can be selected to
control media playback in a host device. In some embodiments, in
response to user selection of button 1006, wearable device 100 can
present an interface to select and control media player functions
of host device 102. For example, wearable device 100 can display
lists of playlists, albums, artists, genres, or songs from which
the user can select tracks to play; once a track is playing,
wearable device 100 can provide playback controls such as play,
pause, skip to previous or next track, rewind, fast-forward, volume
control and the like, and the user can control playback using touch
gestures on the display device.
[0139] In addition or instead, control can be provided based on
movement of wearable device 100 itself. For example,
accelerometers, gyroscopes, or the like can be used to detect
motion of wearable device 100, and certain motions can be defined
as spatial gestures, which in turn can be interpreted as controls.
Thus, in some embodiments, a user can control the volume, e.g., by
circling her wrist or arm clockwise to increase and
counterclockwise to lower. Other gestures can be associated with
other actions, e.g., a quick up-and-down to play, a quick
down-and-up to pause, quick right-then-left to skip ahead, quick
left-then-right to skip back, etc. Different gestures can be
associated with different control operations as desired.
[0140] It is to be understood that other devices can be controlled
by a wearable device. For example, a wearable device can provide
control over environmental systems (e.g., heating, lights) through
an appropriate user interface.
[0141] In some embodiments, wearable device 100 (or wearable device
200) can facilitate access to a host device. For example, many
users choose to "lock" various devices (e.g., mobile phones, tablet
computers, desktop or laptop computers) to prevent unauthorized
persons from operating the device. A host device that supports a
lock feature can require a user to define a passcode (or other
login credential(s) such as a username, secret gesture, or the
like) upon activating the lock feature. The host device can
thereafter require entry of the previously defined passcode (or
supplying of other credential(s)) in order to unlock the device,
e.g., when the device awakes from a sleep or screen-off or when a
user attempts to operate the device while in its locked state. Some
host devices can automatically enter the locked state after a
period of inactivity (e.g., 1 minute or 5 minutes), or they can
enter the locked state in response to a user input such as
operating a button to turn off a display of the mobile device.
Since some host devices (e.g., mobile phones) tend to be
sporadically used throughout the day, users may find themselves
entering their passcodes many times each day.
[0142] Some embodiments of the present invention can reduce the
need for a user to repeatedly enter a passcode into a host device.
For example, wearable device 100 can establish a "verified" session
with host device 102. When a user enters a passcode (or other login
credentials) into host device 102 while wearing wearable device 100
(e.g., while wearable device 100 is in close proximity to host
device 102), host device 102 can alert wearable device 100 to a
sign-in event. In response to the sign-in event, wearable device
100 and host device 102 can establish a verified communication
session, which can include establishing a session key (e.g., a
cryptographic key). Once established, the verified session can
continue until either the user removes the wearable device or the
devices stop communicating, for instance due to the devices moving
out of communication range (e.g., more than roughly 10 meters apart
in the case of Bluetooth). At any time during a verified session,
the host device can become locked, and the verified session can
continue with the host device locked. As long as the verified
session continues, the user can unlock the host device, e.g., by
bringing the wearable device into close proximity with the host
device. This can allow the host device to bypass a passcode
requirement (or a requirement for other credentials) and unlock
itself based on the presence of the wearable device and the
continuing verified session, without requiring the user to re-enter
a passcode.
[0143] In some embodiments, host device 102 can provide
user-identifying information to wearable device 100. e.g., based on
the credentials that were used to establish a verified session
between host device 102 and wearable device 100. Wearable device
100 can use the user-identifying information to perform various
operations such as establishing a persistent user identity for its
wearer, selecting user-specific messages to be displayed and/or
sent, customizing interfaces for a particular user's preferences
(e.g., color schemes, fonts, arrangement of menu options, etc.),
and so on.
[0144] Examples of processes that can allow a wearable device to
facilitate access to a host device will now be described. FIGS. 17
and 18 are flow diagrams of processes that can be executed by a
wearable device, e.g., wearable device 100 of FIG. 1, communicating
with a host device, e.g., host device 102 of FIG. 1. FIG. 17
illustrates a process 1700 for establishing a verified session
according to an embodiment of the present invention, and FIG. 18
illustrates a process 1800 for responding to a confirmation request
from a host device during a verified session according to an
embodiment of the present invention. In some embodiments, the
implementation of processes 1700 and 1800 can include program code
executed by a processor of wearable device 100 (e.g., as part of
host security program 260 of FIG. 2).
[0145] Referring to FIG. 17, process 1700 can begin at block 1702
when wearable device 100 detects a host device (e.g., host device
102) in close proximity. As used herein, "close proximity" refers
to a state in which the devices are within a short enough range of
each other to make it likely that the user wearing wearable device
100 is also operating host device 102. For example, if wearable
device 100 is a wrist-worn device and host device 102 is a mobile
device that would typically be operated while held in a user's
hand, it is likely that a user wearing wearable device 100 and
operating host device 102 would bring the two devices to within 30
or 60 centimeters of each other. Accordingly, some embodiments can
define a threshold distance for close proximity, e.g., at 30
centimeters, 60 centimeters, 100 centimeters, or any other value
between 30 and 100 centimeters. Other threshold distances can also
be specified. Whether two devices are in close proximity can be
determined by comparing the threshold distance to an estimated
distance between the devices.
[0146] Wearable device 100 can estimate the distance between itself
and host device 102 using various techniques. For example, some
versions of Bluetooth protocols provide a relative signal strength
indicator ("RSSI") that allows a receiving device to compare the
actual signal strength of a signal from a transmitting device to a
nominal signal strength associated with the transmitting device at
a nominal distance. Since signal strength decreases with increasing
distance, the receiver (e.g., wearable device 100) can use the RSSI
to estimate the distance to the transmitter (e.g., host device
102). Other wireless communication protocols can provide similar
techniques, and other techniques can also be used. In some
instances, either of host device 102 or wearable device 100 can
perform the distance estimation and determine whether the other of
wearable device 100 or host device 102 is in close proximity at any
given time, and either device can communicate its determination to
the other.
[0147] At block 1704, wearable device 100 can determine whether it
is currently paired with close-proximity host device 102. In some
embodiments, if the devices are not paired, then at block 1706, a
pairing process can be invoked. As described above, in some
embodiments, establishing an initial pairing may involve user
interaction with one or both devices to confirm that the pairing
should be established. Once the initial pairing is established, the
two devices can automatically reconnect to each other (without
further user intervention) any time they come within communication
range and are operating their respective RF transceivers.
[0148] Assuming the devices are paired, at block 1708, wearable
device 100 can receive a notification of a sign-in event from host
device 102. A sign-in event can correspond to any occurrence
detected by host device 102 that corresponds to the user unlocking
host device 102. For example, host device 102 can notify wearable
device 100 of a sign-in event when a user enters a correct passcode
(or other credential) to unlock host device 102.
[0149] At block 1710, in response to receiving the notification,
wearable device 100 can determine whether it is in a trusted state.
As used herein, a "trusted" state refers to a state in which a
sufficient likelihood exists that wearable device 100 is being worn
by the same user who is operating host device 102, and in various
embodiments, different criteria can be used to determine whether
this sufficient likelihood exists. In some embodiments, for
instance, wearable device 100 is determined to be in a trusted
state if the two following conditions are met: (a) wearable device
100 is currently being worn; and (b) wearable device 100 is in
close proximity (as defined above) to host device 102 at a time
correlated with the sign-in event. Whether condition (a) is
satisfied can be determined, for example, based on strap sensors
216 of FIG. 2 and/or other biometric or physiological sensors.
Whether condition (b) is satisfied can be determined, for example,
by checking the estimated distance at a time close in time (e.g.,
within a few microseconds) of receiving the sign-in notification at
block 1708. In some embodiments, other conditions can also be
applied in addition to or instead of conditions (a) and/or (b). For
example, a user identifier ("user ID" or just "ID") can be assigned
to wearable device 100 (some techniques for assigning a user ID are
described below), and the sign-in event notification can include a
user ID of the user who signed into host device 102; accordingly,
wearable device 102 can compare its assigned user ID with the
received user ID and can require that the user IDs match as a
further condition on being in a trusted state.
[0150] At block 1710, if wearable device 100 is not in a trusted
state, then at block 1712, wearable device 100 can interoperate
with host device 102 in an unverified session. Such operation can
include initiating and/or receiving communications (e.g., as
described above), controlling host device functionality via
wearable device 100, and so on. In some embodiments, some functions
of host device 102 may not be accessible to wearable device 100
while in an unverified session. For example, wearable device 100
may be usable to respond to a received communication (e.g., using
processes 400 and 800 described above) but not to initiate a
communication (e.g., using processes 900 and 1400 described
above).
[0151] If, however, at block 1710, wearable device 100 is in a
trusted state, then at block 1714, wearable device 100 can
establish a session key and a verified session with host device
102. The session key can incorporate a shared secret (i.e., any
information item that is known to wearable device 100 and host
device 102 but not generally known or readily determined by other
devices) and can be, e.g., a two-factor cryptographic key. Standard
cryptographic key-agreement protocols or other protocols for
establishing a shared secret can be used. The session key can be
usable to encrypt messages sent between host device 102 and
wearable device 100, either directly or by using the session key to
generate message keys. Particular algorithms and cryptographic
schemes can be selected, e.g., based on the level of security
desired. In some embodiments, establishing the session key and
verified session can include sending various communications between
host device 102 and wearable device 100, e.g., to confirm that a
verified session has been established at each side and/or to test
the session key.
[0152] Once a session key is established at block 1714, wearable
device 100 can operate in a verified session with host device 102.
Referring to FIG. 18, process 1800 can be a continuation of process
1700 and illustrates certain aspects of wearable device operation
in a verified session according to an embodiment of the present
invention.
[0153] At block 1802, wearable device 100 can interoperate with
host device 102 in a verified session. The verified session can be
established, e.g., in accordance with process 1700. In some
embodiments, wearable device 100 can access host device
functionality in a verified session that is not accessible in an
unverified session. For example, initiating a phone call, text
message, or other communication (e.g., as described above) may be
permitted only in a verified session. As another example, in some
embodiments, host device 102 can bypass a sign-in procedure when
transitioning from a locked state to an unlocked state if a
verified session is in progress.
[0154] During a verified session, the session key can be (but need
not be) used to encrypt communications between wearable device 100
and host device 102; some, all, or none of the communications can
be encrypted. Encryption can be selective, e.g., based on the
sensitivity of the data being communicated.
[0155] The verified session can last until a terminating event
occurs. For example, the session can be terminated if communication
with host device 102 is interrupted or lost. This can occur, for
example, if host device 102 (or its RF antenna) is powered down, if
the RF antenna of wearable device 100 is powered down, or if host
device 102 moves out of range of communication with wearable device
100 (e.g., a distance beyond about 10 meters for Bluetooth).
Accordingly, while the verified session is in progress, at block
1804, wearable device 100 can periodically determine whether host
device 102 is still present. For example, wearable device 100 can
listen for a "heartbeat" or other periodic signal indicating the
continued presence of host device 102, or wearable device 100 can
ping host device 102 and listen for a response. Communication of
information (e.g., an event notification) from host device 102 that
is received by wearable device 100 can also serve as confirmation
that host device 102 is still present. If contact with host device
102 is lost, then at block 1806, wearable device 100 can end the
verified session.
[0156] As another example, in some embodiments, a verified session
can be ended if wearable device 100 ceases to be worn by the user
(also referred to as being "taken off"). Accordingly, if host
device 102 remains in communication at block 1804, then at block
1808 wearable device 100 can determine if the user has taken off
wearable device 100. For example, strap sensors 216 of FIG. 2 or
other biometric sensors of wearable device 100 can be configured to
generate an interrupt or other notification to processing subsystem
202 in the event that a change occurs indicating that the user has
removed wearable device 100. Examples can include clasp sensors 250
detecting that clasp members 108a, 108b have become disengaged;
contact sensor 252 detecting a loss of pressure or galvanic skin
response; or pulse sensors, skin temperature sensors, and/or other
biometric sensors detecting cessation of biometric activity. Any
combination of sensor signals can be used to detect wearable device
100 being taken off. If wearable device 100 is taken off, the
verified session can end at block 1806.
[0157] Ending the verified session at block 1806 can include
various actions, such as updating state information of wearable
device 100 to indicate that it is not in a verified session,
destroying or invalidating the session key, and/or sending a
notification to host device 102 to report that wearable device 100
has ended the verified session. After ending the verified session,
wearable device 100 can continue to communicate with host device
102 (in an unverified session), and a new verified session can
subsequently be established (e.g., by performing process 1700 of
FIG. 17).
[0158] Assuming no event that ends the verified session has
occurred, the verified session can continue. From time to time, at
block 1810, host device 102 can request a session confirmation from
wearable device 102. For instance, as described below, user access
to some features and/or functionalities of host device 102 may
depend on whether a verified session has been established.
Accordingly, when a user attempts to access such features or
functionalities, host device 102 can confirm that the verified
session is still in progress as a condition of permitting the
attempted access. To obtain confirmation, host device 102 can send
a session confirmation request to wearable device 100, and wearable
device 100 can receive the request at block 1810.
[0159] At block 1812, in response to a request for session
confirmation, wearable device 100 can generate and send a response.
The response can be based at least in part on the session key. For
example, host device 102 can send a request for session
confirmation that includes a random nonce. Wearable device 100 can
encrypt the random nonce based on the session key (or a message key
derived from the session key) and include the encrypted random
nonce in its response. As described below, host device 102 can use
the encrypted random nonce and its own session key to validate the
response.
[0160] In some embodiments, host device 102 can use the existence
of a verified session as a security measure, which can supplement
and/or substitute for other security measures provided by host
device 102. For example, once a verified session has been
established based on a user signing in to unlock host device 102,
host device 102 can bypass a requirement for signing in during
subsequent unlocking events. FIGS. 19 and 20 are flow diagrams of
processes that can be executed by a host device, e.g., host device
102 of FIG. 1, communicating with a wearable device, e.g., wearable
device 100 of FIG. 1. FIG. 19 illustrates a process 1900 for
establishing a verified session according to an embodiment of the
present invention, and FIG. 20 illustrates a process 2000 for
unlocking a host device during a verified session according to an
embodiment of the present invention. In some embodiments, the
implementation of processes 1900 and 2000 can include program code
executed by a processor of host device 102.
[0161] Referring to FIG. 19, process 1900 can begin at block 1902,
where host device 102 can pair with wearable device 100. The
pairing process can be similar to processes described above. At
block 1904, host device 102 can detect a sign-in event. For
example, a user may turn on a display or other interface of host
device 102, which can trigger host device 102 to present a sign-in
prompt, e.g., prompting the user to enter a passcode, and the user
can respond to the prompt. e.g., by entering the passcode. A
successful response by the user can generate a sign-in event, ant
at block 1906, host device 102 can enter an unlocked state.
[0162] At block 1908, host device 102 can determine whether
wearable device 100 is in a trusted state. The determination can be
based on criteria described above (or other criteria), and the
criteria can be tested by host device 102 and/or wearable device
100. For example, host device 102 can determine whether wearable
device 100 is in close proximity, e.g., using RSSI as described
above. Host device 102 might not be able to determine directly
whether wearable device 100 is being worn; in some embodiments,
host device 102 can query wearable device 100 as to whether it is
being worn, while in other embodiments, host device 102 can infer
whether wearable device 100 is being worn based on subsequent
responses from wearable device 100.
[0163] If wearable device 100 is determined to be in the trusted
state, then at block 1910, host device 102 can send a notification
of the sign-in event to wearable device 100. (This can be the
notification received at block 1708 of process 1700 described
above.) At block 1912, host device 102 can establish a session key
and a verified session with wearable device 100. The session key
can be identical or complementary to the session key established by
wearable device 100 at block 1714 of process 1700, and the same
cryptographic or other techniques can be implemented on both
devices. In some embodiments, establishing the session key can
include sending various communications between host device 102 and
wearable device 100. e.g., to confirm that a verified session has
been established at each side. In some embodiments, if wearable
device 100 is not being worn or otherwise detects that criteria for
being in a trusted state are not currently met, wearable device 100
can decline to establish the verified session.
[0164] At block 1914, host device 102 can interact with the user
within the verified session. In some instances, interaction with
the user can also include interaction with wearable device 102,
e.g., to send or receive phone calls and/or other communications as
described above. As noted above, in some embodiments, host device
102 can selectively allow the user to access certain functionality
based on the verified session, and host device 102 can send session
confirmation requests to wearable device 100 at any time. The
session key can be (but need not be) used to encrypt communications
that may occur between host device 102 and wearable device 100;
some, all, or none of the communications can be encrypted.
Encryption can be selective, e.g., based on the sensitivity of the
data being communicated.
[0165] At block 1916, host device 102 can enter a locked state. For
example, host device 102 can be programmed or otherwise configured
to automatically enter the locked state after a specified period of
inactivity (e.g., 1 minute, 2 minutes, 5 minutes, 30 minutes,
etc.). As another example, a user may be able to place host device
102 into the locked state. e.g., by operating a lock control. In
some embodiments, entering the locked state can include turning off
a display device and/or powering down other components.
[0166] Entering the locked state at block 1916 does not necessarily
terminate the verified session. For example, if host device 102
remains in communication with wearable device 100 and wearable
device 100 continues to be worn, the verified session can continue.
The continuance of the verified session after locking of host
device 102 can facilitate further user operation of host device
102, e.g., by allowing the user to bypass the sign-on process when
unlocking host device 102.
[0167] Referring to FIG. 20, process 2000, which can be a
continuation of process 1900, illustrates certain aspects of host
device operation in a verified session according to an embodiment
of the present invention.
[0168] A locked host device 102 can detect a triggering event for
an unlocking operation at block 2002. For example, a user may pick
up host device 102 or press a button indicating a desire to resume
use. At block 2004, host device 102 can determine whether wearable
device 100 is currently in close proximity to host device 102.
Close proximity can be determined using the same techniques and
definitions described above. In the process as shown in FIG. 20,
lack of close proximity at block 2004 does not end the verified
session; however, in some embodiments, the verified session can
end.
[0169] At block 2006, host device 102 can determine whether a
verified session is currently established with wearable device 100
that is in close proximity. For example, host device 102 can
determine whether it has a valid session key and/or state
information indicating that a verified session is currently
established. If not, then host device 102 can determine that a
verified session is not currently established. As another example,
if host device 102 is in a verified session state but communication
with wearable device 100 has been interrupted or lost, host device
102 can determine that a verified session is not currently
established. As yet another example, if wearable device 100 has
sent a notification that a verified session has ended, host device
102 can determine that a verified session is not currently
established.
[0170] If wearable device 100 is not in close proximity (at block
2004) or if a verified session is not currently established (at
block 2006), then at block 2008, host device 102 can prompt the
user to provide a passcode or other sign-in credentials. At block
2010, if the user provides valid credentials, host device 102 can
enter the unlocked state at block 2012. If the user does not
provide valid credentials, process 2000 can return to block 2008 to
prompt the user to retry. In some embodiments, the number of
retries can be limited to prevent device tampering, and process
2000 can exit if the user repeatedly fails to provide valid
credentials at block 2010. (Other consequences, such as erasing
data from host device 102, can also ensue.)
[0171] It should be noted that if wearable device 100 is in close
proximity when the user enters valid credentials at block 2010,
this can result in establishing a new verified session, e.g., in
accordance with process 1900 described above.
[0172] If, at block 2006, a verified session is in progress,
prompting the user for sign-in credentials can be bypassed. For
example, at block 2014, host device 102 can request a session
confirmation from wearable device 100. For example, host device 102
can send a request for session confirmation that includes a random
nonce. At block 2016, host device 102 can receive a response from
wearable device 100. For example, wearable device 100 can encrypt
the random nonce based on the session key (or a message key derived
from the session key) and include the encrypted random nonce in its
response. At block 2018, host device 102 can determine whether the
response is valid. For example, host device 102 can use the
encrypted random nonce and its own session key to validate the
response.
[0173] If the response is valid, then at block 2012, host device
102 can enter the unlocked state, without prompting the user for
sign-in credentials. In some embodiments, host device 102 can
provide an indication to the user that the normal sign-in process
is being bypassed due to the presence of wearable device 100, e.g.,
by briefly displaying an icon representing wearable device 100 or
by providing a substitute prompt, such as a prompt inviting the
user to operate a touchscreen control to begin using host device
102 rather than prompting the user to enter a sign-in
credential.
[0174] If, at block 2018, the response is not valid, then at block
2020, host device 102 can end the verified session. Ending the
verified session at block 2020 can include various actions, e.g.,
updating state information of host device 102 to indicate that it
is not in a verified session, destroying or invalidating the
session key, and/or sending a notification to wearable device 100
to report that host device 102 has ended the verified session.
After ending the verified session, host device 102 can continue to
communicate with wearable device 100 (in an unverified session),
and a new verified session can subsequently be established.
[0175] After ending the verified session at block 2020, host device
102 can prompt the user to provide sign-in credentials at block
2008. As noted above, in some instances, this can result in
establishing a new verified session.
[0176] It will be appreciated that the verified-session processes
described above are illustrative and that variations and
modifications are possible. Steps described as sequential may be
executed in parallel, order of steps may be varied, and steps may
be modified, combined, added or omitted. For instance, ending a
session can be driven by interrupts when session-ending conditions
are detected by either device, and either device can send a
notification to the other if a session-ending event occurs. In some
embodiments, either device (or both devices) can also alert the
user to the establishment and/or ending of a verified session.
[0177] Session confirmation requests from a host device can be sent
at any time. If a wearable device receives a session confirmation
request when a verified session is not in progress (either before
any verified session has been established or after the most recent
verified session has been terminated), the wearable device can
return a response indicating that no verified session exists, and
the host device can proceed accordingly.
[0178] In some embodiments, a wearable device can send context
information along with a response to a session confirmation
request. This context information can include any information the
wearable device has that is indicative of user activity or
otherwise suggestive of the user's likely intent in operating the
host device at that particular time. The host device can use the
context information in its interaction with the user, e.g., to
present information and/or interfaces that correspond to a user
intent inferred from the context information (and in some instances
other information available to host device 102). For example, as
described above with reference to FIGS. 4-8, wearable device 100
can receive a notification of an incoming text message and present
an alert to the user. If, rather than responding via wearable
device 100, the user picks up host device 102 and triggers an
unlock event, host device 102 can obtain the context
information--in this case that wearable device 100 presented an
incoming-text alert to which the user has not responded--and can
proceed accordingly, e.g., by unlocking and immediately launching a
text messaging app, based on an inference that the user most likely
wants to read and/or respond to the received text message. Other
examples of context information can include alerts regarding missed
calls, voice mail messages received, stock market alerts, and so
on. In some embodiments, context information is sent only if host
device 102 and wearable device 100 are in close proximity when the
request for session confirmation is sent.
[0179] In some embodiments described above, bringing host device
102 and wearable device 100 into close proximity (e.g., within 30
or 60 centimeters of each other) is a prerequisite for establishing
a verified session; however, once the verified session is
established, continued close proximity is not required as long as
the devices remain in communication with each other. This can allow
a user to establish a verified session, then put down the host
device and do other activities (e.g., moving around a room where
the host device is present) without ending the verified session. In
other embodiments, other proximity criteria can be used. For
example, requiring continuous close proximity to maintain a
verified session can provide a higher degree of security. As
another example, establishing a verified session need not require
close proximity. All distance and proximity criteria described
herein can be modified as desired, and different proximity criteria
can be established for different actions. For instance, proximity
criteria for establishing a verified session and subsequently
allowing bypass of a sign-in operation can be based on different
threshold distances.
[0180] A verified session can last indefinitely, until a
terminating event occurs. Terminating events can be defined as
desired and are not limited to the examples described above. In
some embodiments, a verified session can have a maximum duration
(e.g., four, eight, twelve, or twenty-four hours) after which it
automatically ends, and a new sign-in event can be required to
establish a new verified session. Powering down wearable device
100, host device 102, or various components thereof can also
terminate a verified session.
[0181] A further understanding of verified sessions can be had with
reference to the state diagrams in FIGS. 21 and 22. FIG. 21 shows a
simplified state diagram for a host device according to an
embodiment of the present invention. The states and transitions
shown relate to verified sessions and locking and unlocking the
device. These states can occur, e.g., during the course of
executing processes 1900 and 2000 described above.
[0182] For example, a host device, e.g., host device 102, can
initially be in a locked/unverified state 2102. In this state, host
device 102 is locked, and some or all functionality is not
accessible without entry of user credentials. Further, "unverified"
signifies that a verified session with a wearable device 100 is not
currently established.
[0183] Host device 102 can transition from locked/unverified state
2102 to sign-in state 2104 in response to an unlock trigger event
2106. Various events can serve as unlock triggers. For example, if
a display of host device 102 is turned off, user operation of a
button or other control that turns on the display can be an unlock
trigger. In some embodiments where host device 102 is equipped with
motion sensors, certain motions of host device 102 (e.g.,
corresponding to a user picking up host device 102) can be
interpreted as unlock triggers. Other examples include a device
being plugged into or otherwise physically connected to host device
102, an increase in light level at a light sensor of host device
102, etc. In sign-in state 2104, host device 102 can prompt a user
for sign-in credentials.
[0184] In response to successful sign-in (event 2106), host device
102 can transition to unlocked/unverified state 2108. In this
state, host device 102 is unlocked and at least some of its
functions are accessible to a user, but a verified session with a
wearable device is not currently established. An idle/lock event
2110 can occur, e.g., if user activity ceases for a predefined time
interval, or if the user actively locks host device 102. In
response to idle/lock event 2110, host device 102 can transition
back to locked/unverified state 2102.
[0185] If wearable device 100 is in a trusted state (e.g., based on
close proximity and/or other criteria) when host device 102 enters
unlocked/unverified state 2108, host device 102 and wearable device
100 can establish a verified session, e.g., as described above.
Successfully establishing the verified session (event 2112) allows
host device 102 to transition to unlocked/verified state 2114.
[0186] From unlocked/verified state 2114, an idle/lock event 2116
(which can be predicated on any of the same occurrences as event
2110) allows host device 102 to transition to locked/verified state
2118 rather than back to locked/unverified state 2102.
[0187] While host device 102 is in locked/verified state 2114, an
unlock trigger event 2120 can occur. Any event that can serve as
unlock trigger event 2106 can serve as unlock trigger event 2120.
However, instead of transitioning to sign-in state 2104, a host
device 102 that is in locked/verified state 2114 can transition to
confirming state 2122. In this state, host device 102 can send a
session confirmation request to wearable device 102 and receive a
response, e.g., as described above. If the response is valid,
confirmation success event 2124 allows host device 102 to
transition back to unlocked/verified state 2114. If the response is
not valid, confirmation fail event 2126 allows host device 102 to
transition back to sign-in state 2104.
[0188] In some embodiments, a verified session can end while host
device 102 is in locked/verified state 2118. For example, host
device 102 can receive a notification from wearable device 100 that
the session has ended (e.g., because the user has taken offwearable
device 100), contact with wearable device 100 can be lost (e.g.,
due to wearable device 100 moving out of communication range), or
host device 102 can determine that the verified session has expired
(e.g., based on a predefined limit on session duration as described
above). When a verified session ends while host device 102 is in
locked/verified state 2118, session end event 2128 can cause a
transition to locked/unverified state 2102.
[0189] Turning to the wearable device. FIG. 22 shows a simplified
state diagram for a wearable device according to an embodiment of
the present invention. The states and transitions shown relate to
verified sessions between a wearable device and a host device.
These states can occur. e.g., during the course of executing
processes 1700 and 1800 described above.
[0190] For example, a wearable device, e.g., wearable device 100,
can initially be in unworn/unconnected state 2202. In this state,
wearable device 100 is not being worn by a user (e.g., as
determined from strap sensors 216 of FIG. 2 or other biometric
sensors) and is also not connected to (e.g., paired and/or
communicating with) any host device.
[0191] From unworn/unconnected state 2202, wearable device 100 can
transition to either worn/unconnected state 2204 or
unworn/connected state 2206. Transition to worn/unconnected state
2204 can occur if wearable device 100 detects that the user has put
it on (event 2208), and transition to unworn/connected state 2206
can occur if wearable device 100 establishes communication (e.g.,
initial pairing or re-establishing a previous pairing) with a host
device, e.g., host device 102 (event 2210). These transitions can
reversible. As shown, a take-off event 2212 (which can include,
e.g., sensor signals indicating the user has removed wearable
device 100) can return wearable device 100 from worn/unconnected
state 2204 to unworn/unconnected state 2202, and host-disconnect
event 2214 (which can include, e.g., host device 102 moving out of
range) can return wearable device 100 from unworn/connected state
2206 to unworn/unconnected state 2202
[0192] Alternatively, a wearable device that is worn but
unconnected (state 2204) can become connected to a host in host
connection event 2216 (which can be any of the same events as event
2210), and a wearable device that is connected but unworn (state
2206) can become worn in response to a put-on event 2218 (which can
be any of the same events as event 2208). These transitions can
also be reversible via events 2217 and 2219. Thus, there are
multiple paths by which wearable device 100 can reach a
worn/connected state 2220, in which wearable device 100 is both
being worn by a user and in communication with a host device. In
some embodiments, a put-on event can occur simultaneously with a
host-connect event, and a direct transition (not shown) from state
2202 to 2204 can occur, this transition can also be reversible.
[0193] When wearable device 100 is in worn/connected state 2220, it
can determine whether it is in close proximity to the host device
(e.g., host device 102) with which it is in communication.
Detection of close proximity (event 222) can allow wearable device
100 to transition to trusted state 2224. This can be, e.g., the
trusted state described above with reference to FIGS. 17-20. While
in trusted state 2224, wearable device 100 can detect a session
start event 2226, e.g., establishing a session key as described
above, and can transition to verified state 2228. In verified state
2226, wearable device 100 can receive and respond to requests for
session confirmation from host device 102. Once in verified state
2228, wearable device 100 can remain there indefinitely,
irrespective of state transitions that may be occurring in host
device 102, such as transitions between unlocked/verified state
2114 and locked/verified state 2116 shown in FIG. 21.
[0194] In some embodiments, wearable device 100 can leave verified
state 2228 in response to a take-off event 2230 (which can be any
of the same events as event 2212) or to a host-disconnect event
2232 (which can be any of the same events as event 2214). Take-off
event 2230 can lead to a transition to unworn/connected state 2206,
and host-disconnect event 2232 can lead to a transition to
worn/unconnected state 2204. In some embodiments, a take-off event
can occur simultaneously with a host-disconnect event, and a direct
transition from state 2228 to 2202 can occur.
[0195] Other events (not shown) can also cause wearable device 100
to exit verified state 2228 and return to a different state. For
example, powering down wearable device 100 (or just powering down a
communications interface) can cause a transition. As described
above, in some embodiments, a verified session can expire after a
predefined maximum duration, and expiration of the verified session
can cause a transition from verified state 2228 to another state,
e.g., worn/connected state 2220 (if wearable device 100 and host
102 remain in communication) or trusted state 2224 (if wearable
device 100 and host 102 are in communication and in close proximity
when the verified session expires).
[0196] It will be appreciated that the state diagrams of FIGS. 21
and 22 are illustrative and that variations and modifications are
possible. For instance, the diagrams are not intended to illustrate
all possible states or transitions between states, and a particular
implementation can involve more states, fewer states, or a
different combination of states from those shown. It is to be
understood that operations of various kinds can occur within a
device or between the devices without causing a state transition
between states that are shown. For example, host device 102 can
receive a phone call and the user can interact with wearable device
100 to respond to the call without either device changing between
the states shown, although those skilled in the art will recognize
that other aspects of device state may change.
[0197] As described above, a wearable device such as wearable
device 100 can determine whether it is being worn and can detect
being put on or taken off, e.g., by using various sensors. In some
embodiments, a wearable device can also become assigned to a
specific user (or user identifier). Being assigned to a specific
user can allow the wearable device to customize itself according to
the user's preferences. Further, in some embodiments, matching a
user ID assigned to a wearable device with a user ID assigned to a
host device can further improve security of a verified session.
[0198] A user ID can be assigned to a wearable device in various
ways. For example, in some embodiments, a user can push a user ID
from a host device to a wearable device during a synchronization
operation (examples of which are described above). Along with the
user ID, the user can push a user profile that can define various
preferences (e.g., color schemes or other esthetic preferences,
predefined messages that can be sent as described above, options
such as when to generate alerts and what type of alert to generate,
etc.). In some embodiments, a synchronization operation that pushes
a user ID may be restricted to occurring only when a verified
session has been established between the wearable device and the
host device. The user may also be able to set a passcode (or some
other access credential) on the wearable device that prevents
changes to the user ID or profile from being made by a host device
unless the user confirms by entering the passcode via an interface
of the wearable device. It is contemplated that a wearable device
can but need not require a passcode for operation, and the wearable
device can be selective as to which operations require a passcode.
Thus, in some embodiments, a wearable-device passcode can be
required only for certain operations designated as sensitive, such
as changing a user ID or user profile. (In other embodiments, a
wearable-device passcode can be required for any operation, and in
still other embodiments, a wearable-device passcode can be omitted
entirely.)
[0199] In some embodiments, establishing a verified session between
a host device and a wearable device can facilitate establishing a
user ID for the wearable device. FIG. 23 is a flow diagram of a
process 2300 for establishing a verified session and a user ID
according to an embodiment of the present invention. Process 2300
can be executed by a wearable device, e.g., wearable device 100 of
FIG. 1, communicating with a host device, e.g., host device 102 of
FIG. 1. In some embodiments, the implementation of process 2300 can
include program code executed by a processor of wearable device 100
(e.g., as part of host security program 260 of FIG. 2), and in some
embodiments, process 2300 can be implemented as an extension of
processes 1700 and 1800 described above; for instance, node A in
FIG. 17 can correspond to node A in FIG. 23.
[0200] Process 2300 can begin after a verified session has been
established (e.g., at block 1714 of process 1700). At block 2302,
wearable device 100 can determine whether it already has an
assigned user ID. If so, wearable device 100 can keep its assigned
user ID and interoperate with host device 102 in a verified session
at block 2304, which can correspond to block 1802 of process 1800;
from this point, process 1800 can continue as described above.
[0201] If, at block 2302, wearable device 100 does not have an
assigned user ID, then at block 2306, wearable device 100 can
request a user ID from host device 102. At block 2308, wearable
device 100 can receive a user ID from host device 102. As described
below, in some embodiments host device 102 can confirm with the
user that the ID should be sent before responding to the request.
Host device 100 can send the user ID, e.g., in a message encrypted
using the session key (or a message key derived from the session
key). At block 2310, wearable device 100 can establish the received
user ID as its assigned user ID. This can be done without user
intervention; alternatively, wearable device 100 can prompt the
user to confirm that the user ID should be assigned. In some
embodiments, wearable device 100 can use the newly assigned user ID
to retrieve a user profile (e.g., from locally stored user data 262
of FIG. 2 or by further requests to host device 102) and can apply
various customizations and settings based on the retrieved
profile.
[0202] Once a user ID is assigned, wearable device 100 can
interoperate with host device 102 in a verified session at block
2304. In some embodiments, host device 102 can have the option to
refuse to send a user ID, in which case, block 310 can be
skipped.
[0203] As noted above, a host device can receive and respond to a
wearable device's request for a user ID to be assigned. FIG. 24 is
a flow diagram of a process 2400 that can be executed by a host
device, e.g., host device 102 of FIG. 1, communicating with a
wearable device, e.g., wearable device 102 of FIG. 1. In some
embodiments, the implementation of process 2400 can include program
code executed by a processor of host device 102; process 2400 can
be implemented, for example, as an extension to process 1900 of
FIG. 19.
[0204] At block 2402, host device 102 can establish a verified
session with wearable device 100. For example, host device 102 can
execute some or all of blocks 1900-1912 of process 1900. At block
2404, host device 102 can receive a request from wearable device
100 for a user ID to be assigned to wearable device 100.
[0205] At block 2406, before responding to wearable device 100,
host device 102 can confirm that the verified session is still in
progress. Confirmation can include, e.g., sending a session
confirmation request to wearable device 100 as described above
and/or verifying that no interruption in communication with
wearable device 100 has occurred. Host device 102 can also
implement additional conditions on its response, such as verifying
that wearable device 100 is in close proximity before responding to
the request. In some embodiments, if the request at block 2404 is
received within a predefined interval (e.g., 100 microseconds) of
establishing the verified session, host device 102 can treat the
session as confirmed. As another example, host device 102 can
require that any request to assign a user ID be received within a
predefined time interval (e.g., 100 microseconds or 5 seconds) of
establishing a verified session and can refuse any request that
arrives outside this interval regardless of the current status of
the session.
[0206] If the decision at block 2406 is negative, then host device
102 can ignore the request and continue to interact with the user
at block 2408 (e.g., similarly to block 1914 of FIG. 19). Where a
verified session is not in progress, host device 102 can also
interoperate with wearable device 100 in an unverified state as
described above. In some embodiments, instead of simply ignoring
the message, host device 102 can return a refusal message that can
indicate that a user ID will not be provided; the refusal message
can also include a status code indicating the basis for the
refusal.
[0207] If, at block 2406, the decision is positive, then at block
2410, host device 102 can prompt the user to confirm that the user
ID should be sent to the wearable device. Host device 102 can
select a user ID to send, e.g., based on the user ID that is
currently signed in to or otherwise associated with host device
102. For example, a host device that is a mobile phone may have a
single user ID associated with it and can select that user ID. A
host device that is a desktop computer may have multiple user IDs
associated with it (e.g., for different family members) and can
select the ID based on which user is currently logged in. The user
ID can be an ID associated with the user's account on the host
device itself or an ID associated with the user's account on a
different service such as a cloud-based information storage and
retrieval system.
[0208] The user confirmation can be a simple yes/no option, or
additional options such as selecting a different user ID or
defining a new user ID can be presented. In some embodiments where
the user ID that the host device proposes to send is associated
with a password, passcode, or other identification credential, the
host device can prompt the user to provide that credential as part
of the confirmation.
[0209] FIG. 25 illustrates an example of a confirmation interface
screen 2500 according to an embodiment of the present invention.
Interface screen 2500 can present a description 2502 of the
proposed transaction (sending a specific user ID to a specific
wearable device), a confirmation button 2504, and a cancel button
2506. In some embodiments, screen 2500 can also include a password
entry section 2508, and the user can be required to enter a
password associated with the user ID specified in description 2502
to provide further confirmation that the user of host device 102 is
authorized to use the ID that is to be sent. Other screens can also
be used.
[0210] Referring again to FIG. 24, host device 102 can receive the
user's confirmation decision at block 2412. If the user confirms,
then at block 2414, host device 102 can send the selected user ID
to wearable device 100. The ID can be sent, e.g., in a message
encrypted using the session key of the verified session (or a
message key based on the session key). If the user does not confirm
at block 2412, then at block 2416, host device 102 can send a
refusal message to wearable device 100 indicating that a user ID is
not being provided. In either case, host device 102 can continue
interacting with the user at block 2408. Where a verified session
is not in progress, host device 102 can also interoperate with
wearable device 100 in an unverified state as described above.
[0211] It will be appreciated that the processes for assigning a
user ID described above are illustrative and that variations and
modifications are possible. Steps described as sequential may be
executed in parallel, order of steps may be varied, and steps may
be modified, combined, added or omitted. Assignment of a user ID by
a host device in response to a request from a wearable device can
be subject to a variety of conditions, including but not limited to
those described above (verified session, close proximity,
time-based constraints, etc.). The amount and kind of user
interaction can also be varied. For example, in some embodiments,
assignment of a user ID can be accomplished without user
intervention; in some embodiments, a wearable device may request a
user ID in response to an input from the user (e.g., the wearable
device may prompt the user to indicate whether the wearable device
should attempt to obtain an ID when it connects to a host device).
In some embodiments, user interactions with both the host device
and the wearable device can be required, e.g., in order to further
increase the difficulty of spoofing a legitimate request.
[0212] In some embodiments, wearable device 100 can incorporate its
assigned user ID into responses to session confirmation messages.
This can provide an additional confirmation to host device 102 that
the user is present. For example, if wearable device 100 has a user
ID that host device 102 is not expecting, host device 102 can go
into locked state or take other actions to prevent unauthorized
use.
[0213] In some embodiments, a user ID assigned to wearable device
100 can be a persistent property; for example, wearable device 100
can maintain its user ID even after termination of the verified
session in which the ID was assigned. If desired, the assignment
can be permanent, e.g., retained until a hard reset of wearable
device 100 (e.g., restoring factory settings). In other
embodiments, a user interface can be provided on wearable device
100 and/or a host device that allows a user to change or clear the
assigned user ID, or the assigned user ID can be automatically
cleared in response to events such as the user taking off wearable
device 100. An assigned ID that has been cleared can be
re-established. e.g., by executing processes 2300 and 2400
again.
[0214] It is to be understood that clearing an assigned user ID
signifies only that the wearable device no longer has a current
assigned user ID. For example, the wearable device can continue to
store user profile information for that user ID even after it
ceases to be the currently assigned ID, although it may discontinue
using the user profile information as input to operations. Thus,
for example, a particular user's contacts, customized text
responses, or the like may only be accessible while the wearable
device has that user's ID as its assigned ID; at other times they
can be stored on the wearable device but not accessible to the
user.
[0215] Embodiments described above can facilitate user interaction
with a host device, e.g., by allowing the host device to bypass a
sign-in process when a verified wearable device is present. This
can reduce the user's need to repeatedly enter a passcode or other
sign-in credential into the same host device. Operation of a
wearable device can also be facilitated, e.g., by allowing the user
to establish an identity on the wearable device via a host device
and to transfer or synchronize personal settings between the host
device and the wearable device.
[0216] In some embodiments, defining a pairing (e.g., via Bluetooth
pairing or another process) between the host device and the
wearable device can be a prerequisite of establishing a verified
session. Defining a pairing can refer to any process by which a
user indicates to two devices that they should recognize and
communicate with each other. In some instances, a pairing can be
defined by executing a device discovery process on one device
(e.g., the host device) that allows the host device to obtain
information about any other wireless devices that happen to be
within communication range. The host device can present a list of
discovered devices, and the user can select the wearable device as
the device to be paired. The host device and wearable device can
exchange various information to define the pairing (e.g., device
names, MAC addresses or other unique identifiers, security codes,
and any other information that may be used to establish an
operating communication link between the devices). Once the pairing
is defined, the host device and wearable device can automatically
re-establish communication whenever each device detects the other
within its communication range. Where verified sessions are limited
to devices that have a pairing defined, inadvertent creation of
verified sessions of one user's host device with another user's
wearable device can become less likely. As noted above, in some
embodiments, when a host device and a wearable device detect are in
proximity but not paired, a pairing process can be invoked, and
this can include prompting the user to indicate whether the pairing
should be defined or not.
[0217] In some embodiments, a user or administrator of a particular
host device may have the option to disable bypassing of the sign-in
procedure or to select conditions under which bypassing should be
allowed. For example, the user or administrator can set distance
thresholds for determining close proximity, limits on how far out
of close proximity a host device and wearable device can be without
ending the verified session, time limits on verified sessions, and
so on, limiting the establishment of a verified session to
instances where the wearable device already has an assigned user ID
(which can be required to be assigned through a separate process
such as direct user input into the wearable device or a
synchronization operation with a trusted host or the like), and so
on.
[0218] Certain embodiments of the present invention relate to using
a wearable device to facilitate a purchase transaction with a
point-of-sale terminal in a store. In some embodiments, the
wearable device can facilitate creation of a purchase order. For
example, a user can operate a camera, near-field communication
("NFC") transceiver, or other input devices of a wearable device to
obtain product information, e.g., by reading a quick response
("QR") code, bar code, radio-frequency identification ("RFID") tag,
or other information source that may be located on or otherwise
associated with the product. The product information can include an
identifier of the product (e.g., a stock-keeping unit ("SKU")
number, a universal product code ("UPC"), or the like), and other
information such as a name and/or price of the product. As the user
selects products to purchase, the user can operate the wearable
device to add each product to a purchase order. After selecting one
or more desired products, the user can proceed to a point-of-sale
("POS") terminal located somewhere in the store. The wearable
device can establish communication with the POS terminal, e.g.,
using an NFC transceiver. The wearable device can provide the
purchase order to the POS terminal, which can determine a final
price for the transaction (e.g., after applicable taxes and
discounts). The POS terminal can also use information from the
purchase order for other purposes (e.g., inventory management,
store security, or the like).
[0219] In some embodiments, a wearable device can also facilitate
payment for products in a purchase transaction. For example, a user
can store financial account identifying information (e.g., credit
card or debit card numbers and related information) in a wearable
device, e.g., by transferring the information from a host device
during a verified session. At a POS terminal, the user can select a
financial account to be used for a purchase transaction by
interacting with the wearable device, and the wearable device can
transmit the financial account identifying information to the POS
terminal, e.g., using NFC. The POS terminal can send a transaction
request to a payment processor associated with the financial
account (the payment processor can be, e.g., a server maintained by
a financial institution and accessible via a network) and receive a
response, e.g., an approval of the transaction.
[0220] In some embodiments, a host device that is paired with the
wearable device can also participate in the purchase transaction.
For example, a wearable device at the POS terminal can communicate
with a host device (e.g., in a verified session) to obtain
financial account identifying information in real time. As another
example, the host device can communicate with the payment processor
to verify the transaction request.
[0221] To facilitate payment transactions, a user can store account
identifying information (also referred to as an "account
identifier" or "account ID") in a wearable device such as wearable
device 100 of FIG. 1. Some wearable devices can provide a user
interface operable to enter account identifiers directly into the
wearable device. However, for wearable devices with a small form
factor, a user may find it more convenient to provide the data via
a host device such as host device 102. Host device 102 can obtain
the account identifiers via direct user input or by communicating
securely with a data source (e.g., a cloud-based personal
information service).
[0222] To deter data theft, host device 102 and wearable device 100
can be configured such that account identifiers can be transferred
between them only during a verified session. A verified session can
be established, e.g., in the manner described above (a user
unlocking host device 102 while wearing wearable device 100 in
close proximity to host device 102). Some embodiments may allow a
user to establish a verified session on demand, e.g., by operating
a user interface control on host device 102 or wearable device 100
to initiate establishment of a verified session. In some instances,
the on-demand process can include user confirmation; for example,
host device 102 can prompt the user to enter a passcode or other
sign-in credential to establish the verified session without
actually entering a locked state.
[0223] FIG. 26 is a flow diagram of a process 2600 for obtaining
account identifiers that can be implemented in a wearable device
(e.g., wearable device 100 of FIG. 1) according to an embodiment of
the present invention. In some embodiments, the implementation of
process 2600 can include program code executed by a processor of
wearable device 100.
[0224] At block 2602, wearable device 100 can establish a verified
session with a host device, e.g., host device 102; processes
described above or similar processes can be used. At block 2604,
wearable device 100 can obtain an assigned user ID. For example, as
described above, wearable device 100 can request a user ID
assignment from host device 102 when a verified session is
established. As another example, wearable device 100 can obtain a
user ID assignment by direct input from a user. In some instances,
wearable device 100 can already have an assigned user ID (e.g.,
from a previous verified session) when process 2600 begins, and
block 2604 can be skipped.
[0225] At block 2606, wearable device 100 can request account
identifiers (and/or other account data) for its assigned user ID
from host device 102. The request can include the assigned user ID
of wearable device 100 and can be encrypted using the session key;
host device 102 can use these features to determine whether the
requested account identifiers should be provided. In some
embodiments, wearable device 100 can send the request for account
identifiers in response to a user instruction. For example, FIG. 27
illustrates a user interface screen 2700 that can be used to access
host functions of a host device via a wearable device such as
wearable device 100 according to an embodiment of the present
invention. Interface screen 2700 can be generally similar to
interface screen 1000 of FIG. 10 shown above and can present a menu
of options based on the capabilities of the host device with which
wearable device 100 is currently communicating. For example, if the
host device has account identifiers available, interface screen
2700 can include a control 2702 operable to request the account
identifiers. This can allow the user to control whether a wearable
device has access to the user's account identifiers. In some
embodiments, control 2702 may be available only when wearable
device 100 is in a verified session with host device 102; at other
times, control 2702 can be unavailable (e.g., the virtual button
can be omitted from the interface, or the button can be presented
with visual indicia to indicate that it is inactive, such as being
"grayed out"). Other user interfaces can also be provided.
[0226] Referring again to FIG. 26, at block 2608, wearable device
100 can receive one or more account identifiers from host device
102. Since a verified session is in progress, host device 102 can
encrypt the account identifiers using the session key to reduce the
risk of eavesdropping.
[0227] An account identifier can include any kind of information
that may assist in accessing an account (e.g., a financial
account). For example, an account identifier can include a
user-readable "nickname" for the account (e.g., "business credit
card." "personal credit card," "debit card," the card issuer's name
and last few digits of the account number, or anything else a user
can recognize as distinguishing one account from another). An
account identifier can also include account details sufficient to
enable purchases or other transactions to be conducted using the
account, such as the full account number and/or other access code
that may be required to make purchases on the account, expiration
date (e.g., for a credit card account), account holder's name,
identifier of an institution where the account is maintained (e.g.,
ACH routing number for a financial institution), and so on. As
described below, in some embodiments, wearable device 100 can
communicate with host device 102 during a transaction and can use
just the account nickname; in other embodiments, wearable device
100 can store all the information necessary to complete a
transaction.
[0228] At block 2610, wearable device 100 can store the received
information in a local storage medium (e.g., as part of user data
262 of FIG. 2). In some embodiments, wearable device 100 can store
the received account identifiers in encrypted storage. The
encryption can use a different key from the session key so that
wearable device 100 can continue to access locally stored account
identifiers after the verified session ends.
[0229] To reduce the risk of unauthorized access to a user's
accounts, wearable device 100 in some embodiments maintains account
data only for as long as wearable device 100 continues to be worn
by the user. Accordingly, at block 2612, wearable device 100 can
periodically determine whether it has been removed (e.g., based on
strap sensors 216 and/or other biometric sensors); if so, wearable
device 100 can delete the user's account IDs (including any stored
account-related data) at block 2614. In some embodiments, when a
sensor of wearable device 100 detects removal, the sensor can
generate a system-level interrupt in processing subsystem 202. In
response, processing subsystem 202 can invoke an interrupt
servicing routine that can include purging of account IDs and other
sensitive user data from user data 262. The purge can extend to the
assigned user ID, or the assigned user ID can persist after
wearable device 100 is taken off, even if some user-related data
(such as account IDs) is deleted.
[0230] A host device can respond to a request from a wearable
device for account IDs. FIG. 28 is a flow diagram of a process 2800
for providing account IDs to a wearable device according to an
embodiment of the present invention. Process 2800 can be
implemented in a host device, e.g., host device 102 of FIG. 1. In
some embodiments, the implementation of process 2800 can include
program code executed by a processor of host device 102.
[0231] At block 2802, host device 102 can receive a request for
account identifiers (and/or other account data) from a wearable
device, e.g., wearable device 100. At block 2804, host device 102
can determine whether a verified session is in progress. For
example, as described above, a verified session, once established,
can continue until the user takes off the wearable device or the
host device loses contact (i.e., ceases to be able to communicate)
with the wearable device. Determining whether a verified session is
in progress can include sending a session confirmation request and
receiving a response, e.g., as described above, and/or determining
whether the wearable device is in proximity to the host device,
e.g., as described above. In some embodiments, wearable device 100
can encrypt the request for account identifiers using its session
key, and if host device 102 is able to decrypt and recognize the
request, this can serve as the session confirmation.
[0232] If a verified session is not in progress, then at block
2806, host device 102 can deny the request. Denying the request can
include, e.g., not sending any response or sending a response
indicating that the requested information will not be provided. In
some embodiments, host device 102 can provide an alert to the user
indicating that an attempt to obtain account IDs was denied. If the
user intended the attempt to succeed, the user can make appropriate
adjustments (e.g., establishing a new verified session, moving the
devices closer together) and try again.
[0233] If a verified session is in progress, then at block 2808,
host device 102 can prompt the user to confirm that account IDs
should be sent and receive a user response. The confirmation prompt
can include requiring the user to enter a passcode or other
credential to confirm that an authorized user is responding to the
confirmation prompt. User confirmation, while not required, can
help enhance security by making it less likely that a wearable
device can successfully imitate a verified session and obtain the
account IDs without the knowledge of an authorized user of the host
device. In some embodiments, the user confirmation at block 2808
can also include user selection of one or more account IDs to be
sent. If the user does not confirm, host device 102 can deny the
request at block 2806.
[0234] If the user does confirm at block 2808, then at block 2810,
host device 102 can encrypt the account IDs to be sent using the
session key of the verified session. At block 2812, host device 102
can send the encrypted account IDs to the wearable device. Sending
account IDs in encrypted form can reduce the likelihood of account
information being intercepted by unauthorized parties.
[0235] It will be appreciated that processes 2600 and 2800 are
illustrative and that variations and modifications are possible.
Steps described as sequential may be executed in parallel, order of
steps may be varied, and steps may be modified, combined, added or
omitted. In some embodiments, wearable device 100 can include a
user-operable control that can be actuated to selectively delete
some or all of the account IDs that may be stored thereon without
deleting other user data.
[0236] Further, while the description of processes 2600 and 2800
may make specific reference to financial accounts, which can be
general sources of funds for various financial transactions,
identifiers for other types of accounts can also be provided from a
host device to a wearable device in the same processes or similar
processes. For example, a user can store account identifiers
associated with gym memberships, transit passes, merchant loyalty
programs, health care service providers or insurance policies, and
any other type of account. Other types of identifiers, such as
driver's license or passport data, can also be obtained by a
wearable device in a similar manner; any identifiers that can be
stored in or obtained by a host device can be transferred to a
wearable device using process 2600 and 2800 or similar
processes.
[0237] As noted above, the user can select specific accounts for
which identifiers are to be sent to the wearable device. In some
embodiments, the user can be prompted to make a selection during
process 2800 as described above. In other embodiments, the user can
make a selection in advance. For example, host device 102 can
execute a personal information management program that allows the
user to enter and update account data (or retrieve the data from an
external source, such as a cloud-based information management
service). This program can provide user-selectable options to
indicate whether a given account identifier should or should not be
provided to wearable device 100.
[0238] Further, host device 102 can but need not store account
identifiers locally. For example, host device 102 can be configured
to pull account identifiers from an external source (e.g., a
cloud-based information management service) and deliver them to
wearable device 100 without persistently storing a local copy of
the identifiers.
[0239] Using processes 2600 and 2800, the wearable device can
initiate a request for account identifiers. Alternatively, the user
can initiate the operation from the host device. e.g., via a
synchronization option provided in an information management
program, and the host device can push the information to the
wearable device if the wearable device is present and in a verified
session.
[0240] When account identifiers are stored on wearable device 100,
wearable device 100 can become usable as a payment instrument or
user identifier in various transactions. For example, as described
above with reference to FIG. 2, RF interface 208 can include an NFC
interface (e.g., a transceiver and associated circuitry and/or
software to communicate using an NFC communication standard),
allowing wearable device 100 to communicate with any checkpoint
device that is equipped with a compatible NFC interface (e.g., a
point-of-sale terminal in a store, a turnstile in a public transit
system, a security door or barrier in office building, a check-in
station at a gym or doctor's office). Accordingly, a user can
select the account for which the account ID is to be provided at a
particular checkpoint device, then present wearable device 100 to
the checkpoint device. Wearable device 100 can communicate with the
checkpoint device to provide the selected account ID, which the
checkpoint device can use to complete a transaction (e.g., making a
purchase or authorizing entry). Some examples are described below
with reference to purchase transactions; those skilled in the art
with access to the present disclosure will recognize that similar
techniques can be applied in connection with other
transactions.
[0241] It is to be understood that in various embodiments, wearable
device 100 can be used with existing NFC-capable checkpoint devices
as well as new devices. Use of wearable device 100 to present
account information to a checkpoint device can provide added
convenience for the user. Unlike task-specific NFC devices (e.g.,
smart cards) or NFC-equipped smart phones, which too often turn out
to be buried in a user's bag, hidden in one of several pockets on
the user's attire, or left behind entirely, leading to wasted time
at the checkpoint while the user fumbles for the right device,
wearable device 100 can be worn on the user's person (e.g., on the
user's wrist) where it is readily accessible any time the user
needs it. The user can simply select the right account (if multiple
account IDs are stored on wearable device 100) and proceed. In some
instances, the checkpoint device may provide information that
allows wearable device 100 to select the correct account ID
automatically (e.g., selecting the user's transit account if the
checkpoint device identifies itself as a public transit turnstile),
and the user need not manually select the account ID.
[0242] Certain embodiments allow wearable device 100 to facilitate
various aspects of a purchase transaction. For instance, payment
can be facilitated using an account ID for a user's payment account
(e.g., credit card, debit card, or the like). In some embodiments,
wearable device 100 can also facilitate defining the transaction,
for example, by gathering information about products to be
purchased.
[0243] FIG. 29 is a flow diagram of a process 2900 for defining a
purchase transaction according to an embodiment of the present
invention. Process 2900 can be implemented in a wearable device
(e.g., wearable device 100 of FIG. 1). In some embodiments, the
implementation of process 2600 can include program code executed by
a processor of wearable device 100, e.g., in shopping program 264
of FIG. 2.
[0244] Process 2900 can begin, e.g., when a user enters a store and
selects a product to purchase or launches a shopping program on
wearable device 100. The term "store" as used herein refers to any
physical location (including indoor and/or outdoor locations) where
a merchant (any person, corporation, or other entity that operates
a store) offers products for sale to persons who are physically
present at that location. The products can include tangible goods
of any kind (e.g., electronic devices, clothing, food, sports
equipment, books, luggage, tools, appliances, furniture,
housewares, works of art, and any other tangible items) and/or
services (e.g., personal services such as hair cutting, manicures,
medical services, tutoring services, personal training services;
services associated with a purchase of tangible goods such as
extended warranty, training classes, delivery, installation; and
any other service a person may purchase in a store).
[0245] At block 2902, wearable device 100 can initialize a purchase
order for a purchase transaction. For example, if the user launches
a shopping program on wearable device 100, the shopping program can
create a purchase order. The purchase order can initially be empty,
and the user can add products to the order as described below.
[0246] For example, at block 2904, wearable device 100 can obtain
product information for a product selected by the user. Product
information can include any information pertaining to the product,
such as a product name and/or price. Various techniques can be used
to obtain product information. For example, many products have a
computer-readable tag, e.g., a UPC (universal product code) bar
code, a QR (quick response) code, or the like, which can be
attached to the product (or its packaging) or otherwise associated
with the product (e.g., displayed on a shelf edge label near the
product or printed on a display of product information). If
wearable device 100 includes a camera (e.g., camera 229 of FIG. 2),
a user can hold wearable device 100 so that the camera can capture
an image of the computer-readable tag. Wearable device 100 can
analyze the image and extract product information. As another
example, an RFID (radio-frequency identification) chip can be
embedded in a product or its packaging or otherwise associated with
the product (e.g., attached to a shelf edge near the product or
incorporated into a display of product information). Where wearable
device 100 has an NFC transceiver, the NFC transceiver can be
operated to read product information from the RFID chip, e.g., by
holding wearable device 100 in proximity to the RFID chip. Other
techniques can also be used.
[0247] At block 2906, wearable device 100 can present product
information obtained at bock 2904 (e.g., the product's name and/or
price) to the user. At block 2908 the user can confirm whether the
product should be added to the purchase order. If the user
confirms, the product information can be added to the purchase
order at block 2910. Thereafter, at block 2912, process 2900 can
determine whether the user has identified another product of
interest; if so, process 2900 can return to block 2904 to obtain
the product information. If not, then at block 2914, process 2900
can determine whether the purchase order is complete. The
determination can be based, e.g., on user input indicating that the
user has finished modifying the purchase order or on other events;
for example, wearable device 100 can infer that the purchase order
is complete based on presentation of wearable device 100 to a POS
terminal that uses NFC.
[0248] Once the purchase order is complete, at block 2916, wearable
device 100 can provide the purchase order to a POS terminal. A POS
terminal can be any electronic device or other automated system
that is capable of interacting with a customer and/or a store
employee to complete a purchase transaction. (The term "store
employee" as used herein can refer to anyone working in the store,
regardless of actual job title or legal employment status, and the
term "customer" can refer to anyone who purchases or attempts to
purchase products at the store.) At block 2918, wearable device 100
can conduct a purchase transaction to purchase all of the items on
the purchase order. e.g., by communicating with the POS terminal.
It should be noted that in some instances, a purchase transaction
can be conducted on a "self-service" model, without involving a
store employee. The user can generate a purchase order using
wearable device 100 and conclude the transaction at an automated
POS terminal prior to leaving the store.
[0249] FIGS. 30 and 31 illustrate shopping interface screens for
wearable device 100 that can be used in connection with process
2900 according to an embodiment of the present invention. FIG. 30
illustrates an interface screen 3000 that can be used for managing
a purchase order. In region 3002, screen 3000 can present a current
total price of the order based on products already added. "Read"
button 3004 can be actuated to instruct wearable device 100 to
obtain product information for a product (e.g., triggering
execution of block 2904 of process 2900). "Checkout" button 3006
can be actuated to indicate that the purchase order is complete
(e.g., at block 2914 or process 2900). "Clear" button 3006 can be
used to clear the purchase order, e.g., if the user decides to
leave the store without making a purchase. Other options can also
be provided, e.g., options to review a list of products in the
order and/or to remove individual products from the order.
[0250] FIG. 31 illustrates an interface screen 3100 that can be
used for adding an item to a purchase order. Screen 3100 can be
used, e.g., to present product information to the user at block
2906 of process 2900. In region 3102, screen 3100 can present
product information including, e.g., a product identifier and
price. "Add" button 3104 can be selected to instruct wearable
device 100 to add the product to the purchase order. "Cancel"
button 3106 can be selected to instruct wearable device 100 not to
add the product to the purchase order. In some embodiments,
additional options can be provided, such as a control allowing the
user to specify the quantity of the item to be purchased.
[0251] It will be appreciated that purchase-order processes and
interfaces described herein are illustrative and that variations
and modifications are possible. Steps described as sequential may
be executed in parallel, order of steps may be varied, and steps
may be modified, combined, added or omitted. For instance, product
information presented to the user (e.g., product name and price)
need not be read from the product's identifying tag (barcode, QR
code. RFID chip, etc.). In some instances, the identifying tag can
include just an identification code, and wearable device 100 can
use this code to obtain additional information, e.g., by
communicating with another device. For example, wearable device 100
may be able to communicate with a product data server maintained by
the store; such communication can be via Bluetooth or other
wireless protocols supported by wearable device 100, and in some
respects the product data server can act as a host device. As
another example, communication between wearable device 100 and the
store's product data server can be mediated by a host device
carried by the user (e.g., the user's mobile phone). Wearable
device 100 can communicate with the user's host device to request
information, and the user's host device can relay the request to
the store's server and relay the server's response back to wearable
device 100.
[0252] As another example, the purchase order can be but need not
be maintained on wearable device 100. For example, the purchase
order can be maintained on a host device carried by the user or on
a server provided by the store, and wearable device 100 can
communicate updates to the purchase order to the device that
maintains the order as user input is received.
[0253] The interface screens described above can also be varied and
can include more, fewer, or other control options than those shown.
In some embodiments, control can be provided through touch
gestures, spatial gestures, and/or voice input, in addition to or
instead of through virtual buttons or the like.
[0254] Once the purchase order is complete, various processes can
be used to conduct the purchase transaction. FIG. 32 is a flow
diagram of a process 3200 for conducting a purchase transaction
according to an embodiment of the present invention. Process 3200
can be implemented in a wearable device (e.g., wearable device 100
of FIG. 1). In some embodiments, the implementation of process 3200
can include program code executed by a processor of wearable device
100, e.g., in connection with implementing block 2918 of process
2900 described above.
[0255] Process 3200 can begin when wearable device 100 is in
communication with a POS terminal, e.g., using NFC or other
wireless communication technologies. In the context of process
2900, it is assumed that wearable device 100 has provided the
purchase order to the POS terminal, although in some embodiments,
the POS terminal can obtain a purchase order from another source.
For instance, as noted above, purchase orders constructed using
wearable device 100 can be maintained on the store's server, and a
POS terminal can retrieve the correct purchase order from the
store's server based on an identifier of the wearable device with
which it is communicating.
[0256] At block 3202, wearable device 100 can receive a confirmed
total price from the point of sale device, based on the purchase
order. As described above, in some embodiments, wearable device 100
can maintain a running total as the order is constructed. This
running total might or might not take into account discounts,
coupons, taxes, or other factors that can affect the actual price a
customer pays. In some embodiments, the POS terminal can make these
adjustments (if they have not already been made) and determine the
confirmed total price of the purchase order.
[0257] At block 3204, wearable device 100 can present the total
price to the user, along with a list of payment options. FIG. 33
illustrates a payment interface screen 3300 that can be used in
some embodiments. Screen 3300 can present the total price in region
3302 and can present control buttons 3304, 3306, 3308 for selecting
among payment options. The payment options can be generated, e.g.,
from payment account identifiers obtained from a host device using
process 2600 or a similar process. In some embodiments, the various
payment accounts can be assigned nicknames, either by the user or
by default, and buttons 3304, 3306, 3308 can be labeled with the
nicknames or any other label that can distinguish different
accounts. Depending on the number of accounts and size of screen
3300, a scrollable list of options can be provided.
[0258] Some embodiments may provide for filtering the list of
payment options. For example, wearable device 100 can filter out
any accounts that are not payment accounts (e.g., a gym membership
account). If the POS terminal provides information as to the types
of payment accounts accepted (e.g., which credit cards the merchant
accepts), wearable device 100 can present only payment accounts of
accepted types.
[0259] Payment account options can be presented in any order. For
example, the list can be sorted alphabetically or based on recency
of use (e.g., most-recently used listed first). In some
embodiments, the user can select a sort order (either in advance or
in real time), or the user can predefine an arbitrary order
(somewhat similarly to the way some a user of a traditional wallet
may prefer to arrange the cards in an idiosyncratic order).
[0260] Referring again to FIG. 32, at block 3206, the user can
select a payment account. e.g., by selecting the corresponding
button from interface screen 3300. At block 3208, wearable device
100 can present an account identifier of the selected payment
account to the POS terminal. The POS terminal can use the account
identifier to complete a purchase transaction (e.g., by
communicating with a payment processor associated with the account,
as described below). At block 3210, wearable device 100 can receive
a transaction result from the POS terminal. If the POS terminal
indicates that the transaction completed successfully, the user is
free to leave the store with the purchased products. If not, the
user may be prompted to try again (e.g., selecting a different
payment account at block 3206).
[0261] FIG. 34 is a flow diagram of a process 3400 that can be
executed by a point-of-sale terminal to complete a purchase
transaction with a wearable device, e.g., wearable device 100,
according to an embodiment of the present invention. The POS
terminal can be implemented as a computer system (e.g., with
processor(s), storage, user interfaces, network interfaces, and/or
RF interfaces, which can be of generally conventional or other
design) executing appropriate program code.
[0262] Process 3400 can begin when a POS terminal is in
communication with wearable device 100, e.g., using NFC or other
wireless communication technologies. At block 3402, the POS
terminal can receive a purchase order from wearable device 100. For
example, wearable device 100 can transfer the stored product (and
quantity) information for each product in the purchase order to the
POS terminal. Alternatively, if the purchase order is maintained on
in in-store server or the like, the POS terminal can obtain an
identifier of the wearable device and/or the purchase order from
wearable device 100 and can use that identifier to retrieve the
purchase order from the in-store server.
[0263] At block 3404, the POS terminal can verify the total price
of the purchase order, e.g., by communicating with an in-store
server or consulting its own internal data regarding product
pricing and adjustments thereto (e.g., discounts, coupons, taxes,
etc.). At block 3406, the POS terminal can send a confirmation of
the order to wearable device 100. This confirmation can include the
verified total price and can be the confirmation received by
wearable device 100 at block 3202 of process 3200.
[0264] At block 3408, the POS terminal can receive a payment
account identifier from wearable device 100. The payment account
identifier can include any combination of information items that
may be required to process a purchase transaction (e.g., charge or
debit) against a given account. By way of example, an account
identifier for a credit card can include an identifier of the
payment processor (e.g., MasterCard.RTM., VISA.RTM. or the like), a
specific account number (e.g., 16-digit credit card number), a card
verification value (e.g., 3-digit code), an expiration date (e.g.,
month and year), and a name of the account holder. It is to be
understood that the content of different account identifiers may
vary, e.g., based on the type of account, requirements of a
financial institution where the account is maintained, and/or
banking industry regulations.
[0265] At block 3410, the POS terminal can send a transaction
request to a payment processor associated with the financial
account. The payment processor can be, e.g., a server that is owned
and operated by a bank, credit card association, third-party
provider of transaction processing services, or the like, and the
POS terminal can communicate with the payment processor via a
network (e.g., the Internet, a virtual private network, or the
like). The transaction request can include, e.g., a transaction
type indicating that the transaction is a purchase, a transaction
identifier assigned by the POS terminal (this can include. e.g., an
identifier of the POS terminal), the total price, the account
identifier obtained from wearable device 100, and/or other
information such as details of products being purchased. In some
embodiments, the transaction request can include an identifier of
the wearable device that provided the account identifier to the POS
terminal.
[0266] The payment processor, which can be of conventional design,
can use the information contained in the transaction request to
determine whether to approve or reject the transaction. The
determination can include standard payment-processing activities,
such as verifying the existence and good standing of the account to
be charged, sending instructions to the financial institution where
the account is maintained to debit the account, and sending
instructions to a financial institution where the merchant
maintains an account to credit the merchant's account. Other
payment processing mechanisms can also be used.
[0267] At block 3412, the POS terminal can receive a transaction
result from the payment processor, and at block 3414, the POS
terminal can provide the transaction result (or selected
information about the transaction result) to wearable device
100.
[0268] In some embodiments, the POS terminal can include a display
that presents information to the user of wearable device 100
(and/or to a store employee); this information can be the same as
information provided to wearable device 100. If the display of the
POS terminal is larger than the display of wearable device 100,
more information can be included. For instance, when the POS
terminal receives the purchase order, it can present the list of
products and allow the user/customer or a store employee to modify
the list via direct interaction with the POS terminal. The POS
terminal can also provide details regarding taxes, discounts, and
other price adjustments that may have been applied in determining
the total price. The POS terminal can also provide prompts. e.g.,
instructing the user to hold the payment device (wearable device
100) next to an NFC reader in order to provide payment information.
The POS terminal can be self-service, and in combination with
process 2900, a user/customer can complete a "self-service"
purchase without the participation of store employees. If desired,
an employee can be present and can assist the user with various
aspects of completing the purchase order and providing the payment
account information.
[0269] A further understanding of processes 3200 and 3400 can be
had with reference to FIG. 35, which shows a message-passing
diagram for completing a purchase according to an embodiment of the
present invention. In this embodiment, a user 3502 wearing a
wearable device 3504 can complete an in-store purchase with a POS
terminal 3506. POS terminal 3506 can communicate with a payment
processor 3508 to process a purchase transaction.
[0270] The transaction can begin when wearable device 3504
communicates a purchase order (message 3510) to POS terminal 3506.
This communication can correspond to block 3402 of process 3400 and
block 2916 of process 2900 described above. POS terminal 3506 can
return a confirmation message 3512 to wearable device 3504, e.g.,
corresponding to block 3202 of process 3200 and block 3406 of
process 3400. In response to receiving confirmation message 3512,
wearable device 100 can present payment options (message 3514) to
user 3502. e.g., corresponding to block 3204 of process 3200.
Messages to the user can include, e.g., visual displays, audio
prompts, and/or other message formats that are comprehensible to a
human being. User 3502 can select a payment option via message 3516
(e.g., operating a user interface control of wearable device 3504);
this can correspond to block 3206 of process 3200. In response to
receiving selection 3516, wearable device 3504 can communicate the
corresponding payment account identifier to POS device 3506 via
message 3518, which can correspond to block 3208 of process 3200
and block 3408 of process 3400. POS device 3506 can send a
transaction request message 3520 to payment processor 3508 (e.g.,
via a network), and payment processor 3508 can respond with a
transaction result message 3522 indicating acceptance or rejection;
this exchange can correspond to blocks 3410 and 3412 of process
3400. POS device 3506 can provide a transaction result message 3524
(which can be, but need not be, identical to result message 3522)
to wearable device 3504; this can correspond to block 3414 of
process 3400 and block 3210 of process 3200. Finally, wearable
device 3504 can present an alert message to the user, for example,
to indicate whether the transaction was successfully completed.
[0271] It will be appreciated that purchase transaction operations
described herein are illustrative and that variations and
modifications are possible. Steps described as sequential may be
executed in parallel, order of steps may be varied, and steps may
be modified, combined, added or omitted. The particular
communications between a POS terminal and a payment processor can
be adapted to particular payment account types and requirements.
Similarly, communication between the POS terminal and a wearable
device can be adapted to the particular protocols and information
requirements of the devices. It should be noted that a wearable
device can support multiple different wireless communication
channels and protocols (e.g., both NFC and Bluetooth), and
accordingly the same wearable device can be used for purchase
transactions with any POS terminal that supports at least one
protocol that is compatible with a protocol supported by the
wearable device.
[0272] A wearable device can obtain account identifiers from a host
device in advance of the purchase transaction, e.g., using process
2600 described above or similar processes. Accordingly, it is not
required that a host device belonging to the user participate in or
even be present at the location of a purchase transaction.
[0273] In some embodiments, however, a host device belonging to the
user of the wearable device can participate in a purchase
transaction. For example, as noted above, the account identifiers
stored in a wearable device need not include enough information to
actually complete a purchase transaction (e.g., the wearable device
can just store a nickname for each account). Where this is the
case, a host device can provide additional account information to
the wearable device at the point of sale, and the wearable device
can relay the information to the POS terminal. In some embodiments,
the wearable device can delete the additional account information
upon completion of the transaction so that such information is not
persistently stored in the wearable device.
[0274] FIG. 36 shows a message-passing diagram for completing a
purchase according to an embodiment of the present invention in
which a host device is present. In this embodiment, a user 3602
wearing a wearable device 3604 that is paired with (or otherwise in
communication with) a host device 3606 that belongs to the user can
complete an in-store purchase with a POS terminal 3608, POS
terminal 3608 can communicate with a payment processor 3610 to
process a purchase transaction.
[0275] The transaction can begin when wearable device 3604
communicates a purchase order (message 3612) to POS terminal 3608.
POS terminal can return a confirmation message 3614 to wearable
device 3604. In response, wearable device 3604 can present payment
options (message 3616) to user 3602 and receive a user selection
(message 3618). Up to this point, the transaction sequence and
messages can be identical to the sequence and messages described
above with reference to FIG. 35.
[0276] However, in this example, it is assumed that wearable device
3604 does not have sufficient information about the selected
account to initiate a purchase transaction with POS terminal 3608.
Accordingly, wearable device 3604 can send an information request
message 3620 to host device 3606 to obtain additional account
information, and host device 3606 can return the additional account
information (message 3622); the additional information can include
any information needed by wearable device 3604 to initiate the
purchase transaction In some embodiments, messages 3620 and 3622
can be sent while wearable device 3604 and host device 3606 are in
a verified session (e.g., as described above), and the request and
response can be encrypted using the session key. The exchange of
messages 3620 and 3622 can happen automatically (without user
intervention) provided that host device 3606 and wearable device
3604 are in communication range of each other, as is likely if both
are somewhere on the user's person.
[0277] After wearable device 3604 receives message 3622, the
remainder of the transaction can proceed similarly to embodiments
described above with reference to FIG. 35. Wearable device 3604 can
provide account information message 3264 to POS terminal 3608. POS
terminal 3608 can send a transaction request message 3626 to
payment processor 3610 and receive a transaction result 3628. POS
terminal 3608 can provide a corresponding result message 3630 to
wearable device 3604, which in turn can present user alert message
3632 to user 3602.
[0278] The transaction sequence of FIG. 36 allows
account-identifying information sufficient to draw funds from an
account to be persistently stored on a user's host device and
transferred to a wearable device for short-term use on an as-needed
basis. Other transaction sequences can avoid providing account
information to a wearable device even on a short-term basis. For
example, FIG. 37 shows a message-passing diagram for completing a
purchase according to another embodiment of the present invention.
In this embodiment, a host device 3706 and a POS terminal 3708 each
provide portions of a transaction request to a payment processor
3710.
[0279] The transaction can begin when wearable device 3704
communicates a purchase order (message 3712) to POS terminal 3708.
POS terminal can return a confirmation message 3714 to wearable
device 3704. In this case, confirmation message 3714 can include a
transaction identifier ("tid") assigned by POS device 3708 to the
transaction as well as other information such as the total price.
In response, wearable device 3704 can present payment options
(message 3716) to user 3702 and receive a user selection (message
3718). Up to this point, the transaction sequence and messages can
be similar or identical to the sequence and messages described
above with reference to FIG. 35.
[0280] In response to user selection message 3718, wearable device
3704 can provide transaction information message 3720 to host
device 3706. Message 3720 can include information received by
wearable device 3704 in confirmation message 3714 (e.g., the
transaction identifier and total purchase price) and the account
selection received from the user in message 3718. Based on this
information, host device 3706 can generate a customer-side
transaction request message 3722 to be sent to payment processor
3710. Message 3722 can include the transaction identifier, the
purchase amount, account identifying information sufficient to
complete the purchase transaction, and optionally other information
such as an identifier of wearable device 3704 and/or host device
3706. Concurrently, POS terminal 3708 can generate a merchant-side
transaction request 3724 to be sent to payment processor 3710.
Message 3724 can include the transaction identifier, the purchase
amount, an identifier of a merchant account (which in some
embodiments can be incorporated into the transaction identifier)
and optionally other information such as details regarding items
purchased and/or an identifier of wearable device 3704. It is to be
understood that no particular time ordering is required between
messages 3722 and 3724, although in some embodiments the
transaction may be rejected if messages 3722 and 3724 are received
too far apart in time by payment processor 3710.
[0281] Payment processor 3710 can receive messages 3722 and 3724
and correlate them, e.g., based on the transaction identifier;
other overlapping information items can be used to verify the
transaction. In an alternative embodiment, messages 3722 and 3724
can be received at an intermediary, such as an in-store data
server, which can combine messages 3722 and 3724 into a single
transaction request message to be sent to payment processor
3710.
[0282] Payment processor 3710 can process a transaction based on
the information from messages 3722 and 3724 (which can be received
separately or received as a combined request) and can return a
transaction result message 3726 to POS terminal 3708. Similarly to
embodiments described above, POS device 3708 can provide a
corresponding result message 3728 to wearable device 3704, which
can present a user alert message 3730 to user device 3702.
Alternatively, payment processor 3710 can provide transaction
results to both POS terminal 3708 and host device 3706 (e.g., if
payment processor received separate messages 3722 and 3724).
[0283] As FIGS. 35-37 illustrate, a number of different payment
processing techniques can be implemented, and in some embodiments,
a wearable device and/or host device can be configured to adapt to
different transaction requirements at different points of sale. For
instance, a POS terminal can inform a wearable device (e.g., in
confirmation message 3714) if a separate customer-side transaction
request is required. If it is, the wearable device can communicate
with a paired host device to generate the customer-side transaction
request, and this can be done regardless of whether the wearable
device or host device (or both) has a persistent store of
account-identifying information.
[0284] The processes and messages described herein are not limited
to purchase transactions. Similar processes and messages can be
used, for example, in connection with crediting funds to a user's
account (e.g., if the user returns previously purchased goods for a
refund). Likewise, similar processes can be used to identify a user
at a security checkpoint (e.g., a security door or barricade in an
office complex, a check-in station at a gym or medical office, or
the like) and/or to allow the user to use a transit pass or debit
account to enter a mass transit facility or vehicle. For example, a
checkpoint device (which can be physically present at the security
checkpoint) can obtain account identifiers or other identifiers
from the user's wearable device and forward the identifiers to a
back-end server, which can confirm whether the user is authorized
to proceed. In some instances, a checkpoint device can maintain a
local store of authorization information, and a back-end server is
not required.
[0285] As described above, a wearable device can obtain account
information for any number of accounts of various kinds associated
with a user. The accounts can include financial accounts as well as
other types of accounts or authorization credentials, including but
not limited to the examples described above. Account information
(including authorization credentials) can be provided to the
wearable device during a verified session with a host device, to
facilitate secure data exchange. In some embodiments, the wearable
device can require an active user input (e.g., to select an account
or confirm a selection) prior to transmitting account information
to a POS terminal or other checkpoint device; requiring user input
can help avoid unauthorized exposure of account information or
other sensitive data to third-party devices.
[0286] Further, as described above, a wearable device can be
configured to automatically delete any locally-stored account
information (including authorization credentials) when it ceases to
be worn. This can prevent misuse of a user's data. e.g., in the
event of loss or theft of the wearable device. In some instances,
account data may be more securely stored on a wearable device where
it is subject to deletion as soon as the device ceases to be worn
than on a device that may not provide a similar feature, such as
many mobile phones or the like.
[0287] In some embodiments, the user can actively manage which
account data is stored on a wearable device. For example, as
described above, the user can select particular account data to be
synchronized to the wearable device and/or enter some or all
account data directly into the wearable device. Further, a user
interface of a wearable device can allow a user to selectively
delete account identifiers (or any other user data) from the
wearable device. Deletion of data from the wearable device can, but
need not, result in deletion of corresponding data from any other
devices with which the wearable device synchronizes.
[0288] Purchase processes described herein can operate
independently of any particular mechanism for providing account
data to a wearable device. For example, a wearable device can be
used to construct and/or manage a purchase order for a user
regardless of whether it has any purchase account data. A user can
transmit the completed purchase order from the wearable device to a
POS terminal and pay for the purchase using a different medium
(e.g., cash or magnetic-stripe purchase card or the like).
Similarly, the payment processes described above can be implemented
independently of whether the wearable device is used to construct
or manage the purchase order for which payment is made.
[0289] While the invention has been described with respect to
specific embodiments, one skilled in the art will recognize that
numerous modifications are possible and that components,
operations, and/or other features that may be described with
respect to different embodiments can be incorporated into the same
embodiment. Wearable devices can interact with host devices to
facilitate a variety of operations with increased convenience to
the user.
[0290] All user interfaces shown herein are also illustrative.
Sizes of user interfaces or graphical elements thereof can be
modified according to a particular desired form factor of a
wearable device and/or host device. Icons can be used in addition
to or instead of text to identify associated functions, and the
number and arrangement of controls can be varied to facilitate user
operation. In some embodiments, the user may be able to scroll the
display, e.g., by dragging one or two fingers along the surface of
a touchscreen display to see more options than can be presented at
once. Further, while the foregoing description may refer to
graphical user interfaces, other interfaces can also be used. For
example, an audio input interface can be provided by allowing the
user to speak into a microphone of a wearable device; the wearable
device can interpret the audio signal locally to determine a
corresponding instruction or send the audio to a host device for
interpretation. Similarly, an audio output interface can be
provided by using a speaker on the wearable device to produce
sounds. The sounds can include tones (beeps, whirrs, etc.) and/or
speech sounds; for example, synthesized speech can be generated on
a host device and transmitted to the wearable device as a digital
audio signal, or the wearable device can include its own speech
synthesizer. In some embodiments where a wearable device is worn on
the user's hand, wrist, or arm, user input can include spatial
gestures with the hand, wrist, and/or arm that are detected using
motion sensors of the wearable device in addition to or instead of
touch gestures involving contact with a touch-sensitive surface of
the wearable device. Different gestures can be assigned different
meanings, and the meaning of a gesture can be context-dependent,
e.g., depending on what operations of the host device and/or
wearable device are currently in progress. Thus, the same gesture
can, in different contexts, indicate hanging up a call or stopping
playback of a media track. Touch gestures and spatial gestures can
be used in various combinations as desired.
[0291] The foregoing description may make reference to specific
examples of a wearable device (e.g., a wrist-worn device) and/or a
host device (e.g., a smart phone). It is to be understood that
these examples are illustrative and not limiting; other devices can
be substituted and can implement similar functional blocks and/or
algorithms to perform operations described herein and/or other
operations.
[0292] Embodiments of the present invention, e.g., in methods,
apparatus, computer-readable media and the like, can be realized
using any combination of dedicated components and/or programmable
processors and/or other programmable devices. The various processes
described herein can be implemented on the same processor or
different processors in any combination. Where components are
described as being configured to perform certain operations, such
configuration can be accomplished. e.g., by designing electronic
circuits to perform the operation, by programming programmable
electronic circuits (such as microprocessors) to perform the
operation, or any combination thereof. Further, while the
embodiments described above may make reference to specific hardware
and software components, those skilled in the art will appreciate
that different combinations of hardware and/or software components
may also be used and that particular operations described as being
implemented in hardware might also be implemented in software or
vice versa.
[0293] Computer programs incorporating various features of the
present invention may be encoded and stored on various computer
readable storage media; suitable media include magnetic disk or
tape, optical storage media such as compact disk (CD) or DVD
(digital versatile disk), flash memory, and other non-transitory
media. Computer readable media encoded with the program code may be
packaged with a compatible electronic device, or the program code
may be provided separately from electronic devices (e.g., via
Internet download or as a separately packaged computer-readable
storage medium).
[0294] Thus, although the invention has been described with respect
to specific embodiments, it will be appreciated that the invention
is intended to cover all modifications and equivalents within the
scope of the following claims.
* * * * *