Patent Application
20100161494
The present invention relates to techniques for performing financial transactions over a network.
Businesses and financial institutions have made significant investments in financial infrastructure (including hardware and software) to supports secure processing of financial transactions between customers and businesses. For example, many businesses have front-end processors (such as point-of-sale terminals) that receive customer financial information (such as credit- or debit-card information) associated with financial transactions. These front-end processors communicate the customer financial information to back-end processors (which are sometimes referred to as ‘acquirer processors’), which, in turn, interact with financial institutions to determine whether or not a given financial transaction is approved or declined.
Unfortunately, different businesses and financial institutions use different variations of the financial infrastructure, and these variations are often incompatible with each other. For example, different debit-card payment processing systems (such as the Star Cash System™, New York Cash Exchange™, Honor™, Interlink™ and Maestro™) use different encryption key zones to each acquirer processor and each acquirer processor uses different encryption key zones to their respective merchants. Consequently, consumers are typically only able to use their debit card at the physical location of a merchant. Thus, credit- or debit-card payment processing systems include financial infrastructure (such as registered personal identification number or PIN pads) that are uniquely associated with particular businesses.
Unfortunately, this incompatible financial infrastructure can present obstacles to commerce, especially online commerce (which is sometimes referred to as e-commerce). In particular, online customers typically do not have access to the unique financial infrastructure for a given business, let alone the different variations which are used by other businesses. These obstacles make it difficult for customers to use the existing financial infrastructure to perform secure online financial transactions. Furthermore, the significant investment made by businesses and financial institutions in the existing financial infrastructure makes it unlikely that businesses will solve this problem by replacing the existing financial infrastructure with a new financial infrastructure.
One embodiment of the present invention provides a system (such as a computer system) that performs a financial transaction over a network. During operation, the system receives a first encrypted PIN code which is associated with the financial transaction and which is encrypted using a first encryption technique that is associated with a PIN pad (such as a key translation encryption technique that is used within an encryption zone). Next, the system translates the first encrypted PIN code into a second encrypted PIN code using a second encryption technique. This translation involves decrypting the first encrypted PIN code using the first encryption technique and re-encrypting the decrypted PIN code using the second encryption technique. Moreover, the second encryption technique is shared by a merchant associated with the financial transaction and an acquirer processor, which processes financial transactions for the merchant. Then, the system provides the second encrypted PIN code to the merchant for subsequent processing of the financial transaction.
Note that the first encrypted PIN code may be received from a customer in the financial transaction and/or the merchant. Moreover, the financial transaction may be associated with a debit card.
Additionally, the first encryption technique may be uniquely associated with the PIN pad, such as a PIN pad that is associated with a customer in the financial transaction. Furthermore, the first encryption technique and/or the second encryption technique may include DES or Triple DES managed by derived unique key per transaction (DUKPT).
In some embodiments, the system also receives first encrypted financial information which is associated with the financial transaction (such as additional details of the financial transaction) and which is encrypted using the first encryption technique. Then, the system translates the first encrypted financial information into the second encrypted financial information using the second encryption technique, and the computer system provides the second encrypted financial information to the merchant for subsequent processing of the financial transaction.
These operations performed by the system may facilitate financial transactions between the customer and groups of merchants and associated acquirer processors, because a given group of merchants and the associated acquirer processor may use a different encryption technique than other groups of merchants and their associated acquirer processors.
Another embodiment provides a method including at least some of the above-described operations.
Another embodiment provides the computer system.
Another embodiment provides a computer-program product for use in conjunction with the computer system.
Note that like reference numerals refer to corresponding parts throughout the drawings.
The following description is presented to enable any person skilled in the art to make and use the invention, and is provided in the context of a particular application and its requirements. Various modifications to the disclosed embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the present invention. Thus, the present invention is not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features disclosed herein.
Embodiments of a system (such as a computer system), a method, and a computer-program product (e.g., software) for use with the computer system are described. These embodiments may be used to perform financial transactions over a network. In particular, the system allows customers to use personal PIN pads when conducting financial transactions (such as debit-card transactions) with multiple merchants and their associated acquirer processors (which assist the merchants in processing financial transactions), even though different groups of merchants and acquirer processors may use different encryption techniques. For a given financial transaction, this capability may be implemented by decrypting financial information associated with a personal PIN pad from a customer and re-encrypting it using a separate encryption technique of a merchant and the associated acquirer processor.
By decrypting and re-encrypting financial information using this financial-transaction technique, customers may be able to perform financial transactions over networks (such as the Internet and/or a wireless network) using the existing encryption-key management techniques, such as those associated with debit cards. Moreover, this financial-transaction technique may allow a given customer to use a common personal PIN pad to conduct transactions with different groups of merchants and their associated acquirer processors, even though this involves the use of different encryption techniques. Consequently, this financial-transaction technique may facilitate secure commerce over these networks, with a minimum change in the existing financial infrastructure, thereby reducing associated costs and aggravation for merchants, acquirer processors and banks.
In the discussion that follows, debit-card transactions are used as an illustrative example of the financial-transaction technique. However, the financial-transaction technique may be used to facilitate a wide variety of financial transactions over networks, including cash withdrawals, cash advances, wire transfers and credit-card transactions.
We now describe embodiments of a process for performing financial transactions over a network.
After receiving the encrypted PIN code and additional financial information associated with the debit card (such as a user name and debit-card number), merchant 114 forwards the encrypted PIN code, the additional financial information, merchant information and PIN-pad information to acquirer processor 116 via a host network. Acquirer processor 116 translates the encrypted PIN code from the second encryption technique (which is shared in encryption zone 120-2) to a third encryption technique that is used throughout encryption zone 120-3, which includes acquirer processor 116 and financial institution 118 (such as a bank). In particular, acquirer processor 116 decrypts the encrypted PIN code using the second encryption technique and re-encrypts the decrypted PIN code using the third encryption technique prior to sending the re-encrypted PIN code, as well as the other financial information provided by merchant 114, to financial institution 118 via a debit-card network.
Once the financial institution 118 receives this financial information, a determination is made as to whether to approve or decline the financial transaction, and the resulting decision is communicated to merchant 114 by acquirer processor 116.
However, as noted previously, it is often difficult for customers to use existing financial-transaction technique 100 when they attempt to perform financial transactions over a network, such as a wireless network (e.g., using a cellular telephone) or the Internet. For example, it is difficult for customers to use debit cards to conduct financial transactions via the Internet because registered PIN pads (such as PIN pad 112-1) are associated with merchants (such as merchant 114), and different merchants and acquirer processors typically use different (incompatible) encryption techniques.
A solution to this problem is shown in
Customer validation authority 160 translates the encrypted PIN code from the first encryption technique (which is shared in encryption zone 120-1) to a second encryption technique that is used throughout encryption zone 120-2. In particular, customer validation authority 160 decrypts the encrypted PIN code using the first encryption technique and re-encrypts the decrypted PIN code using the second encryption technique prior to sending the re-encrypted PIN code, as well as the other financial information provided by customer 110, to merchant 114 via the host network. Subsequent processing of the financial transaction proceeds as described previously in the discussion of
In an exemplary embodiment, one or more of the encryption techniques in one or more of the encryption zones 120 includes derived unique key per transaction (DUKPT), which changes the encoding for each financial transaction to enhance security. Moreover, the DUKPT technique may utilize a data encryption standard (DES), triple DES, or another encryption technique known to one of skill in the art.
As shown in
Customer validation authority 160 and encryption zone 120-1 enable customers to conduct financial transactions using debit cards via the Internet. Moreover, a given customer (such as customer 110) can interact with multiple merchants, and thus, with multiple associated acquirer processors, using registered PIN pad 112-2, even though the host networks associated with these merchants and acquirer processors use different encryption techniques. Consequently, financial-transaction techniques 150 (
In some embodiments of process 200, there may be additional or fewer operations. For example, in addition to the first encrypted PIN code, the system may receive first encrypted financial information which is associated with the financial transaction (such as additional financial information associated with a debit card) and which is encrypted using the first encryption technique. Then, the system may translate the first encrypted financial information into the second encrypted financial information using the second encryption technique, and the system may provide the second encrypted financial information to the merchant for subsequent processing of the financial transaction. Moreover, the order of the operations may be changed, and/or two or more operations may be combined into a single operation.
We now describe embodiments of a computer system that performs process 200.
Note that this financial-transaction tool may be a stand-alone application or a portion of another application (such as financial software that is resident on and/or that executes on server 314). This financial-transaction tool may perform non-encryption aspects of the financial transaction. In an illustrative embodiment, the financial-transaction tool is a software package written in: JavaScript™ (a trademark of Sun Microsystems, Inc.), e.g., the financial-transaction tool includes programs or procedures containing JavaScript instructions, ECMAScript (the specification for which is published by the European Computer Manufacturers Association International), VBScript™ (a trademark of Microsoft, Inc.) or any other client-side scripting language. In other words, the embedded financial-transaction tool may include programs or procedures containing: JavaScript, ECMAScript instructions, VBScript instructions, or instructions in another programming language suitable for rendering by a web browser or another client application on the computer 310.
During the financial transaction, the user provides the financial information associated with the debit card (including the PIN code) to computer 310 and/or personal PIN pad 112-2. This information is either communicated, via network 312, to merchant 114 and then to customer validation authority 160 (which is resident on and which executes on server 314), or is communicated, via network 312, to customer validation authority 160 and then to merchant 114. In either embodiment, customer validation authority 160 translates the encrypted PIN code and/or encrypted additional financial information from a first encryption zone (associated with personal PIN pad 112-2) to a second encryption zone (associated with merchant 114 and acquirer processor 116). Subsequent processing of the financial transaction may proceed between merchant 114, acquirer processor 116 and one or more financial institutions (such as financial institution 118) via network 312, as described previously with reference to
In order for customer validation authority 160 to perform the translation from the first encryption zone to the second encryption zone, customer validation authority 160 needs to have access to appropriate encryption techniques for the user, as well as for merchant 114 and acquirer processor 116. For example, customer validation authority 160 may have access to this information based on business relationships with the user, merchant 114, acquirer processor 116, and/or financial institution 118. These business relationships may be associated with the financial software. For example, the user, merchant 114, acquirer processor 116, and/or financial institution 118 may use the financial software to conduct financial transactions, to perform financial planning, to generate a payroll and/or to perform financial accounting.
In general, information, such as encryption keys associated with one or more encryption techniques, may be stored at one or more locations in computer system 300 (i.e., locally or remotely). Moreover, because this information may be sensitive information, it may be encrypted. For example, stored information and/or information communicated via network 312 may be encrypted.
Computers and servers in computer system 300 may include one of a variety of devices capable of manipulating computer-readable data or communicating such data between two or more computing systems over a network, including: a personal computer, a laptop computer, a mainframe computer, a portable electronic device (such as a cellular phone or PDA), a server and/or a client computer (in a client-server architecture). Moreover, network 312 may include: the Internet, World Wide Web (WWW), an intranet, LAN, WAN, MAN, or a combination of networks, or other technology enabling communication between computing systems.
In exemplary embodiments, the financial software includes software such as: Quicken™ and/or TurboTax™ (from Intuit, Inc., of Mountain View, Calif.), Microsoft Money™ (from Microsoft Corporation, of Redmond, Wash.), SplashMoney™ (from SplashData, Inc., of Los Gatos, Calif.), Mvelopes™ (from In2M, Inc., of Draper, Utah), and/or open-source applications such as Gnucash™, PLCash™, Budget™ (from Snowmint Creative Solutions, LLC, of St. Paul, Minn.), and/or other planning software capable of processing financial information.
Moreover, the financial software may include software such as: QuickBooks™ (from Intuit, Inc., of Mountain View, Calif.), Peachtree™ (from The Sage Group PLC, of Newcastle Upon Tyne, the United Kingdom), Peachtree Complete™ (from The Sage Group PLC, of Newcastle Upon Tyne, the United Kingdom), MYOB Business Essentials™ (from MYOB US, Inc., of Rockaway, N.J.), NetSuite Small Business Accounting™ (from NetSuite, Inc., of San Mateo, Calif.), Cougar Mountain™ (from Cougar Mountain Software, of Boise, Id.), Microsoft Office Accounting™ (from Microsoft Corporation, of Redmond, Wash.), Simply Accounting™ (from The Sage Group PLC, of Newcastle Upon Tyne, the United Kingdom), CYMA IV Accounting™ (from CYMA Systems, Inc., of Tempe, Ariz.), DacEasy™ (from Sage Software SB, Inc., of Lawrenceville, Ga.), Microsoft Money™ (from Microsoft Corporation, of Redmond, Wash.), and/or other payroll or accounting software capable of processing payroll information.
Memory 424 in the computer system 400 may include volatile memory and/or non-volatile memory. More specifically, memory 424 may include: ROM, RAM, EPROM, EEPROM, flash memory, one or more smart cards, one or more magnetic disc storage devices, and/or one or more optical storage devices. Memory 424 may store an operating system 426 that includes procedures (or a set of instructions) for handling various basic system services for performing hardware-dependent tasks. While not explicitly indicated in the computer system 400, in some embodiments the operating system 426 includes a web browser. Memory 424 may also store procedures (or a set of instructions) in a communication module 428. These communication procedures may be used for communicating with one or more computers and/or servers, including computers and/or servers that are remotely located with respect to the computer system 400.
Memory 424 may also include multiple program modules (or sets of instructions), including: financial-transaction module 430 (or a set of instructions), encryption module 432, and optional financial module 450 (or a set of instructions). Using financial-transaction module 430, customers may provide financial information 434 associated with financial transactions, such as financial transaction A 436-1 and financial transaction B 436-2. This financial information may include encrypted PIN codes for debit cards. These encrypted PIN codes may be encrypted using encryption techniques 448 that are uniquely associated with corresponding PIN pads. Moreover, this unique correspondence may be included in registered PIN-pad information 438. In some embodiments, the financial information 434 is provided by the customers directly to computer system 400. Alternatively, at least some of the financial information 434 may be provided by the customers to businesses 442 (such as merchants), which provide the financial information 434 to computer system 400.
Financial-transaction module 430 (which performs at least some of the operations associated with customer validation authority 160 in
Note that in some embodiments, at least some of the financial information 434 is obtained or is associated with optional financial module 450 (such as the financial software).
Instructions in the various modules in the memory 424 may be implemented in: a high-level procedural language, an object-oriented programming language, and/or in an assembly or machine language. Note that the programming language may be compiled or interpreted, e.g., configurable or configured, to be executed by the one or more processing units 410.
Although the computer system 400 is illustrated as having a number of discrete items,
Computer systems 300 (
We now discuss data structures that may be used in computer system 300 (
Note that in some embodiments of data structure 500 there may be fewer or additional components. Moreover, two or more components may be combined into a single component, and/or a position of one or more components may be changed.
The foregoing descriptions of embodiments of the present invention have been presented for purposes of illustration and description only. They are not intended to be exhaustive or to limit the present invention to the forms disclosed. Accordingly, many modifications and variations will be apparent to practitioners skilled in the art. Additionally, the above disclosure is not intended to limit the present invention. The scope of the present invention is defined by the appended claims.
