Recherche Images Maps Play YouTube Actualités Gmail Drive Plus »
Connexion
Les utilisateurs de lecteurs d'écran peuvent cliquer sur ce lien pour activer le mode d'accessibilité. Celui-ci propose les mêmes fonctionnalités principales, mais il est optimisé pour votre lecteur d'écran.

Brevets

  1. Recherche avancée dans les brevets
Numéro de publicationUS20110035320 A1
Type de publicationDemande
Numéro de demandeUS 12/907,355
Date de publication10 févr. 2011
Date de dépôt19 oct. 2010
Date de priorité21 nov. 2008
Autre référence de publicationUS7827108, US20100131408, WO2010059468A1
Numéro de publication12907355, 907355, US 2011/0035320 A1, US 2011/035320 A1, US 20110035320 A1, US 20110035320A1, US 2011035320 A1, US 2011035320A1, US-A1-20110035320, US-A1-2011035320, US2011/0035320A1, US2011/035320A1, US20110035320 A1, US20110035320A1, US2011035320 A1, US2011035320A1
InventeursJeffrey William Perlman, Sofia Walsh, Gregory Kenneth Storey
Cessionnaire d'origineJeffrey William Perlman, Sofia Walsh, Gregory Kenneth Storey
Exporter la citationBiBTeX, EndNote, RefMan
Liens externes: USPTO, Cession USPTO, Espacenet
System And Method For Validating A Relationship Between A User And A User Account At A Financial Institution
US 20110035320 A1
Résumé
A system and method for validating a relationship between a user and a user account at a financial institution includes a data communication device, a memory, a processor coupled to the memory, and an account validation module executable by the processor. The account validation module generates a verification identifier for storage in the memory and is provided to the user, and subsequently receives a user initiated financial transaction involving the user account at the financial institution. The received financial transaction includes a comparison identifier supplied by the user. The account validation module determines whether the comparison identifier corresponds to the verification identifier for purposes of validating the relationship between the user and the user account maintained at the financial institution.
Images(7)
Previous page
Next page
Revendications(18)
1. A method of establishing a trusted relationship for completing a series of electronic transactions, comprising:
storing user profile data in a memory of a payment system, the user profile data relating to an account of a user with the payment system;
generating a verification identifier at the payment system, wherein a first copy of the verification identifier is provided to the user, and wherein a second copy of the verification identifier is stored at the payment system;
receiving a transaction request at the payment system that identifies the account of the user and that includes the first copy of the verification identifier, wherein the transaction request is received over a network from a second system, and wherein the first copy of the verification identifier is supplied to the second system by the user for inclusion in the transaction request;
matching the received first copy of the verification identifier with the stored second copy of the verification identifier;
storing verification information in the memory of the payment system in association with the user profile data based on a successful match between the received first copy of the verification identifier and the stored second copy of the verification identifier; and
using the stored verification information to complete subsequent transaction requests from the second system relating to the account of the user, wherein the subsequent transaction requests do not require a copy of the verification identifier.
2. The method of claim 1, wherein the transaction request pertains to a financial transaction and the second system is a banking system at a financial institution.
3. The method of claim 1, wherein the user profile data includes account information relating to a user account at the second system.
4. The method of claim 3, wherein the stored account information in the user profile data is matched with information included in the transaction request for further verification.
5. The method of claim 3, wherein the account information includes a routing number and an account number.
6. The method of claim 1, wherein the stored verification information is a verification flag that is set by the payment system.
7. A method of establishing a trusted relationship for performing financial transactions with a financial institution, comprising:
storing user profile data in a memory of a payment system, the user profile data relating to an account of a user with the payment system;
storing financial account information in the memory of the payment system in association with the user profile data, the financial account information relating to a user account maintained at a financial institution;
receiving a user initiated financial transaction request at the payment system that identifies the user account at the financial institution, wherein the financial transaction request is received over a network from a financial institution and includes verification information for verifying a relationship between the user and the user account at the financial institution;
completing the financial transaction request based at least in part on the verification information; and
completing one or more subsequent user initiated transaction requests involving the user account at the financial institution, wherein the one or more subsequent user initiated transaction requests do not require verification information.
8. The method of claim 7, wherein the verification information includes a verification identifier.
9. The method of claim 8, wherein the verification identifier received with the financial transaction request is compared with a copy of the verification identifier stored in the memory of the payment system to verify the relationship.
10. A payment service system for making payments from a payment service account associated with a user, comprising:
a communication device;
a memory;
a processor coupled with the memory and communication device; and
an account validation module executable by the processor and configured to:
store user profile data in the memory that relates to the payment service account;
generate a verification identifier, wherein a first copy of the verification identifier is provided to the user, and wherein a second copy of the verification identifier is stored in the memory;
receive a transaction request that identifies the payment service account and that includes the first copy of the verification identifier, wherein the transaction request is received over a network from a second system, and wherein the first copy of the verification identifier is supplied to the second system by the user for inclusion in the transaction request;
match the received first copy of the verification identifier with the stored second copy of the verification identifier; and
store verification information in the memory in association with the user profile data based on a successful match between the received first copy of the verification identifier and the stored second copy of the verification identifier;
the payment service system being configured to complete subsequent transaction requests from the second system relating to the payment service account of the user, wherein the subsequent transaction requests do not require a copy of the verification identifier.
11. The payment service system of claim 10, wherein the transaction request pertains to a financial transaction and the second system is a banking system at a financial institution.
12. The payment service system of claim 10, wherein the user profile data includes account information relating to a user account at the second system.
13. The payment service system of claim 12, wherein the stored account information in the user profile data is matched with information included in the transaction request for further verification.
14. The payment service system of claim 12, wherein the account information includes a routing number and an account number.
15. The payment service system of claim 10, wherein the stored verification information is a verification flag.
16. A payment service system for making payments from a payment service account associated with a user, comprising:
a communication device;
a memory;
a processor coupled with the memory and communication device; and
an account validation module executable by the processor and configured to:
store user profile data in the memory, the user profile data relating to the payment service account;
store financial account information in the memory in association with the user profile data, the financial account information relating to a user account maintained at a financial institution; and
receive a user initiated financial transaction request that identifies the user account at the financial institution, wherein the financial transaction request is received over a network from a financial institution and includes verification information for verifying a relationship between the user and the user account at the financial institution;
the payment service system being configured to complete the financial transaction request based at least in part on the verification information; and
the payment service system being further configured to complete one or more subsequent user initiated transaction requests involving the user account at the financial institution, wherein the one or more subsequent user initiated transaction requests do not require verification information.
17. The payment service system of claim 16, wherein the verification information includes a verification identifier.
18. The payment service system of claim 16, wherein the verification identifier received with the financial transaction request is compared with a copy of the verification identifier stored in the memory of the payment system to verify the relationship.
Description
    CROSS-REFERENCE TO RELATED APPLICATION
  • [0001]
    This application is a continuation of U.S. patent application Ser. No. 12/275,397 filed Nov. 21, 2008, the entirety of which is incorporated herein by reference.
  • FIELD OF THE INVENTION
  • [0002]
    The present invention relates to data processing systems, and more particularly relates to a system and method of validating a relationship between a user and a user account at a financial institution.
  • BACKGROUND OF THE INVENTION
  • [0003]
    Internet-based payment service providers use payment systems (hereinafter referred to as ‘payment systems’ for the sake of brevity) that allow account holders (users) to transfer funds from accounts being maintained at their financial institutions, and perform financial transactions online with the transferred funds. For example, payment systems enable users to purchase goods and services online from the stored funds, and may also provide money market and brokerage services. However, as with other online services, there is the possibility of use of such user account for money laundering and other potentially illegal and unauthorized activity. Accordingly, it is important to implement security features that ensure that the transfer of funds to and from such accounts is legitimate, authorized, auditable and traceable.
  • [0004]
    Therefore, it would be desirable to provide a system and method of ensuring that a user account being maintained at a financial institution legitimately belongs to the user.
  • SUMMARY OF THE DISCLOSURE
  • [0005]
    In a first aspect, the present invention provides a system for validating a relationship between a user and a user account at a financial institution that includes a data communication device, a memory, a processor coupled to the memory, and an account validation module executable by the processor. The account validation module is adapted to generate a first verification identifier for storage in the memory, provide a second verification identifier corresponding to the first verification identifier to the user, receive a user initiated financial transaction involving the user account at the financial institution, the received financial transaction including a comparison identifier supplied by the user, and determine if the comparison identifier corresponds to the stored first verification identifier for purposes of validating the relationship between the user and the user account maintained at the financial institution.
  • [0006]
    In another aspect, the present invention provides a method of validating a relationship between a user and a user account at a financial institution that includes providing a verification identifier to a user, receiving a user initiated financial transaction involving the user account at the financial institution, the received financial transaction including a comparison identifier, and determining whether the received comparison identifier corresponds to the verification identifier provided to the user for purposes of validating the relationship between the user and the user account maintained at the financial institution.
  • [0007]
    In yet another aspect, the present invention provides a system for validating a relationship between a user and a user account at a financial institution that includes a data communication device, a memory, a processor coupled to the memory, and an account validation module executable by the processor. The account validation module is adapted to: (1) receive, from the user, user profile data containing a first account identifier of the user account, (2) generate a verification identifier, provide the verification identifier to the user, (3) receive a user initiated financial transaction involving the user account at the financial institution, the received financial transaction including a comparison identifier supplied by the user and a second account identifier, and (4) validate the relationship between the user and the user account maintained at the financial institution if the received comparison identifier corresponds to the generated verification identifier and the received second account identifier corresponds to the first account identifier contained in the received user profile data.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • [0008]
    FIG. 1 is a block diagram of an exemplary financial system in which the present invention may be employed.
  • [0009]
    FIG. 2 is an exemplary computer employed by the payment system to enable validation of a user account at a financial institution according to an embodiment of the present invention.
  • [0010]
    FIG. 3 is a flow chart of an exemplary process by which a user sets up an internal account with the payment system according to an embodiment of the present invention.
  • [0011]
    FIG. 4 is a schematic diagram of an exemplary user profile record according to an embodiment of the present invention.
  • [0012]
    FIG. 5 is a flow chart of an exemplary method of validating a user account at a financial institution according to an embodiment of the present invention.
  • [0013]
    FIG. 6 is an exemplary online banking transfer form according to an embodiment of the present invention.
  • DETAILED DESCRIPTION OF THE INVENTION
  • [0014]
    According to the present invention, a user establishes an internal account with a payment service provider, providing user profile data to the payment system which the payment system stores in a user profile record to identify the account. The user profile record, which is maintained securely, includes information identifying an account at a financial institution (other than the payment system) that the user may employ to transfer funds to or from the payment service provider. The financial institution may be a bank, a credit card facility or any other institution at which the user maintains a financial account. For example, a user may have an account at XYZ bank; the user profile record will then include the routing information of the XYZ bank and the user's account number at the XYZ bank.
  • [0015]
    When the internal user account is established at the payment service, the payment system generates a unique verification identifier associated with the account, and then sends the verification identifier or a corresponding verification identifier to the user. To ensure that the user has control of the user account at the financial institution, the payment service requests the user to perform a financial transaction with the user account (e.g., transfer $50 from the financial institution to the internal account maintained at the payment service) by including the verification identifier in the transaction.
  • [0016]
    Subsequently, when a financial transaction is received from the financial institution attempting to transfer funds into the user's internal account, the payment system validates that the user has a pre-existing relationship with the financial institution as a security measure. Specifically, the user directs the financial institution to include the verification identifier it has received previously from the payment system with the transaction along with the user's account information at the financial institution. Upon receipt of financial transaction, the payment system uses the received identifier as an index to locate the user's profile record. The payment system then determines whether financial account information included in the financial transaction matches the financial information in the user's profile record, indicating that the user has a relationship with the financial institution. If the relationship is validated, the verification identifier is no longer required to be included in further financial transactions between the financial institution and the payment system. However, the verification identifier may be included in further financial transactions for purposes of revalidation or as a steering mechanism to direct deposits to the appropriate user account.
  • [0017]
    FIG. 1 is a block diagram of an exemplary financial system 100 in which the present invention may be employed. The system 100 includes a payment system 102 employed by a payment service provider, in which a user 104 may establish financial accounts that store funds and which may be used to pay for goods and services online in a convenient manner. The user 104 may be any individual or corporate entity seeking to establish and use an account in the payment system 102. The user 104 may be connected to the payment system 102 via the Internet 106 using any suitable wire or wireless communication link.
  • [0018]
    The user 104 maintains a financial account at a financial institution 108. The financial institution 108 may be a bank, credit card facility, money market account or any other institution which holds financial accounts. The user 104 has control over the financial account at the financial institution 108 and can direct the financial institution 108 to transfer funds from the financial account by various means (e.g., check, credit or debit card, wire instruction, online interface, etc.) in a financial transaction. The financial institution 108 may communicate the financial transaction to the payment system 102 via a secure link 110, which may be proprietary, using known communication methods. For example, if the financial institution 108 is a bank, the financial transaction may be implemented using a direct entry (DE) file communicated by direct inter-bank transfer or through intermediary entities such as the Automated Clearing House (ACH). To support online communications, the financial institution 108 may also be connected to the Internet 106.
  • [0019]
    It is to be appreciated that while the system 100 of FIG. 1 is depicted as having a single user 104 and a single financial institution 108, this depiction is merely illustrative, and system 100 typically includes a plurality of users, each of which may have accounts at one or more financial institutions.
  • [0020]
    Referring now to FIG. 2, an exemplary computer (e.g., server) 200 of the payment system 102 is shown. The computer 200 includes a communication device 202 adapted for data communication using a plurality of communication modes and protocols. The communication device 202 receives information from and sends information to the user 104 via the Internet 106 and from/to the financial institution 108 over link 110. The computer 200 also includes a processor (CPU) 204, memory storage 206, program storage 208, and data storage 210, all commonly connected to each other through a bus 212. The program storage 208 includes an account validation module 214 that further includes a user registration module 216 and a matching module 218. The user registration module 216 includes program code for establishing internal user accounts and may support a web-based interface with forms, dialog boxes, etc. that prompt the user to enter information to register with the payment system 102. The matching module 216 performs validation of user accounts at financial institutions. The data storage 210 stores a user profile records 220 for all internal user accounts of the payment system 102. The software program modules in the program storage 208 and data in the data storage 210 may be transferred to the memory 206 as needed for ready access by the processor 204.
  • [0021]
    It is to be appreciated that the computer 200 may comprise any computer such as a personal computer, minicomputer, workstation or mainframe, or a combination thereof. While the computer 200 is shown, for illustration purposes, as a single computer unit, the system may comprise a group/farm of computers which can be scaled depending on the processing load and database size.
  • [0022]
    FIG. 3 is a flow chart of an exemplary process 300 by which a user 104 sets up an internal account with the payment system 102 according to an embodiment of the present invention. In step 302, the method begins. The user registration module 216 of the payment system 102 may support a web interface (not shown) having a registration form that prompts the user 104 to enter personal information (user profile data). In step 304, the user registration module 216 receives the user profile data entered into the web interface. In step 306, the user registration module 216 creates an internal account for the user 104 with a unique account identifier, such as an account number. In some embodiments, to keep the unique account identifier secure, the account identifier is not provided to the user and is kept inaccessible from the user 104 even when the user accesses his or her account at the payment system 102. This security measure reduces the possibility of identity theft and unauthorized access to the user's account.
  • [0023]
    In a following step 308, the user registration module 216 creates a user profile record associated with the new internal account (i.e., with the new unique account number) to store the received user profile data. The user profile record 400 may be stored as part of a database 220 of user profile records. An exemplary user profile record 400 according to an embodiment of the present invention is shown in FIG. 4. The exemplary user profile record 400 includes personal information 402 such as a secure ID 402, the user's name 404, address 406, verification identifier (explained below) 408, email address 410, tax ID 412, and account balance 414. In addition, the user profile record 400 includes financial account information 420, 430 for two financial institutions (financial institution #1, financial institution #2) at which the user maintains financial accounts. The financial account information 420 includes the name of financial institution 422, the routing number of the institution 424, the user's account number at the institution 426 and a verification flag 428 indicating whether the user's relationship with financial institution #1 has been verified. Financial account information 430 includes similar name 432, routing 434, account 436, and verification flag 438 information with respect to financial institution #2. The user profile record 400 may also include a transaction history 440 containing a list of transactions the user has performed using the payment system 102. The user profile record 400 may also include any other user information deemed appropriate.
  • [0024]
    Referring again to FIG. 3, the user registration module 216 receives the personal information 402 and financial account information of at least one of the financial institutions 420, 430 in step 308. In step 310, the user registration module 216 generates a unique verification identifier to be associated with the user profile record 400 (internal user account). In some embodiments, the verification identifier is a number or alphanumeric string of less than 16 digits or characters. The verification identifier may be partially or fully based on user information supplied by the user. For example, the identifier can be based on the name of the user whose name character string is converted into a number and then truncated to an appropriate size. In step 312, the user registration module 216 sends the verification identifier to the user 104. In some embodiments, in a following step 314, the user registration module 216 generates a second verification identifier derived from the first verification identifier (e.g., by hashing) and stores the second verification identifier in the user profile record 400 rather than the first verification identifier that has been sent to the user 104 as an added security measure. According to this embodiment, the verification identifier held by the user 104 and the verification identifier stored in the user profile record 400 differ, so that the verification identifier given to the user 104 is not directly accessible to personnel of the payment system 102.
  • [0025]
    In step 316, the user registration module 216 sends payee bank information of the payment system 102 to the user 104 (i.e., the account information of the payment system at a bank), enabling the user 104 to direct a money transfer from the user's financial institution 108 to the bank account of the payment system 102 and thereby to the internal user account at the payment system 102.
  • [0026]
    FIG. 5 is a flow chart of an exemplary method 500 of validating a user account at a financial institution according to an embodiment of the present invention. In step 502, the method begins. In step 504, a matching module 218 of the payment system receives a financial transaction notification (denoted simply as ‘financial transaction’ herein) from the financial institution 108 as directed by the user 104. FIG. 6 is an exemplary online banking transfer form 600 which the user may employ to transfer funds from the financial institution 108 to the user's account at the payment system 102. As indicated, the form 600 includes text input boxes for entering: the financial account information of the sending institution (From Account) 602, the financial account information of the payment system 604, the amount of the transfer 606, and reference information 610 as well as a selection box for the type of transfer 608. According to an embodiment of the present invention, the user 104 enters the verification identifier previously received from the payment system 102 in the reference information box 610. The information entered into form 610 is first delivered to the financial institution 108, which reformats the information into a financial transaction notification according to known inter-bank transfer protocols. For example, the financial institution 108 may incorporate the financial transaction in a direct entry (DE) file. Importantly, DE files may have fields and/or spaces in which the reference information 610 entered into the form 600, i.e., the verification identifier, may be entered. Since the matching module 218 tests the verification identifier included in the financial transaction, it is referred to as the ‘comparison’ identifier in the description below. Similarly, financial account information 602, 604, 606 is denoted as ‘second’ financial account information. The financial institution 108 sends the financial transaction to the payment system's account at the payee bank (not shown), which then passes the financial transaction to the matching module 218 of the payment system 102.
  • [0027]
    After the matching module 218 receives the financial transaction, in step 506, the matching module 218 queries the user profile records 220 for a corresponding verification identifier, for example, by performing the same hash used to derive the stored verification identifier on the comparison identifier and then comparing the hashed result with the stored verification identifier in the user profile record 400. It is noted that in embodiments in which the verification identifier that is sent to the user 104 and the stored verification identifier are the same, that a hashing process is not performed. If the user 104 has not registered with the payment system 102, in step 508, the matching module 218 causes a message indicating a denial of the transfer to the financial institution 108. After step 508, the method ends in step 518. If it is determined in step 506 that the user 104 has registered with the payment system 102, the comparison identifier will correspond to the stored verification in the user profile record database, and, in step 510 the corresponding user profile record is returned as the output of the query. In step 512, the matching module 218 then determines whether the second financial account information included in the financial transaction matches the first financial account information stored in the user profile record 400. More specifically, it is determined whether all items match, i.e., whether the first and second financial account information match exactly as to the name of the financial institution, the routing number, and the user account number. If the first and second financial account information match, in step 514, the matching module 218 validates the relationship between the user 104 and the financial institution 108 and the verification flag 438 in the user profile record 400 is set (e.g., to a check, “yes”, etc.). In step 516, the matching module 218 transfers the deposit to the internal user account at the payment system 102, and updates the balance information in the user profile record 400, and then the method ends in step 518. If it is determined that the first and second financial account information do not match in step 512, the method branches to step 508, and the matching module 218 causes a transfer denial message to be sent to the financial institution 108.
  • [0028]
    Once the relationship between the user 104 and a financial institution 108 has been validated, further financial transactions sent from the financial institution 108 to the payment system 102 do not require a verification identifier to be included (however, as noted, the verification identifier may be included in further transactions for purposes of revalidation or as a steering mechanism); when a subsequent financial transaction from a financial institution 108 is received, the matching module 218 can query the user profile records 220 using the routing number and account number of the financial institution 108 and thereby determine that the verification flag 438 associated with the routing and account number has been set, indicating that the user/financial institution relationship has already been validated. In an alternative embodiment, the payment system 102 may initiate subsequent transactions as directed by the user and ‘pull’ transfers from validated financial institutions. Since both the user and the relationship of the user 104 to the financial institution 108 are trusted, pull transactions performed in this manner do not present significant security risks.
  • [0029]
    The foregoing specific embodiments represent just some of the ways of practicing the present invention. Many other embodiments are possible within the spirit of the invention. Accordingly, the scope of the invention is not limited to the foregoing specification, but instead is given by the appended claims along with their full range of equivalents.
