Location verification in dynamic data transactions

Abstract

Platforms and methods for determining a confidence level associated with a transaction using dynamic data are described. In some embodiments, the confidence level is determined based on location data received in connection with the transaction. For example, some embodiments involve storing first location information gathered from a mobile device provided in a request for dynamic data, receiving second location information in connection with a transaction performed using the dynamic data, and comparing the two with respect to an amount of time elapsed between gathering of each to determine a confidence level associated with a likelihood that the transaction is authentic.

Description

[0001] This application is a continuation-in-part of International Application No. PCT / US2017 / 020247, International Filing Date, March 1, 2017, which entered the National Stage at U.S. Patent Application No. 201780016554.2, entitled "LOCATION VERIFICATION IN DYNAMIC DATA TRANSACTIONS," filed on March 1, 2017, the entire disclosure of which is hereby incorporated by reference in its entirety for all purposes. BACKGROUND

[0002] This application is an international application of U.S. Patent No. 15 / 074,941, filed March 18, 2016, entitled "LOCATION VERIFICATION DURING DYNAMIC DATA TRANSACTIONS," the entire disclosure of which is hereby incorporated by reference in its entirety for all purposes.

[0003] As computing power has increased, it has become increasingly important to provide secure means of performing transactions. Hackers and other fraudsters are increasingly gaining access to accounts, committing high levels of identity fraud and theft. One solution to this problem is to use alternative account representations that are tied to a particular account instead of using a real account number. However, even these alternative account representations can be subject to theft and misuse. Thus, there is a need to provide increasing security for electronic transactions.

[0004] Embodiments of the present invention address these and other problems, individually or collectively. SUMMARY

[0005] Embodiments of the present invention relate to a platform for determining a level of confidence associated with a transaction performed using dynamic data based on location data received in connection with the transaction. In particular, embodiments relate to storing first location information gathered from a mobile device provided in a request for dynamic data, receiving second location information in connection with a transaction performed using dynamic data, and comparing the two with respect to an amount of time that has elapsed between the gathering of the two location information to determine a likelihood that the transaction is authentic. In some embodiments, the dynamic data used in the transaction can be, for example, a dynamic account identifier (e.g., a token) and / or a dynamic key, such as a limited use key or an access key, among others.

[0006] One embodiment of the present invention relates to a method comprising: receiving a request for dynamic data, the request including first location information associated with the mobile device. Upon receiving the request, the method may include generating dynamic data for the mobile device; storing the first location information and associating the first location information with the dynamic data; and transmitting the dynamic data to the mobile device. Upon receiving an authorization request message for a transaction, the authorization request message including second location information associated with the transaction and the dynamic data or transaction data generated from the dynamic data; the method may include comparing a first location with a second location, the first location corresponding to the first location information associated with the dynamic data, and the second location corresponding to the second location information associated with the transaction. A confidence level for the transaction is then determined, at least in part, based on the comparison of the first and second locations.

[0007] Another embodiment of the invention relates to a server computer including a processor and a computer-readable medium coupled to the processor, wherein the computer-readable medium contains code executable by the processor to perform a method. The method includes receiving a request for dynamic data. The request may include first location information associated with a mobile device. Upon receiving the request, the method may include generating dynamic data for the mobile device; storing the first location information and associating the first location information with the dynamic data; and transmitting the dynamic data to the mobile device. Upon receiving an authorization request message for a transaction, the authorization request message includes second location information associated with the transaction and the dynamic data or transaction data generated from the dynamic data; the method may include comparing a first location with a second location, the first location corresponding to the first location information associated with the dynamic data, and the second location corresponding to the second location information associated with the transaction. A confidence level for the transaction is then determined, at least in part, based on the comparison of the first and second locations.

[0008] These and other embodiments of the present invention will be described in more detail below. Attached Figure Description

[0009] Figure 1 An example transaction system architecture capable of implementing at least some of the implementation schemes is described;

[0010] Figure 2 An illustrative example of a service computer, according to at least some implementation schemes, is described, capable of determining a confidence level for a transaction based on location data provided in an authorization request and location data provided at the time of request for dynamic data.

[0011] Figure 3The communication flow of the instance confidence level assessment process according to at least some implementation schemes is described;

[0012] Figure 4 A flowchart illustrating the process of requesting dynamic data and executing transactions using the dynamic data according to at least some implementation schemes is shown; and

[0013] Figure 5 A flowchart is depicted illustrating the process of providing dynamic data and making authorization decisions on transactions that use the dynamic data, based on at least some implementation schemes. Detailed Implementation

[0014] In the following description, various implementation schemes will be described. For illustrative purposes, specific configurations and details are set forth to provide a thorough understanding of the implementation schemes. However, it will also be apparent to those skilled in the art that the implementation schemes can be practiced without such specific details. Furthermore, well-known features may be omitted or simplified so as not to obscure the described implementation schemes.

[0015] Before discussing the details of some embodiments of the invention, a description of some terms may help in understanding the various embodiments.

[0016] An "access device" can be any suitable device for communicating with a merchant's computer or transaction processing network and interacting with a payment device, a user's computer equipment, and / or a user's mobile device. Access devices can typically be located in any suitable location, such as at a merchant's location. Access devices can take any suitable form. Some examples of access devices include POS devices, cellular phones, PDAs, personal computers (PCs), tablets, handheld dedicated readers, set-top boxes, electronic cash registers (ECRs), automated teller machines (ATMs), virtual cash registers (VCRs), kiosks, security systems, access systems, websites, etc. Access devices can use any suitable contact or contactless operating mode to send or receive data from or associated with a portable communication device. In some embodiments where the access device may include a POS terminal, any suitable POS terminal can be used, and it may include a reader, a processor, and a computer-readable medium. The reader may include any suitable contact or contactless operating mode. For example, an exemplary card reader may include a radio frequency (RF) antenna, an optical scanner, a barcode reader, or a magnetic stripe reader for interacting with a portable communication device. In some embodiments, the access device may also be referred to as a terminal device.

[0017] An "access key" can be any identifier or sequence of characters configured to enable access to a resource. In some embodiments, the resource accessed using the access key can be a restricted or secure area, a restricted or secure storage device, etc. In some embodiments, the access key can be a string corresponding to account information. In some embodiments, the access key can be a password or code. In some embodiments, the access key can be a key used to generate information to obtain access to the resource. The access key can also be a dynamic key that changes over time, and / or a restricted key whose use is subject to one or more restrictions.

[0018] "Account parameters" can refer to information associated with an account that can be used to conduct transactions on that account. Examples of account parameters may include information that can identify a user's account (e.g., a real account identifier, alternative account identifier, dynamic account identifier, token, etc.), data or information related to the account's state, one or more keys used to generate password information, and data or information associated with one or more keys. Account parameters can be semi-static or dynamic. Dynamic account parameters can be account parameters with a finite lifespan, and once expired, they can no longer be used for transactions until the account parameters are replenished, refreshed, or updated. Dynamic account parameters can be frequently replenished during the account's lifetime. Examples of dynamic account parameters may include dynamic keys (e.g., restricted access keys, access keys, etc.). In some implementations, dynamic account parameters may include dynamic account identifiers, such as tokens, dynamic master accounts (PANs), etc. Semi-static account parameters can be account parameters with an extended lifespan than dynamic account parameters, and may not be replenished as frequently as dynamic account parameters, or may not be replenished at all during the account's lifetime. Examples of semi-static account parameters may include real account identifiers, such as real PANs.

[0019] An "acquiring party" is typically a business entity (such as a commercial bank) with a business relationship with a specific merchant or other entity. Some entities can perform the functions of both an issuer and an acquirer. Some implementations may include such a single-entity issuer-acquiring party.

[0020] The term “certification” and its derivatives can refer to the process of verifying the certificates of endpoints (including, but not limited to, applications, people, devices, processes, and systems) to ensure that the endpoints are the objects they are claimed to be.

