US20140006196A1 - Method and system for dynamic funding - Google Patents
Method and system for dynamic funding Download PDFInfo
- Publication number
- US20140006196A1 US20140006196A1 US14/013,819 US201314013819A US2014006196A1 US 20140006196 A1 US20140006196 A1 US 20140006196A1 US 201314013819 A US201314013819 A US 201314013819A US 2014006196 A1 US2014006196 A1 US 2014006196A1
- Authority
- US
- United States
- Prior art keywords
- mobile device
- single use
- payment account
- block
- user
- 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.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/401—Transaction verification
- G06Q20/4014—Identity check for transactions
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/20—Point-of-sale [POS] network systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
- G06Q20/322—Aspects of commerce using mobile devices [M-devices]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
- G06Q20/325—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
- G06Q20/327—Short range or proximity payments by means of M-devices
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
- G06Q20/327—Short range or proximity payments by means of M-devices
- G06Q20/3274—Short range or proximity payments by means of M-devices using a pictured code, e.g. barcode or QR-code, being displayed on the M-device
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/385—Payment protocols; Details thereof using an alias or single-use codes
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/401—Transaction verification
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q2220/00—Business processing using cryptography
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
Definitions
- a payment card (e.g., a credit card) may be used to authenticate payment from a payment account.
- a cryptographic key may be included in a magnetic stripe of the payment card and used at a point of sale to identify whether the card is a legitimate card.
- the information in the magnetic stripe may be subject to unauthorized capture, thereby compromising both the payment account and the card.
- a nefarious user that has made that unauthorized capture may be able to withdraw funds from the payment account using the card one or more times before the unauthorized activity is detected.
- FIG. 1 is a block diagram of a system, according to an example embodiment
- FIG. 2 is a block diagram of an example authentication provider that may be deployed within the system of FIG. 1 according to an example embodiment
- FIG. 3 is a block diagram of an example mobile device that may be deployed within the system of FIG. 1 according to an example embodiment
- FIG. 4 is a block diagram of an example point of sale device that may be deployed within the system of FIG. 1 according to an example embodiment
- FIG. 5 is a flowchart illustrating a method for funding authentication according to an example embodiment
- FIGS. 6-8 are flowcharts illustrating a method for processing payment authorization for the payment account according to an example embodiment
- FIG. 9 is a flowchart illustrating a method for funding authentication according to an example embodiment
- FIG. 10 is a flowchart illustrating a method for processing payment authorization according to an example embodiment
- FIG. 11 is a flowchart illustrating a method for utilizing a mobile device according to an example embodiment
- FIG. 12 is a flowchart illustrating a method for utilizing a point of sale device according to an example embodiment
- FIG. 13 is a network diagram depicting a network system, according to one embodiment, having a client server architecture configured for exchanging data over a network;
- FIG. 14 is a block diagram illustrating an example embodiment of multiple network and marketplace applications, which are provided as part of the network-based marketplace.
- FIG. 15 is a block diagram diagrammatic representation of machine in the example form of a computer system within which a set of instructions for causing the machine to perform any one or more of the methodologies discussed herein may be executed.
- Example methods and systems for dynamic funding authentication are described.
- numerous specific details are set forth in order to provide a thorough understanding of example embodiments. It will be evident, however, to one skilled in the art that the present invention may be practiced without these specific details.
- an identifier of a mobile device may be accessed.
- the identifier may be associated with a payment account.
- a single use authentication code relating to the identifier may be generated.
- the single use authentication code may be capable of being used to authenticate the mobile device at a point of sale (POS) device and enable a funds adjustment to the payment account.
- the single use authentication code may be provided to the mobile device through a communications network.
- an identifier of a first mobile device of a first user may be accessed.
- the identifier of the first mobile device may be associated with a payment account of the first user.
- a single use authentication code relating to the identifier of the first mobile device may be generated.
- the single use authentication code may be capable of being used to authenticate a second mobile device of a second user at a POS device and enable a funds adjustment to the payment account of the first user.
- the single use authentication code may be provided to the second mobile device through a communications network.
- funding authorization may be requested from an authentication provider through a mobile device.
- a single use authentication code may be received from the authentication provider.
- the single use authentication code may be capable of being used to authenticate the mobile device at a POS device and enable a funds adjustment to the payment account.
- the single use authentication code may be provided through the mobile device.
- a single use authentication code may be received from a mobile device.
- the single use authentication code and a funding request may be provided over a payment network to an authentication provider. Funds adjustment related to the funding request may be received from the authentication provider.
- FIG. 1 illustrates an example system 100 in which an authentication provider 106 may communicate with a mobile device 108 through a communications network 104 and a POS device 110 through a payment network 102 .
- the system 100 may enable a user of the mobile device 108 to be dynamically authenticated for payment with the authentication provider 106 using the mobile device 108 at the POS device 110 .
- the payment network 102 may be a network used by a credit card company, a debit card company, a bank, or other institution for authorization of financial or other transactions.
- the payment network 102 may be deployed over the Internet, intranet, and/or other type of local or global network.
- the communications network 104 may be a Global System for Mobile Communications (GSM) network, an Internet Protocol (IP) network, a Wireless Application Protocol (WAP) network, a WiFi network, or a IEEE 802.11 standards network as well as various combinations thereof. Other conventional and/or later developed wired and wireless networks may also be used.
- the payment network 102 and the communications network 104 may be the same network.
- the mobile device 108 may be a mobile phone, a personal digital assistant (PDA), a gaming unit, a portable computing unit, and the like.
- PDA personal digital assistant
- a user may use the mobile device 108 to obtain dynamic authentication for purchasing one or more items in a location (e.g., a store) in which the POS device 110 is located.
- the user may request that the dynamic authentication be made, or the dynamic authentication may occur automatically when a user is in proximity to the POS device 110
- the authentication provider 106 may retain an identifier (e.g. a SIM card number) associated with the mobile device 108 in memory and/or stored in the user data 114 of the database 112 .
- the identifier may enable a payment account 116 of a user to be linked to the mobile device 108 of the user or another authorized user (e.g., a child or spouse of the user associated with the payment account 116 ).
- Each user of the authentication provider 106 may have a separate payment account 116 .
- FIG. 2 is an example of an authentication provider 106 that may be deployed in the system 100 (see FIG. 1 ) or another system according to an example embodiment.
- the authentication provider 106 may include an authorization creation subsystem 202 , an authorization utilization subsystem 204 , and/or another subsystem.
- the authorization creation subsystem 202 may include a funding request module 206 , an identifier access module 208 , an authentication code generation module 210 , a code providing module 212 , an identifier provider module 214 , an identifier receiver module 216 , a communication request module 218 , and/or a communication receiver module 220 . Other modules may also be used.
- the funding request module 206 receives a request for funding authorization from the mobile device 108 .
- the request for funding authorization may be received when the mobile device 108 is in proximity to the POS device 110 and a user is seeking dynamic authentication.
- the identifier access module 208 accesses the identifier of the mobile device 108 .
- the identifier access module 208 may associate the payment account 116 with the identifier of the mobile device 108 and/or the identifier of the mobile device 108 may already be associated with the payment account 116 of a user.
- the association links the payment account 116 to the mobile device 108 .
- the authentication code generation module 210 generates a single use authentication code relating to the identifier.
- the single use authentication code may be capable of being used to authenticate the mobile device 108 at the POS device 110 and enable a funds adjustment to the payment account 116 of a user.
- the code providing module 212 provides the single use authentication code and an optional access code to the mobile device 108 through the communications network 104 .
- the access code may be capable of being used by a user at a terminal of the POS device 110 to authorize the funds adjustment.
- the identifier provider module 214 sends an identifier request for the identifier to the mobile device provider (e.g., AT&T Knowledge Ventures or Sprint Nextel) and/or the mobile device 108 .
- the identifier receiver module 216 receives the identifier of the mobile device 108 from the mobile device provider and/or the mobile device 108 .
- the received identifier may be stored in the user data 114 .
- the communication request module 218 sends a communication request message to the mobile device 108 including a request for a request for a confirmation code.
- the communication receiver module 220 receives the confirmation code from the mobile device 108 .
- the receipt of the confirmation code may confirm that the user is in possession of the mobile device 108 .
- the authorization utilization subsystem 204 may include an authentication receiver module 222 , an account identification module 224 , a funds availability module 226 , a funds withdrawal module 228 , a notification module 230 , a funds evaluation module 232 , an account adjustment module 234 , a conference request module 236 , a user determination module 238 , and/or an account authorization module 240 .
- Other modules may also be used.
- the authentication receiver module 222 receives a funds adjustment request and the single use authentication code from the POS device 110 through the payment network 102 .
- the account identification module 224 identifies the payment account 116 associated with the identifier related to the single use authentication code.
- the funds availability module 226 determines availability of funds in the payment account 116 of a user for an amount indicated in the funds adjustment request.
- the funds withdrawal module 228 withdraws funds in the amount from the payment account of the user.
- the notification module 230 sends a notification.
- the notification may be, by way of example, a notification that the funds in a particular amount have been withdrawn from the payment account 116 of a user, a notification that the payment account 116 has been adjusted by the amount, a notification identifying a merchant that has been provided the amount, or a notification identifying one or more items have been purchased with the amount. Other notifications may also be used.
- the funds evaluation module 232 evaluates the funds adjustment request against an evaluation criterion.
- the account adjustment module 234 adjusts the payment account 116 of a user by the amount.
- the conference request module 236 sends a confirmation request to the mobile device 108 and receives a response to the confirmation request.
- the user determination module 238 determines whether a first user associated with the payment account 116 has authorized adjustment by an amount indicated in the funds adjustment request for a second user associated with the mobile device 108 .
- the account authorization module 240 receives account authorization for a second user from a first user.
- FIG. 3 is an example of a mobile device 108 that may be deployed in the system 100 (see FIG. 1 ) or another system according to an example embodiment.
- the mobile device 108 may include a mobile processing subsystem 302 and/or another subsystem.
- the mobile processing subsystem 302 may include a funding request receiver module 304 , an authorization request module 306 , a code receiver module 308 , an authentication providing module 310 , a presentation module 312 , a pattern generation module 314 , a confirmation request receiver module 316 , a response receiver module 318 , and/or a response provider module 320 .
- Other modules may also be used.
- the funding request receiver module 304 receives a funding request from a user of the mobile device 108 .
- the authorization request module 306 requests funding authorization from the authentication provider 106 through the mobile device 108 .
- the code receiver module 308 receives a single use authentication code and an optional access code from the authentication provider 106 .
- the single use authentication code may be capable of being used to authenticate the mobile device 108 at the POS device 110 and enable a funds adjustment to the payment account 116 .
- the access code may be capable of being used with a terminal of the POS device 110 to authorize the funds adjustment.
- the authentication providing module 310 provides the single use authentication code and an optional authorization routing number through the mobile device 108 .
- the authorization routing number may be capable of being used to identify the authentication provider 106 associated with the payment account 116 .
- the authorization routing number may be used to select the payment network 102 from a number of available payment networks from a number of authentication providers.
- the presentation module 312 presents the access code, the single use authentication code, a single use pattern, a confirmation request, and/or the authorization routing number on a display of the mobile device 108 .
- the pattern generation module 314 generates a single use pattern (e.g., a bar code) from the single use authentication code and the authorization routing number.
- the single use pattern may be capable of being scanned by the POS device 110 .
- the confirmation request receiver module 316 receives a confirmation request from the authentication provider 106 .
- the response receiver module 318 receives a response to the confirmation request.
- the response provider module 320 provides the response to the authentication provider 106 .
- FIG. 4 is an example of a POS device 110 that may be deployed in the system 100 (see FIG. 1 ) or another system according to an example embodiment.
- the POS device 110 may include a POS processing subsystem 402 and/or another subsystem.
- the POS processing subsystem 402 may include a selection receiver module 404 , a total generation module 406 , a presentation module 408 , an authentication receiver module 410 , an authentication provider module 412 , an adjustment receiver module 414 , and/or a network determination module 416 . Other modules may also be used.
- the selection receiver module 404 receives a selection of one or more items (e.g., for purchase).
- the total generation module 406 generates a total for the selection.
- the presentation module 408 presents the total for the selection on a display of the POS device 110 .
- the authentication receiver module 410 receives a single use authentication code and an optional authorization routing number from the mobile device 108 .
- the authentication provider module 412 provides the single use authentication code and a funding request over the payment network 102 to the authentication provider 106 .
- the adjustment receiver module 414 receives funds adjustment related to the funding request from the authentication provider 106 .
- the network determination module 416 determines the payment network 102 from among a number of available payment networks based on the authorization routing number.
- FIG. 5 illustrates a method 500 for funding authentication according to an example embodiment.
- the method 500 may be performed by the authentication provider 106 (see FIG. 1 ) or another provider.
- a request for funding authorization may be received from the mobile device 108 at block 502 .
- the request may be sent from the mobile device 108 through the communications network 104 .
- the request may be sent via a text message, an e-mail, a SMS message, or the like.
- An identifier of the mobile device 108 is accessed at block 504 .
- the identifier may be unique or substantially unique (e.g., to distinguish the mobile device 108 of one user from other users).
- the identifier may be associated with the payment account 116 of a user.
- the identifier may be stored on a Subscriber Identity Module (SIM) card of the mobile device 108 , a Removable User Identity Module (RUIM) of the mobile device 108 , and/or known by a mobile device provider.
- SIM Subscriber Identity Module
- RUIM Removable User Identity Module
- the payment account 116 may be associated with the identifier of the mobile device 108 during the operations of block 504 or prior to initiating the operations of block 504 .
- the association of the payment account 116 with the identifier may include, by way of example, sending an identifier request for the identifier to a mobile device provider and receiving the identifier of the mobile device 108 from the mobile device provider, sending an identifier request for the identifier to the mobile device 108 and receiving the identifier of the mobile device 108 from the mobile device 108 , or the like.
- a single use authentication code relating to the identifier is generated at block 506 .
- the single use authentication code may be capable of being used to authenticate the mobile device 108 at the POS device 110 and enable a funds adjustment to the payment account 116 .
- the single use authentication code may include, by way of example, a single use universal product code (UPC), a single use debit card number, a single use credit card number, a single use account reference number, or the like.
- UPC universal product code
- Providing a single use authentication code to the mobile device 108 may enable a user of the mobile device to have a two-factor authentication at the POS device 110 .
- the single use authentication code may enable a dynamically generated code to be used to provide greater security for the payment account 116 and to reduce a potential for fraud with the payment account 116 .
- the single use authentication code and an optional access code is provided to the mobile device 108 through the communications network 104 at block 508 .
- the access code may be capable of being used with a terminal of the POS device 110 to authorize the funds adjustment.
- Payment authorization for the payment account 116 may be processed at block 510 .
- An example embodiment of the payment authorization is described in greater detail below.
- FIG. 6 illustrates a method 600 for processing payment authorization for the payment account 116 according to an example embodiment.
- the method 600 may be performed at block 510 (see FIG. 5 ) by the authentication provider 106 or otherwise performed.
- a funds adjustment request and the single use authentication code is received from the POS device 110 through the payment network 102 at block 602 .
- the payment account 116 is identified from the identifier related to the single use authentication code at block 604 .
- the notification of funding success may include, for example, a notification that the funds in the amount have been withdrawn from the payment account 116 , a notification identifying a merchant that has been provided the amount, or a notification identifying one or more items that have been purchased with the amount.
- Other notifications may also be used.
- FIG. 7 illustrates a method 700 for processing payment authorization for the payment account 116 according to an example embodiment.
- the method 700 may be performed at block 510 (see FIG. 5 ) by the authentication provider 106 or otherwise performed.
- a funds adjustment request and the single use authentication code is received from the POS device 110 through the payment network 102 .
- the payment account 116 is identified from the identifier related to the single use authentication code at block 704 .
- the evaluation criterion may include a limit on a period of time since a pin code (e.g. for access to the mobile device 108 ) was entered into the mobile device 108 , a calling pattern made with the mobile device 108 , a transaction pattern made with the payment account 116 , a period of time between when the single use authentication code was generated and provided to the mobile device 108 and received back from the POS device 110 , a specified sum of money, a specified type of item, and/or a specified merchant. Other criterion may also be used.
- a confirmation request may be sent.
- the confirmation request may be sent to the mobile device 108 , provided orally to a user of the mobile device 108 , or otherwise provided.
- the confirmation request may include a request for a pin code to be received by the mobile device 108 , a request for an audible confirmation to be received by the mobile device 108 , and/or a request for a log in to a web site provided by the authentication provider 106 .
- Other confirmation requests may also be used.
- a response to the confirmation request may be received at block 712 .
- the confirmation request may be provided through the mobile device 108 or to an agent speaking with the user of the mobile device 108 .
- adjusting the payment account 116 may include adding or subtracting funds (e.g., money or other stored value) from the payment account 116 .
- FIG. 8 illustrates a method 800 for processing payment authorization for the payment account 116 according to an example embodiment.
- the method 800 may be performed at block 510 (see FIG. 5 ) by the authentication provider 106 or otherwise performed.
- a funds adjustment request and the single use authentication code is received from the POS device 110 through the payment network 102 .
- the payment account 116 is identified from the identifier related to the single use authentication code at block 804 .
- a first user e.g., a parent 0 associated with the payment account 116 has authorized adjustment by an amount indicated in the funds adjustment request for a second user (e.g., a child) associated with the mobile device 108 . If a determination is made that the payment account has not been authorized, a notice of funding failure may be provided at block 808 . If a determination is made at decision block 806 that the
- FIG. 9 illustrates a method 900 for funding authentication according to an example embodiment.
- the method 900 may be performed by the authentication provider 106 (see FIG. 1 ) or another provider.
- Account authorization for a second user may be received from a first user at block 902 .
- a parent may provide account authorization for a child
- a user may provide account authorization for a spouse, and the like.
- a request for funding authorization is received from the second user at block 904 .
- An identifier of a first mobile device of a first user is accessed at block 906 .
- the identifier of the first mobile device 108 may be associated with the payment account 116 of the first user.
- the identifier of the second mobile device of the second user may be accessed at block 908 .
- the identifier of the second mobile device 108 may be associated with the payment account 118 of the second user.
- a single use authentication code relating to the identifier of the first mobile device is generated at block 910 .
- the single use authentication code may be capable of being used to authenticate the second mobile device 108 of the second user at the POS device 110 and may enable a funds adjustment to the payment account 116 of the first user.
- the single use authentication code may related to the identifier of the first mobile device 108 and the second mobile device 108 and may be capable of being used to authenticate the second mobile device 108 of the second user at the POS device 110 and enable a funds adjustment to the payment account 116 of the first user and/or or the second user.
- the single use authentication code may be provided to the second mobile device 108 through the communications network 104 at block 912 .
- Payment authorization may be processed for the payment account at block 914 .
- payment authorization may be processed according to the methods 600 , 700 , 800 (see FIGS. 6-8 ).
- FIG. 10 illustrates a method 1000 for processing payment authorization for the payment account 116 according to an example embodiment.
- the method 1000 may be performed at block 510 or block 912 (see FIGS. 5 and 9 ) by the authentication provider 106 or otherwise performed.
- a funds adjustment request and a single use authentication code is received from the POS device 110 through the payment network 102 at block 1002 .
- the payment account 116 is identified from the identifier related to the single use authentication code at block 1004 .
- the payment account 116 of the first user may be adjusted by a first portion of the amount and the payment account 116 of the second user may be adjusted by a second portion of the amount.
- the first portion may be a sum of money designated by the first user and the second portion may be a remaining portion of the amount not designated by the first user.
- FIG. 11 illustrates a method 1100 for utilizing the mobile device 108 according to an example embodiment.
- a funding request may be received from a user of the mobile device 108 at block 1102 .
- funding authorization is requested from the authentication provider 106 through the mobile device 108 .
- a single use authentication code and an optional access code is received from the authentication provider 106 at block 1106 .
- the single use authentication code may be capable of being used to authenticate the mobile device 108 at the POS device 110 and enable a funds adjustment to the payment account 116 .
- the access code may be capable of being used with a terminal of the POS device 110 to authorize the funds adjustment.
- the single use authentication code and an optional authorization routing number is provided through the mobile device 108 to the POS device 110 at block 1108 .
- the single use authentication code and an optional authorization routing number may be provided simultaneously or sequentially.
- the authorization routing number may be capable of being used to identify the authentication provider 106 (e.g., as a provider of the payment account 116 ).
- the single use authentication code and the authorization routing number may be a virtual debit card number and the access code may be a pin number.
- the single use authentication code and the authorization routing number may be a credit debit card number and the access code is a card identification number or credit card security code.
- Other embodiments of the single use authentication code, the authorization routing number, and/or the access code may also be used.
- Authorization information may be presented on a display of the mobile device 108 at block 1110 .
- the presented authorization information may include the access code, the single use authentication code, and/or the authorization routing number. Other authorization information may also be presented.
- a single use pattern may be generated from the single use authentication code and the authorization routing number and the single use pattern may be presented on the display of the mobile device 108 .
- the single use pattern may be capable of being scanned by the POS device 110 .
- the single use pattern may be a bar code or other type of cryptographic or non-cryptographic pattern.
- a confirmation request may be received from the authentication provider 106 at block 1112 .
- the confirmation request may be presented on the mobile device 108 at block 1114 .
- a response to the confirmation request may be received at block 1116 .
- the response to the authentication provider 106 may be provided at block 1118 .
- a notification may be received from the authentication provider 106 at block 1120 .
- FIG. 12 illustrates a method 1200 for utilizing the POS device 110 according to an example embodiment.
- a selection of one or more items may be received at block 1202 .
- a total for the selection may be generated at block 1204 .
- the total for the selection may be presented on a display of a point of sale (POS) device at block 1206 .
- POS point of sale
- a single use authentication code and an optional authorization routing number is received from the mobile device 108 .
- the single use authentication code and an optional authorization routing number may be received simultaneously or sequentially.
- the authorization routing number may be capable of being used to identify a provider of the payment account 116 .
- the receipt of the single use authentication code and the optional authorization routing number may enable authorization of a funds adjustment to be made.
- a display of the mobile device 108 may be scanned to receive the single use authentication code and an authorization routing number.
- the single use authentication code and an authorization routing number may be in the form of a single use pattern presented on the display of the mobile device 108 .
- the single use authentication code and an authorization routing number may be provided from the mobile device 108 wirelessly (e.g., IR or RF), through a portable media card, or otherwise provided.
- the payment network may be determined based on the authorization routing number at block 1210 .
- the single use authentication code and a funding request is provided over the payment network 102 to the authentication provider 106 at block 1212 .
- a funds adjustment related to the funding request is received from the authentication provider 106 at block 1214 .
- FIG. 13 is a network diagram depicting a client-server system 1300 , within which one example embodiment may be deployed.
- a network 1304 may include the functionality of the communications network 104
- the authentication provider 106 may be deployed on the application server 1318 as a payment application 1322
- a client machine 1310 or a client machine 1312 may include the functionality of the mobile device 108
- a database 1326 may include the functionality of the database 112 .
- the system 100 may also be deployed in other systems.
- a networked system 1302 in the example forms of a network-based marketplace or publication system, provides server-side functionality, via a network 1304 (e.g., the Internet or Wide Area Network (WAN)) to one or more clients.
- a network 1304 e.g., the Internet or Wide Area Network (WAN)
- FIG. 13 illustrates, for example, a web client 1306 (e.g., a browser, such as the Internet Explorer browser developed by Microsoft Corporation of Redmond, Washington State), and a programmatic client 1308 executing on respective client machines 1310 and 1312 .
- a web client 1306 e.g., a browser, such as the Internet Explorer browser developed by Microsoft Corporation of Redmond, Washington State
- programmatic client 1308 executing on respective client machines 1310 and 1312 .
- An Application Program Interface (API) server 1314 and a web server 1316 are coupled to, and provide programmatic and web interfaces respectively to, one or more application servers 1318 .
- the application servers 1318 host one or more marketplace applications 1320 and authentication providers 1322 .
- the application servers 1318 are, in turn, shown to be coupled to one or more databases servers 1324 that facilitate access to one or more databases 1326 .
- the marketplace applications 1320 may provide a number of marketplace functions and services to users that access the networked system 1302 .
- the authentication providers 1322 may likewise provide a number of payment services and functions to users.
- the authentication providers 1322 may allow users to accumulate value (e.g., in a commercial currency, such as the U.S. dollar, or a proprietary currency, such as “points”) in accounts, and then later to redeem the accumulated value for products (e.g., goods or services) that are made available via the marketplace applications 1320 . While the marketplace and authentication providers 1320 and 1322 are shown in FIG. 13 to both form part of the networked system 1302 , in alternative embodiments the authentication providers 1322 may form part of a payment service that is separate and distinct from the networked system 1302 .
- system 1300 shown in FIG. 13 employs a client-server architecture
- present invention is of course not limited to such an architecture, and could equally well find application in a distributed, or peer-to-peer, architecture system, for example.
- the various marketplace and authentication providers 1320 and 1322 could also be implemented as standalone software programs, which need not have networking capabilities.
- the web client 1306 accesses the various marketplace and authentication providers 1320 and 1322 via the web interface supported by the web server 1316 .
- the programmatic client 1308 accesses the various services and functions provided by the marketplace and authentication providers 1320 and 1322 via the programmatic interface provided by the API server 1314 .
- the programmatic client 1308 may, for example, be a seller application (e.g., the TurboListerTM application developed by eBay Inc., of San Jose, Calif.) to enable sellers to author and manage listings on the networked system 1302 in an off-line manner, and to perform batch-mode communications between the programmatic client 1308 and the networked system 1302 .
- FIG. 13 also illustrates a third party application 1328 , executing on a third party server machine 1330 , as having programmatic access to the networked system 1302 via the programmatic interface provided by the API server 1314 .
- the third party application 1328 may, utilizing information retrieved from the networked system 1302 , support one or more features or functions on a website hosted by the third party.
- the third party may, for example, provide one or more promotional, marketplace or payment functions that are supported by the relevant applications of the networked system 1302 .
- FIG. 14 is a block diagram illustrating multiple applications 1320 and 1322 that, in one example embodiment, are provided as part of the networked system 1302 (see FIG. 13 ).
- the applications 1320 may be hosted on dedicated or shared server machines (not shown) that are communicatively coupled to enable communications between server machines.
- the applications themselves are communicatively coupled (e.g., via appropriate interfaces) to each other and to various data sources, so as to allow information to be passed between the applications or so as to allow the applications to share and access common data.
- the applications may furthermore access one or more databases 1326 via the database servers 1324 .
- the networked system 1302 may provide a number of publishing, listing and price-setting mechanisms whereby a seller may list (or publish information concerning) goods or services for sale, a buyer can express interest in or indicate a desire to purchase such goods or services, and a price can be set for a transaction pertaining to the goods or services.
- the marketplace applications 1320 are shown to include at least one publication application 1400 and one or more auction applications 1402 which support auction-format listing and price setting mechanisms (e.g., English, Dutch, Vickrey, Chinese, Double, Reverse auctions etc.).
- the various auction applications 1402 may also provide a number of features in support of such auction-format listings, such as a reserve price feature whereby a seller may specify a reserve price in connection with a listing and a proxy-bidding feature whereby a bidder may invoke automated proxy bidding.
- a reserve price feature whereby a seller may specify a reserve price in connection with a listing
- a proxy-bidding feature whereby a bidder may invoke automated proxy bidding.
- a number of fixed-price applications 1404 support fixed-price listing formats (e.g., the traditional classified advertisement-type listing or a catalogue listing) and buyout-type listings.
- buyout-type listings e.g., including the Buy-It-Now (BIN) technology developed by eBay Inc., of San Jose, Calif.
- BIN Buy-It-Now
- auction-format listings may be offered in conjunction with auction-format listings, and allow a buyer to purchase goods or services, which are also being offered for sale via an auction, for a fixed-price that is typically higher than the starting price of the auction.
- Store applications 1406 allow a seller to group listings within a “virtual” store, which may be branded and otherwise personalized by and for the seller. Such a virtual store may also offer promotions, incentives and features that are specific and personalized to a relevant seller.
- Reputation applications 1408 allow users that transact, utilizing the networked system 1302 , to establish, build and maintain reputations, which may be made available and published to potential trading partners.
- the reputation applications 1408 allow a user, for example through feedback provided by other transaction partners, to establish a reputation within the networked system 1302 over time. Other potential trading partners may then reference such a reputation for the purposes of assessing credibility and trustworthiness.
- Personalization applications 1410 allow users of the networked system 1302 to personalize various aspects of their interactions with the networked system 1302 . For example a user may, utilizing an appropriate personalization application 1410 , create a personalized reference page at which information regarding transactions to which the user is (or has been) a party may be viewed. Further, a personalization application 1410 may enable a user to personalize listings and other aspects of their interactions with the networked system 1302 and other parties.
- the networked system 1302 may support a number of marketplaces that are customized, for example, for specific geographic regions.
- a version of the networked system 1302 may be customized for the United Kingdom, whereas another version of the networked system 1302 may be customized for the United States.
- Each of these versions may operate as an independent marketplace, or may be customized (or internationalized and/or localized) presentations of a common underlying marketplace.
- the networked system 1302 may accordingly include a number of internationalization applications 1412 that customize information (and/or the presentation of information) by the networked system 1302 according to predetermined criteria (e.g., geographic, demographic or marketplace criteria).
- predetermined criteria e.g., geographic, demographic or marketplace criteria.
- the internationalization applications 1412 may be used to support the customization of information for a number of regional websites that are operated by the networked system 1302 and that are accessible via respective web servers 1316 .
- Navigation of the networked system 1302 may be facilitated by one or more navigation applications 1414 .
- a search application (as an example of a navigation application) may enable key word searches of listings published via the networked system 1302 .
- a browse application may allow users to browse various category, catalogue, or system inventory structures according to which listings may be classified within the networked system 1302 .
- Various other navigation applications may be provided to supplement the search and browsing applications.
- the marketplace applications 1320 may include one or more imaging applications 1416 utilizing which users may upload images for inclusion within listings.
- An imaging application 1416 also operates to incorporate images within viewed listings.
- the imaging applications 1416 may also support one or more promotional features, such as image galleries that are presented to potential buyers. For example, sellers may pay an additional fee to have an image included within a gallery of images for promoted items.
- Listing creation applications 1418 allow sellers conveniently to author listings pertaining to goods or services that they wish to transact via the networked system 1302
- listing management applications 1420 allow sellers to manage such listings. Specifically, where a particular seller has authored and/or published a large number of listings, the management of such listings may present a challenge.
- the listing management applications 1420 provide a number of features (e.g., auto-relisting, inventory level monitors, etc.) to assist the seller in managing such listings.
- One or more post-listing management applications 1422 also assist sellers with a number of activities that typically occur post-listing. For example, upon completion of an auction facilitated by one or more auction applications 1402 , a seller may wish to leave feedback regarding a particular buyer. To this end, a post-listing management application 1422 may provide an interface to one or more reputation applications 1408 , so as to allow the seller conveniently to provide feedback regarding multiple buyers to the reputation applications 1408 .
- Dispute resolution applications 1424 provide mechanisms whereby disputes arising between transacting parties may be resolved.
- the dispute resolution applications 1424 may provide guided procedures whereby the parties are guided through a number of steps in an attempt to settle a dispute. In the event that the dispute cannot be settled via the guided procedures, the dispute may be escalated to a merchant mediator or arbitrator.
- a number of fraud prevention applications 1426 implement fraud detection and prevention mechanisms to reduce the occurrence of fraud within the networked system 1302 .
- Messaging applications 1428 are responsible for the generation and delivery of messages to users of the networked system 1302 , such messages for example advising users regarding the status of listings at the networked system 1302 (e.g., providing “outbid” notices to bidders during an auction process or to provide promotional and merchandising information to users). Respective messaging applications 1428 may utilize any one have a number of message delivery networks and platforms to deliver messages to users.
- messaging applications 1428 may deliver electronic mail (e-mail), instant message (IM), Short Message Service (SMS), text, facsimile, or voice (e.g., Voice over IP (VoIP)) messages via the wired (e.g., the Internet), Plain Old Telephone Service (POTS), or wireless (e.g., mobile, cellular, WiFi, WiMAX) networks.
- e-mail electronic mail
- IM instant message
- SMS Short Message Service
- text e.g., text
- facsimile e.g., facsimile
- voice e.g., Voice over IP (VoIP)
- POTS Plain Old Telephone Service
- wireless e.g., mobile, cellular, WiFi, WiMAX
- Merchandising applications 1430 support various merchandising functions that are made available to sellers to enable sellers to increase sales via the networked system 1302 .
- the merchandising applications 1430 also operate the various merchandising features that may be invoked by sellers, and may monitor and track the success of merchandising strategies employed by sellers.
- FIG. 15 shows a diagrammatic representation of machine in the example form of a computer system 1500 within which a set of instructions may be executed causing the machine to perform any one or more of the methods, processes, operations, or methodologies discussed herein.
- the authentication provider 106 may operate on or more computer systems 1500 and/or the authentication provider 106 , the mobile device 108 , and/or the POS device 110 may include the functionality of the computer system 1500 .
- the machine operates as a standalone device or may be connected (e.g., networked) to other machines.
- the machine may operate in the capacity of a server or a client machine in server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment.
- the machine may be a server computer, a client computer, a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine.
- PC personal computer
- PDA Personal Digital Assistant
- the example computer system 1500 includes a processor 1502 (e.g., a central processing unit (CPU) a graphics processing unit (GPU) or both), a main memory 1504 and a static memory 1506 , which communicate with each other via a bus 1508 .
- the computer system 1500 may further include a video display unit 1510 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)).
- the computer system 1500 also includes an alphanumeric input device 1512 (e.g., a keyboard), a cursor control device 1514 (e.g., a mouse), a drive unit 1516 , a signal generation device 1518 (e.g., a speaker) and a network interface device 1520 .
- the drive unit 1516 includes a machine-readable medium 1522 on which is stored one or more sets of instructions (e.g., software 1524 ) embodying any one or more of the methodologies or functions described herein.
- the software 1524 may also reside, completely or at least partially, within the main memory 1504 and/or within the processor 1502 during execution thereof by the computer system 1500 , the main memory 1504 and the processor 1502 also constituting machine-readable media.
- the software 1524 may further be transmitted or received over a network 1526 via the network interface device 1520 .
- machine-readable medium 1522 is shown in an example embodiment to be a single medium, the term “machine-readable medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions.
- the term “machine-readable medium” shall also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present invention.
- the term “machine-readable medium” shall accordingly be taken to include, but not be limited to, solid-state memories, optical and magnetic media, and carrier wave signals.
- a module or a mechanism may be a unit of distinct functionality that can provide information to, and receive information from, other modules. Accordingly, the described modules may be regarded as being communicatively coupled. Modules may also initiate communication with input or output devices, and can operate on a resource (e.g., a collection of information).
- the modules be implemented as hardware circuitry, optical components, single or multi-processor circuits, memory circuits, software program modules and objects, firmware, and combinations thereof, as appropriate for particular implementations of various embodiments.
Abstract
An identifier of a mobile device may be accessed. The identifier may be associated with a payment account. A single use authentication code relating to the identifier may be generated. The single use authentication code may be capable of being used to authenticate the mobile device at a point of sale (POS) device and enable a funds adjustment to the payment account. The single use authentication code may be provided to the mobile device through a communications network.
Description
- This application is a continuation of U.S. application Ser. No. 11/881,920 filed Jul. 30, 2007, which application is incorporated in its entirety herein by reference.
- A payment card (e.g., a credit card) may be used to authenticate payment from a payment account. A cryptographic key may be included in a magnetic stripe of the payment card and used at a point of sale to identify whether the card is a legitimate card. The information in the magnetic stripe may be subject to unauthorized capture, thereby compromising both the payment account and the card. A nefarious user that has made that unauthorized capture may be able to withdraw funds from the payment account using the card one or more times before the unauthorized activity is detected.
- Some embodiments are illustrated by way of example and not limitation in the figures of the accompanying drawings in which:
-
FIG. 1 is a block diagram of a system, according to an example embodiment; -
FIG. 2 is a block diagram of an example authentication provider that may be deployed within the system ofFIG. 1 according to an example embodiment; -
FIG. 3 is a block diagram of an example mobile device that may be deployed within the system ofFIG. 1 according to an example embodiment; -
FIG. 4 is a block diagram of an example point of sale device that may be deployed within the system ofFIG. 1 according to an example embodiment; -
FIG. 5 is a flowchart illustrating a method for funding authentication according to an example embodiment; -
FIGS. 6-8 are flowcharts illustrating a method for processing payment authorization for the payment account according to an example embodiment; -
FIG. 9 is a flowchart illustrating a method for funding authentication according to an example embodiment; -
FIG. 10 is a flowchart illustrating a method for processing payment authorization according to an example embodiment; -
FIG. 11 is a flowchart illustrating a method for utilizing a mobile device according to an example embodiment; -
FIG. 12 is a flowchart illustrating a method for utilizing a point of sale device according to an example embodiment; -
FIG. 13 is a network diagram depicting a network system, according to one embodiment, having a client server architecture configured for exchanging data over a network; -
FIG. 14 is a block diagram illustrating an example embodiment of multiple network and marketplace applications, which are provided as part of the network-based marketplace; and -
FIG. 15 is a block diagram diagrammatic representation of machine in the example form of a computer system within which a set of instructions for causing the machine to perform any one or more of the methodologies discussed herein may be executed. - Example methods and systems for dynamic funding authentication are described. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of example embodiments. It will be evident, however, to one skilled in the art that the present invention may be practiced without these specific details.
- In an example embodiment, an identifier of a mobile device may be accessed. The identifier may be associated with a payment account. A single use authentication code relating to the identifier may be generated. The single use authentication code may be capable of being used to authenticate the mobile device at a point of sale (POS) device and enable a funds adjustment to the payment account. The single use authentication code may be provided to the mobile device through a communications network.
- In an example embodiment, an identifier of a first mobile device of a first user may be accessed. The identifier of the first mobile device may be associated with a payment account of the first user. A single use authentication code relating to the identifier of the first mobile device may be generated. The single use authentication code may be capable of being used to authenticate a second mobile device of a second user at a POS device and enable a funds adjustment to the payment account of the first user. The single use authentication code may be provided to the second mobile device through a communications network.
- In an example embodiment, funding authorization may be requested from an authentication provider through a mobile device. A single use authentication code may be received from the authentication provider. The single use authentication code may be capable of being used to authenticate the mobile device at a POS device and enable a funds adjustment to the payment account. The single use authentication code may be provided through the mobile device.
- In an example embodiment, a single use authentication code may be received from a mobile device. The single use authentication code and a funding request may be provided over a payment network to an authentication provider. Funds adjustment related to the funding request may be received from the authentication provider.
-
FIG. 1 illustrates anexample system 100 in which anauthentication provider 106 may communicate with amobile device 108 through acommunications network 104 and aPOS device 110 through apayment network 102. Thesystem 100 may enable a user of themobile device 108 to be dynamically authenticated for payment with theauthentication provider 106 using themobile device 108 at thePOS device 110. - The
payment network 102 may be a network used by a credit card company, a debit card company, a bank, or other institution for authorization of financial or other transactions. Thepayment network 102 may be deployed over the Internet, intranet, and/or other type of local or global network. - The
communications network 104 may be a Global System for Mobile Communications (GSM) network, an Internet Protocol (IP) network, a Wireless Application Protocol (WAP) network, a WiFi network, or a IEEE 802.11 standards network as well as various combinations thereof. Other conventional and/or later developed wired and wireless networks may also be used. In an example embodiment, thepayment network 102 and thecommunications network 104 may be the same network. - The
mobile device 108 may be a mobile phone, a personal digital assistant (PDA), a gaming unit, a portable computing unit, and the like. A user may use themobile device 108 to obtain dynamic authentication for purchasing one or more items in a location (e.g., a store) in which thePOS device 110 is located. The user may request that the dynamic authentication be made, or the dynamic authentication may occur automatically when a user is in proximity to thePOS device 110 - The
authentication provider 106 may retain an identifier (e.g. a SIM card number) associated with themobile device 108 in memory and/or stored in theuser data 114 of thedatabase 112. The identifier may enable apayment account 116 of a user to be linked to themobile device 108 of the user or another authorized user (e.g., a child or spouse of the user associated with the payment account 116). Each user of theauthentication provider 106 may have aseparate payment account 116. -
FIG. 2 is an example of anauthentication provider 106 that may be deployed in the system 100 (seeFIG. 1 ) or another system according to an example embodiment. Theauthentication provider 106 may include anauthorization creation subsystem 202, anauthorization utilization subsystem 204, and/or another subsystem. - The
authorization creation subsystem 202 may include afunding request module 206, anidentifier access module 208, an authenticationcode generation module 210, acode providing module 212, anidentifier provider module 214, anidentifier receiver module 216, acommunication request module 218, and/or acommunication receiver module 220. Other modules may also be used. - The
funding request module 206 receives a request for funding authorization from themobile device 108. The request for funding authorization may be received when themobile device 108 is in proximity to thePOS device 110 and a user is seeking dynamic authentication. - The
identifier access module 208 accesses the identifier of themobile device 108. Theidentifier access module 208 may associate thepayment account 116 with the identifier of themobile device 108 and/or the identifier of themobile device 108 may already be associated with thepayment account 116 of a user. The association links thepayment account 116 to themobile device 108. - The authentication
code generation module 210 generates a single use authentication code relating to the identifier. The single use authentication code may be capable of being used to authenticate themobile device 108 at thePOS device 110 and enable a funds adjustment to thepayment account 116 of a user. - The
code providing module 212 provides the single use authentication code and an optional access code to themobile device 108 through thecommunications network 104. The access code may be capable of being used by a user at a terminal of thePOS device 110 to authorize the funds adjustment. - The
identifier provider module 214 sends an identifier request for the identifier to the mobile device provider (e.g., AT&T Knowledge Ventures or Sprint Nextel) and/or themobile device 108. Theidentifier receiver module 216 receives the identifier of themobile device 108 from the mobile device provider and/or themobile device 108. The received identifier may be stored in theuser data 114. - The
communication request module 218 sends a communication request message to themobile device 108 including a request for a request for a confirmation code. Thecommunication receiver module 220 receives the confirmation code from themobile device 108. The receipt of the confirmation code may confirm that the user is in possession of themobile device 108. - The
authorization utilization subsystem 204 may include anauthentication receiver module 222, anaccount identification module 224, afunds availability module 226, afunds withdrawal module 228, anotification module 230, afunds evaluation module 232, anaccount adjustment module 234, aconference request module 236, auser determination module 238, and/or anaccount authorization module 240. Other modules may also be used. - The
authentication receiver module 222 receives a funds adjustment request and the single use authentication code from thePOS device 110 through thepayment network 102. Theaccount identification module 224 identifies thepayment account 116 associated with the identifier related to the single use authentication code. - The
funds availability module 226 determines availability of funds in thepayment account 116 of a user for an amount indicated in the funds adjustment request. Thefunds withdrawal module 228 withdraws funds in the amount from the payment account of the user. - The
notification module 230 sends a notification. The notification may be, by way of example, a notification that the funds in a particular amount have been withdrawn from thepayment account 116 of a user, a notification that thepayment account 116 has been adjusted by the amount, a notification identifying a merchant that has been provided the amount, or a notification identifying one or more items have been purchased with the amount. Other notifications may also be used. - The
funds evaluation module 232 evaluates the funds adjustment request against an evaluation criterion. Theaccount adjustment module 234 adjusts thepayment account 116 of a user by the amount. Theconference request module 236 sends a confirmation request to themobile device 108 and receives a response to the confirmation request. - The
user determination module 238 determines whether a first user associated with thepayment account 116 has authorized adjustment by an amount indicated in the funds adjustment request for a second user associated with themobile device 108. Theaccount authorization module 240 receives account authorization for a second user from a first user. -
FIG. 3 is an example of amobile device 108 that may be deployed in the system 100 (seeFIG. 1 ) or another system according to an example embodiment. Themobile device 108 may include amobile processing subsystem 302 and/or another subsystem. - The
mobile processing subsystem 302 may include a fundingrequest receiver module 304, anauthorization request module 306, acode receiver module 308, anauthentication providing module 310, apresentation module 312, apattern generation module 314, a confirmationrequest receiver module 316, aresponse receiver module 318, and/or aresponse provider module 320. Other modules may also be used. - The funding
request receiver module 304 receives a funding request from a user of themobile device 108. Theauthorization request module 306 requests funding authorization from theauthentication provider 106 through themobile device 108. - The
code receiver module 308 receives a single use authentication code and an optional access code from theauthentication provider 106. The single use authentication code may be capable of being used to authenticate themobile device 108 at thePOS device 110 and enable a funds adjustment to thepayment account 116. The access code may be capable of being used with a terminal of thePOS device 110 to authorize the funds adjustment. - The
authentication providing module 310 provides the single use authentication code and an optional authorization routing number through themobile device 108. The authorization routing number may be capable of being used to identify theauthentication provider 106 associated with thepayment account 116. For example, the authorization routing number may be used to select thepayment network 102 from a number of available payment networks from a number of authentication providers. - The
presentation module 312 presents the access code, the single use authentication code, a single use pattern, a confirmation request, and/or the authorization routing number on a display of themobile device 108. - The
pattern generation module 314 generates a single use pattern (e.g., a bar code) from the single use authentication code and the authorization routing number. The single use pattern may be capable of being scanned by thePOS device 110. - The confirmation
request receiver module 316 receives a confirmation request from theauthentication provider 106. Theresponse receiver module 318 receives a response to the confirmation request. Theresponse provider module 320 provides the response to theauthentication provider 106. -
FIG. 4 is an example of aPOS device 110 that may be deployed in the system 100 (seeFIG. 1 ) or another system according to an example embodiment. ThePOS device 110 may include aPOS processing subsystem 402 and/or another subsystem. - The
POS processing subsystem 402 may include aselection receiver module 404, atotal generation module 406, apresentation module 408, anauthentication receiver module 410, anauthentication provider module 412, anadjustment receiver module 414, and/or anetwork determination module 416. Other modules may also be used. - The
selection receiver module 404 receives a selection of one or more items (e.g., for purchase). Thetotal generation module 406 generates a total for the selection. Thepresentation module 408 presents the total for the selection on a display of thePOS device 110. - The
authentication receiver module 410 receives a single use authentication code and an optional authorization routing number from themobile device 108. Theauthentication provider module 412 provides the single use authentication code and a funding request over thepayment network 102 to theauthentication provider 106. - The
adjustment receiver module 414 receives funds adjustment related to the funding request from theauthentication provider 106. Thenetwork determination module 416 determines thepayment network 102 from among a number of available payment networks based on the authorization routing number. -
FIG. 5 illustrates amethod 500 for funding authentication according to an example embodiment. Themethod 500 may be performed by the authentication provider 106 (seeFIG. 1 ) or another provider. - A request for funding authorization may be received from the
mobile device 108 atblock 502. The request may be sent from themobile device 108 through thecommunications network 104. The request may be sent via a text message, an e-mail, a SMS message, or the like. - An identifier of the
mobile device 108 is accessed atblock 504. The identifier may be unique or substantially unique (e.g., to distinguish themobile device 108 of one user from other users). The identifier may be associated with thepayment account 116 of a user. The identifier may be stored on a Subscriber Identity Module (SIM) card of themobile device 108, a Removable User Identity Module (RUIM) of themobile device 108, and/or known by a mobile device provider. Thepayment account 116 may be associated with the identifier of themobile device 108 during the operations ofblock 504 or prior to initiating the operations ofblock 504. - In an example embodiment, the association of the
payment account 116 with the identifier may include, by way of example, sending an identifier request for the identifier to a mobile device provider and receiving the identifier of themobile device 108 from the mobile device provider, sending an identifier request for the identifier to themobile device 108 and receiving the identifier of themobile device 108 from themobile device 108, or the like. - A single use authentication code relating to the identifier is generated at
block 506. The single use authentication code may be capable of being used to authenticate themobile device 108 at thePOS device 110 and enable a funds adjustment to thepayment account 116. The single use authentication code may include, by way of example, a single use universal product code (UPC), a single use debit card number, a single use credit card number, a single use account reference number, or the like. Providing a single use authentication code to themobile device 108 may enable a user of the mobile device to have a two-factor authentication at thePOS device 110. The single use authentication code may enable a dynamically generated code to be used to provide greater security for thepayment account 116 and to reduce a potential for fraud with thepayment account 116. - The single use authentication code and an optional access code is provided to the
mobile device 108 through thecommunications network 104 atblock 508. The access code may be capable of being used with a terminal of thePOS device 110 to authorize the funds adjustment. - Payment authorization for the
payment account 116 may be processed atblock 510. An example embodiment of the payment authorization is described in greater detail below. -
FIG. 6 illustrates amethod 600 for processing payment authorization for thepayment account 116 according to an example embodiment. Themethod 600 may be performed at block 510 (seeFIG. 5 ) by theauthentication provider 106 or otherwise performed. - A funds adjustment request and the single use authentication code is received from the
POS device 110 through thepayment network 102 atblock 602. Thepayment account 116 is identified from the identifier related to the single use authentication code atblock 604. - A determination may be made at
decision block 606 as to the availability of funds in thepayment account 116 for an amount indicated in the funds adjustment request. If a determination is made that funds are not available in thepayment account 116, a notice of funding failure may be provided atblock 608. If a determination is made atdecision block 606 that funds are available in thepayment account 116, funds are withdrawn in the amount from thepayment account 116 atblock 610 and a notice of funding success may be provided atblock 612. - In an example embodiment, the notification of funding success may include, for example, a notification that the funds in the amount have been withdrawn from the
payment account 116, a notification identifying a merchant that has been provided the amount, or a notification identifying one or more items that have been purchased with the amount. Other notifications may also be used. -
FIG. 7 illustrates amethod 700 for processing payment authorization for thepayment account 116 according to an example embodiment. Themethod 700 may be performed at block 510 (seeFIG. 5 ) by theauthentication provider 106 or otherwise performed. - At
block 702, a funds adjustment request and the single use authentication code is received from thePOS device 110 through thepayment network 102. Thepayment account 116 is identified from the identifier related to the single use authentication code atblock 704. - An evaluation of the funds adjustment request against an evaluation criterion is made at
block 706. The evaluation criterion may include a limit on a period of time since a pin code (e.g. for access to the mobile device 108) was entered into themobile device 108, a calling pattern made with themobile device 108, a transaction pattern made with thepayment account 116, a period of time between when the single use authentication code was generated and provided to themobile device 108 and received back from thePOS device 110, a specified sum of money, a specified type of item, and/or a specified merchant. Other criterion may also be used. - A determination may be made at
decision block 708 as to whether the evaluation was successful. If a determination is made that the evaluation was successful, themethod 700 may proceed to block 718. If a determination is made atdecision block 708 that the evaluation is not successful, themethod 700 may proceed to block 710. - At
block 710, a confirmation request may be sent. The confirmation request may be sent to themobile device 108, provided orally to a user of themobile device 108, or otherwise provided. The confirmation request may include a request for a pin code to be received by themobile device 108, a request for an audible confirmation to be received by themobile device 108, and/or a request for a log in to a web site provided by theauthentication provider 106. Other confirmation requests may also be used. A response to the confirmation request may be received atblock 712. For example, the confirmation request may be provided through themobile device 108 or to an agent speaking with the user of themobile device 108. - A determination may be made at
decision block 714 as to whether the response was successful. If a determination is made that the response was not successful, a notice of funding failure may be provided atblock 716. If a determination is made atdecision block 714 that the response was successful, thepayment account 116 is adjusted by the amount atblock 718 and a notice of funding success may be provided atblock 720. For example, adjusting thepayment account 116 may include adding or subtracting funds (e.g., money or other stored value) from thepayment account 116. -
FIG. 8 illustrates amethod 800 for processing payment authorization for thepayment account 116 according to an example embodiment. Themethod 800 may be performed at block 510 (seeFIG. 5 ) by theauthentication provider 106 or otherwise performed. - At
block 802, a funds adjustment request and the single use authentication code is received from thePOS device 110 through thepayment network 102. Thepayment account 116 is identified from the identifier related to the single use authentication code atblock 804. - A determination may be made at
decision block 806 as to whether a first user (e.g., a parent0 associated with thepayment account 116 has authorized adjustment by an amount indicated in the funds adjustment request for a second user (e.g., a child) associated with themobile device 108. If a determination is made that the payment account has not been authorized, a notice of funding failure may be provided atblock 808. If a determination is made atdecision block 806 that thepayment account 116 has been authorized, thepayment account 116 is adjusted by the amount atblock 810 and a notification of funding success may be provided atblock 812. -
FIG. 9 illustrates amethod 900 for funding authentication according to an example embodiment. Themethod 900 may be performed by the authentication provider 106 (seeFIG. 1 ) or another provider. - Account authorization for a second user may be received from a first user at
block 902. For example, a parent may provide account authorization for a child, a user may provide account authorization for a spouse, and the like. A request for funding authorization is received from the second user atblock 904. - An identifier of a first mobile device of a first user is accessed at
block 906. The identifier of the firstmobile device 108 may be associated with thepayment account 116 of the first user. - The identifier of the second mobile device of the second user may be accessed at
block 908. The identifier of the secondmobile device 108 may be associated with the payment account 118 of the second user. - A single use authentication code relating to the identifier of the first mobile device is generated at
block 910. The single use authentication code may be capable of being used to authenticate the secondmobile device 108 of the second user at thePOS device 110 and may enable a funds adjustment to thepayment account 116 of the first user. - In an example embodiment, the single use authentication code may related to the identifier of the first
mobile device 108 and the secondmobile device 108 and may be capable of being used to authenticate the secondmobile device 108 of the second user at thePOS device 110 and enable a funds adjustment to thepayment account 116 of the first user and/or or the second user. - The single use authentication code may be provided to the second
mobile device 108 through thecommunications network 104 at block 912. Payment authorization may be processed for the payment account atblock 914. For example, payment authorization may be processed according to themethods FIGS. 6-8 ). -
FIG. 10 illustrates amethod 1000 for processing payment authorization for thepayment account 116 according to an example embodiment. Themethod 1000 may be performed atblock 510 or block 912 (seeFIGS. 5 and 9 ) by theauthentication provider 106 or otherwise performed. - A funds adjustment request and a single use authentication code is received from the
POS device 110 through thepayment network 102 atblock 1002. Thepayment account 116 is identified from the identifier related to the single use authentication code atblock 1004. - A determination may be made at
decision block 1006 as to whether thepayment account 116 of the first user is adjustable by an amount indicated in the funds adjustment request. If the payment account of the first user is not adjustable by the amount, a notice of a failure of the funds adjustment request may be provided atblock 1008. If the payment account of the first user is adjustable by the amount, the payment account of the first user may be adjusted by the amount atblock 1010 and a notice of a success of the funds adjustment (e.g., the payment account has been adjusted by the amount) may be provided atblock 1012. - In an example embodiment, the
payment account 116 of the first user may be adjusted by a first portion of the amount and thepayment account 116 of the second user may be adjusted by a second portion of the amount. For example, the first portion may be a sum of money designated by the first user and the second portion may be a remaining portion of the amount not designated by the first user. -
FIG. 11 illustrates amethod 1100 for utilizing themobile device 108 according to an example embodiment. A funding request may be received from a user of themobile device 108 atblock 1102. Atblock 1104, funding authorization is requested from theauthentication provider 106 through themobile device 108. - A single use authentication code and an optional access code is received from the
authentication provider 106 atblock 1106. The single use authentication code may be capable of being used to authenticate themobile device 108 at thePOS device 110 and enable a funds adjustment to thepayment account 116. The access code may be capable of being used with a terminal of thePOS device 110 to authorize the funds adjustment. - The single use authentication code and an optional authorization routing number is provided through the
mobile device 108 to thePOS device 110 atblock 1108. The single use authentication code and an optional authorization routing number may be provided simultaneously or sequentially. The authorization routing number may be capable of being used to identify the authentication provider 106 (e.g., as a provider of the payment account 116). - In an example embodiment, the single use authentication code and the authorization routing number may be a virtual debit card number and the access code may be a pin number. The single use authentication code and the authorization routing number may be a credit debit card number and the access code is a card identification number or credit card security code. Other embodiments of the single use authentication code, the authorization routing number, and/or the access code may also be used.
- Authorization information may be presented on a display of the
mobile device 108 atblock 1110. For example, the presented authorization information may include the access code, the single use authentication code, and/or the authorization routing number. Other authorization information may also be presented. - In an example embodiment, a single use pattern may be generated from the single use authentication code and the authorization routing number and the single use pattern may be presented on the display of the
mobile device 108. The single use pattern may be capable of being scanned by thePOS device 110. The single use pattern may be a bar code or other type of cryptographic or non-cryptographic pattern. - A confirmation request may be received from the
authentication provider 106 atblock 1112. - The confirmation request may be presented on the
mobile device 108 atblock 1114. A response to the confirmation request may be received atblock 1116. The response to theauthentication provider 106 may be provided atblock 1118. A notification may be received from theauthentication provider 106 atblock 1120. -
FIG. 12 illustrates amethod 1200 for utilizing thePOS device 110 according to an example embodiment. A selection of one or more items may be received atblock 1202. A total for the selection may be generated atblock 1204. The total for the selection may be presented on a display of a point of sale (POS) device atblock 1206. - At
block 1208, a single use authentication code and an optional authorization routing number is received from themobile device 108. The single use authentication code and an optional authorization routing number may be received simultaneously or sequentially. The authorization routing number may be capable of being used to identify a provider of thepayment account 116. The receipt of the single use authentication code and the optional authorization routing number may enable authorization of a funds adjustment to be made. - In an example embodiment, a display of the
mobile device 108 may be scanned to receive the single use authentication code and an authorization routing number. The single use authentication code and an authorization routing number may be in the form of a single use pattern presented on the display of themobile device 108. The single use authentication code and an authorization routing number may be provided from themobile device 108 wirelessly (e.g., IR or RF), through a portable media card, or otherwise provided. - The payment network may be determined based on the authorization routing number at
block 1210. The single use authentication code and a funding request is provided over thepayment network 102 to theauthentication provider 106 atblock 1212. A funds adjustment related to the funding request is received from theauthentication provider 106 atblock 1214. -
FIG. 13 is a network diagram depicting a client-server system 1300, within which one example embodiment may be deployed. By way of example, anetwork 1304 may include the functionality of thecommunications network 104, theauthentication provider 106 may be deployed on theapplication server 1318 as apayment application 1322, aclient machine 1310 or aclient machine 1312 may include the functionality of themobile device 108, and adatabase 1326 may include the functionality of thedatabase 112. Thesystem 100 may also be deployed in other systems. - A
networked system 1302, in the example forms of a network-based marketplace or publication system, provides server-side functionality, via a network 1304 (e.g., the Internet or Wide Area Network (WAN)) to one or more clients.FIG. 13 illustrates, for example, a web client 1306 (e.g., a browser, such as the Internet Explorer browser developed by Microsoft Corporation of Redmond, Washington State), and aprogrammatic client 1308 executing onrespective client machines - An Application Program Interface (API)
server 1314 and aweb server 1316 are coupled to, and provide programmatic and web interfaces respectively to, one ormore application servers 1318. Theapplication servers 1318 host one ormore marketplace applications 1320 andauthentication providers 1322. Theapplication servers 1318 are, in turn, shown to be coupled to one ormore databases servers 1324 that facilitate access to one ormore databases 1326. - The
marketplace applications 1320 may provide a number of marketplace functions and services to users that access thenetworked system 1302. Theauthentication providers 1322 may likewise provide a number of payment services and functions to users. Theauthentication providers 1322 may allow users to accumulate value (e.g., in a commercial currency, such as the U.S. dollar, or a proprietary currency, such as “points”) in accounts, and then later to redeem the accumulated value for products (e.g., goods or services) that are made available via themarketplace applications 1320. While the marketplace andauthentication providers FIG. 13 to both form part of thenetworked system 1302, in alternative embodiments theauthentication providers 1322 may form part of a payment service that is separate and distinct from thenetworked system 1302. - Further, while the
system 1300 shown inFIG. 13 employs a client-server architecture, the present invention is of course not limited to such an architecture, and could equally well find application in a distributed, or peer-to-peer, architecture system, for example. The various marketplace andauthentication providers - The
web client 1306 accesses the various marketplace andauthentication providers web server 1316. Similarly, theprogrammatic client 1308 accesses the various services and functions provided by the marketplace andauthentication providers API server 1314. Theprogrammatic client 1308 may, for example, be a seller application (e.g., the TurboLister™ application developed by eBay Inc., of San Jose, Calif.) to enable sellers to author and manage listings on thenetworked system 1302 in an off-line manner, and to perform batch-mode communications between theprogrammatic client 1308 and thenetworked system 1302. -
FIG. 13 also illustrates athird party application 1328, executing on a thirdparty server machine 1330, as having programmatic access to thenetworked system 1302 via the programmatic interface provided by theAPI server 1314. For example, thethird party application 1328 may, utilizing information retrieved from thenetworked system 1302, support one or more features or functions on a website hosted by the third party. The third party may, for example, provide one or more promotional, marketplace or payment functions that are supported by the relevant applications of thenetworked system 1302. -
FIG. 14 is a block diagram illustratingmultiple applications FIG. 13 ). Theapplications 1320 may be hosted on dedicated or shared server machines (not shown) that are communicatively coupled to enable communications between server machines. The applications themselves are communicatively coupled (e.g., via appropriate interfaces) to each other and to various data sources, so as to allow information to be passed between the applications or so as to allow the applications to share and access common data. The applications may furthermore access one ormore databases 1326 via thedatabase servers 1324. - The
networked system 1302 may provide a number of publishing, listing and price-setting mechanisms whereby a seller may list (or publish information concerning) goods or services for sale, a buyer can express interest in or indicate a desire to purchase such goods or services, and a price can be set for a transaction pertaining to the goods or services. To this end, themarketplace applications 1320 are shown to include at least onepublication application 1400 and one ormore auction applications 1402 which support auction-format listing and price setting mechanisms (e.g., English, Dutch, Vickrey, Chinese, Double, Reverse auctions etc.). Thevarious auction applications 1402 may also provide a number of features in support of such auction-format listings, such as a reserve price feature whereby a seller may specify a reserve price in connection with a listing and a proxy-bidding feature whereby a bidder may invoke automated proxy bidding. - A number of fixed-
price applications 1404 support fixed-price listing formats (e.g., the traditional classified advertisement-type listing or a catalogue listing) and buyout-type listings. Specifically, buyout-type listings (e.g., including the Buy-It-Now (BIN) technology developed by eBay Inc., of San Jose, Calif.) may be offered in conjunction with auction-format listings, and allow a buyer to purchase goods or services, which are also being offered for sale via an auction, for a fixed-price that is typically higher than the starting price of the auction. -
Store applications 1406 allow a seller to group listings within a “virtual” store, which may be branded and otherwise personalized by and for the seller. Such a virtual store may also offer promotions, incentives and features that are specific and personalized to a relevant seller. -
Reputation applications 1408 allow users that transact, utilizing thenetworked system 1302, to establish, build and maintain reputations, which may be made available and published to potential trading partners. Consider that where, for example, thenetworked system 1302 supports person-to-person trading, users may otherwise have no history or other reference information whereby the trustworthiness and credibility of potential trading partners may be assessed. Thereputation applications 1408 allow a user, for example through feedback provided by other transaction partners, to establish a reputation within thenetworked system 1302 over time. Other potential trading partners may then reference such a reputation for the purposes of assessing credibility and trustworthiness. -
Personalization applications 1410 allow users of thenetworked system 1302 to personalize various aspects of their interactions with thenetworked system 1302. For example a user may, utilizing anappropriate personalization application 1410, create a personalized reference page at which information regarding transactions to which the user is (or has been) a party may be viewed. Further, apersonalization application 1410 may enable a user to personalize listings and other aspects of their interactions with thenetworked system 1302 and other parties. - The
networked system 1302 may support a number of marketplaces that are customized, for example, for specific geographic regions. A version of thenetworked system 1302 may be customized for the United Kingdom, whereas another version of thenetworked system 1302 may be customized for the United States. Each of these versions may operate as an independent marketplace, or may be customized (or internationalized and/or localized) presentations of a common underlying marketplace. Thenetworked system 1302 may accordingly include a number ofinternationalization applications 1412 that customize information (and/or the presentation of information) by thenetworked system 1302 according to predetermined criteria (e.g., geographic, demographic or marketplace criteria). For example, theinternationalization applications 1412 may be used to support the customization of information for a number of regional websites that are operated by thenetworked system 1302 and that are accessible viarespective web servers 1316. - Navigation of the
networked system 1302 may be facilitated by one ormore navigation applications 1414. For example, a search application (as an example of a navigation application) may enable key word searches of listings published via thenetworked system 1302. A browse application may allow users to browse various category, catalogue, or system inventory structures according to which listings may be classified within thenetworked system 1302. Various other navigation applications may be provided to supplement the search and browsing applications. - In order to make listings available via the
networked system 1302 as visually informing and attractive as possible, themarketplace applications 1320 may include one ormore imaging applications 1416 utilizing which users may upload images for inclusion within listings. Animaging application 1416 also operates to incorporate images within viewed listings. Theimaging applications 1416 may also support one or more promotional features, such as image galleries that are presented to potential buyers. For example, sellers may pay an additional fee to have an image included within a gallery of images for promoted items. -
Listing creation applications 1418 allow sellers conveniently to author listings pertaining to goods or services that they wish to transact via thenetworked system 1302, andlisting management applications 1420 allow sellers to manage such listings. Specifically, where a particular seller has authored and/or published a large number of listings, the management of such listings may present a challenge. Thelisting management applications 1420 provide a number of features (e.g., auto-relisting, inventory level monitors, etc.) to assist the seller in managing such listings. One or morepost-listing management applications 1422 also assist sellers with a number of activities that typically occur post-listing. For example, upon completion of an auction facilitated by one ormore auction applications 1402, a seller may wish to leave feedback regarding a particular buyer. To this end, apost-listing management application 1422 may provide an interface to one ormore reputation applications 1408, so as to allow the seller conveniently to provide feedback regarding multiple buyers to thereputation applications 1408. -
Dispute resolution applications 1424 provide mechanisms whereby disputes arising between transacting parties may be resolved. For example, thedispute resolution applications 1424 may provide guided procedures whereby the parties are guided through a number of steps in an attempt to settle a dispute. In the event that the dispute cannot be settled via the guided procedures, the dispute may be escalated to a merchant mediator or arbitrator. - A number of
fraud prevention applications 1426 implement fraud detection and prevention mechanisms to reduce the occurrence of fraud within thenetworked system 1302. -
Messaging applications 1428 are responsible for the generation and delivery of messages to users of thenetworked system 1302, such messages for example advising users regarding the status of listings at the networked system 1302 (e.g., providing “outbid” notices to bidders during an auction process or to provide promotional and merchandising information to users).Respective messaging applications 1428 may utilize any one have a number of message delivery networks and platforms to deliver messages to users. For example,messaging applications 1428 may deliver electronic mail (e-mail), instant message (IM), Short Message Service (SMS), text, facsimile, or voice (e.g., Voice over IP (VoIP)) messages via the wired (e.g., the Internet), Plain Old Telephone Service (POTS), or wireless (e.g., mobile, cellular, WiFi, WiMAX) networks. -
Merchandising applications 1430 support various merchandising functions that are made available to sellers to enable sellers to increase sales via thenetworked system 1302. Themerchandising applications 1430 also operate the various merchandising features that may be invoked by sellers, and may monitor and track the success of merchandising strategies employed by sellers. - The
networked system 1302 itself, or one or more parties that transact via thenetworked system 1302, may operate loyalty programs that are supported by one or more loyalty/promotions applications 1432. For example, a buyer may earn loyalty or promotions points for each transaction established and/or concluded with a particular seller, and may be offered a reward for which accumulated loyalty points can be redeemed. -
FIG. 15 shows a diagrammatic representation of machine in the example form of acomputer system 1500 within which a set of instructions may be executed causing the machine to perform any one or more of the methods, processes, operations, or methodologies discussed herein. Theauthentication provider 106 may operate on ormore computer systems 1500 and/or theauthentication provider 106, themobile device 108, and/or thePOS device 110 may include the functionality of thecomputer system 1500. - In an example embodiment, the machine operates as a standalone device or may be connected (e.g., networked) to other machines. In a networked deployment, the machine may operate in the capacity of a server or a client machine in server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine may be a server computer, a client computer, a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.
- The
example computer system 1500 includes a processor 1502 (e.g., a central processing unit (CPU) a graphics processing unit (GPU) or both), amain memory 1504 and astatic memory 1506, which communicate with each other via abus 1508. Thecomputer system 1500 may further include a video display unit 1510 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). Thecomputer system 1500 also includes an alphanumeric input device 1512 (e.g., a keyboard), a cursor control device 1514 (e.g., a mouse), adrive unit 1516, a signal generation device 1518 (e.g., a speaker) and anetwork interface device 1520. - The
drive unit 1516 includes a machine-readable medium 1522 on which is stored one or more sets of instructions (e.g., software 1524) embodying any one or more of the methodologies or functions described herein. Thesoftware 1524 may also reside, completely or at least partially, within themain memory 1504 and/or within theprocessor 1502 during execution thereof by thecomputer system 1500, themain memory 1504 and theprocessor 1502 also constituting machine-readable media. - The
software 1524 may further be transmitted or received over anetwork 1526 via thenetwork interface device 1520. - While the machine-
readable medium 1522 is shown in an example embodiment to be a single medium, the term “machine-readable medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term “machine-readable medium” shall also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present invention. The term “machine-readable medium” shall accordingly be taken to include, but not be limited to, solid-state memories, optical and magnetic media, and carrier wave signals. - Certain systems, apparatus, applications or processes are described herein as including a number of modules or mechanisms. A module or a mechanism may be a unit of distinct functionality that can provide information to, and receive information from, other modules. Accordingly, the described modules may be regarded as being communicatively coupled. Modules may also initiate communication with input or output devices, and can operate on a resource (e.g., a collection of information). The modules be implemented as hardware circuitry, optical components, single or multi-processor circuits, memory circuits, software program modules and objects, firmware, and combinations thereof, as appropriate for particular implementations of various embodiments.
- Thus, methods and systems for dynamic funding have been described. Although the present invention has been described with reference to specific example embodiments, it will be evident that various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of the invention. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.
- The Abstract of the Disclosure is provided to comply with 37 C.F.R. §1.72(b), requiring an abstract that will allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. In addition, in the foregoing Detailed Description, it can be seen that various features are grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separate embodiment.
Claims (1)
1. A method comprising:
accessing an identifier of a mobile device, the identifier associated with a payment account;
generating a single use authentication code relating to the identifier, the single use authentication code capable of being used to authenticate the mobile device at a point of sale (POS) device and enable a funds adjustment to the payment account; and
providing the single use authentication code to the mobile device through a communications network.
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US14/013,819 US20140006196A1 (en) | 2007-07-30 | 2013-08-29 | Method and system for dynamic funding |
US14/984,238 US20160110715A1 (en) | 2007-07-30 | 2015-12-30 | Method and system for dynamic funding |
US14/984,266 US20160117677A1 (en) | 2007-07-30 | 2015-12-30 | Method and system for dynamic funding |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/881,920 US8538819B2 (en) | 2007-07-30 | 2007-07-30 | Method and system for dynamic funding |
US14/013,819 US20140006196A1 (en) | 2007-07-30 | 2013-08-29 | Method and system for dynamic funding |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/881,920 Continuation US8538819B2 (en) | 2007-07-30 | 2007-07-30 | Method and system for dynamic funding |
Related Child Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/984,238 Continuation US20160110715A1 (en) | 2007-07-30 | 2015-12-30 | Method and system for dynamic funding |
US14/984,266 Continuation US20160117677A1 (en) | 2007-07-30 | 2015-12-30 | Method and system for dynamic funding |
Publications (1)
Publication Number | Publication Date |
---|---|
US20140006196A1 true US20140006196A1 (en) | 2014-01-02 |
Family
ID=40304669
Family Applications (4)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/881,920 Active 2031-07-22 US8538819B2 (en) | 2007-07-30 | 2007-07-30 | Method and system for dynamic funding |
US14/013,819 Abandoned US20140006196A1 (en) | 2007-07-30 | 2013-08-29 | Method and system for dynamic funding |
US14/984,238 Abandoned US20160110715A1 (en) | 2007-07-30 | 2015-12-30 | Method and system for dynamic funding |
US14/984,266 Abandoned US20160117677A1 (en) | 2007-07-30 | 2015-12-30 | Method and system for dynamic funding |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/881,920 Active 2031-07-22 US8538819B2 (en) | 2007-07-30 | 2007-07-30 | Method and system for dynamic funding |
Family Applications After (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/984,238 Abandoned US20160110715A1 (en) | 2007-07-30 | 2015-12-30 | Method and system for dynamic funding |
US14/984,266 Abandoned US20160117677A1 (en) | 2007-07-30 | 2015-12-30 | Method and system for dynamic funding |
Country Status (2)
Country | Link |
---|---|
US (4) | US8538819B2 (en) |
WO (1) | WO2009017754A1 (en) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2015195176A1 (en) * | 2014-06-20 | 2015-12-23 | Ebay Inc. | Two factor authentication for invoicing payments |
JP6487091B1 (en) * | 2018-03-29 | 2019-03-20 | 株式会社電通 | ICO management method, communication device, ICO management system and program |
Families Citing this family (33)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8538819B2 (en) | 2007-07-30 | 2013-09-17 | Ebay Inc. | Method and system for dynamic funding |
US9098844B2 (en) | 2007-11-20 | 2015-08-04 | Wells Fargo Bank, N.A. | Mobile electronic wallet |
US20090254479A1 (en) * | 2008-04-02 | 2009-10-08 | Pharris Dennis J | Transaction server configured to authorize payment transactions using mobile telephone devices |
US8423457B1 (en) * | 2009-04-13 | 2013-04-16 | Amazon Technologies, Inc. | Anonymous mobile payments |
US20110153380A1 (en) * | 2009-12-22 | 2011-06-23 | Verizon Patent And Licensing Inc. | Method and system of automated appointment management |
US20110196782A1 (en) * | 2010-02-05 | 2011-08-11 | Bank Of America Corporation | Transferring Funds Using Mobile Devices |
BR112012022785A2 (en) * | 2010-03-08 | 2016-06-14 | Telefonica Sa | method and system for performing a transaction |
US8571939B2 (en) | 2010-07-07 | 2013-10-29 | Toshiba Global Commerce Solutions Holdings Corporation | Two phase payment link and authorization for mobile devices |
US20120136796A1 (en) * | 2010-09-21 | 2012-05-31 | Ayman Hammad | Device Enrollment System and Method |
US9558481B2 (en) * | 2010-09-28 | 2017-01-31 | Barclays Bank Plc | Secure account provisioning |
US9607293B2 (en) * | 2010-11-29 | 2017-03-28 | Barclays Bank Plc | Method and system for account management and electronic wallet access on a mobile device |
DE102011079317A1 (en) * | 2011-07-18 | 2013-01-24 | QMT GbR (vertretungsberechtigter Gesellschafter: Christian Roth, 88239 Wangen) | MOBILE SYSTEM FOR FINANCIAL TRANSACTIONS |
US8554671B2 (en) * | 2011-07-18 | 2013-10-08 | Rabih Salem Ballout | System and associated method and service for providing a platform that allows for the exchange of cash between members in a mobile environment |
EP2737444A4 (en) * | 2011-07-28 | 2014-11-26 | Upc Konsultointi Oy | Offline transaction |
AU2015100744B4 (en) * | 2011-08-30 | 2015-08-06 | Ov Loop Inc. | Systems and methods for authorizing a transaction with an unexpected cryptogram |
CN104025137B (en) * | 2011-08-30 | 2019-05-03 | D·耶格尔 | System and method for authorizing the transaction using not expectable password |
US20130197968A1 (en) * | 2011-09-24 | 2013-08-01 | Elwha LLC, a limited liability corporation of the State of Delaware | Behavioral fingerprinting with retail monitoring |
US9825967B2 (en) | 2011-09-24 | 2017-11-21 | Elwha Llc | Behavioral fingerprinting via social networking interaction |
US9729549B2 (en) | 2011-09-24 | 2017-08-08 | Elwha Llc | Behavioral fingerprinting with adaptive development |
US9621404B2 (en) | 2011-09-24 | 2017-04-11 | Elwha Llc | Behavioral fingerprinting with social networking |
US20130097079A1 (en) * | 2011-10-18 | 2013-04-18 | Felix Bruder | Enabling payment for items using a mobile device |
US20130347013A1 (en) * | 2012-06-22 | 2013-12-26 | Ebay Inc. | Interactive television shopping via a payment provider |
US10223688B2 (en) | 2012-09-24 | 2019-03-05 | Samsung Electronics Co., Ltd. | Competing mobile payment offers |
US9619799B2 (en) | 2013-02-06 | 2017-04-11 | Apple Inc. | Apparatus and methods for secure element transactions and management of assets |
US20140279566A1 (en) * | 2013-03-15 | 2014-09-18 | Samsung Electronics Co., Ltd. | Secure mobile payment using media binding |
US20150006388A1 (en) * | 2013-03-15 | 2015-01-01 | Paul Myers | Electronic payment systems and methods involving a mobile device |
GB2512944A (en) * | 2013-04-12 | 2014-10-15 | Mastercard International Inc | Systems and methods for outputting information on a display of a mobile device |
US9875468B2 (en) | 2014-11-26 | 2018-01-23 | Buy It Mobility Networks Inc. | Intelligent authentication process |
DE102015006751A1 (en) * | 2015-05-26 | 2016-12-01 | Giesecke & Devrient Gmbh | Method for providing a personal identification code of a security module |
US11657386B2 (en) * | 2015-08-21 | 2023-05-23 | Samsung Electronics Co., Ltd. | Reference-based card enrollment for secondary devices |
CN108428127A (en) * | 2018-03-14 | 2018-08-21 | 杭州蓝魔网络科技有限公司 | A kind of intelligence POS machine form ordering system and its method |
US10990947B2 (en) * | 2019-09-16 | 2021-04-27 | The Toronto-Dominion Bank | Point-of-sale device and method for generating a discounted authorization request |
US20220217136A1 (en) * | 2021-01-04 | 2022-07-07 | Bank Of America Corporation | Identity verification through multisystem cooperation |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030230630A1 (en) * | 2001-12-20 | 2003-12-18 | Whipple Larry Cale | Using mobile electronic devices to transfer data through dynamically generated scannable barcode images |
US20040030601A1 (en) * | 2000-09-29 | 2004-02-12 | Pond Russell L. | Electronic payment methods for a mobile device |
US20060269061A1 (en) * | 2001-01-11 | 2006-11-30 | Cardinalcommerce Corporation | Mobile device and method for dispensing authentication codes |
US7312707B1 (en) * | 2001-07-10 | 2007-12-25 | American Express Travel Related Services Company, Inc. | System and method for authenticating a RF transaction using a transaction account routing number |
US20080046366A1 (en) * | 2006-06-29 | 2008-02-21 | Vincent Bemmel | Method and system for providing biometric authentication at a point-of-sale via a mobile device |
US20080210754A1 (en) * | 2005-06-13 | 2008-09-04 | Robert Lovett | Account payment using barcode information exchange |
Family Cites Families (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
IL134741A (en) * | 2000-02-27 | 2003-11-23 | Adamtech Ltd | Mobile transaction system and method |
WO2004092993A1 (en) * | 2003-04-09 | 2004-10-28 | Gtech Rhode Island Corporation | Electronic payment system |
US7124937B2 (en) * | 2005-01-21 | 2006-10-24 | Visa U.S.A. Inc. | Wireless payment methods and systems |
US8762263B2 (en) * | 2005-09-06 | 2014-06-24 | Visa U.S.A. Inc. | System and method for secured account numbers in proximity devices |
US8538819B2 (en) | 2007-07-30 | 2013-09-17 | Ebay Inc. | Method and system for dynamic funding |
-
2007
- 2007-07-30 US US11/881,920 patent/US8538819B2/en active Active
-
2008
- 2008-07-30 WO PCT/US2008/009200 patent/WO2009017754A1/en active Application Filing
-
2013
- 2013-08-29 US US14/013,819 patent/US20140006196A1/en not_active Abandoned
-
2015
- 2015-12-30 US US14/984,238 patent/US20160110715A1/en not_active Abandoned
- 2015-12-30 US US14/984,266 patent/US20160117677A1/en not_active Abandoned
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20040030601A1 (en) * | 2000-09-29 | 2004-02-12 | Pond Russell L. | Electronic payment methods for a mobile device |
US20060269061A1 (en) * | 2001-01-11 | 2006-11-30 | Cardinalcommerce Corporation | Mobile device and method for dispensing authentication codes |
US7312707B1 (en) * | 2001-07-10 | 2007-12-25 | American Express Travel Related Services Company, Inc. | System and method for authenticating a RF transaction using a transaction account routing number |
US20030230630A1 (en) * | 2001-12-20 | 2003-12-18 | Whipple Larry Cale | Using mobile electronic devices to transfer data through dynamically generated scannable barcode images |
US20080210754A1 (en) * | 2005-06-13 | 2008-09-04 | Robert Lovett | Account payment using barcode information exchange |
US20080046366A1 (en) * | 2006-06-29 | 2008-02-21 | Vincent Bemmel | Method and system for providing biometric authentication at a point-of-sale via a mobile device |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2015195176A1 (en) * | 2014-06-20 | 2015-12-23 | Ebay Inc. | Two factor authentication for invoicing payments |
JP6487091B1 (en) * | 2018-03-29 | 2019-03-20 | 株式会社電通 | ICO management method, communication device, ICO management system and program |
JP2019175249A (en) * | 2018-03-29 | 2019-10-10 | 株式会社電通 | ICO management method, communication device, ICO management system and program |
Also Published As
Publication number | Publication date |
---|---|
US20160117677A1 (en) | 2016-04-28 |
WO2009017754A1 (en) | 2009-02-05 |
US20090037285A1 (en) | 2009-02-05 |
US8538819B2 (en) | 2013-09-17 |
US20160110715A1 (en) | 2016-04-21 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8538819B2 (en) | Method and system for dynamic funding | |
US20200226565A1 (en) | Payment transactions via substantially instant communication system | |
US8108278B2 (en) | Non-reversible payment processing | |
US8112431B2 (en) | Method and system for processing search requests | |
US7860784B2 (en) | Method and system for user payment account management | |
US8844002B2 (en) | Method and system for notification and request processing | |
US20080162295A1 (en) | Method and system for payment authentication | |
US20090265252A1 (en) | Money pooling with electronic invoice | |
US20080133390A1 (en) | System and method for authorizing a transaction | |
US20090271313A1 (en) | Method and system for balance account utilization | |
US20160162851A1 (en) | Method and system for processing transfer requests | |
US20100121649A1 (en) | Methods and systems for user registration | |
US20090265262A1 (en) | Method and system for installment payment utilization | |
US20100082354A1 (en) | User definition and identification | |
US20120054321A1 (en) | Method and system to deliver a digital good | |
US20110119069A1 (en) | Methods and systems for recurring feature subscription service | |
US20090254470A1 (en) | Method and system for sharing searches | |
US10015240B2 (en) | Method and system for interface data utilization | |
CA2704095C (en) | Methods and systems for recurring feature subscription service | |
US20150286999A1 (en) | Method and system for transaction processing | |
Woessner | i, United States Patent (10) Patent No.: US 8,844,002 B2 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: EBAY INC., CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:MURPHY, TIMOTHY M.;REEL/FRAME:031112/0126 Effective date: 20070730 |
|
AS | Assignment |
Owner name: PAYPAL, INC., CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:EBAY INC.;REEL/FRAME:036170/0289 Effective date: 20150717 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |