Search Images Maps Play YouTube News Gmail Drive More »
Sign in
Screen reader users: click this link for accessible mode. Accessible mode has the same essential features but works better with your reader.

Patents

  1. Advanced Patent Search
Publication numberUS20040117321 A1
Publication typeApplication
Application numberUS 10/688,734
Publication dateJun 17, 2004
Filing dateOct 16, 2003
Priority dateJul 30, 1999
Also published asUS7885899, US20050108177
Publication number10688734, 688734, US 2004/0117321 A1, US 2004/117321 A1, US 20040117321 A1, US 20040117321A1, US 2004117321 A1, US 2004117321A1, US-A1-20040117321, US-A1-2004117321, US2004/0117321A1, US2004/117321A1, US20040117321 A1, US20040117321A1, US2004117321 A1, US2004117321A1
InventorsEnrique Sancho
Original AssigneeSancho Enrique David
Export CitationBiBTeX, EndNote, RefMan
External Links: USPTO, USPTO Assignment, Espacenet
System and method for secure network purchasing
US 20040117321 A1
Abstract
There is disclosed a method for performing secure electronic transactions on a computer network, the network comprising a buyer's computer, a vendor server, a creditor server and a security server. The buyer's computer has a fingerprint file stored in the memory thereof. The method includes the steps of:
i) the buyer computer requesting to purchase merchandise to the vendor server, the purchase request including said buyer computer's IP address;
ii) the buyer computer selecting a predetermined form of secured payment method;
iii) the payment method selection causing the vendor server to transmit to the security server a request for confirmation of the buyer computer's identity at the buyer computer's IP address;
iv) the confirmation request causing the security server to send a retrieval request to the IP address, the retrieval request including a retrieval program for detecting and retrieving the buyer's computer's fingerprint file, and the retrieval request further comprising a response request asking for confirmation of the purchase request; whereby a positive response from the buyer's computer to the security server accompanied by the fingerprint file causes the security server to confirm the buyer computer's identity to the vendor server and to approve the purchase.
Images(7)
Previous page
Next page
Claims(37)
I claim:
1) In a computer network, a system for performing a secured transaction between a buyer's PC, a vendor server, a creditor server and a security server, wherein said buyer's PC has received fingerprint programming from said security server.
2) A system for performing a secured transaction according to claim 1, wherein said buyer's PC has received encryption programming and decryption programming from said security server.
3) A method for performing secure electronic transactions on a computer network, said network comprising a buyer's computer, a vendor server, a creditor server and a security server, said buyer's computer having a fingerprint file stored in the memory thereof, including the steps of:
i) said buyer computer requesting to purchase merchandise to said vendor server, said purchase request including said buyer computer's IP address;
ii) said buyer computer selecting a predetermined form of secured payment method;
iii) said payment method selection causing said vendor server to transmit to said security server a request for confirmation of said buyer computer's identity at said buyer computer's IP address;
iv) said confirmation request causing said security server to send a retrieval request to said IP address, said retrieval request including a retrieval program for detecting and retrieving said buyer's computer's fingerprint file, and said retrieval request further comprising a response request asking for confirmation of said purchase request; whereby a positive response from said buyer's computer to said security server accompanied by said fingerprint file causes said security server to confirm said buyer computer's identity to said vendor server and to approve said purchase.
4) A method of performing secure electronic transactions on a computer network, said network comprising a buying computer, an ISP computer and a vendor computer, including the steps of:
said ISP computer assigning to buying computer a Buyer-ID code and IP address;
said buying computer communicating via said ISP computer with said vendor computer and allowing an operator to select merchandise or services for purchase;
said Buyer-ID and buyer computer's IP address are provided to vendor computer programmed to request and receive said information;
vendor computer is programmed to use Buyer-ID and BC's current IP address along with information such as desired Item ID, cost and name for generating an electronic purchase inquiry which is transmitted to ISP computer;
ISP is programmed such that upon receipt of purchase inquiry from MC, ISP uses combination of IP address and Buyer-ID to determine within ISP's internal network whether Buyer is in fact still online at the address assigned at the beginning of the online session;
whereby if buyer computer is determined to be connected to ISP computer at correct address, ISP computer then generates and transmits Transaction Confirmation Number and instructs MC to generate and forward invoice to ISP computer.
sending at least one verification response, based upon the comparing of the first fingerprint file against the second fingerprint file and upon the comparing of the first identification for the user against the second identification for the user.
6. The method according to claim 5 wherein the verification computer is a clearinghouse computer.
7. The method according to claim 5 wherein the verification computer is a vendor computer.
8. A method according to claim 5, wherein said step of sending at least one request to a user computer includes:
sending a first request to the user computer for the first fingerprint file; and
sending a second request to the user computer for the first identification for the user.
9. A method according to claim 5, wherein said step of receiving at least one response from the user computer includes:
receiving a first response from the user computer including the fingerprint file; and
receiving a second response from the user computer including the first identification for the user.
10. A method according to claim 9, wherein the second response from the user computer is received prior to first response from the user computer.
11. A method according to claim 5, wherein said steps of comparing the first fingerprint file against a second fingerprint file, and comparing the first identification for the user against a second identification for the user are not performed simultaneously.
12. A method according to claim 7, wherein said step of sending at least one response to the vendor computer, based upon the comparing of the first fingerprint file against the second fingerprint file and upon the comparing of the first identification for the user against the second identification for the user includes sending a confirmation only when both the first fingerprint file and the first identification of the user match the second fingerprint file and the second identification for the user respectively.
13. A method according to claim 8, wherein said step of receiving at least one response from the user computer includes:
receiving a first response from the user computer including the first fingerprint file; and
receiving a second response from the user computer including the first identification for the user.
14. A method according to 13, wherein the second response from the user computer is received prior to first response from the user computer.
15. A method according to claim 5, wherein the first identification for the user includes a password.
16. A method according to claim 5, wherein the first fingerprint file includes information based upon an identification number of a CPU of the user computer.
17. A method according to claim 5, wherein the first fingerprint file includes information based upon a MAC address associated with the user computer.
18. A method according to claim 5, wherein prior to the step of receiving the first request from the verification computer,
storing the second fingerprint file in a first data base accessible by verification computer, and
storing the second identifications for the user in a second database accessible by the verification computer.
19. A method according to claim 7, wherein prior to the step of receiving the first request from the vendor computer,
storing the second fingerprint file in a first data base accessible by a clearinghouse computer, and
storing the second identifications for the user in a second database accessible by a clearinghouse computer.
20. A method according to claim 17, wherein the first database and second database are the same.
21. A method according to claim 7, wherein the step of receiving a request from a vendor computer includes receiving an internet address of the user computer.
22. A method according to claim 21, wherein prior to the step of sending the at least one request to the user computer, identifying the user computer based upon the internet address received from the vendor computer.
23. A clearinghouse computer comprising:
a storage unit for storing information received from a user computer; the information including a second fingerprint file and a second identification for a user;
a memory unit for receiving information indicative of first fingerprint file and a first identification for the user; and
a processor for communicating with the storage unit and the memory unit for comparing information indicative of the second fingerprint file and the second identification for the user with information indicative of the first fingerprint file and first identification for the user, and causing a message to be generated based upon the comparing.
24. A clearinghouse computer according to claim 23, wherein the storage unit includes:
a first storage location for storing the second fingerprint file, and
a second storage location for storing the second identification for the user.
25. A clearinghouse computer according to claim 23, wherein the memory unit includes:
a first memory location for storing, at least temporarily, the first fingerprint file, and
a second memory location for storing, at least temporarily, the first identification for the user.
26. A clearinghouse computer according to claim 23, further including:
an output for receiving the message to be generated based upon the comparison, and
the output further capable of communicating with a vendor computer.
27. A clearinghouse computer according to claim 23, wherein the second identification for the user includes a password.
28. A clearinghouse computer according to claim 23, wherein the second fingerprint file includes information based upon an identification number of a CPU of the user computer.
29. A method for verifying a user and a user computer comprising:
receiving at a first server at least one first message from the user computer, the at least one first message including a first fingerprint file;
comparing the first fingerprint file against a second fingerprint file to verify the user computer, the second fingerprint file accessible by the first server;
receiving at a second server at least one second message from the user computer, the at least one second message including a first identification for the user; and
comparing the first identification for the user against a second identification for the user to verify the user, the second identification for the user accessible by the second server.
30. A method according to claim 29 where at least one server is a mini-server
31. The method according to claim 30 where the first and second servers are mini-servers.
32. A method according to claim 31, wherein the first mini-server is associated with a first clearinghouse computer and the second mini-server is associated with a second clearinghouse computer.
33. A method according to claim 31, wherein the first mini-server is associated with a first clearinghouse computer and the second mini-server is associated also with the clearinghouse computer.
34. A method according to claim 29, wherein:
after the step of comparing the first fingerprint file against the second fingerprint file to verify the user computer, generating a first-mini-server message at the first mini-server based upon the results of said comparison; and
after the step of comparing the first identification for the user against the second identification for the user to verify the user, generating a second-mini-server message at the second mini-server based upon the results of said comparison.
35. A method according to claim 34, further including:
sending the first-mini-server message to a vendor computer; and
sending the second-mini-server message to the vendor computer.
36. A method according to claim 35, further including:
authorizing an action by the vendor computer only if both the first-mini-server message contains information indicating the user computer was verified and the second-mini-server message contains information indicating the user was verified.
37. A vendor computer comprising:
a first input for communicating with a first mini-server for receiving a first-mini-server message containing information indicating if a user computer was verified;
a second input for communicating with a second mini-server for receiving a second-mini-server message containing information indicating if a user was verified;
a processor for receiving the first-mini-server message from the first output and the second mini-server message from the second output and authorizing an action only if both the first-mini-server message contains information indicating the user computer was verified and the second-mini-server message contains information indicating the user was verified.
38. A vendor computer according to claim 37, wherein the first input and the second input are the same.
Description
TECHNOLOGICAL FIELD OF THE INVENTION

