Internet commerce, or e-commerce as it is otherwise known, relates to the buying and selling of products and/or services between consumers and merchants over the Internet or other like transactional exchanges of information. The convenience and availability of shopping over the Internet has sparked considerable interest in e-commerce on behalf of both consumers and merchants. This increased interest in e-commerce has, in turn, sparked an increase in network traffic and an increase in the number of requests e-commerce services must address. To handle this increase in requests, e-commerce services generally route requests for a service between a plurality of redundant servers. This reduces the response times for requests and/or the load of any single server. As should be appreciated, this has the added advantage of providing redundancy in the event of server failure, whereby an e-commerce service may employ a plurality of redundant servers irrespective of the number of requests. Such redundant servers may, for example, be located at geographically disparate locations, so as to protect against localized failures. Unfortunately, heretofore, the routing of requests between the plurality of servers has been, in a sense, “dumb.”
Namely, traditional routing systems for routing requests between a plurality of redundant servers generally route requests to redundant servers and forget about them; they have no ability to re-route a request should the server a request was routed to prove to be non-performant. For example, if a request is assigned to a non-performant server, notwithstanding that the server appears to be performant, the request will eventually fail by way of timeout or simply be addressed by the non-performant server in a suboptimal amount of time. Accordingly, it would be advantageous to have a routing system that monitors whether requests have been processed and re-routes the requests after certain non-performance criteria have been met.
Additionally, some traditional routing systems may include an internal ranking of redundant servers based largely upon a historic bias, whereby the rankings may be slow to change. For example, consider a ranking on the basis of the average response time of 1000 response time measurements. Adding another measurement is going to affect the average response time in a minimalistic way. However, server failure issues may arise unexpectedly, whereby internal rankings according to the foregoing ranking scheme would be slow to adapt. Similarly, if servers are ranked with a historic bias according to some performance criteria, such as response time, and the most highly ranked server has a strong historic bias of performance, internal rankings according to the foregoing ranking scheme would be less likely to try another server that may have higher performance than the most highly ranked server at the present time. Accordingly, it would be advantageous to have a routing system that periodically re-ranks servers in a random order, so as to reset any historic bias that may have accrued.
What's more, other traditional routing systems generally fail to look at the substance of responses to requests. Namely, other routing systems are generally content to look at response times. However, such approaches fail to account for server failures in which the server is not entirely non-performant. For example, consider a web server in which an internal database server from which it depends crashed. If routing web requests to the web server, the response time of the server may be excellent; however, the server may be returning error messages that lack substance responsive to, a request. Accordingly, it would be advantageous to have a routing system that is able to examine responses from redundant servers to determine whether the redundant servers are operating properly and returning proper responses.
Moreover, other traditional routing systems generally fail to take into account the dependencies between redundant servers and other servers, and only monitor the redundant servers. However, each redundant server may include at least one server from which it depends. Naturally, if there is failure of any of the at least one server from which a redundant server depends, the redundant server will fail, whereby a request to the redundant server will fail. Consider, for example, a performant directory server dependent upon a nonperformant authentication server. Traditional routing systems may determine the directory server is sufficiently performant to route requests to, notwithstanding that it is returning bad responses or not returning responses at all. Accordingly, it would be advantageous to have a routing system that not only monitors the redundant servers, but also examines the servers from which the redundant servers depend.
Notwithstanding performance issues, traditional routing systems generally lack means to detect whether the reason for non-performance of a redundant server is due to fraud or simply system failure. However, this poses a problem given that increased interest in e-commerce has led to more and more stories emerge regarding identity theft and cyber crime, which has, in turn, led to a deterioration of consumer confidence in the security of their personal information. Naturally, a reduction in consumer confidence leads to fewer e-commerce transaction because the willingness of consumers to purchase goods and/or services electronically is inversely proportional to the apprehension they may have about the safety of their personal information. Accordingly, it would be advantageous to have a routing system that includes means to detect whether the reason for non-performance of a server is due to fraud or simply system failure.
Supplemental to the foregoing, one area in which an intelligent server router finds particular application is for certain authentication initiatives, such as Visa's Verified by Visa (VbV) initiative. Therein, directory servers are employed in connection with processing transaction authentication requests. Naturally, if a directory server fails, transactions cannot be completed, whereby merchants, banks, credit card companies, etc. lose out on revenue. Accordingly, it is common for a plurality of directory servers to be available to a requestor, whereby it is generally desirable to select the directory server providing the optimal response time and/or performance.
FIG. 1 illustrates one such exemplary authentication initiative. As shown in this example, a consumer/cardholder 10, e.g., employing a suitable web browser or the like, is making an on-line purchase, e.g., over the Internet, from a merchant 20. As is known in the art, the illustrated back-end payment processing chain includes an optional payment gateway 30, the merchant's financial institution or acquiring bank 32, the credit card network 34 and the issuing bank 36.
At a point of checkout, the consumer 10 selects an appropriate payment method based on the initiatives supported by the merchant 20. At this point, the consumer fills out the on-line checkout form including a payment option, card number, expiration date, etc. Based on the payment information, the merchant 20, via a plug-in 22 installed on their server, passes a verify enrollment request (VEReq) message to a directory 38 on a server, e.g., suitably operated by the credit card network 34. The directory 38 includes a database associating participating merchants with their acquiring banks and a database associating card number ranges with locations or addresses, e.g., universal resource locator (URL) addresses, of issuing banks' authentication servers, e.g., the authentication server 40 for issuing bank 36. The VEReq message is a request to verify the enrollment of the card in the authentication program, and it contains the card number provided by the consumer 10.
Based on the card number range stored within the directory, the VEReq message will be sent to the appropriate URL address for the server 40 which returns to the merchant 20 via the directory 38 a response thereto, i.e., a verify enrollment response (VERes). That is to say, the server 40 will verify the enrollment status of the card and respond with a VERes message to the directory 38 which is then passed back to the merchant's plug-in component 22.
Based on the VERes message (i.e., if positive), the merchant plug-in component 22 will redirect the cardholder's browser to the server 40 by passing it a payer authentication request (PAReq) message generated by the merchant's plug-in component 22. The consumer 10 then completes an authentication process directly with the server 40. The authentication server 40 authenticates the consumer/cardholder 10 and responds to the merchant 20 with a payer authentication response (PARes) message including a digital signature. The merchant's plug-in component 22 validates the digital signature of the PARes and extracts the authentication status and other specified data that is to be used by the merchant 20 during the payment authorization process carried out via the back-end payment processing chain. For example, the merchant 20 sends an authorization/sale transaction to their payment gateway 30 along with the data elements received from the PARes. The payment gateway 30 routes the data to the acquiring bank 32 based on the acquirer's specification. The acquiring bank 32 then sends the data via the appropriate credit card network 34 to the issuing bank 36 for settlement.
The present invention contemplates a new and improved system and/or method which overcomes the above-referenced problems and others.
USPTO Backgrounds
USPTO Backgrounds