Contemporary communications networks, particularly the worldwide packet data communications network known as the “Internet,” give consumers an unprecedented ability to purchase products and services from a myriad of locations around the world. Consumers can use the Internet to visit “electronic stores” to obtain information about products and services and make purchases. In response to the proliferation of electronic stores on the Internet, web sites known as “shopping applications” or “portals” have been developed to provide a single point of access to a large number of electronic stores, making comparison shopping much easier. Shopping applications and portals typically allow a customer to enter a search request and be presented with a list of electronic stores that offer the requested product or service. The customer can select a particular store and be automatically connected to the store's website.
FIG. 1 is block diagram 100 that depicts example web pages viewed by a customer when purchasing a product or service over the Internet using a conventional shopping application. As used herein, the terms “web page” and “page” are use analogously to refer generally to an electronic document that can be displayed using a web browser.
A customer begins by using a web browser to access a product search page 102 of a shopping application (not illustrated). The customer may either enter the Uniform Resource Locator (URL) of product search page 102 directly into the web browser or “navigate” to product search page 102 by “following”, i.e., selecting, a link from another web page.
Product search page 102 includes a search terms object 104 that the customer uses to enter terms that describe the desired product or service. The customer then initiates a search by selecting a search button object 106. This causes the search terms to be sent to the shopping application for processing.
Once the shopping application has processed the search terms specified by the customer, search results are displayed to the customer on a shopping results page 108. Shopping results pages generally identify merchants that offer the product or service specified by the search terms and sometimes include other information such as price. In the present example, shopping results page 108 includes product information for two merchants. Objects 110 and 112 include descriptions of first and second products offered by first and second merchants, respectively. Objects 114 and 116 identify the names of the first and second merchants, respectively. Objects 118 and 120 provide price information for the first and second products offered by the first and second merchants, respectively.
After reviewing shopping results page 108, the customer may take several actions. For example, customer may “return” to product search page 102 by selecting a return button object 122. As used herein, the term “return” refers to re-displaying a previously displayed web page. In the present example, return button object 122 includes the URL of product search page 102. Thus, selecting return button object 122 causes product search page 102 to be retrieved and re-displayed on the customer's browser. Note that product search page 102 may be retrieved either from the server where the shopping application resides or from the client where the customer's web browser is executing.
The customer initiates a purchase of the first product listed on shopping results page 108 by selecting a buy button object 124 associated with the first product offered by the first merchant. Similarly, the customer initiates a purchase of the second product from the second merchant by clicking on a buy button object 126. Other objects displayed on shopping results page 108, such as objects 110 and 112, may also allow a customer to initiate a product purchase.
Initiating a product purchase causes merchant product page 128 to be retrieved and displayed on the customer's browser. Merchant product page 128 is typically provided by the merchant's web site, not by the shopping application that provides product search page 102 and shopping results page 108.
In the present example, merchant product page 128 includes a product picture object 130 and a product information object 132 that provide information about the particular product offered by the merchant. To purchase a product, the customer selects an “add product to shopping cart button” object 134, which selects the particular product for purchase. The customer then selects a checkout button object 136 to complete the transaction, which conventionally requires that the customer enter address and billing information. Merchant product page 128 may also contain other links (not illustrated) to information about the merchant, such as shipping options or policies relating to purchases and returns.
One problem with conventional approaches for processing orders over the Internet, such as just described, is the difficulty or inability for customers to return easily to a shopping application after having been transferred from the application to a merchant web site. The ability of a web site to remain the target of the user's input once the user has visited the site is referred to as “stickiness,” so the problem of losing a user in the transition from the shopping results page to the merchant product page is referred to as a lack of “stickiness.”
Ordinarily, a customer uses the “back” button on their browser to reload previous web pages until the desired shopping application web page is loaded. This may require that a customer select the back button many times, depending upon how many web pages were viewed to get to the merchant web page. Furthermore, customers cannot use the back button to return to the shopping application web page when so-called redirect URLs are used to cause a web browser to load a different web page than the requested web page. In these situations, the “chain” of links used to access the merchant web page is “broken” and selecting the back button will not return the customer to the shopping application. Hence, customers may be unable to return to a shopping application from a merchant site, or may only be capable of doing so via the repeated use of a web browser's back button. Either of these situations can deter customers from returning to a merchant web site.
Another problem with conventional approaches for processing orders over the Internet relates to the payment of commissions to shopping applications and portals. It is now common for shopping applications and portals to be compensated for directing or “driving” customers to particular merchants. This necessitates tracking the origination of transactions to particular shopping applications or portals, which can be difficult. The nature of the hyperlink structure of the World Wide Web is such that once a customer traverses from a first web page to a second web page, the provider of the first web page may no longer be in contact with the customer and not know the “location” of the customer. For example, in the context of a customer who uses a shopping application to access a merchant, once the customer leaves the shopping application and arrives at the merchant web site, the customer may navigate through various merchant web pages exploring the products offered for sale. Once the user is at the merchant's web site, the shopping application does not know what, if anything, the customer buys at the merchant web site. In this situation, the shopping application does not know whether it is entitled to a commission for directing the customer to that particular merchant.
One solution to this problem is for merchants to track how customers reached their web site by adding to their web sites the ability to track and record how each customer navigated to their web site. Although this approach allows merchants to definitively track the origination of transactions, there are two significant drawbacks. First, this solution requires that merchants customize their web sites, which is costly and time consuming for the merchants. Second, this solution requires that shopping application providers trust that merchants will properly account for the origination of transactions.
Another solution to this problem involves the use of what are known as “tracer images.” This generally involves merchants providing to all interested shopping applications data that uniquely identifies particular transactions and then relying upon shopping applications to claim origination of certain transactions. FIG. 2 is a block diagram 200 that illustrates example web pages and a conventional approach for using tracer images to track transactions.
A customer uses a web browser (not illustrated) to navigate to a merchant product page 202, typically by following a link from a shopping application or portal. The customer then navigates to a merchant order page 204 to make a purchase from the merchant associated with merchant product page 202. At merchant order page 204, the customer specifies the products that are desired along with other information required to complete the order, such as customer identification, customer and shipping addresses and payment information. After placing the order, the merchant web site generates an order confirmation page 206 that summarizes the order. The merchant web site may also record information about the purchase transaction to be used later to confirm commission charges from the shopping application.
Order confirmation page 206 includes a tracer image 208 that identifies attributes of the completed transaction. Tracer images may be implemented in several ways. For example, tracer images may be represented by a single dot or pixel so that customers do not notice them. They are embedded on the Hyper-Text Markup Language (HTML) order confirmation page on a merchant site as an image (IMG) tag, where the source (SRC) attribute of the image consists of the URL of an order confirmation tracking server hosted by the shopping application. This tracking URL also includes attributes about the transaction that was just completed by the customer. Example attributes include, without limitation, a merchant identification number, an order identification number, a total amount of merchandise purchased or currency denomination.
Order confirmation page 206 is sent to the customer's browser for display. The customer's web browser interprets image links contained in an order confirmation page 206 to retrieve and display the appropriate image. For tracer image 208, the information associated with tracer image 208 is requested from the location indicated in the SRC attribute (i.e., the specified third party) and provided to the web browser. The information about the transaction is sent to the third party from the browser when the browser requests tracer image 208 from the third party. The third party may be a shopping application provider or another company that provides a commission tracking service.
Tracer images may be used to send transaction information to all shopping applications for all transactions. This approach leaves to shopping applications the determination of where transactions originated, which is undesirable to many merchants since they must trust the shopping applications to correctly assign commissions. Alternatively, tracer images may be sent to shopping applications on a transaction-by-transaction basis. This approaches leaves the tracking of commissions in the hands of merchants, which is undesirable to many shopping applications since they must trust the merchants to correctly assign commissions. In either situation, a considerable burden is placed on merchants to implement tracer image technology into their web site infrastructure, which is costly and time consuming.
Yet another problem with conventional approaches for processing orders over the Internet relates to completing order forms required by merchants to process a transaction. Customers are typically required to complete an order form to complete transactions. Order forms provide merchants with various types of information, such as shipping and billing information. This same information is often needed, and must be separately provided, for every online purchase that a customer makes.
One solution is for merchants to maintain this information for their customers so that returning customers only have to confirm or change the information. Another solution is for the information to be maintained by a third party and used by merchants to complete transactions. Even if a third party service is used, the customer will have to access that information for each merchant from whom the customer makes a purchase. Therefore, a customer may have to spend considerable time providing or accessing the same basic information over and over for each purchase even if they are not from different merchants.
Based on the foregoing, an approach for processing orders over the Internet that does not suffer from limitations of prior approaches is highly desirable.
There is a particular need for an approach for processing orders over the Internet that provides stickiness by allowing customers to easily and reliably return to a shopping application from a merchant web site.
There is a further need for an approach for processing orders over the Internet that allows a shopping application to collect commissions without requiring merchants to modify their web sites.
There is a further need for an approach for processing orders over the Internet that allows a merchant to determine how customers traversed to their web sites and that allow a shopping application to collect detailed information about transactions between customers and merchants.
There is yet a further need for an approach for processing orders over the Internet that eliminates the need for a customer to repeatedly enter the same information for different transactions or to repeatedly access such stored information.
USPTO Backgrounds
USPTO Backgrounds