US20200279263A1

Movatterモバイル変換

Info

Publication number: US20200279263A1
Application number: US16/878,353
Authority: US
Inventors: Kevin Patrick Mahaffey; Brian James Buck
Original assignee: LookOut Inc
Current assignee: LookOut Inc
Priority date: 2013-03-14
Filing date: 2020-05-19
Publication date: 2020-09-03
Also published as: US10699273B2; US20180068309A1

Abstract

A method for processing a payment transaction is provided that is based on device locations. The method includes a processor receiving a request to authorize an action from a point of sale (POS) device with the request including context representing a first location associated with the action and context representing information about an account associated with the action. In response to receiving additional context including a location associated with a user device from the user device, the processor compares the context representing the first location and the additional context to determine whether to authorize the action.

Description

CROSS REFERENCE TO RELATED APPLICATIONS

The present application is a continuation of U.S. patent application Ser. No. 15/805,889, entitled “SYSTEM AND METHOD FOR AUTHORIZING A PAYMENT TRANSACTION BASED ON DEVICE LOCATIONS,” filed on Nov. 7, 2017, which is a continuation-in-part of U.S. patent application Ser. No. 13/829,132, entitled “SYSTEM AND METHOD FOR AUTHORIZING A PAYMENT TRANSACTION, filed on Mar. 14, 2013, now U.S. Pat. No. 9,852,416, each of which is incorporated by reference in its entirety. This application is related to: U.S. application Ser. No. 15/687,395, entitled “METHODS AND SYSTEMS FOR BLOCKING THE INSTALLATION OF AN APPLICATION TO IMPROVE THE FUNCTIONING OF A MOBILE COMMUNICATIONS DEVICE,” filed on Aug. 25, 2017; U.S. application Ser. No. 15/608,556, entitled “METHODS AND SYSTEMS FOR DETECTING AND PREVENTING NETWORK CONNECTION COMPROMISE,” filed on May 30, 2017; U.S. application Ser. No. 14/634,115, entitled “ASSESSING A SECURITY STATE OF A MOBILE COMMUNICATIONS DEVICE TO DETERMINE ACCESS TO SPECIFIC TASKS,” filed on Feb. 27, 2015; and U.S. application Ser. No. 14/071,366, entitled “METHODS AND SYSTEMS FOR SECURE NETWORK CONNECTIONS,” filed on Nov. 4, 2013, each of which is incorporated by reference in its entirety.

TECHNICAL FIELD

The present invention relates to the field of information technology, including, more particularly, to systems and techniques for authorizing a payment transaction based on a location of an authenticating device.

BACKGROUND OF THE INVENTION

Mobile electronic communication devices have evolved beyond simple telephone functionality and are now highly complex multifunctional devices with capabilities rivaling those of desktop or laptop computers. In addition to voice communications, many mobile communication devices are capable of text messaging, e-mail communications, internet access, and the ability to run full-featured application software. Mobile communication devices can use these capabilities to perform online transactions such as banking, stock trading, payments, and other financial activities. Furthermore, mobile communication devices used by an individual, a business, or a government agency often store confidential or private information in forms such as electronic documents, text messages, access codes, passwords, account numbers, e-mail addresses, personal communications, phone numbers, and financial information.

In addition to the functionality described above, mobile electronic communication devices are frequently being used to perform mobile payments, thereby eliminating the need, in some cases, for customers to carry coin/paper currency, checks or credit/debit cards. In a particular implementation, a merchant or a service provider is equipped with a point of sale (“POS”) module, e.g., an NFC reader, that is coupled to a payment processing system on a server or in a cloud computing environment. When a mobile communication device is configured for mobile payments, a user of the device can purchase items from the merchant by simply using the device to exchange a user's payment credentials from the device to the POS module. The credentials can be transmitted to the POS module by tapping the configured mobile communication device on a sensor of the POS module, or by waving the device near the POS module's sensor. The payment amount can be deducted from a pre-paid account or charged to a mobile or bank account directly.

As mobile payments using phone-based or electronic wallet-based payments mediated by the use of mobile devices become more widespread, it is more likely that there will be attempts to steal user payment credentials and to use them fraudulently. This could be done by malware on a user's communication device or personal computer, or by network eavesdropping on a user's network connections, for example. Accordingly, a merchant, a payment processor, and/or the user herself need to be sure that when mobile payment credentials are presented at a POS module, the person presenting them is actually the user associated with the payment credentials or is someone who has stolen the payment credentials to make unauthorized purchases.

DESCRIPTION OF THE FIGURES

In the following drawings like reference numbers are used to refer to like elements. Although the following figures depict various examples, the one or more implementations are not limited to the examples depicted in the figures.

FIG. 1 is a block diagram illustrating a system including an electronic device and a server coupled to a network according to an embodiment;

FIG. 2 is a block diagram illustrating of a specific implementation of a system of the invention according to an embodiment;

FIG. 3 is an operational flow diagram illustrating a high level overview of a method of the invention according to an embodiment;

FIG. 4 is a block diagram illustrating an alternative implementation of a system of the invention according to an embodiment;

FIG. 5 is an operational flow diagram illustrating a high level overview of a method of the invention according to another embodiment; and

FIG. 6 is an operational flow diagram illustrating a high level overview of a method of the invention according to an embodiment.

DETAILED DESCRIPTION

It should be appreciated that the present invention can be implemented in numerous ways, including as a process, an apparatus, a system, a device, a method, or a computer readable medium such as a computer readable storage medium containing computer readable instructions or computer program code, or a computer network wherein computer readable instructions or computer program code are sent over optical or electronic communication links. Applications, software programs or computer readable instructions may be referred to as components or modules. Applications may take the form of software executing on a general purpose computer or be hardwired or hard coded in hardware. Applications may also be downloaded in whole or in part through the use of a software development kit, framework, or toolkit that enables the creation and implementation of the present invention. In this specification, these implementations, or any other form that the invention may take, may be referred to as techniques. In general, the order of the steps of disclosed processes may be altered within the scope of the invention.

According to an embodiment, an authorizing client device is associated with a user and is typically located on or near the user. Thus, the location of the authorizing client device is indicative of the user's location. Based on this assumption, when a mobile payment transaction of the user is initiated on a POS module, the location of the user's authorizing client device can be used to determine whether the payment transaction is legitimate, e.g., being initiated by the user, or fraudulent, e.g., being initiated by a person other than the user.

