MXPA99008381A - Method and system for secure online transaction processing - Google Patents

Abstract

A method for executing a secure online transaction between a vendor computer (14) and a user computer (12), wherein vendor (14) and user (12) computers are interconnected to a network (16). The method comprises the steps of the user computer (12) transmitting a transaction request message to the vendor computer (14) via the computer network (16), the financial transaction request comprising user identification data unique to the user computer (12);in response to receiving the transaction request, the vendor computer (14) sending a transaction verification request to a trust server computer (18) interconnected to the computer network (16), the transaction verification request comprising the user identification data and data indicative of the requested transaction;in response to receiving the transaction verification request, the trust server computer (18) authenticating the user computer (12) by using the user identification data and communicating with the user computer (12) for verification with the user identification data;and the trust server (18) authorizing the transaction when the authenticating step has passed.

Description

METHOD AND SYSTEM FOR PROCESSING A SECURE ONLINE TRANSACTION TECHNICAL FIELD This invention relates to online electronic commerce, and in particular to a secure methodology for providing an online transaction made over the Internet by authorizing the buyer's identity and credit without transmitting a credit card number or other means of payment as part of the online transaction.

PREVIOUS TECHNIQUE The Internet is constantly expanding at a very fast pace and has become one of the essential means of communication and information today. However, its potential as a facilitator of electronic commerce has not yet been fully developed. This is because current networks are not safe enough to transmit sensitive financial information. Despite the constant development of new methods of encryption or coding, apparently these are not beyond the capacity of a manic calculation. Most users still do not want the opportunity for someone to furtively listen to their credit card number or even postal address when they are imported even with the most secure means of network communication. The biggest problem in today's e-commerce is the lack of user confidence and psychological barriers to using the Internet as a trading tool that arises from these. The systems of the prior art have been developed in an effort to satisfy this need; for example, a system known as Secure Electronic Transaction (SET, Secure Electronic Transaction) has been proposed. With the software enabled for the SET and an account with a financial institution that supports the system, a user can go to a World Wide Web (WWW) website, choose the products that they will buy and then sort them with a few clicks on the mouse . The order is processed, the buyer's identity and account are verified and the transaction is completed. If it is a checking or credit card account, or another payment system such as a DIGICASH or FIRST VIRTUAL, this will be with a financial institution (such as MASTERCARD or VISA) that supports electronic payments, known as the bank. When a user opens the account, the bank receives an electronic file known as a certificate, which acts as a credit card for online purchases. This contains information about the user, which includes a public key, it has an expiration date and has been digitally signed by the Bank to guarantee its validity. At the other extreme, merchants doing business with banks also obtain certificates that include the merchant's public key and the Bank's public key. This certificate is also signed by the Bank to indicate that the merchant is legitimate. The merchant's key will be used to order while the bank key will be used to pay. The user indicates to the merchant which product or service he wishes to acquire through e-mail, by means of a transfer of data from the website or similar. The following series of events are set in motion, which takes a few seconds to complete. First, the user's software receives a copy of the merchant's certificate and verifies that it is dealing with a valid store since the certificate has been signed by the Bank. The user's software sends the merchant three points, all of which have been signed: the order information, which is encrypted by the merchant's public key; the payment information, which is encrypted with the Bank's public key (thus, the merchant can not see the payment information); and a message summary (a code that contains payment and order information) that guarantees that the payment can only be used for this order. After receiving these points, the merchant verifies the user's digital signature. The merchant validates the user's information with a third party (probably, but not necessarily the Bank) to make sure the user is genuine. The merchant then sends the user a message indicating that the order has been received. The merchant also sends a signed message to the Bank using the Bank's public key. This message includes the customer's payment information (which the merchant can not interpret) and the merchant's certificate. The Bank first verifies that the merchant is legitimate, then checks the signature of the newly received message to ensure that the message is legitimate. The Bank then opens the payment information contained in the client and verifies that it is good. The Bank also verifies to make sure that the payment information is for this merchant and the specific order. The Bank signs and encrypts an authorization for the merchant who then sends the products. The SET system has been criticized for several reasons, one of which is the possibility that a key-stealing program that joins the keypad handlers on a user's computer can remain dormant until activated by the presence of a keypad. digital wallet program. This then registers the keystrokes made (before they are encrypted) and sends them to a third party. This ghost program can be disseminated within a modified (but apparently normal) e-commerce software package inadvertently distributed by a financial institution. The SET methodology depends to a large extent on encryption, which is also another potential weakness. Certificates play an important part in the security scheme of the SET. The parameter that provides the mathematical resistance of the certificates to the decryption is the length of the original encryption key. SET certificates will use a key of 1.024 bits long, which is perceived to provide strong enough security. But, as with any scheme based on encryption, a manic calculation can break the code with enough time and computing power. The problem with a total dependence on cryptographic methods is that if they are decrypted, they totally fail. Worst of all, if the de-encryption is done by a third party and is not detected by legitimate users, a false sense of security is created. The strongest security for electronic transactions must have some sort of backup mechanism in place, rather than simply faith in a specific encryption scheme. In another e-commerce scheme of the prior art, the FIRST VIRTUAL system does not depend in any way on cryptography, instead it allows non-sensitive transaction information to travel over the Internet, while the numbers of the credit cards of the users are gathered by phone. In addition, there is a buyer feedback mechanism built on top of existing Internet application protocols including email, FTP, telnet and the World Wide Web. Because these protocols do not carry proof of identity, the FIRST VIRTUAL uses a payment system based on the return of calls by e-mail. When asked to process a financial transaction, it goes to the buyer's account and sends an email asking the buyer to confirm the validity of the transaction. The buyer can respond with "yes", "no", or "fraud". Only when the buyer says "yes" is a financial transaction - which starts. In addition, the dependence of FIRST VIRTUAL on the email and the "VirtualPIN" takes advantage of a careful reading potential of the manic calculations for various reasons. First, email is relatively easy to upset because it uses well-known ports and can be "tricked" or imitated with simple tools and a rudimentary understanding of SMTP (Simple Mail Transfer Protocol, Simple Protocol for the Transfer of Mail). Also, in the case of a slow e-mail gate (such as the one provided by most of the online services available in the store), mailing can take up to a day or more. In addition, the VirtualPIN is static and therefore can be imitated. A different scheme for electronic payments was developed by DIGICASH, based on a digital wallet containing signals. The signals are validated (digitally endorsed) by a Bank, but the Bank can not track the signals for an individual user [sic].

