US11042851B2 - Token based transactions - Google Patents

Token based transactions Download PDF

Info

Publication number
US11042851B2
US11042851B2 US15/537,776 US201515537776A US11042851B2 US 11042851 B2 US11042851 B2 US 11042851B2 US 201515537776 A US201515537776 A US 201515537776A US 11042851 B2 US11042851 B2 US 11042851B2
Authority
US
United States
Prior art keywords
user
server
token
transaction
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active, expires
Application number
US15/537,776
Other versions
US20180047000A1 (en
Inventor
David William KUCHENSKI
Douglas Kurt HARTUNG
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Diebold Nixdorf Inc
Original Assignee
Diebold Nixdorf Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to US201462094320P priority Critical
Application filed by Diebold Nixdorf Inc filed Critical Diebold Nixdorf Inc
Priority to PCT/US2015/067011 priority patent/WO2016100965A1/en
Priority to US15/537,776 priority patent/US11042851B2/en
Assigned to DIEBOLD NIXDORF, INCORPORATED reassignment DIEBOLD NIXDORF, INCORPORATED ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: KUCHENSKI, DAVID WILLIAM, HARTUNG, DOUGLAS KURT
Assigned to DIEBOLD NIXDORF, INCORPORATED reassignment DIEBOLD NIXDORF, INCORPORATED CHANGE OF NAME (SEE DOCUMENT FOR DETAILS). Assignors: DIEBOLD, INCORPORATED
Publication of US20180047000A1 publication Critical patent/US20180047000A1/en
Assigned to JPMORGAN CHASE BANK, N.A., AS ADMINISTRATIVE AGENT reassignment JPMORGAN CHASE BANK, N.A., AS ADMINISTRATIVE AGENT SECURITY INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: DIEBOLD NIXDORF, INCORPORATED (F/K/A DIEBOLD, INCORPORATED), DIEBOLD SELF SERVICE SYSTEMS
Assigned to U.S. BANK TRUSTEES LIMITED reassignment U.S. BANK TRUSTEES LIMITED SECURITY INTEREST (NOTES) Assignors: DIEBOLD NIXDORF, INCORPORATED (F/K/A DIEBOLD, INCORPORATED), DIEBOLD SELF-SERVICE SYSTEMS
Assigned to JPMORGAN CHASE BANK, N.A,, AS ADMINISTRATIVE AGENT reassignment JPMORGAN CHASE BANK, N.A,, AS ADMINISTRATIVE AGENT SECURITY INTEREST (SUPPLEMENT) Assignors: DIEBOLD NIXDORF INCORPORATED (F/K/A DIEBOLD, INCORPORATED), DIEBOLD SELF-SERVICE SYSTEMS
Assigned to U.S. BANK NATIONAL ASSOCIATION, AS COLLATERAL AGENT reassignment U.S. BANK NATIONAL ASSOCIATION, AS COLLATERAL AGENT SECURITY INTEREST (NOTES) Assignors: DIEBOLD NIXDORF, INCORPORATED (F/K/A DIEBOLD, INCORPORATED), DIEBOLD SELF-SERVICE SYSTEMS
Publication of US11042851B2 publication Critical patent/US11042851B2/en
Application granted granted Critical
Active legal-status Critical Current
Adjusted expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/10Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/108Remote banking, e.g. home banking
    • G06Q20/1085Remote banking, e.g. home banking involving automatic teller machines [ATMs]
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/363Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes with the personal data of a user
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/382Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821Electronic credentials
    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07FCOIN-FREED OR LIKE APPARATUS
    • G07F19/00Complete banking systems; Coded card-freed arrangements adapted for dispensing or receiving monies or the like and posting such transactions to existing accounts, e.g. automatic teller machines
    • G07F19/20Automatic teller machines [ATMs]
    • G07F19/203Dispensing operations within ATMs
    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07FCOIN-FREED OR LIKE APPARATUS
    • G07F19/00Complete banking systems; Coded card-freed arrangements adapted for dispensing or receiving monies or the like and posting such transactions to existing accounts, e.g. automatic teller machines
    • G07F19/20Automatic teller machines [ATMs]
    • G07F19/206Software aspects at ATMs

Abstract

In an example embodiment, there is described in here a method for pre-staging transactions that permit a banking customer to either transfer money to a third party or to themselves. In particular embodiments, a token is generated that can be used multiple times by the recipient.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS
This application claims the benefit under 35 U.S.C. § 371 to international application PCT/US2015/67011 filed on 21 Dec. 2015 that claims the benefit of U.S. Provisional Patent Application No. 62/094,320 filed 19 Dec. 2014, the contents of the aforementioned applications are hereby incorporated by reference in their entirety.
BACKGROUND
This relates in general to systems for providing financial services and transactions.
These systems may generally include certain stand-alone machines. For one example, one such known system is the Automated Transaction Machine (ATM).
One category of ATM includes machines capable of conducting a wide variety of traditional banking transactions including acceptance of cash and/or checks for deposit, check cashing, and withdrawals/dispensing of cash, also referred to herein as currency or notes.
Currency/notes, checks and other sheet materials, generally referred to as documents, that are accepted and/or dispensed by an ATM, are typically housed in containers, such as bins or removable cassettes, while documents are stored in the machine. Typically, documents are dispensed from cassettes and presented by an ATM through an aperture or opening in a user interface, typically in the front facing or top of a housing of the ATM. In some ATMs, documents may be accepted through the user interface for deposit and the like and then placed into a cassette.
SUMMARY
This relates more specifically to cardless systems for financial services and transactions.
An embodiment enables a first party to pre-stage a one-time ATM transaction to dispense a fixed amount of currency, wherein the pre-staged transaction can be initiated by a second party by inputting a token, e.g., an alphanumeric character string, into an ATM configured to receive it. Because the second party only needs a token and an ATM configured to receive the token to initiate the pre-staged transaction, this embodiment allows an ATM transaction to be initiated by a party without using a debit card or mobile phone.
In another embodiment, a first party pre-stages a one-time ATM transaction to dispense a variable amount of currency, wherein the pre-staged transaction can be initiated by a second party by inputting a token into an ATM configured to receive it. The second party inputs, into the ATM, the currency amount to be dispensed by the ATM at about the same time as inputting the token into the ATM.
In another embodiment, the token that is generated as a result of a first party pre-staging multiple ATM transactions is a reusable token that can be used repeatedly to initiate a pre-staged transaction. In this embodiment, a first party pre-stages a plurality of ATM transactions to dispense a fixed or variable amount of currency, wherein the pre-staged transactions can be initiated by a second party by entering a reusable token into an ATM configured to receive it. In the variable-currency embodiment, the first party inputs, into the ATM, the currency amount to be dispensed by the ATM at about the same time as entering the reusable token into the ATM.
In another embodiment, a first party pre-stages a fixed-amount or variable-currency ATM transaction, wherein the pre-staged transaction can be initiated by a second party by entering a token into an ATM configured to receive it. In this embodiment, the token's life span is for a fixed amount of time, e.g., 15 minutes or 3 days; alternatively, the token's life span is for a fixed number of uses, e.g., 1 time or 5 times.
In another embodiment, a first party pre-stages a one-time ATM transaction to dispense a variable amount of currency, wherein the pre-staged transaction can be initiated by the first party by entering a token into an ATM configured to receive it. Because the first party only needs a token and an ATM configured to receive the token to initiate the transaction, this embodiment allows an ATM transaction to be initiated by a party without using a debit card or mobile phone.
In another embodiment, a first party pre-stages a one-time ATM transaction to dispense a variable amount of currency, wherein the pre-staged transaction can be initiated by the first party by entering a token into an ATM configured to receive it. The first party inputs, into the ATM, the currency amount to be dispensed by the ATM at about the same time as entering the token into the ATM.
In another embodiment, a first party pre-stages a multiple-use ATM transaction(s) to dispense a variable amount of currency, wherein the pre-staged transaction(s) can be initiated by the first party by entering a reusable token into an ATM configured to receive it. The first party inputs, into the ATM, the currency amount to be dispensed by the ATM at about the same time as entering the reusable token into the ATM.
In another embodiment, a first party pre-stages a fixed-amount or variable-currency ATM transaction, wherein the pre-staged transaction can be initiated by the first party by entering a token into an ATM configured to receive it. In this embodiment, the token's life span is for a fixed amount of time, e.g., 15 minutes or 3 days; alternatively, the token's life span is for a fixed number of uses, e.g., 1 time or 5 times.
This embodiment allows a first party or entity to pay multiple second parties fixed amounts of currency using pre-staged ATM transactions using a plurality of independent financial tokens in place of traditional checks or cash. In this embodiment, a first party pre-stages a plurality of one-time ATM transactions wherein each transaction is pre-staged to dispense a fixed amount of currency, wherein each pre-staged transaction can be initiated by a second party by entering its respective token, e.g., an alphanumeric character string, into an ATM configured to receive it.
This technology allows a first party to set up a repeating pre-staged fixed-amount of currency that can be withdrawn by a second party using a reusable token. Associated with the token is a regular time interval that allows the token redeemer to receive the fixed amount of currency per time, e.g., once per a week like a child's weekly allowance.
An additional embodiment that could be used in any of the above embodiments includes using a biometric reading in place of an alphanumeric token to initiate a pre-staged ATM transaction.
This embodiment enables a user, having a pre-staged variable-amount-of-currency transaction associated with a biometric token, to execute a point-of-sale transaction by using a fingerprint to initiate the transaction and allowing the vendor to populate the currency amount. The currency is then transferred from the account associated with the pre-staged transaction and then directly or indirectly into the vendor's account, where it is deposited.
BRIEF DESCRIPTION OF DRAWINGS
FIG. 1 is a flow diagram showing an embodiment of how a user can create a mobile-wallet account.
FIG. 2 is a flow diagram showing an embodiment of how a user can pre-stage a financial transaction.
FIG. 3 is a flow diagram showing an embodiment of how a financial-transaction token is created by a server and then sent electronically from that server to the currency recipient via the currency recipient's computing device.
FIG. 3a is a flow diagram showing an embodiment of how a user-identification token is generated.
FIG. 4 is a flow diagram showing an embodiment of how a financial-transaction token is processed.
FIG. 5 is a flow diagram showing a universal overview of data transfers throughout the system.
FIG. 6 shows an embodiment wherein the user is requested to enter user-identification data.
FIG. 7 shows an embodiment wherein a financial transaction token is sent from an ATM to a server via data transfer.
FIG. 8 shows an embodiment wherein the user pre-stages and subsequently receives a financial transaction token for the user's own personal use.
FIG. 9 shows an embodiment directed to a user that has pre-staged a plurality of financial transactions, wherein each pre-staged financial transaction respectively has an independent financial transaction token associated with it.
FIG. 10 shows an embodiment for pre-staging, initiating, and completing pre-staged financial transaction 46 between a currency sender and receiver.
DETAILED DESCRIPTION
Methods and system embodiments for pre-staging and initiating a pre-staged financial transaction are described in the context of computer-readable logic executed by one or more general-purpose computers. For example, in a portion of an embodiment, computer readable logic is stored on a server computer system and accessed by a client computer via a communications link or a network, such as an intranet, Internet, or another computer network. And because the basic structures and functions related to computer-readable routines and corresponding implementations are known, they have not been shown or described in detail here to avoid unnecessarily obscuring the described embodiments.
Details are set forth in the following description and in FIGS. 1-10 to provide a thorough understanding of various embodiments of the invention. Those of ordinary skill in the art will understand, however, that the invention may have additional embodiments which may be practiced without several of the details described below. In other instances, those of ordinary skill in the art will appreciate that the methods and systems described herein can include additional details without departing from the spirit or scope of the disclosed embodiment. Additionally, some known structures and systems associated with automated teller machines (ATMs), mobile devices, and associated computer networks have not been shown or described in detail below to avoid unnecessarily obscuring the description of the invention's various embodiments.
In the following figures, identical reference numbers identify identical or at least generally similar elements. In the flow diagrams, a rectangle represents a process, task, action, or operation; a diamond presents a question; and a parallelogram shows input or output.
FIG. 1 is a flow diagram showing an embodiment of how a user can create a mobile-wallet account by using a computing device to input a plurality of required data sets. A mobile-wallet account is a collection of one or more electronic data sets that include bank-account data sets and personal-information data sets. In block 100, the user is prompted to create mobile-wallet account by using computing device 4 (FIG. 9) to input a plurality of data sets that include 1) personal bank-account data set and 2) personal-information data set, shown respectively in blocks 100A and 100B. In decision block 102, the user decides whether to input the prompted data sets. Block 104 shows the user inputting data sets by populating the data fields prompted to the user. In response to populating the prompted data fields, block 106 shows computing device 4 (FIG. 9) sending mobile-wallet account to server 16 (FIG. 9) that then forwards mobile-wallet account to one or more servers 17 (FIG. 9) for hosting. In an embodiment, computing device 4 sends mobile-wallet account to server 16 that executes an algorithm on at least a portion of mobile-wallet account and thereby determines the appropriate host-server destination for mobile-wallet account. Mobile-wallet account is then forwarded to the appropriate host server for hosting. In an embodiment, server 16 may have a plurality of host servers 17 to select from, wherein the plurality of host servers 17 are specific as to the type of mobile-wallet account that they each respectively host. For example, servers 17 may respectively host different types of bank-specific accounts or bank-specific data sets, and mobile-wallet account including information about a specific bank is forwarded by server 16 to a dedicated host server 17 for that specific bank or bank data. As an illustrative example, mobile-wallet account relating to ABC bank is sent to a host server 17 dedicated to hosting ABC bank data; mobile-wallet account relating to DEF bank is sent to a host server 17 dedicated to hosting DEF bank data; mobile-wallet account relating to GHI bank is sent to a host server 17 dedicated to hosting GHI bank data; and so on.
FIG. 2 is a flow diagram showing an embodiment of how a user can pre-stage a financial transaction by creating a financial-transaction data set using computing device 4 (FIG. 9) to input a plurality of required data subsets. A financial-transaction data set is a collection of one or more data subsets that an ATM commonly requires to execute an ATM transaction. A financial-transaction data set can include i) a currency-amount data subset including the currency amount of pre-staged financial transaction, ii) a user-identification data subset that identifies the user; the user-identification data subset may include an alphanumeric user-identifying character string such as a PIN number or a biometric signature, and iii) a currency-recipient-identifying data subset that includes data associated with contacting the designated currency recipient, e.g., currency recipient's mobile-phone number or email address.
Block 200 shows that to create pre-staged financial transaction, the user is prompted create financial-transaction data set by using computing device 4 (FIG. 9) to input a plurality of financial-transaction data subsets respectively shown in blocks 200A, 200B, and 200C; the plurality of data subsets include: i) a currency-amount data subset that includes the currency amount of pre-staged financial transaction, ii) a user-identification data subset that identifies the user; a user-identification data subset may include an alphanumeric user-identifying character string such as a PIN number or a biometric signature, and iii) a currency-recipient-identifying data subset that includes data associated with contacting currency recipient, e.g., a mobile-phone number or an email address of currency recipient. In decision block 202, the user decides whether to input the prompted data subsets. Block 204 shows the user inputting data subsets by populating the data fields prompted to the user. In response to populating the prompted data fields, block 206 shows computing device 4 electronically sending financial-transaction data set to server 16 (FIG. 9) for hosting. In an embodiment, server 16 sends a portion of financial-transaction data set to server 18 (FIG. 9) for hosting.
FIG. 3 is a flow diagram showing an embodiment of how a financial-transaction token is created by a server and then sent electronically from that server to the currency recipient via the currency recipient's computing device. Block 300 shows that server 16 (FIG. 9) receives financial-transaction data set from computing device 4 (FIG. 9). In block 302, server 16 uses computer-readable logic to generate financial-transaction token e.g., an alphanumeric character string that identifies and is associated with financial-transaction data set. In block 304, a financial-transaction token is sent from server 16 (FIG. 9) to the currency recipient's computing device. The financial-transaction token is used at a later time by the currency recipient to help initiate a pre-staged financial transaction; currency recipient initiates the pre-staged financial transaction by inputting the financial-transaction token into an ATM configured to receive tokens. The financial-transaction token figuratively acts as a key that enables ATM 50 to access and receive portions of both a financial-transaction data set and a mobile-wallet account.
FIG. 3a is a flow diagram showing an embodiment of how an additional and different type of token called a user-identification token is generated by server 16 in response to server 16 receiving a user-identification data subset. The user-identification token, e.g., an alphanumeric character string, is used later in the process to identify and receive a user-identification data subset or a decrypted version of the user-identification data subset from a remote server. In block 3000, user uses computing device 4 (FIG. 9) to input a user-identification number and thereby create a user-identification data subset. In an embodiment, the user-identification data subset replicates a traditional personal-identification-number signature created as a function of personal-identification-number keystrokes entered by the user. In another embodiment, the user-identification data subset includes vertical and horizontal PIN pad or touch-screen coordinates resulting from a user's keystrokes or touches on a PIN pad or touch-screen display while entering a personal identification number. In response to a PIN pad or touch screen being used, the user-identification data subset includes vertical and horizontal coordinates of the PIN-pad or touch-screen numbers selected by the user. The vertical and horizontal coordinates of the PIN-pad or touch-screen numbers selected by the user can only be decrypted into the actual personal identification number by using a decryption key hosted on server 18 (FIG. 9). Block 3010 shows the user-identification data subset being received from user's computing device 4. Block 3020 shows the server generating a user-identification token by using computer readable logic. The user-identification token is used later in the process to retrieve the decrypted-user-identification data subset. In block 3030, both the user-identification token and user-identification data subset are sent from server 16 (FIG. 9) to server 18 for hosting and decryption. A decrypted user-identification data subset is released from the host server only to a client computer (such as an EFT network) that provides the user-identification token.
FIG. 4 is a flow diagram showing an embodiment of how i) the cash recipient receives and uses a financial-transaction token to initiate a pre-staged financial transaction at ATM 50 that is configured to a receive token, and ii) how upon authenticating a token received from ATM 50, server 16 (FIG. 9) retrieves and forwards portions of a mobile-wallet account; portions of a financial transaction dataset; and a user-identification token to ATM 50. Upon receiving: the mobile-wallet account; portions of the financial transaction dataset; and the user-identification token, ATM 50 generates an ATM transmission message using those three items and forwards both the ATM transmission message and the user-identification token to ATM driver 60. ATM driver 60 directs the ATM transmission message to the appropriate EFT network 58.
Block 400 shows that the computer readable logic hosted on server 16 (FIG. 9) uses a currency-recipient-identifying data subset 28 to generate and send communication to the currency recipient's computing device 77, e.g., via text or email. The communication is received by computing device 77. The communication includes: i) a financial-transaction token; ii) the currency amount from the currency-amount data sub set; and iii) the identity of the user that created the pre-staged financial transaction. Block 402 shows that in response to receiving the communication, the currency recipient then identifies ATM 50 (FIG. 9) that is configured to receive a financial-transaction token. The currency recipient initiates a pre-staged financial transaction by inputting a financial-transaction token into ATM 50 (FIG. 9) using a data-entry pad or touch-screen display. Blocks 404, 406, and 408 respectively show that in response to inputting a financial-transaction token from a currency recipient, ATM 50 (FIG. 9) electronically submits the financial-transaction token to server 16 (FIG. 9). In response to this electronic submission, server 16 (FIG. 9) authenticates the token using computer-readable logic, and in response to authentication, server 16 (FIG. 9) retrieves and sends portions of the mobile-wallet account, portions of the financial transaction dataset, and the user-identification token associated with the financial-transaction token to ATM 50 (FIG. 9).
In an embodiment not shown in FIG. 4, in response to a financial-transaction token being input into ATM 50 (FIG. 9) by the currency recipient, ATM 50 (FIG. 9) performs a cash-recipient verification step that generates and sends a secondary communication, e.g., via email or text, to the currency recipient in order to authenticate the currency recipient's identity before ATM 50 (FIG. 9) continues with executing the pre-staged financial transaction.
Block 410 shows that in response to receiving portions of a mobile-wallet account, portions of a financial-transaction dataset, and a user-identification token associated with a financial-transaction token from server 16 (FIG. 9), ATM 50 (FIG. 9) generates an ATM transmission message by executing an algorithm on portions of mobile-wallet account, portions of a financial-transaction dataset, and a user-identification token. Upon generating an ATM transmission message, ATM 50 (FIG. 9) then continues to execute the pre-staged financial transaction. ATM 50 (FIG. 9) does this by sending an ATM transmission message in combination with a unique transaction identifier to ATM driver 60 (FIG. 9). In block 412, ATM driver 60 forwards the ATM transmission message and unique transaction identifier to the appropriate electronic-funds-transfer (EFT) network 58. EFT network 58 receives ATM transmission message 56 and a unique transaction identifier from ATM driver 60. EFT network 58 (FIG. 9) forwards the user-identification token (that is included in ATM transmission message 56) to server 18 (FIG. 9). In response to server 18 (FIG. 9) receiving the user-identification token, server 18 authenticates the user-identification token and then sends the decrypted user-identification data subset back to EFT network 58 (FIG. 9).
In response to receiving the decrypted user-identification data subset from server 18 (FIG. 9), EFT network 58 (FIG. 9) then forwards both the decrypted user-identification data subset and portions of an ATM transmission message to bank server 72 (of the proper banking institution) for processing. The decrypted user-identification data subset and portions of the ATM transmission message sent to bank server 72 (from EFT network 58) is formatted in harmony with the normal protocol of known ATM currency-dispensing-transaction information needed by bank server 72 for processing.
The banking institution, via bank server 72 (FIG. 9), either accepts or rejects the transaction, and if accepted, bank server 72 (FIG. 9) sends an acceptance message to ATM 50 (FIG. 9). In response, ATM 50 (FIG. 9) dispenses a currency amount a to currency recipient via known electronic processing methods. But if the banking institution, via bank server 72, rejects the transaction, bank server 72 sends a rejection message to ATM 50. In response, ATM 50 does not disperse currency to the intended currency recipient and the transaction ends.
FIG. 5 is a flow diagram showing a universal overview of data transfers throughout the system. Data transfer 501 shows the mobile-wallet account being sent from computing device 4 to server 16. Data transfer 502 shows the mobile-wallet account being sent from server 16 to server 17 for hosting. Data transfer 503 shows the financial transaction data set being sent from computing device 4 to server 16. Data transfer 504 shows a portion of the financial transaction data set being sent from server 16 to server 18 for hosting and decryption. In an embodiment, the portion of the financial-transaction data set that is sent from server 16 to server 18 includes a user-identification data subset. Data transfer 505 shows i) a financial-transaction token, ii) currency amount from a currency-amount of data subset, and iii) the identity of the user that created the pre-staged financial transaction, being sent from server 16 to computing device 77. Data transfer 506 shows cash recipient physically (represented by the dashed line) inputting a financial transaction token into ATM 50; cash recipient receives the financial transaction token from the display of computing device 77. Data transfer 507 shows the financial-transaction token being sent from ATM 50 to server 16. Data transfer 508 shows server 16 requesting mobile-wallet account from server 17. Data transfer 509 shows server 17 sending mobile wallet account to server 16. Data transfer 510 shows server 16 sending a mobile-wallet account, portions of the financial-transaction data set, and the user-identification token to ATM 50. Data transfer 511 shows ATM 50 sending the ATM transmission message to ATM driver 60. Data transfer 512 shows ATM transmission message 56 being sent from ATM driver 60 to EFT network 58. Data transfer 513 shows EFT network 58 sending the user-identification token to server 18. Data transfer 514 shows server 18 sending the decrypted user-identification data subset to EFT network 58. Data transfer 515 shows EFT network 58 sending the decrypted user-identification data subset and portions of the ATM transmission message to bank server 72. Data transfers 516, 517, and 518 show bank server 72 sending a transaction acceptance or rejection message to ATM 50. In an alternate embodiment, bank server 72 sends a direct transaction acceptance or rejection message to ATM 50 via data transfer 519.
FIG. 6 shows an embodiment wherein instead of entering a user-identification data subset (while creating a financial-transaction data set) at the time of pre-staging a financial transaction, the user is requested to enter the user-identification data subset, e.g., the user's PIN (using the user's computing device 4), in response to the recipient initiating a pre-staged financial transaction by entering a financial-transaction token into ATM 50 configured to receive it. In response to recipient initiating a pre-staged financial transaction by a entering financial-transaction token into ATM 50, a request is directly or indirectly sent from ATM 50 to the user's computing device 4 (requesting that the user input and submit the user-identification data subset) via data transfer PIN request 507 and 520. In response to the request, and upon inputting and the submitting user-identification data subset, the user-identification data subset is sent to ATM 50 via PIN data transfer 521 and 510. By inputting and submitting the user-identification data subset in response to the request, the user is confirming that pre-staged transaction will proceed.
FIG. 7 shows an embodiment wherein instead of a financial transaction token being sent from EFT network 58 to server 18 via data transfer 513, the financial transaction token is sent from ATM 50 to server 18 via data transfer 522. In response to receiving the financial transaction token, server 18 sends decrypted user identification data subset 64 to ATM 50 via data transfer 523. In this embodiment, the financial transaction token is sent from ATM 50 to server 18 in response to ATM 50 receiving the mobile-wallet account, portions of the financial-transaction data set, and the user-identification token via data transfer 510. And because ATM 50 requests and receives decrypted user identification data subset 64 via data transfers 522 and 523 respectively, data transfers 522 and 523 obviate the need for data transfers 513 and 514 (between EFT network 58 and server 18).
FIG. 8 shows an embodiment wherein the user pre-stages and subsequently receives a financial transaction token for the user's own personal use. In this embodiment, the financial transaction token is sent from server 16 to the user's mobile phone 4 via data transfer 524. The user may then initiate a pre-staged financial transaction by physically going to ATM 50 and inputting the financial transaction token into ATM 50.
FIG. 9 shows an embodiment directed to a user that has pre-staged a plurality of financial transactions, wherein each pre-staged financial transaction respectively has an independent financial transaction token associated with it. As shown in FIG. 9, each intended recipient of the plurality of pre-staged financial transactions receives their respective financial transaction token via their mobile phone 77. As a non-limiting example, FIG. 9 shows three separate mobile phones 77 respectively receiving an independent financial transaction token via data transfers 505A, 505B, and 505C. As shown in elements 506A, 506B, and 506C—each of the mobile phone owners/recipients then goes to ATM 50 and inputs their respective financial transaction token 32 into ATM 50 to initiate their respective pre-staged financial transaction. Each respective pre-staged financial transaction is initiated as each of the respective tokens is input into ATM 50. As a non-limiting example, this embodiment could be used to handle payroll using a plurality of financial transaction tokens in place of paper checks or cash.
FIG. 10 shows an embodiment for pre-staging, initiating, and completing a pre-staged financial transaction between a currency sender and receiver. FIG. 10 qualifies the user as the “sender”; and the currency recipient is qualified as the “receiver.” The temporal sequence of events shown in FIG. 10 begins with a pre-staging financial transaction and ends with completion of the transaction. FIG. 10 should be interpreted with the understanding that the beginning of the embodiment is shown at the top of FIG. 10 and the end of the embodiment is shown at the bottom of FIG. 10. Furthermore, the beginning stem of an arrow shows the origin of an act, event, or data transfer, and the end point of the arrowhead shows the destination or receiving device of the particular act, event, or data transfer. As a non-limiting example, the first event shown in FIG. 10 is represented by the upper-most arrow at the top of FIG. 10 and shows an initial action taken by the sender and described as, “Insert ATM Card & PIN, enter sender's mobile #, select P2P send”; this action is shown by the arrow as being taken by the Sender at the Financial Institution ATM (FI ATM). Arrows consecutively beneath this first arrow respectively represent the next and consecutive acts, events, or data transfers in the embodiment. The end of the embodiment is shown by the arrow at the bottom of FIG. 10 and shows a message or data transfer being sent from the FI ATM to the ATM Driver, wherein the message is “Dispense successful”.
While principals and modes of operation have been explained and illustrated with regard to particular embodiments, it must be understood, however, that this may be practiced otherwise than as specifically explained and illustrated without departing from its spirit or scope.