[0001] The present invention relates to systems and methods for implementing secure purchases over a computer network. More particularly, the methods relate to a system which permits purchases of merchandise to be made over a computer network, whereby the purchaser may feel confident that personal credit card information is not at risk of being diverted, misappropriated or stolen and the merchant may be more confident that the purchaser is bona fide.

[0002] It is well known for buyers of merchandise to access the global client/server network commonly referred to as the Internet, a part of which is the World Wide Web, for the purpose of searching for and purchasing merchandise from on-line vendors selling wares ranging from travel services and investment services to buying CD recordings, books, software, computer hardware and the like.

[0003] Numerous patents have already been granted which teach methods or systems purporting to secure commercial credit card transactions carried out over the Internet. Examples of such patents include U.S. Pat. No. 5,671,279 to Elgamal, U.S. Pat. No. 5,727,163 to Bezos, U.S. Pat. No. 5,822,737 to Ogram, U.S. Pat. No. 5,899,980 to Wilf et al. and U.S. Pat. No. 5,715,314 and U.S. Pat. No. 5,909,492, both to Payne, et al., the disclosures of which are incorporated by reference herein for providing background and as indicative of the state of the art prior to the invention herein disclosed.

[0004] Most of the disclosed systems have the disadvantage that they rely on the transmission of sensitive information over unsecured network routes and lines for each transaction. Although practically-speaking, the systems which use encryption are fairly safe, there is still some risk of credit card misappropriation and there is little psychological comfort given to potential users by their knowing that encryption is being used.