In an embodiment, a system for authorizing a mobile payment transaction includes an anti-fraud service coupled to the payment processing system that interfaces with the POS module. When a payment transaction is initiated at the POS module, the anti-fraud service can receive a request to authorize the payment transaction. The request can include payment information of the payment transaction and information identifying the POS module, which can include or be used to identify the POS's location. When the request is received, the anti-fraud service can identify an authorizing client device based on the payment information and then can determine location information of the authorizing client device. Once the location information of the authorizing client device and of the POS module are determined, the anti-fraud service can compare the location information to determine a disposition of the request to authorize the payment transaction.

According to an embodiment, when the location of the user's authorizing client device is at or near the POS module, the user associated with the presented payment information is presumably also at or near the POS module, and payment authorization can be granted. Otherwise, when the opposite is true, i.e., the authorizing client device's location is not in proximity to the POS module, the payment authorization can be denied or additional authentication information can be requested from the customer. In an embodiment, the authorizing client device can be a dedicated device. In another embodiment, the authorizing client device can be a personal electronic device associated with the user, e.g., a smart phone, a car fob, or any other personal item typically carried by the user.

As used herein, the term “mobile communication device” refers to mobile phones, tablets, PDAs and smartphones. The term “mobile communications device” also refers to a class of laptop computers which run an operating system that is also used on mobile phones, tablets, PDAs, or smartphones. Such laptop computers are often designed to operate with a continuous connection to a cellular network or to the internet via a wireless link. Specifically, mobile communication devices include devices for which wireless communication services such as voice, messaging, data, or other wireless Internet capabilities are a primary function. As used herein, a “mobile communication device” may also be referred to as an “electronic device,” an “electronic client device,” “mobile device,” “mobile client,” or “handset.” However, a person having skill in the art will appreciate that while the present invention is disclosed herein as being used on mobile communication devices, the present invention may also be used on other computing platforms, including desktop, laptop, notebook, netbook, or server computers.

Prior to describing the subject matter in detail, an exemplary network in which the subject matter may be implemented shall first be described. Those of ordinary skill in the art will appreciate that the elements illustrated inFIG. 1 may vary depending on the system implementation.FIG. 1 is a simplified block diagram of acomputer network100 that includes amobile communication device101, aserver system111, aPOS module112 and other electronic client devices140a-140c, coupled to acommunication network121 via a plurality ofcommunication links130.Communication network121 may be comprised of many interconnected computer systems and communication links.Communication links130 may be hardwire links, optical links, satellite or other wireless communications links, wave propagation links, or any other mechanisms for communication of information. Various communication protocols may be used to facilitate communication between the various devices shown inFIG. 1. These communication protocols may include TCP/IP, HTTP protocols, wireless application protocol (WAP), vendor-specific protocols, customized protocols, Internet telephony, IP telephony, digital voice, voice over broadband (VoBB), broadband telephony, Voice over IP (VoIP), public switched telephone network (PSTN), and others. While in one embodiment,communication network112 can be the Internet, in other embodiments,communication network112 may be any suitable communication network including a local area network (LAN), a wide area network (WAN), a wireless network, a intranet, a private network, a public network, a switched network, and combinations of these, and the like.

In an embodiment, themobile device101 includes: anoperating system113, aninput device115, a radio frequency transceiver(s)116, avisual display125, and a battery orpower supply119. Each of these components is coupled to a central processing unit (CPU)103. Thedevice operating system113 runs on theCPU103 and enables interaction between application programs and the mobile device hardware components. In an embodiment, themobile device101 receives data through an RF transceiver(s)116 which may be able to communicate via various networks, for example: BLUETOOTH, local area networks such as WI-FI, and cellular networks such as GSM, CDMA or LTE.

In an embodiment, alocal software component175 is an application program that is downloaded to a mobile device and installed so that it integrates with theoperating system113. Much of the source code for thelocal software component175 can be re-used between various mobile device platforms by using a cross-platform software architecture. In such a system, the majority of software functionality can be implemented in a cross-platform core module. The cross-platform core can be universal allowing it to interface with various mobile device operating systems by using a platform-specific module and a platform abstraction module that both interact with the mobiledevice operating system113, which is described in U.S. Pat. No. 8,099,472, entitled “SYSTEM AND METHOD FOR A MOBILE CROSS-PLATFORM SOFTWARE SYSTEM.” In another embodiment, thelocal software component175 can be device, platform or operating system specific.

As indicated above, themobile device101 may operate in a networked environment usinglogical connections130 to one or more

remote nodes

111,112,140a-140cvia a communication interface. The remote node may be anothercomputer140a, aserver111, an NFC reader/POS module112, aclient device140b-140cor other common network node, and typically includes many or all of the elements described above relative to themobile device101. The communication interface may interface with a wireless network and/or a wired network. Examples of wireless networks include, for example, a BLUETOOTH network, a wireless personal area network, a wireless 802.11 local area network (LAN), a near field communication (NFC), and/or wireless telephony network (e.g., a cellular, PCS, or GSM network). Examples of wired networks include, for example, a LAN, a fiber optic network, a wired personal area network, a telephony network, and/or a wide area network (WAN). Such networking environments are commonplace in intranets, the Internet, offices, enterprise-wide computer networks and the like.

It should be understood that the arrangement ofmobile communication device101 illustrated inFIG. 1 is but one possible implementation and that other arrangements are possible. It should also be understood that the various system components (and means) defined by the claims, described below, and illustrated in the various block diagrams represent logical components that are configured to perform the functionality described herein. For example, one or more of these system components (and means) can be realized, in whole or in part, by at least some of the components illustrated in the arrangement ofmobile device101. In addition, while at least one of these components are implemented at least partially as an electronic hardware component, and therefore constitutes a machine, the other components may be implemented in software, hardware, or a combination of software and hardware. More particularly, at least one component defined by the claims is implemented at least partially as an electronic hardware component, such as an instruction execution machine (e.g., a processor-based or processor-containing machine) and/or as specialized circuits or circuitry (e.g., discrete logic gates interconnected to perform a specialized function), such as those illustrated inFIG. 1. Other components may be implemented in software, hardware, or a combination of software and hardware. Moreover, some or all of these other components may be combined, some may be omitted altogether, and additional components can be added while still achieving the functionality described herein. Thus, the subject matter described herein can be embodied in many different variations, and all such variations are contemplated to be within the scope of what is claimed.

In the description that follows, the subject matter will be described with reference to acts and symbolic representations of operations that are performed by one or more devices, unless indicated otherwise. As such, it will be understood that such acts and operations, which are at times referred to as being computer-executed, include the manipulation by the processing unit of data in a structured form. This manipulation transforms the data or maintains it at locations in the memory system of the device, which reconfigures or otherwise alters the operation of the device in a manner well understood by those skilled in the art. The data structures where data is maintained are physical locations of the memory that have particular properties defined by the format of the data. However, while the subject matter is being described in the foregoing context, it is not meant to be limiting as those of skill in the art will appreciate that various of the acts and operation described hereinafter may also be implemented in hardware.

