WO2014182785A1 - Prévention de fraude pour les transactions - Google Patents

Prévention de fraude pour les transactions Download PDF

Info

Publication number
WO2014182785A1
WO2014182785A1 PCT/US2014/037103 US2014037103W WO2014182785A1 WO 2014182785 A1 WO2014182785 A1 WO 2014182785A1 US 2014037103 W US2014037103 W US 2014037103W WO 2014182785 A1 WO2014182785 A1 WO 2014182785A1
Authority
WO
WIPO (PCT)
Prior art keywords
user
transaction
payment
payment source
authenticating device
Prior art date
Application number
PCT/US2014/037103
Other languages
English (en)
Inventor
Ramalingam Krishnamurthi Anand
Original Assignee
Ramalingam Krishnamurthi Anand
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US13/889,242 external-priority patent/US9245261B2/en
Priority claimed from US13/893,165 external-priority patent/US20140337216A1/en
Priority claimed from US14/024,421 external-priority patent/US9020859B2/en
Application filed by Ramalingam Krishnamurthi Anand filed Critical Ramalingam Krishnamurthi Anand
Publication of WO2014182785A1 publication Critical patent/WO2014182785A1/fr

Links

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/4016—Transaction verification involving fraud or risk level assessment in transaction processing
    • 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/38—Payment protocols; Details thereof
    • G06Q20/389—Keeping log of transactions for guaranteeing non-repudiation of a transaction

