US9691059B1 - Systems and methods for transactions using an ATM/credit/debit card and a second communications channel to an account holder's bank - Google Patents

Abstract

Systems and methods for performing a transaction with a headless point-of-sale or automated teller machine (ATM) device are disclosed using a card having a second communications path to a financial services provider. A card having a display and radio frequency (RF) communications module may be authenticated with a headless point-of-sale device using a short-range RF communications link. Characteristics of the card may be set prior to the transaction. Transaction information may be provided to the display of the card from the headless point-of-sale device. A customer may confirm the transaction at the card using a touch-sensitive input area. During the processing, a communication may be made over the second communications path to authorize the transaction independently of the transaction processing path. A transaction may then be completed at the headless point-of-sale device.

Description

BACKGROUND

The process by which customers have made purchases or withdrawals currency from point-of-sale (POS) devices and automated teller machines (ATM) has remained the same for a considerably long time. The user first approaches the POS/ATM, insert or swipes his/her card into the card reader, enters a PIN number in accordance with a transaction type, responds to the prompts on the screen, and makes a payment or receives currency and a receipt. However, conventional cards provide litter or no configurable parameters to adjust to the specifics of a transaction. As such, a conventional credit/debit card may be used to make purchases without regard to the merchant where the purchase is being made, the location of the merchant, etc. Similarly, a conventional credit/debit card may be used by one joint account holder without the knowledge or approval of another joint accounts holder. Thus, conventional credit/debit/ATM cards may not be suitable for certain transaction types under certain conditions.

SUMMARY

Systems and methods for performing a transaction with a headless point-of-sale or automated teller machine (ATM) device are disclosed using a card having a second communications path to a financial services provider. A card having a display and radio frequency (RF) communications module may be authenticated with a headless point-of-sale device using a short-range RF communications link. Transaction information may be provided to the display of the card from the headless point-of-sale device. A customer may confirm the transaction at the card using a touch-sensitive input area. The headless point-of-sale device may then provide the transaction information to a transaction processor for processing and verification. During the processing, a communication may be made over the second communications path to authorize the transaction independently of the transaction processing path. A transaction may then be completed at the headless point-of-sale device.

In some implementations, where the headless device is a headless ATM, the card may be authenticated to the ATM. Transaction information may be entered and displayed on the card. A communication may be made over the second communications path to authorize the card transaction with the headless ATM independently of the ATM transaction processing path. A cardholder may authenticate with the ATM by entering, e.g., a PIN number and funds may be dispensed to the cardholder upon verification of the PIN.

This summary is provided to introduce a selection of concepts in a simplified form that are further described in the detailed description section. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing summary, as well as the following detailed description of preferred embodiments, is better understood when read in conjunction with the appended drawings. For the purposes of illustration, there is shown in the drawings exemplary embodiments; however, the present disclosure is not limited to the specific methods and instrumentalities disclosed. In the drawings:

FIG. 1 illustrates an example financial transaction system;

FIG. 2 depicts the front surface of an exemplary contactless card in accordance with implementations herein;

FIG. 3 shows a block diagram of exemplary RF module;

FIG. 4 shows an example process for conducting a transaction at an ATM/POS device using the card ofFIG. 2;

FIG. 5, which illustrates an example operational flow for processing the card ofFIG. 2 as a bearer card;

FIG. 6, which is an example operational flow of processing the card ofFIG. 2 as a youth card;

FIG. 7, which is an example operational flow of processing the card ofFIG. 2 as a joint account card;

FIG. 8, which is an example operational flow of processing the card ofFIG. 2 as configured generally;

FIG. 9 illustrates exemplary transaction types that may be implemented in the system ofFIG. 1 using the ATM/POS and the card ofFIG. 2; and

FIG. 10 is a block diagram of an example computing environment that may be used in connection with implementations of the subject matter described herein.

DETAILED DESCRIPTION