FIG. 2 is a block diagram illustrating a system for authorizing a mobile payment transaction according to an embodiment. As is shown inFIG. 2, thesystem200 includes apayment facilitating device210, aPOS module220, and apayment processing server230 communicatively coupled to one another over one ormore communication networks201. Thepayment facilitating device210 can be the client device used to initiate a payment transaction via thePOS module220 and can be amobile communication device101, or any one of the other electronic client systems140a-140c. Accordingly, thepayment facilitating device210 can include adisplay screen216 and an operating system (not shown) that supports various device features and/or applications, such as amobile payment application212. Thedevice210 can be a portable electronic device that can be easily carried in a customer's pocket, wallet, purse or other personal item. In an embodiment, thedevice210 can be a dedicated stand-alone device such as a card or a key chain. Alternatively, it can be integrated with another portable electronic client device associated with thecustomer206, e.g., the customer's smart phone, car fob, or any other personal item typically carried by the customer.

ThePOS module220 can be an in-store NFC reader and/or a BLUETOOTH enabled device that is configured to receive the user'spayment credentials202 for the payment transaction from thepayment facilitating device210. In an embodiment, for example, when thepayment facilitating device210 is positioned near a sensor (not shown) in thePOS module220 or is physically tapped against the sensor, the customer'spayment credentials202 can be transmitted to thePOS module220. According to an embodiment, thePOS module220 collects payment information222 for the payment transaction that can include the customer'spayment credentials202 and information identifying thecustomer206. The payment information222 can then be transmitted from thePOS module220 to thepayment processing server230 in a request to process thepayment203.

Thepayment processing server230 hosts apayment processing service240 that stores user information242 that can include information identifying theuser207, a user's credit/debit card information and/or banking information so that mobile payment transactions can be processed for the user's purchases. Thepayment processing service240 can receive the request to process thepayment transaction203 and can use the includedpayment credentials202 of thecustomer206/user207 to retrieve the user information242 associated with theuser207. The amount of the payment transaction can then be deducted from or charged to the user's banking/credit account. When the payment transaction is completed, thepayment processing service240 can generate aresponse203ato the request to process that indicates that the payment transaction was successfully processed and can transmit theresponse203ato thePOS module220. When theresponse203ais received, thePOS module220 can provide a receipt to thecustomer206 or provide some other indication that the payment transaction has been successfully completed, e.g., by providing a message on adisplay226.

Presumably, thecustomer206 and theuser207 are the same entity and presumably, the submittedpayment credentials202 are associated with thecustomer206/user207. Nonetheless, such an assumption may be erroneous if thepayment credentials202 have been stolen by thecustomer206 and embedded into themobile payment application212 of the facilitatingdevice210. In this case, thecustomer206 can effectively impersonate theuser207 and use the user'spayment credentials202 to improperly procure items and/or services, which will be charged to theuser207.

To address this issue, a system and method is described for authorizing a mobile payment transaction based on the proximity of an authorizing client device associated with theuser207 to thePOS module220. According to an embodiment, the authorizing client device can be a device that is typically on or near theuser207 so that a location of the authorizing client device is indicative of a location of theuser207. Thus, when the authorizing client device's location is at or near a location of thePOS module220, it is highly likely that thecustomer206 and theuser207 are the same entity and that the payment transaction is legitimate. When the opposite is true, there is a strong suggestion that the payment transaction is fraudulent.

FIG. 3 is a flow diagram illustrating a method for authorizing a mobile payment transaction according to an embodiment. The method illustrated inFIG. 3 can be carried out by at least some of the components in the example electronic device(s) illustrated inFIG. 1 andFIG. 2, but can also be carried out in environments other than those illustrated inFIG. 1 andFIG. 2. According to an embodiment, themethod300 begins, inblock302, when a request to authorize a payment transaction that originates from a POS module is received. In an embodiment, a system for authorizing a mobile payment transaction includes ananti-fraud service250 configured for receiving the request to authorize thepayment transaction204. According to an embodiment, theanti-fraud service250 can receive therequest204 from thepayment processing service240 when it receives the request to process thepayment transaction203 from thePOS module220.

Theanti-fraud service250 can be hosted by thepayment processing server230 as is shown inFIG. 2. Alternatively, in another embodiment shown inFIG. 4, theanti-fraud service450 can reside in anotherserver432 communicatively coupled to the payment processing server430 and/or to thePOS module420 over thenetwork401. In this embodiment, theanti-fraud service450 can receive therequest404 over thenetwork401 from thePOS module420 when thePOS module420 receives thepayment credentials402 from the facilitatingmobile device410. In another embodiment, the

payment processing service

240,440 and/or the

anti-fraud service

250,450 can be integrated in a common device with the

POS module

220,420. In this case, the

anti-fraud service

250,450 can receive the request to authorize204,404 via an internal link from either the

payment processing service

240,440 or the

POS module

220,420.

In an embodiment, the request to authorize the

payment transaction

204,404 can include thepayment information222,422 of the payment transaction and information identifying the

POS module

224,424. As stated above, the payment information222 can include the payment credentials, e.g.,202, and information identifying theuser207 with which the payment credentials are associated. The information identifying the POS, e.g.,424, can include location information of thePOS module424aand/or information that can be used to determine the location information of the

POS module

220,420. For example, the POS identifying information, e.g.,224, can include an identifier that can be correlated to a location of thePOS module220. This correlation can be included in a table that associates POS identifiers with locations for a plurality of POS modules, and the table can be stored in a database (not shown) on thepayment processing server230 or elsewhere on another server accessible via thenetwork201.

Referring again toFIG. 3, when the request to authorize the

payment transaction

204,404 is received by the anti-fraud service component (250,450), an authorizing client device for the payment transaction is identified based on thepayment information222,422 inblock304. According to an embodiment, the authorizing client device, e.g.,210a, is a personal mobile device associated with auser207 that includes amobile payment application212a, and ananti-fraud client application214 which allows theanti-fraud service250 to communicate with the authorizingclient device210aover thenetwork201. In an embodiment, for example, the authorizingclient device210acan be a smartphone, a tablet computer, or any network enabled handheld personal device.