[0005] Generally speaking, the Internet is a network of computers, remote from one another, linked by a variety of communications lines including telephone lines, cable television lines, satellite link-ups and the like. Internet service providers (hereinafter “ISPs”) provide the link to the main backbone of the Internet for small end users. The account for the end user is established in the normal manner usually by providing credit card information to the ISP by conventional means, such as by voice telephony, fax transmission or check. In most ISP-end user relationships, the ISP has been given credit card or other credit account information, which information is on file with the ISP and available to the ISP's computers. In return for receiving payment, the ISP provides a gateway to the Internet for the end-user's use. The end-user (or subscriber) is provided with identification codes for dialling directly into the ISP's computers and software means (for example, dialler software, browser software, electronic mail software, and the like) for doing so if necessary.

[0006] Most purchases are conducted in the following manner: a purchaser using a browser application on his local client computer connects via his computer's modem to a dial-up Internet Service Provider (hereinafter “ISP”) and makes connections therethrough to various Web sites, Internet server locations assigned a URL (Uniform Resource Locator) address. The purchaser selects his merchandise and the vendor usually requests payment by one of several methods, one of which usually includes payment by providing credit card information.

[0007] According to surveys and other marketing data, there always has been and there still exists a high percentage of the population which is detered from purchasing merchandise directly over the Internet. This large population apparently fears that, despite all the efforts at security and cryptography promised by the vendors, there still exists the possibility that their credit account information will be intercepted on-line by a third party computer hacker and used illegally, at great expense and trouble for the cardholder.

[0008] An additional anxiety-inducing factor related to merchandising over the Internet, or e-commerce, is that the merchant cannot always be certain that just because he has obtained credit card infomation, that he will actually be paid for the merchandise he ships. After all, credit card fraud and/or theft occurs regularly and may not be caught in time to stop the order from being shipped. When the cardholder discovers the theft and stops the card, it may be too late for the vendor to recover his property. At the very least, this situation leads to unnecessary aggravation and wasted resources for the merchant, credit card company and cardholder.

SUMMARY AND OBJECTS OF THE INVENTION

[0009] Thus, it is an objective of the present invention to provide a system and method for potential on-line buyers of merchandise marketed over the Internet to pay for those purchases with minimized exposure to the risk of credit card theft by electronic interception.

[0010] It is a further objective of the invention to provide a mechanism for facilitating e-commerce which will increase the confidence of the consuming public in the safety of such transactions.

[0011] It is still a further objective of the invention to provide a mechanism for facilitating e-commerce which will increase the confidence with which vendors may ship the purchased product or deliver the purchased service without fear of the payment being provided fraudulently.

[0012] It is yet a further object of the present invention to provide a site-specific and computer-specific identification confirmation system for use in a secure electronic purchasing system.

[0013] These objectives and others and others not specifically enumerated herein are achieved by the invention disclosed herein which comprises a system and method for providing payment to an on-line merchant for services or goods provided to an on-line buyer. In one exemplary embodiment, the method takes advantage of the existing business relationships between the member computers which form the structure of the Internet.