None of the systems of the prior art provide a secure methodology for electronic commerce sufficient to be carried out on a large scale over an unsecured network such as the Internet. The main reasons for the drawbacks of the prior art are the dependence on encryption, as well as the transmission of sensitive financial data over the Internet. Therefore, it is an object of the present invention to provide a secure methodology and system for approving an online transaction carried out over the Internet by authorizing the buyer's identity and credit without transmitting a credit card number as a part of the transaction. of the online transaction.

Another object of the present invention is to provide a system that does not depend on encryption for transmission of data over the Internet, as part of the process of approving the transaction. Another objective of the present invention is to provide this system that uses a third party as a real broker that has pre-registered users (buyers) and sellers, so that the real broker can validate the transaction authorizing the user to use data stored internally that they are not transmitted over the Internet.

DESCRIPTION OF THE INVENTION In accordance with these and other objects, a method is provided for executing a secure online transaction between a vendor's computer and a user's computer, where the vendor's computer and the user's computer are interconnected to a network of computation for data communications between them. The method consists of the steps of: the user's computer transmits a transaction request message to the vendor's computer through the computer network, the transaction request contains unique user identification data for the user's computer; in response to the receipt of the transaction request, the seller's computer sends a transaction verification request to a trust server computer interconnected with the computer network, the transaction verification request contains the user identification data and data that indicate the requested transaction; in response to the receipt of the transaction verification request, the trust server computer authorizes the user's computer to use the user's identification data and communicates with the user's computer for verification with the user's identification data; and the escrow server authorizes the transaction when it has passed the authorization step. In particular, the user's computer executes the transaction request by generating a user authorization number as a first function of a unique user registration number for the user's computer, data of the time correlated with the time of the transaction request , and an internally stored user matrix unique to the user's computer; assigns a port number of the network protocol as a second function of the user's registration number, the time and date data and the calculated user matrix; and transmits a transaction request message to the vendor's computer through the computer network, the transaction request message contains the user's registration number, time and date data, the first indicative data of the transaction requested and the address of the network associated with the user's computer. The transaction verification request sent by the vendor's computer to the real broker contains the user's registration number, time and date data, the second indicative data of the transaction requested and the network address associated with the user's computer. . The trust server computer authorizes the user's computer by calculating the user's matrix using the user registration number received; generates an authorization number of the trust server as a first function of the received user registration number, the data of the received date and time and the calculated user matrix; calculates a protocol port number of the expected network as a second function of the received user registration number, the data of the received date and time and the calculated user matrix. The trust server communicates with the user's computer using the computer network address of the user received from the vendor's computer and the expected number, calculated from the protocol port of the network. The trust server obtains the user's computer the user authorization number; compares the user authorization number obtained with the authorization number of the generated trust server; and this indicates that the user's computer is authentic when the comparison step has been performed or indicates that the user's computer is not authentic when the comparison step fails, or the calculated port number is not available. The first function for generating the user authorization number consists of the step of synthesizing a user matrix as a third function of the calculated user matrix; and the first function for generating an authorization number of the trust server comprises the step of synthesizing a user matrix of the trust server as the third function of the calculated user matrix. In addition, the first function for generating a user authorization number uses the user's registration number and date and time data to extract the authorization number of the user from the synthesized user matrix; and the first function to generate the authorization number of the trust server uses the user's registration number and date and time data to extract the authorization number from the trust server of the user matrix of the synthesized trust server. In this way, as will be apparent, the present invention is a novel online payment method that will solve current e-commerce problems and utilizes the potential of mass electronic commerce of the Internet. The invention is a complete solution consisting of servers and clients that already have an existing trust relationship and therefore only need communication requests, and not financial data to carry out online transactions. The system provides the ability to perform secure electronic commerce over the Internet without communication of sensitive or financial data. There is nothing to encrypt and therefore there is nothing to hack. Even if the online connection is intercepted illegally, the information communicated on the wire is useless since it forms only part of the whole system, and is the product of a calculation, therefore it is dynamic contrary to the static information that can be effectively reused . The user interested in the product or service of a vendor would simply access the Web pages of the seller, which already incorporate grafted transaction request buttons. By doing this, the client software would be automatically downloaded to the user's machine. Once the transaction request button is clicked, a transaction is carried out without typing any credit card number or address. Some seconds pass since the user initiates a transaction until it has been carried out.