In an embodiment, during a service registration phase, auser207 can designate one or more of her personal network enabled client devices to be an authorizingclient device210afor the user's mobile payment transactions. Theuser207 can provide information relating to theclient device210athat enables theanti-fraud service250 to communicate with theclient device210a. For example, when the authorizingclient device210ais the user's mobile phone, the phone number associated with the phone can be provided. In another embodiment, the authorizingclient device210acan be a dedicated client device that is provided to theuser207 upon registering with a service provider associated with the anti-fraud service.

According to an embodiment, the

anti-fraud service component

250,450 can store the information relating to the user's authorizing client device(s)252,452 in a storage component coupled to the

server

230,432 and accessed by the

anti-fraud service component

250,450. In an embodiment, when the request to authorize the

payment transaction

204,404 is received, the

anti-fraud service

250,450 can be configured to extract the

payment credentials

202,402 of theuser207 from thepayment information222,422, in order to identify theuser207. Once theuser207 is identified, the

anti-fraud service

250,450 can be configured, in an embodiment, to identify the user's authorizingclient device210aby retrieving the

information

252,452 relating to the user's authorizing client device(s).

Referring again toFIG. 3, once the authorizing client device for the payment transaction, e.g.,210a, is identified, theanti-fraud service250 is configured to determine location information of the authorizingclient device210ainblock306. As noted above, theinformation252 relating to the user's authorizingclient device210aincludes information that enables theanti-fraud service250 to communicate with theclient device210a. Therefore, according to an embodiment, the anti-fraud service, e.g.,250, can use theinformation252 to generate and transmit a request forlocation information205 to the authorizingclient device210aover thenetwork201, which in an embodiment, can be a Wi-Fi network, a LAN, a PAN, a WAN, a BLUETOOTH network, or a near field communication (NFC) depending on the circumstances. In another embodiment when the authorizingclient device210ais a phone connected to a cellular network, therequest message205 can be transmitted over thecellular network201.

In another embodiment, theanti-fraud service250 can transmit the request forlocation information205′ to the authorizingclient device210aindirectly via thePOS module220. In this case, when thePOS module220 receives therequest205′, it can be configured to forward therequest205′ to the authorizingclient device210aover thenetwork201, which in this embodiment, can be a wireless short range personal area network (“WPAN”), such as a BLUETOOTH network or a NFC network.

When the request forlocation205 is received by the authorizingclient device210a, theanti-fraud client application214 in theclient device210acan provide its location information in several ways. For example, in an embodiment, when theclient device210ais equipped with a Global Positioning System (“GPS”) tracking unit, the device's location information can be provided as geo-coordinates associated with its location. Alternatively or in addition, when theclient device210ais connected to a cellular network that includes a plurality of cell towers, the device's location information can also be provided as the location of a cell tower nearest to the authorizingclient device210a. For example, the nearest cell tower can be the destination tower that transmits therequest message205 directly to the authorizingclient device210a. Alternatively or in addition, when theclient device210ais connected to a wired orwireless network201, the location information can be related to a wireless access point of the wireless network or related to a LAN.

According to an embodiment, theanti-fraud client application214 in theclient device210acan be configured to generate aresponse205ato the request forlocation205 and to include the device's location information in theresponse205a. Theresponse205acan then be returned to and received by theanti-fraud service250 over thenetwork201. In an embodiment, theanti-fraud service250 can receive theresponse205adirectly from theclient device210aover thenetwork201, while in another embodiment, theanti-fraud service250 can receive the response250a′ indirectly via thePOS module220. In the latter case, theresponse205a′ may not be received by thePOS module220 when the authorizingclient device210ais not located within the module'sshort range WPAN201. If, however, theclient device210ais located within theshort range WPAN201, thePOS module220 can be configured to receive and forward theresponse205′ to theanti-fraud service250 over thenetwork201.

As discussed above, theanti-fraud service250 can be configured to transmit the request for

location

205,205′ to the authorizingclient device210aover different network environments, e.g., a WAN and a WPAN. Theresponse205a,250a′ from the authorizingclient device210acan be received over the same network environment as the one used to transmit the request or over a different network environment from that used to transmit the request. Accordingly, in an embodiment, theanti-fraud service250 can transmit therequest205 to theclient device210adirectly over a WAN, such as the Internet, and theresponse205a′ can be received indirectly via thePOS module220 over a BLUETOOTH network and a WAN.

Referring again toFIG. 3, when the location information of the authorizing client device is determined, the

anti-fraud service

250,450 can be configured to compare the location information of the authorizing

client device

210a,410 to the location information of the

POS module

220,420 to determine a disposition of the request to authorize the payment transaction inblock308. According to an embodiment, the disposition of the request, i.e., whether the

request

204,404 is granted, denied, or pending, can be determined based on whether and to what degree the location of the authorizing

client device

210a,410 is different from the location of the

POS module

220,420.

For example, inFIG. 2, because the authorizingclient device210ais not the payment facilitatingclient device210, there is a likelihood that the authorizingclient device210awill be in a different location from thePOS module220, and that therefore the location information of theclient device210awill be different from that of thePOS module220. Alternatively, inFIG. 4, because the authorizingclient device410 is the payment facilitating device, it is likely that the location information of the authorizingclient device410 is substantially the same as the location information of thePOS module420.

Depending on the circumstances, when the location information of the authorizing

client device

210a,410 is different from the location information of the

POS module

220,420, the

anti-fraud service

250,450 can be configured to deny the request to authorize the payment transaction in an embodiment. In another embodiment, when the location information of the authorizing client device corresponds to a first geo-location and the location information of the POS module corresponds to a second geo-location, the

anti-fraud service

250,450 can be configured to deny the request to authorize the payment transaction when a distance between the first geo-location and the second geo-location exceeds a threshold distance. According to an embodiment, the threshold distance can be provided by the

user

207,407 and/or by an administrator, and can vary according to contextual circumstances. For example, a threshold distance for aPOS module220 located in a highly restricted area can be shorter/smaller than the threshold distance for aPOS module420 in a public store because the adverse consequences of allowing an unauthorized transaction in the highly restricted area can be more severe than those in the public store.

According to an embodiment, the disposition of the request to authorize204,404 can also depend on other circumstances unrelated to proximity. In an embodiment, a plurality ofpayment rules454 can be provided that define under what circumstances the request to authorize404 should be granted or denied based on factors in addition to the authorizing client device's proximity to thePOS module420. For example, apayment rule454 can be based on the location of thePOS module420 and can define whether the request to authorize404 should be granted, denied, or conditionally granted when the POS module's location is within a specified region or location. So, for instance, such a location-basedpayment rule454 can indicate that a request to authorize404 should be denied when thePOS module420 is located in a specified location associated with a particular fast food restaurant. Thus, even though the authorizing client device's location is within a specified distance of the POS module's location, the request to authorize404 will be denied when the POS module's location is in the fast food restaurant.