[0021] An "authorization request message" can be an electronic message sent to request authorization for a transaction. Authorization request messages can be sent to a payment processing network and / or the issuer of a payment card. According to some implementation schemes, authorization request messages may conform to ISO 8583, a standard for systems for exchanging information about electronic transactions associated with payments made by a user using a payment device or payment account. Authorization request messages may include information that can be used to identify the account. Authorization request messages may also include one or more additional data elements, such as a service code, expiration date, etc. Authorization request messages may also include transaction information (such as any information associated with the current transaction, such as the transaction amount, merchant identifier, merchant location, etc.), and any other information that can be used to determine whether to identify and / or authorize the transaction. Authorization request messages may also include other information, such as information identifying the access device that generated the authorization request message, information about the location of the access device, etc.

[0022] An "authorization response message" can be an electronic message reply to an authorization request message. The authorization response message can be generated by the issuing financial institution or the payment processing network. The authorization response message can include (by way of example only) one or more of the following status indicators: Approval - the transaction is approved; Rejection - the transaction is not approved; or Call Center - further information is pending, and the merchant must call the toll-free authorization number. The authorization response message may also include an authorization code, which can be a code indicating approval of the transaction returned by the credit card issuing bank to the merchant's computer in response to the authorization request message in the electronic message (directly or via the payment processing network). The code can serve as evidence of authorization. As described above, in some implementations, the payment processing network may generate or forward authorization response messages to the merchant.

[0023] A "password" can refer to an encrypted representation of certain information. A password can be used by the recipient to determine whether the password generator has the correct key, for example, by encrypting the underlying information using a valid key and comparing the result with the received password.

[0024] A "key" can refer to a piece of information used in a cryptographic algorithm to transform input data into another representation. A cryptographic algorithm can be an encryption algorithm that transforms original data into alternative representations, or a decryption algorithm that transforms encrypted information back into original data. Examples of cryptographic algorithms include Triple Data Encryption Standard (TDES), Data Encryption Standard (DES), and Advanced Encryption Standard (AES). A key can also be called an encryption key.

[0025] "Dynamic data" can refer to data that changes over time. Transactions can be executed using certain types of dynamic data. Instances of such dynamic data may include dynamic account parameters, such as dynamic keys (e.g., restriction keys, access keys, etc.), dynamic account identifiers (e.g., tokens, dynamic PANs), etc.

[0026] A "dynamic key" can be a key that changes over time. A dynamic key can be any identifier or character sequence that can be changed or refreshed over time. Instances of dynamic keys can include access keys that are configured to enable access to resources, or restricted keys whose use is subject to one or more restrictions.

[0027] A "restricted use key" can be a key that is valid as long as the restricted use conditions have not been exceeded. In some implementations, a restricted use key can be associated with multiple restricted use conditions, such that the restricted use key is valid until one or more of these conditions are met. In some implementations, a restricted use key can be a key. In some implementations, a restricted use key can also be an access key.

[0028] "Issuer" can generally refer to a commercial entity (e.g., a bank) that maintains accounts for users associated with a portable communication device, such as accounts registered in mobile applications installed on the portable communication device. The issuer can also send account parameters associated with the account to the portable communication device. The issuer can be associated with a host system that performs some or all of the issuer's functions on its behalf.

[0029] "Usage restriction conditions" can refer to conditions that limit the use of a piece of information. Usage restriction conditions can be exceeded or exhausted when basic conditions are met. For example, usage restriction conditions may include a lifetime indicating the amount of time a piece of information is valid, and once that amount of time has elapsed, the usage restriction conditions are exceeded or exhausted, and the information may become invalid and no longer usable. As another example, usage restriction conditions may include the number of times a piece of information can be used, and once that number of times the information has been used, the usage restriction conditions are exceeded or exhausted, and the information may become invalid and no longer usable.

[0030] A “merchant” can typically be an entity that participates in transactions and can sell goods or services, or provide access to goods or services.

[0031] A "mobile application" can be any application stored on or executed from a mobile device. In some embodiments, a mobile application can be used to make payments via a mobile device. In some embodiments, a mobile payment application can be an e-wallet or digital wallet application. In some embodiments, a mobile payment application can be linked to one or more payment accounts. In some embodiments, a mobile payment application can store one or more "tokens" or representations of payment accounts. In some embodiments, a mobile payment application can be linked to a decentralized virtual currency. In some embodiments, a mobile payment application can include applications used to complete transactions without using currency. For example, a mobile payment application can complete transactions using reward points or store credits.

[0032] A "mobile device" can be a device that can be transported and operated by a user and includes one or more electronic components (e.g., an integrated chip). A communication device can provide the ability to communicate remotely with a network. A mobile device can be configured to transmit data or communications to and receive data or communications from other devices. A mobile device can be in the form of any portable device, such as a mobile phone (e.g., a smartphone, cellular phone, etc.), a tablet computer, a portable media player, a personal digital assistant device (PDA), a wearable computing device (e.g., a smartwatch), an e-reader device, or a card (e.g., a smart card) or a pendant. Examples of mobile devices may also include portable computing devices (e.g., laptops, netbooks, ultrabooks, etc.). A mobile device can also be in the form of a vehicle (e.g., a car) or integrated into a vehicle (e.g., a vehicle information system).

[0033] A “real account identifier” can include the original account identifier associated with the payment account. For example, a real account identifier can be the primary account number (PAN) issued by the issuer for a card account (e.g., a credit card, debit card, etc.). For example, in some implementations, a real account identifier can include a sixteen-digit number, such as “4147 0900 0000 1234”. The first six digits of the real account identifier (e.g., “414709”) can represent the actual issuer identifier (BIN) that identifies the issuer associated with the real account identifier.

[0034] A "server computer" can include a powerful computer or cluster of computers. For example, a server computer can be a mainframe, a small cluster of computers, or a group of servers operating like cells. In one example, a server computer can be a database server coupled to a web server. A server computer can be coupled to a database and can include any hardware, software, other logic, or combination of the foregoing for serving requests from one or more client computers. A server computer can include one or more computing devices and can use any computing architecture, arrangement, and compilation from a variety of computing architectures, arrangements, and compilations to serve requests from one or more client computers.

[0035] A "token" can include a substitute identifier for some information. For example, a payment token can include an identifier for a payment account, which is a substitute for an account identifier such as a primary account number (PAN). For example, a token can include a string of alphanumeric characters that can be used as a substitute for the original account identifier. For example, the token "4900 0000 0000 0001" can be used instead of the PAN "4147 0900 0000 1234". In transactions, instead of using a physical account identifier (such as a PAN) to identify a user's account, a token can be used instead to identify the account. By using a token as a substitute for an account identifier, the risk of including physical account information can be mitigated. In some implementations, the token can be "preserved format" and can have a numerical format consistent with account identifiers used in existing payment processing networks (e.g., the ISO 8583 Financial Transaction Message Format). In some implementations, the token can be used in place of the PAN to initiate, authorize, settle, or complete a payment transaction. In other systems where the original certificate is typically provided, the token can also be used to represent the original certificate. In some implementations, the token value can be generated such that the original PAN or other account identifier cannot be recovered from the token value by computation. Additionally, in some implementations, the token format can be configured to enable the entity receiving the token to identify it as a token and to recognize the entity issuing the token.

[0036] The term "verification" and its derivatives can refer to the process of using information to determine whether an underlying subject is valid under a given set of conditions. Verification can include any comparison of information to ensure that certain data or information is correct, valid, accurate, legitimate, and / or credible.

[0037] Details of some embodiments of the present invention will now be described.

[0038] Embodiments of the present invention relate to techniques for trading systems in which transactions executed using dynamic data can be approved or rejected, at least in part, based on a confidence level associated with the transaction. The trading system can collect information related to the location of the request for dynamic data, the location of the execution of the transaction, and the timing of both the request for dynamic data and the execution of the transaction. In some embodiments, the confidence level can be calculated based on the distance between two locations and the amount of time between the dynamic data request and the transaction.

[0039] Figure 1 An example transaction system architecture 100 capable of implementing at least some embodiments of this disclosure is depicted. Figure 1 In this embodiment, mobile device 102 is depicted communicating with mobile application server 106 via one or more communication networks 104. Mobile application server 106 may communicate with token server 108 and / or issuing computer 110. In some embodiments, mobile device 102 may be used to conduct transactions via terminal device 114. Upon receiving an instruction to conduct a transaction, terminal device 114 may transmit an authorization request message to acquiring computer 116, which may then forward the authorization request message to issuing computer 110 via transaction processing network 118 for authorization. Issuing computer 110 may authorize or reject a transaction based on one or more factors associated with the transaction. In some embodiments, issuing computer 110 may make this decision based at least in part on a confidence level associated with the transaction.

