WO2014058951A1 - Comptes avec niveaux multiples de pré-autorisation - Google Patents

Comptes avec niveaux multiples de pré-autorisation Download PDF

Info

Publication number
WO2014058951A1
WO2014058951A1 PCT/US2013/063992 US2013063992W WO2014058951A1 WO 2014058951 A1 WO2014058951 A1 WO 2014058951A1 US 2013063992 W US2013063992 W US 2013063992W WO 2014058951 A1 WO2014058951 A1 WO 2014058951A1
Authority
WO
WIPO (PCT)
Prior art keywords
account
initiator
transaction
machine
verification
Prior art date
Application number
PCT/US2013/063992
Other languages
English (en)
Inventor
Jorge M. Fernandes
Ziad Alshobaki
Original Assignee
Quisk, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US13/755,421 external-priority patent/US8959032B2/en
Priority claimed from US13/786,408 external-priority patent/US20140101025A1/en
Application filed by Quisk, Inc. filed Critical Quisk, Inc.
Publication of WO2014058951A1 publication Critical patent/WO2014058951A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/02—Banking, e.g. interest calculation or account maintenance

Definitions

  • an account at a financial institution such as a bank account
  • a financial institution has certain fixed limitations on transactions that can be performed on it.
  • Certain accounts may limit ATM cash withdrawals to $300 total per day.
  • the account holder may be required to go through extra verification procedures.
  • the account holder may be required to show a form of photo identification (for example, a driver's license) to a teller at a bank branch.
  • the account holder must go through these extra verification procedures every time a transaction falls outside the account's fixed limitations. Moreover, usually the account holder has no control over the fixed limitations - they are pre-set by the financial institution.
  • Embodiments of the present invention provide a method of configuring a financial account.
  • the configuration includes limitations on later transactions, based on user identity information provided at the time of configuration.
  • One embodiment includes a computer- implemented method for such a configuration process.
  • a server device receives a request to configure an account from an initiator.
  • the server device sends a prompt for verification information to the initiator.
  • the prompt for information may be a list of verification options including the account limitation associated with each option.
  • the initiator sends the verification information to the server.
  • the server creates the account if one does not already exist.
  • the server configures the account with the limitation associated with the later transaction.
  • the limitation depends, at least in part, on the verification information.
  • the server device optionally generates a compact identification code and sends it to the initiator.
  • the server device receives data for an active transaction associated with the account.
  • the transaction data is compared to the limitation, and the transaction is processed if the data is w ithin the limitation.
  • Another embodiment of the present invention includes a machine-readable medium including instructions executable by the machine. These instructions cause the machine to accept receipt of a request to configure an account from an initiator.
  • the machine is instructed to send the initiator a prompt for verification information. This may comprise sending to the initiator a list of verification options including the account limitation associated with each verification option.
  • the machine is instructed to receive the verification information from the initiator.
  • the machine is instructed to create an account if one does not already exist.
  • the machine is instructed to configure the account with the limitation associated with a later transaction.
  • the limitation depends, at least in part, on the verification information.
  • the machine is optionally instructed to generate a compact identification code and send it to the initiator.
  • FIG. 1 is a block diagram of an account configuration system according to an embodiment of the present invention.
  • FTG. 2 is a flowchart of an account configuration method according to an embodiment of the present invention.
  • FIG. 3 is a block diagram of an account configuration system using an outside source of verification information, according to an embodiment of the present invention.
  • FIG. 4 is a flowchart of an account configuration method using an outside source of verification information, according to an embodiment of the present invention.
  • FIG. 5 is a flowchart of an account configuration or modification method, according to an embodiment of the present invention.
  • FIG. 6 is a flowchart of an account modification method using account data, according to an embodiment of the present invention.
  • FIG. 7 is a flowchart of an account configuration method, with a subsequent transaction method included, according to an embodiment of the present invention.
  • FIG. 8 is a flowchart of an account configuration method, with a subsequent mobile- phone-initiated transaction method included, according to an embodiment of the present invention.
  • FIG. 9 is a block diagram of a point-of-sale transaction system using a configured account, according to an embodiment of the present invention.
  • FIG. 10 is a block diagram of an online sale transaction system using a configured account, according to an embodiment of the present invention.
  • FIG. 1 1 is a block diagram of a peer-to-peer transaction system using a configured account, according to an embodiment of the present invention.
  • the present disclosure relates to accounts used for monetary or credit transactions.
  • the present disclosure relates to pre-configuring such an account to allow or deny a later transaction based on certain limitations.
  • an account has extra verification data associated with it. This data is stored and then keyed to more compact verification information - for example, to a mobile phone number and/or a user-defined personal identification number (PIN). The account holder can then perform transactions that would normally require extra identification procedures simply by providing this compact verification information.
  • PIN personal identification number
  • the account described herein is a regular bank account, possibly with added features.
  • the account described herein may also be similar to the MOBI account, described in U.S. Patent Publication No. 2009/0024533 Al for "Payment Systems and Methods” filed August 29, 2007, or U.S. Patent Application No. 13/755,421 for "Self-authenticating peer-to-peer transaction” filed January 31, 2013, both of which are owned by the assignee of the present invention, and both are incorporated herein in their entirety.
  • the extra verification data provided at account configuration may also be required to satisfy various "know your customer" (KYC) regulations. These are regulations regarding which forms of identification are acceptable for various transactions. For example, these regulations may stipulate that customers wishing to make higher value transactions must present more secure forms of identity verification.
  • KYC knowledge your customer
  • the configuration methods described herein are not limited to new accounts; existing accounts can be reconfigured using the same methods.
  • the account holder may change the extra verification data associated with the account, and/or the limitations associated with the account may change automatically based on account usage data,
  • Communication means include (i) messages to and/or from a mobile device such as email messages, voice calls, data messages, text messages, messages sent via other applications (e.g., Facebook, Linked In, Skype and the like) and (ii) the same sort of messages sent to and/or from a stationary device such as a desk top computer or browser running on a television.
  • FIG. i shows a block diagram 100 exemplary of an embodiment of this invention.
  • An initiator 1 10 for example, a user who wants to open a new account or re-configure an existing account - communicates with an account server 130 through a network 120 via any of a number of communication means.
  • the network 120 could be, for example, the Internet.
  • the account server 130 maintains an account 135.
  • the account 135 is configured with one or more limitations 136 associated with later transactions. These limitations 136 will be compared with data from the later transactions in order to allow or deny the processing of the transaction.
  • limitations 136 that could be associated with the account 135. Such examples include, but are not limited to, a maximum limit on cash withdrawals, or a maximum limit on purchases, or other maximum transaction limits; limitations on currencies in which transactions may be denominated; or limitations on transaction types (for example, online purchases may restricted, but point-of-sale purchases may be allowed). Other examples include: maximum deposit limits, limitations on the number of transactions in a given time period (e.g., day, week, or month), restrictions on the location of the transaction, restriction on type of item or service purchased, or a restriction on people to whom cash is sent.
  • a maximum limit on cash withdrawals or a maximum limit on purchases, or other maximum transaction limits
  • limitations on currencies in which transactions may be denominated for example, online purchases may restricted, but point-of-sale purchases may be allowed.
  • Other examples include: maximum deposit limits, limitations on the number of transactions in a given time period (e.g., day, week, or month), restrictions on the location of the transaction, restriction on type of item or
  • FIG. 2 shows a flowchart 200 of an account configuration process.
  • the process represented by flowchart 2.00 may be implemented via a telephone call (to an automated voice system, for example), or a series of text messages, or a web site on a mobile or stationary device, or interactively through a bank branch or financial institution office, or at a merchant point-of- sale (POS), or any combination of these.
  • the account server 130 receives from the initiator 1 10 a request to configure an account 135.
  • This request may be sent, for example, from an Internet-connected mobile or stationary device, via a web site form; it may also be sent via a text message or a phone call from a mobile device, for example, to an automated voice interactive system.
  • step 220 the account server 130 sends a request to the initiator 1 10 for verification information.
  • the request sent in step 220 may be in the fonn of, for example, a list or menu of different verification options and the account limitations to which they correspond.
  • Such a menu may be presented, for example, on a web page, or as part of an automated voice system (in the case where the operation is taking place over the phone), or interactively, by a merchant at a POS, or an agent at a bank.
  • one menu option may be to type in an existing PIN, corresponding to an account maximum transaction limit of $100, or $300; another option may be to scan or photograph an identifying document, such as a passport or driver's license, to enable a higher account transaction maximum (for example, $500, or $1000, or $1500).
  • identifying document such as a passport or driver's license
  • Other examples of verification information include a series of identifying questions presented to the initiator, an account number of a second account (which has, for example, already been configured), a photograph of the initiator, a government-issued identifier, or a trusted-source issued identifier.
  • biometric information such as fingerprint or retinal scans. This type of verification information may allow even higher transaction limits, for example, S5000 or $10,000.
  • biometric information such as fingerprint or retinal scans.
  • This type of verification information may allow even higher transaction limits, for example, S5000 or $10,000.
  • Different combinations of options may be available for different limitations - for example, both photo ID's and biometric information may be required for transactions involving certain currencies.
  • different levels may be set for different types of transactions; for example, a user may want to configure an account for a $500 purchase limit but a $100 cash withdrawal limit. In this way, an account may be configured with multiple limitations.
  • Other limitation combinations for example, limitations consistent with KYC regulations - may be available.
  • Transactions on the account may still be subject to some limitations that are not based on the initiator's configuration choices; for example, a total cash withdrawal limit of $1000 per day may be fixed by the financial institution and not be configurable.
  • the account server 130 may also request, in step 220, the initiator's mobile phone number, which may serve as part of the initiator's identification for each later transaction.
  • the account server 130 receives the verification information from the initiator 1 10.
  • This step may comprise, for example, the initiator choosing from the menu of different verification options, and then providing the information associated with that option.
  • the initiator may choose to provide an image of her passport, for a maximum transaction limit of $1000, The initiator then can submit an image of the required document; for example, by scanning it, or taking a picture of it with her mobile phone camera, or with a web camera attached to or embedded in a stationary computer.
  • the initiator may send the image via a postal service, or may show it to an authorized agent.
  • the verification information requested may require specialized hardware to submit; for example, a fingerprint scanner.
  • the initiator may visit an office, such as a bank branch, to complete the configuration procedure.
  • the account server 130 configures the account 135 based on the verification information acquired in step 230.
  • This step may comprise, for example, storing the received verification intonnatioii and associated transaction limitations in a secure storage area, and/or generating a secure compact identifier, such as a PIN, that the initiator will use (along with, for example, his mobile phone number) for identity verification for each later transaction.
  • the secure PIN may be sent to the initiator, for example, via physical mail (e.g., U.S. Postal Service), or it may be given to the mitiator if he is in a bank branch office or POS.
  • the server may request the initiator to select a secure PIN.
  • This request may be sent by any of the means discussed above: web site, phone call/voice message system, text message, or interactively at a POS or office, and the like.
  • the initiator may respond with the secure PIN using similar communication means.
  • the server may optionally send the initiator a temporary validation code (or temporary PIN) to use while waiting to receive the permanent secure PIN.
  • FIG. 3 Shown in FIG. 3 is a block diagram 900 of a system that includes an outside source of verification data 150, which can communicate to the initiator i 10 directly and/or through the network 120, The outside source 150 also communicates with the account server 130 through the network 120.
  • an outside source of verification data 150 which can communicate to the initiator i 10 directly and/or through the network 120.
  • the outside source 150 also communicates with the account server 130 through the network 120.
  • FIG. 4 shows a flowchart 1000 illustrating how the system 900 illustrated in FIG. 3 would operate.
  • the initiator 1 10 sends a request to configure an account to the server 130 in step 210, and ihe server requests verification information from the initiator in step 220.
  • the server receives verification information in step 230; this verification information may include a key that allows the server to request information from an outside source.
  • the initiator may send a user ID and a password so that the server 130 can access an outside financial account, or another account similarly configured with extra verification infomiation.
  • the server 130 uses this information to request further verification from the outside source 150; for example, the server may request an account balance of an outside financial account, or it may request the verification information with which another, similar, account was configured.
  • the server 130 receives this additional verification information from the outside source 130.
  • the server requests that the initiator validate the information it has received from the outside source, and the initiator sends validation of this outside data.
  • the account is configured, and a compact identifier is generated, in step 240.
  • FIG. 5 shows a flowchart 300 of an account configuration process that accommodates initializing new accounts or re-configuring existing accounts.
  • the account holder initiator
  • the account server 130 receives from the initiator 1 10 a request to configure a new account, or re-configure an existing account
  • the account server 130 sends a request to the initiator 1 10 for verification information.
  • the request sent in step 220 may be in the form of, for example, a web site page that comprises a menu of different verification options and the account limitations to which they correspond. Again, this step may also include a request for a mobile phone number, as well as a request for a previously defined secure PIN, if the initiator wishes to modify an existing account, rather than create a new account.
  • the account server 130 receives the verification information from the initiator.
  • the account server 130 checks to see if the account exists; for example, by comparing the mobile phone number submitted with its database of existing accounts, if the account does not exist, it is created in step 238.
  • the account (new or existing) is again configured based on the verification information received in step 230.
  • FIG. 6 shows a flowchart 1 100 for such a method.
  • the initiator requests to reconfigure the account based on account usage data.
  • step 210 is optional; the flowchart 1 100 may be run automatically, thus periodically checking to see if the account can be refigured.
  • the server may check account usage every month to see if limitations may be upgraded, or if the need to be downgraded.
  • step 260 the usage data is checked to see if it qualifies the initiator for a change in limitations.
  • the initiator keeps an average daily balance of more than $1000 for a month, then he may be eligible to increase his maximum withdrawal limit by $50. If the usage data qualifies the initiator for a change in limitations, the account is re-configured with the new limitations in step 280.
  • FIG. 7 shows an extended flowchart 400 of the configuration process, followed by the verification of a later transaction against the limitations set up during account configuration.
  • Element 300 of FIG. 7 represents the account configuration process as described in any of the embodiments above.
  • the account 135 is ready to accept transaction requests.
  • the account server 130 receives data for a transaction associated with the account 135.
  • the data may be sent from, for example, the initiator, or from a merchant, or a combination of the two. This data may comprise, for example, the type of transaction, the amount of the transaction, and the transaction's currency.
  • the initiator may want to make a point-of-sale purchase.
  • the merchant may send part of the transaction data - for example, the purchase amount - to the server.
  • the initiator may then complete the purchase by sending to the server her secure PIN, for example.
  • the server receives both pieces of this transaction data in step 410 of FIG. 7.
  • step 420 of FIG. 7 the server compares the transaction data with the pre-configured limitations 136 associated with the account 135.
  • this comparison could comprise comparing the purchase price to the pre-configured maximum purchase amount associated with the account 135. If the transaction data fails within the pre- configured limits - for example, if the transaction price is below the POS purchase price limit - then the transaction is processed, as shown in step 430. If not, the transaction is not processed. In this case, the initiator may be given the opportunity (not shown) to provide other verification information in order to re-configure the account with increased limitations; in effect, repeating step 300 in FIG. 7.
  • FIG. 8 shows a flowchart 500 detailing a variation on the extended process described in FIG. 7.
  • the configuration process 300 takes place, and the account 135 is ready to accept transaction requests.
  • the server 130 receives data for a transaction; all or part of this data is sent from the initiator's mobile device.
  • the initiator may, for example, send her secure PIN from her mobile device via a text message.
  • some information about the transaction may be sent to the server by another party; for example, the merchant may send the purchase price information to the server.
  • the server uses caller ID information, including, for example, the initiator's mobile phone number, to identify the initiator's account.
  • the server compares the transaction data with the pre- configured limitations 136 associated with the account 135 in step 420, and the transaction is processed, if the transaction data falls within the pre-configured limitations for the account, in step 430.
  • FIG. 9 shows a block diagram 600 of a point-of-sale transaction system using a pre- configured account.
  • an initiator 1 10 makes a purchase from a merchant 610.
  • Both the initiator 1 10 and the merchant 610 may transmit transaction information to the account server 130, via a network 120.
  • the merchant 610 may send the purchase price, and other product information, to the server 130 via a web-enabled device, and the initiator 1 10 may confirm the purchase, for example, by texting his secure PIN to the server 130 using his mobile device.
  • the network 120 comprises multiple communication channels - the merchant 610 may use the Internet, while the initiator 1 10 uses a cellular network.
  • the account server 130 may identify the initiator's account 135, for example, by using caller ID information. The server 130 then compares the transaction data to limitations 136 associated with the account 135, and, if the transaction falls within the limitations 136, the server 130 will process the transaction. At this point, the server 130 may send a message to the merchant 610, and possibly the initiator 1 10, indicating that the purchase has been approved (i.e., that the purchase price funds have been transferred to the merchant), and the merchant 610 may give the purchased product to the initiator 1 10. This notice of approval may, for example, be a web-based message sent to the merchant 610, and/or a text message sent to the initiator 1 10.
  • FIG. 9 may also represent a system wherein an initiator 1 10 withdraws cash from his account 135,
  • the merchant 610 has a cash register.
  • both the initiator 1 10 and the merchant 610 may send transaction information to the server 130, and, again, the server 130 uses this information, and the limitations 136 associated with the initiator's account 135, to approve or deny the transaction. If the transaction is approved, notice, again, is sent to the merchant 610 and possibly the initiator 1 10, and the merchant 610 can then hand the cash to the initiator 110.
  • FIG. 10 shows a block diagram 700 of an online transaction system using a pre- configured account.
  • the initiator 1 10 makes an online purchase from the merchant 610, through, for example, the merchant's web site.
  • the initiator 1 10 may access the merchant's web site on a stationary or mobile de vice, connected to a network 120; for example, the Internet.
  • Both the initiator 110 and the merchant 610 may transmit transaction information to the account sei'ver 130 via the Internet.
  • the initiator 1 10 may then be prompted by the web site to enter her mobile phone number and secure PIN.
  • the server 130 compares the transaction data to limitations 136 associated with the account 135, and, if the transaction falls within the limitations 136, the server 130 will process the transaction.
  • the server 130 may then send a confirmation message to the merchant 610 and the initiator 1 10, and the merchant 610 can ship the product to the customer.
  • the confirmation message from the server 130 may be sent to the initiator 1 10 and merchant 610, for example, via an e-mail message,
  • the server 130 may deny the purchase, if the purchase data does not fail within the limitations 136 of the pre-configured account 135.
  • the initiator 110 in this case may be given the opportunity to provide other verification information in order to re-configure the account with increased limitations.
  • the initiator may be re-directed to a web site where he can re-configure his account providing extra verification data, if necessary.
  • FIG . 1 1 shows a block diagram 800 of a peer-to-peer transaction using a pre-configured account exemplifying the present invention.
  • the initiator 1 10 sends a remittance to a recipient 810.
  • Both initiator 1 10 and recipient 810 connect to the account server 130 via a network 120, for example, a cellular network.
  • the initiator may begin by sending transaction information and recipient information to the account sei'ver 130. This -information may be sent, for example, in a text message, and may include, for example, the recipient's mobile phone number and the amount to remit to the recipient.
  • the sei'ver 130 may identify the initiator's account 135 from, for example, the initiator's caller ID information.
  • the server 130 compares the transaction data to limitations 136 associated with the account 135, and, if the transaction falls within the limitations 136, the server 130 may proceed with the transaction. For example, the server 130 may then ask for additional verification information from the initiator 1 10 and recipient 810. When all verification procedures are completed successfully, funds may be transferred from the initiator's account to the recipient's account. If the recipient does not have an account, he may be prompted to create one,
  • the present invention provides a multi-step system to pre-configure, and re-configure, accounts to operate with different limitations on transactions.
  • this system may operate in the following manner:
  • This prompt may be in the form of a menu of different verification options and their corresponding account limitations.
  • Computer code that controls the system to accept receipt of the initiator's verification information This may consist of:
  • the initiator for the appropriate verification information; for example, the initiator's mobile phone number, and a photograph or a scan of the initiator's passport;
  • a secure, compact identifier for example, a secure PIN
  • the system may send a request for a self-generated PIN to the initiator, and subsequently receive the initiator's PIN.
  • the system as set forth herein also provides methods to verify later transactions with the pre-eonfigured limitations described above.
  • this system may verify transactions in the following manner:
  • this may be, for example, for a point-of-sale purchase, where a merchant sends purchase price information to the server, and the initiator (purchaser) sends her compact identifying information to the server, via her mobile phone.
  • Computer code that control s the system to process the transaction if the transaction data is within the limitations; for example, if the purchase price is less than the POS purchase price limit set for the account.
  • the code then may control the system to notify the merchant and initiator of the successful transaction,
  • a mobile device may be a mobile phone, two-way pager, tablet or notebook computer, and the like.
  • a compact identifier may be a PIN, or a pseudorandom code, or the like.
  • Secure identity verification may be a photograph of one of the transacting parties, or a photograph of identification documents, such as a passport, license, or utility bill, or the like, or biometric information such as a fingerprint or retinal scan.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Engineering & Computer Science (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • Technology Law (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

L'invention concerne un système et un procédé de pré-configuration d'un compte financier en vue de transactions ultérieures. Le système comprend un serveur de comptes qui, après avoir reçu une demande de configuration d'un compte de la part d'un initiateur, envoie à l'initiateur une sollicitation d'informations de confirmation d'identification. Après avoir reçu les informations de confirmation, le serveur configure le compte avec des limitations basées au moins en partie sur les informations de confirmation. Le serveur peut également envoyer à l'initiateur un code compact sécurisé d'identification qui peut être utilisé pour des transactions ultérieures. Ces transactions ultérieures sont vérifiées en les confrontant aux limitations prédéfinies associées au compte, et elles sont traitées si elles se situent dans le cadre des limitations.
PCT/US2013/063992 2012-10-10 2013-10-09 Comptes avec niveaux multiples de pré-autorisation WO2014058951A1 (fr)

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US201261711957P 2012-10-10 2012-10-10
US61/711,957 2012-10-10
US13/755,421 2013-01-31
US13/755,421 US8959032B2 (en) 2012-10-10 2013-01-31 Self-authenticating peer to peer transaction
US13/786,408 US20140101025A1 (en) 2012-10-10 2013-03-05 Accounts with multiple pre-authorization levels
US13/786,408 2013-03-05

Publications (1)

Publication Number Publication Date
WO2014058951A1 true WO2014058951A1 (fr) 2014-04-17

Family

ID=50477839

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2013/063992 WO2014058951A1 (fr) 2012-10-10 2013-10-09 Comptes avec niveaux multiples de pré-autorisation

Country Status (1)

Country Link
WO (1) WO2014058951A1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20050063176A (ko) * 2003-12-22 2005-06-28 김학수 다중 비밀번호 체계가 적용된 금융시스템과 그 제어방법
KR20060096593A (ko) * 2005-03-02 2006-09-13 주식회사 비즈모델라인 카드(또는 계좌) 관리방법 및 시스템과 이를 위한 기록매체
JP2006260504A (ja) * 2005-03-17 2006-09-28 Toshihiro Handa Ａｔｍシステム及び方法並びにキャッシュカード
US20080011823A1 (en) * 2004-07-28 2008-01-17 Cisco Technology, Inc. System and method for securing transactions in a contact center environment
US20120066758A1 (en) * 2010-09-13 2012-03-15 Srinivas Kasturi Online User Authentication

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20050063176A (ko) * 2003-12-22 2005-06-28 김학수 다중 비밀번호 체계가 적용된 금융시스템과 그 제어방법
US20080011823A1 (en) * 2004-07-28 2008-01-17 Cisco Technology, Inc. System and method for securing transactions in a contact center environment
KR20060096593A (ko) * 2005-03-02 2006-09-13 주식회사 비즈모델라인 카드(또는 계좌) 관리방법 및 시스템과 이를 위한 기록매체
JP2006260504A (ja) * 2005-03-17 2006-09-28 Toshihiro Handa Ａｔｍシステム及び方法並びにキャッシュカード
US20120066758A1 (en) * 2010-09-13 2012-03-15 Srinivas Kasturi Online User Authentication

Similar Documents

Publication Publication Date Title
US11935045B1 (en) Mobile wallet account provisioning systems and methods
US8301500B2 (en) Ghosting payment account data in a mobile telephone payment transaction system
US20140258123A1 (en) Tokenized Payment Service Registration
WO2019055972A1 (fr) Systèmes et procédés de fourniture de modèles biométriques à des dispositifs biométriques
US11587058B1 (en) Mobile wallet integration within mobile banking
US11410161B1 (en) Mobile wallet systems and methods
US11928668B1 (en) Mobile wallet using tokenized card systems and methods
US11868977B1 (en) Payment services via application programming interface
US20140258009A1 (en) Payment service registration
US10997654B1 (en) Identity verification services through external entities via application programming interface
US20210019741A1 (en) Mobile wallet systems and methods using trace identifier
US20140101025A1 (en) Accounts with multiple pre-authorization levels
US20230153792A1 (en) Mobile wallet account activation systems and methods
US11663599B1 (en) Mobile wallet authentication systems and methods
WO2014058951A1 (fr) Comptes avec niveaux multiples de pré-autorisation
US11132670B1 (en) Systems and methods for performing payment transactions using indicia-based associations between user interfaces

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: 13845445

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 13845445

Country of ref document: EP

Kind code of ref document: A1