In another embodiment, apayment rule454 can be based on a temporal attribute of the payment transaction that defines the disposition of the request to authorize404 according to when the request to authorize404 is received. For example, such a time-basedpayment rule454 can indicate that a request to authorize404 should be granted during specified hours, specified days of the week, specified months, or during a specified time interval. In an embodiment, because the payment rules454 are based on different factors, they can be enforced independently and simultaneously. Thus, the time-basedpayment rule454 can be enforced along with the location-basedpayment rule454.

In another embodiment, apayment rule454 can be based on a type of item and/or service associated with the payment transaction. For example, this type ofpayment rule454 can provide a white or black list of items and services that are allowed or disallowed or disallowed unless additional authentication information is provided respectively. Similar to theother payment rules454 described above, the item/service-basedpayment rules454 can be enforced independently and simultaneously.

In addition,payment rules454 can be based on a payment amount associated with the payment transaction. According to an embodiment, transaction amount-basedpayment rules454 can define the disposition of the request to authorize404 according to the cost of any individually charge item and/or the total cost associated with the payment transaction. For example, the cost-basedpayment rules454 can indicate that a request to authorize404 should be denied outright or conditionally denied unless additional authentication is provided when a cost of an individual item exceeds a threshold value, and/or when the total cost of the transaction exceeds another threshold value. In another embodiment, the request to authorize404 can be denied or conditionally denied when a frequency of payment transactions within a specified time period exceeds another threshold value.

According to an embodiment, the payment rules454 for the authorizingclient device410 can be defined and provided by theuser407 associated with theclient device410. In an embodiment, somepayment rules454 can be provided and stored during the registration phase along with the information relating to the authorizingclient device410. Alternatively or in addition,other payment rules454 can be stored on the authorizingclient device410 and provided to theanti-fraud service component450 when the payment transaction is initiated or pending. Accordingly, theanti-fraud service component450 can be configured to determine the disposition of the request to authorize thepayment transaction404 based on whether the authorizingclient device410 is located within a predetermined proximity to thePOS module420 and on whether at least one of the payment rules454 is satisfied.

As noted above, instead of or in addition to, denying the request, the

anti-fraud service

250,450 can be configured to conditionally deny the request unless additional authentication information is provided by thecustomer206/user407. For example, in an embodiment, when the

anti-fraud service

250,450 would otherwise deny the request, it can be configured instead to transmit an indication to the

POS module

220,420 directing it to request additional authentication information from thecustomer206/user407. For example, thecustomer206 can be requested to produce additional forms of identification or to submit a PIN or password to prove that she is the

user

207,407 associated with thepayment credentials202.

In addition to denying the request and/or requesting additional authentication information, in another embodiment, the

anti-fraud service

250,450 can be configured to send a message relating to the requested payment transaction at thePOS module220 to the authorizingclient device210afor display to theuser207 on the device'sdisplay216a. According to an embodiment, the message can include a request to verify the requested payment transaction thereby allowing theuser207 to override the anti-fraud service's denial and to indicate that the payment transaction is legitimate. For example, when thecustomer206 is an employee of theuser207 and is making a purchase on behalf of theuser207, theuser207 can verify that the mobile payment transaction as an approved transaction. When theuser207 authorizes the requested payment transaction, the authorization can be included in a response to the request to verify, which can be transmitted to and received by theanti-fraud service250. Upon receipt, theanti-fraud service250 can be configured to disregard the denial and to grant the request to authorize the payment transaction.

In the embodiment described above, theanti-fraud service component250 is configured to proactively determine the location information of the authorizingclient device210aso that the location information of the authorizing client device can be compared to that of thePOS module220. In another embodiment, the authorizingclient device410 can take a more proactive role in providing its information automatically, and theanti-fraud service component450 can take a more passive role by listening for the information regarding the authorizingclient device410.FIG. 5 is a flow diagram illustrating a method for authorizing a mobile payment transaction according to this embodiment. The method illustrated inFIG. 5 can be carried out by at least some of the components in the example electronic device(s) illustrated inFIG. 1 andFIG. 4, but can also be carried out in environments other than those illustrated inFIG. 1 andFIG. 4.

According to an embodiment, themethod500 begins, inblock502, when theanti-fraud service component450 receives the request to authorize apayment transaction404 that originates from thePOS module420. As described above, the request to authorize404 can be received from thePOS module420 when thePOS module420 receives thepayment credentials402 from themobile device410. Alternatively, it can be received from thepayment processing service440 when it receives the request to process thepayment transaction403 from thePOS module420. In either of these embodiments, therequest404 can be received over at least oneexternal network401. In another embodiment, when thepayment processing service440 and/or theanti-fraud service450 are integrated in a common device with thePOS module420, theanti-fraud service450 can receive the request to authorize404 via an internal link from either thepayment processing service440 or thePOS module420.

Once the request to authorize thepayment transaction404 is received, theanti-fraud service450 can be configured to determine whether information regarding an authorizing client device for the payment transaction has been received inblock504 and to determine a disposition of the request when the information has been received inblock506.

According to an embodiment, theanti-fraud client application414 in the authorizingclient device410 can be configured to collect information regarding itself and to transmit thatinformation405 to theanti-fraud service component450 periodically and/or spontaneously. For example, theanti-fraud client application414 can be configured to transmit the information regarding itself405 every five (5) minutes. In another embodiment, theanti-fraud client application414 can be configured to transmit theinformation405 when thepayment application412 is invoked and/or when thepayment credentials402 of theuser407 are presented to thePOS module420. Accordingly, theanti-fraud service component450 can receive the information regarding the authorizingclient device405 periodically or when theclient device410 is used to facilitate a payment transaction.

In an embodiment, the information regarding the authorizingclient device405 can include information identifying the client device and its location information. Theanti-fraud service component450 can be configured to receive the information, to identify the authorizingclient device410 based on the received information, and to store the received information in the storage component along with the information relating to the user's authorizing client device(s)452.

According to an embodiment, when the request to authorize404 is received, theanti-fraud service component450 can identify the authorizingclient device410 for the payment transaction and can determine that information regarding the identified authorizingclient device405 has been received. In an embodiment, theanti-fraud service component450 can be configured to compare the location information of the authorizingclient device410 to the location information of thePOS module424a. In an embodiment where theinformation405 is received periodically, the client device's location information received immediately prior to receiving the request to authorize404 can be compared to the POS module'slocation information424a. Theanti-fraud service component450 can be configured to grant the request to authorize the payment transaction when the comparison indicates that the authorizingclient device410 is located within a predetermined distance of thePOS module420.