[0040] Mobile device 102 can be any type of portable communication device, such as, but not limited to, mobile phones, smartphones, personal digital assistants (PDAs), laptops, tablets, etc. Alternatively, mobile device 102 can be any type of wearable technology device, such as watches, headphones, glasses, etc. It can also be a car with remote communication capabilities.

[0041] Mobile device 102 may include one or more processors 120 capable of processing user input. Mobile device 102 may also include one or more input sensors 122 for receiving user input. Various input sensors 122 capable of detecting user or environmental input may be present, such as keyboards, mice or pointing devices, accelerometers, speedometers, cameras, microphones, satellite positioning system receivers (e.g., GPS receivers), etc. In some embodiments, mobile device 102 may include a contactless interface 124 configured to enable communication between mobile device 102 and terminal device 114. Examples of the contactless interface 124 may include one or more radio frequency (RF) transceivers configured to send and receive communications using near field communication (NFC), or other radio frequency or wireless communication protocols such as Bluetooth, Bluetooth Low Energy (BLE), Wi-Fi, iBeacon, etc. In some embodiments, the contactless interface 124 may include an optical interface (e.g., a display screen) to present payment information in image form (such as a quick response (QR) code or other machine-readable code) to the terminal device 114 in the embodiment, wherein the terminal device 114 includes an optical code scanner or reader. Embodiments of one or more modules on the mobile device 102 may be stored and executed from its memory 126.

[0042] Turning more specifically to the contents of memory 126, according to at least some embodiments, memory 126 may include operating system 128 and one or more modules configured to cause processor 120 to execute instructions. For example, memory 126 may include mobile application 130, which is configured to work with processor 120 to convey transaction data (e.g., tokens and / or other account information) to terminal device 114 to complete a transaction. Furthermore, the mobile application may be configured to transmit location data of mobile device 102 and, for example, provide location data to terminal device 114 for transaction processing.

[0043] In some embodiments, mobile application 130 may include code configured, when executed by processor 120, to provide one or more pieces of data to an external device. For example, mobile application 130 may include code executable by processor 120 to receive location information from input sensor 122 and provide that location information to terminal device 114. In some embodiments, mobile application 130 may be configured to manage payment accounts that perform transactions using dynamic data (e.g., dynamic account identifiers, such as tokens and / or dynamic keys). For example, mobile application 130 may be configured to cause mobile device 102 to request dynamic data from token server 108 via mobile application server 106. Mobile application 130 may be configured to include location data in the request for dynamic data from token server 108. In some embodiments, mobile device may use dynamic data (e.g., dynamic keys) to generate a password for performing a transaction. In some embodiments, mobile application 130 may be configured to cause mobile device 102 to provide dynamic data and / or transaction data (e.g., passwords) generated from the dynamic data to terminal device 114 to complete a transaction. Mobile application 130 may also be configured to include location data in the information provided to the terminal. In some embodiments, before performing a transaction using mobile application 130, the user of mobile device 102 may be required to log in to mobile application 130 or otherwise verify their identity. In some embodiments, mobile application 130 may be a mobile wallet application stored on or executed from a smartphone device. Mobile application 130 may provide access to decentralized virtual currencies. Mobile application 130 may be configured to provide a payment account's "token" or other representation to the access device to complete a transaction. In some embodiments, mobile application 130 may include account information that enables an individual to access a secure location or resource.

[0044] In some instances, communication network 104 and / or transaction processing network 118 may include any or a combination of many different types of networks, such as cable networks, the Internet, wireless networks, cellular networks, and other private and / or public networks. Furthermore, communication network 104 and / or transaction processing network 118 may include multiple different networks. For example, mobile device 102 may utilize a wireless local area network (WLAN) to communicate with a wireless router, which may then route the communication to mobile application server 106 via a public network (e.g., the Internet). In some embodiments, transaction processing network 118 may be an electronic payment network (e.g., VisaNet).

[0045] Mobile application server 106 can be any computing device or multiple computing devices configured to provide backend support for mobile application 130. In some embodiments, mobile application server 106 can be configured to perform one or more computations on behalf of mobile application 130, which is stored on and executed from mobile device 102. In some embodiments, mobile application 130 can communicate periodically with mobile application server 106. For example, mobile application 130 can receive updates or other instructions from mobile application server 106. In some embodiments, mobile application 130 and mobile application server 106 can utilize proprietary encryption and / or decryption schemes to secure communication between them.

[0046] Token server 108 can be any computing device or multiple computing devices configured to enable secure access to account information using tokens (alternative identifiers for account information). Token server 108 can be configured to implement or be equipped with access to token service 131 and / or token store 132. Token service 131 can be any system capable of generating, processing, and storing tokens and associated account information (e.g., dynamic keys). As noted above, tokens can have their own set of user restrictions, and token service 131 can manage the deployment and use of tokens according to these restrictions. Token service 131 can communicate with token store 132, where generated tokens are stored in association with account information. Specifically, token store 132 can maintain a mapping between tokens and real account identifiers (e.g., PANs) represented by the tokens. During transaction processing, token store 132 can be queried to retrieve the real account identifier or PAN associated with the token.

[0047] Token server 108 can also be configured to generate dynamic keys (e.g., restricted access keys) associated with tokens and / or accounts. For example, token server 108 can provide the dynamic key to a mobile device, which is used to generate a password to execute a transaction. When verifying the authenticity of the token provided in the authorization request, the token server can independently generate a password from the dynamic key associated with the token and compare it with the password provided in the authorization request message. Token server 108 can also be configured to determine the confidence level associated with a transaction based on location information provided at the time the dynamic key is generated and location information provided at the time of the transaction.

[0048] The issuing computer 110 can be any computing device or multiple computing devices configured to receive authorization request messages for transactions, authorize or reject transactions, and provide authorization response messages based on whether a transaction has been authorized or rejected. In some embodiments, the issuing computer 110 can be configured to determine a confidence level associated with a transaction based on location information provided at the time of requesting dynamic data and location information provided at the time of the transaction. The issuing computer 110 can determine whether to authorize or reject a transaction based on the confidence level associated with the transaction.

[0049] Terminal device 114 can be any computing device or multiple computing devices configured to complete a transaction. In some embodiments, the terminal device can be a point-of-sale (POS) device, such as a register. In some embodiments, terminal device 114 can restrict access to resources or services. In some embodiments, terminal device 114 can be owned and / or operated by one of the parties to a transaction in which terminal device 114 is configured to complete. In some embodiments, terminal device 114 can be configured to transmit transaction information to mobile device 102 and, in response, receive information from mobile device 102 that can be forwarded to the acquiring party (e.g., account information).

[0050] Acquiring computer 116 can be any computing device or multiple computing devices configured to process transaction information received from terminal device 114 and generate an authorization request message to be transmitted to issuing computer 110. In some embodiments, acquiring computer 116 and issuing computer 110 can be the same entity. For example, issuing computer 110 can be configured to receive transaction information from terminal device 114 and authorize or reject transactions. In some embodiments, the acquiring party can be a third-party entity (e.g., an entity not affiliated with issuing computer 110 or terminal device 114).

[0051] To simplify the explanation, Figure 1 A specific number of components are shown. However, it should be understood that embodiments of the invention may include more than one of each component. Furthermore, some embodiments of the invention may include more than one of each component. Figure 1 The components shown are fewer or more components. Furthermore, Figure 1 The components can communicate using any appropriate communication protocol through any suitable communication medium (including the Internet).

[0052] Figure 2 A schematic example of a service computer 200, according to at least some embodiments, is depicted, capable of determining a level of confidence for a transaction based on location data provided in an authorization request and location data provided at the time of requesting dynamic data. In some embodiments, the service computer 200 may be... Figure 1An exemplary issuer computer 110. In some embodiments, the service computer 200 may be... Figure 1 An example token server 108.