Claims (8)

What is claimed is:
1. A method, comprising:
generating, by a first server, a user-identification token;
forwarding, by the first server, the user-identification token and user-identification data subset to a third server;
receiving, by the first server, from a computing device, associated with a user initiating a transaction, data representative of a financial transaction, the data representative of a financial transaction comprises data representative of the user initiating the financial transaction, data representative of an amount of the transaction, and data representative of a recipient of the financial transaction, the data representative of the recipient including contact data for a user device associated with the recipient;
forwarding, by the first server, a portion of the data representative of the financial transaction to the third server, where the portion of the data representative of the financial transaction comprises data representative of the user initiating the transaction to the third server;
generating, by the first server, a financial transaction token associated with the portion of the data representative of the financial transaction;
sending, by the first server, a copy of the financial transaction token to the user device associated with the recipient;
receiving, by the first server, from an automated banking machine, data representative of the financial transaction token that was sent to the user device associated with the recipient;
requesting, by the first server, mobile wallet data from a second server;
receiving, by the first server, the mobile wallet data from the second server;
sending, by the first server, the mobile wallet data the portion of the data representative of the financial transaction, and the user-identification token to the automated banking machine;
sending, by the automated banking machine, an automated teller machine transmission message and the user-identification token to an automated teller machine driver, the automated teller machine transmission message comprises the mobile wallet data, the portion of the data representative of the financial transaction, and the user-identification token;
forwarding the automated teller machine transmission message and the user-identification token by the automated teller machine driver to the electronic funds transfer network;
sending, by the electronic funds transfer network, the user-identification token to the third server;
sending, by the third server, a user-identification data to the electronic funds transfer network;
sending, by the electronic funds network, to a fourth server, the fourth server associated with a financial institution, the user-identification data and portions of the automated teller machine transmission message;
sending, by the fourth server, a transaction acceptance message to the automated banking machine; and
dispensing the amount of currency by the automated banking machine.
2. The method according to claim 1, wherein the user identification data comprises a personal identification number (PIN) associated with the user initiating the transaction.
3. The method according to claim 1, wherein the amount of the transaction is a fixed amount.
4. The method according to claim 1, wherein the financial transaction token is a reusable token for a plurality of withdrawals of variable amounts.
5. The method according to claim 1, wherein the financial transaction token is a reusable token for withdrawals of a fixed amount for a plurality of time periods.
6. The method according to claim 1, wherein the financial transaction token is associated with a fixed number of transactions.
7. The method according to claim 1, wherein the financial transaction token is an alphanumeric character string.
8. The method according to claim 1, wherein the contact data for the user device associated with the recipient is a phone number.
US15/537,776 2014-12-19 2015-12-21 Token based transactions Active 2037-03-26 US11042851B2 (en)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US201462094320P true 2014-12-19 2014-12-19
PCT/US2015/067011 WO2016100965A1 (en) 2014-12-19 2015-12-21 Pre-staged atm transactions
US15/537,776 US11042851B2 (en) 2014-12-19 2015-12-21 Token based transactions

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US15/537,776 US11042851B2 (en) 2014-12-19 2015-12-21 Token based transactions