In another embodiment where theclient device410 automatically transmits theinformation405 when the payment transaction is initiated or while the payment transaction is pending, the fact that the information regarding the authorizingclient device405 is not received by theanti-fraud service component450 suggests that the payment transaction is fraudulent. Thus, when the information regarding the authorizingclient device405 has not been received under these circumstances, theanti-fraud service component450 can be configured to deny the request to authorize the payment transaction.

In another embodiment, as described above with regard toFIG. 2, theanti-fraud service component250 can be configured to transmit a

request

205,205′ for the client device information, e.g., the location information of the authorizing client device, to theclient device210adirectly over thenetwork201 or indirectly via thePOS module220. When therequest205 is received directly over thenetwork201, theanti-fraud client application214 cannot transmit itsresponse205a′ to theanti-fraud service component250 via thePOS module220 unless theclient device210alocated within the module's wireless short range network. Alternatively, theanti-fraud service component250 cannot transmit therequest205′ to theanti-fraud client application214 indirectly via thePOS module220 unless theclient device210ais located within the module's wireless short range network.

Accordingly, in this embodiment, theanti-fraud service component250 will receive theinformation405 regarding the authorizing client device when the

client device

210a,410 is located within the POS module's wireless short range network. In this case, when theinformation405 regarding the authorizing client device has been received, theanti-fraud service component450 can be configured to grant the request to authorize thepayment transaction404. Alternatively, when the

client device

210a,410 is not located within the POS module's wireless short range network, theinformation405 will not be received. In this case, when theinformation405 regarding the authorizing client device has not been received, theanti-fraud service component450 can be configured to deny the request to authorize thepayment transaction404.

According to yet another embodiment, instead of transmitting a request forlocation information205 to the authorizingclient device210aor waiting to receiveinformation405 regarding the authorizingclient device410, the

anti-fraud service component

250,450 can be configured to transmit the location information of thePOS module424ato the authorizingclient device410, and to request that the authorizingclient device410 confirm or deny that a current location of the authorizing client device substantially matches the POS module'slocation information424a. In this embodiment, theanti-fraud client application414 in theclient device410 can be configured to receive the location information of thePOS module424aand the request, and to compare its own location information to that of thePOS module420.

Based on the comparison, theanti-fraud client application414 can generate a decision either confirming or denying that its current location information substantially matches the POS module'slocation information424a. Theanti-fraud client application414 can then include the decision in a reply message and can transmit the reply message to theanti-fraud service component450. Upon receiving the reply, theanti-fraud service component450 can be configured to determine the disposition of the request to authorize thepayment transaction404 based on the authorizing client device's decision confirming or denying that the current location information of the authorizing client device substantially matches the POS module'slocation information424a. For example, when the decision is confirming, theanti-fraud service component450 can be configured to grant the request to authorize thepayment transaction404.

In an embodiment, the

anti-fraud service

250,450 can be configured to generate a

response

204a,404ato the request to authorize204,404 that includes the disposition of the request and to transmit the response to204a,404ato thepayment processing service240,340 and/or the

POS module

220,420. In an embodiment when theresponse204ais transmitted to thepayment processing service240, depending on the disposition of the request, thepayment processing service240 can either proceed with or stop processing the payment transaction. In another embodiment, when theresponse404ais transmitted to thePOS module420, thePOS module420 can transmit therequest203 to process the payment transaction or deny the transaction depending on the disposition.

According to embodiments, a system for authorizing a mobile payment transaction that originates from a POS module includes an anti-fraud service component coupled to the POS module and/or to a payment processing service associated with the POS module. In an embodiment, when payment credentials associated with a user are provided to the POS module to initiate the payment transaction, the anti-fraud service component can identify and determine a location a client device typically carried by the user. Because the user typically carries the client device on his or her person, the device's location is indicative of the user's location. In an embodiment, when the anti-fraud service component determines that the user's client device is located at or near the POS module, the payment transaction can be authorized based on the assumption that the authorized user is carrying the client device and is also located at or near the POS module. When the location of the client device is not at or near the POS module, the authorized user is presumptively not at or near the POS module. In this case, the payment transaction can be denied outright or denied pending the presentation of additional authentication information from the customer.

According to an embodiment, the user may designate more than one of her personal network enabled client devices to be an authorizingclient device210afor the user's mobile payment transactions. The personal network enabled client devices can be in different locations, but typically only those devices that are actively in use will be considered in the same location as the user. That is, it would be unusual for one of the personal network enabled client devices to be actively in use at one location while one or more of the user's other personal network enabled client devices are actively in use at a different location.

In an embodiment, based on this premise, the anti-fraud service component may obtain current locations for a plurality of authorizing client devices, together with information indicating whether the devices are actively in use. If one of the authorizing client devices is at the location of the POS module, and the other authorizing client devices are not, but they are not currently active, then the transaction can be permitted. Alternatively, if one or more of the authorizing client devices are not at the location of the POS module and are actively in use, even if one of them is at the location of the POS module, the legitimacy of the transaction can be questionable. In this embodiment, under such a situation, the anti-fraud service component can deny the request to authorize the transaction, and/or request additional authentication or authorization information from the user via one or more of the authorizing client devices.

In an embodiment,device information452 for use with one ormore payment rules454 may contain information regarding contextual factors. The contextual factors may include the information previously discussed regardingpayment rules454, such as location information, distance information, time information, transaction item, and transaction amount. Additional contextual factors may include, for example, one or more of the current security state of the payment facilitating device (e.g., trusted, untrusted, or unknown), the security state of the authorizing client device, the security state of the one ormore network connections401 from thepayment application412 providingpayment credentials402 toPOS module420, said security state being trusted or untrusted (e.g., based on detection of a Man in the Middle in the connection). In the embodiment, a decision to grant a request to proceed with the processing of the payment transaction may be based on such contextual information and whether the contextual information conforms to one or more payment rules454. For example, the request could be granted based on one or more rules related to contextual factors being met, such as: the distance between the authorizing client device and the POS device does not exceed a threshold distance; the security state of the device is “trusted;” and the security state of the network is “trusted.” Similarly, the request could be denied when one or more rules related to contextual factors are not met, such as: the distance between the authorizing client device and the POS device exceeds a threshold distance; the security state of the device is not “trusted;” and the security state of the network is not “trusted.” In addition, various combinations of rules related to contextual factors may result in different outcomes regarding whether the request is granted. For example, even if the distance between the authorizing client device and the POS device is within a threshold distance, the request may be denied when the security state of the device is “untrusted.” Methods for determining whether to grant a request to process a payment transaction based on contextual factors and payment rules are further illustrated with regard toFIG. 6.