[0053] The service computer 200 can be any type of computing device, including server computers located in remote locations. Additionally, it should be noted that in some implementations, the service computer 200 can be embodied by multiple virtual machines implemented in a managed computing environment. A managed computing environment can include one or more rapidly provisioned and published computing resources, which may include computing devices, networking devices, and / or storage devices. A managed computing environment can also be referred to as a cloud computing environment.

[0054] In one illustrative configuration, the service computer 200 may include at least one memory 202 and one or more processing units (or processors) 204. The processor 204 may be suitably implemented in hardware, computer-executable instructions, firmware, or a combination thereof. The computer-executable instructions or firmware implementation of the processor 204 may include computer-executable instructions or machine-executable instructions written in any suitable programming language for performing the various functions described.

[0055] Memory 202 may store program instructions that are loadable and executable on processor 204, as well as data generated during the execution of these programs. Depending on the configuration and type of service computer 200, memory 202 may be volatile (such as random access memory (RAM)) and / or non-volatile (such as read-only memory (ROM), flash memory, etc.). Issuer computer 110 may also include additional memory 206, such as removable or non-removable memory, including but not limited to magnetic storage, optical disk and / or magnetic tape storage. Disk drives and their associated computer-readable media may provide non-volatile storage of computer-readable instructions, data structures, program modules and other data for the computing device. In some embodiments, memory 202 may include a variety of different types of memory, such as static random access memory (SRAM), dynamic random access memory (DRAM) or ROM. Turning more specifically to the contents of memory 202, memory 202 may include operating system 208 and one or more applications or services for implementing the features disclosed herein, the application or service including at least a module (location evaluation module 210) for evaluating the location associated with one or more transactions and comparing that location with the location associated with a request for dynamic data. The memory 202 may also include transaction data 212 and location data 214, whereby transaction data 212 provides data associated with one or more previously conducted transactions, and location data 214 provides location data associated with one or more mobile devices. In some embodiments, transaction data 212 and / or location data 214 may reside outside of the service computer 200. For example, one or more of these databases may be maintained by a third-party entity (an entity not affiliated with the service computer 200).

[0056] Removable and non-removable memory 202 and additional memory 206 are examples of computer-readable storage media. For example, a computer-readable storage medium may include volatile or non-volatile, removable or non-removable media implemented with any method or technique for storing information such as computer-readable instructions, data structures, program modules, or other data. As used herein, a module may refer to a programmed module executed by a computing system (e.g., a processor) that is part of mobile device 102 or service computer 200. Service computer 200 may also include a communication connection 216 that allows service computer 200 to communicate with a stored database, another computing device or server, one or more terminal devices, and / or other devices on a network. Service computer 200 may also include input / output (I / O) devices and / or ports 218, such as for enabling connections to a keyboard, mouse, pen, voice input device, touch input device, display, speaker, printer, etc.

[0057] Turning more specifically to the contents of memory 202, memory 202 may include operating system 208. One or more applications or services for implementing the features disclosed herein, including location assessment module 210, may also be stored in memory 202. Transaction data 212 and location data 214 may include any suitable persistent data storage system. In some embodiments, transaction data 212 and / or location data 214 may be stored in one or more databases. Information stored in transaction data 212 or location data 214 may be accessed by location assessment module 210 through database queries or any other suitable data retrieval means.

[0058] In some implementations, the location assessment module 210 may be combined with the processor 204 and configured to receive two sets of location data and determine a confidence level associated with the transaction based on the amount of time between the acquisition of the two locations. In some implementations, the service computer 200 may receive from a token server location information indicating the location reported by the mobile device in a dynamic data request and the time when the mobile device requested the dynamic data. In some implementations, the service computer 200 may receive the location information directly from the mobile device when requesting dynamic data.

[0059] The issuing computer may also receive location information for transactions executed using dynamic data. For example, a terminal may receive dynamic data from a mobile device or transaction data generated from dynamic data to complete a transaction. In some embodiments, the transaction data may include a password generated by the mobile device using dynamic data (e.g., a dynamic key, such as a restriction key or access key). The terminal may then provide various transaction details to the acquiring party, which may generate an authorization request message to complete the transaction. The authorization request message may include dynamic data, and / or transaction data generated from the dynamic data (e.g., in the form of a password), and location information for the transaction. In some embodiments, the location information may be provided by the mobile device. In some embodiments, the location information may be location information associated with a terminal device.

[0060] Once the issuer has received an authorization request and transaction location information, including dynamic data or transaction data generated using dynamic data (e.g., a password generated using a dynamic key), the location information is provided to the location assessment module 210. The location assessment module 210 can calculate the confidence level to be associated with the transaction. For example, the issuer may receive an authorization request message including a password and location information for the transaction. In some embodiments, the service computer 200 can verify a password by independently generating a password from a dynamic key associated with the account and comparing that password with a password received in the transaction. In some embodiments, the service computer 200 can decrypt the password and identify the dynamic key from the decrypted information. In some embodiments, the service computer 200 can determine whether the dynamic key is still valid (e.g., whether one or more restrictions on use have been met or exceeded) before or after verifying the password. If the dynamic key is determined to be valid, the issuer can query one or more databases to identify the location of the mobile device associated with the identified dynamic key generation request. In some embodiments, the service computer 200 can query the token server that generated the dynamic data for location information provided by the mobile device at the time the dynamic data was generated. The location assessment module 210 can compare first location information (location information associated with the mobile device received in the request to generate dynamic data) with second location information (location information received in the authorization request message) to determine the confidence level associated with the transaction.

[0061] In some implementations, the location assessment module 210 can be configured to assess the first location information and the second location relative to the amount of time elapsed between the acquisition of the location information. For example, if the first location information indicates that the mobile device is in New York when the dynamic data is requested, and the second location information indicates that a transaction using the dynamic data is executed in Paris, a confidence level for the transaction can be generated based on the amount of time between the request for the dynamic data and the transaction. In this example, if the transaction occurs only two hours after the dynamic data is requested, the confidence level can be determined to be very low (because it is impossible for the mobile device to travel from New York to Paris within two hours). However, if the transaction occurs 10 hours after the dynamic data is requested, the confidence level can be calculated to be higher. In some implementations, other factors can be used when calculating the confidence level for the transaction. The location assessment module 210 can use past transaction data when calculating its confidence level. In some implementations, one or more variables of the function used to calculate the confidence level can be adjusted based on past transaction data. For example, if the mobile device frequently makes transactions from Paris, the confidence level in the example given above can be calculated to be higher. In another instance, location assessment module 210 may use a distance-time ratio or a time-distance ratio. In some implementations, an acceptable distance-time ratio may be calculated based on past transactions. For example, if the mobile device associated with a transaction typically performs transactions over long distances within a short timeframe (which may also indicate that the user of the mobile device is a frequent traveler), the confidence level may be higher than if the mobile device is associated with a low distance-time ratio.

[0062] In some implementations, the confidence level can be determined by the location assessment module 210 as a function of elapsed time. For example, a distance threshold (e.g., a maximum distance value) can be calculated by multiplying the amount of time elapsed between the request for dynamic data and the transaction by a predetermined value. In this example, the distance between two location pieces of information can be compared to the distance threshold to determine the confidence level for the transaction. Authorizing entities (e.g., issuers or token service providers) can systematically reject transactions with distances greater than the distance threshold. In some implementations, a distance-time ratio can be calculated for the transaction and compared to an acceptable distance-time ratio. For example, 100 miles and 10 hours (600 minutes) apart can be interpreted as 1 / 6 mile per minute. In this example, the location assessment module 210 can identify a predetermined acceptable distance-time ratio of 1 / 3, making any distance-time ratio greater than this value suspicious. The distance-time ratio can be specific to a particular user, account holder, mobile device, or dynamic key.

[0063] In some implementations, transaction data 212 may include information about transactions that have been conducted in the past. In some implementations, transaction data 212 may be used to calculate acceptable values ​​for the distance between two locations to be evaluated and the time between the two locations to be collected (e.g., distance-time ratio). In some implementations, transaction data 212 may be queried to identify one or more transactions associated with a specific individual or account.

[0064] In some implementations, location data 214 may include location information relating to the mobile device at the time the dynamic data is requested, the location where the transaction is executed, or both. Location data 214 may include a single database table or multiple database tables. For example, location data 214 may include separate tables for the location of the mobile device at the time the dynamic data is requested and the location where the transaction is executed. In some implementations, location data 214 may include information stored at different entities / components of the system. For example, a portion of location data 214 may be stored at a token server, and another portion of location data 214 may be stored at the issuing computer.