[0014] Each time a subscriber signs in to the ISP's computers for an on-line session, the subscriber is assigned an Internet Protocol (hereinafter “IP”) address. The subscriber's computer transmits messages which are received by the ISP computer and relayed through the IP address and out onto the Internet to the ultimate intended recipient computer. During the entire time the on-line session in progress, the IP address does not change and is thus available as identifying information. By monitoring and occasionally re-verifying that the subscriber's computer is still on-line at the assigned IP address, the ISP can confirm that certain activities could be attributed to the subscriber.

[0015] One embodiment of the present invention takes advantage of the intimate relationship which is re-created every time an Internet subscriber's computer goes online and signs into his ISP's computer by assigning to the ISP computer the function of clearinghouse and active intermediary between the subscriber's computer and the vendor's computer. A subscriber computer signs in to the ISP computer system and is recognized and assigned an IP address. When the subscriber identifies merchandise or services at a vendor's website which he wishes to purchase, he sends programming to the website which selects the items and instructs the vendor's computer to generate a purchase authorization request which is sent to the ISP computer. The purchase authorization request contains information about the merchandise to be purchased, identifying information about the proposed purchaser, some of which is the identifying information assigned by the ISP to the subscriber. The ISP confirms internally that the subscriber is still signed in to the ISP computer system by verifying the identity of the computer currently actively communicating through the IP address. When satisfied that the subscriber is still online, the ISP computer generates and sends a message to the subscriber's computer requesting confirmation of the order for the merchandise. Upon receipt from the subscriber's computer of the confirmation, the ISP generates and transmits to the vendor's computer a message confirming the order and providing a confirmation number, agreeing to pay the invoice which the vendor's computer subsequently generates and presents to the ISP computer. ISP computer then uses the subscriber's credit card information and presents an invoice against the credit card account to be sent through normal channels.

[0016] In another exemplary embodiment of the present invention, the ISP does not serve as the credit giver or transaction verifier/guarantor. This function is provided by a bank or vendor with whom the subscriber already has a credit account, and who has an online presence, i.e. has a transaction server connected to the Internet which can participate in the transaction as it is carried out by the subscriber/consumer.

BRIEF DESCRIPTION OF THE DRAWINGS

[0017] For better understanding of the invention, the following drawings are included for consideration in combination with the detailed specification which follows:

[0018]FIG. 1 shows a buyer computer in communication with a vendor computer via the ISP computer, wherein buyer computer is initiating a purchase transaction;

[0019]FIG. 2 shows the vendor computer communicating with the ISP computer to request authorization to complete buyer's requested transaction;

[0020]FIG. 3 shows the ISP computer confirming that correct IP address is active with buyer's computer and requesting confirmation of buyer's transaction;

[0021]FIG. 4 shows buyers computer responding to ISP computer's request for confirmation;

[0022]FIG. 5 shows ISP computer's transmission of a confirmation code and invoicing instructions to vendor's computer;

[0023]FIG. 6 shows a block diagram illustrating another exemplary embodiment of the present invention; and

[0024]FIG. 7 shows a block diagram illustrating another exemplary embodiment of the present invention.

DETAILED DESCRIPTION OF THE EXEMPLARY EMBODIMENTS

[0025] As was mentioned hereinabove, in one exemplary embodiment of the invention, the credit account for the subscriber (also referred to as an end user or Buyer) is established in the normal manner usually by providing credit card information to the ISP by conventional means, such as by voice telephony, fax transmission or check. In most ISP-end user relationships, the ISP has been given credit card information and this information is on file with the ISP and avilable to the ISP's computers. In return for receiving payment, the ISP provides a gateway to the Internet for the end-user's use. The end-user (or subscriber) is provided with software means and identification codes for dialling directly into the ISP's computers. The ISP's computers assign an Internet Protocol (hereinafter “IP”) address to the subscriber for use duiring the particular on-line session in progress. The subscriber's computer transmits messages which are received by the ISP computer and relayed through the IP address and out onto the Internet to the ultimate intended recipient computer. During the entire time the on-line session In progress, the IP address does not change and is thus available as identifying information. By monitoring and occasionally re-verifying that the subscriber's computer is still on-line at the assigned IP address, the ISP can confirm that certain activities could be attributed to the subscriber.

[0026] This exemplary embodiment of the present invention takes advantage of the intimate relationship which is re-created every time an Internet subscriber's computer goes online and signs into his ISP's computer by assigning to the ISP computer the function of clearinghouse and active intermediary between the subscriber's computer and the vendor's computer.

[0027] The method is described with reference to the drawings described hereinabove as follows:

[0028] The ISP (also referred to hereinafter as a “Clearinghouse Computer”) is assigned a unique ISP-ID code.

[0029] As described hereinabove, the ISP's subscriber or customer (hereinafter “Buyer”) has gained the ability to access the Internet network from his remote computer by opening an account with ISP.

[0030] The Buyer has provided credit card or other payment information to the ISP when the account was opened, by conventional mail, fax, voice telephony or any other acceptable method including known methods. In exchange, Buyer receives from the ISP certain software and identification codes which permit Buyer's computer to communicate with the ISP's computers and to negotiate (request and obtain) an IP address.