Finally, as an integral part of the trust server system, the user-client uses a multimedia interface. The transaction request button appears as an animated and attractive figure. When you click on it, the animation changes accompanied by sound effects. And when the transaction is approved, the animation changes once again accompanied by a sound effect like "cha-_ chang!" A seller needs a website to offer and conduct electronic commerce. To use the transaction authorization system, it is registered with the trusted broker through any preferred means (mail, fax, telephone or Internet). Then, add simple HTML tags to your Web pages, specifying information for each transaction offered. A user who connects to a Web page would need the user-client software module as a browser to view the page. Therefore, if it is not yet installed, it will be automatically downloaded and installed on the machine in a matter of seconds. When a user requests to make his first transaction, he will have to register with the trust server through any means - preferred (mail, fax phone or Internet), and receive his User Registration Number. By entering this number and your chosen PIN in the user-client, a short introductory session is held between the latter and the trusted servants, which will later allow them to be recognized online. After this the first transaction is carried out. Note that the PIN simply serves as a key to access the user-client, and is never sent over the wire. To request a transaction, a user simply has to click on the embedded button and enter their PIN. After this everything is done automatically. The request is sent through the seller to the trusted servants. Upon receipt of the request, the trusted servants authorize the user's machine to use the same algorithm used by the user-client to verify their desire to carry out the transaction. After the user's credit has been deleted and the identity of the user's computer authorized, the transaction is made and the user is shown the status. All this happens in a few seconds. The system accurately tracks all the transactions carried out in a database, sending to the sellers and users daily or monthly reports of the transactions in which they participate.

BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 is a block diagram of a higher level system illustrating the communications of the present invention; Figure 2 is a simplified block diagram showing a single transaction and the data flow between the parties; Figure 2a illustrates a common Web page shown to the user to effect the present invention; Figure 3 is a top-level flow diagram of the method of the present invention; Fig. 4a is a detailed flow diagram of the scanning function of the present invention; Figure 4b is a detailed flow chart of the transaction function of the user of the present invention; Figure 4c is a detailed flow chart of the seller's function of the present invention; Figure 4d is a detailed flow chart of the trust server function of the present invention; Figure 5 is an illustration of the architecture of the software components of the present invention; and Figure 6 is a block diagram of the functionality of the user's computer to carry out the present invention, BEST MODE FOR CARRYING OUT THE INVENTION Figure 1 exemplifies a top-level illustration of the system 10 of the present invention. A plurality of user computers 12, designated USER1, USER 2, ..., USERn, are interconnected to the Internet 16 by any of the different means known in the art such as by a modem connection to a service provider of Internet (ISP), a direct connection to a network that in turn is connected to the Internet, and so on. The Internet 16 is a global network of interrelated computer networks that allows the exchange of information between them. Although the Internet 16 is used in the preferred embodiment, the invention is applicable to any computing network topology where secure transactions between the interconnected computers are desired. Typically, a user computer 12 will be a personal computer in a home or business environment that has Internet access through a commercially available browser-client software package. A plurality of ve computers 14 designated as VE1, VE2, ..., VEn, in the same manner are interconnected to the Internet 16 by any of the various means known in the art. The computer of the ve 14 can, for example, be a suitable server that operates in a dedicated host connected to the Internet. A trust server 18 is also interconnected with the Internet as shown in Figure 1, and acts as a trusted broker for the purpose of authorizing a transaction between any user computer 12 and any ve computer 14, both must first be registered with the trust server 18 as will be described herein. The escrow server 18 is shown with a dotted line connection to a credit institution 20, which is not part of the present invention but which is accessed by the trust server 18 by any means known in the art (e.g. connection by modem) to determine the merit of the credit of a user requesting a transaction from the trust server 18. Each of the user computers, the ve's computers and the trusted broker can communicate with each other by well-known communication protocols in the technique as it applies to the specific network that is going to be implemented. Thus, for Internet connections of the preferred embodiment, the TCP / IP protocol known in the art will be implemented by each party for the transaction as described herein.