[0065] Service computer 200 can represent Figure 1 The system architecture 100 depicted herein comprises various components. It should be noted that the location assessment module 210 may be stored on and executed from various components of the system. In some embodiments, the location assessment module 210 may be stored on the issuing computer (e.g., a computer with a different location). Figure 1 On the issuer computer 110 (the instance of the location assessment module 210). In an implementation where the location assessment module 210 is stored on and executed from the issuer computer, the location included in the request to generate dynamic data can be provided to the issuer computer (at the time the request is generated or at the request of the issuer computer), and transaction-related location information can be provided to the issuer computer via an authorization request message. In some implementations, the location assessment module 210 may be provided by a token server (e.g., Figure 1 The instance token server 108 is implemented. In an implementation where the location assessment module 210 is stored on and executed from the token server, the issuing computer can forward location information from the authorization request to the token server, and the location assessment module 210 can determine the confidence level for the transaction by comparing the location data of the transaction with the location data stored at the time of requesting dynamic data. In some implementations, the location assessment module 210 may be implemented by an application server (e.g., Figure 1 The instance application server 106 is implemented. In an implementation where the location assessment module 210 is stored on and executed from the application server, location information can be collected from the mobile device at the time a request to generate dynamic data is made. The issuing computer can forward the location information from the authorization request to the application server, which is then used by the location assessment module 210 to generate a confidence level.

[0066] Figure 3 A communication flow for an instance confidence level assessment process according to at least some embodiments is described. The confidence level assessment process may be initiated from mobile device 102 with an installed mobile application, wherein the mobile application includes instructions for communicating with mobile application server 106. The mobile application may be pre-installed on mobile device 102 (e.g., by a manufacturer or wireless provider) or may be downloaded and installed by a user of mobile device 102. The mobile application may be executed when initiated by a user of mobile device 102. For example, a user may open the mobile application on mobile device 102. In some embodiments, the mobile application may be executed to complete a transaction with another electronic device using dynamic data (e.g., dynamic account identifiers, such as tokens, dynamic PANs, etc., and / or dynamic keys, such as restriction keys or access keys, etc.). The user may use the mobile application to request dynamic data, or the mobile application may initiate a request for automatically generated dynamic data (e.g., without user-initiated request). When the mobile application is executed, at 302, mobile device 102 may transmit a request to generate dynamic data to mobile application server 106. The request may include location information acquired using one or more input sensors of the mobile device. Location information acquired using input sensors can include location details based on any suitable coordinates (such as GPS data, cellular tower triangulation data, etc.).

[0067] Upon receiving a request for dynamic data, mobile application server 106 can query information related to the mobile device from account data stored on mobile application server 106. For example, the mobile application server can identify the account associated with the mobile device based on an identifier (e.g., phone number, serial number, International Mobile Equipment Identifier (IMEI), or any other suitable identifier). Once identified, the mobile application server can retrieve account information associated with the identified account (e.g., payment account, user identifier, account number, etc.). In some embodiments, mobile application server 106 may also store the received location information in data storage. At 304, mobile application server 106 may then send a request to generate dynamic data to token server 108. In some embodiments, the sent request may include additional details (e.g., at least a portion of the retrieved account information). The sent request may also include location information collected by mobile device 102.

[0068] Upon receiving a request to generate dynamic data, token server 108 may identify one or more account details associated with the mobile device. For example, token server 108 may identify the payment account associated with the mobile device for which dynamic data should be generated. In some embodiments, account information may be identified based on the received request for dynamic data. In some embodiments, token server 108 may query a database of account data. Token server 108 may also identify location information associated with the request. In some embodiments, token server 108 may identify this location information within the request itself. In other embodiments, token server 108 may establish a session with mobile device 102 upon receiving a request for dynamic data to request location information. Dynamic data may include a dynamic key, generated by token server 108 based on a key index, which acts as a seed for generating the dynamic key. Once dynamic data has been generated, it may be stored in association with the account associated with mobile device 102. Dynamic data may also include a dynamic account identifier (e.g., a token or dynamic PAN), generated by token server 108 based on the account associated with the user. Additionally, at 306, the token server 108 can respond to a request for dynamic data from the mobile application server 106 with a response including the generated dynamic data. At 308, the mobile application server 106 can forward the received dynamic data to the mobile device 102. The mobile device 102 can then store the received dynamic data in its memory for later use. In some embodiments, the functionality of the mobile application server 106 can be integrated with the token server 108, so the mobile device 102 can directly request dynamic data from the token server 108.

[0069] At 310, token server 108 may provide location information received in a request for dynamic data generation to issuing computer 110. In some embodiments, location information may be provided to issuing computer 110 when generating dynamic data. In some embodiments, location information may be provided to issuing computer 110 when a request is made or a query is submitted.

[0070] When a mobile device detects that a transaction needs to be completed using dynamic data, it can generate a password from the dynamic data (e.g., a dynamic key) by encrypting one or more pieces of information. In some embodiments, the mobile application can generate a password from the dynamic key when executing the mobile application to complete the transaction. In some embodiments, the mobile device 102 can generate a password when it receives transaction information from the terminal device 114. For example, the mobile application can execute on the mobile device 102, and the mobile device can move within proximity of a wireless communication interface communicatively coupled to the terminal device 114. In this example, the terminal device 114 can provide transaction details to the mobile device 102 via the wireless communication interface. Upon receiving the transaction details, the mobile application can generate a password for the transaction. This password may include the dynamic key and one or more transaction details received from the terminal device 114.

[0071] At point 312, mobile device 102 may provide a password to terminal device 114 to complete a transaction. In some embodiments, the transaction may be a purchase transaction (e.g., a transaction for payment of goods or services). In some embodiments, the transaction may be non-financial in nature (e.g., a transaction for access to a secure area). In some embodiments, the password may be provided by a mobile application via a contactless reader communicatively coupled to terminal device 114. In some embodiments, the mobile application may provide the location of the mobile device along with the password to terminal device 114. In some embodiments, dynamic data itself may be provided to terminal device 114. For example, mobile device 102 may provide a dynamic account identifier (e.g., a token or dynamic PAN) to terminal device 114 to execute a transaction. In some embodiments, the mobile device may provide a dynamic account and a password generated using a dynamic key.

[0072] At point 314, upon receiving a password associated with a transaction, terminal device 114 may transmit dynamic data and / or transaction data (e.g., the password) generated from the dynamic data to acquiring computer 116. In some embodiments, terminal device 114 may generate an authorization request message including the received dynamic data and / or transaction data (e.g., the password) generated from the dynamic data. In some embodiments, terminal device 114 may forward the dynamic data and / or transaction data (e.g., the password) along with one or more transaction details to acquiring computer 116, which may generate an authorization request message. In some embodiments, terminal device 114 may transmit location information received from mobile device 102 to acquiring computer 116. In some embodiments, terminal device 114 may provide its own location information to acquiring computer 116. For example, the terminal device may be associated with a terminal identifier, which may be associated with location information that the terminal device can retrieve and execute for each transaction transmission.

[0073] At point 316, the acquiring computer 116 may transmit an authorization request message to the issuing computer 110. In some embodiments, the issuing computer 110 may verify dynamic data and / or transaction data (e.g., passwords) generated from the dynamic data or request verification from the token server 108. In some embodiments, the issuing computer 110 may determine whether any restrictions on the use of the dynamic data have been met or exceeded. If met or exceeded, the issuing computer 110 may reject the transaction associated with the authorization request message.

[0074] In some implementations, the issuing computer 110 may evaluate the location information received in the request to generate dynamic data, the location information received in the authorization request message, and the difference between the time of acquisition of the two location information to determine the confidence level associated with the transaction. For example, at 318, the issuing computer 110 may send a request for location information associated with the request to generate dynamic data to a token server 108. The token server 108 may retrieve the location information and provide it to the issuing computer 110 in its response to the query. In another instance, the issuing computer 110 may have previously been provided with location information associated with the request to generate dynamic data (e.g., at 310). The issuing computer 110 may retrieve this location information from a data store to calculate the confidence level.

[0075] In some implementations, at point 318, the issuing computer 110 may provide the location information received in the authorization request message to the token server 108, allowing the token server 108 to calculate a confidence level associated with the transaction. The confidence level may be returned to the issuing computer, enabling it to determine whether to authorize the transaction. In some implementations, this may be handled by one or more function calls. For example, 318 may represent a call to a function provided by the token server 108, where dynamic data and transaction location information are passed as parameters to the function call. During function initialization, the token server 108 may calculate the confidence level associated with the transaction. The confidence level may be provided to the issuing computer 110 as a return parameter of the function.

[0076] The issuing computer 110 can determine whether to authorize or reject a transaction at the terminal device 114. In making this determination, the issuing computer 110 may use a calculated confidence level associated with the transaction, along with one or more additional factors related to the transaction and / or the account. Based on the determination of whether to authorize or reject the transaction, the issuing computer 110 can generate an authorization response message indicating whether the transaction is approved or rejected. At 320, the authorization response message can be provided to the acquiring party. At 322, the authorization response message, or a message derived from the authorization response message, can then be provided to the terminal device 114.

[0077] Figure 4A flowchart is depicted illustrating the process of requesting dynamic data and providing dynamic data and / or transaction data generated from dynamic data in subsequent transactions. Process 400 is shown as a logic flowchart, where each operation represents a series of operations that can be implemented by hardware, computer instructions, or a combination thereof. In the context of computer instructions, an operation represents a computer-executable instruction stored on one or more computer-readable storage media, which, when executed by one or more processors, performs the operation. Generally, computer-executable instructions include routines, programs, objects, components, data structures, etc., that perform a particular function or implement a particular data type. The order in which the operations are described is not intended to be construed as a limitation, and any number of described operations may be omitted or combined in any order and / or in parallel to perform this process and any other process described herein.

[0078] Process 400 may begin when it is determined that a mobile device requires dynamic data to execute a future transaction. Upon making this determination, at 402, a request for dynamic data may be sent to a token server. In one scenario, a mobile application may be installed on the mobile device; upon its first execution, the mobile application may submit a request to a mobile application server, and subsequently to a token server. In another scenario, the mobile application, the mobile application server, or the token server may determine that one or more restrictions on the currently stored dynamic data have been met or exceeded (therefore the currently stored dynamic data is invalid), and a request should be made to replace the dynamic data. For example, the token server may determine that dynamic data stored on a particular mobile device (such as a dynamic account identifier or dynamic key) has expired. Upon making this determination, the token server may notify the mobile device or mobile application to request replacement of the dynamic data, or it may initiate a request to generate new replacement dynamic data for itself.

[0079] Regarding a request for dynamic data (or replacement dynamic data), the mobile device may provide location information associated with its current location. In some embodiments, the request to generate dynamic data may be initiated by a mobile application on the mobile device. The mobile device may acquire location information from one or more input sensors communicatively coupled to it and provide that location information in the request. In some embodiments, the request may be initiated by a token server or an application server. The token server may generate dynamic data and provide it to the mobile device, which may provide location information in response to receiving the dynamic data. In some embodiments, the location information may be stored by the token server. In some embodiments, the location information may be forwarded to and stored on the issuing computer.

[0080] At 404, in response to the request, the mobile device may receive the generated dynamic data. In some embodiments, the dynamic data may be stored by the mobile device in a secure memory storage area. For example, the dynamic data may be stored on an encrypted storage medium. In some embodiments, multiple pieces of dynamic data, such as dynamic account identifiers and / or dynamic keys, may be received by the mobile device. For example, upon receiving a request to generate dynamic data, the token server may generate a set of restricted-use keys to provide to the mobile device. In some embodiments, a set of restricted-use keys may include multiple one-time-use restricted-use keys.

[0081] At point 406, the mobile device may attempt to initiate a transaction using dynamic data. The mobile device may receive an instruction to complete the transaction using dynamic data at a terminal device. This instruction may be provided by the user of the mobile device or a terminal device communicating with the mobile device. In some embodiments, the mobile device may receive transaction information associated with the transaction to be completed. Upon receiving the instruction to complete the transaction, the mobile device may launch a mobile application.

[0082] At step 408, when a mobile application determines that it needs to use dynamic data to complete a transaction, it can determine whether one or more usage restrictions associated with the dynamic data have been met or exceeded. For example, the mobile application can determine whether the maximum number of times the dynamic data can be used has been exceeded. In another instance, the mobile application can determine whether expired data associated with the dynamic data has already been transmitted. If the dynamic data is no longer valid, the process can return to step 402, requesting replacement of the dynamic data upon return. In this case, the location information associated with the request to generate the dynamic data can be updated to the location of the mobile device at the time the request to replace the dynamic data was made.

[0083] At 410, the mobile device can determine its current location to be associated with the transaction. In some embodiments, the current location may be acquired from an input sensor (e.g., a Global Positioning System) configured to identify the location coordinates of the mobile device. Although process 400 depicts the association of transaction location information with the mobile device, in some embodiments, the transaction location information may be associated with a terminal (e.g., a point-of-sale terminal or a tag reader). Therefore, some embodiments of process 400 may not include block 410.

[0084] At position 412, a transaction password can be generated from dynamic data (e.g., a dynamic key). In some embodiments, a password can be generated by encrypting information using the dynamic key as an encryption key. In some embodiments, the information to be encrypted may include transaction details, such as the transaction account, unpredictable numbers received from the terminal, etc. In some embodiments, the information to be encrypted may also include location information for the mobile device. In some embodiments, password generation may be optional, for example, when performing a transaction that does not require a transaction password.

[0085] At 414, dynamic data and / or transaction data generated from the dynamic data (e.g., passwords), and possibly transaction location, may be provided to the terminal device. In some embodiments, the terminal device may receive the password from the mobile device and provide it to the acquiring party (e.g., a banking entity belonging to the owner of the terminal device). In some embodiments, the terminal device may provide location information along with the dynamic data and / or transaction data generated from the dynamic data (e.g., passwords) to the acquiring party.

[0086] Figure 5 A flowchart illustrating a process for providing dynamic data and making authorization decisions for transactions that use dynamic data, according to at least some implementation schemes, is depicted.

[0087] Process 500 may begin at 502, receiving a request for dynamic data. In some embodiments, the request may be provided by a mobile device (e.g., via a mobile application server). In this case, the request may include location information collected by the mobile device. In some embodiments, the request may be generated by a server computer when it determines that the dynamic data has expired or exceeded its usage restrictions. In this case, the server computer may establish a communication session with the mobile device that will receive the dynamic data in order to collect the location information collected by the mobile device. In some embodiments, the request may be received as a function call. For example, the application server (or the mobile device itself) may execute a function on the server computer that generates the dynamic data. In this example, the location of the mobile device may be passed as a function parameter.

[0088] At step 504, upon receiving a request for dynamic data, process 500 may store the location data received from the mobile device in a data storage associated with a timestamp. In some embodiments, the location data may be stored in a token vault (e.g., Figure 1 The token store (132) is used for this purpose. In some implementations, location information may be stored in a separate database table, which includes at least location, timestamp, and dynamic data. In some implementations, location information and timestamp may be stored in a database using a hash index. For example, dynamic data may be hashed to identify the data storage location for location information and timestamp. Time information may be annotated by the server computer upon receiving a request to generate dynamic data.

[0089] At point 506, process 500 can transfer dynamic data to the mobile device. In some implementations, the dynamic data can be returned as a function parameter. For example, the application server (or the mobile device itself) can execute a function that generates the dynamic data on the server computer. In this example, the dynamic data can be returned to the mobile device as a return parameter.

[0090] At point 508, the server computer may receive an authorization request associated with a transaction that has used dynamic data. For example, the authorization request may include a password generated from the dynamic key. In some embodiments, the server computer may independently generate the password from the dynamic key and compare it with the password received in the authorization request message. In some embodiments, the server computer may recognize the dynamic key when decrypting the password. The authorization request may be received from a terminal device (e.g., a point-of-sale device). The authorization request may be forwarded to the server computer by one or more intermediary entities that process authorization requests between the terminal device and the server computer.

[0091] At 510, process 500 may include determining location information and time data for the transaction. In some embodiments, the location associated with the transaction may be provided by a terminal device. For example, the terminal device may provide GPS coordinates in an authorization request. In some embodiments, the location may be determined from a lookup table or index. For example, the authorization request may include a terminal identifier associated with an access device or point of sale used in the transaction, and the terminal identifier may be queried from a database table that includes location information associated with each terminal device. In this way, the database table can be used to determine the location of the terminal device. In some embodiments, the location associated with the transaction may be provided by a mobile device. For example, the mobile device may generate a password that includes current information collected by the mobile device. When decrypting the password, the server computer may identify the location information associated with the transaction. The time information associated with the transaction may be annotated by the server computer when receiving an authorization request message for the transaction.

[0092] At 512, when determining the location and time data for a transaction, this information can be compared with stored location and time data to determine the confidence level associated with the transaction. In some embodiments, the location data associated with the transaction can be subtracted from the location data associated with the request for the dynamic key. The resulting distance can then be divided by the time difference between the request for dynamic data and the transaction to identify a value representing the speed of the mobile device. This value can be presented as a distance-time ratio. In some embodiments, this distance-time ratio can be compared with a threshold (e.g., an acceptable value) to determine the likelihood of executing the transaction using the mobile device. In some embodiments, the distance-time ratio can be compared with a range of acceptable values ​​to determine if the distance-time ratio falls within that range. In some embodiments, additional factors can be used to calculate the confidence level. For example, the confidence level can be determined based on the verification of the transaction cipher received at 508.

[0093] In some implementations, the confidence level can be calculated as a mathematical function of the location and timestamp associated with the dynamic data. As an illustration, location information can be represented as coordinates on a map (e.g., latitude and longitude). Therefore, the distance between the first and second locations can be expressed as:

[0094]

[0095] Among them, D L X1 and X2 are the latitudes of the corresponding locations, and Y1 and Y2 are the longitudes of the corresponding locations. Once the distance is determined, the server computer can correlate that distance with the time between the two requests.

[0096] In some implementations, the distance threshold can be calculated as a function of time. The distance D associated with the transaction. L This can then be compared with a calculated distance threshold. For example, the distance threshold can be calculated as follows:

[0097] D T =DPT*(T2–T1)

[0098] Where is the distance threshold, DPT is the distance value per unit time (e.g., a predetermined multiplier including distance units in the numerator and time units in the denominator), and T1 and T2 are the corresponding times associated with the request. In some implementations, the distance threshold may represent the maximum distance that can be associated with the use of dynamic data. For example, in some implementations, a distance greater than the distance threshold (D... T The distance (D) L A certain value can lead to the automatic rejection of a transaction. In some implementations, the confidence level can be determined by comparing the distance to a distance threshold. For example, the confidence level can be determined from the distance threshold (D). T Subtract distance (D) L This will give you the confidence level. In this example, the confidence level can be negative.

[0099] In some implementations, distance is related to time in order to determine whether it is feasible or possible for the mobile device to make two requests. For example, the distance-time ratio can be expressed as:

[0100] DT T =D L / (T2–T1)

[0101] Among them, DT T D is the distance-time ratio for the current transaction. L T1 and T2 are the distance between the two locations, and T1 and T2 are the response times associated with the request. In some implementations, DT... T It can be expressed as a fraction or a ratio. In some implementations, DT T This can be represented as a decimal value. It should be noted that any comparison of the distance between two location pieces of information with respect to time should be considered equal to the distance-time ratio above.

[0102] In some implementations, the confidence level can be calculated as having an inverse relationship with the calculated distance-time ratio (e.g., a higher distance-time ratio results in a lower confidence level for the transaction). For example, one possible function that can be used when calculating the confidence level based on the calculated distance-time ratio is:

[0103] C T =M(1 / DT) T )+C B

[0104] In this instance function, C T M represents the confidence level for the transaction, and C represents the predetermined multiplier. B DT represents the basic confidence value. T This represents the distance-time ratio for the current transaction. In some implementations, the multiplier (M) can be equal to 1. In some implementations, the basic confidence value (C) B ) can be equal to 0 (zero).

[0105] In some implementations, confidence values ​​can be calculated based on acceptable distance-time ratios. For example, the confidence level can be calculated as follows:

[0106] C T =M(DT) A -DT T )+C B

[0107] Among them, DT A It is an acceptable distance-time ratio. It should be noted that those skilled in the art will readily recognize many possible functions for performing the equivalent computation.

[0108] At point 514, once the confidence level for a transaction has been determined, that confidence level can be used to approve or reject the transaction. For example, if the confidence level is below the minimum confidence level, the transaction can be rejected. In some implementations, the confidence level may be just one of many factors used to approve or reject a transaction. For example, even if the confidence level for a transaction is very high, the transaction may still be rejected if the account associated with the dynamic key has insufficient funds. In some implementations, the confidence level may take into account traffic patterns in the vicinity of the transaction and / or at different times of the day.

[0109] At point 516, upon determining whether a transaction is approved or rejected, process 500 may respond to the authorization request message with an authorization response message. For example, an authorization response message may be generated that includes an indication that the transaction has been approved or rejected. The authorization response message may be transmitted directly to the terminal device associated with the transaction, or via an intermediary entity. In some embodiments, upon determining that a transaction has been approved, process 500 may provide access to resources. For example, upon determining that the confidence level associated with the transaction exceeds a minimum threshold confidence level, the user may be granted access to a secure area or storage location.

[0110] Consider an instance scenario where a dynamic key is requested and subsequently used in a transaction, illustrated by the above-described process 500. Consider the scenario where Mr. Smith holds an account with a token service, and requests dynamic data (e.g., a dynamic account identifier and / or a dynamic key) for his mobile phone to enable him to perform token-related transactions using that phone. In this scenario, Mr. Smith may not need to take any active steps to initiate the request. For example, the request could be automatically generated by Mr. Smith's mobile phone when a mobile application used to perform token-related transactions is installed. To request the dynamic data, the application on the mobile phone can interact with a backend server supporting the application (e.g., a mobile application server), and can provide GPS coordinates collected by the mobile device in the request. The backend server can then request the dynamic data from the token service where Mr. Smith has an account. The token service can then identify one or more accounts associated with Mr. Smith and can generate dynamic data linked to one or more of those payment accounts. In this scenario, Mr. Smith's request time and the mobile phone's GPS coordinates are then stored by the token service. For illustrative purposes, assume the location associated with the token request is San Francisco, and the time is 12:00 PM on January 1, 2016.

[0111] Continuing the above scenario, the token service can receive instructions that dynamic data was used in the first transaction in Palo Alto (33.3 miles from San Francisco) at 2:00 PM on January 1, 2016. For example, a password may have been provided to the terminal device in Palo Alto to complete the transaction. Upon decryption or verification of the password, it can be determined that the password was generated using Mr. Smith's dynamic key. Therefore, the distance between the requests is approximately 33.3 miles, and the time between the requests is 2 hours (120 minutes), resulting in a distance-time ratio of 33.3 / 120 (i.e., DT). T =0.2775). For the purposes of this example, assume a basic confidence value (C). B The confidence level for the first transaction is 50, and the multiplier (M) is 10. Using the previously mentioned formula, the confidence level for the first transaction can be calculated as C. T=10*(1 / 0.2775)+50 or 86.04. This confidence level can then be used to approve or reject the first transaction.

[0112] Continuing with the above scenario, the token service could receive dynamic data indicating that the second transaction was being used in Seattle (680.05 miles from San Francisco) at 4:00 PM on January 1, 2016. Therefore, the distance between the requests was approximately 680.05 miles, and the time between the requests was 4 hours (240 minutes), resulting in a distance-time ratio of 680.05 / 240 (i.e., DT). T =2.834). Using the above assumptions, the confidence level of the second transaction can be calculated as C. T =10*(1 / 2.834)+50 or 53.53. This confidence level can then be used to approve or reject the second transaction. As shown in the three examples, a higher distance-time ratio can result in a lower overall confidence level.

