METHOD AND APPARATUS FOR REAL-TIME ELECTRONIC
MARKETING
FIELD OF THE INVENTION The present invention relates generally to hardware and software tools that aid in using the Internet. More particularly, the present invention relates to automatic electronic marketing on the Internet. BACKGROUND OF THE INVENTION
As more and more products, services and information become available in the Internet, it becomes increasingly challenging for an Internet user to quickly find World Wide Web ("web" ) sites offering the most appropriate products, services or information. Search engines and catalog systems are available, but require time to use and often give unsatisfactory results. Both catalog systems and search engines receive a word or phrase input by the user and return pages for the user to view. Pages returned may not contain any useful or relevant information. For these reasons, search engines and catalog systems are often ineffective in aiding a user in finding truly helpful web sites.
Various tools have been developed to assist Internet users. For example, there are various Internet shopping tools. The usefulness of these tools is limited, however, for a variety of reasons. One disadvantage of existing shopping tools is that users must modify their shopping behavior by interrupting their web browsing to interact with the shopping tool. The user is also required to input accurate information that will enable the shopping tool to extract what the user requires. Another shortcoming of current shopping tools is related to the quantity and correctness of price comparison data. A single price comparison query may return one hundred or more price records. For various reasons, many of these price records are incorrect or outdated. The user must then manually filter through data to find the best price. Even then, there is no guarantee that the price is current. SUMMARY OF THE DISCLOSURE
A method and apparatus for real-time electronic marketing is described. In one embodiment, software queries a database in real-time for "offers" that the user may be interested in based upon what the user is viewing and previously collected information about the user. Dynamically generated offers are presented to the user in real-time, for example at the point of sale in an Internet buying transaction. In one embodiment, dynamic offers are calculated using predetermined formulas, or rule sets, applicable to a particular merchant. A rule set may include a normal price, a discount price or discount range, to what kind of consumer the discount should be given, and under what circumstances the discount should be given. Circumstance may include details about the consumers buying history, for example, or which merchant the consumer is about to buy from. An offer may be an offer for a better price on the same item at a different merchant. An offer may also be a complimentary product offer, for example, an offer to buy compact discs (CDs) when a user is about to buy a CD player. When the user accepts an offer, fulfillment of the offer is automatically facilitated. Facilitation may include: automatically transferring items from a shopping cart currently viewed to a different shopping cart on another web site; automatically transferring items from a shopping cart currently viewed to a different shopping cart on an intermediate web site from which the user may complete the transaction with a third website; and allowing the user to click through to a different web site. For example, the user may be automatically transferred to another web site to complete a transaction with a different merchant. An offer from a non-Internet merchant may also be made. An offer may be made when a user is viewing a site that is not a merchandising site. For example, a user perusing a web site that includes content about new automobiles may be offered an incentive to test drive a car at a local dealership. The user may be further presented with the option of scheduling an appointment in real-time on the Internet. Embodiments include software resident on a user's computer, or on any other Internet access device, that performs functions in collaboration with a remote server including searching for, presenting, storing and managing offers. A user interface includes a user-customizable alert user interface that functions as a web browser and enables the user to view and manage offers.
BRIEF DESCRIPTION OF THE DRAWINGS
Figure 1 is a block diagram of one embodiment of an electronic marketing system.
Figure 2 is an illustration of a user's computer display showing a task bar and an embodiment of an alert user interface.
Figure 2 A is an illustration of one embodiment of an offer window of an alert user interface. Figure 2B is an illustration of one embodiment of an offer window of an alert user interface..
Figure 3 is an illustration of a product page as it appears on a computer display.
Figure 4 is an illustration of a shopping cart page as it appears on a computer display.
Figure 5 is an illustration of a checkout page to which a user has been transferred by the alert software.
Figure 6A is a flow diagram showing the operation of one embodiment.
Figure 6B is a continuation of the flow diagram of Figure 6 A. Figure 6C is a continuation of the flow diagram of Figures 6 A and 6B.
Figure 7 is a flow diagram showing more detail of an element of the process illustrated in Figure 6B.
Figure 8A is a flow diagram showing a process of buyer aggregation.
Figure 8B is a continuation of the flow diagram of Figure 8 A. DETAILED DESCRIPTION
Embodiments of the present invention as described herein automatically provide useful and accurate assistance in finding "offers" and presenting them to Internet users. Dynamically generated offers are presented to the users in real-time, for example at the point of sale in an Internet buying transaction. An offer may be an offer for a better price on the same item at a different merchant. An offer may also be a complimentary product offer such as an offer to buy compact discs (CDs) when a user is about to buy a CD player. An offer from a non-Internet merchant may also be made. An offer may be made when a user is viewing a site that is not a merchandising site. One embodiment comprises an alert software module resident on a user's computer which operates in the background while the user browses the Internet. In some circumstances, when offers are found that may be of interest to the user, the shopping process may be interrupted to present the better offer to the user. In other circumstances, the user may view any available offers at the user's discretion. In one embodiment, an icon visible to the user indicates at all times whether or not offers are available, and the user may click on the icon to view the offers.
When an offer is accepted, fulfillment of the offer is automatically facilitated. For example, the user may be automatically transferred to a different web page. In one example, the different web page is a web page of another merchant. For example, the user may be transferred from a first merchant's checkout page to a checkout page of a second merchant with a better offer. Items that the user was planning to buy on the first merchant's site appear on the checkout page of the second merchant. In other circumstances the different web page is an intermediate checkout page on a web site of a provider of software and services as described herein such as, for example, the alert client software.
In one embodiment, dynamic pricing may be available to the user. Dynamic pricing allows the user to benefit from better prices that are specially negotiated with partner merchants and calculated in real-time. Partner merchants are merchants who integrate their software and/or services with those of the provider of the alert client software. In one embodiment, partner merchants may choose to dynamically price their products in response to user behavior in order to win customers from a particular competing merchant or group of merchants.
Figure 1 is a block diagram of system 100 which is one embodiment of an electronic marketing system. In general, the system 100 includes hardware and software components which may be physically located in different places. For example, the user's machine 114 includes hardware and software that may be located in an individual user's house while all of the other elements shown are located remotely (in the same or different places) from user's machine 114. The user's machine may be any device from which the user may access the Internet, including a mobile device. User's machine 114 includes a web browser 102 and an alert client software 104. Web browser 102 may be any commonly available software for browsing the web. Alert client software 104, in one embodiment, is software that interacts with the web browser 104 and performs operations to provide the user with relevant offers based upon content of web sites being viewed, as explained more fully below. The embodiments of the method and apparatus described herein are most often in reference to e- commerce web sites and merchandising. The references are examples, and the embodiments described are equally applicable to any type of web site or web site content. Offers are described herein most often as with reference to buying products. Offers are equally applicable to situations in which an Internet user is automatically notified by the offer of, for example, informational content that was determined to be of interest to the user based upon a web site the user is viewing. The use of offers may be completely independent of merchandising. Alert application server 108 communicates with alert client software 104 and assists in locating and presenting offers through the alert client software 104 or through web browser 102. Merchant web server 116 is the server for an exemplary web site operated by a merchant who sells products over the web. The application server 108 facilitates the presentation of offers through the alert client software 104 or through the web browser 102.
In one embodiment, offer engine 110 comprises an expert system that uses sets of rules to calculate dynamic offers and present them to a user based upon the user's on-line behavior. The alert client software sends information from the user's currently viewed page to the offer engine 1 10 and the offer engine uses the information to query the database 112. If one or more merchant rule sets pertaining to the information are found, the offer engine uses the rule set(s) to calculate one or more dynamic offers. Offer engine 110, in one embodiment, uses a particular set of rules for a particular merchant that wishes to compete for buyers of a particular product or products. These rules may instruct the deal engine to discount an item by a fixed dollar amount, to offer better shipping terms, or any other alteration of a previous offer that would be considered an improvement of the previous offer. As an example, a merchant may provide a rule set that includes a normal price for an item, a discount price or discount percentage range, to what kind of consumer the discount should be given, and under what circumstances the discount should be given. Circumstances may include details about the consumers buying history, for example, or which merchant the consumer is about to buy from. Dynamic offer that are calculated in real-time using a rule set supplied by a merchant are one type of offer among many types. Another type of offer is a complimentary offer, which is an offer for a type of item that is related to the item the user is currently viewing. For example, a link to a maker of patio furniture may be presented to a buyer of an outdoor spa. The buyer may also be presented with a specific offer to buy from a patio furniture merchant. Another type of offer is a "business model" offer in which the user is presented with content and/or a link to another web site at which they may obtain assistance in getting deals. Typically, the web site is a destination web site such as priceline.com or mercata.com. Another type of offer is an "apples to oranges" offer in which the user is presented with a similar product to the one currently viewed along with comparison information. For example, a user viewing a "Brand A" printer may be presented with a "Brand B" printer along with detailed comparison information regarding the two products. Another type of offer is a service-oriented offer that presents the user with the same or a similar item from a different merchant who offers superior service, such as product delivery or after sale service.
The database 112 stores a variety of information including user attributes. The user attributes "user identification" and "operational preferences" are stored for each user. The user email address is the default user ID and user password is a mandatory element of user identification. User address is an optional element of user identification. User name is an optional element of user identification. An element of operation preferences is an indication of whether to collect statistics. This indicates whether the alert client software 104 may collect the user web navigation statistics and use them in aggregate form. In some embodiments, other information such as age, sex, income range, etc., may be requested on an optional basis.
User identification attributes are used to identify the user and set user attributes in a purchase. The alert client software 104 asks for the user ID and password, then sends this ID (and a password) to the application server 108 during transactions. The alert client software 104 may be asked to save the ID and the password. If the ID and password are saved, the alert client software 104 does not ask the user for ID every time it starts. Operational preferences are another type of user attribute. Operational preferences determine how the alert client software 104 behaves when the user is browsing the Internet and during transactions. Two operational preference type user attributes are price threshold and weightage for merchant attributes. Price threshold represents an amount of money the user wishes to be able to save before being notified by alert client software 104. Price threshold can be specified as a percentage value, an absolute dollar amount, or both. The server considers an item from a partner merchant only if the aggregate savings (considering item cost + tax + shipping) crosses this threshold. In one embodiment, the default price threshold is fifty cents. Weightage for merchant attributes may be chosen by a user. Weightage indicates what factors are important to a user in a comparison of products between merchants. For example, weightage is assigned to price, availability, return costs, and after sale service.
The database 112 also includes a list of covered sites. This is the list of the web sites that are monitored. The list is maintained by an administrator who may periodically update the list and store it on the database 112. The alert client software 104 downloads the list of covered sites from the application server 108 when alert client software 104 initially starts. Thereafter, alert client software 104 periodically contacts the application server 108 and downloads any updates.
In one embodiment, the covered site list is divided into blocks. Each of the blocks has an update date. When the alert client software 104 contacts the application server 108, it informs the application server 108 of the time of last update. If the application server 108 has a block updated later than that, it sends that block to the alert client software 104.
An entry in the list of covered sites contains the uniform resource locator ("URL") of the covered merchant web page. The alert client software 104 monitors the URL of the site or sites the user is navigating, and checks these against the list of covered sites.
Covered site information is also stored in the database 112, and defines how the alert client software 104 handles a covered site. The information is maintained by a system administrator and stored on the database 112. When the alert client software 104 detects a covered site the first time, it contacts the application server 108 and downloads the information for that site. The alert client software 104 also saves the information in a local cache. Thereafter, when the alert client software 104 detects a covered site, it contacts the application server 108, and the application server 108 sends the information only if it has been updated in the database 112. Covered site information includes covered merchant profiles, product page templates, and shopping cart templates.
Covered merchant profiles include a merchant name, merchant shipping policies, and merchant return policies.
Product page templates inform the alert client software 104 how to parse the product information within a product page. For example, product page templates inform the alert client software 104 how to extract the product ID, name, description, category, price, shipping costs, etc. Product page templates also inform the alert client software 104 how to detect a one-click buy and how to detect when an item is added to a shopping cart.
Shopping cart templates inform the alert client software 104 how to parse a shopping cart and extract the item information including product ID, name, description, price, shipping costs, quantity, etc. A shopping cart template also informs the alert software 104 how to detect a checkout action.
The database 112 also stores a master item list. The master item list contains the descriptions of covered items or topics. By querying this database, the application server 108 will be able to extract information about an item, such as: a normalized item ID from the merchant specific item ID; the item ID from its description; the item category and subcategory from the item ID; the related items from the same or different subcategory; one or more partner merchants that sell that product or service; and whether any partner merchant has any special offers on the item. Depending upon the number of covered merchants, the number of partner merchants, and the number of products covered merchants and partner merchants offer, the list of all the covered items may be unmanageably large. Also, offered items may change frequently. If the list of covered items becomes difficult to manage, it is an alternative to only cover a manageable number of highly popular items.
In those cases in which a product ID is unique to a particular merchant, the merchant specific ID must be converted to a "normalized" ID. This is accomplished in one embodiment by a table that maps the ID for each covered merchant and partner merchant to a normalized ID.
The database 112 also stores a partner merchant list. This list contains the information about partner merchants. The information includes: merchant name; merchant shipping policies; merchant return policies; merchant ratings; and other content. The merchant policies are stored in a normalized form to facilitate more accurate price and policy comparisons
In the cases of a user viewing a product page, a shopping cart page, or shopping on an e-commerce web site, the template is used to parse pages of the covered merchant web site as the pages are viewed by the user. The template assists the alert client software 104 in determining if the page viewed is a product page or a shopping cart page and in extracting information such as product IDs of the products displayed on the page, quantities indicated on the page, and prices for the products on the page. The information is sent to the offer engine 110 through application server 108, which uses the information to look for offers on the products using an expert system and information in the database 112 that is related to various covered sites offering products. Offers are continuously looked for in the background as the user shops. If the user is viewing a product page with a single item, the single item is identified and an offer is looked for on the single item. If multiple items are on the page (a product page or a checkout page) all of the items are identified and offers are looked for on each of the items. If the multiple items are on a checkout page, offers are looked for on each item individually and also on the items as a group. An offer may be a lower price on the item, lower shipping charges, or a more favorable buying term in any aspect.
Alert client software 104, in one embodiment, is a Win32-based piece of software. This software is installed on the user's machine 114. Alert client software 104 may be downloaded from a supplier's web site after the user registers with the web site. The alert client software 104 may also be sent via email from one person to another. Alert client software 104 consists of several objects. These objects communicate with each other using events. The objects may handle certain events. The objects subscribe to these events. The objects may also generate events for other objects to handle. Alert client software 104, in one embodiment, is downloaded to the user machine 114 as an executable binary. The alert client software 104 also detects when an update is available for the alert client software 104 from application server 108. At this time, an installer object is informed, and the installer object terminates the alert client software 104. The installer then downloads updated components and reinstalls the alert client software 104. The installer object in one embodiment is a Win32 executable.
A controller object is an object that is started when the alert client software 104 is started. The controller object is responsible to start and shutdown the other alert client software 104 objects.
A post office object is an object that provides subscription and delivery facilities. The objects in alert client software 104 can notify the post office object to subscribe certain event messages. In case an interesting event takes place, these objects send the event message to the post office. The post office is then responsible to deliver the event message to the subscriber objects. When sending an event message, the alert client software 104 objects can also optionally specify a destination object or objects.
A configurator graphical user interface (GUI) object allows the user to configure several client preferences. Several client preferences are stored locally on the user machine 114. In one embodiment, client preferences involve the attributes that define the functionality of the alert client software 104. A preference involves choosing whether or not alert client software 104 generates a sound to notify the user that a better offer has been found while the user is browsing a product page.
A client cache object stores the client preferences as well as a merchant list, a merchant profile, offers, and other cacheable objects. In one embodiment, the objects are stored in encrypted files on a hard disk. In another embodiment, the objects are stored in a windows registry.
A server interface object is the interface to the application server 108. When the server interface receives an event message from the post office, it translates that into an application server message, then forwards the message to the application server 108. When the server interface receives a message from the application server 108, it translates this message into an event message, and forwards it to the post office for delivery. The server interface spawns multiple threads to concurrently process multiple messages.
A browser interface object is a layer that sits between the web browser 102 and the alert client software 104. There is an instance of this object for each web browser instance. This object provides a uniform interface to all types of browsers. The browser interface is attached to an instance of the site manager object and works closely with it.
A site manager object is responsible for handling web site data. It accepts URL data as well as web page hypertext markup language ("HTML") data. It attempts to detect triggers and parse HTML data to extract information helpful in getting an offer. In one embodiment, the information includes the original merchant name and/or ID, items the user is browsing, the prices of these items, etc. In one embodiment, a trigger includes the user clicking on a 'checkout' button on an e-commerce site. The site manager uses templates associated with the sites to detect triggers and parse HTML data.
Figure 2 is an illustration of an alert user interface 201 presented by the alert client software 104. Computer display 200 includes a task bar that shows program activation buttons 216 and status icons 220. As will be further described, the alert user interface 201 appears on the computer display 220 under a variety of circumstances. In one embodiment, the alert user interface 201 is a web browser. Alert icon 222 appears in different modes, each of which indicate a state of the installed alert client software 104. For example, if the alert icon 222 is grayed out, the alert client software is inactive. If the alert icon 222 is colored, the alert client software is active. When the alert icon 222 spins, the alert client software is actively seeking offers. When an offer is found, the icon 222 blinks. Other modes are possible in different embodiments to inform the user about the actions of the software 104 without interrupting the user actions. When the alert client software 104 is active, clicking the alert icon in any of its modes causes the alert user interface 201 to appear.
Alert user interface 201 includes a selection buttons on the left side that allow the user to customize the operation of alert client software 104. When one of the selection buttons on the left of the user interface 201 is clicked, the central display area displays information pertinent to the selection. In Figure 2, the "offers" button has been clicked and an offer manager is visible in the central display area. The top tool bar includes selection buttons pertinent to the selection chosen from the selection buttons on the left side. The top selection buttons "open", "delete", add to tools", and "send to a friend" indicate actions the user may take in the offer manager.
The offer manager as shown in Figure 2 appears when the alert icon 222 is clicked by the user. The offer manager displays any current offers that the user may accept or decline. The offer manager lists the offers, where each offer is from, details about the offer, and when the offer expires. To view the offer, the user selects the offer and clicks the open button. The user may further delete a selected offer by clicking the delete button, or send it to a friend by clicking the send to a friend button. Clicking the send to a friend button displays any friend or groups of friends already stored by the user using the friends window. The friends window is accessed by clicking the friends button on the left side of the alert user interface 201.
Figure 2A illustrates an offer window 203 as it appears when the offer from "Buy.com, Kozmo.com", as shown in Figure 2, is highlighted and the opened. The offer window 203 includes top buttons that allow a user to view offer details, merchant ratings, and product reviews. In Figure 2 A, the offer details button has been clicked in the offer window 203. The offer window 203 lets the user view prices from each of the offerors, prices delivery times, bonus offered and a shorthand merchant rating. The offer window 203 also includes an accept button. When an accept button corresponding to an offer is clicked, the alert client software 104 facilitates fulfillment of the offer in one of a variety of ways, as further described below.
Figure 2B illustrates the offer window 205 displayed when the "Toyota of Dallas" offer is highlighted and opened from the offer manager of Figure 2. The details of the Toyota offer are displayed in Figure 2B. The Toyota offer is an example of an offer from a non-Internet merchant. The user is offered an incentive to go to a car dealership and test drive a car. In one embodiment, clicking on the accept button at the bottom of the offer window 205 will connect the user automatically via telephone to the merchant so that an appointment can be made. Alternatively, clicking the accept button allows the user to schedule a test drive via the Internet.
Clicking the merchant ratings button, in one embodiment, connects the user to the web site of a merchant rating service. In another embodiment, the merchant rating information is obtained from the database 112. When the tools button is clicked, user contact information, credit card information and password and ID information may be entered or changed. User information is stored on the database 112 with the exception of user credit card information, which is encrypted and stored on the user machine 114. When settings button is clicked, current settings are displayed. The settings may be entered or changed. The settings include, for example, a minimum dollar amount of savings threshold for notification of an offer, preferred shipping methods, and preferred offer notification method or methods. Offer notification methods include an audible sound and a blinking alert icon 222. When the friends button is clicked, a dialog box including a prompt for a friend email address appears. An offer may be forwarded to a friend or a circle of friends. Multiple friends' names and email addresses may be stored and referenced through the dialog box. The stored friends information may be used to compose distribution lists for easy dissemination of offers. Figures 3-6 illustrate screen displays as seen by a user during shopping according to one embodiment of the invention. Figure 3 is an example of a web product page of the kind typically encountered by a user while browsing. The page includes a description of a product with a price and an "add to cart" button to click in order to add the product to the user's shopping cart.
According to one embodiment, when the user enters an e-commerce site with a product page as shown in Figure 3, and locates a product such as a book to purchase, the alert client software 104 analyzes the product web page and identifies particular information such as product ID and product price. The alert client software 104 operates simultaneously on multiple instances of web browsers if more than one browser is operating on the user machine 114. After identifying this information, alert client software 104 transfers the information to the offer engine 110 to determine whether a better offer is available. When the user is viewing a product page, the icon 222 spins to indicate that the alert client software 104 is searching for offers. The alert client software 104 may look for offers when the user is viewing many other kinds of web pages that include various kinds of content. Whenever the alert software 104 is attempting to locate an offer, the icon 222 spins. Whenever an offer is found, the icon 222 blinks, so that the user is made aware that an offer has been found. The user may click on the icon 222 at any time to view offers, as previously explained. In some circumstances, the user does not need to click on the icon 222 to view offers. For example, the offer window 202 may automatically appear over the currently viewed page when a user clicks on a "checkout" or "add to cart button". An offer is then made to the user at the point of purchase, as explained below.
The user may decide to purchase the book shown in Figure 3 by clicking on the "add to cart" button. When the add to cart button is clicked, the shopping cart contents page of Figure 4 appears. When the user adds the book to their shopping cart, the alert client software 104 identifies the quantity information. In this case, the user wishes to purchase one copy of Thriving in the New Millennium. The user may then choose to proceed to check out by clicking the " checkout" button. When the checkout button is clicked, an offer window as shown in
Figure 2A automatically appears. In one embodiment, if one or more offers are available on any item, clicking the checkout button causes an offer manager as in Figure 2 to appear automatically. In this case, the offer is for a discount given by merchant 2 on the same item offered by merchant 1. The offer window shows the total savings for the offer and the total savings to date for the user. The user may decline or accept the offer by clicking the appropriate button. Before deciding to accept the offer, thereby deciding to change merchants, the user may view a third party rating of the merchant by clicking on the merchant rating button. The third party rating indicates how well the merchant has performed in areas such as timely delivery.
When the user clicks the "accept" button, the user is transferred to the web site of merchant 2. Figure 5 shows a checkout page on merchant 2's web site, including a personalized user greeting. In this case, the alert client software 104 has automatically placed the item in a shopping cart at the merchant 2 web site and created a customer account for the user. The user's information has also been used to automatically fill in payment information from the user information stored on the user machine 114. In one embodiment, in order for the user to be transferred to merchant 2's checkout page, merchant 2 must be a partner merchant. A partner merchant is a merchant who has integrated the necessary software with the alert client software 104 in order to facilitate the "transfer" from any merchant 1 to merchant 2. In order to place the contents of the merchant 1 shopping cart in the shopping cart of merchant 2, the user is transparently logged onto the merchant 2 site. In one embodiment, alert client software 104 requests a look up of a user ID and password for merchant 2 from application server 108. If such a user ID and password exist, they are used to log onto the web site of merchant 2. If a user ID and password for merchant 2 do not exist in the database 112, a new unique user ID and password for merchant 2 are created, used to log onto the web site, and stored for later use. The creation of the user ID and password occur transparently to the user. When the transaction is complete, the alert client software 104 securely transmits a transaction record in the background for tracking purposes to the merchant web server 116. In cases in which merchant 2 is not a partner with integrated software, the contents of the shopping cart appear on an intermediate web site hosted by web server 106 to which the user is transferred. The intermediate web site includes an intermediate checkout page on which the user can complete the acceptance of the offer, such as completing a buying transaction. As in the partner merchant case, alert client software 104 requests a look up of a user ID and password for merchant 2 from application server 108. If such a user ID and password exist, they are used to log onto the web site of merchant 2. If a user ID and password for merchant 2 do not exist in the database 112, a new unique user ID and password for merchant two are created, used to log onto the web site, and stored for later use. The creation of the user ID and password occur transparently to the user, as does a logon to the merchant 2 web site to submit information required to complete the transaction for the user. In some embodiments, to further facilitate a purchase, alert client software 104 provides electronic wallet functionality that allows easy access to user information such as passwords, credit card numbers, and shipping addresses. In some embodiments, alert client software 104 integrates with other existing electronic wallet products. Figures 6A, 6B and 6C are a flow diagram that shows an embodiment of a process executed by the hardware and software of Figure 1 (shown on the right side of the figures) in response to the actions of a user (shown on the left side of the figures). When the user downloads and installs alert client software 104, alert client software 104 automatically installs itself at 602. The user is then prompted for profile information at 604. At the end of the install 602, the user is prompted to fill out a short form (for example, an HTML form in the browser containing personal information such as name and address). Credit card information is also recorded in some embodiments. The profile information is stored locally in user's machine 114. This provides additional security, but in other embodiments the profile information may be stored on database 112. The profile information is encrypted in one embodiment.
In some embodiments, more detailed user profiles may be captured for the purpose of allowing partner merchants to create highly targeted offers in order acquire customers. Profile information may include age, geographic location, etc. Users may be offered incentives in exchange for more detailed personal information or for allowing their shopping behavior to be tracked. User behavior information is extremely valuable to merchants. The user may prompted to refer friends at 606 by providing friends' email addresses. In one embodiment, the alert client software 104 provides a list of names from the user's email address book and contact list.
In one embodiment, alert client software 104 performs interactions with the user to facilitate viral marketing. For example, viral marketing via an email based referral program allows a new user to refer friends, family, and co- workers. Messages are sent to each person referred via email and include an implied endorsement, and a URL link to download alert client software 104. In return for providing referrals, the providers of alert client software 104 credits users some percentage of transaction fees generated by each referred person. The credit may be applied to future purchases, for example, or redeemed for air miles.
When the user launches a web browser, alert client software 104 detects the browser launch and retrieves a list of covered or monitored sites at 608. The list of covered sites is retrieved from application server 108 along with any updates to the list. This site list may be a subset of a master merchant table in database 112 stored, for example, as merchant domain and merchant ID (some assigned number).
As the user browses the internet, alert client software 104 begins monitoring the user's navigation at 612 and compares the domain navigated to the covered site list at 614. As sites are navigated, the alert client software 104 determines whether a current site is a covered site or not at 616. If the site is not a covered site, no action is taken as shown at 618. If the site is a covered site, alert client software 104 requests and receives a configuration template specific to the site from database 112 at 620. Alert client software 104 parses key information using the template at 622.
Communication between alert client software 104 and application server 108 may be through a variety of protocols in different embodiments. For example, communication between alert client software 104 and application server 108 occurs through a hypertext transport protocol (HTTP) port in on embodiment.
The configuration template includes information indicating how to determine when a user is looking at a product page, how to parse key information from the HTML and URL (e.g., product name, product identification (ID), price, and availability). The configuration template also includes information indicating how to tell when a user adds an item to the shopping cart, how to identify and parse the shopping cart page, how to manage the shopping cart, how to tell when a user clicks to buy (including one-click ordering), and shipping and tax rules for the merchant. Extensible markup language (XML) is used for the templates in one embodiment.
Because some e-commerce sites offer "buy" buttons on pages other than product pages, it is necessary to identify products on these pages. Therefore, one embodiment identifies page types through Boolean rules. For example, IF the URL contains the word "open product" AND the HTML contains the word "our price" AND the HTML page contains a product ID THEN the page is a PRODUCT PAGE.
Some of the key information may be contained in graphic images as graphics interchange format ("GIF"). In this case, alert client software 104 sends the images, or references to the images, to application server 108 for optical character recognition (OCR) processing.
Once a product is identified at 624, a request is sent to application server 108 at 626, containing a merchant ID, a product ID, and a price. It may be necessary for application server 108 to normalize the product ID if the merchant uses a proprietary ID/stock-keeping unit (ID/SKU) system. If offers are available, application server 108 selects the best offers and responds with one or more offers at 630.
Referring to Figure 7, the process of retrieval of offers 630 is explained in greater detail. First, a negotiation level is determined at 702. Database 112 accommodates categorization and sub-categorization of products so that offers can be negotiated at a granular level (for example, a category called books may have a subcategory called New York Times bestsellers). Partner merchants have the option, as shown at 704, to provide price lists for products or to configure an "offer". If a partner merchant chooses not to configure an offer, the price lists for the partner merchant are looked up at 710. If the partner merchant wishes to configure an offer, two types of calculated offers that may be accommodated are discount by fixed percentage as shown at 706, or discount by a fixed dollar amount at 708. Many other offer types 720 may be made. Offers may be specific to a category, subcategory, merchant, single product or a combination of these criteria. Offers are configured by the partner merchant. For example, a merchant may choose to discount every product that is offered by a specific competing merchant by a certain percentage. Also, alert application server 108 may consider price comparison based on a fixed percentage and price comparison based on a fixed dollar amount and choose the lowest price option.
Referring again to Figures 6B and 6C, alert application server 108 retrieves user preference data at 632. User preferences are considered when preparing comparison data. For example, a user may want their savings to exceed a threshold (in dollars or percentage of total purchase price) before alert client software 104 interrupts the user's actions. Alternatively, a user may choose vendors in various categories from which they are willing to consider offers. Alert application server 108 performs the comparison and responds to alert client software 104 at 634. Alert application server 108 stores a record of the compared item in database 112 at 636. Alert application server 108 further sends one or more offers back to the alert client software 104.
Alert client software 104 determines whether an offer has been found at 638. If no offer has been found, no action is taken at 640. If an offer is found, the alert icon 222 enters an alert mode, for example blinking. The offer window of Figure 2A is displayed at 642 under a variety of circumstances. For example, the offer window may pop up on the user computer display when the user clicks on an the icon 222, when the user clicks on a "checkout" button, or when the user clicks on a "one-click" buy button.
The currently displayed item is added to a "file shopping cart" in a local database of the user's machine 114 at 644. It is verified that the user shopping cart contents match the file shopping cart contents at 646, and the file shopping cart contents are updated if necessary. The user is queried at 656 by the alert offer window whether the user wants to accept any offer. When user clicks the "accept" button, products in the user's current shopping cart are placed in a shopping cart at a different web site at 658. For example, as previously explained, the web site may be a partner merchant web site or an intermediate web site. The user is also transferred to a shopping cart page on the different web site at 660. The contents of the user's shopping cart are placed in a shopping cart of a different web site in the background. This can be achieved in several ways, for example, it may be achieved through URLs for merchants that use a URL structure, allowing users to add items to a shopping cart by providing a SKU as a parameter in the URL. This may also be accomplished by submitting HTML forms in the background to add items to shopping carts. In some embodiments, partner merchants provide special functionality to facilitate the efficient placement of multiple items in a shopping cart at the partner merchant site. Additional information such as user name, location, etc. may be passed to partner merchants to allow partner merchants to present a customized shopping cart. The additional information also enables merchants to present information targeted at the specific customer, even though the customer may not have viewed the merchant site before. The partner merchant shopping cart page may thus be customized for a user of alert client software 104 to inform them about the merchant partner's site and the advantages of shopping with the partner merchant.
User accounts must be created with partner merchants if the user does not already have an account with the partner merchant. This process is facilitated when the partner merchant allows encrypted information to be sent to the partner merchant's server in the background so that the partner merchant can create an account immediately. Alternatively, HTML forms may be submitted in the background. Another alternative embodiment integrates the operations of alert client software 104 with an existing electronic wallet system. A record of the transaction is stored at 662 so that traffic through the application server 108 may be measured and owners of application server 108 may collect revenue.
If the user declines the offer of the alert offer window and clicks on a "decline" button the alert offer window is hidden at 664 and a record of that transaction is stored at 666. The transaction records allow users' reactions to be gauged and allows refinement of the shopping process.
In one embodiment, the method and apparatus of the present invention aids on-line shoppers by providing the option of buyer aggregation to negotiate special offers with partner merchants. This process is illustrated in the flow diagram of Figures 8 A and 8B. As the user browses a product page, product information is extracted from the page and sent to application server 108 at 802. When the user modifies a shopping cart, for example by adding an item, the application server 108 determines whether buyer aggregation is possible at 804. Conditions under which aggregation is possible are predetermined, for example by partner merchants in combination with user preference information. If it is determined that aggregation is possible, application server 108 sends that information to alert client software 104 at 806. Alert client software 104 stores that information at 808. The user is then queried whether the user wishes to join a buyer group at 810. The user may be queried by a pop-up window. If the user clicks on a "join group" button, that information is sent to application server 108 at 812. Application server 108 then stores the information and updates user group information at 814. If a predetermined number of users has joined the group, application server 108 proceeds to purchase the item from the partner merchant at 816. A pop-up window is then displayed to inform the user of the purchase at 818. Buyer aggregation allows partner merchants and buyers to benefit. Partner merchants are able to sell items in quantity and buyers are able to realize lower prices by aggregating. Buyer aggregation also makes it impossible for merchants to practice discriminatory pricing based on a user's demographic data.
In other embodiments, variations on the process described above are implemented. For example, the user may have the opportunity to click on the alert icon 222 when the user is not within a merchant's web site. When certain products appear on other pages, such as a news page, an offer on the product may be offered. Other variations provide the user with additional information when the user presses an offer button. For example the user may be offered reviews of the merchant or ratings by other users of alert client software 104. The user may also be offered statistics, such as the number of purchases by users of alert client software 104. Users may also be offered complimentary item suggestions.
Alert application server 108 includes administrative functions to be used by a system administrator. These include reporting capabilities and partner merchant update capabilities. For example, an administrator may request the database 112 to provide a report spanning a predetermined amount of time and including information on: total number of active users, total number of partner merchants, total number of items successfully transferred to partner merchant, total number of offers declined, and more detailed information on prices, types of items, etc. In one embodiment, there is an administrative GUI used by an administrator to maintain merchant profiles, update templates, and generate reports.
The present invention has been described with reference to particular embodiments. One of ordinary skill in the art, however, could make modifications to the embodiments described herein without departing from the spirit and scope of the invention as defined in the following claims.