Figures 2 and 3 illustrate the flow of data between a user computer 12, a ve computer 1 _ associated with a transaction desired by a user and the trust server computer 18. A user begins the process during a session of exploration in step 1, where you download the pages of the different vendors through an Internet browser such as Netscape, until you see a page that describes an item you wish to purchase. As shown in Figure 2a, the user makes a transaction request by selecting an item to be purchased in step 2 using his mouse or other indicating device associated with the computer 12 to click on an embedded control within the screen page 22 and indicative of the article, for example in the HTML format (hypertext markup language). In Figure 2a the user selects the clock to be acquired by clicking on the associated control 20. The selection of a control enabling the transaction will initiate the internal processing described below, and a transaction request message is transmitted via the Internet to the computer of the selected vendor 14 in the methodology known for Internet protocol. The user's computer 12 then remains in a temporary waiting state pending a subsequent communication from the trust server 18. The computer of the vendor 14, upon receiving the transaction request message from the user's computer 12 sends an image of the transaction request to the trust server 18 through the Internet in step 3. Along with the transaction request image, the vendor's computer 14 sends the IP network address of the requesting user's computer to the trust server 18. which will allow the escrow server 18 to authenticate the identity of the user's computer 12 before authorizing the transaction! The computer of vendor 14 ends with processing for this transaction and thus waits for another transaction request from another user. The escrow server then performs two independent functions at virtually the same time to carry out the approval of the transaction request. One function, as shown in step 4, is to communicate with the credit institution by any means known in the art, for example through a direct connection to a modem to determine the merit of the user's credit for the requested transaction. The escrow server 18 knows the identity of the user and the amount of credit requested to approve the transaction from the data contained within the transaction request. If the credit institution does not approve the request for credit reasons, then the escrow server 18 declines the transaction request and notifies the user accordingly. The seller does not need to be notified in the case of a denied transaction. At this time, in step 5, the escrow server 18 performs internal processing and data communications with the user's computer 12 to authenticate the identity of the user's computer 12 and approve the transaction. The trust server 18 knows the address of the IP of the user's computer 12 from the data transmitted by the computer of the vendor 14. The trust server 18 obtains some data, called the user's authentication number (UMAN), and compares them with a trust server matrix authentication number (TSMAN) that was calculated internally as a function of the user's identity. When the respective numbers of the authentication of the matrix coincide, then the user is considered authentic, and the transaction is approved in step 6. In this way, the triangulation methodology of the present invention for approving a transaction request is evident to from the three-part process illustrated in Figure 2. The user's computer 12 and the vendor's computer 14 are both pre-registered with the trust server 18, which acts as a trusted broker performing trust and trust services. authentication The seller has confidence in the trust server 18 and depends on his user authentication method, since he knows that trust server 18 will only allow transactions requested by registered users. Since the users are previously registered with the trust server, the trust server can request authentication information that would only be known by the user computer 12. It is important to note that, in the present invention, the credit card number is The user's credit or other similar sensitive information is not transmitted between the entities as part of the transaction approval process. Instead, the user registers with the trust server, which will be described in more detail later, through secure communications; that is, by direct telephone connection, by fax, normal mail, etc. Once the trust server registers the user, the user can use the credit card number for credit approval without the user needing to transmit sensitive financial information or other means of electronic payment over the Internet. Another beneficial result of this process is that the vendor's computer 14 is never provided with the user's credit card number or other payment account numbers, thus reducing the vendor's fraud opportunities in the system. The only information that the seller obtains is the article that is going to be acquired, and the identification information of the user (to allow the user to send it). The specific methodology of the preferred embodiment will now be explained with reference to Figures 4A-4D. Step 1, where the user browses on the Internet for a desired transaction, is shown in detail in the flow chart of Figure 4A. The user executes the normal Internet browsing commands using the user's browser client software running it on the user's computer. The Internet browser sends appropriate scan commands to the computer of the selected vendor 14, for example using embedded HTML tags as controls to access the URLs (Uniform Resource Locators) associated with the IP address of the vendor's computer 14. In response , the computer of the seller 14 transmits back to the user browser user embedded web pages to show the user. Once the user has found a desired product or service to purchase, which will be displayed in the HTML format on a seller's website, then the user clicks on the embedded control associated with the selected product. A user client software module is then accessed by the control, which will perform the appropriate functions to execute a transaction request. Figure 4B illustrates the detailed steps that are carried out by the software module of the user client resident on the user's computer 12. If the software module of the user client is not present on the user's computer, that is, if the Once the user has never had access to a transaction request system of the present invention, then the embedded control will automatically download from the approved FTP site the appropriate installation routine, which will proceed to install the user client module in the computer of the user. user. If the user client module has been installed, but the present transaction is first performed by the user, then the client module will ask the user through a dialog box to enter a pre-assigned registration number that uniquely identifies the user. The user can obtain the registration number through a registration process with the trust server 18 through the secure means of communication such as a facsimile or a free telephone call. The user provides an operator associated with the trust server with his name, address, etc., a credit card or other payment mechanism that the user wishes to use for future transactions. The escrow server assigns a unique user registration number to the user, and registers it along with this user information in a local database. Thus, when the trust server receives a transaction request from the seller, it takes the user's registration number supplied by the vendor and searches the database for the user's identification information, including the credit card number It will be used in the transaction. In this way, after the initial secure communications with the trust server, the user does not need to transmit his credit card number or any other data on the Internet as required in the prior art electronic commerce systems. After the user enters the registration number once for the first transaction request, you are also asked to enter the PIN for subsequent transaction sessions. The PIN is used only to access the user client and is not used in Internet communications. When requesting a PIN to be entered in each session, the opportunity for an unauthorized person to unlawfully use the user's computer to execute a transaction (which would then use the user's financial payment scheme or credit card number) is eliminated. . In this way, in subsequent sessions, when the PIN is requested and it is not entered properly, then access to the user client is denied and the transaction request is not made by the system. In addition, in the first transaction request session a user matrix is generated as a function of certain unique hardware identifiers that are found in the system. For example, the user client can have a serial number of the user's hard disk and process it to generate the user's matrix. This is stored locally on the user's hard drive for further processing and authentication with the escrow server. A second variable, the authentication number of the user's matrix (UMAN) is set equal for the user's matrix for the initial transaction request only. When the transaction request is not the first, that is, the user has previously used the system, then the user client module calculates the UMAN as a function of the user's registration number (taken from memory), the matrix of the user. user (taken from memory), and a date and time field that correlates with the real-time clock of the user's computer. The date and time is an additional security feature that is not required, but is preferred since it changes with each transaction request and makes it more difficult to circumvent the system. The function used to generate UMAN can be any robust function generator that takes the three input variables and calculates an output; the function can be a multiplier, a matrix constructor, a displacement register, and so on. The generator of the identical function used to generate UMAN is also stored in the trust server 18, and will be used by the trust server to generate the authentication number of the TSMAN trust server matrix for authentication of the user's computer 12 The user client module also uses the user registration number, the user's matrix and the time and time field to generate a number that is used to assign and open a port number of the PORT protocol by the TCP / IP format . A function generator, similar but not necessarily identical to the function generator is used to calculate UMAN, is used to calculate the PORT. That is, the PORT can be any robust function generator that takes the three input variables and calculates an output; the function can be a multiplier, a matrix constructor, a shift register, and so on. As with the calculation of the UMAN authentication, the identical function generator used to generate PORT is also stored in the trust server 18, and will be used by the trust server to generate the port number of the PORT protocol for communications with the user's computer 12. The user client module also assembles a transaction request message to transmit over the Internet to the vendor's computer 14. The transaction request message is composed of the user's registration number, the field of the time and date and the transaction data indicative of the product chosen for the purchase. The transaction data may be in the form of a SKU, a catalog number or the like, and may optionally describe the price of the product selected for purchase. If the price data is omitted, then the seller's computer 14 must add the price data when it relays the message to the escrow server 18 for approval. The transaction request message is then transmitted via the Internet to the vendor's computer 14 by means of an appropriate protocol, such as by an HTTP request (Hypertext Transfer Protocol). HTTP is well known in the art and is currently a very common way to transmit data packets (IP datagrams) over the Internet. A specific importance for the present invention is the ability of the receiver, in this case the computer of the vendor 14, to extract from the HTTP request header the IP address of the source computer, that is, the user's computer 14. The invention is not limited to be used with HTTP, however, since any transfer protocol that allows the receiver to extract the network address of the sending computer will also be operable. If the transfer protocol used does not provide this information, then the transaction request message must be provided with it during the assembly of the message by means of the user's computer. After transmitting the transaction request message to the computer of the vendor 14, the user's computer 12 is in a pending pending communication state from the trust server 18 through the open protocol port PORT. As shown in Figure 4c, the vendor's computer 14 receives the transaction request message over the Internet and assembles a transaction verification request for transmission to the escrow server. The transaction verification request is primarily an image of the transaction request message and contains the user registration number and the date and time field taken from the transaction request message, as well as transaction data indicative of the selected product for the purchase, in particular its price. If the user's computer 12 provided only a SKU or catalog number, then the seller's computer 14 must first see the price of the product for inclusion in the verification request of the transaction sent to the trust server 18. The transaction verification request also includes the computer network address of the computer of the user requesting 12, that is, the IP address that is obtained from the HTTP request header previously pending the transaction request message. In this way, the information provided to the trust server 18 from the vendor computer 14 is the identity of the user (by means of the user's registration number), the location of the computer network of the user(through the IP address), the price of the product that will be acquired and the time in which the transaction was requested. The trust server 18 will use this information to determine the validity of the user's credit as well as to authenticate his identity. The vendor computer 14 is now out of the loop for purposes of this invention, and waits for subsequent transaction requests from other users. The seller will be informed, by any appropriate means, if the transaction was approved or denied. The trust server 18 receives the request for verification of the transaction from the vendor's computer 14 and proceeds to perform two independent and practically simultaneous processes, as shown in Figure 4d. The escrow server 18 unpacks the verification request and searches for information related to the identity of the user by accessing an internal database with the user's registration number as an indicator. The escrow server uses this identity information along with the unpacked price data of the message and communicates with the credit institution to determine if the user has adequate credit to perform the desired transaction. This can be done by fax, telephone, modem or over the Internet. The credit institution returns a decision; if the process is denied and the user is informed by the communications channel as stated below, if it is accepted, then the trust server continues with the authentication process. Assuming that this is not the first transaction requested by this user, then the escrow server implements the user's registration number as an indicator to its database and searches from it for the user's matrix previously stored for this specific user. Then, the escrow server calculates the authentication number of the trust server matrix (TSMAN) as a function of the user's registration number, the user's matrix (searched from memory) and the received time and date field. . The function used to generate the TSMAN is identical to the function stored in the user's computer 12 and used by the user's computer to generate the UMAN. The user client module also uses the user's registration number, the user's matrix, and the time and date field to calculate the protocol port number of the expected network P0RT_EXP. As with the calculation of the TSMAN authentication, the generator of the identical function used to generate PORT_EXP is also stored in the user's computer 12 and is used in the user's computer to generate the port number of the PORT protocol for communications with the trust server 18. The trust server then initiates a communication over the Internet with the user's computer 12 by sending a data request for the IP address that was received from the vendor's computer 14 and the protocol port number calculated PORT_EXP. The user's computer 12, which was in a waiting state pending receipt of this request, then returns the UMAN value to the trust server through the open PORT. The trust server 18, with the reception of the UMAN, compares the UMAN with the calculated TSMAN for the authentication of the user's computer. If the comparison passes (UMAN = TSMAN), then the transaction is authorized (assuming that the credit check passes) and the user's computer 12 is notified by the existing Internet connection. The credit institution is informed of the transaction, which updates its records accordingly. Finally the seller is notified that the transaction has been approved, so that he can carry out his part of the transaction, for example sending the purchased products to the user. The seller will receive payment for the transaction by any means used in the technique for credit card transactions. If the comparison step fails, then the transaction is declined and the user's computer 12 is notified by the existing Internet connection. The state of the transaction is also stored by the trust server 18 in an internal database for subsequent analysis and processing.