[0113] It should be noted that the illustrations presented above represent a simplified and therefore less precise embodiment of this disclosure. It should also be noted that any number of additional factors can be used to determine the confidence level associated with the transaction. For example, in the scenario above, information relating to Mr. Smith's past transactions could also be used to determine the confidence level of the transaction. In some embodiments, an acceptable distance-time ratio for Mr. Smith can be calculated based on past transactions.

[0114] Some or all (or variations and / or combinations thereof) of any of the processes described herein can be executed under the control of one or more computer systems configured with executable instructions, and can be implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications). According to at least one embodiment, Figure 4 The process 400 can be at least by Figure 1 The depicted mobile device 102 performs this action. According to at least one embodiment, Figure 5 The process 500 can be at least by Figure 2 The described service computer 200 executes the code. The code can be stored on a computer-readable storage medium, for example, in the form of a computer program comprising multiple instructions executable by one or more processors. The computer-readable storage medium can be non-transitory.

[0115] A computer system may include multiple identical components or subsystems connected together, for example, via external or internal interfaces. In some implementations, the computer system, subsystem, or device may communicate via a network. In this case, one computer may be considered a client and another a server, where each computer may be part of the same computer system. The client and server may each comprise multiple systems, subsystems, or components.

[0116] Embodiments of the present invention offer numerous technical advantages. For example, embodiments of the present invention provide improved deception determination capabilities. For instance, the authorizing entity is better able to determine the likelihood that a user is a user for whom a dynamic key has already been generated based on the distance-time ratio. Additionally, the serving computer is better able to track users' purchase / travel patterns. Thus, the serving computer can also generate user-specific distance-time ratios, further improving deception analysis.