Disclosure regarding the security state of a device is further contained in U.S. application Ser. No. 14/634,115, entitled “ASSESSING A SECURITY STATE OF A MOBILE COMMUNICATIONS DEVICE TO DETERMINE ACCESS TO SPECIFIC TASKS,” filed on Feb. 27, 2015, and U.S. application Ser. No. 15/687,395, entitled “METHODS AND SYSTEMS FOR BLOCKING THE INSTALLATION OF AN APPLICATION TO IMPROVE THE FUNCTIONING OF A MOBILE COMMUNICATIONS DEVICE,” filed on Aug. 25, 2017, which are both incorporated by reference in their entirety. Disclosure regarding security states of network connections is further contained in U.S. application Ser. No. 15/608,556, entitled “METHODS AND SYSTEMS FOR DETECTING AND PREVENTING NETWORK CONNECTION COMPROMISE,” filed on May 30, 2017, which is incorporated by reference in its entirety. And disclosure regarding contextual information, the security state of a device, and the security state of a connection is further contained in U.S. application Ser. No. 14/071,366, entitled “METHODS AND SYSTEMS FOR SECURE NETWORK CONNECTIONS,” filed on Nov. 4, 2013, which is incorporated by reference in its entirety.

FIG. 6 is a flow diagram illustrating a method for authorizing a mobile payment transaction according to an embodiment. The method illustrated inFIG. 6 can be carried out by at least some of the components in the example electronic device(s) illustrated inFIG. 1 andFIG. 2, but can also be carried out in environments other than those illustrated inFIG. 1 andFIG. 2. According to an embodiment, themethod600 begins, inblock602, when a request to authorize a payment transaction that originates from a POS module is received. In an embodiment, a system for authorizing a mobile payment transaction includes ananti-fraud service250 configured for receiving the request to authorize thepayment transaction204. According to an embodiment, theanti-fraud service250 can receive therequest204 from thepayment processing service240 when it receives the request to process thepayment transaction203 from thePOS module220.

payment processing service

240,440 and/or the

anti-fraud service

250,450 can be integrated in a common device with the

POS module

220,420. In this case, the

anti-fraud service

payment processing service

240,440 or the

POS module

220,420.

In an embodiment, the request to authorize the

payment transaction

POS module

Referring again toFIG. 6, inblock604, when the request to authorize the

payment transaction

204,404 is received by the anti-fraud service component (250,450), an authorizing client device for the payment transaction is identified based on thepayment information222,422. According to an embodiment, the authorizing client device, e.g.,210a, is a personal mobile device associated with auser207 that includes amobile payment application212a, and ananti-fraud client application214 which allows theanti-fraud service250 to communicate with the authorizingclient device210aover thenetwork201. In an embodiment, for example, the authorizingclient device210acan be a smartphone, a tablet computer, or any network enabled handheld personal device.

According to an embodiment, the

anti-fraud service component

server

230,432 and accessed by the

anti-fraud service component

250,450. In an embodiment, when the request to authorize the

payment transaction

204,404 is received, the

anti-fraud service

250,450 can be configured to extract the

payment credentials

anti-fraud service

information

252,452 relating to the user's authorizing client device(s).

Referring again toFIG. 6, inblock606, once the authorizing client device for the payment transaction, e.g.,210a, is identified, theanti-fraud service250 determines context information associated with the request. Contextual information associated with the request may include contextual information associated with the authorizing client device, the payment facilitating device, and the POS module. For example, the determined context information may include and of: the location information of the authorizingclient device210a, location information of the payment facilitating device, distance information, time information, transaction item, transaction amount, the security state of the payment facilitating device, the security state of the authorizing client device, and the security state of the one ormore network connections401 from thepayment application412 providingpayment credentials402 toPOS module420.

As noted above, theinformation252 relating to the user's authorizingclient device210aincludes information that enables theanti-fraud service250 to communicate with theclient device210a. Therefore, according to an embodiment, the anti-fraud service, e.g.,250, can use theinformation252 to generate and transmit a request for contextual information to the authorizingclient device210aover thenetwork201, which in an embodiment, can be a Wi-Fi network, a LAN, a PAN, a WAN, a BLUETOOTH network, or a near field communication (NFC) depending on the circumstances. In another embodiment when the authorizingclient device210ais a phone connected to a cellular network, therequest message205 can be transmitted over thecellular network201.

In another embodiment, theanti-fraud service250 can transmit the request for contextual information to the authorizingclient device210aindirectly via thePOS module220. In this case, when thePOS module220 receives therequest205′, it can be configured to forward therequest205′ to the authorizingclient device210aover thenetwork201, which in this embodiment, can be a wireless short range personal area network (“WPAN”), such as a BLUETOOTH network or a NFC network.

When the request for contextual information is received by the authorizingclient device210a, theanti-fraud client application214 in theclient device210acan provide its contextual information in several ways. For example, in an embodiment, when theclient device210ais equipped with a Global Positioning System (“GPS”) tracking unit, the device's contextual information, in this case location information, can be provided as geo-coordinates associated with its location. Alternatively or in addition, when theclient device210ais connected to a cellular network that includes a plurality of cell towers, the device's contextual information can also be provided as the location of a cell tower nearest to the authorizingclient device210a. For example, the nearest cell tower can be the destination tower that transmits therequest message205 directly to the authorizingclient device210a. Alternatively or in addition, when theclient device210ais connected to a wired orwireless network201, the contextual information can be related to a wireless access point of the wireless network or related to a LAN.

According to an embodiment, theanti-fraud client application214 in theclient device210acan be configured to generate aresponse205ato the request for contextual information and to include the device's contextual information in theresponse205a. Theresponse205acan then be returned to and received by theanti-fraud service250 over thenetwork201. In an embodiment, theanti-fraud service250 can receive theresponse205adirectly from theclient device210aover thenetwork201, while in another embodiment, theanti-fraud service250 can receive the response250a′ indirectly via thePOS module220. In the latter case, theresponse205a′ may not be received by thePOS module220 when the authorizingclient device210ais not located within the module'sshort range WPAN201. If, however, theclient device210ais located within theshort range WPAN201, thePOS module220 can be configured to receive and forward theresponse205′ to theanti-fraud service250 over thenetwork201.