The triangulation methodology of the present invention is advantageously based on trust, wherein the trust server already has knowledge of the identity of the user and seller computers through a prior registration process. Since sensitive information such as credit card numbers can not be communicated during a transaction, the data can pass without being encrypted. The dependence on encryption as in the prior art systems is undesirable, since it is commonly accepted that a stealth user, with enough time, can unlawfully decipher transactions and cheat the system to the detriment of all parties involved. In this system, a stealth user can only capture part of the data necessary to forge the system since the authentication data (UMAN) requested by the trust server will change as a function of the time and date. In essence, the trust server and the user are aware of the identical data patterns that are generated "on the fly" (in real time) according to variables that are known only by each party and stored as a function of the number of user registration. Of course, the patterns of the data can be stored in memory instead of being calculated on the fly for each transaction, but the memory requirements for this mode would be extremely large and expensive. By storing only the array, and using the array to generate the array when required by the generators of identical functions, then the memory storage requirements are greatly reduced. The system finds a useful analogy in a library metaphor. Consider the user's computer and the trust server that have the same library of books, each of which has been written in a personalized way and in this way unknown to the world at large. When the escrow server requests authentication data, it is essentially asking for a certain word from a certain book in the user's library. Since the escrow server has the same library, it knows the word that should be if the request is stamped by the appropriate user. In essence, the user's computer tells the escrow server: "I will provide you with the twelfth word of the fourth paragraph in the sixteenth chapter of the forty-second book in the ninth drawer of the first wall of your library." This describes the appropriate word that is provided by means of the transmission of the user's registration number and the time and date through the transaction request message. The trust server can determine from these variables the word that the user's computer will have to write, and can check them against their own mirror image library. Since the specific word transmitted over the Internet in an unencrypted format will necessarily change from one request to another, even for the same user, then a sneaky user can not fool the system since he has no way to predict the word that will meet the requirement specific since it does not have the same library available. In this way, the capture of a word does not make the user furtive. In the preferred embodiment, the function used to generate UMAN and TSMAN operates to generate an array using the registration number, the array number, and the time and date as input variables. For example, the 16 x 16 matrix can be generated by forming different predetermined combinations of portions of the record number, matrix and date and time, and the specific location would be labeled for the UMAN and TSMAN variables using another predetermined combination of the same variables. Since you change the request time and date on request, UMAN and TSMAN will also change. In an alternative embodiment, the computer of the vendor 14 can be removed from the authentication process, and the user's computer 12 and the trust server 18 communicate with each other directly. In this mode, the user sends a transaction request message directly to the escrow server and the protocol port is opened and used for these communications. Everything else remains practically the same as in the preferred modality.