Publications (2)

Publication Number Publication Date
US20180047000A1 US20180047000A1 (en) 2018-02-15
US11042851B2 true US11042851B2 (en) 2021-06-22

Family

ID=55168413

Family Applications (1)

Application Number Title Priority Date Filing Date
US15/537,776 Active 2037-03-26 US11042851B2 (en) 2014-12-19 2015-12-21 Token based transactions

Country Status (5)

Country Link
US (1) US11042851B2 (en)
EP (1) EP3234932A1 (en)
CN (1) CN107408246A (en)
BR (1) BR112017013223A2 (en)
WO (1) WO2016100965A1 (en)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180165663A1 (en) * 2016-12-12 2018-06-14 Citibank, N.A. Systems and methods for pre-staging atm transactions
US11037114B2 (en) 2018-03-22 2021-06-15 Diebold Nixdorf, Incorporated System and method for financial transactions
US10965662B2 (en) 2018-06-27 2021-03-30 Bank Of America Corporation Method and system for data communication and frictionless authentication
US11057377B2 (en) * 2018-08-26 2021-07-06 Ncr Corporation Transaction authentication
US11037127B2 (en) 2019-05-07 2021-06-15 Capital One Services, Llc Symbols to indicate which ATM to use
EP3812991A1 (en) 2019-10-21 2021-04-28 Joachim Walser Cryptocurrency cash gateway