Citations de brevets
Brevet cité Date de dépôt Date de publication Déposant Titre
US4750119 *10 oct. 19867 juin 1988Tradevest, Inc.Purchasing system with rebate feature
US5132521 *15 sept. 198921 juil. 1992Smith Charles MSystem and method for acquisition and encoding of ATM card data
US5329589 *3 juin 199312 juil. 1994At&T Bell LaboratoriesMediation of transactions by a communications system
US5450537 *4 nov. 199312 sept. 1995Hitachi, Ltd.Method and apparatus for completing a partially completed document in accordance with a blank form from data automatically retrieved from a database
US5537314 *23 févr. 199516 juil. 1996First Marketrust Intl.Referral recognition system for an incentive award program
US5640577 *22 août 199517 juin 1997Davox CorporationData processing system with automated at least partial forms completion
US5717989 *13 oct. 199410 févr. 1998Full Service Trade System Ltd.Full service trade system
US5742845 *22 juin 199521 avr. 1998Datascape, Inc.System for extending present open network communication protocols to communicate with non-standard I/O devices directly coupled to an open network
US5794259 *25 juil. 199611 août 1998Lextron Systems, IncApparatus and methods to enhance web browsing on the internet
US5883810 *24 sept. 199716 mars 1999Microsoft CorporationElectronic online commerce card with transactionproxy number for online transactions
US6067621 *6 oct. 199723 mai 2000Samsung Electronics Co., Ltd.User authentication system for authenticating an authorized user of an IC card
US6182894 *28 oct. 19986 févr. 2001American Express Travel Related Services Company, Inc.Systems and methods for authorizing a transaction card
US6226624 *25 mars 19991 mai 2001Craig J. WatsonSystem and method for pre-authorization of individual account remote transactions
US6360205 *5 mars 199919 mars 2002Trip.Com, Inc.Obtaining and utilizing commercial information
US6421729 *14 avr. 199916 juil. 2002Citicorp Development Center, Inc.System and method for controlling transmission of stored information to internet websites
US6850996 *7 juil. 20031 févr. 2005Datascape, Inc.System and method for enabling transactions between a web server and an automated teller machine over the internet
US6871288 *21 févr. 200322 mars 2005Ronald K. RussikoffComputerized password verification system and method for ATM transactions
US6873974 *16 août 200029 mars 2005Citibank, N.A.System and method for use of distributed electronic wallets
US6907476 *3 févr. 200414 juin 2005Datascape, Inc.Open network system and method for I/O operations with non-standard I/O devices using an extended open network protocol
US6915271 *5 mars 19995 juil. 2005The Product Engine, Inc.Method and system for delivering redeeming dynamically and adaptively characterized promotional incentives on a computer network
US7062706 *29 avr. 200313 juin 2006America Online, Inc.Method and apparatus for populating a form with data
US7092913 *26 févr. 200215 août 2006Cannon Jr Thomas CalvinSystem for inexpensively executing online purchases
US7159180 *14 déc. 20012 janv. 2007America Online, Inc.Proxy platform integration system
US7216292 *1 sept. 19998 mai 2007Microsoft CorporationSystem and method for populating forms with previously used data values
US7254569 *23 juin 20047 août 2007Microsoft CorporationIntelligent autofill
US7257581 *6 août 200114 août 2007Guardian Networks, LlcStorage, management and distribution of consumer information
US7260724 *20 sept. 200021 août 2007Security First CorporationContext sensitive dynamic authentication in a cryptographic system
US7334184 *10 mars 200019 févr. 2008American Express Travel Related Services Company, Inc.Method for online information sharing for completing electronic forms
US7343351 *31 août 200011 mars 2008American Express Travel Related Services Company, Inc.Methods and apparatus for conducting electronic transactions
US7346587 *6 déc. 200218 mars 2008Aol LlcIntelligent method of order completion in an e-commerce environment based on availability of stored billing information
US7347361 *11 juil. 200625 mars 2008Robert LovettSystem, method and program product for account transaction validation
US7350139 *16 juin 200025 mars 2008American Express Travel Related Services Company, Inc.System and method for utilizing a drag and drop technique to complete electronic forms
US7366703 *4 janv. 200129 avr. 2008American Express Travel Related Services Company, Inc.Smartcard internet authorization system
US7379919 *11 avr. 200127 mai 2008Mastercard International IncorporatedMethod and system for conducting secure payments over a computer network
US7392536 *18 juin 200324 juin 2008Microsoft CorporationSystem and method for unified sign-on
US7395241 *19 janv. 20001 juil. 2008Intuit Inc.Consumer-directed financial transfers using automated clearinghouse networks
US7412420 *16 janv. 200312 août 2008U.S. Encode CorporationSystems and methods for enrolling a token in an online authentication program
US7415443 *24 sept. 200719 août 2008American Express Travel Related Services Company, Inc.Online card present transaction
US7483845 *24 juin 200327 janv. 2009Nokia CorporationMethods, system, and computer readable medium for user data entry, at a terminal, for communication to a remote destination
US7533063 *14 juin 200112 mai 2009Silicon Storage Technology, Inc.Smart memory card wallet
US7533828 *28 août 200719 mai 2009Ong Yong Kin MichaelElectronic credit card—ECC
US7552467 *23 avr. 200723 juin 2009Jeffrey Dean LindsaySecurity systems for protecting an asset
US7568631 *21 nov. 20054 août 2009Sony CorporationSystem, apparatus and method for obtaining one-time credit card numbers using a smart card
US7580898 *30 déc. 200625 août 2009Qsecure, Inc.Financial transactions with dynamic personal account numbers
US7657531 *5 janv. 20062 févr. 2010Bisbee Stephen FSystems and methods for state-less authentication
US7660779 *12 mai 20049 févr. 2010Microsoft CorporationIntelligent autofill
US7664699 *21 déc. 200516 févr. 2010Symantec CorporationAutomatic generation of temporary credit card information
US7680679 *26 janv. 200716 mars 2010Evolution Benefits, Inc.Method and system for processing transactions involving accounts for reimbursing medical expenses or patient responsible balances with multiple transaction substantiation modes
US7711621 *30 oct. 20074 mai 2010Visa U.S.A. Inc.Method and system for facilitating payment transactions using access devices
US7716596 *8 nov. 200611 mai 2010International Business Machines CorporationDynamic input field protection
US7729925 *31 janv. 20051 juin 2010Sony CorporationSystem and method for facilitating real time transactions between a user and multiple entities
US7761374 *18 août 200320 juil. 2010Visa International Service AssociationMethod and system for generating a dynamic verification value
US8069121 *4 août 200829 nov. 2011ProPay Inc.End-to-end secure payment processes
US20010013542 *2 juil. 199816 août 2001Edward HorowitzSystem and method for transferring value to a magnetic stripe on a transaction card
US20010014878 *9 nov. 199816 août 2001Nilotpal MitraTransaction method and apparatus
US20020002495 *19 mai 20003 janv. 2002Npax, Inc.Integrated pharmaceutical accounts management system and method
US20020004772 *10 juil. 200110 janv. 2002Templeton James E.System and method for verifying a financial instrument
US20020046341 *27 févr. 200118 avr. 2002Alex KazaksSystem, and method for prepaid anonymous and pseudonymous credit card type transactions
US20020083011 *21 déc. 200127 juin 2002Koji KobayashiTransaction mediation system and transaction mediation method
US20020120582 *4 mars 200229 août 2002Stephen ElstonMethod for establishing an electronic commerce account
US20030014633 *12 juil. 200116 janv. 2003Gruber Thomas RobertMethod and system for secure, authorized e-mail based transactions
US20030061111 *26 sept. 200127 mars 2003International Business Machines CorporationMethod and system for parent controlled e-commerce
US20030097331 *18 sept. 200122 mai 2003Cohen Morris E.Systems for financial and electronic commerce
US20030101134 *28 nov. 200129 mai 2003Liu James C.Method and system for trusted transaction approval
US20030135434 *3 juil. 200217 juil. 2003Ravi JainSystem and method for micro-payments
US20040039694 *24 juil. 200326 févr. 2004American Express Travel Related Services Company, Inc.System and method for facilitating a subsidiary card account with controlled spending capability
US20040044621 *27 août 20024 mars 2004Visa U.S.A., Inc.Method and system for facilitating payment transactions using access devices
US20040093303 *28 oct. 200313 mai 2004Picciallo Michael J.Third party debit card
US20040122770 *1 déc. 200324 juin 2004United Services Automobile Association (Usaa)System and method of processing account information over a computer network
US20040148252 *25 janv. 200229 juil. 2004Jack FleishmanOnline payment transfer and identity management system and method
US20050005094 *18 juin 20036 janv. 2005Microsoft CorporationSystem and method for unified sign-on
US20050097049 *14 août 20025 mai 2005Shea WriterMethods for verifying cardholder authenticity and for creating billing address database
US20050149455 *7 juin 20047 juil. 2005Visa U.S.A. Inc.Method and system for providing advanced authorization
US20060080238 *24 nov. 200413 avr. 2006Nielsen Thomas AMicro-payment system architecture
US20060089906 *21 oct. 200427 avr. 2006Michael RowleyMethod for securing a payment transaction over a public network
US20060143122 *9 mai 200329 juin 2006Sines Randy DPurchasing on the internet using verified order information and bank payment assurance
US20060143690 *30 juin 200529 juin 2006Yuh-Ren LinMultiple methods for transacting, publishing and purchasing copyrighted digital content
US20060190300 *19 avr. 200624 août 2006Fairpay Solutions, Inc.Post payment provider agreement process
US20070011093 *5 sept. 200611 janv. 2007Virtual Access LimitedSecure payment method and system
US20070061254 *15 sept. 200615 mars 2007Richard BlunckSystems and methods for opening, funding, and managing financial accounts
US20070136211 *30 déc. 200614 juin 2007Brown Kerry DFinancial transactions with dynamic card verification values
US20070198432 *5 oct. 200623 août 2007Pitroda Satyan GTransactional services
US20070198435 *31 janv. 200723 août 2007Jon SiegalMethod and system for providing online authentication utilizing biometric data
US20080015985 *11 juil. 200717 janv. 2008Armand AbhariSystem and process for expedited payment through online banking/payment channel
US20080091600 *27 avr. 200717 avr. 2008Rockne EgnatiosMethods and systems for opening and funding a financial account online
US20080091619 *11 oct. 200717 avr. 2008Visa International Service AssociationMethod and system for processing micropayment transactions
US20080110983 *15 nov. 200615 mai 2008Bank Of America CorporationMethod and apparatus for using at least a portion of a one-time password as a dynamic card verification value
US20080177796 *19 janv. 200724 juil. 2008Eldering Charles AMethod of Distributing Contact Information to Merchant Websites
US20080208762 *30 juil. 200728 août 2008First Data CorporationPayments using a mobile commerce device
US20090006646 *26 juin 20071 janv. 2009Data Frenzy, LlcSystem and Method of Auto Populating Forms on Websites With Data From Central Database
US20090063345 *29 août 20075 mars 2009American Express Travel Related Services Company, Inc.System and Method for Facilitating a Financial Transaction with a Dynamically Generated Identifier
US20090089176 *2 oct. 20072 avr. 2009American Express Travel Related Services Company, Inc.Modular electronic wallet
US20090094148 *24 janv. 20089 avr. 2009Gilder Clark SSystems and methods using paperless check 21 items
US20090121016 *8 juil. 200814 mai 2009Ayman HammadOn-Line Authorization In Access Environment
US20090171778 *28 déc. 20072 juil. 2009Jonathan Robert PowellMethods and systems for applying a rewards program promotion to payment transactions
US20090171850 *26 déc. 20072 juil. 2009Microsoft CorporationTransaction authentication platform using video
US20090173782 *2 janv. 20099 juil. 2009Muscato Michael ADynamic Card Validation Value
US20090210347 *5 nov. 200820 août 2009Branko SarcaninMethod and System for a Virtual Safe
US20090216676 *8 avr. 200827 août 2009Anup Kumar MathurIntegrated mobile transaction system and methods thereof
US20100153269 *17 déc. 200817 juin 2010American Express Travel Related Services Company, Inc.System, method, apparatus and computer program product for interfacing a multi-card radio frequency (rf) device with a mobile communications device
Référencé par
Brevet citant Date de dépôt Date de publication Déposant Titre
US90927783 déc. 201328 juil. 2015Varsgen, LlcBank account protection method utilizing a variable assigning request string generator and receiver algorithm
WO2014145566A1 *17 mars 201418 sept. 2014Gibson Jeffrey SFinancial account protection method utilizing a variable assigning request string generator and receiver algorithm
WO2015038353A1 *28 août 201419 mars 2015Ebay Inc.Electronic wallet fund transfer system
Classifications
Classification aux États-Unis705/44
Classification internationaleG06Q40/00
Classification coopérativeG06Q20/40, G06Q20/385, G06Q20/10, G06Q40/025, G06Q40/00, G06Q20/04
Classification européenneG06Q40/00, G06Q20/04, G06Q20/10, G06Q40/025, G06Q20/385, G06Q20/40