[0031] At time of first sign-on, Buyer's Computer (hereinafter referred to as “BC”) transmits to BC a Buyer-ID code which is electronically recorded or written into a file (e.g. a cookie file) on BC. The Buyer ID code could be generated by any number of methods known in the art for generating identification codes.

[0032] When Buyer activates his BC to log onto ISP network (BC provides standard log-in infomation to ISP), ISP also reads and logs in Buyer-ID code and assigns IP address for current session to BC.

[0033] BC connects via ISP portal with Merchant Computer (MC) and Buyer selects desired merchandise and further selects to pay using Security program manager payment method disclosed hereinbelow.

[0034] Buyer-ID and BC's IP address assigned for current session are provided to MC programmed to request and receive said information

[0035] MC is programmed to use Buyer-ID and BC's current IP address along with information such as desired Item ID, cost and name for generating an electronic purchase inquiry which is transmitted through the network to ISP.

[0036] ISP is programmed such that upon receipt of purchase inquiry from MC, ISP uses combination of IP address and Buyer-ID to determine within ISP's internal network whether Buyer is in fact still online at the address assigned at the beginning of the online session.

[0037] If ISP computer is unable to confirm that BC is still connected to ISP system at the IP address expected, or that the BC IP address given by MC is different from that assigned by ISP to BC, then a negative message is generated by ISP's computer and transmitted to MC thereby resulting in the early termination of the purchase transaction process by MC. ISP's computer may alternatively be programmed to conduct other tests or inspect for other necessary conditions in an attempt to verify the source of the order placed with MC.

[0038] If BC is determined to be connected to ISP at correct address, ISP sends message containing details of purchase inquiry to BC asking Buyer to input confirmation of details of purchase desired to be transacted with MC.

[0039] Upon input of confirmation command by Buyer into BC, BC generates and transmits a confirmation to ISP.

[0040] On receipt of Buyer's confirmation, ISP then generates and transmits a Transaction Confirmation Number and instructs MC to proceed with filling Buyer's order and also to generate and forward an invoice to ISP.

[0041] The invoice to the ISP can be generated electronically and transmitted directly to ISP's computer, instantaneously (during the same session) or MC might wait until receiving programming indicating that the order has actually been filled.

[0042] Receipt of the invoice by ISP's computer then causes the ISP computer to generate and transmit, either electronically or through conventional means, an instruction to Buyer's credit card company to debit Buyer's account for the amount of the purchase. Alternatively, ISP could bill Buyer directly or any other reimbursement arrangement, e.g. through an insurance fund, is contemplated herein.

[0043] In another exemplary embodiment of the present invention, either the ISP's server acts as the security coordinator or a black box (hereinafter “ISP Toolbox”) is located at the site of the ISP server. The following description will describe the embodiment where the security coordinator functions are carried out by an ISP Toolbox.

[0044] Physical Placement of ISP Toolbox—

[0045] In this exemplary embodiment, the ISP Toolbox is located at the physical site of the ISP, the ISP Toolbox is connected to the phone or communication lines coming into the ISP server directly from users on one side of ISP server. The ISP Toolbox is also connected to lines going out to the Internet (via the modem basket) from the ISP server. The ISP Toolbox does not interact directly with the ISP server. For the most part, it monitors incoming and outgoing traffic, waiting to take over those communications should a security related transaction be called for by a home user.

[0046] The ISP Toolbox is essentially a mini-server, dedicated to the security tasks assigned to it. The ISP Toolbox is provided with programming which, when activated, will send, receive and verify the proper forms and/or data to either a participating home user, ISP server or vendor in order to carry out the proposed transaction. The following scenario describes what can happen when a request for such a security related transaction is detected by the ISP Toolbox.

[0047] As will be further described hereinbelow, in another exemplary embodiment, the Toolbox is not located at the ISP but at the site of another credit provider.

[0048] 1. Application Process—This process only needs to occur once for each acccount which a user might have:

[0049] a) In order to begin participation in the secure transaction system installed by his or her ISP, a User at home connects his home PC with the server of the ISP with whom the home user has established an ISP-user relationship. Upon establishing direct dial-up communications with the ISP server, the home user activates a file on ISP Website, for example by clicking a button presented on his browser using his input device, which alerts the ISP Toolbox to user's request for an application to enroll user's PC in system of the invention.

[0050] b) The ISP Toolbox supplies an apply.asp (“.asp” denotes an active server page) file to the browser application, such as Netscape Company's Navigator® or Communicator® browser applications or Microsoft Corp.'s Internet Explorer® applications. The user fills in the requested information into the form and clicks on a submit button on his display. The apply.asp submits a new application record bearing the user's ISP user name back to the ISP Toolbox which in turn notifies the ISP, for example by way of an e-mail bearing a URL link to the application form, that a request for credit has been made. A credit decision on the application is then made either electronically at the level of the ISP based on predefined or by a human credit manager. The ISP verifies the username and e-mail address of the user and sets a credit limit. The account is marked as “activated” by the setting of an approved credit limit which initiates promotion by the ISP toolbox of the user record from application status to active account status.