Claims (12)

1. A method for executing a secure online transaction between a vendor computer and a user computer, with the vendor computer and the user computer interconnected to a computer network for data communications between them, the method comprises the steps of: a) the user computer transmits a transaction request message to the vendor computer through the computer network, the financial transaction request contains unique user identification data for the user computer; b) in response to the receipt of the transaction request, the seller's computer sends a transaction verification request to a trust server computer interconnected with the computer network, the transaction verification request contains identification data of the user and data indicative of the requested transaction; c) in response to receiving the transaction verifying the transaction, the trust server computer authenticates the user computer using user identification data and communicates with the user's computer for verification with the identification data of the user. user; and d) the trust server authorizes the transaction when it has passed the authentication step.

2. A method for executing a secure online transaction between a user computer and a vendor computer, the computer of the vendor and the user's computer being interconnected to a computer network for data communications between them, the user computer it has associated with it a unique network address for this at the time of the request; the method comprises the steps of: a) the user computer executing a transaction request, comprising the steps of: i) generating a user authentication number as a first function of a unique user registration number for the computer of the user; user, time and date data correlated with the moment of the transaction request, and a user matrix stored internally unique to the user's computer; ii) assigning a network protocol port number as a second function of: the user's registration number, date and time data, and the user's matrix; iii; transmitting a transaction request message to the vendor's computer through the computer network, the transaction request message contains: the user's registration number, the date and time data, the first indicative data of the requested transaction, and the network address associated with, the user's computer; b) In response to the receipt of the transaction request message, the seller's computer sends a request for verification of the transaction to a server computer} of trust interconnected with the computer network, the request for verification of the transaction contains: (i) the user's registration number, (ii) data of date and time, (iii) a second indicative data of the transaction requested, and (iv) the address of the network associated with the user's computer; c) in response to the receipt of the transaction verification request from the vendor's computer, the trust server's computer authenticates the user's computer: (i) calculating the user's matrix from an internal memory using the registry number of the user. user received to address the memory, (ii) generate an authentication number of the trust server as a first function of: the received user registration number, data of date and time of reception, and the calculated matrix; (iii) calculating an expected network protocol port number as a second function of: the received user registration number, reception date and time data, and the calculated user matrix, (iv) communicating through the computing network with the user computer using the address., of the computer network of the user computer received from the computer of the vendor and the expected network protocol port number, calculated, (v) obtaining from the user's computer the number of user authentication, (vi) compare the user authentication number obtained with the authentication number of the generated trust server; and v) [sic] indicate that the user computer is authentic when it has passed the comparison step, and indicate that the user computer is not authentic when the comparison step has failed.

