Patent Publication Number: US-2021174336-A1

Title: One use wearable

Description:
PRIORITY CLAIM 
     This application claims priority from U.S. Provisional Patent Application No. 62/152,456 filed on Apr. 24, 2015, which is incorporated by reference in the present application. 
    
    
     TECHNICAL FIELD 
     The present disclosure relates to systems and methods for enabling the use of assistive technologies to assist in the selection of information. 
     BACKGROUND 
     Many forms of mobile payments are available to consumers today. While traditional methods such as cash and credit cards remain popular, many consumers also use new forms of payment made available via electronic computing devices, For example, many devices contain near-field communication (“NFC”) capability, which allows a payment to be initiated when the device is placed into close proximity with an NFC reader. The payment terminal obtains payment account information through the NFC reader and then communicates with an appropriate financial network or other back-end processing system to authorize the transaction. 
     Payment tokens are typically used to secure data processed by mobile devices equipped with NFC technology when conducting payment transactions with contactless payment cards, contactless payment terminals, and/or other NFC equipped cell phones, But existing methods and devices for employing payment tokens typically require network connectivity beyond NFC technology in order to request and/or receive payment tokens for mobile payment transactions and to authorize the transactions. Moreover, existing systems that employ NFC technology typically use Bluetooth® or similar wireless technology that are too expensive and/or involve hardware ill-suited for wearable technology. 
     Thus, certain aspects of the disclosed embodiments provide methods and systems that enable the use of payment tokens to conduct transactions, as well as the reprovisioning of payment tokens, on wearable devices without Bluetooth® or other network connectivity beyond NFC radio. Other aspects are also provided as disclosed below. 
     SUMMARY 
     Disclosed embodiments include methods, systems, and computer-readable media configured to, for example, provide payment tokens for conducting transactions, as Weil as reprovisioning tokens, on wearable devices without Bluetooth® or other network connectivity beyond NFC radio. 
     in one aspect, the disclosed embodiments may include a wearable device comprising a near field communication (NFC) system for performing one or more transactions using NFC radio, The device may further include a secure element for providing an environment in which processes and data are be securely stored and executed, the secure element including a plurality of slots. The device may also include at least one storage device storing instructions for conducting a transaction, and at least one processor configured to execute the instructions to perform operations. The operations may include establishing NFC radio communication with a third-party device, and identifying an active slot associated with a token. The operations may also include providing, by the established NFC radio communication and in response to a request by the third-party device, the token stored in the active slot of the secure element. 
     In another aspect, the disclosed embodiments may include a system for issuing and reprovisioning tokens for wearable devices having NFC radio. The system may include a token vault configured to store one or more tables including a plurality of records associated with one or more tokens, wherein the plurality of records includes a plurality of fields for each token including at least a token value, an account number, a confidence score, secure element slot data, and user preferences. The system may include a token vault operator server configured to access the one or more tokens from the token vault provisioned to a secure element of a wearable device associated with a wearable device ID and having a display and a near field communication (NFC) controller. The system may be configured to process authorization requests, received from a merchant device configured to generate and send token authorization requests, for at least one token stored in the token vault associated with the wearable device ID, and provide data from the token vault based on the account number, confidence score, secure element slot data, and user preferences associated with the at least one token. 
     The disclosed embodiments also include a system comprising a database configured to store a plurality of tokens, each token of the plurality of tokens associated with a user. The system may also include at least one network communication device, a storage device comprising instructions, and at least one processor configured to execute the instructions to perform a method. The method may comprise receiving a request for account information from a third-party device, the request for account information comprising at least a token. The method may also comprise accessing the database to identify token information associated with the token, the token information comprising at least the requested account information, a confidence score associated with the token, and one or more user preferences. The method may further include determining whether the confidence score exceeds a predetermined threshold, and determining whether the one or more user preferences require an additional security measure before providing the requested account information. The method may also include providing the requested financial account information to the third-party device after determining that the confidence score exceeds a predetermined threshold and the one or more user preferences do not require an additional security measure. 
     Aspects of the disclosed embodiments may include tangible computer-readable media that stores software instructions that, when executed by one or more processors, are configured to and capable of performing and executing one or more of the methods, operations, or the like consistent with the disclosed embodiments. Also, aspects of the disclosed embodiments may be performed by one or more processors that are configured as special-purpose processor(s) based on software instructions that are programmed with logic and instructions that perform, when executed, one or more operations consistent with the disclosed embodiments. 
     It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosed embodiments, as claimed. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate disclosed embodiments and, together with the description, serve to explain the disclosed embodiments, In the drawings: 
         FIG. 1  is a block diagram of an exemplary system, consistent with disclosed embodiments. 
         FIG. 2  is a diagram of an exemplary wearable device configuration, consistent with disclosed embodiments. 
         FIG. 3  is a diagram of exemplary data structure for storing data in memory of a wearable device, consistent with disclosed embodiments. 
         FIG. 4  is a diagram of exemplary data structure for storing data in token vault, consistent with disclosed embodiments. 
         FIG. 5  is another exemplary system, consistent with disclosed embodiments. 
         FIG. 6  is a flow chart of an exemplary wearable device issuer process, consistent with disclosed embodiments. 
         FIG. 7  is a flow chart of an exemplary wearable device configuration process, consistent with disclosed embodiments. 
         FIG. 8  is a flow chart of an exemplary user purchase process, consistent with disclosed embodiments. 
         FIG. 9  is a flow chart of an exemplary Secure Element reprovisioning process, consistent with disclosed embodiments. 
     
    
    
     DETAILED DESCRIPTION 
     Reference will now be made in detail to the disclosed embodiments, examples of which are illustrated in the accompanying drawings. Wherever convenient, the same reference numbers will be used throughout the drawings to refer to the same or like parts. 
       FIG. 1  is a block diagram of an exemplary system  100  for performing one or more operations, consistent with the disclosed embodiments. In one embodiment, system  100  may include one or more wearable devices  110 , one or more user devices  120 , one or more wearable issuer servers  130 , one or more financial service provider (FSP) servers  140 , one or more token vault operator servers  150 , one or more token vaults  155 , and/or network  170 . Consistent with disclosed embodiments, user  115  may be associated with user device  120  and/or wearable device  110 . The components and arrangement of the components included in system  100  may vary. Thus, system  100  may include other components that perform or assist hi the performance of one or more processes consistent with the disclosed embodiments. 
     Components of system  100  may be computing systems configured to provide methods and systems that enable the use of tokens (e.g., a secure software mechanism that may be used to authorize operations) to conduct payment transactions, as well as reprovision of payment tokens, on wearable devices without Bluetooth® or other network connectivity beyond NFC radio, consistent with disclosed embodiments. As further described herein, components of system  100  may include one or more computing devices (e.g., computer(s), server(s), etc.), memory storing data and/or software instructions (e.g., database(s), memory device(s), etc.), and other known computing components. In some embodiments, the one or more computing devices may be configured to execute software instructions stored on one or more memory devices to perform one or more operations consistent with the disclosed embodiments. Components of system  100  may be configured to communicate with one or more other components of system  100 , including systems associated with wearable device  110 , user device  120 , wearable issuer server  130 , financial service provider (FSP) server  140 , token vault operator server  150 , or token vault  155 . in certain aspects, users may operate one or more components of system  100  to initiate and provide input for one or more operations consistent with the disclosed embodiments. 
     A financial service provider (not shown) may be an entity that provides, maintains, manages, or otherwise offers financial services. For example, financial service provider may be a bank, credit card issuer, or any other type of financial service entity that generates, provides, manages, and/or maintains financial se ice accounts for one or more cardholders. Financial service accounts may include, for example, credit card accounts, loan accounts, checking accounts, savings accounts, reward or loyalty program accounts, and/or any other type of financial service account known to those skilled in the art. Financial service provider include infrastructure and components that are configured to generate and/or provide financial service accounts such as credit card accounts, checking accounts, debit card accounts, loyalty or reward programs, lines of credit, or the like. 
     For example, a financial service provider may include one or more FSP servers  140 . In one aspect, FSP servers  140  may be one or more computing devices configured to perform one or more operations consistent with disclosed embodiments. In one aspect FSP servers  140  may be a desktop computer, a server, or any other type of computing device. FSP servers  140  may include one or more processors configured to execute software instructions stored in memory. The one or more processors may be configured to execute software instructions that when executed by a processor performs known Internet-related communication and financial service-based processes. 
     A merchant (not shown) may be an entity that offers goods, services, and/or information, such as a retailer Macy&#39;s®, Target, etc.), grocery store, service provider (e.g., utility company, etc.), or any other type of entity that offers goods, services, and/or information that consumers (e.g., end-users or other business entities) may purchase, consume, use, etc. in one example, a merchant may be associated with a merchant brick and mortar location that a user (e.g., user  115 ) may physically visit and purchase a product or service. The merchant may also include back- and/or front-end computing components that store data and execute software instructions to perform operations consistent with disclosed embodiments, such as computers that are operated by employees of the merchant (e.g., back office systems, etc.). 
     The merchant may include merchant device  160 . Merchant device  160  may include one or more computing systems, such as server(s), desktop computer(s), point-of-sale device(s), etc., that are configured to execute stored software instructions to perform operations associated with a merchant, including one or more processes associated with processing purchase transactions, generating transaction data, generating product data (e.g., SKU data) relating to purchase transactions, etc. Merchant device  160  may perform one or more operations consistent with the disclosed embodiments. The disclosed embodiments are not limited to any particular configuration of merchant device  160 . As one example, merchant device  160  may be a point-of-sale system like a cash register. Merchant device  160  may comprise functionality and/or hardware operable to receive wireless communications from wearable device  110  and/or user device  120 . For example, merchant device  160  may be configured to utilize technologies such as near field communication (NFC) radio, RFID, infrared, electric field, magnetic fields, or other technologies, in order to initiate and/or process a purchase or other transaction. 
     Merchant device  160  may also generate and send token authorization requests to systems, such as token vault operator server  150  and/or token vault  155 . For example, merchant device  160  may receive a token from wearable device  110  as part of a payment transaction for services and/or good rendered, and merchant device  160  may send the token (along with other information) to token vault operator server  150  and/or token vault  155  requesting financial account information associated with the token with which to complete a payment transaction, Thus, merchant device  160  may also generate and send transaction requests to systems, such as FSP server  140 , Such transaction requests may comply with ISO 8583. For example, upon receiving financial account information associated with the token, merchant device  160  may generate an ISO 8583 message to FSP server  140  indicating that an account holder would like to make a debit transaction for the purchase price of the rendered good or service. 
     Merchant device  160  may include a contactless payment terminal (not shown) comprising any known NFC device designed to communicate (directly or indirectly) with other components of system  100 . For example, the contactless payment terminal (CPT) may be a point of sale (POS) terminal, automated teller machine (ATM), or any other device that is configured to communicate with NFC mobile devices (e.g., wearable device  110  and/or user device  120 ) to facilitate a financial transaction according to disclosed embodiments. 
     Wearable device  110  may be wearable computing devices configured to communicate with other components of systems  100  to perform one or more processes consistent with disclosed embodiments, For example, wearable device  110  may include memory devices configured to store information (e.g., one or more tokens) that may be transmitted to a merchant device (e.g., merchant devices  160 ) for use in processing a transaction. 
       FIG. 2  depicts an exemplary wearable device  110 , consistent with disclosed embodiments. In one embodiment, wearable device  110  may include components that may execute one or more processes to initiate a financial transaction by, for example, transmitting a token associated with a financial account to merchant device  160 . As shown in  FIG. 2 , wearable device  110  may include a display  210 , processor  220 , a memory  230 , a near field communication (NFC) controller  240  comprising at least a secure element  250 , and/or an I/O component  260 . 
     Display  210  may be a device component configured to convey information to a user, such as user  115 . For example, display  210  may be a screen display, one or more LED light(s), etc. In some embodiments, display  210  may be configured to displaying optical payment methods, such as token slots/tokens, or providing information to the user. 
     Processor  220  may include one or more known processing devices, from microcontrollers configured to process simple logic commands, such as PIC microcontrollers, MIPS microcontrollers, etc., to more powerful microprocessors including the Pentium™ or Xeon™ family manufactured by Intel™, the Turion™ family manufactured by AMD™, or any of various processors manufactured by Sun Microsystems. The disclosed embodiments are not limited to any type of processor(s) configured in wearable device  110 . 
     Memory device  230  may include one or more storage devices configured to store information. For example, in some embodiments, memory device  230  may store instructions that may be executed by a processor, such as processor  220 . Memory device  230  may store data that may reflect any type of information in any format that the system may use to perform operations consistent with the disclosed embodiments. 
     In some embodiments, processor  220  may execute one or more programs stored by memory device  230 . For example, processor  220  may execute a transaction program configured to provide a token stored in secure element  250  to a merchant device (e.g., a POS device) when user  115  operates wearable device  110  to complete a financial transaction. 
     NFC controller  240  may be a device with logic that is configured to execute NFC-related operations. Alternatively, NFC controller  240  may be software that is stored in memory device  230 , or a separate memory device in wearable device  110 . NFC controller  240  may operate and be configured according to architectures and designs known to one of ordinary skill in the art. In one embodiment, NFC controller  240  includes a secure element  250  providing an environment in which processes and data may be securely stored and/or executed. In other embodiments, secure element  250  may be separate from NFC controller  240 , such as a separate embedded device in wearable device  110 , such as a SIM/UICC card that functions as the secure element, or software located in memory  230  that may or may not be the same memory that hosts NFC controller  240 . For example, secure element  250  may provide delimited memory for applications operating according to disclosed embodiments. In certain embodiments, secure element  250  may be configured and operate as known secure elements for NFC devices. For example secure element  250  may store applications, slot information, credentials (e.g., tokens), and/or other information associated with secure execution of applications. 
     For example, as shown in  FIG. 3 , secure element  250  may comprise memory storing one or more token slots (fields  251 ) and token values (fields  252 ). For example, secure element may comprise five slots  251 A-E corresponding to five token values  252 A-E. According to some embodiments, each token value  252  -E may correspond to a different financial account of user  115  held with the financial service provider associated with FSP server  140 . In other embodiments, one or more token values  252 A-E may correspond to the same financial account of user  115  held with the financial service provider associated with FSP server  140 . As discussed in more detail below, upon communicating with, e.g., merchant device  160 , wearable device  110  may identify a slot  251 A-D and transmit a corresponding token  252 A-E to merchant device  160  that the underlying merchant may use to obtain a financial account associated with the token in token vault  115 . In some embodiments, wearable device  110  may be preprogrammed with an active slot to use when communicating with a merchant device  160 . In other embodiments, wearable device  110  may identify a slot  251  dynamically based on, for example, a rotating basis, a command from another system  100  component (e.g., merchant device  160 , FSP server  140 , token vault operator server  150 , etc.). 
     I/O devices  260  may also include one or more digital and/or analog devices that allow user  115  to interact with wearable device  110 , such as a touch-sensitive area, buttons, or microphones. I/O devices  260  may also include one or more accelerometers to detect the orientation and inertia of wearable device  110 . I/O devices  304  may also include other components known in the art for interacting with user  115 , such as optical, magnetic, vibration, or other sensors capable of detecting interaction with wearable device  110  by user  115 . 
     In some embodiments, wearable device  110  may be a passive device having no internal power supply. For example, wearable device  110  may draw power to operate from, for example, an NFC reader associated with merchant device  160 . In other embodiments, wearable device  110  may be a semipassive device having an internal power supply for operating circuitry of wearable device  110  but drawing power from, for example, an NFC reader associated with merchant device  160  in order to communicate. In still other embodiments, wearable device  110  may be an active device having an internal power supply capable of operating all aspects of wearable device  110 . 
     Wearable device  110  may be any device configured to be worn or carried by a user, such as a user  115 . For example, wearable device  110  may be incorporated into a wearable item such as a wristband, jewelry, eyeglasses, sunglasses, watch, piece of clothing (e.g., shirt, shoe, pants, jacket, etc.), etc., may include an attachment device (e.g., a clip) to allow it to be attached to a wearable item (e.g., belt), may be incorporated into an item that is normally carried by a user or held in the user&#39;s pocket (e.g., smartphone, wallet, keys), and the like. In ome embodiments, wearable device  110  may be a component of or incorporated into a commercially available wearable computing device, such as Google Glass®, a smartwatch, etc. 
     User device  120  may be one or more computing devices configured to perform one or more operations consistent with disclosed embodiments. User device  120  may be a desktop computer, a laptop, a server, a mobile device (e.g., tablet, smart phone, etc.), or any other type of computing device. For exemplary purposes, aspects of the disclosed embodiments are described with reference to user device  120  as a mobile client device, such as a smart phone, tablet, or the like. As mentioned herein, however, the disclosed embodiments are not limited to such examples. For example, user device  120  could be a laptop, a desktop, or any other device. 
     User device  120  may include one or more processors configured to execute software instructions stored in memory, such as memory included in user device  120 . User device  120  may include software that when executed by a processor performs known Internet-related communication, content display processes, and/or disclosed token vault processes for a user of user device  120 . For instance, user device  120  may execute browser or related mobile display software that generates and displays interfaces including content on a display device included in, or in communication with, user device  120 . User device  120  may be a mobile device that executes mobile device applications and/or mobile device communication software that allows user device  120  to communicate with components over network  170 , and generates and displays content in interfaces via a display device included in user device  120 . The disclosed embodiments are not limited to any particular configuration of user device  120 . For instance, user device  120  may be a mobile device that stores and executes mobile applications that provide token vault functions offered by token vault operator server  150  and/or financial service-related functions offered by FSP server  140 . 
     Wearable issuer server  130  may be one or more devices associated with an entity (not shown) that manufactures, sells, promotes, or otherwise provides wearable devices, such as wearable devices  110 . In some embodiments, wearable issuer server  130  may communicate with user device  120 , FSP server  140 , and/or token vault operator server  150  to, for example, associate one or more financial accounts of user  115  in token vault  155  with one or more tokens stored in secure element  250  of wearable device  110 . 
     Token vault operator server  150  may be one or more devices associated with an entity (not shown) that monitors and/or controls access to token vault  155 . For example, token vault operator server  150  may be operated by VISA®, MasterCard®, or any other entity controlling a payment rail capable of facilitating a transaction from FSP server  140  for an account of user  115  to a merchant associated with merchant device  160 . In other embodiments, may be one or more devices associated with the issuer of wearable device(s)  110 , a financial service provider, etc. Thus, in some embodiments, token vault operator server  150  may be part of wearable issuer server  130 , FSP server  140 , etc. 
     Token vault operator server  150  may execute software that provides data used for generating and displaying interfaces, including content on a display device included in, or connected to, user device  120 , a POS associated with merchant device  160 , etc, In some embodiments, token vault operator server  150  may provide one or more web sites, online portals, APIs, etc. that are accessible by user device  120 , FSP server  140 , wearable issuer server  130 , and/or merchant device  160  over network  170 . The disclosed embodiments are not limited to any particular configuration of token vault operator server  150 . 
     Token vault(s)  155  may include one or more memory devices that store information and are accessed and/or managed through token vault operator server  150 . By way of example, token vault(s)  155  may include Oracle™ databases, SybaseTM databases, or other relational databases or non-relational databases, such as Hadoop sequence files, HBase, or Cassandra. The databases or other files may include, for example, data and information related to generated token(s), token relationships to financial accounts of user(s)  115 , financial records, purchase transaction data, etc. Systems and methods of disclosed embodiments, however, are not limited to separate databases. 
     In one aspect, token vault operator server  150  may include token vault(s)  155 . Alternatively, token vault(s)  155  may be located remotely from the token vault operator server  150 . Token vault(s)  155  may include computing components (e.g., database management system, database server, etc.) configured to receive and process requests for data stored hi memory devices of token vault(s)  155  and to provide data from token vault(s)  155 . 
       FIG. 4  is a diagram of exemplary information stored in token vault(s)  155 , consistent with disclosed embodiments. In one aspect, token vault(s)  155  stores one or more tables that contain records  402 ,  404 ,  406 , and  408 . Each of records  402 ,  404 ,  406 , and  408  contain one or more fields  401  (e.g.,  401 A,  401 B,  401 C,  401 D, and  401 E). The fields, records, and values therein in  FIG. 4  are exemplary and are provided to illustrate embodiments of the disclosure. 
     For example, each record may contain field  401 A, entitled for exemplary purposes as “Token Value.” Field  401 A may contain a unique token value. Token values may be generated, for example, by wearable issuer server  130  token vault operator sever  150 , or other components of system  100 . For example, wearable issuer server  130  may generate one or more token values and store the token value(s) in the secure element  250  when constructing wearable device  110 . Wearable issuer server  130  may transmit the generated token(s) to token vault  155  (via, e.g., token vault operator sever  150 ), which may be inserted into token vault(s)  155  as an entry under field  401 A. 
     Each record may also contain field  401 B, entitled for exemplary purposes as “Account Number.” Field  401 B may contain an account number associated with a financial account of a user (e.g., user  115 ) issued by a financial service provider (e.g., associated with FSP server  140 ). For example, consistent with disclosed embodiments, user  115  may purchase a wearable device  110  from an issuer of wearable devices and operate user device  120  to link with a financial account(s) of user  115  with one or more token(s) stored in secure element  250  of the wearable device  110 . In response, token vault  155  may associate the identified token (which are stored under field  401 A) with the financial account of user  115  by inserting the financial account number in a corresponding field  401 B. 
     Each record may also contain field  401 C, entitled for exemplary purposes as “Confidence Score.” Field  401 C may contain a representation of the estimated likelihood that one or more of the wearable device, secure element, token, or financial account associated with a given row  402 - 408  has become compromised, For example, if user  115  reports wearable device  110  and/or secure element  250  stolen, token vault  155  may insert a confidence score in field  401 C that results in the denial of requests for financial account numbers  401 B using token values  401 A associated with the stolen wearable device  110  and/or secure element  250 . in other embodiments, transactions associated with account numbers  401 B may be monitored for fraudulent activity by one or more components of system  100 , and token vault  155  may update the confidence score indicated in field  401 C based on monitored activities. Thus, in some embodiments, token vault  155  may deny requests for financial account numbers  401 B using token values  401 A associated with confidence scores that have fallen below a threshold. 
     Each record may also contain field  401 D, entitled for exemplary purposes as “Secure Bement Slot Data.” Field  401 D may contain data associated with the slot(s) of a secure element  250  For example, field  401 D may indicate the slot of secure element  250  in which tokens indicated in field  401 A are stored in secure element  250  (e.g., one or more of slots  251 A-D of  FIG. 3 ). In some embodiments, only one slot  251  of secure element  250  may be active at a time (e.g., token vault  155  will only provide an account number associated with secure element  155  when the requesting party—e.g., merchant device  160 —requests the account using the token stored in an active slot). Thus, field  401 D may store data indicating, among other things, the number of slots available on a given secure element  250 , as well as the active slot. In some embodiments, the active slot may rotate through available slots such that the active slot of a secure element  250  is predictable to both token vault  155  and secure element  250 , but not unauthorized parties. In other embodiments, token vault  155  may indicate to secure element  250  (via, e.g., an NFC device at merchant device  160 ) which slot is active before providing a token to merchant device  160  as part of a purchase transaction with user  115 . 
     Each record may also contain field  401 E, entitled for exemplary purposes as “User Preferences,” Field  401 E may contain account token vault preferences of a user (e.g., user  115 ). For example, consistent with disclosed embodiments, user preferences may indicate which account from among a polarity of accounts to use based on set of predefined circumstances. For example, multiple financial accounts may be associated with a token, and user preferences  401 E may instruct token vault operator server  150  to return a first financial account for purchases made for a first merchant, a second financial account for transactions exceeding a predetermine amount, etc. Moreover, the user preferences may indicate that token vault operator server  150  should return the account number associated with the financial account that would provide a purchase discount, maximize rewards associated with a loyalty program, etc, In other embodiments, when each financial account is associated with a separate token, token vault operator server  150  may request the token value associated with the preferred account according to user preferences when presented with a request for a financial account number. User preferences  401 F may further indicate that token vault operator server  150  should prompt merchant device  160  (e.g., a POS terminal) to request a PIN, biometrics, etc. for transactions would lower confidence score  401 C (e.g., due to a higher risk associated with an new merchant, uncharacteristically high transaction amount, etc.). Token vault  155  may associate the identified token (which are stored under field  301 A) with the user preferences by inserting the user preferences in a corresponding field  401 E. 
     One of ordinary skill will understand that token vault  155  may contain other fields and/or additional types of data. For example, token vault  155  may contain information such as security codes (e.g., CVV, CVV 2 ) associated with account numbers  401 B may contain expiration dates associated with account numbers  401 B, may contain names on payment cards associated with account numbers  401 B, etc. Moreover, while  FIG. 1  depicts a single token vault  155 , one of ordinary skill will understand that a plurality of token vaults  155  may be employed operated by the same and/or different components of system  100  may be possible. 
     Network  170  may be any type of network configured to provide communications between components of system  100 . For example, network  170  may be any type of network (including infrastructure) that provides communications, exchanges information, and/or facilitates the exchange of information, such as the Internet, a Local Area Network, wireless network (e.g., a Wi-Fi/802.11 network), NFC, magnetic fields, Optical code scanner, infrared, or other suitable connection(s) that enables the sending and receiving of information between the components of system  100 . In other embodiments, one or more components of system  100  may communicate directly through a dedicated communication link(s) (shown and not shown). 
     It is to be understood that the configuration and boundaries of the functional building blocks of system  100  have been arbitrarily defined herein for the convenience of the description. Alternative boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. For example, wearable device  110 , user device  120 , wearable issuer server  130 , FSP server  140 , token vault operator server  150 , or token vault  155  may constitute a part of components of system  100  other than those specifically described, or may constitute a part of multiple components of system  100  (i.e., a distributed system). Moreover, token vault operator server  155  and token vault  155  may be separate and distinct from other components of system  100  (as shown), or token vault operator server  155  and token vault  155  may be may be part another component of system  100 , such as FSP server  140 . 
       FIG. 5  is a diagram of another exemplary system  500 , consistent with disclosed embodiments. Variations of exemplary system  500  may be used by user device  120 , wearable issuer server  130 , FSP server  140 , token vault operator server  150 , and/or token vault  155 . In one embodiment, system  500  may comprise one or more processors  521 , one or more input/output (U 0 ) devices  522 , and one or more memories  523 . In some embodiments, system  500  may take the form of a server, general purpose computer, mainframe computer, or any combination of these components. In some embodiments, system  500  may take the form of a mobile computing device such as a smartphone, tablet, laptop computer, or any combination of these components. Alternatively, system  500  may be configured as a particular apparatus, embedded system, dedicated circuit, or the like based on the storage, execution, and/or implementation of the software instructions that perform one or more operations consistent with the disclosed embodiments. 
     Processor  521  may include one or more known processing devices, such as mobile device microprocessors or any various other processors. The disclosed embodiments are not limited to any type of processor(s) configured in system  200 . 
     Memory  523  may include one or more storage devices configured to store instructions used by processor  521  to perform functions related to disclosed embodiments. For example, memory  523  may be configured with one or more software instructions, such as program(s)  224  that may perform one or more operations when executed by processor  521 . The disclosed embodiments are not limited to separate programs or computers configured to perform dedicated tasks. For example, memory  523  may include a single program  224  that performs the functions of the user device  120 , or program  224  may comprise multiple programs. Memory  523  may also store data  225  that is used by one or more programs. In certain embodiments, memory  523  may store software that may be executed by processor(s)  221  to perform one or more processes consistent with disclosed embodiments. 
     I/O devices  522  may be one or more devices configured to allow data to be received and/or transmitted by system  200 . I/O devices  522  may include one or more digital and/or analog devices that allow system  200  to communicate with other machines and devices, such as other components of system  100 . I/O devices  522  may also include one or more digital and/or analog devices that allow a user to interact with system  200  such as a touch-sensitive area, keyboard, buttons, or microphones. I/O devices  522  may also include other components known in the art for interacting with a user. 
     The components of system  500  may be implemented in hardware, software, or a combination of both hardware and software, as will be apparent to those skilled in the art. For example, although one or more components of system  500  may be implemented as computer processing instructions, all or a portion of the functionality of system  500  may be implemented instead in dedicated electronics hardware. 
     System  500  may also be communicatively connected to one or more database(s)  527 . System  500  may be communicatively connected to database(s)  527  through network  170 . Database  527  may include one or more memory devices that store information and are accessed and/or managed through system  500 . By way of example, database(s)  527  may include Oracle databases, Sybase™ databases, or other relational databases or non-relational databases, such as Hadoop sequence files, Haase, or Cassandra. The databases or other files may include, for example, data and information related to the financial records, purchase transaction data, etc. Systems and methods of disclosed embodiments, however, are not limited to separate databases. In one aspect, system  500  may include database  527 , Alternatively, database  527  may be located remotely from the system  500 . Database  527  may include computing components (e.g., database management system, database server, etc.) configured to receive and process requests for data stored in memory devices of database(s)  527  and to provide data from database  527 . 
       FIG. 6  is a flow chart of an exemplary wearable device issuer process  600 , consistent with disclosed embodiments. 
     In step  602 , wearable device  110  may be constructed. For example, a manufacturer may produce a wristband, jewelry, watch, money clip, wallet, key, keyfob or some other type of item that includes the components of wearable device  110  and may be worn or carried by user  115 . In step  604 , the wearable device  110  (or, more particularly, secure element  250  of wearable device  110 ) may be associated with a wearable device D. For example, wearable issuer server  130  may generate a wearable device ID and associate it with the constructed wearable device  110 . One or more tokens may also become generated (step  606 ) and stored on secure element  250  (step  608 ), In some embodiments, wearable issuer server  130  may generate the one or more tokens. One of ordinary skill in the art, however, would understand that systems associated with other entities of system  100 , such as token vault operator server  150  or FSP server  140 , may generate the tokens that become stored in secure element  250 . At step  610 , wearable issuer server  130  may associate the wearable device ID with the generated one or more tokens. Wearable issuer server  130  may further transmit the wearable device ID, generated one or more tokens, and association information to token vault  155  (via, e.g., token vault operator server  150 ). In some embodiments, wearable issuer server  130  may transmit the wearable device ID, generated one or more tokens, and association information in response to a request by token vault  155  upon a user  115  initiating a wearable device configuration process  700 , as discussed below in more detail. 
       FIG. 7  is a flow chart of an exemplary wearable device configuration process  700 , consistent with disclosed embodiments. For ease of discussion, process  700  may be discussed from the perspective of wearable issuer server  130 . It should be understood, however, that other components of system  100 —such as token vault operator server  150 —may execute one or more steps of process  700 . 
     At step  702 , wearable issuer server  130  may provide one or more interface(s) to user device  120 . For example, user  115  may purchase wearable device  110  and operate user device  120  to access a web site, online portal, API, etc. provided by wearable issuer server  130  in order to activate wearable device  110  for use in financial transactions, At step  704 , wearable issuer server  130  may receive a wearable device ID from user device  120  via the provided interface(s). Based on the received wearable device ID, wearable issuer server  130  may identify one or more tokens stored on secure element  250  of the wearable device  110  associated with the received wearable ID (step  706 ). Wearable issuer server  130  may also receive user personal information personal information from the user device  120  via the provided interface (step  708 ). For example, wearable issuer server  130  may receive personal information including, but not limited to, user  115 ′s name, address, social security number, phone numbers, financial account numbers, access credentials to one or more financial accounts, and the like. For example, user  115  may operate user device  120  to provide wearable issuer server  130  with an indication as to which financial accounts user  115  would like to associate with the one or more tokens identified in step  706 . In some embodiments, at step  710 , wearable issuer server  130  may interact with one or more other components of system  100 —such as FSP server  140 —to authenticate user  115  or otherwise confirm the identify and provided personal information provided by user  115  operating user device  120 . At step  712 , wearable issuer server  130  may transmit the received financial account information to token vault  155  for association with the provided wearable device ID and associated tokens (e.g., the tokens associated with the wearable device ID at step  610 / 612 ). 
       FIG. 8  is a flow chart of an exemplary user purchase process  800 , consistent with disclosed embodiments. For ease of discussion, process  800  may be discussed from the perspective of token vault operator server  150  and token vault  155 . It should be understood, however, that other components of system  100 —such as FSP server  140 —may execute one or more steps of process  800 . 
     At step  802 , token vault operator server  150  may receive a request for financial account information associated with a token. For example, user  115  may present wearable device  110  during checkout at a merchant associated with merchant device  160 . Wearable device  110  may pass a token stored on secure element  250  to merchant device  160  via NFC controller  240 , and merchant device  160  may, in turn, request the account number associated with the passed token in order to complete a financial transaction. At step  804 , token vault operator server  150  may access token vault  155  to identify one or more fields (e.g.,  401 B- 401 E) associated with the received token. Token vault operator server  150  may further identify a confidence level associated with the token (e.g., field  401 C) (step  806 ) and determine whether the confidence level exceeds a threshold (step  808 ). If the confidence level associated with the token meets or exceeds the threshold (step  808 ; YES), token vault operator server  150  may provide merchant device  160  with the requested financial account information (step  810 ). If the confidence lever associated with the token falls below the threshold (step  808 ; NO), token vault operator server  150  may deny the request for Financial account information made by merchant device  160  (step  810 ). In some embodiments, token vault operator server  150  may require additional authentication data (e.g., PIN, biometric data, etc.) before providing the requested financial account information (step not shown). In some embodiments, token vault operator server  150  may provide reprovisioning data for reprovisioning secure element  250  with new token information according to method discussed with respect to  FIG. 9  below. After providing reprovisioning data, token vault operator server  150  may update token vault  155  to associate a new token with the identified one or more fields (e,g.,  401 B- 401 E) previously associated with the received token. 
       FIG. 9  is a flow chart of an exemplary secure element reprovisioning process  900 , consistent with disclosed embodiments. For ease of discussion, process  900  may be discussed from the perspective of token vault operator server  150  and token vault  155 . It should be understood, however, that other components of system  100 —such as FSP server  140 —may execute one or more steps of process  900 . 
     At step  904 , token vault operator server  150  may identify a secure element  250  for reprovisioning. Reprovisioning may refer to, for example, replacing or token on secure element  250  or setting another slot of secure element as the active slot for use in transactions. 
     In some embodiments, token vault operator server  150  may identify an element  250  for reprovisioning when a confidence score  401 C falls below acceptable limits. hi some embodiments, confidence score  401 C of a secure element  250  may fall below acceptable limits after token vault operator server  150  receives an indication from another component of system  100  (shown or not shown) that token  401 A has become compromised (e.g., stolen, associated with potentially fraudulent activity, etc.). Additionally or alternatively, token vault operator server  150  may reprovision secure elements  250  on a regular timetable. In such embodiments, token vault operator server  150  may identify an element  250  for reprovisioning after determining that the period of time since the last time the secure element  250  was reprovisioned exceeds a certain limit. 
     At step  906 , token vault operator server  150  may determine whether secure element  250  includes a plurality of slots, and that at least one slot from the plurality of slots is available (e.g., includes a token not associated with a financial account). For example, token vault operator server  150  may access Secure Element Slot Data associated with the token in field  401 D of token vault  155 . If another slot is available on secure element  250  (step  906 ; YES), token vault operator server  150  may update token vault  155  (step  908 ) to associate the token of the available slot with the account number  401 B, user preferences  401 F, etc. 
     Additionally or alternatively, secure element  250  may include a plurality of slots each having a token associated with the same financial account, and secure element  250  and token vault operator server  150  may automatically increment through the plurality of slot after every use of the wearable device  110  to make a purchase transaction. In such embodiments, no communication need take place between secure element  250  and token vault operator server  150  to reprovision the secure element  250 . 
     At step  910 , token vault operator server  150  may provide an indication of the active slot for updating the secure element  250 . For example, token vault operator server  150  may cause merchant device  160  (e.g., POS terminal) and/or user device  120  to display an indication of the new active slot. Wearable device  110  and/or secure element  250  may be manipulated to switch the active slot on the secure element  250 . For example, wearable device  110  and/or secure element  250  may include a binary addressing switch panel, multipole toggle switches, and/or other type of physical mechanism for manipulating the active slot of secure element  250 . In other embodiments, wearable device  110  may include a vibration sensor capable of recognizing physical gestures of user  115  (e.g., tapping on the wearable device  110 ). In still other embodiments, wearable device  110  may be configured to receive a magnetic trigger for switching the polarity of components indicating the active slot of wearable device  110 . 
     Regardless of the means for altering the active slot of secure element  250 , wearable device  110  may include a display for conveying the current active slot setting of secure element  150 . For example, where a secure element comprises four slots, the second of which is the active slot, wearable device  110  may cause two LED lights of a display to light up. 
     If another slot is not available on secure element  250  (step  906 ; NO), token vault operator server  150  may determine whether wearable device  912  may receive a new token (step  912 ). If so (step  912 ; YES), token vault operator server  150  may provide a new token to wearable device  110  for storage on secure element  250 . For example, token vault operator serrver  150  may determine that wearable device  110  may receive NFC radio communications from merchant device  160 . Upon such a determination, token vault operator server  150  may transmit the new token to merchant device  160  via, e.g., network  170 , and merchant device  160  may transmit the new token to wearable device  110  via NFC radio for storage on secure element  250 . 
     if token vault operator server  150  determines that wearable device  912  may receive not a new token (step  912 ; NO), token vault operator server  150  may issue a new secure element for wearable device  110 , For example, token vault operator server  150  may determine that wearable device  110  includes a removable secure element  250 . Upon such a determination, token vault operator server  150  may cause a new secure element  250  storing the new token to become provided to user  115  for installation in wearable device  110 . 
     At step  920 , token vault operator server  150  may update token vault  155  to reflect the new token slot and/or token value associated with wearable device  110 . 
     The foregoing description has been presented for purposes of illustration. It is not exhaustive and is not limited to the precise forms or embodiments disclosed. Modifications and adaptations of the embodiments will be apparent from consideration of the specification and practice of the disclosed embodiments. For example, the described implementations include hardware and software, but systems and methods consistent with the present disclosure can be implemented as hardware alone. Furthermore, although aspects of the disclosed embodiments are described as being associated with data stored in memory and other tangible computer-readable storage mediums, one skilled in the art will appreciate that these aspects can also be stored on and executed from many types of tangible computer-readable media, such as secondary storage devices, like hard disks, floppy disks, or CD-ROM, or other forms of RAM or ROM. 
     Computer programs based on the written description and methods of this specification are within the skill of a software developer. The various programs or program modules can be created using a variety of programming techniques. For example, program sections or program modules can be designed in or by means of Java, C, C++, assembly language, or any such programming languages. One or more of such software sections or modules can be integrated into a computer system, computer-readable media, or existing communications software. 
     Moreover, while illustrative embodiments have been described herein, the scope includes any and all embodiments having equivalent elements, modifications, omissions, combinations (e.g., of aspects across various embodiments), adaptations or alterations based on the present disclosure. The elements in the claims are to be interpreted broadly based on the language employed in the claims and not limited to examples described in the present specification or during the prosecution of the application, which examples are to be construed as non-exclusive. Further, the steps of the disclosed methods can be modified in any manner, including by reordering steps or inserting or deleting steps. it is intended, therefore, that the specification and examples be considered as example only, with a true scope and spirit being indicated by the following claims and their full scope of equivalents.