WO2018140272A1 - Contacts for misdirected payments and user authentication - Google Patents
Contacts for misdirected payments and user authentication Download PDFInfo
- Publication number
- WO2018140272A1 WO2018140272A1 PCT/US2018/014126 US2018014126W WO2018140272A1 WO 2018140272 A1 WO2018140272 A1 WO 2018140272A1 US 2018014126 W US2018014126 W US 2018014126W WO 2018140272 A1 WO2018140272 A1 WO 2018140272A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- mobile device
- user
- hash values
- server
- payment
- Prior art date
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
- G06Q20/322—Aspects of commerce using mobile devices [M-devices]
- G06Q20/3223—Realising banking transactions through M-devices
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/401—Transaction verification
- G06Q20/4014—Identity check for transactions
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/42—Confirmation, e.g. check or permission by the legal debtor of payment
Definitions
- the phone number may get exchanged and/or recycled, and when a user attempts to log into their mobile credit account from a different phone number and/or a different mobile device, additional levels of information about that user's account may be desired to ensure account security in order to prevent accidental account takeovers by unauthorized persons who may have obtained the recycled phone number.
- FIG. 1 illustrates an example of a system for processing mobile payments, according to an embodiment.
- FIG. 2 illustrates an example of a process for authenticating a user accessing payment transfer application on a mobile device, according to an embodiment.
- FIG. 3A illustrates a graphical user interface (GUI) for presenting a login process when a user is accessing payment transfer application on a mobile device, according to an embodiment.
- GUI graphical user interface
- FIG. 3B illustrates a graphical user interface for presenting a login process when a user is accessing payment transfer application on a mobile device, according to an embodiment.
- FIG. 3C illustrates a database of a payment processing system (PPS) in communication with a mobile device, according to an embodiment.
- PPS payment processing system
- FIG. 3D illustrates a graphical user interface for presenting a login process when a user is accessing payment transfer application on a mobile device, according to an embodiment.
- FIG. 4 illustrates an example of a process for processing mobile payment requests, according to an embodiment.
- FIG. 5A illustrates a graphical user interface for presenting a mobile payment request, according to an embodiment.
- FIG. 5B illustrates a graphical user interface for presenting a mobile payment request, according to an embodiment.
- FIG. 6A illustrates a graphical user interface for presenting a mobile payment request, according to an embodiment.
- FIG. 6B illustrates a graphical user interface for presenting a mobile payment request, according to an embodiment.
- FIG. 6C illustrates a graphical user interface for presenting a mobile payment request, according to an embodiment.
- the various embodiments described herein generally relate to methods and systems that provide an efficient and secure technique for mobile payment transfer on a mobile device, based on authenticating a user (payor) of the mobile device, by multi factor authentication.
- the methods and systems described herein use mobile devices that can execute a payment transfer application that facilitates a transfer of money between accounts. A user can then command the payment transfer application running on the mobile device to send money to a recipient account via a payment processing system that runs the payment transfer application.
- users may access the payment processing system and services via a website, where the payment processing system may comprise a webserver in communication with an application server configured to perform the various processes and tasks described herein.
- the user may access the payment processing system through a native application installed on the user's local device that was downloaded from a server of the payment processing system.
- the user may access the payment processing system through an Internet browser application through which the user may provide various process instructions to a webserver of the payment processing system.
- payment transfer application may include a messaging application executed by a mobile device through which the user interfaces with the payment processing system via a chat messaging interface on the user's mobile device.
- the payment processing system may then perform the various tasks and processes described herein, based upon the chat-based (e.g., SMS, iMessage®) instructions received from the user's mobile device.
- chat-based e.g., SMS, iMessage®
- the values and currencies associated with such transactions are not limited to a certain form or type of currency; the type of currency may be ordinary form of cash currency (e.g., dollars, euros, rupees) and the form of currency may be a cash currency or may be digital currency, sometimes referred to as cryptocurrency, such as Bitcoin, Ripple, or the like.
- the type of currency transmitted on a sending-side of a transaction e.g., dollars
- the type of currency received on the recipient-side of the transaction e.g., euros).
- the servers of the payment processing system may be configured to automatically convert the transaction value according to the respective transaction currency types or forms, according to a conversion factor, which the server may receive from one or more external data sources or may be programmed by an administrative user.
- the server may have installed and execute a software application that is required to conduct transactions using a digital currency, such as executable routines that update a blockchain ledger to indicate an exchange in ownership over the converted digital currency value.
- a payment processing system that runs the payment transfer application may execute a layer of security protocols to verify an identity of the user. For instance, in a first layer of security, upon entry of the login information in the payment transfer application, the user may receive a code on the new mobile device and/or e-mail account of the user. The user enters the code into a user interface of the payment transfer application on the new mobile device to verify that the account being accessed by the user belongs to the user.
- a payment processing system may send to the user a request to access to a contact list on the new mobile device.
- the payment processing system receives the contact list from the new mobile device.
- the payment processing system may then compare the contact list obtained from the new mobile device with a contact list retrieved from old mobile device of the user.
- the contact list of the old mobile device is stored in a user record within the payment processing system. When the results of a comparison show a significant overlap (e.g., a pre-determined percentage of contacts in both the contact lists are same), the payment processing system allows the user to access the payment transfer application of the new mobile device.
- a new mobile device may generate an encrypted version of contacts stored in a memory of the new mobile device and then transmit the encrypted version of the contacts to a payment processing system.
- the new mobile device may use any suitable encryption technique to encrypt the contacts.
- the encrypted version of contacts provide a hash value for each contact in the contact list of the new mobile device, and thus there is a hash value for each contact.
- the payment processing system may then compare the hash value of each contact on new mobile device with a hash value of contacts of the old mobile device of the user to determine if there is a significant overlap. Upon determining the significant overlap between the hash values of the new and old contacts, the payment processing system may authenticate the user.
- the payment processing system and administrators of the payment processing system are unable to view or otherwise access the actual data entries in a plaintext format, thereby protecting the privacy of the data yet still enabling the capability of comparing the contact data and/or transaction data.
- a payment transfer application authenticates a user having two mobile devices, where the user is attempting to perform a transaction on the second mobile device using the payment transfer application.
- the payment transfer application automatically generates hash values representing contact records stored on the first mobile device.
- the first mobile device transmits the hash values representing the contact records stored in the first mobile device to a server of a payment processing system.
- the server may store the hash values representing the contact records stored in the first mobile device in a database of the payment processing system.
- the payment transfer application on the second mobile device When the user attempts to use the second mobile device (e.g., a later-activated device) for executing the payment transfer application, the payment transfer application on the second mobile device generates an authentication request.
- the second mobile device transmits the authentication request to the server.
- the second mobile device transmits hash values representing contact records stored in the second mobile device.
- the server compares the hash values representing the contact records stored in the second mobile device with the hash values representing the contact records stored in the first mobile device.
- the server Upon determining that the hash values received from the second mobile device satisfy an overlap threshold with the hash values received from the first mobile device, the server grants access to the user to access the payment transfer application via the second mobile device.
- the mobile device may transmit to the payment processing server a unique user identifier (user ID) for a recipient-user.
- the server may then generate a hash value for the recipient-user and then matches the hash value of the user ID with a stored hash value for the recipient-user received from the user contacts of the sending-user's mobile device.
- a payment transfer application verifies a payment destination account for an outgoing transaction request initiated by a mobile device.
- a user is running a payment transfer application on the mobile device and requests the outgoing transaction (payment of funds from an account) using the payment transfer application.
- the payment transfer application of each mobile device in the system generates hash values representing contact records stored on the mobile devices.
- Each mobile device transmits the hash values to a server of a payment processing system.
- the server may store the hash values in a database of the payment processing system.
- the hash values are associated with a user record of each respective associated with each respective mobile device stored in the database.
- the user records contain a history of payment requests indicating a respective recipient hash value associated with each respective payment request in the history of payment requests.
- the mobile device transmits the payment request to the server.
- the payment request contains a recipient contact and a corresponding hash value.
- the server compares the recipient contact and the corresponding hash value with the hash values from the mobile device and the hash values in the history of payment requests stored in the user record.
- the server may generate and transmit to the mobile device a message requesting confirmation of an identity of the recipient.
- the server Upon receiving a positive response from a user to the confirmation request, the server will then approve the payment request of the user and the payment will be transferred to the recipient.
- the improvements upon the login process described herein address shortcomings in the prior art, such as the .
- logging into the system using prior art technologies may result in substantial back-and-forth network traffic and data processing obligations, due to the needs for system hardware components to process passwords or other credentials.
- the systems and methods described herein provide a user authentication methodology that may ease the burden on data processing and reduce the amount of network traffic exchanges between the network devices.
- the numerous amount of login attempt from users and external systems may establish a backlog or present a substantial timing burden when authenticating users or systems.
- the systems and methods of using hashed values of data stored on a user device may provide a significantly faster means of authenticating users, as improvement upon using user credentials or biometric inputs. This improve the speed at which login attempts are processed, which, in turn, reduces the backlog of authentication requests, and thus improves response time to other user login attempts and third-party software attempting to access to the system.
- data stored locally on a user device should be used for authentication purposes. However, this data could be sensitive or large, which raises concerns of confidentiality and data processing sizes, and threatens to mitigate the potential benefits described herein.
- hash value of the data entries to be processed for authentication purposes e.g., hash value of each contact entry in contacts list.
- Using hash values could potentially resolve the confidentiality concerns by acting as cryptographic scheme, and could reduce the amount of data being exchanged and processed as the resulting hash value could be a smaller byte size compared to the original data entry.
- FIG. 1 illustrates an example of a system 100 for processing mobile payments, according to an embodiment.
- the system 100 may include a first mobile device 102, a payment processing system (PPS) 104, a network 106, a second mobile device 108, a record server 110, a local database 112 of the first mobile device 102, and a second local database 109 of the second mobile device 108.
- the payment processing system PPS may include a PPS server 104, an Application Programming Interface (API 116), and a PPS database 118.
- API 116 Application Programming Interface
- the system 100 can use multiple mobile devices (such as the first mobile device 102 and or the second mobile device 108) to request that money be transferred over bank account or debit card networks.
- the system 100 includes a sender device, such as the first mobile device 102 and/or the second mobile device 108 connected to the network 106, where the sender device is capable of running an a payment processing application of the PPS system 104.
- a user may use the first mobile device 102 and/or the second mobile device 108 to send a payment (money) through the PPS system 104 to a recipient account.
- the first mobile device 102 the PPS system 104, and the second mobile device
- the network 106 may be a medium that also connects the PPS database 118 and the record server 110 of the system 100.
- the examples of the network 106 may include, but are not limited to, private or public LAN, WLAN, MAN, WAN, and Internet.
- the network 106 may include both wired and wireless communications according to one or more standards and/or via one or more transport mediums.
- the communication over the network 106 may be performed in accordance with various communication protocols such as Transmission Control Protocol and Internet Protocol (TCP/IP), User Datagram Protocol (HDP), and IEEE communication protocols.
- the network 106 may include wireless communications according to Bluetooth specification sets, or another standard or proprietary wireless communication protocol.
- the network 106 may also include communications over a cellular network, including, e.g. a GSM (Global System for Mobile Communications), CDMA (Code Division Multiple Access), or EDGE (Enhanced Data for Global Evolution) network.
- GSM Global System for Mobile Communications
- CDMA Code Division Multiple Access
- EDGE Enhanced Data for Global Evolution
- the first mobile device 102 and/or the second mobile device 108 may be any portable or non-portable computing device with a processor/microcontroller and/or any other electronic component that performs one or more operations according to one or more programming instructions.
- the examples of the first mobile device 102 and/or the second mobile device 108 include, but are not limited to, a cellular phone, a tablet computer, a smart watch, a personal data assistant, a gaming console, or personal computer.
- the first mobile device 102 and/or the second mobile device 108 are capable of communicating with the PPS system 104 through the network 104 using wired or wireless communication capabilities.
- the first mobile device 102 and/or the second mobile device 108 may include one or more input/output devices configured to allow user interaction with one or more programs configured to communicate with the PPS system 104 to perform financial payment transactions.
- the user may have the payment transfer application installed on the first mobile device 102 from which user access and interact with the PPS system 104 to perform financial transactions.
- the payment transfer application may be a software stack running on an operating system (OS) of the first mobile device 102.
- the payment transfer application of the PPS system 104 may have a protocol layer and a user interface layer ("UP') where each layer may be responsible for specific functions.
- OS operating system
- UP' user interface layer
- the protocol layer of the payment transfer application of the PPS system 104 may communicate with the OS of the first mobile device 102 and manages the connections of the first mobile device 102 over the communication network 106.
- the protocol layer may also communicate with the user interface layer and may be arranged to control the user interface layer to present information to the user via the user interface of the payment transfer application on the first mobile device 102 and to receive information from the user via the user interface of the payment transfer application on the first mobile device 102.
- the first mobile device 102 may run a web browser that accesses and presents a payment transfer web application to be executed by a processor of the first mobile device 102 or the PPS server 114 of the PPS system 104 and allows the user to perform financial transactions using the payment transfer web application on the first mobile device 102.
- the first mobile device 102 may execute an application outside of a web browser, for example, an operating system-specific payment transfer application that accesses and presents information processed by the processor of the first mobile device 102 or the PPS system 104 to perform financial transactions.
- the first mobile device 102 stores a list of contacts.
- the first mobile device 102 may also store data related to transactions performed by the user using the payment transfer application.
- the list of contacts and/or transaction data may be stored in the local database 112 associated to the first mobile device 102.
- data such as the list of contacts and/or transaction data transmitted over the suitable communication network 106 from the first mobile device 102 to the local database 112 may be formatted and/or encrypted in accordance with a variety of different protocols such as security and communication protocols.
- all or a portion of the communication network 106 may be a packet-based, Internet Protocol (IP) network that communicates the data from the first mobile device 102 to the local database 112 in Transmission Control Protocol/Internet Protocol (TCP/IP) packets.
- IP Internet Protocol
- the payments processed on the first mobile device 102 using the payment transfer application may be formatted, as transaction data in accordance with a formatting specification or protocol expected by the local database 112 and/or the PPS system 104, and then the formatted data may be transmitted by the first mobile device 102 to the local database 112.
- a processor of the first mobile device 102 may generate an encrypted value for each contact in the list of contacts, or otherwise translate the list of contacts as hash records, which may then be stored into the local database 112 and/or the PPS database 118.
- the local database 112 may be hosted on any mobile device (such as the first mobile device 102).
- the local database 112 is capable of storing the transaction data and the list of contacts in plaintext format and/or encrypted version. Moreover, by exchanging and storing hash values of contacts, contact lists, and/or transaction data, as opposed to the actual data, the PPS system 104 and administrators of the PPS system 104 may be unable to view the actual data entries in a plaintext format, thereby protecting the privacy of the data but still enabling the capability of comparing the contact entries and/or transaction data.
- the local database 112 may be in communication with a processor, where the processor is capable of executing the various commands of the database management system. In some embodiments, the local database 112 may be part of the first mobile device 102. In some embodiments, the local database 112 may be a separate component in communication with the first mobile device 102 and the PPS system 104
- the local database 112 and/or the PPS database 118 may be in communication to each other via the network 106 and include a non-transitory machine-readable storage media capable of receiving, storing, updating, and/or querying contacts and transaction records stored in the local database 112.
- the local database 112 and/or the PPS database 118 may have a logical construct of data files that are stored in non-transitory machine-readable storage media, such as a hard disk or memory, controlled by software modules of a database program (for example, SQL), and a related database management system (DBMS) that executes the code modules (for example, SQL scripts) for various data queries and other management functions generated by the PPS server 114 and/or the first mobile device 102.
- DBMS database management system
- the memory of the local database 112 and/or the PPS database 118 may be a non-volatile storage device for storing data and instructions to be used by a processor of the first mobile device 102 and/or the PPS server 114.
- the memory may be implemented with a magnetic disk drive, an optical disk drive, a solid state device, or an attachment to a network storage.
- the memory may include one or more memory devices to facilitate storage and manipulation of program code, set of instructions, tasks, data, PDKs, and the like.
- Non-limiting examples of memory implementations may include, but are not limited to, a random access memory (RAM), a read only memory (ROM), a hard disk drive (HDD), a secure digital (SD) card, a magneto-resistive read/write memory, an optical read/write memory, a cache memory, or a magnetic read/write memory.
- RAM random access memory
- ROM read only memory
- HDD hard disk drive
- SD secure digital
- the memory of the local database 112 and/or the PPS database 118 may be a temporary memory, such that a primary purpose of the memory is not long-term storage.
- the memory in some examples, described as a volatile memory, meaning that the memory do not maintain stored contents when the first mobile device 102 is turned off.
- Examples of the volatile memories may include dynamic random access memories (DRAM), static random access memories (SRAM), and other forms of volatile memories known in the art.
- the memory may be configured to store larger amounts of information than volatile memory.
- the memory may further be configured for long-term storage of information.
- the memory may include non-volatile storage elements. Examples of such non-volatile storage elements include magnetic hard discs, optical discs, floppy discs, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories.
- a processor operates the PPS system 104.
- the processor processes transfers conducted between the sender and recipient mobile or other electronic devices.
- the sender device can send money to the recipient device via the payment processing application of the PPS system 104.
- the payment processing system 104 can, based on the transfer request, transfer money between a sender card account to a recipient card account, and can communicate with the sender and recipient mobile or other electronic devices.
- the PPS system 104 may include one or more PPS servers 114, at least some of which can handle secure transactions to process all transactions with the sender and recipient mobile or other electronic devices.
- One or more accounts can be associated with a payment processing application installed on the first mobile device 102.
- An account can be a financial account managed by a card issuer and can be associated with a card number.
- the one or more accounts are stored at the PPS server 114.
- the PPS system 104 may communicate with a record server 110 of a debit card payment network.
- the PPS system 104 may communicate with a record server 110 of a credit card payment network, e.g., over the network 106 used to communicate with the sender device such as the first and the second mobile devices 102, 108 or over a different communication network.
- the PPS system 104 may identify debit card accounts, e.g., stored at the PPS servers 114, for the sender.
- the PPS system 104 may submit a request to an appropriate card issuer, e.g., the sender's card issuer, to transfer money.
- the appropriate card issuer may receive and process the request by transferring money to the appropriate card account.
- the PPS system 104 may receive a payment amount by processing a card, e.g., a credit card or a debit card, of the sender and hold the payment amount.
- the PPS system 104 may push the payment amount to a debit account of the recipient. Instead of holding the payment amount, the PPS system 104 may also forward the payment once the recipient links an account with the PPS system 104.
- the PPS server 114 may be positioned between the first mobile device 102, the second mobile device 108, and the record server 110.
- the PPS server 114 is part of the PPS system 104, which may also include the Application Programming Interface (API) 116 and the PPS database 118.
- the PPS server 114 may use the API 114 to communicate with the mobile devices 102, 108 belonging to the user or the recipient over the network 106.
- the PPS database 118 may include information such a user profile, phone number, contacts lists, hash values of contacts lists, and account numbers of the user. In the exemplary system 100 seen in FIG.
- the PPS server 114 may receive transmissions regarding payment requests that occur between a user using the first and the second mobile devices 102, 108 and the record server 110. In some embodiments, upon receiving a payment request from the user, and generating a payload, the PPS server 114 may forward the transaction to the record server 110 that is associated with a financial institute. In some embodiments, the PPS server 114 may directly contact the financial institute in order to facilitate the payment request and transaction.
- the record server 110 may be hosted by a financial institute or a third party that provides a service to the financial institute.
- the record server 110 may maintain information regarding the balance of an account maintained by the user at the financial institute. Certain parties, such as the user who is an account owner or an administrator of the PPS system 104, may assume certain risks that an account holder does not have sufficient funds to fund a transaction, until the record server 110 authorizes the transaction.
- the server 114 may forward associated information to the record server 110, which maintains an account corresponding to the balance of the user.
- the financial institute may also generate an authorization response to forward to the record server 110, back through other devices in a payment stream and eventually to the PPS server 114 to confirm that the user or the recipient may complete the payment transaction.
- the PPS server 114 may either receive authorization from the financial institute or create a custom authorization or anti-fraud procedure in order to authorize the payment requests.
- the PPS server 114 and/or the record server 110 may include one or more processors to control the operations of the PPS system 104. In some embodiments, a single processor may be employed. In some embodiments, a plurality of processors may be employed for configuring the PPS system 104 as a multi-processor system.
- the processor may include suitable logic, circuitry, and interfaces that are operable to execute one or more instructions to perform data transfer and other operations.
- the processor may be realized through a number of processor technologies known in the art.
- the examples of the processor include, but are not limited to, an x86 processor, an ARM processor, a Reduced Instruction Set Computing (RISC) processor, an Application-Specific Integrated Circuit (ASIC) processor, or a Complex Instruction Set Computing (CISC) processor.
- the processor may also include a Graphics Processing Unit (GPU) that executes the set of instructions to perform one or more processing operations.
- GPU Graphics Processing Unit
- a user may access a payment transfer application of the PPS system 104 on the first mobile device 102.
- the user may not have an account on the payment transfer application, and the user may register on the payment transfer application.
- the user may register on the payment transfer application installed on the first mobile device 102 by generating a username using a full name, a phone number, and/or e-mail address to access the account.
- the first mobile device 102 may contain a list of contacts of the user in its phonebook directory.
- the list of contacts may include one or more of: name of each contact, a phone number of each contact, a username associated to the contact's payment transfer application, e-mail address of each contact, and bank account details for each contact.
- the list of contacts and their corresponding details may be stored on the first mobile device 102 or in the local database 112 linked to the first mobile device 102.
- a processor of the first mobile device 102 may transmit the list of contacts on the first mobile device 102 to the PPS server 114 of the PPS system 104. In one instance, a processor of the first mobile device 102 may transmit a list of contacts to the PPS server 114 when the user of the first mobile device 102 registers an account on the payment transfer application. In another instance, a processor of the first mobile device 102 may initially transmit a list of contacts to the PPS server 114 when the user of the first mobile device 102 registers an account on the payment transfer application, and subsequently further transmits an updated list of contacts from the first mobile device 102 to the PPS server 114 after pre-defined intervals of time (for example, every one week, or one month).
- a processor of the first mobile device 102 may initially transmit the list of contacts to the PPS server 114 when the user of the first mobile device 102 registers an account on the payment transfer application, and subsequently further transmits each new contact added in a phone book of the first mobile device 102 by the user of the first mobile device 102 to the PPS server 114 as soon as the new contact is added in the phone book of the first mobile device 102.
- a processor of the first mobile device 102 may retrieve the list of contacts from the local database 112 and then transmit the list of contacts to the PPS server 114.
- the first mobile device 102 creates hash values for each contact of the list of contacts stored in first mobile device 102.
- the generated hash values for each contact of the list of contacts are sent between the first mobile device 102 and the server 114 rather than the details of the contacts indicated by the hash values, such that first mobile device 102 avoids the need to reveal the details of the list of contacts to the PPS server 114.
- the first mobile device 102 may also store the hash values associated to each contact of the list of the contacts in the local database 112 along with the list of contacts.
- the first mobile device 102 may generate a hash value for each contact in the list of contacts using a hashing technique.
- the hashing technique compacts information to identifiers (hash values) in such a way that the content of the information in the contacts and/or the order of the information in contacts in the list of contacts are taken into account in generating hash values from a list of contacts by the first mobile device 102.
- a single hash value may correspond to one contact item, such that the identification of matching hash values equates to an identification of matching contacts identified by the hash values.
- using the hash values rather than the contacts details themselves reduces the amount of data transmitted over the network 106 and hides the content of the contacts as well.
- the hash values may be generated using a one-way hashing algorithm executed by the first mobile device 102 where the hash functions are non-reversible, meaning that the original content from which the hash was calculated cannot be recreated from the hash value, thereby protecting the original content details of the contact. It can therefore be seen that using the hash values provides a level of security to protect against the disclosure of details of the contact from the first mobile device 102 to the PPS server 114.
- the user may use a new mobile device, such as a second mobile device 108, to access its account on a payment transfer application.
- the user may install the payment transfer application on the second mobile device 108.
- the PPS server 114 may then receive a request from user and/or the second mobile device 108 for authorizing the second mobile device 108 to become a trusted device for access to a payment transfer application service.
- the request may be generated in any suitable manner. For example, the user of the second mobile device 108 logs into a secure payment transfer application service installed on the second mobile device 108 where the request is generated.
- the user may log into the payment transfer application service by entering username and/or user ID of a service account on the payment transfer application installed on the second mobile device 108.
- the request for authorizing the second mobile device 108 to become the trusted device for access to the payment transfer application service may be generated by the second mobile device 108 and then transmitted to the PPS server 114.
- the PPS server 114 may implement a series of security protocols in order to verify that a service account of the payment transfer application being accessed by the user on the second mobile device 108 belongs to the user. For instance, in a first layer of security protocol implemented by the PPS server 114, the PPS server 114 may generate a security code that may be transmitted to a phone number of the second mobile device 108. The PPS server 114 may request a user of the second mobile device 108 to enter the code on a user interface of the payment transfer application installed on the second mobile device 108.
- the PPS server 114 may receive computer readable instructions that are used to render the code in a format that is readable by the second mobile device 108.
- the code may include a secret token, which may be for example a globally unique identifier (GUTD), such as for example but not limited to a unique string of characters including, but not limited to letters or numbers or both.
- GUID globally unique identifier
- the code may also include one or more Uniform Resource Locators (URLs).
- the URL may be used to designate an address from which the second mobile device 108 may obtain instructions and/or information for use.
- the URL may also designate an address of the PPS server 114 to which the second mobile device 108 may send a set up message.
- the code may be associated with an expiry time.
- the expiry time may be included in the code.
- the expiry time may be recorded together with the secret token associated with the code at the PPS database 118 associated with the PPS server 114 when the code is generated.
- the generated code by the PPS server 114 is then provided to a user of the second mobile device 108.
- the user may then enter the code into a user interface of the payment transfer application installed on the second mobile device 108.
- the second mobile device 108 may then transmit a set up message based on the entered code.
- the code may include instructions and/or information for how and where to send the set up message.
- the software on the second mobile device 108 may be hard-coded to use a specific web server, or URL, or location to send the set up message. Accordingly, in some embodiments, this technology can be used as a component of software and can be locked to a specific authentication server such as the PPS server 114 or service.
- the setup message may be transmitted to the PPS server 114.
- the set up message may be transmitted to the PPS system 104, and the PPS system 104 may transmit to one of the servers such as the PPS server 114.
- the set up message may include a unique identifier (UID) of the second mobile device 108.
- the unique identifier may be a globally unique identifier of the second mobile device 108 and can include, for example, but is not limited to, an identifier generated based on the second mobile device 108 metadata or a unique identifier associated with the second mobile device 108 including but not limited to an International Mobile Equipment Identity (IMEI) address.
- IMEI International Mobile Equipment Identity
- the second mobile device 108 does not generate a set up message, and the process ends such that the second mobile device 108 does not become a trusted device for access to the payment transfer application service unless further action is taken such as repeating the process with a valid code.
- the PPS server 114 may determine if the code has expired and if so, rejects it.
- the code may not have any expiry data or timestamp and is associated a secret code on the PPS server 114 side that can be produced at the time the code was generated.
- the setup message may be encrypted that is sent to the PPS server 114.
- the PPS server 114 may then implement a second layer of security protocol in order to verify that a service account of a payment transfer application being accessed by the user on the second mobile device 108 belongs to the user.
- the second layer of security protocol implemented by the PPS server 114 corresponds to matching of contacts of the user in a phone book of the second mobile device 108 with a list of contacts associated to any previous devices of the user used for accessing the service account of the payment transfer application service.
- the PPS server 114 may request access from the second mobile device 108 to a list of contacts stored in a phone book of the second mobile device 108.
- the second mobile device 108 may have had automatically transmitted the list of contacts stored in a memory of the second mobile device 108 to the PPS server 114 prior to receiving the request from the PPS server 114 and when the user log on to the payment transfer application installed on the second mobile device 108.
- the second mobile device 108 upon receiving the request from the PPS server 114, may create hash values for each contact in the list of contacts stored in a memory of the second mobile device 108, and the hash value for each contact may then be transmitted by the second mobile device 108 to the PPS server 114 rather than the usernames of the contacts indicated by the hash values, such that the second mobile device 108 avoids the need to reveal usernames and/or identification details of the list of contacts to the PPS server 114.
- the second mobile device 108 may create hash values for each contact in the list of contacts stored in a memory of the second mobile device 108 and store the hash values in a second local database 109 associated with the second mobile device 108, and upon receiving the request from the PPS server 114, the hash values may then be retrieved from the local database by the second mobile device 108 and transmitted to the PPS server 114.
- the second local database 109 of the second mobile device 108 may store a list of contacts in contacts data and data related to transactions performed using a payment transfer application.
- data such as the list of contacts and/or transaction data transmitted over the suitable communication network 106 from the second mobile device 108 to the second local database 109, may be formatted and/or encrypted in accordance with various protocols, such as security and communication protocols.
- all or a portion of the communication network 106 may be a packet-based, Internet Protocol (IP) network that communicates the data from the second mobile device 108 to the second local database 109 as TCP/IP packets.
- IP Internet Protocol
- contacts data and/or transaction data may be formatted in accordance with a data format specification or protocol expected by the second local database 109 and/or the PPS system 104, and then the formatted data may be transmitted by the second mobile device 108 to the second local database 109.
- the second local database 109 may be hosted on any mobile device (such as the second mobile device 108).
- the second local database 109 is capable of storing the transaction data and the list of contacts in a plaintext format and/or encrypted version.
- the second local database 109 may be in communication with a processor, where the processor is capable of executing the various commands of the database management system.
- the second local database 109 may be part of the second mobile device 108; and, in some embodiments, the second local database 109 may be a separate device that is in communication with the second mobile device 108.
- the second local database 109 and/or the PPS database 118 may be in communication to each other via the network 106, and may include a non-transitory machine- readable storage media capable of receiving, storing, updating, and/or querying contacts and transaction records stored in the second local database 109.
- the second local database 109 and/or the PPS database 118 may have a logical construct of data files that are stored in non-transitory machine-readable storage media, such as a hard disk or memory, controlled by software modules of a database program (for example, SQL), and a related database management system (DBMS) that executes the code modules (for example, SQL scripts) for various data queries and other management functions generated by the PPS server 114 and/or the second mobile device 108.
- DBMS database management system
- the memory of the second local database 109 may be a non-volatile storage device for storing data and instructions to be used by a processor of the second mobile device 108 and/or the PPS server 114.
- the memory may be implemented with a magnetic disk drive, an optical disk drive, a solid state device, or an attachment to a network storage.
- the memory may include one or more memory devices to facilitate storage and manipulation of program code, set of instructions, tasks, data, PDKs, and the like.
- Non-limiting examples of memory implementations may include, but are not limited to, a random access memory (RAM), a read only memory (ROM), a hard disk drive (HDD), a secure digital (SD) card, a magneto-resistive read/write memory, an optical read/write memory, a cache memory, or a magnetic read/write memory.
- RAM random access memory
- ROM read only memory
- HDD hard disk drive
- SD secure digital
- the memory of the second local database 109 may be a temporary memory, such that a primary purpose of the memory is not long-term storage.
- the memory described as a volatile memory meaning that the memory do not maintain stored contents when the second mobile device 108 is turned off.
- Examples of the volatile memories may include dynamic random access memories (DRAM), static random access memories (SRAM), and other forms of volatile memories known in the art.
- the memory may be configured to store larger amounts of information than volatile memory.
- the memory may further be configured for long-term storage of information.
- the memory may include non-volatile storage elements.
- the PPS server 114 subsequently compares the hash values for each respective contact record of the user stored on the second mobile device 108 with the hash values for each respective contact record of the user obtained from a mobile device used by the user prior to using the second mobile device 108, for example, the first mobile device 102.
- the PPS server 114 may grant the user of the second mobile device 108 access to the payment transfer application installed on the second mobile device 108.
- the PPS server 114 may then generate additional security layer of questions for the user of the second mobile device 108 and transmit the additional question to the second mobile device 108.
- the PPS server 114 may generate a list of one or more questions for the user, including but not limited to, details related to bank account, social security number, mother's name, father's name, date of birth, year of opening the account, or last three transactions performed by the user using the payment transaction application.
- the list of one or more questions generated by the PPS server 114 may then be transmitted by the PPS server 114 to the second mobile device 108.
- the user's answers to the questions may be transmitted by the second mobile device 108 to the PPS server 114.
- the PPS server 114 After receiving the answers provided by the user of the second mobile device 108 for the set of questions, the PPS server 114 will then match the answers provided by the user for the set of questions with answers to same set of questions previously provided by the user at the time of initial registration of service account of a payment transfer application, which are stored in the PPS database 118.
- the PPS server 114 may authorize access for the user to the payment transfer application service on the second mobile device 108, in addition to the authorization of the second mobile device 108 to become the trusted device for access to the payment transfer application service for any future transactions.
- the user may want to request a payment transfer to another user (recipient) using second mobile device 108.
- the second mobile device 108 of the user and a device being used by the recipient may or may not be in direct communication with each other in order to transmit a payment request, payload, token, or other financial information associated with the payment request.
- a processor of the second mobile device 108 and/or the PPS server 114 may generate instructions for the second mobile device 108 to populate a user interface and generate a payment request.
- the processor of the second mobile device 108 and/or the PPS server 114 may utilize the network 106 to communicate the payment request and other relevant information to device of the recipient via a message or an e-mail.
- the PPS server 114 when the user generates a request to transfer a payment to the recipient using the payment transfer application of the second mobile device 108, the PPS server 114 initiates a process for verifying recipient and the payment destination accounts of the recipient for outgoing transactions from the payment transfer application.
- the second mobile device 108 may automatically transmit hash values for each respective contact stored on the second mobile device 108 to the PPS server 114 along with the transfer request.
- the PPS server 114 may generate a query and transmit the query to the second mobile device 108 to obtain the hash values for each respective contact stored on the second mobile device 108.
- the second mobile device 108 may transmit the hash value for each respective contact stored on the second mobile device 108 or a local database associated with the second mobile device 108 to the PPS server 114.
- the second mobile device 108 may first generate the hash value for each respective contact stored on the second mobile device 108 or a local database associated with the second mobile device 108 and then transmit the hash value for each respective contact to the PPS server 114.
- the second mobile device 108 may directly transmit a list of contacts to the PPS server 114 along with the transfer request, and the PPS server 114 may create a hash value for each respective contact for the list of contacts stored on the second mobile device 108.
- the PPS server 114 and/or the second mobile device 108 may generate hash values for contacts using a same set of rules and/or hash algorithm stored in the PPS database 118.
- the PPS server 114 Upon receiving the hash values corresponding to each respective contact stored in the second mobile device 108 or upon generating the hash values for each of the contact details received from the second mobile device 108, the PPS server 114 stores the hash values of the plurality of contact records received from the second mobile device 108 in the PPS database 118.
- the plurality of hash values may be associated with a user record of the user of the second mobile device 108 stored in the PPS database 118.
- the user record of the user in the PPS database 118 may contain a history of one or more payment requests of the user indicating a respective recipient hash value associated with each respective payment request in the history of payment requests.
- the PPS server 114 may receive a payment transfer request from the second mobile device 108 containing a recipient hash value for the payment request. Based on the recipient hash value in the payment request, the PPS server 114 may query a plurality of hash values corresponding to a plurality of contacts obtained from the second mobile device 108 and hash values of recipients in the history of payment requests stored in the user record in the PPS database 118. When the PPS server 114 determines that the recipient hash value in the payment request is stored in the hash values of recipients in the history of payment requests of the user, the PPS server 114 approves the payment transfer request of the user.
- the PPS server 114 may generate and transmit a confirmation request to the second mobile device 108 of the user to confirm the recipient.
- the confirmation request generated by the PPS server 114 relates to an identity of the recipient, and the request may include details of the recipient including, but not limited to, name of the recipient, picture of the recipient, and/or bank account details of the recipient.
- the PPS server 114 may obtain the details about the recipient, such as the picture of the recipient, from an external database, by searching for social networking profiles of the recipient using input data provided by user related to the details of the recipient within the payment transfer request. Upon receiving the confirmation request from the PPS server 114, the user may input a response back to the PPS server 114. Upon receiving, by the PPS server 114, a positive confirmation from the user in response to the confirmation request, the PPS server 114 may then approve the payment transfer process request of the user, and the payment is transferred to the recipient mentioned on a payment transfer request.
- the PPS server 114 may employ contacts of contacts search. While employing the contacts of contacts search, the PPS server 114 may examine contact lists of some or all of a user's contacts in order to identify contacts of the user's contacts that match with the recipient. In some embodiments, some or all of user's contacts may be registered with the PPS system 104 and therefore there may be a hash value stored of them in the PPS database 118 of the PPS system 104.
- the PPS server 114 may approve the payment transfer request of the user.
- the PPS server 114 may determine a similarity score based on weighted values assigned to the hashed values, indicating the likelihood that a contact or set of contacts received from a recipient-user device are matched to a contact or set of contacts received from the sending-user device.
- the PPS server 114 may determine a status of the contact whose hash value matches with the recipient.
- the status of the matching contact may be stored in the PPS database 118, if the matching contact is registered with the PPS system 104.
- the status details may include a profile of the matching contact.
- the profile may include information related to transaction records of the person and/or any feedback of the person provided by other members of the PPS system 104 as well external law enforcement agencies.
- the PPS server 114 may not approve the payment transfer request of the user to the recipient, and instead the PPS server 114 may generate and transmit a confirmation request to the second mobile device 108 of the user to confirm the recipient.
- FIG. 2 illustrates a flowchart process 200 for authenticating a user accessing payment transfer application on a mobile device in accordance with an embodiment.
- the steps of flowchart process 200 may be implemented using one or more modules of a PPS system such as a PPS server.
- FIG. 2 does not imply any limitations with regard to the environments or embodiments that may be implemented. Modifications to the depicted environment or embodiment shown in FIG. 2 may be made.
- a PPS server may receive hash values for each contact in a list of contacts on a first mobile device of a user.
- a user interested in using a payment transfer application of a PPS system might not have any relationship with the PPS system, so the user will register with the PPS system.
- the user may be asked by the PPS server to input a username and other identifying information, such as name, address, social security number, date of birth, and current and prior addresses for registering with the PPS system.
- a user may execute a payment transfer application on the first mobile device.
- the first mobile device may receive a request from the PPS server to create a hash value for each contact in the list of contacts stored on the first mobile device or a local database associated to the first mobile device.
- the first mobile device may then create the hash value for each contact stored on the first mobile device or the local database associated to the first mobile device.
- the first mobile device may then transmit the hash value for each respective contact to the server and/or store the hash value for each respective contact in the list of contacts in the local database associated with the first mobile device along with the list of contacts.
- the first mobile device may automatically create a hash value for each contact in the list of contacts, stored on the first mobile device or a local database associated to the first mobile device. The first mobile device may then automatically transmit the hash value for each respective contact in the list of contacts to the server and/or store the hash value for each respective contact in the list of contacts in the local database associated to the first mobile device along with the list of contacts.
- the first mobile device may receive instructions from the PPS server.
- the instructions from the PPS server may specify one or more rules based on which the first mobile device may periodically generate the hash value for contacts after pre-defined intervals of time.
- the first mobile device may generate a hash value for an updated contact list on the first mobile device when there is new addition of contacts in the list of contacts on the first mobile device.
- the hash values generated for the updated contact list on the first mobile device may then be transmitted to the server and/or stored in the local database associated to the first mobile device, along with list of updated contacts after the pre-defined intervals of time.
- the first mobile device may receive instructions to generate and transmit the hash value for each new contact added by the user into a list of contacts as soon as the new contact is added in the first mobile device.
- the hash value generated for each new contact by the first mobile device is transmitted by the first mobile device to the server and/or stored in the local database associated to the first mobile device along with details of the new contact.
- the PPS server may store the hash values in the PPS database of the PPS system.
- the PPS database may be a non-transitory machine-readable storage media capable of receiving, storing, and updating the first mobile device contact records and their corresponding hash values.
- the PPS database may include a logical construct of data files that are stored in non-transitory machine-readable storage media, such as a hard disk or memory.
- the logical construct of data files may be controlled by software modules of a database program (for example, SQL), and a related database management system (DBMS) that executes the code modules (for example, SQL scripts) for various data queries and other management functions received from the PPS server and/or the first mobile device.
- a database program for example, SQL
- DBMS database management system
- code modules for example, SQL scripts
- the PPS server may receive an authentication request from a second mobile device of the user.
- the PPS server may receive an authentication request from the second mobile device.
- the user may login into the account of the payment transfer application on the second mobile device by entering a login input that is transmitted to the PPS server (e.g., via the network).
- the login input may include at least one of symbolic, alphanumeric, graphical, audio, video, or any other type of input data.
- the login input may also include user information, such as name, age, gender, address, credit score information, or any other relevant information, such as personal information.
- the login input entered by the user may be stored in a local database of the second mobile device and/or transmitted by the second mobile device to the PPS server.
- the PPS server may execute a series of security protocols generated by the PPS server to verify that the service account of the payment transfer application being accessed by the user on the second mobile device belongs to the user. For instance, in a first layer of security protocol executed by the PPS server, the PPS server may generate a security code that may be transmitted to a phone number of the second mobile device, and a user of the second mobile device may be requested to enter the code on a user interface of the payment transfer application.
- the user may then enter the code into the user interface of the payment transfer application on the second mobile device, and upon the receipt of the correct code by the PPS server, the PPS server may then execute a second layer of security protocol, in which the PPS server may generate and transmit a request to the second mobile device to forward a list of contacts and/or hash values for the list of contacts stored on the second mobile device or in a local database associated with the second mobile device.
- a second layer of security protocol in which the PPS server may generate and transmit a request to the second mobile device to forward a list of contacts and/or hash values for the list of contacts stored on the second mobile device or in a local database associated with the second mobile device.
- the second mobile device may generate hash values for contacts stored on the second mobile device.
- the second mobile device may generate hash values for each contact on the second mobile device in accordance to a hash function.
- the hash function may be a function that take input contact records of any length as their inputs and generate hash value of specific length.
- the hash function may be configured with block ciphers that take contact records as their inputs.
- the hash function may perform a block encryption of the contacts, and finally output the result as a hash value.
- the PPS server may execute a one-way hashing algorithm to convert the input contact records into the hash values where the length of the resulting hash is chosen such that one hash value indicates one contact.
- the second mobile device may then transmit the hash values for each contact stored on the second mobile device to the PPS server.
- the PPS server may then transmit the hash values for each contact stored on the second mobile device of the user to a user record file stored in a PPS database of the PPS server.
- the user record file may contain information related to the user, such as username, account number, social security number, address, a list of other authorized devices of the user, and hash value of contacts stored in other authorized devices of the user.
- the PPS server may initiate a query to the PPS database to retrieve the user record in order to identify previously stored hash value of contacts of other authorized devices of the user. Then the PPS server may compute a similarity contact score by comparing the hash values associated with the second mobile device with those of the second mobile device. In one example, the PPS server may derive the similarity contact score by counting a number of occurrences of each hash value for each contact obtained from the second mobile device of the user that appear in the previously stored hash value of contacts of other authorized devices of the user, such as previously stored hash values of contacts of the first mobile device of the user. In other words, the PPS server may compare the hash values for each respective contact record of the user stored on the second mobile device with the hash values for each respective contact record of the user obtained from the first mobile device of the user.
- the PPS server may rely not just on a count of the number of occurrence of each hash value, but could be based on weighted factors, in addition or as an alternative to the count of hash values. For example, the PPS server may determine a contact score based upon the popularity of certain contacts or often-used contacts, where such contacts are weighted more heavily than other contacts; this weighting is particularly useful in the event that a user mobile device does not copy every contact to the second device, and thus there could be gaps in the total data available for comparison.
- the PPS server will then determine whether the similarity contact score exceeds a threshold value. For example, the PPS server may determine whether the count of a number of occurrences of each hash value for contacts on the second mobile device when compared with the hash values of contacts of the first mobile device of the user exceeds a threshold number of matches.
- the threshold may include a value, a flag, or a variable input or set via the PPS server.
- the PPS server may receive or set a threshold number and stores the threshold number in the PPS database.
- the PPS server may determine the contact score based upon weighted contacts, which are weighted according to the respective popularity of certain contacts that are often-used.
- the PPS server compares the hash value of contacts stored on the second mobile device of the user and the hash value of contacts on the first mobile device of the user. When the comparison satisfies a threshold amount of matches, the PPS server may authenticate a user of the second mobile device to access a payment transfer application on the second mobile device at step 216.
- the PPS server may then generate additional questions for a user of the second mobile device and transmit the additional question to the second mobile device, at step 218. For example, when the PPS server may generate a list of one or more questions for the user, including but not limited to, details related to bank account, social security number, mother's name, father's name, date of birth, year of opening the service account of a payment transaction application, and last three transactions performed by the user using the payment transaction application.
- the list of one or more questions generated by the PPS server may be transmitted by the PPS server to the second mobile device of the user, and upon obtaining the answers provided by the user for the set of questions, the PPS server will then match the answers provided by the user for the list of one or more questions to answers previously provided by the user at the time of initial registration of an account of a payment transaction application that are stored in the PPS database.
- the PPS server Upon determining, by the PPS server, that the answers provided by the user for the set of questions matches with the previously provided and verified answers by the user for the same set of questions, the PPS server authenticates the user to access the payment transfer application service on the second mobile device.
- FIGS. 3A, 3B, and 3D illustrate a graphical user interface (GUI) 304 for presenting a login process of a user accessing payment transfer application on a mobile device 300, according to an embodiment.
- GUI graphical user interface
- the mobile device 300 has a display 302.
- the display 302 of the mobile device 300 may include a cathode ray tube (CRT) display, liquid crystal display (LCD), plasma, or light emitting diode (LED) display.
- the display 302 may provide some or all of the functionality of a user interface 304 of the mobile device 300.
- the display 302 may be a touch-sensitive and/or presence-sensitive display that can display a graphical user interface (GUI) 304 and detect input from a user in the form of user input gestures.
- GUI graphical user interface
- a graphics subsystem may receive textual and graphical information and process the information for output to the display 302.
- the display 302 includes a user interface 304 that allows a user of the mobile device 300 to interact with the mobile device 300.
- the examples of the user interface 304 include, but are not limited to, a keypad embedded on the mobile device 300, a keyboard, a mouse, a roller ball, buttons, stylus, or other devices that allow the user to interact with the mobile device 300.
- the mobile device 300 does not include the user interface 304, and the user interacts with the mobile device 300 with the display 302 (e.g., by providing various user gestures).
- the user interacts with the mobile device 300 with the user interface 304 and the display 302.
- the user interface 304 may further contain multiple portions where each portion may be used for a specific purpose, such as sending and receiving messages via a communication service application, generating a message and interacting with a third party application, and loading an application, such as the PSS API.
- a specific purpose such as sending and receiving messages via a communication service application, generating a message and interacting with a third party application, and loading an application, such as the PSS API.
- the user of the mobile device 300 requests access a payment transfer application installed on the mobile device 300, the user may be prompted to enter login details 306 such as username, as displayed on the user interface 304 of the payment transfer application, depicted in FIG. 3A.
- the PPS server may generate a message 308 indicating request to access to contacts, as displayed on the user interface 304 of the payment transfer application, depicted in FIG. 3B.
- the user of the mobile device 300 will have an option on one of the portions of the user interface 304 to accept or deny the request message.
- a hash value of contacts 312 are transmitted from the mobile device 300 to a database 310 of the PPS system, as depicted in FIG. 3C.
- a processor of the PPS system then compares, using a comparator 316, the hash value received from the mobile device 300 of the user with previously stored hash value of contacts 314 obtained from previous devices of the user.
- the PPS system processor Upon determining that the hash values of contacts received from the mobile device 300 satisfy a threshold amount of matches when compared with the hash values of contacts obtained from the previous devices of the user that are stored in the database 310, the PPS system processor authenticates the user of the mobile device 300 to access to the payment transfer application, and a home screen page 318 of the payment transfer application is launched on the display 302 of the mobile device 300, as depicted in FIG. 3D.
- FIG. 4 illustrates an example of a process 400 for generating and processing mobile payment requests, according to an embodiment.
- the steps of process 400 may be implemented using one or more modules of the PPS such as the PPS server.
- FIG. 4 does not imply any limitations with regard to the environments or embodiments that may be implemented. Modifications to the depicted environment or embodiment shown in FIG. 4 may be made.
- a PPS server may receive hash values for each contact in a list of contacts on a mobile device of a user.
- a user interested in using a payment transfer application of a PPS system might not have any relationship with the PPS system, so the user will be registering with the PPS system for the first time.
- the user may be asked by the PPS server to input a username and other identifying information, such as name, address, social security number, date of birth, and current and prior addresses for registering with the PPS system.
- a user may execute a payment transfer application on the mobile device.
- the mobile device may receive a request from the PPS server to create a hash value for each contact in the list of contacts stored on the mobile device or a local database associated to the mobile device.
- the mobile device may then create the hash value for each contact stored on the mobile device or the local database associated to the first mobile device.
- the mobile device may then transmit the hash value for each respective contact in the list of contacts to the server and/or store the hash value for each respective contact in the list of contacts in the local database associated to the mobile device along with the list of contacts.
- the mobile device may automatically create a hash value for each contact in the list of contacts stored on the mobile device or a local database associated to the mobile device. The mobile device may then automatically transmit the hash value for each respective contact in the list of contacts to the server and/or store the hash value for each respective contact in the list of contacts in the local database associated to the mobile device along with the list of contacts.
- the PPS server may transmit instructions to the mobile device.
- the instructions from the PPS server may specify one or more rules based on which the mobile device may periodically generate the hash value for contacts after pre-defined intervals of time. For example, is the mobile device may generate a new hash value for an updated contact list on the mobile device when there is a new addition of contacts in the list of contacts on the mobile device.
- the hash values generated for the updated contact list on the mobile device may then be transmitted to the PPS server and/or stored in the local database associated to the mobile device, along with list of updated contacts after the pre-defined intervals of time.
- the mobile device may receive instructions, upon the transfer of the hash value for each contact in the list of contacts from the mobile device to the PPS server, based on which the mobile device may have to generate and transmit the hash value for each new contact added by the user into a list of contacts as soon as the new contact is added in the mobile device.
- the mobile device transmits the hash value generated for each new contact to the server and/or stored in the local database associated to the mobile device along with details of the new contact.
- step 404 upon receiving the hash value for contacts on the mobile device, the
- the PPS server may store the hash values in the PPS database of the PPS system.
- the PPS database maybe a non-transitory machine-readable storage media capable of receiving, storing, and updating the mobile device contact records and their corresponding hash values.
- the PPS database may include a logical construct of data files that are stored in non-transitory machine-readable storage media, such as a hard disk or memory.
- the logical construct of data files may be controlled by software modules of a database program (for example, SQL), and a related database management system (DBMS) that executes the code modules (for example, SQL scripts) for various data queries and other management functions received from the PPS server and/or the mobile device.
- DBMS database management system
- the PPS server may receive a payment transfer request from the mobile device.
- the PPS server may receive the payment request from the mobile device by a communication application for initiating a payment transfer.
- the payment transfer request may include details related to an amount of money to be paid and identification of the recipient. In some embodiments, the payment transfer request may not include any identification of who will receive the payment (i.e., the recipient).
- the payment transfer request may be received by the PPS server through the communication application installed on the user's mobile device.
- the user's mobile device communication application may be linked, directly or indirectly, to the PPS server and notify the PPS server of any payment requests originated from the user's mobile device.
- the PPS server may receive the payment transfer request through an electronic input source when the user interacts with an electronic input source to request a payment to be made.
- an input source may be spoken words, e.g., various speech recognition software, various third-party applications native to user's mobile device, e.g., third-party instant messaging application or a third-party application from user's cell phone or other portable devices that support the same or similar operating systems, or inputting a corpus electronically from a computer implemented source such as another electronic device.
- the user may directly enter payment transfer request information into a mobile application native to user's mobile device and in direct communication with the PPS server or designated to communicate with the PPS server.
- the PPS server may have a designated payment transfer request (for example, the PPS API) for the user and payment transfer request may be generated through the application.
- the PPS server may initiate a comparison of the details of the recipient with information stored in a local database and/or a PPS database corresponding to a user profile. For instance, the mobile device may match the details of the recipient provided by the mobile device with the list of contacts or the hash values associated with the list of contacts stored in the mobile device and/or the PPS database under the user profile.
- the details of the recipient provided by the user of the mobile device in the payment transfer request may include username of the recipient and/or hash value of the recipient contact details. The mobile device will then match the hash value of the recipient contact details, with the list of hash values associated with the list of contacts stored in a mobile database and/or obtained from a PPS database of the PPS system.
- the mobile device may automatically identify a payment request to the recipient using information from a financial account associated with the user and stored in PPS database under the user profile and/or a local database associated to the mobile device of the user. For instance, if the user pays a same amount of money on substantially the same day each month or after a recurring event to the recipient, then the mobile device may identify the payment request as a recurring payment request to the recipient based on prior history of payments made by the user stored in the PPS database under the user profile and/or a local database associated to the mobile device of the user. In one example, the recurring payment is $1000 to pay for rent and occurs around the 5th day of every month.
- the mobile device and/or the PPS server may record the recurring payment in the local database associated to the mobile device of the user and/or the PPS database and expect a similar payment request to be generated for the recipient every month around the same time.
- the mobile device may send a notification to the PPS server that the recipient has matched one of the contacts or is in list of recipients of the prior payment history of the user.
- the PPS server may then approve the payment request of the user.
- the mobile device may send a notification to the PPS server that the recipient has not matched any contacts of the mobile device, and/or is not in list of recipients in the prior payment history of the user.
- the PPS server matches the recipient with contacts of contacts of the user. For instance, the PPS server may examine contact lists of some or all of user's contacts obtained from the mobile device in order to identify contacts of the user's contacts that match with the recipient contact details or corresponding hash value. In some embodiments, some or all of the user's contacts may also be registered with the PPS system, and therefore there may be a hash value associated to some or all of the user's contact stored in the PPS database of the PPS system.
- the PPS server may compute a similarity score among contact entries using any number of entries in a contact list.
- the PPS server may determine a similarity score based upon the contact entries received from two different mobile devices.
- the similarity score may be based upon contact list entries of a sending- user device and a recipient-user device, such that the PPS server reviews each user's contact list.
- the PPS server may compute a similarity score based on a full or subset of hash values for each user, such that the PPS server determines a similarity score indicating whether the sending-user is sending the payment to the correct, intended recipient.
- the similarity score may be based on a predetermined number of matches, or summation of weighted values of frequently employed contacts from both contact lists, between the two contact lists.
- the PPS server may determine the similarity score based upon the hash values of the recipient-user's contacts, at a predetermined degree of separation. For example, the PPS server may determine a similarity score between hash values for contacts from the sending-user device and hash values for contacts from the recipient-user device; the PPS server may then determine a supplemental similarity score (supplementing the initial similarity score) based upon hash values for contacts of the recipient-user device and a pre-stored hash values from the contacts list of one or more contacts of the recipient-user device. The PPS server may review the hash values for any number of contacts in the recipient-user device, at any iterative degree of separation.
- the PPS server may approve the payment transfer request of the user to the recipient. As previously mentioned, in some implementations, rather determine whether a count of matches satisfies a match threshold, the PPS server may determine a similarity score satisfies a score threshold.
- the server may transmit a confirmation request to user to confirm identity of the recipient.
- the PPS server may then approve the payment transfer request of the user.
- the confirmation request related to identify of the recipient may include details of the recipient including but not limited to name of the recipient, picture of the recipient, and/or bank account details of the recipient.
- the PPS server may obtain the details about the recipient, such as the picture of the recipient, from an external database, by searching for social networking profiles of the recipient, using input data provided by the recipient by the user.
- the PPS server may then approve the payment transfer process request of the user, and the payment is then transferred to a recipient mentioned on the payment transfer request.
- FIGS. 5A-5B illustrate a graphical user interface (GUI) 504 for presenting a mobile payment request from a mobile device 500, according to an embodiment.
- the mobile device 500 has a display 502.
- the display 502 of the mobile device 500 may include a cathode ray tube (CRT) display, liquid crystal display (LCD), plasma, or light emitting diode (LED) display.
- the display 502 may provide some or all of the functionality of a user interface 504 of the mobile device 500.
- the display 502 may be a touch- sensitive and/or presence-sensitive display that can display a graphical user interface (GUI) 504 and detect input from a user in the form of user input gestures.
- GUI graphical user interface
- the display 502 includes the user interface 504 that allows a user of the mobile device 500 to interact with the mobile device 500.
- the examples of the user interface 504 include, but are not limited to, a keypad embedded on the mobile device 500, a keyboard, a mouse, a roller ball, buttons, stylus, or other devices that allow the user to interact with the mobile device 500.
- the mobile device 500 does not include the user interface 504, and the user interacts with the mobile device 500 with the display 502 (e.g., by providing various user gestures).
- the user interacts with the mobile device 500 with the user interface 504 and the display 502.
- the user interface 504 may further have multiple portions where each portion may be used for a specific purpose such as sending and receiving messages via a communication service application, generating a message and interacting with a third party application and to load an application such as the PSS API.
- a message 506 showing a payment request for $100 to a recipient (ABC) has been initiated by the user.
- the user may generate a payment request using an input unit such as a keyboard, mouse, pointer, or other input generating device to facilitate input of instructions.
- the input unit may provide a portion of a user interface 504 for the mobile device 500, and may include an alphanumeric keypad for inputting alphanumeric and other key information along with a cursor control device such as a mouse, a trackpad, or stylus.
- a PPS server Upon generation of the payment request by the user, in some embodiments, a PPS server generates a payment authorization query to a record server, sometimes referred to as a "system of record" server. The record server communicates with a financial institute associated with the user in order to determine whether the user has sufficient funding to complete the payment request or not.
- the PPS server determines whether the recipient (ABC) matches one of the contacts on the mobile device 500 of the user or not. In some embodiments, the PPS server may determine whether the recipient (ABC) matches one of the contacts on the mobile device 500 of the user or not prior to generating a payment authorization query to the record server. In this example, the PPS server determines that the recipient (ABC) matches one of the contacts of the user stored in the mobile device 500 and the payment request of the user is accepted, and therefore a message 508 is displayed as depicted in FIG. 5B indicating to the user that the money has been transmitted to the recipient.
- the server on receiving inputs from a record server based on the payment authorization query, may determine that the user does not have sufficient money to transfer, then the PPS server generates instructions for user's mobile device to display message that informs the user that the user does not have sufficient funding to complete the payment request.
- the PPS server may generate instructions to user mobile device to display options for the user to cure the monetary deficiency. Options are generated by the PPS server based on the user account information kept in the PPS database. For example, the user has previously registered two bank cards with the PPS.
- the PPS server generates instructions to user mobile device to provide the user with options to cure the funding deficiency using those bank cards.
- FIGS. 6A-6C illustrate a graphical user interface (GUI) 604 for presenting a mobile payment request from a mobile device 600, according to an embodiment.
- the mobile device 600 has a display 602 where the display 602 includes a user interface 604 that allows a user of the mobile device 600 to interact with the mobile device 600.
- a message 606 shows a payment request for $100 to a recipient ("XYZ") has been initiated by the user.
- the user may generate a payment request using an input unit such as a keyboard.
- the PPS server determines that the recipient matches one of the contacts in a list of contacts stored in a memory of the mobile device 600, or the recipient matches one of the recipients in a payment history record of the user stored in a PPS database, or the recipient matches any contact of the contacts of the user.
- the PPS server upon determining that the recipient does not match any contacts in the list of contacts of the mobile device 600, or with a list of recipients in a payment history record of the user stored in the PPS database, or with any contact of the contacts of the user, the PPS server may then transmit a message 608 indicating a confirmation request to user to confirm identity of the recipient, as displayed in the FIG. 6B.
- the PPS server may then approve the payment transfer process request of the user, and a message 610 is displayed as depicted in FIG. 6C indicating to the user that the money has been transmitted to the recipient.
- This apparatus may be specially constructed for the required purposes, or it may comprise a special purpose computer selectively activated or reconfigured by a computer program stored in the computer.
- a computer program may be stored in a machine (e.g., computer) readable storage medium, such as, but is not limited to, any type of disk including floppy disks, optical disks, CD-ROMs and magnetic-optical disks, read only memories (ROMs), random access memories (RAMs) erasable programmable ROMs (EPROMs), electrically erasable programmable ROMs (EEPROMs), magnetic or optical cards, or any type of media suitable for storing electronic instructions for operations on a processor, and each coupled to a bus.
- ROMs read only memories
- RAMs random access memories
- EPROMs erasable programmable ROMs
- EEPROMs electrically erasable programmable ROMs
- magnetic or optical cards or any type of media suitable for storing electronic instructions for operations on a processor, and each coupled to a
- the exemplary embodiments described herein are described as software executed on at least one server, though it is understood that embodiments may be configured in other ways and retain functionality.
- the embodiments may be implemented on known devices such as a personal computer, a special purpose computer, cellular telephone, personal digital assistant ("PDA"), a digital camera, a digital tablet, an electronic gaming system, a programmed microprocessor or microcontroller and peripheral integrated circuit element(s), and ASIC or other integrated circuit, a digital signal processor, a hard-wired electronic or logic circuit such as a discrete element circuit, a programmable logic device such as a PLD, PLA, FPGA, PAL, or the like.
- any device capable of implementing the processes described herein may be used to implement the systems and techniques according to this disclosure.
- the exemplary embodiments may relate to an apparatus for performing one or more of the functions described herein.
- This apparatus may be specially constructed for the required purposes or be selectively activated or reconfigured by computer executable instructions stored in non-transitory computer memory medium or non-transitory computer-readable storage medium.
- the various components of the technology may be located at distant portions of a distributed network or the Internet, or within a dedicated secured, unsecured, addressed/encoded or encrypted system.
- the components of the system may be combined into one or more devices or co-located on a particular node of a distributed network, such as a telecommunications network.
- the components of the system may be arranged at any location within a distributed network without affecting the operation of the system.
- the components could be embedded in a dedicated machine.
- the various links connecting the elements may be wired or wireless links, or any combination thereof, or any other known or later developed element(s) that is capable of supplying or communicating data to and from the connected elements.
- the term "module” as used herein may refer to any known or later developed hardware, software, firmware, or combination thereof that is capable of performing the functionality associated with that element.
Landscapes
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Engineering & Computer Science (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Finance (AREA)
- Computer Networks & Wireless Communication (AREA)
- Computer Security & Cryptography (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
Description
Claims
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
AU2018213955A AU2018213955B9 (en) | 2017-01-30 | 2018-01-18 | Contacts for misdirected payments and user authentication |
CA3054287A CA3054287C (en) | 2017-01-30 | 2018-01-18 | Contacts for misdirected payments and user authentication |
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US15/419,921 | 2017-01-30 | ||
US15/419,940 | 2017-01-30 | ||
US15/419,921 US9934502B1 (en) | 2017-01-30 | 2017-01-30 | Contacts for misdirected payments and user authentication |
US15/419,940 US10810569B2 (en) | 2017-01-30 | 2017-01-30 | Contacts for misdirected payments and user authentication |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2018140272A1 true WO2018140272A1 (en) | 2018-08-02 |
Family
ID=61569395
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/US2018/014126 WO2018140272A1 (en) | 2017-01-30 | 2018-01-18 | Contacts for misdirected payments and user authentication |
Country Status (3)
Country | Link |
---|---|
AU (1) | AU2018213955B9 (en) |
CA (1) | CA3054287C (en) |
WO (1) | WO2018140272A1 (en) |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110033362A (en) * | 2018-11-14 | 2019-07-19 | 阿里巴巴集团控股有限公司 | One kind beating money method, device and equipment |
US10423948B1 (en) | 2017-06-29 | 2019-09-24 | Square, Inc. | Automated third-party messaging |
US10467615B1 (en) | 2015-09-30 | 2019-11-05 | Square, Inc. | Friction-less purchasing technology |
US10810574B1 (en) | 2017-06-29 | 2020-10-20 | Square, Inc. | Electronic audible payment messaging |
US10810569B2 (en) | 2017-01-30 | 2020-10-20 | Square, Inc. | Contacts for misdirected payments and user authentication |
US20220188784A1 (en) * | 2020-12-15 | 2022-06-16 | Bank Of America Corporation | System for implementing centralized resource distribution framework |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20050273626A1 (en) * | 2004-06-02 | 2005-12-08 | Steven Pearson | System and method for portable authentication |
US20110113029A1 (en) * | 2009-11-10 | 2011-05-12 | Madis Kaal | Matching Information Items |
US8682297B2 (en) * | 2011-10-11 | 2014-03-25 | Tangome, Inc. | Seamlessly authenticating device users |
EP2945410A1 (en) * | 2014-05-14 | 2015-11-18 | Mastercard International Incorporated | Security for mobile applications |
Family Cites Families (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20060131385A1 (en) * | 2004-12-16 | 2006-06-22 | Kim Mike I | Conditional transaction notification and implied approval system |
US8509734B1 (en) * | 2008-06-26 | 2013-08-13 | Amazon Technologies, Inc. | Location aware transaction authorization |
-
2018
- 2018-01-18 WO PCT/US2018/014126 patent/WO2018140272A1/en active Application Filing
- 2018-01-18 CA CA3054287A patent/CA3054287C/en active Active
- 2018-01-18 AU AU2018213955A patent/AU2018213955B9/en active Active
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20050273626A1 (en) * | 2004-06-02 | 2005-12-08 | Steven Pearson | System and method for portable authentication |
US20110113029A1 (en) * | 2009-11-10 | 2011-05-12 | Madis Kaal | Matching Information Items |
US8682297B2 (en) * | 2011-10-11 | 2014-03-25 | Tangome, Inc. | Seamlessly authenticating device users |
EP2945410A1 (en) * | 2014-05-14 | 2015-11-18 | Mastercard International Incorporated | Security for mobile applications |
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10467615B1 (en) | 2015-09-30 | 2019-11-05 | Square, Inc. | Friction-less purchasing technology |
US10810592B1 (en) | 2015-09-30 | 2020-10-20 | Square, Inc. | Friction-less purchasing technology |
US10810569B2 (en) | 2017-01-30 | 2020-10-20 | Square, Inc. | Contacts for misdirected payments and user authentication |
US11783314B2 (en) | 2017-01-30 | 2023-10-10 | Block, Inc. | Contacts for misdirected payments and user authentication |
US10423948B1 (en) | 2017-06-29 | 2019-09-24 | Square, Inc. | Automated third-party messaging |
US10810574B1 (en) | 2017-06-29 | 2020-10-20 | Square, Inc. | Electronic audible payment messaging |
CN110033362A (en) * | 2018-11-14 | 2019-07-19 | 阿里巴巴集团控股有限公司 | One kind beating money method, device and equipment |
US20220188784A1 (en) * | 2020-12-15 | 2022-06-16 | Bank Of America Corporation | System for implementing centralized resource distribution framework |
US11887082B2 (en) * | 2020-12-15 | 2024-01-30 | Bank Of America Corporation | System for implementing centralized resource distribution framework |
Also Published As
Publication number | Publication date |
---|---|
AU2018213955B9 (en) | 2021-11-04 |
CA3054287C (en) | 2022-07-12 |
AU2018213955A1 (en) | 2019-09-12 |
AU2018213955B2 (en) | 2021-07-08 |
CA3054287A1 (en) | 2018-08-02 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11783314B2 (en) | Contacts for misdirected payments and user authentication | |
US9934502B1 (en) | Contacts for misdirected payments and user authentication | |
US20230412367A1 (en) | Systems and methods for trustworthy electronic authentication using a computing device | |
AU2018213955B2 (en) | Contacts for misdirected payments and user authentication | |
US11706212B2 (en) | Method for securing electronic transactions | |
US10360561B2 (en) | System and method for secured communications between a mobile device and a server | |
US9378491B1 (en) | Payment transfer by sending E-mail | |
US9596237B2 (en) | System and method for initiating transactions on a mobile device | |
EP2652688B1 (en) | Authenticating transactions using a mobile device identifier | |
US9852416B2 (en) | System and method for authorizing a payment transaction | |
US11132425B1 (en) | Systems and methods for location-binding authentication | |
US20120150748A1 (en) | System and method for authenticating transactions through a mobile device | |
US20170213220A1 (en) | Securing transactions on an insecure network | |
US20200279263A1 (en) | System and method for processing a payment transaction based on point-of-sale device and user device locations | |
US20210049588A1 (en) | Systems and methods for use in provisioning tokens associated with digital identities | |
EP3579595B1 (en) | Improved system and method for internet access age-verification | |
US20200279270A1 (en) | Identity-backed authentication and authorization system | |
US20190026704A1 (en) | Method of registering a membership for an electronic payment, system for same, and apparatus and terminal thereof | |
US20170213213A1 (en) | Enhanced authentication security applicable in an at least partially insecure network environment | |
US11989278B2 (en) | Method and system for obtaining consent to perform an operation | |
US20230237172A1 (en) | Data broker | |
US20140143147A1 (en) | Transaction fee negotiation for currency remittance | |
US20140006271A1 (en) | Cross-network electronic payment processing system and method | |
WO2021146818A1 (en) | Identification verification system |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 18709173 Country of ref document: EP Kind code of ref document: A1 |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
ENP | Entry into the national phase |
Ref document number: 3054287 Country of ref document: CA |
|
ENP | Entry into the national phase |
Ref document number: 2018213955 Country of ref document: AU Date of ref document: 20180118 Kind code of ref document: A |
|
122 | Ep: pct application non-entry in european phase |
Ref document number: 18709173 Country of ref document: EP Kind code of ref document: A1 |