The method of claim 2, wherein: the first function for generating a user authentication number comprises the step of synthesizing a user matrix as a third function of the user matrix; and the first function for generating an authentication number of the trust server comprises the step of synthesizing a user matrix of the trust server as the third function of the calculated matrix.

4. The method of claim 3, wherein: the first function for generating a user authentication number uses the user's registration number and the date and time data to extract the user's authentication number from the user's Synthesized user; and the first function to generate an authentication number of the trust server uses the user registration number and the date and time data to extract the authentication number from the trust server from the user matrix of the synthesized trust server .

5. A method for executing a secure online transaction between a user computer and a vendor computer, the computer of the vendor and the user's computer being interconnected to a computer network for data communications between them, the user computer has associated with it a unique network address for it at the time of the request; the method comprises the steps of: i) generating a user authentication number as a first function of: a unique user registration number for the user computer; and an internally stored user matrix unique to the user computer; ii) assigning a network protocol port number as a second function of: the user's registration number, and the user's matrix; iii) transmit a transaction request message to the vendor's computer through the computer network, the transaction request message contains: the user's registration number, the first indicative data of the transaction requested, and the address of the network associated with the user's computer; b) in response to the receipt of the transaction request message, the vendor's computer sends a transaction verification request to a computer of the trust server interconnected to the computer network, the transaction verification request contains: (i) the user registration number, (ii) the second indicative data of the requested transaction, and (iv) the network address associated with the user's computer; c) In response to the request for transaction verification from the vendor's computer, the trust server's computer authenticates the user's computer by: (i) calculating the user's matrix from an internal memory using the registry number of the user received for the address of the memory, (ii) generates an authentication number of the trust server as a first function of: the received user registration number, and the calculated matrix, (iii) calculates a number of protocol ports of network expected as a second function of: the received user registration number, and the calculated user matrix, (iv) communicates with the user computer using the network address of the user computer received from the vendor's computer and the expected network protocol port number, calculated, (v) obtains the user's authentication number from the user's computer, (vi) compares the user authentication number obtained with the authentication number of the generated trust server; and v) [sic] indicates that the user's computer is authentic when it has passed the comparison step, and indicates that the user's computer is not authentic when the comparison step fails.