[0051] 2) Activation of the account initiates a process by which the ISP toolbox generates a UID or unique identification for the user. The ISP toolbox then generates and transmits an e-mail to the user which contains a link to a registration URL. When the user opens the e-mail and clicks on the registration URL, it downloads and activates an installation page and a system file from the ISP Toolbox, containing a Locator which comprises an <OBJECT> tag, the tag pointing to a GUID (Unique ID generator) and a codebase. The Locator is installed in the user's browser cache and an instance thereof is blown inside the HTML page object module.

[0052] 3) The ISP Toolbox asks user to inspect his/her personal data, to choose a personal password and click an icon or button to finish activation of the new account. Clicking the button causes the onsubmit handler which came as part of the Locator, to start running a script which takes the user information, UID and further information about the user's computer and sends these back to the ISP Toolbox.

[0053] a) Stupid agent—directs user to most recent client software.

[0054] b) Client software—encryption and decryption and retrieving data from wallet kept in registry, i.e.

[0055] 4) Generation of GUID by Black Box

[0056] 5) Describe purchasing session.

[0057] a) Online user goes to Website of merchant using any Web Browser Program and selects merchandise to purchase.

[0058] b) User is offered methods of payment and selects option button for “SECURITY PROGRAM MANAGER” or “SAFE PAY OPTION”.

[0059] c) In an Autofetch process, an OnChange script handler in User's software prepares and sends request to Security program manager server for Session User Identity.

[0060] d) Security program manager server redirects request to user's black-box equipped ISP.

[0061] e) ISP black box searches its files and returns user's identity.

[0062] f) A user form is generated by user's computer and populated with user information including identity returned in step (e) from ISP black box.

[0063] g) The form is submitted, together with a challenge which is forwarded to the vendor server.

[0064] h) Vendor server runs a script that calls the Security program manager server's getGatePass.asp, thereby transmitting the Session User Identity, IP (user's current IP address), Sum and the challenge.

[0065] i) The Security program manager center redirects the vendor server's call to the ISP identified by the IP while the user stands by.

[0066] j) The ISP's getGatePass.asp runs a check of the IP provided as part of the vendor server's call against the internally known IP to make the sure that is where the user really is logged in. If the IP test fails, the vendor server receives a rejection notification from the ISP server and the transaction is terminated.

[0067] k) If the IP test succeeds (i.e. the user really is connected to the correct IP address) then the ISP challenges the home listener.

[0068] The examples discussed herein and demonstrated by the Figures are merely for illustrative purposes only. Variations and modifications of the disclosed invention in a manner well within the skill of the man of average skill in the art are contemplated and are intended to be encompassed within the scope and spirit of the invention as defined by the claims which follow.

[0069] For example, in another exemplary embodiment the ISP is not the site where the Toolbox resides. With reference to FIG. 7, The Toolbox could be physically located at the site of the credit provider (“Creditor”), e.g. online-enabled bank, credit card provider or other affinity-card or charge account provider (including brick-and-mortar retailer's with an online presence such as Macy's) and in communication through normal channels with Creditor's transactional server. In this case, the ISP would not be an active part of the purchase transaction, other than in the usual known way by giving User access to the Internet. Generally, except as specified hereinbelow, the rest of the process proceeds substantially as decribed hereinabove. Specifically, in this exemplary embodiment, the account is set up as follows:

[0070] 1) In order to subscribe to or begin participation in the secure transaction system in which his Creditor also participates, a User at home connects his home PC with the Internet via an ISP. Upon establishing communications with the Creditor server, user activates a getapplication file on Creditor's Website, for example by clicking a button presented by user's browser using his input device, Which alerts the Creditor Toolbox to user's request for an application to enroll user's PC in system of the invention. The system is specific to the user PC which is enrolled as will be further elaborated hereinbelow.

[0071] 2) The Creditor's Toolbox supplies an apply.asp (“.asp” denotes an active server page) file to the browser application. The user fills the requested information into the form; usually this will include a user name (either new or pre-existing), a requested credit line, and an e-mail address which is accessible from the PC, laptop or other client computer from which user wishes to be able to make purchases. The apply.asp also includes diagnostic programming which is activated when user clicks on the submit or sign up button on his display. At that point, the apply.asp “reads” diagnoses whether the user's PC has labelled certain components which can be used for generating a fingerprint file for helping to verify user's PC's identity in future functions. Certain basic information is “read” and is transparently submitted by the apply.asp along with the user-provided information in the form of a new application record bearing the user's IP address back to the Creditor's Toolbox.

[0072] 3) The application is processed by a credit-decision maker. This may be either done automatically by Creditor's server based on pre-definable parameters and access to user's credit particulars and the particulars provided in the application, or by a human credit operator who manually opens the application record by accessing the Toolbox Administration Center Website and selects the option to Accept/reject new applications. Either way, a credit decision on the application is made and a credit limit is set or the application is rejected. If rejected, an e-mail is generated to inform user.