[0117] It should be understood that any embodiment of the present invention can be implemented in a modular or integrated manner using hardware (e.g., application-specific integrated circuits or field-programmable gate arrays) and / or computer software in the form of control logic via a general-purpose programmable processor. As used herein, the processor includes a single-core processor, a multi-core processor on the same integrated chip, or multiple processing units or networks on a single circuit board. Based on the disclosure and teachings provided herein, those skilled in the art will recognize and appreciate other ways and / or methods of implementing embodiments of the present invention using hardware and combinations of hardware and software.

[0118] Any software component or function described in this application can be implemented as software code executed by a processor using any suitable computer language (such as, for example, Java, C, C++, C#, Objective-C, Swift) or scripting language (such as Perl or Python) employing techniques such as conventional or object-oriented methods. The software code can be stored as a series of instructions or commands on a computer-readable medium for storage and / or transmission, suitable media including random access memory (RAM), read-only memory (ROM), magnetic media such as hard disk drives or floppy disks, or optical media such as optical discs (CDs) or DVDs (Digital Universal Discs), flash memory, etc. The computer-readable medium can be any combination of these storage or transmission devices.

[0119] Such programs can also be encoded and transmitted using carrier signals suitable for transmission over wired, optical, and / or wireless networks conforming to various protocols, including the Internet. Therefore, a computer-readable medium according to embodiments of the invention can be created using data signals encoded with such a program. Computer-readable media encoded with program code can be packaged using compatible devices or provided separately from other devices (e.g., for download via the Internet). Any such computer-readable medium can reside on or within a single computer product (e.g., a hard disk drive, CD, or an entire computer system) and can exist on or within different computer products within a system or network. The computer system may include a monitor, printer, or other suitable display for providing a user with any of the results mentioned herein.

[0120] The above description is illustrative and not restrictive. Many variations of the invention will become apparent to those skilled in the art upon reading this disclosure. Therefore, the scope of the invention should not be determined by reference to the foregoing description, but rather by reference to the pending claims and their full scope or equivalents.

[0121] Without departing from the scope of the invention, one or more features of any embodiment may be combined with one or more features of any other embodiment.

[0122] Unless explicitly indicated otherwise, the use of the terms "a," "an," or "the / described" is intended to mean "one / a kind or a plurality of / kinds."

[0123] All patents, patent applications, publications, and descriptions mentioned above are incorporated herein by reference in their entirety for all purposes. They are not recognized as prior art.

Claims

1. A computer-implemented method comprising: The mobile device obtains first location information associated with the mobile device via a positioning system on the mobile device; The mobile device generates a request for dynamic data, wherein the dynamic data includes a dynamic account identifier, and the request includes the first location information; The mobile device sends the request to the server computer; The mobile device receives the dynamic data from the server computer; The dynamic data is stored by the mobile device; as well as The mobile device sends transaction data generated from the dynamic data in a transaction to the terminal device, wherein the transaction data includes a transaction password, and the dynamic data also includes a restricted key used by the mobile device to generate the transaction password; The terminal device then sends an authorization request message to the server computer including second location information of the terminal device and transaction data generated using the dynamic data, and the server computer then compares a first location corresponding to the first location information associated with the dynamic data with a second location corresponding to the second location information associated with the transaction, and determines the confidence level of the transaction based at least in part on the comparison of the first location and the second location, a comparison of the distance-time ratio of the transaction with an acceptable distance-time ratio, and verification of the transaction password.

2. The computer-implemented method of claim 1, wherein the second location information includes a terminal identifier associated with an access device used in the transaction, and the terminal identifier is used to determine the location of the access device.

3. The computer-implemented method of claim 1, wherein determining the confidence level of the transaction includes determining whether the distance between the first location corresponding to the first location information and the second location corresponding to the second location information is less than a distance threshold.

4. The computer-implemented method of claim 3, wherein the distance threshold is calculated based on first time information associated with when the dynamic data is requested and second time information associated with when the transaction is executed.

5. The computer-implemented method of claim 1, wherein determining the confidence level of the transaction comprises using a function in which the confidence level has an inverse relationship with the distance between the first location and the second location.

6. A mobile device comprising: processor; as well as The memory includes instructions that, when executed by the processor, cause the mobile device to perform at least the following operations: The mobile device obtains first location information associated with the mobile device via a positioning system on the mobile device; The mobile device generates a request for dynamic data, wherein the dynamic data includes a dynamic account identifier, and the request includes the first location information; The mobile device sends the request to the server computer; The mobile device receives the dynamic data from the server computer; The dynamic data is stored by the mobile device; as well as The mobile device sends transaction data generated from the dynamic data in a transaction to the terminal device, wherein the transaction data includes a transaction password, and the dynamic data also includes a restricted key used by the mobile device to generate the transaction password; The terminal device then sends an authorization request message to the server computer including second location information of the terminal device and transaction data generated using the dynamic data, and the server computer then compares a first location corresponding to the first location information associated with the dynamic data with a second location corresponding to the second location information associated with the transaction, and determines the confidence level of the transaction based at least in part on the comparison of the first location and the second location, a comparison of the distance-time ratio of the transaction with an acceptable distance-time ratio, and verification of the transaction password.

7. The mobile device according to claim 6, wherein the mobile device is a mobile phone.

8. A system comprising: Terminal device Server computer; as well as A mobile device includes a processor; and a memory including instructions that, when executed by the processor, cause the mobile device to perform at least the following operations: The mobile device obtains first location information associated with the mobile device via a positioning system on the mobile device; The mobile device generates a request for dynamic data, wherein the dynamic data includes a dynamic account identifier, and the request includes the first location information; The mobile device sends the request to the server computer; The mobile device receives the dynamic data from the server computer; The dynamic data is stored by the mobile device; as well as The mobile device sends transaction data generated from the dynamic data in a transaction to the terminal device, wherein the transaction data includes a transaction password, and the dynamic data also includes a restricted key used by the mobile device to generate the transaction password; The terminal device then sends an authorization request message to the server computer including second location information of the terminal device and transaction data generated using the dynamic data, and the server computer then compares a first location corresponding to the first location information associated with the dynamic data with a second location corresponding to the second location information associated with the transaction, and determines the confidence level of the transaction based at least in part on the comparison of the first location and the second location, a comparison of the distance-time ratio of the transaction with an acceptable distance-time ratio, and verification of the transaction password.

9. The system according to claim 8, wherein the terminal device is a POS terminal.

10. The system of claim 8, wherein the confidence level is determined using a function in which the confidence level is inversely related to the distance between the first location associated with the first location information and the second location associated with the second location information.

11. The system of claim 8, wherein the password includes the dynamic data.

12. The system of claim 11, wherein the password further includes the second location information.

Images