FIG. 1 illustrates an examplefinancial transaction system100. A population of user cards is represented herein bycards102. Thecards102 may be configured as credit cards, debit cards, gift cards, loyalty cards, ATM cards, and other types in these general formats, as described below. Eachcard102 may include a magnetic stripe that includestracks 1, 2 and/or 3. The magnetic stripe may include a primary account number (PAN), a name, an expiration date, a service code, discretionary data (e.g., a Pin Verification Key Indicator (PVKI), Pin Verification Value (PVV), Card Verification Value or Card Verification Code (CVV, CVK, CVC1, CVV1), a Longitudinal redundancy check (LRC), etc. In a typical 16-digit credit/debit card personal account number (PAN) [XXXX XXXX XXXX XXXX], the first digit is a card system identifier (VISA/MC/AMEX), the next 5-digits are a bank identification number (BIN), the next 9-digits are the customer user account number, and the longitudinal redundancy check character (LRC).

Thecard102 may be a contactless smart card that includes embedded integrated circuits such that thecard102 may communicate with acard reader106 through RFID induction technology. As such, thecard102 need only be in close proximity to anantenna107 to complete a transaction with an automated teller machine/point-of-sale device (ATM/POS)105. The standard for contactless smart card communications is ISO/IEC 14443, which defines two types of contactless cards (“A” and “B”), that allows for communications at distances up to 10 cm. In some implementations, thecard102 may use a built-in inductor to capture some of the incident radio-frequency interrogation signal, rectify it, and use it to power the card's electronics. Thecard102 may also include a user interface through which information may be presented to, or received from, a user. A more detailed description of the contactless card is provided with reference toFIG. 2.

Thecard102 may also be used as an electronic wallet. The integrated circuits in thecard102 may be loaded with funds, which can be spent in parking meters, vending machines, merchants, etc. Cryptographic protocols protect the exchange of money between the smart card and the accepting machine. No connection to an issuing bank is necessary in such a configuration, so the holder of the card can use it regardless of the holder being the owner of the card and/or account associated with the card.

Amerchant101 may have the ATM/POS device105 at a location that may be configured as “headless” device (i.e., no display). The ATM/POS105 may include a CPU to control transaction devices, a magnetic and/or chip card reader to identify the customer, a secure cryptoprocessor, and, optionally, a printer to provide the customer with a record of their transaction. In some implementations, the ATM/POS105 may lack a physical input device (e.g., a keypad) and rely solely on thecard102 to send and receive information to the user. Many ATMs include an architecture similar to a general purpose computing device, as described with reference toFIG. 10. For example, many ATMs/POS devices use operating systems such as MICROSOFT WINDOWS and LINUX.

In some implementations, the ATM/POS105 may include, or be operably connected to, thereader106 that may have theRF antenna107 in some implementations. Thereader106 provides an interrogation signal for powering thecard102 when thecard102 is positioned in proximity to thereader106. The interrogating signal may power thecard102 thereby initiating operation of thecard102 to perform a transaction.

In some implementations, thereader106 may be a more general purpose wireless communication system. In such implementations, thereader106 may be configured to communicate with devices using such protocols and standards as IEEE 802.11x, Bluetooth, IEEE 802.16, among others. As such, thereader106 may communicate with wireless devices such as handsets, laptop personal computing devices and other mobile computing devices, etc.

In some implementations, thereader106 may be a contact plate on which thecard102 is placed to power thecard102 to perform a transaction. In some implementations, thereader106 and ATM/POS105 may be a surface computing device, such as MICROSOFT SURFACE. Thecard102 may communicate with thereader106 by placing it on a surface to active the card's electronics.

As part of the transaction process, the ATM/POS105 may readmagnetic swipe data104 that may include, a user identification ISO/IEC and/orTrack 1/2/3 data. In some implementations, the above information may be received from thecard102 or other handheld wireless device using thereader106. The information may be communicated together with other details of the transaction (e.g., an amount, type of transaction, merchant/bank ID, etc.) to atransaction processor108 to authenticate the user account and approve the transaction.

Thetransaction processor108 includes an accountaccess request process110, afraud detection process112, and anauthorization process114. These may also be used to administer inter-partner data exchanges, such as when transaction data and requests are bridged bi-directionally between the payment infrastructure (e.g., the ATM/POS105) and one or morefinancial institutions116a. . .116n.

Eachfinancial institution116a. . .116nthat providescards102 may maintain arespective customer database118a. . .118ncontaining information for each customer such as a residence/mailing address (street, city, state and ZIP code), contact information (telephone, e-mail, etc.), social security number, and security information (a secret password or passphrase, answer(s) to security question(s)). Eachfinancial institution116a. . .116nmay maintain arespective ledger balance120a. . .120nto track transactions and balances for each customer account to determine an amount of funds on deposit, loan balances, etc.

Thefinancial institutions116a. . .116nmay authenticate the user based on information contained in themessage104 and information contained in thecustomer databases118a. . .118nand ledger balances120a. . .120n. If the transaction is approved, anauthorization code122 is returned to the ATM/POS105 by the paymentprocessor authorization process114 to enable the user to perform a transaction on the ATM/POS105. Thus, in thesystem100, transactions made at the ATM/POS105 may be processed as ATM transactions.

FIG. 2 depicts the front surface of an exemplary contactless card in accordance with implementations herein. Thecard102 may have any shape and may be formed having a size similar to a credit card (i.e., as set in ISO/IEC 7810, which defines the dimensions as 85.60×53.98 mm), a SIM card (i.e., ID-000 which is 25×15 mm), or as a key fob having varying dimensions. Thecard102 may include adisplay area210, anRF module220 for conducting a RF transaction, anembossed card number230, anetwork interface240, abattery250, and a magnetic stripe on the back (not shown).

Thedisplay area210 may be a touch-sensitive display to receive inputs from a user and to display information to the user. The touch-sensitive display may be one or a combination of the following types: resistive, capacitive, dispersive signal, acoustic pulse, electronic ink (e-ink), etc. Thedisplay area210 may be rendered operational when placed into communication with the ATM/POS105. A resistive display may include a panel that is covered with a conductive and a resistive metallic layer. The two layers are held apart by spacers, and a scratch-resistant layer is placed on top. An electrical current may runs through the two layers while thedisplay area210 is operational. When a user touches the screen, the two layers make contact in that exact spot. The change in the electrical field is noted and the coordinates of the point of contact are calculated. Once the coordinates are known, a driver320 (see,FIG. 3) translates the touch into something that thecard102 understands as a position.

In the capacitive system, a layer that stores electrical charge is placed on thedisplay area210. When a user touches thedisplay area210 with his or her finger, some of the charge is transferred to the user, so the charge on the capacitive layer decreases. This decrease is measured in circuits located at each corner of thedisplay area210. From the relative differences in charge at each corner, thecard102 may calculate exactly where the touch event took place and then relays that information to the driver.

In an acoustic pulse system, two transducers (one receiving and one sending) are placed along the x and y axes of thedisplay area210. Also placed on thedisplay area210 are reflectors that reflect an electrical signal sent from one transducer to the other. The receiving transducer is able to tell if the wave has been disturbed by a touch event at any instant, and can locate it accordingly.

Electronic ink displays utilize microcapsules, each of which contains positively charged white particles and negatively charged black particles suspended in a clear fluid. When a negative electric field is applied, the white particles move to the top of the microcapsule where they become visible to the user. This makes the surface appear white at that spot. At the same time, an opposite electric field pulls the black particles to the bottom of the microcapsules where they are hidden. By reversing this process, the black particles appear at the top of the capsule, which now makes the surface appear dark at that spot. To form an e-ink electronic display, the ink is printed onto a sheet of plastic film that is laminated to a layer of circuitry. The circuitry forms a pattern of pixels that can then be controlled by thedisplay driver320.

FIG. 3 shows a block diagram ofexemplary RF module220. Themodule220 may include any conventional RF circuitry capable of communicating using Radio Frequency (RF) transmission. Themodule220 may also be electrically connected to receive inputs from thedisplay area210 using asuitable display driver320. TheRF module220 may include anantenna304 for receiving an interrogation signal fromRFID reader106 viaantenna107. Theantenna304 may be in communication with atransponder314. Thetransponder314 may be a 13.56 MHz transponder compliant with the ISO/IEC 14443 standard, and theantenna304 may be of the 13 MHz variety.

Thetransponder314 may be in communication with a transponder compatible modulator/demodulator306 configured to receive the signal from thetransponder314 and configured to modulate the signal into a format readable by any later connected circuitry. Further, the modulator/demodulator306 may be configured to format (e.g., demodulate) a signal received from the later connected circuitry in a format compatible with thetransponder314 for transmitting to thereader106 via theantenna304. For example, where thetransponder314 is of the 13.56 MHz variety, the modulator/demodulator306 may be ISO/IEC 14443-2 compliant.

The modulator/demodulator306 may be coupled to a protocol/sequence controller308 for facilitating control of the authentication of the signal provided by thereader106, and for facilitating control of the sending of the module account number. In this regard, protocol/sequence controller308 may be any suitable digital or logic driven circuitry capable of facilitating determination of the sequence of operation for themodule220 inner-circuitry. For example, protocol/sequence controller308 may be configured to determine whether the signal provided by thereader106 is authenticated, and thereby providing to thereader106 the account number stored onmodule220.

To authenticate the signal, the protocol/sequence controller308 may be further in communication withauthentication circuitry310 for facilitating authentication of the signal provided by thereader106. Similarly, theauthentication circuitry310 may facilitate the sending and receipt of information to and from thedisplay area210 through thedisplay driver320. The authentication circuitry may be further in communication with a non-volatilesecure memory database312.Secure memory database312 may be any suitable elementary file system such as that defined by ISO/IEC 7816-4 or any other elementary file system allowing a lookup of data to be interpreted by the application on the chip. Thedatabase312 may be any type of database, such as relational, hierarchical, object-oriented, and/or the like. Thedatabase312 may be organized in any suitable manner, including as data tables or lookup tables.

Association of certain data in thedatabase312 may be accomplished either manually or automatically. Automatic association techniques may include, for example, a database search, a database merge, GREP, AGREP, SQL, and/or the like. The association may be accomplished by a database merge function, for example, using a “key field” in each of the manufacturer and retailer data tables. A “key field” partitions the database according to the high-level class of objects defined by the key field. For example, a certain class may be designated as a key field in both the first data table and the second data table, and the two data tables may then be merged based on the class data in the key field. The data corresponding to the key field in each of the merged data tables may be the same. However, data tables having similar, though not identical, data in the key fields may also be merged by using AGREP, for example.

The data received from thereader106 or thedatabase312 may be used by the protocol/sequence controller308 for data analysis and used for management and control purposes, as well as security purposes. Theauthentication circuitry316 may authenticate the signal provided byreader106 by association of the signal to authentication keys stored ondatabase312. Theauthentication circuitry316 may be in further communication withencryption circuitry316 which may encrypt or decrypt thereader106 signal or the data (e.g., account number, user identifier, device identifier, etc.) returned from thedatabase312 prior to transmitting the data. Theencryption circuitry316 may use keys stored on thedatabase312 to perform encryption and/or decryption of signals sent to or from theRFID reader106.

In addition, the protocol/sequence controller308 may be in communication with thedatabase312 for storing at least one ofmodule220 account data, a unique module identification code, user identification code, or transaction device identifier, etc. The protocol/sequence controller308 may be configured to retrieve the account number fromdatabase312 as desired. The account data and/or unique device identification code stored on thedatabase312 may be encrypted prior to storage.

Thus, where the protocol/sequence controller308 retrieves the account data, and or unique transaction device identifier, or the like, from thedatabase312, the data may be encrypted by theencryption circuit316 when being provided toreader106. Further, the data stored on thedatabase312 may include, for example, an unencryptedunique module220 identification code, a user identification ISO/IEC,Track 1/2/3 data, as well as specific application applets. The data may additionally be stored in thedatabase312 inTrack 1/Track 2/Track 3 format and may also be inTrack 1/Track 2/Track 3 format when provided to thereader106

In an exemplary operation, themodule220 is placed in proximity to, or physically on, thereader106 when the user wishes to conduct a transaction. The user simply positions themodule220 at a certain distance from thereader106 until thereader106 acknowledges that the information contained in themodule220 has been received. Thereader106 then utilizes at least a portion of the information provided by module220 (such as, a user's account number associated with the transaction device) to complete the transaction. Thereader106 may receive the account information from themodule220 and verify the account information authenticity prior to forwarding the account information to thetransaction processor108.

Inputs may be received in thedisplay area210 and interpreted by thedisplay driver320, as noted above. The inputs may be input to theauthentication circuit310 and the protocol/sequence controller308 configured to send and receive information to and from thedisplay area210 to the modulator/demodulator306 and theantenna304 to allow a user to interact with thecard102 during a transaction. The interaction may allow the user to perform a transaction at the ATM/POS105 (or other point of sale device) to withdraw cash, pay for goods and services, etc., using thecard102.

Theembossed card number230 may be a conventional raised card number and may be optional. Having theembossed card number230 allows the card to be used as a conventional credit/debit/ATM card where a merchant can verify the card number with magnetic swipe information at the point of sale.

Thenetwork interface240 may implement one or more connections standards. Examples include IEEE 802.11 series, Bluetooth, IEEE 802.16 series, among others. Further examples of communication standards are Global System for Mobile Communications (GSM) network, an Internet Protocol (IP) network, a Wireless Application Protocol (WAP) network, a WiFi network, or local area network (LAN), BLUETOOTH, as well as various combinations thereof. Other conventional and/or later developed wired and wireless networks may also be used. The network interface may utilize components within theRF module220 to link to an external wireless network infrastructure.

Thebattery250, if provided, may be comprised of a monolithic electrochemical cell having a lithium-containing cathode, a carbon anode, and a porous polymer separator infused with electrolyte solution. The cell has a thickness of less than 0.7 mm, such that it fits within thecard102.

FIG. 4 shows anexample process400 for conducting a transaction at an ATM/POS device105 using thecard102. At402, the card is powered-up. Thecard102 may be brought into proximity to thereader106 or placed on top of thereader106 to induce a current within thecard102 to power up the internal circuitry. In some implementations, if thecard102 includes abattery250, thecard102 may be powered up through user action.

At404, the card authenticates to the ATM/POS. Information within thedatabase312 may be communicated to thereader106 to authenticate the card with the ATM/POS105. For example, a card identifier, a financial institution identifier, an account number, etc., may be communicated to thereader106 by theRF module220 in thecard102. The ATM/POS105 may receive information from thecard102 to determine if thecard102 can continue communications with the ATM/POS105. In some implementations, the user may enter a PIN number, pass phrase, username/password, etc., into thecard102 through the touchscreen display area210 in addition or alternatively to the above.

At406, it is determined if the card has authenticated to the ATM/POS105. If the authentication fails, then at408 the process ends. If the authentication is successful, then at410, asecure transmission path124 between thecard102 and a financial institution (e.g.116a) is established. As noted above, thesecure transmission path124 may be a separate communications that between thecard102 and thefinancial institution116aoutside conventional ATM network.

At412, the user and/or card is identified. The user may enter a pin number, pass phrase, username/password, etc., into thecard102 through the touchscreen display area210 to identify the user and/or card with thefinancial institution116a. In accordance with the identification and412, a car type may be determined at414. For example, thecard102 may have a predefined configuration, such as a conventional credit/debit/ATM card, a bearer card, a youth card, a joint account card, or other. It is noted that the types of cards illustrated inFIG. 4 are merely for exemplary purposes and should not be construed as limiting the type(s) of configurations thecard102 may have.FIG. 9 illustrates additional non-limiting uses and types configurations that may be assigned to thecard102.

If at416, is determined at thecard102 is configured as conventional credit/debit/ATM card, then the card may be processed by amerchant101 or conventional ATM in a conventional fashion.

If at416, the card type is determined to be a bearer card, the process continues as shown inFIG. 5, which illustrates an exampleoperational flow500 for processing thecard102 as a bearer card. In accordance with implementations herein, the bearer card acts like cash instrument may be used by the cardholder to withdraw a predetermined amount of funds from the ATM/POS105. This may be a single-transaction or one-time-use-only card that has specific purposing such as, “dispense $100 from ATM #43 at the corner of Market and Main streets when it is presented to the device. This could also be done in affiliation with businesses that thefinancial institution116ahas an alliance with, such as retail merchants, other banks, convenience stores, universities, etc where no ATM devices are located but where cash could be dispensed where point-of-sale checkout stands or merchant customer service offices exist. Such an alliance would allow for single-purpose cards to be used across a wide variety of locations, extending the number of potential cash dispensing locations.

At502, a predefined authorization forcard102 is accessed. The authorization may have been defined by the grantor (e.g. an account holder at thefinancial institution116ahave an account to which thecard102 is linked) by accessing a website, contacting call center, etc. of thefinancial institution116ato prearrange the authorization/configuration ofcard102. The authorization may specify terms, conditions, the amount of funds, a schedule for dispersing funds, etc. to the bearer of thecard102.

At504, the grantor is contacted. Thefinancial institution116amay receive a communication from thecard102 using theinterface240 and thesecure transmission path124 to ascertain an authorization for the bearer to make a withdrawal of funds using thecard102. The grantor may be contacted by thefinancial institution116aby electronic messaging (e.g., an SMS message, e-mail) or telephonically. At506, is determined if an authorization has been received from the grantor. If thefinancial institution116awas unable to contact the grantor, thefinancial institution116amay wait a predetermined amount of time and try again. Thefinancial institution116amay contact the grantor up to a predetermined number of tries. If no authorization has been received after the predetermined number of tries has been attempted, then at506 it is determined that no authorization has been given by the grantor. At506, it may be determined that the grantor has affirmatively denied an authorization tocard102, where the process continues at508 and a reason may be provided by the grantor (e.g., “the work was not completed satisfactorily,” etc.).

At510, the bearer is notified over thesecure transmission path124. The bearer may be notified in thedisplay area210 of thecard102. The reason may scroll or ask the bearer to touch the display to read through additional information across thedisplay area210 and may provide suggestions to the bearer to rectify the reason for the denial. The process then ends at512.

If at506, an authorization was received from the grantor, then at514 the authorization is returned to thecard102. The authorization may be returned to the card over thesecure transmission path124 and enables thecard102 to complete the transaction at the ATM/POS105 at516. The transaction may be completed by dispensing funds to the bearer in the amount determined by the predefined authorization at502. At518, the process ends. Thus, for example, a contractor may be able to use thecard102 to dispense funds in an amount to cover supplies for a job. Later, the contractor may use thecard102 to dispense funds and an amount agreed upon with the customer as payment for a milestone.

Returning toFIG. 4, if it is determined at414 the card type is a youth card, then processing continues at as shown inFIG. 6, which is an exampleoperational flow600 of processing thecard102 as a youth card. At602, a predefined authorization forcard102 is accessed. The authorization may have been defined by the grantor (e.g. an account holder at thefinancial institution116ahave an account to which thecard102 is linked) by accessing a website, contacting call center, etc. of thefinancial institution116ato prearrange the authorization/configuration of thecard102. The authorization may specify terms, conditions, the amount of funds, a schedule for dispersing funds, etc. to a youth bearing thecard102.

At604, a location of the card is ascertained. The location of thecard102 may be ascertained by determining the location the ATM/POS105 that thecard102 has authenticated to in404. The geographic location of the ATM/POS105 may be stored in a database accessible to thefinancial institution116a, thecard102 may be located using GPS or trilateration techniques (over the secure transmission path124), or the location provided by the cardholder.

At606, it is determined if thecard102 is authorized to make a transaction based on the geographic location and the predefined authorization retrieved at602. For example, in some implementations, the youth card may be “geo-fenced” such that it may be operable to make a transaction only within a certain geographic area (e.g. an ATM/POS105 on a school campus). If the card is not authorized to make the transaction, the process ends at608. If the card is authorized to make the transaction, then, at610, the transaction is initiated.

At612, authorization limits are applied to the transaction initiated at610. For example in addition to the geo-fenced area in which thecard102 may be operable, a withdrawal amount may be limited (e.g., limited to $20/day). In addition, thecard102 may be limited such that transfers between accounts is not allowed. Many such limitations are possible in view of the flexible nature of thecard102.

At614, the transaction is completed at the ATM/POS105. Transaction may be completed by dispensing funds to the youth bearing the card a102 and the process ends at616.

Returning toFIG. 4, if it is determined at414 that the card type is a joint account card, then processing continues at as shown inFIG. 7, which is an exampleoperational flow700 of processing thecard102. At702, a predefined authorization for a transaction associated with thecard102 is accessed. The authorization may have been defined by the joint account holders (e.g. an account holder at thefinancial institution116ahave an account to which thecard102 is linked) by accessing a website, contacting call center, etc. of thefinancial institution116ato prearrange the authorization/configuration of thecard102. The authorization may specify terms, conditions, the amount of funds, a schedule for dispersing funds, etc. to a single one of the account holders bearing thecard102.

At704, is determine if an authorization from the joint account holder is required based on the transaction to be completed at702. If, at706, an authorization is not needed, then at the process flow continues to714 where the cardholder completes the transaction at the ATM/POS105 using thecard102. However, if an authorization is needed at706, then at708, the joint account holder is contacted via thesecure transmission path124 and thefinancial institution116a.

At708, is determined if an authorization has been received from the joint account holder. If thefinancial institution116awas unable to contact the joint account holder, thefinancial institution116amay wait a predetermined amount of time and try again. Thefinancial institution116amay contact the joint account holder up to a predetermined number of tries. If no authorization has been received after the predetermined number of tries has been attempted, then at710 it is determined that no authorization has been given by the joint account holder and the process ends at712. At710, it also may be determined at the joint account holder has affirmatively denied an authorization tocard102 and the process ends at712.

If the joint account holder authorizes thetransaction710, the authorization may be communicated over the secure transmission link126 and the transaction is completed at the ATM/POS105 at714. The transaction may be completed by dispensing funds to the joint account holder bearing thecard102, or transferring funds, etc., as specified at702. The process ends at716. It could also be the case that two cards had to be presented together to the same ATM/POS device for the funds to be dispensed. This would provide a high level of security where both parties had to be physically present for the funds to be dispensed.

Returning toFIG. 4, if it is determined at414 that the card type is “other,” then processing continues at as shown inFIG. 8, which is an exampleoperational flow800 of processing thecard102. Theoperational flow800, is provided as a generic overview of processing which may be applied to many different types of transactions in accordance to the configuration of thecard102. Many such non-limiting configurations are provided inFIG. 9 below.

At802, a predefined authorization for a transaction associated with thecard102 is accessed. The authorization may have been defined by an account holder at thefinancial institution116ahaving an account to which thecard102 is linked. The account holder may predefine and configure thecard102 by accessing a website, contacting call center, etc. of thefinancial institution116a. The authorization may specify terms, conditions, the amount of funds, a schedule for dispersing funds, etc. to a single one of the account holders bearing thecard102.

At804, is determined if the transaction to be completed at802 meets the criteria of the authorization. For example, the transaction may involve one or more of the terms, conditions, the amount of funds, schedule, etc. set forth by the account holder. If at806 an authorization is not needed, then at the process flow continues to814 where the cardholder completes the transaction at the ATM/POS105 using thecard102. However, if an authorization is needed at806, then at808 the account holder is contacted via thesecure transmission path124 and thefinancial institution116a.

At808, is determined if an authorization has been received from the account holder. If thefinancial institution116awas unable to contact the account holder, thefinancial institution116amay wait a predetermined amount of time and try again. Thefinancial institution116amay contact the account holder up to a predetermined number of tries. If no authorization has been received after the predetermined number of tries has been attempted, then at810 it is determined that no authorization has been given by the account holder and the process ends at812. At810, it also may be determined that the account holder has affirmatively denied an authorization tocard102 and the process ends at812.

If the account holder authorizes thetransaction810, the transaction is completed at the ATM/POS105 at814. The transaction may be completed by dispensing funds to the person bearing thecard102, or transferring funds, printing tickets, receiving deposits, paying bills, etc. The process ends at816.

FIG. 9 illustrates exemplary transaction types that may be implemented in thesystem100 using the headless ATM/POS105 and thecard102. As illustrated inFIG. 9, such exemplary transaction types may includeconditional transactions902,value story transactions904,co-signature transactions906, alternative locations/interface transactions908, queuedcash transactions910, on-demand transaction912, and preauthorizedtransactions914.

Theconditional transactions902 may include preset transactions based on triggering events. For example, such transactions may include receipt of a retailer coupon, receipt of funds from another source (e.g., rewards funds issued in “store currency” or “financial institution reward currency” that may be used for specific types of purchases, such as in a particular store, or using a particular card102), and certain particular transactions (e.g., a specific transaction at specific locations). “Store currency” or “financial institution reward currency” may include incentives where purchases made at amerchant101 or through a financial institution website may completed using an artificially-valued currency (e.g., $50 charged at a Big Electronics Store POS device yields $60 of Big Electronics Store dollars to make a purchase of electronic equipment from the store. Similarly, a $50 purchase on Bank website results in buying power of, e.g., $75 in Bank dollars to make purchases on the Bank website.). Theconditional transactions902 may also include preset transactions based on dates and/or times. For example, conditional transactions may be cash transactions to a housekeeper or other service provider who utilizes thecard102 to withdraw cash as payment for services rendered. The “store currency” amounts could be stored on the card issuers authorization systems to allow for the “currency” to be retained in the case of a card needing to be replaced due to damage or theft. It would also be possible to exchange one currency for another at a conversion rate negotiated by the currency issuers. For example, $50 Big Electronics Store currency credits could be exchanged for $25 of Popular Restaurant Chain currency credits. This allows for merchants to establish secondary purchasing patterns and value exchanges between themselves.

Value story transactions904 include transactions that take advantage of certain aspects of the flexible nature of thecard102. Areplacement card102 may be provided and activated for use by the customer immediately without waiting for a new ATM card to be processed and delivered. Thecard102 may be acquired from anymerchant101 or financial institution116a-n, and activated for use by the customer. Thecard102 may provide convenience aspects such as an ATM/POS105 where no ATM may presently exist. The customer may go to amerchant101 having an ATM/POS105 and make a withdrawal within thesystem100, whereas conventionally themerchant101 would likely not have a conventional ATM machine on premises. In addition, thecard102 may provide access to emergency funds asdevice institution116amay authorize thecard102 to access emergency funds that would otherwise not be accessible. Social networking aspects are possible, such as merchant feedback about a purchase that may be provided using thecard102. Thecard102 may be used to prevent price gouging. For example, thecard102 may be presented to make a purchase from vendor X. During the transaction, information may be displayed in thedisplay210 that the price is too high, and that vendor Y is selling the same product for 50% less.

Co-signature transactions906 may include transactions by a first account holder that a second account holder authorizes. Suchco-signature transactions906 may be useful to businesses, etc., to authorize withdrawals over a threshold amount, approval of funds transfers to outside accounts, and authorizing payments to vendors to ensure that only legitimate vendors receive funds from the account tied to thecard102.

Alternative locations/interfaces908 are transactions whereby a customer approaches an ATM/POS105 and begins a communication session therewith. The ATM/POS105 may suggest a different ATM/POS105 having different capabilities to complete a requested transaction and/or the ATM/POS105 may reconfigure its interface to a format more appropriate for the customer and order the card a102. For example, a disabled customer may be unable to access an ATM/POS105. Using theRF module220, thecard102 may communicate with thereader106 whereby be ATM/POS105 may suggest an accessible ATM/POS105 in a different location. In some implementations, thecard102 may be provided with capabilities whereby additional functionalities are provided if in contact with a surface computing device. The ATM/POS105 may reconfigure its interface from an RF-based interface to a surface-based interface in order to provide maximum capabilities to the customer carrying thecard102.

Queued cash transactions910 are transactions where a customer is preauthorized to obtain certain features and benefits. Thecard102 may be a vehicle for authentication of the customer at retailers, financial institutions, travel destinations, etc., whereby the customer is provided a higher-level service, passes for events, discounts, or any other benefit that may be bestowed upon the customer in accordance with a particular location.

On-demand transactions912 are transactions that are specific to amerchant101 and/or the ATM/POS105. On-demand transactions912 may only be completed at themerchant101 or the ATM/POS105, and may be requested for security purposes, transferring funds to a specific person, etc. For example, thecard102 may be used as a meal plan card at State University, etc.

Preauthorized transactions914 may include transactions based on origination and/or transaction and security measures. Transactions based on origination may include those initiated by an account holder, initiated by recipient, or set up at a personal computer and/or a mobile device prior to taking place. Transactions based on security measures may be those having a specific time to live duration, having a specific location or boundary of locations, having a pre-shared key arranged in advance or through and out of band notification (e.g., an SMS message, e-mail, etc.), and those paired to specific mobile device associated with a person or persons. In some implementations, a one-time PIN may be created for a specific transaction in order to prevent fraudulent use of thecard102.

Thus, thesystem100 including thecard102 and the ATM/POS105 may have many expandable uses in combination with the above described operational flows, or in related operational flows.

The subject matter described herein may be implemented through the use of a computer system, or other type of device that has some computing mechanism(s).FIG. 10 shows an example computing environment in which example embodiments and aspects may be implemented. The computing system environment is only one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality.

Numerous other general purpose or special purpose computing system environments or configurations may be used. Examples of well known computing systems, environments, and/or configurations that may be suitable for use include, but are not limited to, personal computers (PCs), server computers, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, network PCs, minicomputers, mainframe computers, embedded systems, distributed computing environments that include any of the previously-described systems or devices, and the like.

Computer-executable instructions, such as program modules, being executed by a computer may be used. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform particular tasks or implement particular abstract data types. Distributed computing environments may be used where tasks are performed by remote processing devices that are linked through a communications network or other data transmission medium. In a distributed computing environment, program modules and other data may be located in both local and remote computer storage media including memory storage devices.

With reference toFIG. 10, an example system for implementing aspects described herein includes a computing device, such ascomputing device1000. In its most basic configuration,computing device1000 typically includes at least oneprocessing unit1002 andmemory1004. Depending on the exact configuration and type of computing device,memory1004 may be volatile (such as random access memory (RAM)), non-volatile (such as read-only memory (ROM), flash memory, etc.), or some combination of the two. This most basic configuration is illustrated inFIG. 10 by dashedline1006.

Computing device1000 may have additional features/functionality. For example,computing device1000 may include additional storage (removable and/or non-removable) including, but not limited to, magnetic or optical disks or tape. Such additional storage is illustrated inFIG. 10 byremovable storage1008 and non-removable storage1010.

Computing device1000 typically includes a variety of computer readable media. Computer readable media can be any available media that can be accessed bycomputing device1000 and includes both volatile and non-volatile media, removable and non-removable media. By way of example, and not limitation, computer readable media may comprise computer storage media and communication media.

Computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data.Memory1004,removable storage1008, and non-removable storage1010 are all examples of computer storage media. Computer storage media includes, but is not limited to, RAM, ROM, electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed bycomputing device1000. Any such computer storage media may be part ofcomputing device1000.

Computing device1000 may also contain communications connection(s)1012 that allow the device to communicate with other devices. Communications connection(s)1012 is an example of communication media. Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, radio frequency (RF), infrared and other wireless media. The term computer readable media as used herein includes both storage media and communication media.

Computing device1000 may also have input device(s)1014 such as keyboard, mouse, pen, voice input device, touch input device, etc. Output device(s)1016 such as a display, speakers, printer, etc. may also be included. All these devices are well known in the art and need not be discussed at length here.

It should be understood that the various techniques described herein may be implemented in connection with hardware or software or, where appropriate, with a combination of both. Thus, the methods and apparatus of the presently disclosed subject matter, or certain aspects or portions thereof, may take the form of program code (i.e., instructions) embodied in tangible media, such as floppy diskettes, CD-ROMs, hard drives, or any other machine-readable storage medium wherein, when the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the presently disclosed subject matter. In the case of program code execution on programmable computers, the computing device generally includes a processor, a storage medium readable by the processor (including volatile and non-volatile memory and/or storage elements), at least one input device, and at least one output device. One or more programs may implement or utilize the processes described in connection with the presently disclosed subject matter, e.g., through the use of an API, reusable controls, or the like. Such programs are preferably implemented in a high level procedural or object oriented programming language to communicate with a computer system. However, the program(s) can be implemented in assembly or machine language, if desired. In any case, the language may be a compiled or interpreted language, and combined with hardware implementations.

Although example embodiments may refer to utilizing aspects of the presently disclosed subject matter in the context of one or more stand-alone computer systems, the subject matter is not so limited, but rather may be implemented in connection with any computing environment, such as a network or distributed computing environment. Still further, aspects of the presently disclosed subject matter may be implemented in or across a plurality of processing chips or devices, and storage may similarly be effected across a plurality of devices. Such devices might include personal computers, network servers, and handheld devices, for example.

Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described previously. Rather, the specific features and acts described previously are disclosed as example forms of implementing the claims.

Claims (16)

What is claimed is:

1. A non-transitory computer-readable medium comprising computer-readable instructions for completing a transaction at an automatic teller machine that when executed perform steps, comprising:

establishing a first communication path between a card and the automatic teller machine;

establishing a second communication path between the card and a financial institution;

establishing a third communication path between the automatic teller machine and the financial institution;

authenticating a card with the automatic teller machine without a dedicated display using the first communication path;

receiving transaction information for the transaction from the automatic teller machine using the first communication path, wherein the automatic teller machine is configured to send at least some of the transaction information to the financial institution using the third communication path;

in response to receiving the transaction information, providing the transaction information to the financial institution via the second communication path;

receiving an authorization code for the transaction from the financial institution via the second communication path, wherein the authorization code enables the card to complete the transaction using the first communication path; and

in response to receiving the authorization code from the financial institution, completing the transaction at the automatic teller machine by sending the authorization code over the first communication path after receiving the authorization code;

wherein the transaction is authorized using the second communication path between the card and a financial institution authorizes the transaction based on a predefined authorization and the transaction is authorized using the third communication path between the automatic teller machine and the financial institution based on an account balance.

2. The computer-readable medium ofclaim 1, further comprising:

displaying the transaction information in a display area of the card.

3. The computer-readable medium ofclaim 1, further comprising sending information about the transaction to the automatic teller machine using a touch-sensitive input in a display area of the card.

4. The computer-readable medium ofclaim 1, further comprising creating a short range radio frequency (RF) communications link between the card and the automatic teller machine, the short range radio frequency (RF) communications link communicating data to and through the first communication path.

5. The computer-readable medium ofclaim 1, further comprising creating the second communication path using a network interface of the card.

6. The computer-readable medium ofclaim 5, wherein the second communication path is a secure tunnel over a public network.

7. The computer-readable medium ofclaim 1, wherein characteristics of the card are determined in advance of the transaction by one of a card holder or a card issuer.

8. A system, comprising:

a card including a processor and memory, the card configured to:

establish a first communication path between a card and an automatic teller machine;

establish a second communication path between the card and a financial institution,

receive transaction information for the transaction from the automatic teller machine using the first communication path, wherein the automatic teller machine is configured to send at least some of the transaction information to the financial institution using a third communication path,

provide the transaction information to the financial institution via the second communication path,

receive an authorization code for the transaction from the financial institution via the second communication path, wherein the authorization code enables the card to complete the transaction using the first communication path, and

complete the transaction at the automatic teller machine by sending the authorization code over the first communication path after receiving the authorization code; and

an automatic teller machine without a dedicated display configured to:

establish the third communication path between the automatic teller machine and a financial institution, and

authenticate the card with the automatic teller machine without a dedicated display using the first communication path;

wherein the transaction is authorized using the second communication path between the card and a financial institution authorizes the transaction based on a predefined authorization and the transaction is authorized using the third communication path between the automatic teller machine and the financial institution based on an account balance.

9. The system ofclaim 8, wherein the card has a predetermined authorization as a youth card, and wherein a characteristic of the transaction is one of a geographic location of the transaction, and an amount of the transaction.

10. The system ofclaim 8, wherein the card has a predetermined authorization as a joint account holder card, and wherein a characteristic of the transaction is one of an amount of the transaction, a transfer of funds to another account, and a geographic location.

11. The system ofclaim 8, wherein the card has a predetermined authorization as a bearer card, and wherein a characteristic of the transaction is one of an amount of the transaction, and a frequency of transactions using the card.

12. A method comprising:

establishing a first communication path between a card and an automatic teller machine;

establishing a second communication path between the card and a financial institution;

establishing a third communication path between the automatic teller machine and the financial institution;

authenticating a card with the automatic teller machine without a dedicated display using the first communication path;

receiving transaction information for the transaction from the automatic teller machine using the first communication path, wherein the automatic teller machine is configured to send at least some of the transaction information to the financial institution using the third communication path;

providing the transaction information to the financial institution via the second communication path;

receiving an authorization code for the transaction from the financial institution via the second communication path, wherein the authorization code enables the card to complete the transaction using the first communication path; and

completing the transaction at the automatic teller machine by sending the authorization code over the first communication path after receiving the authorization code;

wherein the transaction is authorized using the second communication path between the card and a financial institution authorizes the transaction based on a predefined authorization and the transaction is authorized using the third communication path between the automatic teller machine and the financial institution based on an account balance.

13. The method ofclaim 12, further comprising instructions for: displaying the transaction information in a display area of the card.

14. The method ofclaim 13, further comprising instructions for creating a short range radio frequency (RF) communications link between the card and the automatic teller machine, the short range radio frequency (RF) communications link communicating data to and from the first communication path.

15. The method ofclaim 12, further comprising instructions for sending information about the transaction to the automatic teller machine using a touch-sensitive input in a display area of the card.

16. The method ofclaim 12, wherein a configuration of the card is determined in advance of the transaction and can be altered by the financial institution over the second communication path.

Images