[0073] 4) If the application is accepted, the account is marked as “activated” by the setting of an approved credit limit which initiates promotion by the Creditor Toolbox of the user record from application status to active account status. Activation of the account also initiates a process by which the Creditor Toolbox generates a fingerprint file including a unique identification (“UID”) for the user using the identifying characteristics of user's PC which were diagnosed by the apply.asp and accompanied the application (e.g. CPU ID number, hard disk serial number, amountg of RAM, BIOS version and type, etc.). User is notified via an e-mail sent to the e-mail address specified in the application. The e-mail includes a notification of what credit line has been set and it also includes a hypertext link, e.g. “Please click here to activate your account”. When user clicks on the link which is also a registration URL, it downloads and activates an installation page and system files from the Creditor's Toolbox, including a Locator which comprises an <OBJECT> tag, the tag pointing to a GUID (Unique ID generator) and a codebase (encryption and decryption programs, a handshake code generating program, and a challenge generating program are among the files downloaded for future use by the user PC; these may also be useful for retrieving encrypted data from the wallet kept in user's PC registry). The Locator is installed in the user's PC and an instance thereof is blown inside the HTML page object module. The above step occurs only after the link activates a file which reads the identity numbers of the various components of user's PC to make sure that the user PC is the same one from which the application was generated in Paragraph 2 hereinabove. If in fact it appears to be the same user PC, then the rest of the download takes place.

[0074] 5) The Creditor Toolbox asks user to fill in her selected password again and to fill in her personal data, and click an icon or button to finish activation of the new account. Clicking the button causes the onsubmit handler which came as part of the Locator, to start running a script which takes the user information, UID and further identifying information about the user's computer and sends these back to the Creditor's Toolbox for future reference.

[0075] 6) Another of the items which may have been downloaded into User's computer is a Stupid agent which directs User's computer to the most recent client software available, either from the Creditor Toolbox or from a Security Management Website. This stupid agent is activated at the beginning of any purchase transaction, to ensure that User has the most recent agents to permit the transaction to work, and optionally to provide Creditor Toolbox or the Security Management Website with an opportunity to verify that certain identifying factors of User's system have not changed, as a security spotcheck.

[0076] 7) A participating Merchant agrees to participate in the Safe system of the invention and does so by incorporating source code provided by the Security Program Manager into his “Select Payment Method” Web page. This [i] creates an option for payment using the Safe system of the invention, which when activated by a user, causes Merchant server to take user's IP address and send a request to Creditor Toolbox asking for verification (a) that user having IP address provided is actually online and placing an order having a certain purchase value and (b) that user has a sufficient credit limit to place an order of that value and (optionally) that Creditor has agreed honor a demand for payment of said purchase. The full cycle of a transaction will be described more completely and in greater detail hereinbelow.

[0077] With reference to FIG. 7, it can be seen that a typical purchasing session in this exemplary embodiment proceeds as follows:

[0078] a) User PC goes online and user points his browser to the Website of a Merchant server using any Web Browser Program; downloads files depicting merchandise for sale and selects merchandise to purchase which generates a purchase request to Merchant's server, all in a manner well known in the art.

[0079] b) Merchant's server sends back to user PC an order page or pages which typically includes a transaction number, the value of the order, and asks for billing information, shipping information. At some point, user is offered to indicate her desired method of payment and selects option button which designates the Safe payment plan of the present invention, e.g. “SAFE OPTION”.

[0080] c) Selection of the “Safe Option” generates a message back to Merchant's server which includes user's IP address and instructs Merchant's server to forward a request to Creditor's Toolbox to confirm that the user at the IP address provided is (a) actually and actively online and trying to make this purchase, and (b) that the user at the IP address has the necessary credit to make such a purchase.

[0081] d) Upon receipt of the request from Merchant's server, Toolbox immediately sends a transmission to the IP address provided by Merchant's server. The transmission includes files which (a) search for, decrypt and read the UID files in user's PC to see who it is, (if the PC is a machine registered in the system) and (b) which generate a Pop-up message on the registered user's browser to make sure that the transaction is desired by the Safe system registered user. The message advises that a transaction having a particular value is being requested and asks for confirmation or rejection of the transaction. To reject the transaction, user can actively Reject by pressing a Reject button or simply by not responding within a pre-determined default time. To accept the transaction, the user must provide his user password and submit the form back to the Toolbox. The form is accompanied transparently by the fingerprint file containing the UID and other machine identifying information decrypted and extracted from user's PC by the transmission from the Toolbox.

[0082] e) If accepted by user, then Toolbox checks database to make sure user's credit limit is not exceeded and sends a coded confirmation to Merchant's server that the transaction is confirmed and will be paid for by Creditor on behalf of user. Merchant then sends HTML message to advise user that the identified transaction has been successfully processed.