As discussed above, theanti-fraud service250 can be configured to transmit the request for contextual information to the authorizingclient device210aover different network environments, e.g., a WAN and a WPAN. Theresponse205a,250a′ from the authorizingclient device210acan be received over the same network environment as the one used to transmit the request or over a different network environment from that used to transmit the request. Accordingly, in an embodiment, theanti-fraud service250 can transmit the request to theclient device210adirectly over a WAN, such as the Internet, and theresponse205a′ can be received indirectly via thePOS module220 over a BLUETOOTH network and a WAN.

Referring again toFIG. 6, inblock608, when the contextual information of the authorizing client device is determined, the

anti-fraud service

250,450 can be configured to compare the contextual information to one or moreapplicable payment rules454 to determine a disposition of the request to authorize the payment transaction. According to an embodiment, the disposition of the request, i.e., whether the

request

204,404 is granted, denied, or pending, can be determined based on whether and to what degree the determined contextual information satisfies one or more applicable payment rules454.

In an embodiment, the one or moreapplicable payment rules454 may vary, e.g., based on the user of the authorized client device. In this embodiment,payment rules454 are determined to be applicable based on those rules being associated with, e.g., a particular user, or a particular authorizing client device. The association between the payment rules and the user or client device may be created by, e.g., the user or administrator of the authorizing client device. In this embodiment, onceapplicable payment rules454 are determined, requests for context information associated withblock606 may be fashioned based on what contextual information must be satisfied by theapplicable payment rules454 in order for the payment request to be granted, or denied.

Any of the above embodiments may be used alone or together with one another in any combination. The one or more implementations encompassed within this specification may also include embodiments that are only partially mentioned or alluded to or are not mentioned or alluded to at all. Although various embodiments may have been motivated by various deficiencies with the prior art, which may be discussed or alluded to in one or more places in the specification, the embodiments do not necessarily address any of these deficiencies. In other words, different embodiments may address different deficiencies that may be discussed in the specification. Some embodiments may only partially address some deficiencies or just one deficiency that may be discussed in the specification, and some embodiments may not address any of these deficiencies.

In addition, one will appreciate that in the description above and throughout, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be evident, however, to one of ordinary skill in the art, that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form to facilitate explanation.

While one or more implementations have been described by way of example and in terms of the specific embodiments, it is to be understood that one or more implementations are not limited to the disclosed embodiments. To the contrary, it is intended to cover various modifications and similar arrangements as would be apparent to those skilled in the art. Therefore, the scope of the appended claims should be accorded the broadest interpretation so as to encompass all such modifications and similar arrangements.

Claims

What is claimed is:

1. A method for processing a payment transaction, the method comprising:

receiving, by a processor, a request to authorize an action from a point of sale device, the request including a first context representing a first location associated with the action, and a second context representing information about an account associated with the action;

determining a user device information associated with the second context representing information about the account associated with the action;

transmitting a request for a third context to the user device associated with the second context representing information about the account associated with the action, the third context including a second location associated with the user device;

receiving the third context including a second location associated with the user device from the user device; and

determining whether to transmit a response to the point of sale device based on the comparison between the first context representing the first location associated with the action, and the third context including the second location associated with the user device, the response representing whether to authorize the action.

2. The method ofclaim 1, wherein determining whether to transmit the response to the point of sale device based on the comparison between the first context, and the third context is based on comparing a geographic proximity between the first context and the third context.

3. The method ofclaim 2, further comprising transmitting a response to the point of sale device indicating that the action is authorized.

4. The method ofclaim 3, wherein the third context represents a temporal attribute of the point of sale device to the user device.

5. The method ofclaim 1 further comprising the account being associated with payment rules, the payment rules representing one or more attributes that must be met before payment is authorized; and

wherein the determination whether to transmit the response to the point of sale device based on the comparison between the first context representing the first location associated with the action, and the third context including the second location associated with the user device is based on the payment rules associated with the account.

6. The method ofclaim 5, wherein the payment rule is a plurality of rules and the one or more attributes to be met before payment is authorized is based on a payment amount.

7. The method ofclaim 6, wherein the payment rule includes one or more attributes to be met before payment is authorized is based on the proximity between the point of sale device, and the user device.

8. A system, comprising:

at least one processor; and

memory storing instructions configured to instruct the at least one processor to:

receive a request to authorize an action from a point of sale device, the request including a first context representing a first location associated with the action, and a second context representing information about an account associated with the action;

determine a user device information associated with the second context representing information about the account associated with the action;

transmit a request for a third context to the user device associated with the second context representing information about the account associated with the action, the third context including a second location associated with the user device;

receive the third context including a second location associated with the user device from the user device; and

determine whether to transmit a response to the point of sale device based on the comparison between the first context representing the first location associated with the action, and the third context including the second location associated with the user device, the response representing whether to authorize the action.

9. The system ofclaim 8, wherein determining whether to transmit the response to the point of sale device based on the comparison between the first context, and the third context is based on comparing a geographic proximity between the first context and the third context.

10. The system ofclaim 9, further comprising transmitting a response to the point of sale device indicating that the action is authorized.

11. The system ofclaim 10, wherein the third context represents a temporal attribute of the point of sale device to the user device.

12. The system ofclaim 8 further comprising the account being associated with payment rules, the payment rules representing one or more attributes that must be met before payment is authorized; and

13. The system ofclaim 12, wherein the payment rule is a plurality of rules and the one or more attributes to be met before payment is authorized is based on a payment amount.

14. The system ofclaim 13, wherein the payment rule includes one or more attributes to be met before payment is authorized is based on the proximity between the point of sale device, and the user device.

15. A non-transitory storage medium storing computer-readable instructions, which when executed, cause a computing device to:

16. The non-transitory storage medium ofclaim 15, wherein determining whether to transmit the response to the point of sale device based on the comparison between the first context, and the third context is based on comparing a geographic proximity between the first context and the third context.

17. The non-transitory storage medium ofclaim 16, further comprising transmitting a response to the point of sale device indicating that the action is authorized.

18. The non-transitory storage medium ofclaim 17, wherein the third context represents a temporal attribute of the point of sale device to the user device.

19. The non-transitory storage medium ofclaim 15. further comprising the account being associated with payment rules, the payment rules representing one or more attributes that must be met before payment is authorized; and

20. The non-transitory storage medium ofclaim 19, wherein the payment rule is a plurality of rules and the one or more attributes to be met before payment is authorized is based on a payment amount.

21. The non-transitory storage medium ofclaim 20, wherein the payment rule includes one or more attributes to be met before payment is authorized is based on the proximity between the point of sale device, and the user device.