Definitions

  • This specification relates to electronic transactions.
  • POS point-of-sale
  • ATMs Automatic Teller Machines
  • a transaction can occur, for example, when a user makes a purchase of goods (e.g., products) or services (e.g., rentals).
  • Fraudulent transactions arise when, for example, the user did not actually make the purchase, the user's payment source was compromised, the user's account or other payment-related information was erroneously used, or when other misuse occurs.
  • the detection of fraudulent (i.e., at the moment of the occurrence of the fraud) activity can be difficult.
  • a computer-implemented method includes receiving, during registering, registration information for a user, including receiving an identity of the user, an identifier for an authenticating device, and a payment source identifier.
  • the method includes storing the registration information and receiving a payment authorization request relating to a transaction purported to be by the user.
  • the payment authorization request includes the payment source identifier and transaction details including a transaction amount and information describing one or more details of the transaction.
  • the method further includes using the payment source identifier, identifying the user including retrieving the identity of the user and the identifier for the authenticating device and providing a communication to the user including creating a message including transaction information and delivering the message to the user at the authenticating device.
  • the method further includes receiving either a payment authorization or a payment repudiation responsive to the communication from the user by way of the authenticating device and providing either a payment authorization or a payment repudiation responsive to the payment authorization request.
  • the payment source identifier can be a credit card number or a debit card number.
  • the Attorney Docket No. 38060-0003WO1 authenticating device can be a mobile telephone or a mobile computing device.
  • the identity of the user can be an identifier created by the user at registration. Storing the registration information can include storing the registration information in a data structure indexed by payment source identifier.
  • the method can further include presenting by the user the payment source identifier to a merchant either online or at a brick-and-mortar presence for the transaction, and wherein, prior to the merchant receiving confirmation of the transaction, providing the communication to the user.
  • Providing the communication to the user can include providing either a telephone message, a text message, or an email message to the user, including transaction details.
  • Receiving registration information includes receiving or setting a default transaction limit, and wherein communicating with the user only occurs when the transaction is above the default transaction limit.
  • the method can further include evaluating the received payment authorization request, determining the default transaction limit associated with the user, and approving the transaction responsive to the payment authorization request when the transaction amount is less than the default transaction limit.
  • Providing a communication to the user can include presenting a user interface to the user on the authenticating device that includes information for the transaction.
  • the information for the transaction can include transaction amount, a transaction date and time, a transaction location, a merchant name and a control for selection by the user to either accept or repudiate the transaction.
  • the method can include providing an alert to a sponsor of the payment source indicating the repudiation or providing a follow up message to the user on the authenticating device including a control for linking the user to a payment source sponsor to enable further action related to the payment source.
  • the further action can be the cancelling of the payment source or the suspension of payment source.
  • the method can include adding the merchant associated with the transaction to a list of disapproved merchants and using the list of disapproved merchants to either automatically repudiate future transactions or to alert the user of prior repudiated transactions when communicating to the user about a pending transaction.
  • the payment source identifier can be a checking or savings account number.
  • the transaction can be an automated clearing house (ACH) transaction.
  • the registering can be performed with a payment source sponsor or with a clearing house associated with the payment source.
  • the method can further include determining when a payment authorization or repudiation has been provided, and when not provided within a predetermined amount of time since providing the communication, automatically authorizing the transaction when the transaction amount is less than a predetermined amount or is a common transaction.
  • the method can further include identifying common transactions including identifying the transaction as common when a user has historically made transactions with a same merchant for similar amounts in a recent past.
  • the predetermined amount can be set based on a location or activity of the user.
  • the method can further include separately authorizing the transaction using a clearing service.
  • the authenticating device can be a mobile electronic device and the payment source can be a credit card or debit card, the method can further include inhibiting the transaction when a user fails to present both the payment source and a payment authorization as displayed on the authenticating device.
  • the method can further include determining a location associated with an authenticating device and a location associated with the transaction and automatically approving a given transaction without requiring separate acceptance or repudiation when the distance between the two locations is less than a predetermined amount.
  • Particular implementations may realize none, one or more of the following advantages.
  • Users can register to receive notifications of payments that are associated with payment methods and devices for which they have registered. Because the authorizations are received in near real-time, users can authorize or repudiate a particular individual transaction. A user can suspend or cancel a payment method, e.g., if the user suspects fraudulent activity involving their accounts.
  • Authentication of user transactions can use a two- or multi-factor authentication process. For example, transaction success can be based at least in part on actions performed on a mobile device independent of and unconnected to a physical credit/debit/check card or other payment source.
  • FIG. 1 is a block diagram of an example environment for fraud prevention involving payment-related transactions.
  • FIG. 2 is a flowchart of an example process for authorization or repudiation of a payment associated with a user.
  • FIG. 3 is a block diagram of an example computer system that can be used to implement the methods, systems and processes described in this disclosure.
  • a user can register for a service for preventing fraud on accounts that are associated with the user.
  • the registration can include user identification of a payment source identifier, such as a credit or debit card number, a checking or savings account number, or information for some other payment source.
  • the user can also designate an authentication device that is a device that will be communicated with (e.g., provided with notifications) in order to authenticate transactions associated with registered payment sources.
  • an authentication device e.g., provided with notifications
  • payment-related or withdrawal-related transactions that are associated with the user's payment sources can occur.
  • the user can receive a notification that includes information obtained from a corresponding payment/debit/withdrawal transaction.
  • the notification can be to the authentication device that is designated by the user.
  • the user can either authorize or repudiate the payment.
  • Other user actions and/or options are possible.
  • FIG. 1 is a block diagram of an example environment 100 for fraud prevention involving payment-related transactions.
  • the example environment 100 includes at least one payment system 108 (e.g., a point-of-sale (POS) system) and at least one authentication Attorney Docket No. 38060-0003WO1 device (e.g., mobile device 106).
  • the example environment 100 further includes a central server 104 for registering users 101, receiving and processing payment authorization requests 112, providing payment authorization notification 114 to users 101, receiving payment authorizations 116a and payment repudiations 116b from users, and providing payment authorizations 118a and payment repudiations 118b (e.g., to payment systems 108 and/or other systems).
  • POS point-of-sale
  • the example environment 100 further includes a central server 104 for registering users 101, receiving and processing payment authorization requests 112, providing payment authorization notification 114 to users 101, receiving payment authorizations 116a and payment repudiations 116b from users, and providing payment authorizations 118a and payment
  • the example environment 100 includes a secure network/s 102, such as a local area network (LAN), a wide area network (WAN), the Internet, or a combination thereof.
  • the network/s 102 connects the payment systems 108, mobile devices 106, the central server 104 and other systems that may interact with the payment systems 108, the mobile devices 106, and the central server 104.
  • the example environment 100 may include many thousands of payment systems 108 and mobile devices 106. While the examples in this disclosure generally discuss mobile devices (e.g., mobile device 106), the systems, mechanisms and methods described herein can also use, or apply to, other authentication devices including non-mobile devices.
  • the central server 104 can include plural engines.
  • a registration engine 130 can receive registration information 110 from the mobile devices 106.
  • the registration information 110 can include an identity of the user (e.g., user name, etc.), an identifier for an authenticating device (e.g. that identifies the mobile device 106), and a payment source identifier, such as a credit card number, account number or other payment source for the user 101.
  • the registration engine 130 can store and access user registration information in a data store of user registrations 140.
  • a request processing engine 132 can process payment authorization requests 112 received by the central server 104.
  • Each payment authorization request 112 can be associated with a payment-related transaction purported to be by (or associated with) the user 101.
  • Each payment authorization request 112 can include at least a payment source identifier and transaction details, including a transaction amount and information describing one or more details of the transaction.
  • a user identification engine 134 can use user-related information from the payment authorization request 112 to identify a user (e.g., the user 101) that is associated with a corresponding transaction. Identification of the user 101 can be facilitated, for Attorney Docket No. 38060-0003WO1 example, by matching user-related information in the payment authorization request 112 with information in the user registrations 140.
  • a notification engine 136 can create notifications to be provided to the user 101.
  • the payment authorization notification 114 can include a communication that is provided to the user 101.
  • the communication can include transaction information and can be delivered to the user 101 at the authentication device (e.g., the mobile device 106).
  • An authorization engine 138 can process payment authorizations 116a and payment repudiations 116b received from users.
  • the payment authorizations 116a and the payment repudiations 116b can be stored in a data store of payment
  • the authorization engine 138 can also provide payment authorization and/or repudiation information to systems outside of the client server 104, such as payment authorizations 118a and payment repudiations 118b that are provided to payment systems 108 or other systems.
  • FIG. 2 is a flowchart of an example process 200 for authorization or repudiation of a payment associated with a user.
  • the central server 104 and/or its components can perform stages of the process 200 using instructions that are executed by one or more processors.
  • FIG. 1 is used to provide example structures for performing the stages of the process 200.
  • Registration information for a user is received, including an identity of the user, an identifier for an authenticating device, and a payment source identifier (202).
  • the central server 104 can receive registration information 110 from the mobile device 106.
  • the registration information 110 can include, for example, a user name or other user identification information for the user 101, a device identifier for registering the mobile device 106 with the central server 104, and credit card and/or payment source information.
  • the registration engine 130 can process the received registration information 110 to ensure that the information is complete.
  • the payment source identifier can be a credit card number or a debit card number.
  • the user 101 when the user 101 registers, the user 101 can provide credit card information that identifies a name, a credit card number, an expiration date, billing information, and/or other information associated with a credit card or debit card.
  • the payment source identifier can be a checking or savings account number.
  • the user 101 can designate checking, savings or other bank account numbers associated with payment-related transactions, e.g., from which to draw funds to complete a purchase transaction.
  • the authenticating device can be a mobile telephone or a mobile computing device.
  • registration information that the user 101 includes during the registration process can include at least one computer device (e.g., the mobile device 106) to which notifications of payment transactions are to be sent for review by the user 101.
  • the identity of the user can be an identifier created by the user at registration.
  • the user 101 can provide a user identifier or other identifier that is used for registration purposes and which may or may not be the user's name or include an email address or other user-unique information.
  • the registering can be performed with a payment source sponsor.
  • the user 101 can complete the registration process while accessing a web site associated with a credit card company, such as at the same time or a different time that a purchase is being made.
  • registering can be performed with a clearing house or association associated with the payment source.
  • the user 101 can complete the registration process while accessing a web site associated with a clearing house or association associated with credit/debit card transactions.
  • the registration information is stored (204).
  • the registration engine 130 can store the registration information 110 in the user registrations 140, which may store multiple registrations for the user 101 and other users.
  • storing the registration information can include storing the registration information in a data structure indexed by payment source identifier.
  • the registration engine 130 can store information from the registration information 110 in the user registrations 140, which can be indexed by payment source identifier (e.g., credit card number, etc.).
  • a payment authorization request is received that relates to a transaction purported to be by the user (206).
  • the payment authorization request includes the payment source Attorney Docket No. 38060-0003WO1 identifier and transaction details, including a transaction amount and information describing one or more details of the transaction.
  • the central server 104 can receive a payment authorization request 112 from the payment system 108 or some other payment system.
  • the payment authorization request 112 can be related to a transaction that is purported to be by the user 101, such as a point-of-sale transaction, online purchase (e.g., a camera purchase on a camera-selling website), or some other transaction.
  • the payment authorization request 112 can include the payment source identifier (e.g., credit card number associated with the user 101) and transaction details, including a transaction amount (e.g., purchase amount) and information describing one or more details of the transaction (e.g., camera model purchased).
  • a request processing engine 132 can process the payment authorization request 112.
  • the transaction can be an automated clearing house (ACH) transaction.
  • ACH automated clearing house
  • the transaction can be an automatic transfer of funds associated with the user, such as a monthly payment for a loan, utility or other regular payment.
  • the user is identified, including retrieving the identity of the user and the identifier for the authenticating device (208).
  • the user identification engine 134 can use a credit card number that is included in the payment authorization request 112 to identify the user 101 as the user who is associated with the transaction.
  • the identification can include looking up information for the user 101 in the user registrations 140, e.g., using the credit card number from the transaction to identify the user 101 and the mobile device 106.
  • a notification is created that includes transaction information, and the notification is delivered to the user at the authenticating device (210).
  • the notification engine 136 can create the payment authorization notification 114, which the content server 104 can provide to the mobile device 106 for presentation to the user 101.
  • the notification for example, can identify a transaction involving the camera purchase on a camera-selling website.
  • the payment source identifier can be presented by the user to a merchant either online or at a brick-and-mortar presence for the transaction, and prior to the merchant receiving confirmation of the transaction, the communication can be Attorney Docket No. 38060-0003WO1 provided to the user.
  • the user can provide a credit card number or other payment source identifier while making a purchase on a website or at a physical store.
  • the payment authorization notification 114 can be provided to the user 101 (for review and handling by the user 101) before the merchant receives confirmation of the purchase information.
  • providing the communication to the user can include providing a telephone message, a text message, or an email message to the user, including transaction details.
  • the user can receive the payment authorization notification 114 in the form of a telephone call, a voice message, or a text message sent to the mobile device 106.
  • the payment authorization notification 114 can be in the form of an email message that is sent to an email account for the user 101, e.g., that is accessible using the mobile device 106.
  • Other forms of communication can be used, and multiple forms can be used for any one payment authorization notification 114, e.g., depending on user settings specified during registration.
  • providing a communication to the user can include presenting a user interface to the user on the authenticating device that includes information for the transaction.
  • the central server 104 can provide the payment
  • information for the transaction can include a transaction amount, a transaction date and time, a transaction location, a merchant name, and a control for selection by the user to either accept or repudiate the transaction.
  • the payment authorization notification 114 can identify a dollar (or any other currency amount) amount of the purchase or payment, the time and date that the purchase was made, a website name and/or physical address of the entity to which the payment is made, a company name, and one or more user interface controls for either accepting or repudiating the transaction.
  • receiving registration information can include receiving or setting a default transaction limit, and communicating with the user may occur only when the transaction is above the default transaction limit.
  • the user 101 can specify a dollar (a currency threshold) amount, and transactions having amounts exceeding the specified dollar amount are to be communicated to the user.
  • the received payment authorization request is evaluated, the default transaction limit associated with the user is determined, and the transaction responsive to the payment authorization request is approved when the transaction amount is less than the default transaction limit.
  • transactions involving amounts not exceeding the limit are to be authorized automatically, e.g., without user intervention (but can still be rapidly reported to the user).
  • Either a payment authorization or a payment repudiation response to the communication is received from the user by way of the authenticating device (212).
  • the user can use controls (e.g., in a payment authorization application (sometimes referred to as Mobile App) or other suitable interface) on the mobile device 106 to authorize or repudiate the payment.
  • a payment authorization application sometimes referred to as Mobile App
  • the payment authorization application for example, on the mobile device 106 can produce the corresponding one of either the payment authorization 116a or the payment repudiation 116b to be received by the central server 104.
  • an alert is provided to a sponsor of the payment source indicating the repudiation.
  • a sponsor of the payment source indicating the repudiation.
  • the central server 104 can provide an alert identifying the repudiation to the user's bank, credit card company or other payment source sponsor associated with the user's account, credit/debit card or other payment method.
  • an alert is provided to the merchant indicating the repudiation. This could allow the merchant to take further actions - including stopping the merchandise from being given to fraudulent buyer and/or informing law enforcement of the incident.
  • a follow- up message is provided to the user on the authenticating device, including a control for linking the user to a payment source sponsor to enable further action related to the payment source.
  • a payment source sponsor e.g., credit card company's
  • further actions can include, for Attorney Docket No. 38060-0003WO1 example, cancelling the payment source (e.g., credit card), suspending the payment source, or some other action related to the payment source.
  • the merchant associated with the transaction is added to a list of disapproved merchants, and the process 200 further includes using the list of disapproved merchants to either automatically repudiate future transactions or to alert the user of prior repudiated transactions when communicating to the user about a pending transaction.
  • a specific camera- selling website can be added to a list (e.g., a blacklist) of merchants and/or websites that are disapproved by the user 101.
  • Either a payment authorization or a payment repudiation responsive to the payment authorization request is provided (214).
  • the authorization engine 138 can provide the corresponding one of either the payment authorization 118a or the payment repudiation 118b to the payment system 108 and/or other systems.
  • the process 200 can further include determining when a payment authorization or repudiation has been provided, and when not provided within a predetermined amount of time since providing the communication, automatically authorizing the transaction when the transaction amount is less than a predetermined amount or is a common transaction. For example, for any given payment authorization request 112 and subsequent payment authorization notification 114, the central server 104 can automatically authorize the corresponding purchase if a pre-determined time (e.g., two minutes) expires and no authorization or repudiation is received from the user 101.
  • a pre-determined time e.g., two minutes
  • the central server 104 can automatically authorize the corresponding purchase if the transaction amount is less than a predetermined amount (e.g., under $100) or is a common transaction (e.g., a recurring payment for loan or utility).
  • a predetermined amount can be set based on a location or activity of the user. For example, a predetermined amount (e.g., under $200) can be established for a specific location such as a grocery store or other place (e.g., online or brick-and-mortar location) at which the user makes regular purchases.
  • predetermined amounts can be tied to particular activities, such as buying groceries, buying gasoline, eating at a restaurant, or other identifiable and/or regular activities.
  • the process 200 can further include identifying common transactions, including identifying the transaction as common when a user has historically made transactions with a same merchant for similar amounts in a recent past.
  • the central server 104 can identify a transaction as similar to previous transactions for the same user 101 if the merchant is the same between a pending transaction and previous transactions between the user 101 and the merchant.
  • Common transactions can include, for example, weekly purchases at a grocery store, monthly automatic drafts to utilities or clubs, or other payments that the user 101 may make on a regular basis.
  • the process 200 can further include separately authorizing the transaction using a clearing service.
  • the user 101 can set up certain types of transactions to be automatically cleared, e.g., if the transactions are regular (e.g., monthly) transactions.
  • the authenticating device can be a mobile electronic device
  • the payment source can be a credit card or debit card
  • the process 200 can further include inhibiting the transaction when a user fails to present both the payment source and a payment authorization as displayed on the authenticating device.
  • the central server 104 can enforce a rule that transactions cannot occur unless the user 101 uses one of one or more designated payment sources (e.g., specific credit cards) and shows the merchant a displayed authorization on a specified device (e.g., the user's mobile device 106). The user 101 can specific such a rule, for example, during registration.
  • providing a communication to the user can be based at least in part on whether the authenticating device is within a threshold distance of a location associated with the purchase.
  • central server 104 can generate a payment authorization notification 114 if a global positioning system (GPS) location (e.g., GPS) location.
  • GPS global positioning system
  • a distance threshold e.g., ten miles
  • the transaction can be approved automatically.
  • the distance difference of the transaction can trigger generation of the payment authorization notification 114 for acceptance from the user of either a payment authorization 116a or a payment repudiation 116b.
  • FIG. 3 is a block diagram of example computing devices 300, 350 that may be used to implement the systems and methods described in this document, as either a client or as a server or plurality of servers.
  • Computing device 300 is intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers.
  • Computing device 300 is further intended to represent any other typically non-mobile devices, such as televisions or other electronic devices with one or more processers embedded therein or attached thereto.
  • Computing device 350 is intended to represent various forms of mobile devices, such as personal digital assistants, cellular telephones, smartphones, and other computing devices.
  • the components shown here, their connections and relationships, and their functions, are meant to be examples only, and are not meant to limit implementations of the inventions described and/or claimed in this document.
  • Computing device 300 includes a processor 302, memory 304, a storage device 306, a high-speed interface 308 connecting to memory 304 and high-speed expansion ports 310, and a low speed interface 312 connecting to low speed bus 314 and storage device 306.
  • Each of the components 302, 304, 306, 308, 310, and 312, are interconnected using various busses, and may be mounted on a common motherboard or in other manners as appropriate.
  • the processor 302 can process instructions for execution within the computing device 300, including instructions stored in the memory 304 or on the storage device 306 to display graphical information for a GUI on an external input/output device, such as display 316 coupled to high speed interface 308.
  • multiple processors and/or multiple buses may be used, as appropriate, along with multiple memories and types of memory.
  • multiple computing devices 300 may be connected, with each device providing portions of the necessary operations (e.g., as a server bank, a group of blade servers, or a multi-processor system).
  • the memory 304 stores information within the computing device 300.
  • the memory 304 is a computer-readable medium.
  • the memory 304 is a volatile memory unit or units.
  • the memory 304 is a non-volatile memory unit or units.
  • the storage device 306 is capable of providing mass storage for the computing device 300.
  • the storage device 306 is a computer-readable medium. Attorney Docket No. 38060-0003WO1
  • the storage device 306 may be a floppy disk device, a hard disk device, an optical disk device, or a tape device, a flash memory or other similar solid state memory device, or an array of devices, including devices in a storage area network or other configurations.
  • a computer program product is tangibly embodied in an information carrier.
  • the computer program product contains instructions that, when executed, perform one or more methods, such as those described above.
  • the information carrier is a computer- or machine-readable medium, such as the memory 304, the storage device 306, or memory on processor 302.
  • the high speed controller 308 manages bandwidth-intensive operations for the computing device 300, while the low speed controller 312 manages lower bandwidth- intensive operations. Such allocation of duties is an example only.
  • the high-speed controller 308 is coupled to memory 304, display 316 (e.g., through a graphics processor or accelerator), and to high-speed expansion ports 310, which may accept various expansion cards (not shown).
  • low-speed controller 312 is coupled to storage device 306 and low-speed expansion port 314.
  • the low-speed expansion port which may include various communication ports (e.g., USB, Bluetooth, Ethernet, wireless Ethernet) may be coupled to one or more input/output devices, such as a keyboard, a pointing device, a scanner, or a networking device such as a switch or router, e.g., through a network adapter.
  • input/output devices such as a keyboard, a pointing device, a scanner, or a networking device such as a switch or router, e.g., through a network adapter.
  • the computing device 300 may be implemented in a number of different forms, as shown in the figure. For example, it may be implemented as a standard server 320, or multiple times in a group of such servers. It may also be implemented as part of a rack server system 324. In addition, it may be implemented in a personal computer such as a laptop computer 322. Alternatively, components from computing device 300 may be combined with other components in a mobile device (not shown), such as device 350. Each of such devices may contain one or more of computing device 300, 350, and an entire system may be made up of multiple computing devices 300, 350 communicating with each other.
  • Computing device 350 includes a processor 352, memory 364, an input/output device such as a display 354, a communication interface 366, and a transceiver 368, among other components.
  • the device 350 may also be provided with a storage device, such as a microdrive or other device, to provide additional storage.
  • a storage device such as a microdrive or other device, to provide additional storage.
  • components may be mounted on a common motherboard or in other manners as appropriate.
  • the processor 352 can process instructions for execution within the computing device 350, including instructions stored in the memory 364.
  • the processor may also include separate analog and digital processors.
  • the processor may provide, for example, for coordination of the other components of the device 350, such as control of user interfaces, applications run by device 350, and wireless communication by device 350.
  • Processor 352 may communicate with a user through control interface 358 and display interface 356 coupled to a display 354.
  • the display 354 may be, for example, a TFT LCD display or an OLED display, or other appropriate display technology.
  • the display interface 356 may comprise appropriate circuitry for driving the display 354 to present graphical and other information to a user.
  • the control interface 358 may receive commands from a user and convert them for submission to the processor 352.
  • an external interface 362 may be provided in communication with processor 352, so as to enable near area communication of device 350 with other devices.
  • External interface 362 may provide, for example, for wired communication (e.g., via a docking procedure) or for wireless communication (e.g., via Bluetooth or other such technologies).
  • the memory 364 stores information within the computing device 350.
  • the memory 364 is a computer-readable medium.
  • the memory 364 is a volatile memory unit or units.
  • the memory 364 is a non- volatile memory unit or units.
  • Expansion memory 374 may also be provided and connected to device 350 through expansion interface 372, which may include, for example, a subscriber identification module (SIM) card interface.
  • SIM subscriber identification module
  • expansion memory 374 may provide extra storage space for device 350, or may also store applications or other information for device 350.
  • expansion memory 374 may include instructions to carry out or supplement the processes described above, and may include secure information also.
  • expansion memory 374 may be provide as a security module for device 350, and may be programmed with instructions that permit secure use of device 350.
  • secure applications may be provided via the SIM cards, along with additional information, such as placing identifying information on the SIM card in a non-hackable manner.
  • the memory may include for example, flash memory and/or MRAM memory, as discussed below.
  • a computer program product is tangibly embodied in an information carrier.
  • the computer program product contains instructions that, when executed, perform one or more methods, such as those described above.
  • the information carrier is a computer- or machine -readable medium, such as the memory 364, expansion memory 374, or memory on processor 352.
  • Device 350 may communicate wirelessly through communication interface 366, which may include digital signal processing circuitry where necessary. Communication interface 366 may provide for communications under various modes or protocols, such as GSM voice calls, SMS, EMS, or MMS messaging, CDMA, TDMA, PDC, WCDMA, CDMA2000, or GPRS, among others. Such communication may occur, for example, through radio-frequency transceiver 368. In addition, short-range communication may occur, such as using a Bluetooth, WiFi, or other such transceiver (not shown). In addition, GPS receiver module 370 may provide additional wireless data to device 350, which may be used as appropriate by applications running on device 350.
  • GPS receiver module 370 may provide additional wireless data to device 350, which may be used as appropriate by applications running on device 350.
  • Device 350 may also communicate audibly using audio codec 360, which may receive spoken information from a user and convert it to usable digital information. Audio codec 360 may likewise generate audible sound for a user, such as through a speaker, e.g., in a handset of device 350. Such sound may include sound from voice telephone calls, may include recorded sound (e.g., voice messages, music files, etc.) and may also include sound generated by applications operating on device 350.
  • Audio codec 360 may receive spoken information from a user and convert it to usable digital information. Audio codec 360 may likewise generate audible sound for a user, such as through a speaker, e.g., in a handset of device 350. Such sound may include sound from voice telephone calls, may include recorded sound (e.g., voice messages, music files, etc.) and may also include sound generated by applications operating on device 350.
  • the computing device 350 may be implemented in a number of different forms, as shown in the figure. For example, it may be implemented as a cellular telephone 380. It may also be implemented as part of a smartphone 382, personal digital assistant, or other mobile device.
  • implementations can include implementation in one or more computer programs that are executable and/or interpretable on a programmable system including at least one programmable processor, which may be special or general purpose, Attorney Docket No. 38060-0003WO1 coupled to receive data and instructions from, and to transmit data and instructions to, a storage system, at least one input device, and at least one output device.
  • a programmable processor which may be special or general purpose, Attorney Docket No. 38060-0003WO1 coupled to receive data and instructions from, and to transmit data and instructions to, a storage system, at least one input device, and at least one output device.
  • the systems and techniques described here can be implemented on a computer having a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user and a keyboard and a pointing device (e.g., a mouse or a trackball) by which the user can provide input to the computer.
  • a display device e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor
  • a keyboard and a pointing device e.g., a mouse or a trackball
  • Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form, including acoustic, speech, or tactile input.
  • the systems and techniques described here can be implemented in a computing system that includes a back end component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front end component (e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation of the systems and techniques described here), or any combination of such back end, middleware, or front end components.
  • the components of the system can be interconnected by any form or medium of digital data communication that is either secure/encrypted or unsecured (e.g., a communication network). Examples of communication networks include a local area network ("LAN”), a wide area network (“WAN”), and the Internet.
  • LAN local area network
  • WAN wide area network
  • the Internet the Internet.
  • the computing system can include clients and servers.
  • a client and server are generally remote from each other and typically interact through a communication network.
  • the relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.
  • combination may be directed to a subcombination or variation of a subcombination.

Abstract

L'invention concerne des procédés, des systèmes et un appareil qui comprennent des programmes informatiques codés sur un support d'informations lisible par ordinateur et comprennent un procédé de prévention de fraude. Un procédé consiste à recevoir des informations d'inscription pour un utilisateur, comprenant des identités de l'utilisateur et un dispositif d'authentification et un identifiant de source de paiement, et à mémoriser les informations d'inscription. Une requête d'autorisation de paiement concernant une transaction censément effectuée par l'utilisateur et comprenant l'identifiant de source de paiement est reçue. Au moyen de l'identifiant de source de paiement, l'identité de l'utilisateur et du dispositif d'authentification est extraite. Une communication est envoyée à l'utilisateur, comprenant les informations de transaction. Le message est remis à l'utilisateur au niveau du dispositif d'authentification. Le procédé consiste aussi à recevoir (puis à transférer) une autorisation de paiement ou un refus de paiement en réponse à la communication provenant de l'utilisateur via le dispositif d'authentification.
PCT/US2014/037103 2013-05-07 2014-05-07 Prévention de fraude pour les transactions WO2014182785A1 (fr)

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US13/889,242 2013-05-07
US13/889,242 US9245261B2 (en) 2013-05-07 2013-05-07 Automatic receipt logging and notifications for transactions
US13/893,165 2013-05-13
US13/893,165 US20140337216A1 (en) 2013-05-13 2013-05-13 Fraud prevention for transactions
US14/024,421 2013-09-11
US14/024,421 US9020859B2 (en) 2013-05-13 2013-09-11 Fraud prevention for transactions

Publications (1)

Publication Number Publication Date
WO2014182785A1 true WO2014182785A1 (fr) 2014-11-13

Family

ID=51867710

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2014/037103 WO2014182785A1 (fr) 2013-05-07 2014-05-07 Prévention de fraude pour les transactions

Country Status (1)

Country Link
WO (1) WO2014182785A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10387849B2 (en) * 2015-11-18 2019-08-20 International Business Machines Corporation System, method, and recording medium for a bi-directional feed between electronic calendar and credit-card authorization unit
US10475020B2 (en) 2015-05-01 2019-11-12 At&T Mobility Ii Llc Mobile device roaming status subscription

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080319889A1 (en) * 2007-06-25 2008-12-25 Ayman Hammad Restricting access to compromised account information
US20120246076A1 (en) * 2009-09-30 2012-09-27 Rakuten, Inc. Credit card fraud prevention system
US20120271712A1 (en) * 2011-03-25 2012-10-25 Edward Katzin In-person one-tap purchasing apparatuses, methods and systems
US20120290482A1 (en) * 2004-12-07 2012-11-15 Farsheed Atef System and method for identity verification and management
US20120330787A1 (en) * 2011-06-27 2012-12-27 Robert Hanson Payment selection and authorization

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120290482A1 (en) * 2004-12-07 2012-11-15 Farsheed Atef System and method for identity verification and management
US20080319889A1 (en) * 2007-06-25 2008-12-25 Ayman Hammad Restricting access to compromised account information
US20120246076A1 (en) * 2009-09-30 2012-09-27 Rakuten, Inc. Credit card fraud prevention system
US20120271712A1 (en) * 2011-03-25 2012-10-25 Edward Katzin In-person one-tap purchasing apparatuses, methods and systems
US20120330787A1 (en) * 2011-06-27 2012-12-27 Robert Hanson Payment selection and authorization

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10475020B2 (en) 2015-05-01 2019-11-12 At&T Mobility Ii Llc Mobile device roaming status subscription
US10387849B2 (en) * 2015-11-18 2019-08-20 International Business Machines Corporation System, method, and recording medium for a bi-directional feed between electronic calendar and credit-card authorization unit

Similar Documents

Publication Publication Date Title
US9020859B2 (en) Fraud prevention for transactions
US11288657B1 (en) Detecting device presence indication
US10242363B2 (en) Systems and methods for performing payment card transactions using a wearable computing device
CA2992421C (fr) Transactions de paiement en temps reel, securisees
US20140337216A1 (en) Fraud prevention for transactions
US20160180305A1 (en) Payment Method Linked To A Mobile Number
US9881305B1 (en) Context-based restrictions on payment cards
US20150199679A1 (en) Multiple token provisioning
US20150170149A1 (en) Financial authorization of an online transaction based on a location and an identifier of a user device
US20150100491A1 (en) Broker-mediated payment systems and methods
US20160335637A1 (en) Systems and Methods for Facilitating Transactions to Payment Accounts, Via SMS Messaging
EP2502192A2 (fr) Systèmes et procédés de paiement en transaction anonyme
US11501268B2 (en) Real-time transaction and receipt processing systems
WO2018102056A1 (fr) Systèmes et procédés de détection de collusion entre commerçants et titulaires de cartes
US11354668B2 (en) Systems and methods for identifying devices used in fraudulent or unauthorized transactions
US20230410119A1 (en) System and methods for obtaining real-time cardholder authentication of a payment transaction
US20140365368A1 (en) Systems and methods for blocking closed account transactions
US10607224B2 (en) Systems and methods for secure authentication of transactions initiated at a client device
US20200126151A1 (en) Systems and methods for providing budget management that incorporates budget regulated transaction alerts
US20190205871A1 (en) System and methods for populating a merchant advice code
US20150371230A1 (en) Methods of processing transactions and related systems and computer program products
WO2014182785A1 (fr) Prévention de fraude pour les transactions
EP3182360A1 (fr) Système et procédé d'ajout d'un code de sécurité dynamique d'achats à distance
US20200394633A1 (en) A transaction processing system and method
US20150324797A1 (en) Phone-number-based payments

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 14794745

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 14794745

Country of ref document: EP

Kind code of ref document: A1