The method of claim 5, wherein: the first function for generating a user authentication number comprises the step of synthesizing a user user matrix [sic] as a third function of the user matrix; and the first function for generating an authentication number of the trust server comprises the step of: synthesizing a user matrix of the trust server as the third function of the calculated matrix.

7. The method of claim 6, wherein: the first function for generating a user authentication number uses the user registration number to extract the user authentication number from the synthesized user matrix; and the first function to generate an authentication number of the trust server uses the user registration number to extract the authentication number of the trust server from the user matrix of the synthesized trust server,

8. The method of claim 5, wherein the user authentication number generated by the user's computer is also a first function of the time and date data correlated with the time of the transaction request, the transaction request message transmitted by the user computer to the vendor computer also contains date and time data, the transaction verification request sent by the vendor computer to the trust server computer containing date and time data, and the authentication number of the trust server generated by the trust server computer is also a first function of the reception date and time data.

9. The method of claim 5, wherein "the protocol port number of the network allocated by the user's computer is also a second function of the date and time data correlated with the time of the transaction request, the message of The transaction request transmitted by the user's computer to the vendor's computer also contains date and time data, the transaction verification request sent by the vendor's computer to the trust server also contains date and time data, and the number of the transaction. port of the expected network protocol is calculated as a second function of the reception date and time data

10. A method for executing a secure online transaction between a user computer and a vendor computer, with the vendor's computer and the user computer interconnected to a computing network for data communications between them, the user computer has associated with it a unique network address for this at the time of the request; the method comprises the steps of: i) generating a user authentication number as a first function of: a unique user registration number for the user's computer, and date and time data correlated with the time of the transaction request; ii) assigning a network protocol port number as a second function of: the user's registration number, and the date and time data; iii) transmitting a transaction request message to the vendor's computer through the computer network, the transaction request message contains: the user's registration number, the date and time data, the first indicative data of the requested transaction, and the network address associated with the user's computer; b) In response to the transaction request message, the seller's computer sends a transaction verification request to a trust server computer interconnected to the computer network, the transaction verification request contains: (i) the user registration number, (ii) date and time data, (iii) the second indicative data of the requested transaction, and (iv) the network address associated with the user's computer; c) in response to the receipt of the transaction verification request from the vendor's computer, the trust server computer authenticates the user's computer by: (i) generating an authentication number of the trust server as a first function of : the registration number of the user received, and the date and time of reception; (iii) [sic] calculating an expected network protocol port number as a second function of: the received user's registration number, and- the reception date and time data, (iv) communicating with the user's computer using the network address of the user computer received from the vendor's computer and the protocol port number of the expected, calculated network, (v) obtaining the user's authentication number from the user's computer, (vi) comparing the number of authentication of the user obtained with the authentication number of the trust server generated; and v) indicating that the user's computer is authentic when it has passed the comparison step, and indicating that the user's computer is not authentic when the comparison step fails. The method of claim 10, wherein the user authentication number generated by the user computer is also a first function of an internally stored user matrix unique to the user's computer, the trust server computer searching for the memory of the user's matrix using the user registration number received as the memory address, and the authentication number of the trust server generated by the trust server computer is also a first function of the calculated user matrix. The method of claim 10, wherein the port number of the network protocol assigned by the user computer is also a second function of an internally stored user matrix unique to the user's computer, the server computer of the user. Escrow searches the memory of the user's matrix using the user registration number received as the memory address, and the protocol port number of the expected network is calculated by the trust server computer as well as a second function of the calculated user matrix.