[0083] f) As described hereinabove, if user either actively Rejects or fails to respond to the Pop-up message in a predetermined time period, for example, 2 minutes, the Pop-up message disappears and Toolbox advises Merchant's server that the transaction is not accepted. Optionally, provision can be made where user can label a tendered transaction as “suspicious” and reject an order with prejudice, thus alerting both Toolbox and Security Program Manager, and therefore Merchant, that some attempt was made to defraud Merchant. Obviously, this knowledge can provide great benefits in aiding to track down cyber credit frauds and inhibit criminal activity.

[0084] In another exemplary embodiment, the Creditor server is also an ISP server, or at least they are at the same location and being serviced by the same modem basket. The Toolbox is still situated at that location as well. Thus, a bank which offers ISP services to it's on-line customers can also offer them the safety of the Safe transaction system and method, which is carried out by the Toolbox right on the bank's/ISP's premises.

Referenced by
Citing PatentFiling datePublication dateApplicantTitle
US6986461 *Jun 30, 2003Jan 17, 2006American Express Travel Related Services Company, Inc.Online enrollment tool
US7438226Aug 24, 2006Oct 21, 2008Digital Envoy, Inc.Fraud risk advisor
US7497374Aug 23, 2005Mar 3, 2009Digital Envoy, Inc.Fraud risk advisor
US7543740Apr 26, 2006Jun 9, 2009Digital Envoy, Inc.Fraud analyst smart cookie
US7673793Aug 24, 2006Mar 9, 2010Digital Envoy, Inc.Fraud analyst smart cookie
US7708200Aug 24, 2006May 4, 2010Digital Envoy, Inc.Fraud risk advisor
US7711748 *Feb 2, 2006May 4, 2010Bright Walter GMethod and apparatus for simplified access to online services
US7797233 *Aug 27, 2004Sep 14, 2010Store Financial Services, LlcMethods and systems for processing, accounting, and administration of stored value cards
US7853533Sep 29, 2005Dec 14, 2010The 41St Parameter, Inc.Method and system for identifying users and detecting fraud by use of the internet
US8151327Mar 30, 2007Apr 3, 2012The 41St Parameter, Inc.Systems and methods for detection of session tampering and fraud prevention
US8213907Jul 1, 2010Jul 3, 2012Uniloc Luxembourg S. A.System and method for secured mobile communication
US8438394Jul 8, 2011May 7, 2013Netauthority, Inc.Device-bound certificate authentication
US8719106Oct 6, 2006May 6, 2014Kemesa Inc.Identity theft and fraud protection system and method
US8726407Oct 13, 2010May 13, 2014Deviceauthority, Inc.Authentication of computing and communications hardware
US20090083397 *Sep 25, 2007Mar 26, 2009Infineon Technologies AgMethod for Loading a Program Module into a Network Device and Network with Network Devices
US20100332400 *Jun 2, 2010Dec 30, 2010Craig Stephen EtchegoyenUse of Fingerprint with an On-Line or Networked Payment Authorization System
DE102004034702A1 *Jul 17, 2004Feb 23, 2006Deutsche Telekom AgElectronic transaction procedure for high value goods and services uses ISP based billing
DE102004034702B4 *Jul 17, 2004Dec 27, 2012Deutsche Telekom AgVerfahren zur technischen Abwicklung von elektronischen Transaktionen über ein paketorientiertes Datennetzwerk
WO2007044596A2 *Oct 6, 2006Apr 19, 2007Steven I BachenheimerIdentity theft and fraud protection system and method
Classifications
U.S. Classification705/76
International ClassificationG06Q20/00
Cooperative ClassificationG06F21/33, G06Q20/12, G06Q20/4014, G06Q20/3821, G06Q20/3674, G06F2221/2115, G06Q20/00, G06Q20/02, G06Q20/382, H04L63/126, G06Q30/06
European ClassificationG06Q20/12, G06Q20/02, G06Q20/4014, G06Q20/3821, G06Q30/06, G06Q20/3674, G06F21/33, H04L63/12B, G06Q20/382, G06Q20/00
Legal Events
DateCodeEventDescription
Jun 1, 2010ASAssignment
Owner name: SAFE3W, INC.,NEW YORK
Effective date: 20040910
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:SANCHO, ENRIQUE DAVID;REEL/FRAME:24464/338
Free format text: MERGER;ASSIGNOR:SAFE3W, INC.;REEL/FRAME:24464/705
Owner name: IPASS INC.,CALIFORNIA
Effective date: 20040915
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:SANCHO, ENRIQUE DAVID;REEL/FRAME:024464/0338
Free format text: MERGER;ASSIGNOR:SAFE3W, INC.;REEL/FRAME:024464/0705
Owner name: SAFE3W, INC., NEW YORK
Owner name: IPASS INC., CALIFORNIA
Jun 7, 2004ASAssignment
Owner name: C&C INTERNET SECURITY, NEW YORK
Owner name: LEMLE, ROBERT S., NEW YORK
Free format text: SECURITY AGREEMENT;ASSIGNOR:SAFE3W, R&D, LTD;REEL/FRAME:015425/0044
Effective date: 20040329