Methods and apparatus for conducting secure, online monetary transactions6970852Abstract A system, method, and apparatus for conducting secure monetary transactions over a communications network is provided. The invention facilitates secure monetary and financial transactions over the Internet and other public networks for various purposes, including automated payments associated with purchasing goods or services online. Different implementation methods may be utilized, including systems based on proxy and psuedo-credit-card models. In each case, communications protocols are provided between a consumer, merchant web site, payment processor and a service provider, enabling online transactions to proceed in a secure manner. The invention utilizes a physical medium to provide consumers, merchants, and financial institutions with a secure system to conduct electronic commerce transaction. The preferred medium assumes the form of a miniature recordable CD-ROM that contains cryptographic data representing one-time monetary and/or transactional details. The medium can be used in a standard CD-ROM drive of a personal computer system, and easily fits in a wallet. Consumers insert the medium into the CD-ROM drive, enter a personal identification number, and complete the transaction process. Claims 1. A method of securely transferring data having a corresponding equivalent monetary value in a communications system including a first device having access to a removable recordable media having a first set of data encoded thereon, a second device having a second set of data thereon, a third device having a third set of data thereon, and a fourth device having a fourth set of data thereon, the method comprising the steps of: Description FIELD OF THE INVENTION Once the merchant has performed the above tasks, the e-shopping consumer will be presented with the IMC option at the checkout point. After the consumer chooses this payment option, a payment authentication page is downloaded, and this begins the payment session as described below. Once the payment session is complete, the merchant will receive notification from the IMC server, and will be ready to present the final confirmation (receipt) page to the consumer. Software Components The merchant has the choice of two methods for the integration of the inventive Payment Option. The easiest and fastest method is through a Link kit, and for the highest degree of customization an SDK option is available. The SDK option provides the most power and flexibility because the solution developed interacts directly with the an Authentication Service using the programming language of the developer's choice (i.e., Java, C/C++, or Perl). The following sections discuss each software component used in the Payment Process. An important point to keep in mind is that whether the merchant is using Link or the SDK options, the same underlying components are used. The only difference is that for the Link option each component is configured and delivered through an automated interface on the IMC server, thus circumventing most of the programming issues that need tending while working directly with the SDK. Consumer Browser "Checkout" Components 1. Payment Option. The Payment Option consists of a small piece of HTML script that is added to the web store checkout page, and must be designed to provide the correct visual feedback and user input so that the consumer may select the inventive service over the conventional payment options. A standard logo for the service is strongly recommended, and may be required by the merchant. The SDK and Link options both contain this logo in a Gif and .Jpg format. 2. Payment Session Script The Payment Session Script is a piece of HTML script that belongs on a page that will be presented once the consumer has selected the Payment Option. A primary function of this script is to direct the browser how to locate and initialize the Authentication Control, as described below. 3. Authentication Control The Authentication Control is a software component that is downloaded to the consumer's PC and controls the Payment authentication and authorization process on the client machine. It is this component that directly reads the hardware device containing the physical medium and its security data. It also handles the communication of this sensitive data to the Authentication Service. Depending on the targeted consumer browser, this control can take various forms. For example if the browser is Win32 ActiveX enabled, the Authentication Control is a signed ActiveX control. For other browsers, the control comes in the form of a Signed Java Applet or a Netscape Plug-In. Merchant Server Components 1. Authorization Processing. When an e-shopping consumer uses the physical medium to make a purchase at a merchant web-store, the IMC server generates what is called a payment authorization message. This message informs the merchant whether the transaction was successful. Authorization Processing refers to the work that must take place on the merchant's server in response to this Authorization Message. Typically, this will involve updating an order database to initiate a request for the delivery of the merchant's product or service; and in some cases, generating the consumer receipt page (or failure message in the case of a failed authorization). The merchant web store development team will use an API specifically developed to create the processing for incoming messages. An Authorization Message can be delivered to the merchant in one of the following three basic ways: Email notification, Http post, or through a custom network protocol based on RPC. In most if not all web store implementations today, there already exists the processing necessary to handle incoming authorizations from a variety of sources. Essentially, the payment option according to the invention essentially provides yet another payment type that should be easily introduced into the mix. The composition of the Authorization Message can be modified through the Merchant Account Manager, which is a web based administration tool for use by the merchant web store development team. An Integration Guide is preferably provided to assist the merchant development team in creating the Authorization processing. 2. Merchant API For the merchants who choose to use the SDK option, they will be writing code which makes use of a set of modules and library functions provided in the Merchant API. This API will permit the developer a central method from which to extract incoming messages from the IMC server and process them into the merchant database, as well as generate feedback for the e-shopping consumer. iMC Server Components 1. Card Database The database of the physical medium stores the data necessary to manage the vital functions of the inventive service. This includes tracking each card, consumer, merchant, and payment method as well as the consumer's shopping activity that includes each authorization request, whether the request was approved, and complete transaction history. 2. Authentication Service The Authentication Service provides the communication components necessary to fully authenticate a physical medium. It is the server side counterpart that the Authentication Control must talk to. It forms the necessary hand shaking, IMC database access as well as communication with the Payment Processor for payment authorization and settlement. 3. Merchant Account Manager The Merchant Account Manager provides web-based access to all aspects of a merchant's account. The functions provided include registration, setup and managing a merchant account. For example, it provides the merchant access to information that controls which payment processors and financial institutions the merchant's payment transactions will be used for electronic settlement. 4. Consumer Account Manager The Merchant Account Manager provides web-based access to all aspects of a customer's account. The functions provided include registration, setup and managing a customer account. Transaction Processing At least two basic models are available for integration into existing payment processing systems. Merchants can chose the implementation that best integrates with their checkout experience. According to the first method, the provider of the inventive service inserts itself between the merchant and the payment processor, and acts as a proxy between the consumer and the payment processor and merchant. The software interacts with the consumer to authorize the transaction and, in the final stage where the software provides an authentication token, the IMC server not only verifies the token but continues to process the transaction by obtaining an authorization from a payment processor and forwarding the authorization code to the merchant. In the second method, the provider of the inventive service operates in the periphery. The software in this case interacts with the consumer to authenticate a single transaction between the consumer and the merchant. It then generates a pseudo-credit card number that is submitted to the merchant to authorize the transaction. The merchant's software will forward the pseudo-credit card number to a payment processor as usual. The pseudo-credit credit card number is routed by the payment processor to the service provider to retrieve the consumers actual credit card number, expiration date, and billing address. The Proxy Model The proxy model is simple for the merchant to integrate into their Web site. It requires software modification on the part of the payment processors since it is implemented using their established APIs. The state diagram in FIG. 1 depicts the order of network calls in the proxy model. Initially, the consumer begins by visiting the checkout page of the merchant's Web site. From there, the following interactions and transactions take place: The IMC Web server will verify that the token is indeed the next token in the one time pad. At this point, the service provider has all of the information necessary for transaction processing stored in the session record. Before control returns to the browser, the IMC server will process the transaction for the consumer. Using the Card ID, the IMC server queries the database for the information required to process the transaction for the consumers selected payment method. For example, in the case of a credit card payment method, this would be the card number, expiration date, and billing address. This information has been provided by the consumer at registration. To integrate the service, the merchant will create a link on their checkout page that will be labeled in accordance with the inventive payment option. The link will pass the order ID, merchant id, and amount to the IMC Web server. The merchant's checkout page will have to dynamically change this link for each order. Once the transaction has been approved, the IMC server will post the approval code with the order ID to the merchant's Web server. The merchant will have to create a CGI script that will receive the order ID and approval code from the service provider. Pseudo Credit Card Model With the pseudo-credit model, the merchant has to do even less modification to their existing software base. After the IMC server performs the token-based authentication, it generates a pseudo-credit card number that is returned to the consumer's Web browser in a form. This form posts to the merchant's existing order processing script where it is treated like an ordinary credit card submission and forwarded to a payment processor. The payment processor then contacts IMC to exchange the pseudo-credit card number for the consumer's actual credit card number. If the credit card number itself is not large enough to uniquely identify transactions even when combined with a merchant ID, other fields that are commonly used in credit card transactions can be used to provide the necessary bandwidth. The billing address fields are candidates for the additional space. The state diagram in FIG. 2 illustrates the pseudo-credit card model. The network traffic is identical to the proxy model until the consumer submits their payment method choice. The IMC Web server receives the next token off the one time pad and the payment type. It verifies that the token is indeed the next token in the one time pad. The payment method is stored in the session record. The IMC Web server generates a unique identifier for this transaction. The unique identifier will be associated with the session data that has been stored in the session record. The unique identifier is retuned in hidden fields in a form to the consumers browser. When the consumer submits the form, it posts the pseudo-credit card information to the merchant's order processing script. The merchant's order processing script processes the form submission by forwarding the pseudo-credit card information to the payment processor. The payment processor identifies the pseudo-credit card information as originating from the service provider. It forwards the pseudo-credit card information to the IMC server. The IMC server retrieves the session record associated with the unique identifier encapsulated in the pseudo-credit card information. The IMC server returns to the payment processor the actual credit card number, expiration date, and billing address for the payment method that the consumer selected. The payment processor authorizes the transaction and returns an approval code to the merchant. The merchant stores the approval code and begins order fulfillment. It returns a page containing a detailed receipt to the consumer's Web browser. If the approval code indicates that the transaction has been denied, the merchant returns a Web page informing the consumer of the denial. Database Schema The following will detail the database schema for the IMC database by dividing the ERD into two components. One of the major tasks of the IMC database is to store cardholder information, including account information. The cardholder view of the ERD in FIG. 3 depicts the entities and relationships that together form the cardholder model. This information will be updated by the cardholder through a Web interface when the visit the IMC Web site. It will also be edited by customer service representatives in response to a cardholder inquiry, or by data entry personnel. The cardholder view of the ERD contains a separate entity for addresses. Entities that would otherwise duplicate address fields in their own definition instead have a many to many, or many to one relationship with the address entity. The address entity is used by merchant and account entities, for example. The card entity represents a physical medium according to the invention, and stores the tokens and the index of the next valid token. From the card entity, one can derive the cardholder and a list of accounts that can be used to make purchases. Entities that will be modified over time by the cardholder and customer service representatives will have those modifications tracked by the database. It will be possible for customer representatives to determine when a cardholder's information was last modified, how it was modified and by whom. The address, cardholder and account entities all contain the field "edited by" which contains the representative id of the last representative to edit the record, or no value if the cardholder last edited the record. Both the "edited by" and the "modified" fields are updated each time the entity updated. All changes made to these tables will be recorded in history tables. This will allow customer representatives to view the changes made to a cardholder's account information over time. The representative will be able to roll back erroneous modifications to the cardholder's data. For each entity whose change history is tracked there will be a history table that contains the same fields as the entity with an additional field in the key to denote the sequence of the edit, and an additional non-identifying field to indicate whether or not the entity has been deleted. The IMC database must also store the information required to authenticate a transaction. Each time a consumer attempts to authenticate a transaction an authorization session record is created. As information is sent from the consumer's Web browser, that information is stored in the session record. In the pseudo-credit card model, the authorization session entity is uniquely identified by the pseudo-credit card number. When the payment processor receives the pseudo-credit card number, it will retrieve the actual credit-card information from the IMC server. The IMC server will obtain this information by referring to the authorization session record. Once the transaction associated authorization session has been completed, the authorization session entity becomes a record of the transaction. Physically the transactions may be stored in a different table. Systems Architecture The invention preferably uses state-of-the-art, redundant, secure computing and networking systems, along with high-quality, stable, secure operating systems, redundant hardware and networking, and advanced Internet security technology. In all cases, redundancy will be used to enhance reliability. For instance, Oracle database replication will preferably be used to keep a hot backup of the production database server, multiple web servers with load-sharing and monitoring software (e.g., Resonate), RAID instead of individual disks, etc. Sun's Solaris is preferred as the primary operating system. Solaris is very stable, performs well, is well-understood, and can be made highly secure. For certain applications, OpenBSD or FreeBSD may be used, depending upon their state of development. The networking infrastructure will preferably use Cisco routers. For Internet security, we will use the security features of the Cisco routers, as well as application-level firewalls (Network Associates Gauntlet or Checkpoint Firewall-1). Our database servers containing confidential consumer information will be protected behind multiple filtering routers and firewalls, and will be running on secure operating systems. This approach of using multiple, complementary methods for system security assures a high level of security. The Internet connection will preferably have Cisco filtering rules, such that only necessary traffic is allowed through, packets are checked for appropriate source & destination, broadcast echo requests are disallowed, etc. Behind this Cisco will sit the "DMZ" (de-militarized zone), which will contain the web servers that need direct connections to the Internet: the front-end servers which serve consumer content, and the merchant connectivity servers which contact merchants to note payment authorization (under one potential protocol design). Connecting the DMZ to the "Private side" will be a pair of systems, to provide redundant security—if one fails, we have the other. First, there will be an application-level firewall such as Gauntlet or Checkpoint, which can perform active checks on the data being passed through to the other side. Next will be another Cisco router with a more-restrictive filter list. Availability is also a major concern. Consumers will want to be able to use their physical media at any time of the day or night. Multiple physical sites will therefore preferably be used, including multiple database servers, firewalls, and network hardware, and high-availability and load-balancing software on the front-end web site. Physical Media Production The physical medium preferably takes the form of a small, easily transportable card with variable dimensions for use with any standard device drive capable of reading and writing data to and from computer-readable media. A preferred physical medium according to the invention is a recordable CD-ROM card having the size and form of a creditor business card, as shown in FIG. 7. Such media can currently hold 20 Mbytes of data, though a larger form is now available which can hold around 50 Mbytes of data. The approximate dimensions of 2 inches by 4 inches by 1/16th inch or less facilitate easy portability in a wallet. A full-size disk may also be used. Multicolored images are best imposed onto a card via a large volume silk-screen process. A card can be visually individualized with a black ribbon printer during the recording process. Individualization could include a unique name, serial number, or bar code. The data recorded into a card is unique and is obtained from a repository under control of the inventive service provider. Currently, a single robotic machine consisting of four CDR-drives and one black printer can produces 100 cards per hour. One skilled in the art will recognize that the physical and functional design characteristics of the medium may be implemented in a variety of ways, so long as the implementation conforms to the functional requirements described herein. In addition, the card may be encoded on both sides, as technology permits, and information other than the use tokens described below may be encoded. For example, advertising or other information may be contained on the card, thereby at least partially offsetting the cost of manufacture and/or distribution. FIG. 8 shows an alternative medium in the form of an expandable magnetic medium 302. In this configuration, the expandable magnetic medium 302 in its collapsed state measures approximately 2 inches by 4 inches by 1/16th inch, thereby permitting the consumer to easily transport the expandable medium 302 as one would a credit card. In its expanded state, however, the magnetic medium 302 approximates the dimensions of a standard 3.5-inch floppy diskette. The expandable magnetic medium 302 is constructed from a durable plastic and metal combination housing an inner magnetic disk 322 shown in phantom lines for data storage. In the collapsed state, two protective outer sleeves 224 meet along an axis of the expandable magnetic disk, protecting the inner magnetic disk 322, and a third metal protective sleeve 326 located along a front edge of the magnetic expandable package to protect the inner magnetic disk 322. Due to the reduced overall size of the expandable magnetic medium 302 in its collapsed state, the diameter of inner magnetic disk 322 is substantially less than the diameter of a magnetic disk of a standard 3.5 floppy diskette. For this reason, the data storage capacity of the expandable magnetic medium 322 is reduced, and the distance the inner magnetic disk 322 extends into the drive is reduced as well. To accommodate the aforementioned reductions, a file allocation table (FAT) located at the interior portion of the inner magnetic disk 322 instructs a read/write head of the drive to search areas on the inner magnetic disk 322 where data is stored. The read/write head reads the FAT instruction on initialization of the personal computer and the associated disk drive, and eliminates drive errors due to an absence of magnetic medium under the entire length of head track during read/write operations to the expandable magnetic medium 302. To use the expandable medium, the consumer slides each outer sleeve along the length of the second protective metal sleeve 224 and away from the center of the expandable magnetic medium 302. The two protective outer sleeves 224 bring the overall width of the expandable magnetic disk 302 to 3.5 inches. The outer sleeves 224 snaps into place using a simple spring and groove system with track and groove similar to the protective portions found on a traditional 3.5-inch diskettes. Alternatively, the two outer sleeves 224 slide across a J-shaped groove track to lock into place. To collapse the expandable magnetic medium 302 to its smaller size, simply pull each outer sleeve 23 outward and away from the center of the expandable magnetic medium a fraction of an inch, and it snaps back to its reduced size using the J-grooves with a spring mechanism. One skilled in the art will recognize that multiple means for expansion and various design techniques are available in for this embodiment of the present invention. For example, a winged model 420 of the expandable medium shown in FIG. 9 replaces the outer sleeves 224 found in the expandable magnetic medium 302 a hinged wing on each side. The hinged wings affix with a standard rivet-style pin protruding through the expandable magnetic disk, and expand and collapse to provide dimensions appropriate for transportation and use of the winged model of FIG. 9. In addition to the uses described above, the one-time data tokens may be cryptographically derived identifiers representing a monetary value, each of which may be used to authorize a single transaction. For example, a dollar may be represented on the medium as a coded multidigit alphanumeric number (hereinafter, an AN string). With each AN string utilizing 16 bytes of storage space, the 120,000 byte usable surface will store approximately 7500 AN strings, or the equivalent of $7500.00 per medium. A slightly enlarged version of the medium holds approximately 29,437 AN strings, or $29,437. The remaining authentication data on the optic medium may be used to prevent the interception and unauthorized use of data tokens during reapplication of monetary value. If a consumer depletes the one-time data tokens on the optic medium, the consumer may apply more monetary value to the optic medium by consummating an online withdrawal from a bank or other authorized institution. The transfer of the one-time data tokens in this case preferably employs a two-tier scheme to secure the one-time data tokens 528 while enroute to the medium. First, upon issuance of each medium, a two-digit code is encrypted and hidden thereon, and the authentication server stores the two-digit number along with a reference to the associated medium. Upon request for revaluation of the medium, the authentication server downloads a sequence of 12-digit, unique AN strings. After download, the hidden two-digit code is added to each AN string to make a 14-digit AN string. Second, the authentication server adds a two-digit code and one hundred random AN strings to the download data. The one hundred random AN strings mask the two-digit, preventing deciphering of the same. Once the download completes, the two-digit code appends to each 14-digit AN string to complete the final 16-digit sequence necessary for a one-time data token. The authentication server records the complete 16-digit AN string by compiling all information pertaining to a 16-digit AN string from the authentication server information. Any attempt to intercept an AN string enroute to a consumer's personal computers results in, at best, the capture of a 12-digit, meaningless number. The inability to easily ascertain the two-digit code transferred with the AN strings coupled with an inability to ascertain the secret two-digit code hidden on each medium presents a robust, secure means to revaluate the same. The encoded data may also include application data for marketing, promotional, and other purposes. It is anticipated that the device drive connected to the personal computer reads the medium and transfers the application data to personal computer of the consumer for display on the video display unit in the form of images, video and other multimedia means designed to capture the attention of the consumer. The application data typically includes the logo of the issuing institution of the optic medium, media-rich advertising in the form of video clips, sound bytes, and other means to target the consumer. For example, the consumer's personal computer interacts with the merchant's server to process a payment transaction; the personal computer may concurrently display an advertisement utilizing several media on the video display monitor. It is anticipated that the various payment transaction models implemented for use with the present invention offer multiple methods to obtain and activate the medium. Some media are distributed in an immediately usable form, while others require consumer activation before use. In some case, a provision of a PIN number activates the medium, wherein the PIN number is known only to a consumer and an authentication server, and not encoded on the medium. In other cases, the activation requires the provision of a credit card or other valid payment instrument to associate with the medium itself. For example, the issuing bank preapproves consumers and the consumers requests the medium, the medium company provides media via a mass distribution scheme, or merchants offer retail stored-value cards. Each of these examples is discussed in detail below. FIG. 10 depicts the events in one method for issuing, providing, and activating the medium. Initially, a source 630 produces the media 631 in volume, and ships a medium to a consumer 632 upon request. The consumer utilizes a personal computer and the medium 631 to logon to a bank website 634 and provide information about the medium 631. The bank website 634 issues a PIN number 633 for the consumer for validation purposes. The bank website also contacts the authentication server 635 and its associated network of servers to provide the consumer account data relevant to the medium and the consumer 632. The authentication server 635 and the associated network of servers add the PIN number to the information pertaining to that particular medium 631 already stored in its database. The authentication server 635 then contacts the issuing bank 636 to exchange consumer account data, at which time the activated card may be used by a the consumer. FIG. 11 depicts the events surrounding a mass distribution method for providing media to consumers. Card production at a source 741 produces inactivated volumes of media 742 that are distributed to a population 743 of people via a predetermined plan and means. The distribution plan includes a provision for a separate distribution of unique PIN numbers, each corresponding to a medium 742 and each distributed via a separate channel from the medium 742 to prevent a breach of security. Once the consumer receives both the medium 742 and the PIN number, the consumer uses a personal computer to access a website associated with the bank 744 of the consumer. The PIN number and payment data on the card are forwarded via secure means to the website, and on to the authentication server 745 and its associated network of servers for activation. The authentication server 745 routes the activation data through the website of the bank 744, at which time the consumer can use the medium for online payment transactions. FIG. 12 depicts a distribution and activation process whereby the source 851 produces and encodes media 852 complete with authentication data and a series of one-time data tokens; i.e., active and ready for use by a consumer. The production and encoding process is implemented according to a predetermined plan in conjunction with an issuing bank 853, whereupon the individual data associated with each medium is transmitted to an authentication server 853a and its associated network of servers. Once the media are produced, they are distributed via a secure method; e.g., armored truck 854 to a retail establishment 855. Upon purchase by a consumer 856 from the retail establishment 855, the consumer can immediately use the medium 852 in conjunction with a personal computer system 857 for online payment transactions with various websites 858 associated with various merchants. Having illustrated and described the principles of the system, method, and apparatus of the present invention in various embodiments, it should be apparent to those skilled in the art that the embodiment can be modified in arrangement and detail without departing from such principles. For example, the physical manifestation of the medium may be changed if preferred. Therefore, the illustrated embodiments should be considered only as example of the invention and not as a limitation on its scope, which is defined by the following claims. We therefore claim as our invention all modifications and equivalents to the embodiment coming within the scope and spirit of these claims.
|
Same subclass Same class Consider this |
||||||||||