Citations (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5386104A (en) * 1993-11-08 1995-01-31 Ncr Corporation System and method for detecting user fraud in automated teller machine transactions
WO2002095696A1 (en) 2001-05-23 2002-11-28 Yong Hock Lawrence Sim Currency conversion
US20030069856A1 (en) * 2001-10-10 2003-04-10 First Data Corporation Method and system for performing money transfer transactions
US7416112B2 (en) 2006-04-05 2008-08-26 Diebold Self-Service Systems Division Of Diebold, Incorporated Automated banking machine system and method
US20080203150A1 (en) 2006-04-07 2008-08-28 John Royce-Winston System and method for creating digital currency
US20120160912A1 (en) * 2010-12-23 2012-06-28 Kevin Laracey Mobile phone atm processing methods and systems
US8423462B1 (en) * 2009-05-01 2013-04-16 Amazon Technologies, Inc. Real-time mobile wallet server
US20130238497A1 (en) * 2012-03-08 2013-09-12 Citicorp Development Center, Inc. Methods and Systems for Performing a Financial Transaction Using a Mobile Communication Device
EP2704116A2 (en) 2012-08-27 2014-03-05 NCR Corporation Transaction flow
US20140095383A1 (en) * 2011-10-20 2014-04-03 Bindu Rama Rao System for anonymous funds transfer using adhoc staging accounts
US20140172703A1 (en) 2012-12-19 2014-06-19 Ncr Corporation Customer verification
US9141956B2 (en) * 2006-11-13 2015-09-22 Ncr Corporation Using biometric tokens to pre-stage and complete transactions

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU2003219276A1 (en) * 2002-04-03 2003-10-13 Swivel Secure Limited System and method for secure credit and debit card transactions
US8639602B2 (en) * 2010-04-27 2014-01-28 Bindu Rama Rao System for agent assisted mobile funds transfer and mobile banking
US20140089188A1 (en) * 2011-10-20 2014-03-27 Bindu Rama Rao System for funds transfer using source atm and delivering atm
CN103136699A (en) * 2011-12-02 2013-06-05 张艺 Money withdrawing and transaction method without bank card
US8915426B2 (en) * 2012-07-11 2014-12-23 Ncr Corporation Media dispensing self-service terminal
CN103778728A (en) * 2014-02-23 2014-05-07 王恩惠 Method and system for realizing transaction without bank card through automatic teller machine

Patent Citations (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5386104A (en) * 1993-11-08 1995-01-31 Ncr Corporation System and method for detecting user fraud in automated teller machine transactions
WO2002095696A1 (en) 2001-05-23 2002-11-28 Yong Hock Lawrence Sim Currency conversion
US20030069856A1 (en) * 2001-10-10 2003-04-10 First Data Corporation Method and system for performing money transfer transactions
US20120223134A1 (en) 2002-11-26 2012-09-06 Diebold Self-Service Systems Division Of Diebold, Incorporated Banking Machine Controlled Responsive to Data Read from Data Bearing Records
US7416112B2 (en) 2006-04-05 2008-08-26 Diebold Self-Service Systems Division Of Diebold, Incorporated Automated banking machine system and method
US20080203150A1 (en) 2006-04-07 2008-08-28 John Royce-Winston System and method for creating digital currency
US9141956B2 (en) * 2006-11-13 2015-09-22 Ncr Corporation Using biometric tokens to pre-stage and complete transactions
US8423462B1 (en) * 2009-05-01 2013-04-16 Amazon Technologies, Inc. Real-time mobile wallet server
US20120160912A1 (en) * 2010-12-23 2012-06-28 Kevin Laracey Mobile phone atm processing methods and systems
US20140095383A1 (en) * 2011-10-20 2014-04-03 Bindu Rama Rao System for anonymous funds transfer using adhoc staging accounts
US20130238497A1 (en) * 2012-03-08 2013-09-12 Citicorp Development Center, Inc. Methods and Systems for Performing a Financial Transaction Using a Mobile Communication Device
EP2704116A2 (en) 2012-08-27 2014-03-05 NCR Corporation Transaction flow
US20140172703A1 (en) 2012-12-19 2014-06-19 Ncr Corporation Customer verification

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
International Search Report and Written Opinion dated May 4, 2016 for corresponding International Patent Application No. PCT/US2015/067011.
International Search Report for corresponding PCT application; 16 pages.

Also Published As

Publication number Publication date
CN107408246A (en) 2017-11-28
WO2016100965A1 (en) 2016-06-23
US20180047000A1 (en) 2018-02-15
BR112017013223A2 (en) 2018-02-06
EP3234932A1 (en) 2017-10-25

Similar Documents

Publication Publication Date Title
US11042851B2 (en) Token based transactions
US20180012234A1 (en) Method for authenticating financial instruments and financial transaction requests
US20180330342A1 (en) Digital asset account management
JP2011516980A (en) Transaction server configured to authorize payment transactions using a mobile phone device
KR101977131B1 (en) Customized financial management system using of a sub-certification
US10956906B2 (en) Secure account creation
US20190287095A1 (en) Digital asset distribution by transaction device
EP3391619A1 (en) Browser extension for limited-use secure token payment
WO2017057770A1 (en) Information processing device and information processing method
US11023867B2 (en) Push payment scheme through a trusted third party
EP2613287B1 (en) Computer system and method for initiating payments based on cheques
US20140236819A1 (en) Payment System For Issuing And Depositing Paperless Checks
US20190266600A1 (en) System and method for monetary transaction
US20210176340A1 (en) Graphical User Interface and Operator Console Management System for Distributed Terminal Network
US20140101025A1 (en) Accounts with multiple pre-authorization levels
US20200387876A1 (en) Immediate release of resource for data transfer
WO2019130809A1 (en) Transaction management system, transaction management device, transaction management method, and transaction management program
US11037110B1 (en) Math based currency point of sale systems and methods
CN110069761A (en) A kind of bank self-aid apparatus fills out single method and device
CN112823368A (en) Tokenized contactless transactions via cloud biometric identification and authentication
KR101021604B1 (en) Computing data managing system of an import letter of credit over bank network
KR20120040978A (en) User authentication apparatus for cdatm

Legal Events

Date Code Title Description
AS Assignment

Owner name: DIEBOLD NIXDORF, INCORPORATED, OHIO

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:KUCHENSKI, DAVID WILLIAM;HARTUNG, DOUGLAS KURT;SIGNING DATES FROM 20170620 TO 20170717;REEL/FRAME:043027/0817

AS Assignment

Owner name: DIEBOLD NIXDORF, INCORPORATED, OHIO

Free format text: CHANGE OF NAME;ASSIGNOR:DIEBOLD, INCORPORATED;REEL/FRAME:044048/0417

Effective date: 20161209

STPP Information on status: patent application and granting procedure in general

Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION

AS Assignment

Owner name: JPMORGAN CHASE BANK, N.A., AS ADMINISTRATIVE AGENT, ILLINOIS

Free format text: SECURITY INTEREST;ASSIGNORS:DIEBOLD NIXDORF, INCORPORATED (F/K/A DIEBOLD, INCORPORATED);DIEBOLD SELF SERVICE SYSTEMS;REEL/FRAME:047878/0974

Effective date: 20181024

Owner name: JPMORGAN CHASE BANK, N.A., AS ADMINISTRATIVE AGENT

Free format text: SECURITY INTEREST;ASSIGNORS:DIEBOLD NIXDORF, INCORPORATED (F/K/A DIEBOLD, INCORPORATED);DIEBOLD SELF SERVICE SYSTEMS;REEL/FRAME:047878/0974

Effective date: 20181024

STPP Information on status: patent application and granting procedure in general

Free format text: NON FINAL ACTION MAILED

STPP Information on status: patent application and granting procedure in general

Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER

STPP Information on status: patent application and granting procedure in general

Free format text: NON FINAL ACTION MAILED

STPP Information on status: patent application and granting procedure in general

Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER

AS Assignment

Owner name: JPMORGAN CHASE BANK, N.A,, AS ADMINISTRATIVE AGENT, ILLINOIS

Free format text: SECURITY INTEREST (SUPPLEMENT);ASSIGNORS:DIEBOLD NIXDORF INCORPORATED (F/K/A DIEBOLD, INCORPORATED);DIEBOLD SELF-SERVICE SYSTEMS;REEL/FRAME:053268/0908

Effective date: 20200720

Owner name: U.S. BANK TRUSTEES LIMITED, UNITED KINGDOM

Free format text: SECURITY INTEREST (NOTES);ASSIGNORS:DIEBOLD NIXDORF, INCORPORATED (F/K/A DIEBOLD, INCORPORATED);DIEBOLD SELF-SERVICE SYSTEMS;REEL/FRAME:053271/0067

Effective date: 20200720

Owner name: U.S. BANK NATIONAL ASSOCIATION, AS COLLATERAL AGENT, OHIO

Free format text: SECURITY INTEREST (NOTES);ASSIGNORS:DIEBOLD NIXDORF, INCORPORATED (F/K/A DIEBOLD, INCORPORATED);DIEBOLD SELF-SERVICE SYSTEMS;REEL/FRAME:053270/0783

Effective date: 20200720

STPP Information on status: patent application and granting procedure in general

Free format text: NON FINAL ACTION MAILED

STCB Information on status: application discontinuation

Free format text: FINAL REJECTION MAILED

STPP Information on status: patent application and granting procedure in general

Free format text: NOTICE OF ALLOWANCE MAILED -- APPLICATION RECEIVED IN OFFICE OF PUBLICATIONS

STPP Information on status: patent application and granting procedure in general

Free format text: AWAITING TC RESP., ISSUE FEE NOT PAID

STPP Information on status: patent application and granting procedure in general

Free format text: NOTICE OF ALLOWANCE MAILED -- APPLICATION RECEIVED IN OFFICE OF PUBLICATIONS

STPP Information on status: patent application and granting procedure in general

Free format text: PUBLICATIONS -- ISSUE FEE PAYMENT RECEIVED

STPP Information on status: patent application and granting procedure in general

Free format text: PUBLICATIONS -- ISSUE FEE PAYMENT VERIFIED

STCF Information on status: patent grant

Free format text: PATENTED CASE