AU2021206165A1 - Systems, methods, and computer programs for providing users maximum benefit in electronic commerce - Google Patents

Abstract

The present technology generally relates to a system, method, and computer program for facilitating e-commerce transactions. For example, during a shopping experience, several products or service inputs, such as: electronic coupon codes, sales taxes, cashback rebates, customer loyalty programs, etc. are calculated and compared against numerous competitor retailer stores to ascertain the lowest price. From a product landing page, a checkout modal window may be presented to the user as an overlay of the product landing page. Upon selection of a checkout element in the checkout modal window, the purchase process may be completed without additional user interaction or without displaying a checkout page of the website.

Description

SYSTEMS, METHODS, AND COMPUTER PROGRAMS FOR PROVIDING USERS MAXIMUM BENEFIT IN ELECTRONIC COMMERCE

CLAIM OF PRIORITY

This application is being filed on January 5, 2021, as a PCT International Patent Application and claims the benefit of U.S. Provisional Patent Application Serial No. 62/957,576 filed on January 6, 2020, the entirety of which is incorporated herein by reference.

INTRODUCTION

The present technology generally relates to systems, methods, and computer programs for providing the maximum user benefit to a user in electronic commerce. Specifically, multiple price factors are used to compare products and services of various e- commerce merchants in order to automatically alert the user to the best possible price during electronic checkout. Various examples of the present technology also provide the user-less tracking of an affiliate purchase in order to apportion user cash back without first requiring the creation of a shopping experience. Further examples are directed to various optimizations of a software embodiment designed to enhance the user experience.

DESCRIPTION OF THE RELATED ART Electronic commerce (“e-commerce”) generally utilizes the internet to conduct retail transactions, or “e-commerce transactions.” As such, it has adopted a number of features that are analogous to brick-and-mortar institutions, such as shopping carts. To this end, most e-commerce websites utilize electronic coupon codes, strings of letters and/or digits which must be input by a consumer, to provide customers with discounts, as opposed to physical coupons. These electronic coupon codes may be issued to the public at large, either via marketing or advertising, or may be issued to individual consumers, or groups of consumers, for various purposes. Either way, the electronic coupon code must be known before it can be utilized during checkout of an e-commerce transaction. Several attempts have heretofore been made to aggregate known electronic coupon codes for the public benefit, usually as listings on websites dedicated to such a purpose. This solution has not been ideal as it requires consumers to first seek out applicable electronic coupon codes, and then manually test each one to determine whether it is still viable. Additionally, most e-commerce websites do not provide the user with information regarding competitor’s goods or services. If the user would like to compare product or service information between various merchants (e.g., price) he/she would have to visit each website or open each native application, which takes time and utilizes additional computing resources, including processing cycles, network bandwidth, display resources, and memory resources. In addition, it would take even more time to calculate the lowest “net” price (i.e., base price +/- taxes, shipping costs, electronic coupon code savings, cashback savings, etc.) of each product or service. As such, there is a need in the art for an automated solution that conserves time and computing resources. The present technology addresses such a need, among other things, and provides several additional benefits to consumers in order to facilitate e-commerce transactions.

SUMMARY

The present technology is generally directed to providing the maximum benefit, such as automatic detection and application of coupons, cash back, and price comparison across multiple vendors, to a user in electronic commerce and accompanying systems, methods, and computer programs thereof. Examples of the present technology facilitate the provision of a maximum benefit in electronic commerce (“e-commerce”) settings, such as retail websites and downloadable applications. More specifically, products and/or services of various e-commerce merchants may be automatically compared in order to alert the user to his/her maximum benefit, such as lowest price. In order to compare a product or service of various e-commerce merchants and find the lowest price, multiple inputs may be included, such as but not limited to, availability, price, taxes, fees, electronic coupon codes, rebates or cash back, etc. Accordingly, the user may save money on the purchase of any conceivable e-commerce product or service, including activities, tours, hotel rooms, car rentals, etc. This can be done on exact matches of a product or service, or on a similarity match for the product or service, as described in greater detail below.

As such, at least one example may comprise a browser “plug-in,” or background service, whether in a desktop, mobile, or wearable electronic operating system, which may be implemented for tracking the current website or application the user is viewing and automatically populating at least one electronic coupon or coupon code, as well as providing the user with a lower priced option, as described in greater detail below. For example, in a browser plug-in embodiment, a Uniform Resource Locator (URL) or Uniform Resource Identifier (URI) may be tracked, and upon a change or a user’s visit to a recognized store, at least one input, such as a coupon code, may be sent by the browser plug-in to an application server communicating with the plug-in.

For purposes of clarity and without limiting the scope of the present technology, examples of the present technology may be described as being implemented with a web browser (e.g., mobile, desktop, etc.) for accessing information on the world wide web. More specifically, accessing retail websites or web pages that are identified by a distinct identifier, such as a URL, enabling the web browser to retrieve and display them on the user’s device. However, it is emphasized that then present technology may be operable with downloadable applications (e.g., mobile apps, desktop apps, etc.) which do not require a URL or access to the world wide web, or on websites through some other means of identifying what product, hotel, flight, service, activity, or other type of listing is being presented to the user on the page.

The present technology may detect a website URL or other e-commerce interface identifier or certain product and/or service information, or determine the type of retail store, and accordingly access various data fields, preferably in a uniform format across different stores, in order to determine which input(s) to retrieve from the e-commerce website or application that the user is viewing (this is typically, but not always, initiated when the user is at a “checkout” process - the area of the website or application which allows the user to initiate and/or complete an e-commerce transaction).

Document Object Model (DOM) parsing rules may be implemented, for example, to access various fields from the website or application via JavaScript code. Individual algorithms may be implemented for different proprietary websites or applications (such as Amazon.com and other large retailers), as well as available out-of-the-box electronic commerce solutions or stores such as Joomla, Magenta, or Wordpress plugins, Shopify, Volusion, Bigcommerce, bigcartel, 3dcart, Squarespace, and the like. Each algorithm specific to a particular store may be established by reverse engineering an existing online store and/or store shopping cart, such as to securely retrieve, submit, and validate responses to the data fields within the online store and/or shopping cart. Certain stores may require the redaction of prices of items, charges for the quantity of shipping, etc., in order to obtain a set of usable data fields for the application server, and as such, the present technology may be configured to comply with same.

In at least one example, electronic coupon code(s) may be predetermined to be the “best” code or set of codes in accordance with a rules engine. The rules engine may determine the best code based on crowd sourced user feedback (e.g., voting), administrator setting at the application server of various coupon priorities, numerical percentage or dollar off, other factors, or combinations thereof. As such, the rules engine may be configured to establish a ranking of codes according to at least the aforementioned metrics, with the “best” electronic coupon code, or set of electronic coupon codes, being the highest ranked electronic coupon code or set of electronic coupon codes. A database of electronic coupon codes may be stored at the application server, the database of electronic coupon codes may be manually inserted, user-uploaded, or received from respective application programming interfaces (APIs) and/or third-party application servers of affiliates and partners.

The rules engine may run in part or in whole on the application server and/or on the user or client device as a background process. On an application server embodiment, each time a new electronic coupon code is inserted for a certain store, the application server may run an algorithm to ascertain the numerical discount, percentage discount, and/or combinability of the new code with existing electronic coupon codes, and determine a preset “best” or highest ranked set of codes at the application server. This would then be pulled or pushed from the application server to the client device or browser plug-in running thereon at the time of a customer’s “checkout” or completion of the e-commerce transaction. In the client-side embodiment, a plurality of electronic coupon codes may be pulled or pushed from the application server to be tested on the fly on the client device. This embodiment allows customization of the electronic coupon codes to the particular user, as a user may have exhausted certain electronic coupon code already.

In at least one example, if an electronic coupon code is applied a number of times and is unsuccessful in achieving a reduction of the user’s e-commerce transaction amount, the application server may set a flag for human review to ensure that the electronic coupon code is still valid, or, in yet further embodiments, may automatically set the code to be invalid and to therefore be no longer utilized by the rules engine.

The highest ranked electronic coupon codes may be automatically (requiring no user action) or semi-automatically (requiring a single or a few user action(s)) populated into the coupon fields of an online store, in accordance with the rules engine.

Another example of the present technology provides for the user-less, or anonymous, tracking of an affiliate purchase in order to apportion user cash back without first requiring the creation of a user account. The present service may receive a percentage of product sales for each product sold through an affiliate network or partnership. This revenue is then divided up or apportioned to the user making the purchase, therefore providing them with a so-called “cash back.” The tracking of this cash back is believed to be particularly novel because the present service and application server are able to track e-commerce transactions, without first requiring the user to create a user account at the application server or service.

In order to support this, an identifier is assigned to the application (application identifier or App ID), such as the browser plug-in, background process, or other desktop or mobile application, upon installation and/or first communication to the application server. A table of App IDs are kept on the application server, which checks and logs new unique App IDs.

Signed communications are then utilized, e.g., a unique identifier tagged into any links or navigable portions for effecting action at the application server and/or client device. The application server may then track actions, e.g., clicks, and purchases through the plug in and tie the actions to the App ID.

As discussed, this feature allows the application server to track users without first forcing or requiring registration of personal information during either the coupon use or cash back receiving steps. The transaction is preferably kept for a number of days, such as 10, 15, 30, 45, 60 days in order to encourage user registration. Later, when a user uses the installed application having the App ID to create a user account, traditional user registration (or login by 3^rd party APIs described below) is used, and the data associated with an App ID is then merged into the user account.

Additional features and examples may be combined with the various systems and methods of providing maximum benefit disclosed herein in order to enhance the overall user experience. Initially, various software embodiments of the technology, such as mobile applications, desktop applications, or browser extensions, may be optimized to run various processes as background processes while the user’s attention is elsewhere, in order to reduce waiting times for the user. By way of example, as has been disclosed, in at least one embodiment, a method of automatically applying coupon codes and other benefits is as follows:

1. A user lands at cart or checkout page of an e-commerce platform using a computing device;

2. A software example of the technology directs the device to display a modal window to the user;

3. The user completes an affirmative interaction with the device, such as a click or tap, to apply coupons, activate cashback, or seek another benefit, such as price comparison; 4. The software example of the technology then searches for and/or applies the desired benefits, such as coupons, which according to current estimates, can take anywhere from 3-15+ seconds depending on the number of coupons that need to be identified and applied;

5. The software example of the technology applies the benefit with the biggest savings to the user, thereby determining the maximum benefit.

However, an optimized example of the foregoing method of automatically applying benefits is capable of reducing wait times by at least 3, but most likely 10 seconds, or more. Such a method may include the steps of:

1. A user lands at cart or checkout page of an e-commerce platform using a computing device;

2. With or without appearing to the user, a software example of the technology automatically starts identifying and applying benefits, such as coupon codes, cash back, and/or price comparison, as a background process while the user may be, e.g., reviewing the contents of the cart;

3. Once the software example identifies which benefits are successful, it further identifies the benefit or combination of benefits providing the most savings, i.e., the maximum benefit;

4. The software embodiment then directs the device to display a notification to the user, which may be in the form of a message such as “We found $3.07 in savings, click to apply” or “Click to apply coupons”;

5. The user may then complete an affirmative interaction with the device, such as a click or tap, to apply the coupon code or other benefit.

Accordingly, because the software embodiment has already identified which coupon code or other benefit or combination of benefits provides the maximum benefit, it does not need to cycle through all codes after the user completes the affirmative interaction, and instead it simply applies the previously identified benefit(s). Thus, the user perceives that the operating time for applying coupon codes is reduced as compared to the first embodiment and indeed, the user’s overall wait time is reduced.

In additional embodiments, the software embodiment can also activate cashback and/or price comparison features as part of the benefits that are determined in a background process if there is an affiliate relationship with the merchant operating the e-commerce platform for cashback, or if there are lower prices available at an alternate vendor. In yet further embodiments, the software embodiment may not prompt the user at all to apply the identified benefit(s), but the software embodiment may simply check and automatically apply the benefit(s) providing the most savings without any user input whatsoever. Alternatively, the software embodiment can run at least a portion of the software embodiment on an application server side first (after having identified what is already in the user’s cart), if it is not able to run it on a client device for any reason.

Yet another feature that may be deployed with any of the embodiments disclosed herein is the ability for a software embodiment of the present technology to monitor various page elements to determine if a customer is in a cart or checkout page, as opposed to solely relying on monitoring a URL. Such a feature is useful for app-based shopping or in circumstances where a URL may be obscured from the software embodiment of the present technology. Such a page element can include a keyword, image, logo, or other parsable object associated with a checkout interface of an e-commerce interface, and may be operative to trigger the software embodiment of the present technology to begin applying the ruleset to obtain maximum benefit, such as testing and/or application of coupon codes, cashback, or price comparison across multiple vendors.

Yet another feature that may be deployed with virtually any embodiment of the present technology is the incorporation of disparate customer “loyalty” or “perk” programs into the ruleset for analysis of maximum user benefit. By way of non-limiting example, a user of the software embodiment of the present technology may operatively associate a customer shipping program, such as Freeshipping.com, shoprunner.com, or even one implemented by the applicant, with the present technology. If it is a program implemented by the applicant, customer access may be identified through a username or a unique app identifier. Third party programs may require one or more solutions, either via participating credit cards that those programs work with (e.g., American Express offers Shoprunner access to its cardholders); customers may be prompted to login to a third-party shipping program directly from a software embodiment of the present technology; or by forwarding the user to the login page for those third-party programs, and then routing the user back to the page they were previously on for the e-commerce merchant.

In any event, such a consideration as free shipping from a particular vendor or other loyalty benefit associated with a merchant or financial institution (such as reward “points” redeemable with the merchant or financial institution) may be considered by the ruleset when considering maximum benefit for a user. By way of non-limiting example, if a user is searching for a particular product on a particular website or mobile application, the software embodiment of the present technology may be operative to search for coupons, cashback, price comparison, and whether the product is available via a participating customer shipping program, in order to assess the least expensive means for the user to obtain the product, whether that means applying a large coupon to a merchant that requires a shipping fee, or possibly ignoring a coupon from one merchant, in favor of free shipping from a participating customer shipping program available from another merchant. Other customer loyalty programs, such as “points” or “perks” can be assessed in a similar manner, and the user may be presented with the option to spend the “points” earned from a particular merchant in order to obtain the maximum benefit on a given purchase.

Yet another feature that may be deployed with virtually any embodiment of the present technology is presentation of customization options to users. Given that the present technology presents a variety of embodiments with various features and services, further embodiments provide users with options to select the particular embodiments, benefits, features, services, etc. that are desirable to the user. Additionally, a user may be able to select which e-commerce platforms to implement the present technology. For example, in the embodiment of automatic coupon application, a user may choose to allow the software embodiment to run only on the top stores in the US (top 10, top 50, etc.), or choose to have the software embodiment run on all stores globally. For price comparison embodiments (both the product and travel price compare products), the user may choose which e- commerce platforms to compare. The user may also select which benefits the ruleset will consider, including, but not limited to, coupons, cashback, price comparison, and loyalty programs. Finally, the user may also select whether the present technology will automatically search for and apply the best benefits without user intervention, or whether an affirmative action will be required from the user before the technology begins to search for and apply the best benefits.

Yet further embodiments allow the user to choose these preferences in the onboarding process and manage these selections later in a preferences section of their account, which may be presented in a mobile application, browser extension or, on a dedicated website.

In yet further embodiments, the present technology includes systems and methods facilitating the ability for a consumer to purchase items in a cart from anywhere within an e-commerce website, without having to visit a designated check-out portion of the e- commerce website. For example, if a user adds a product to a cart on a given e-commerce site, e.g., www.macys.com, a software embodiment of the present technology may be operative to detect this operation and present to the user (without leaving the product’s listing page) any one of activating a cashback incentive, applying coupons, or checking out. This may be accomplished by presenting a checkout interface in a pop-up, pop-over, modal window, or the like. Accordingly, maximum benefit is accorded to the user upon adding a product to a virtual shopping cart, and without further user interaction.

In an example of the previously described system enabling checkout in any area of an e-commerce site, it is noted that input of payment and shipping information are also in need of streamlining. Accordingly, a software embodiment of the present technology may offer the user a number of payment options including those integrated with the merchant (e.g., the user already has an account with payment and shipping information stored with the merchant on whose e-commerce site the transaction is taking place); those integrated with a third party (e.g., Amazon Pay, Google Pay, Verified by Visa, etc.) in which the user may be asked to sign in to the third party service as well; those integrated within a software embodiment of the present technology (e.g., in an example where the present technology comprises a web browser extension, the user may save payment and shipping information within the extension; and finally, the user may manually input payment or shipping information. As can be seen, one of the primary goals of the present technology is to reduce the number of “clicks,” inputs, or steps the user must undertake to complete a transaction, and achieve maximum benefit at the same time. Thus, computing resources are conserved as well and the functioning of the computing system is improved. Accordingly, having payment and shipping information accessible by the software embodiment of the present technology facilitates the goal of reducing the number of inputs that must be made by a user. A preferred shipping address, out of a plurality of shipping addresses, may also be specified, which is set as a default shipping address, unless the user specifies otherwise during check out.

The software embodiments which facilitate check out on any portion of an e-commerce website may be carried out in a desktop environment, such as via a web browser extension, or in a mobile environment, such as on a mobile device web browser, or within a native mobile retail application.

The previously described price comparison tools may also be combined with the presently-described method of expediting check out as well. In such an embodiment when a user adds a product to a cart on e-commerce site A, while remaining on e-commerce site A, a software embodiment of the present technology may prompt the user to add the same product to a cart on e-commerce site B, if e-commerce site B provides better benefits (such as a discounted price, availability of coupons/cashback, and the like). As previously described, such a prompt may appear via pop-over, pop-up, modal window, and the like. The software embodiment may then permit the user to complete the transaction within the modal window, while remaining on e-commerce site A (or at the least, without requiring the user to manually navigate to e-commerce site B).

In yet further embodiments, the user may have the option to decline to complete the transaction after adding a first item, but the user may return to the prompt (or be further prompted) after adding one or more additional items, such that a user can browse for and purchase multiple items.

In addition, a software embodiment of the present technology may be operative to detect whether a user has a predetermined relationship with a particular e-commerce retailer or whether the user has installed a software embodiment of the present technology on the computing device used to access the e-commerce site. If the software embodiment is present upon visiting the e-commerce site, the user may be granted access to features, offers, coupons, or deals that would not otherwise be visible to the user. Such an embodiment is operative as a desktop browser extension, as well as on mobile web browsing and native mobile retail applications.

These and other objects, features and advantages of the present invention will become clearer when the drawings as well as the detailed description are taken into consideration.

BRIEF DESCRIPTION OF THE DRAWINGS

For a fuller understanding of the nature of the present invention, reference should be had to the following detailed description taken in connection with the accompanying drawings in which:

Figure 1 is a diagrammatic representation of an exemplary application and implementation environment for providing electronic coupon codes and cash back in electronic commerce of the present invention.

Figure 2 is an exemplary user interface of a browser application for providing electronic coupon codes and cash back in electronic commerce of the present technology, illustrating end user functionality.

Figure 3 is an exemplary user interface of a browser application for providing electronic coupon codes and cash back in electronic commerce of the present technology, illustrating end user functionality with a browser extension. Figure 4 is an exemplary user interface of a browser application for providing electronic coupon codes and cash back in electronic commerce of the present technology, illustrating end user functionality with a browser extension.

Figure 5 is an exemplary user interface of a browser application for providing a providing electronic coupon codes and cash back in electronic commerce of the present technology, illustrating end user functionality with a browser extension.

Figure 6 is an exemplary user interface of a browser application for providing a providing electronic coupon codes and cash back in electronic commerce of the present technology, illustrating end user functionality with a browser extension.

Figure 7 is another exemplary user interface of a browser application for providing electronic coupon codes and cash back in electronic commerce of the present technology, illustrating end user functionality.

Figure 8 is another exemplary user interface of a browser application for providing electronic coupon codes and cash back in electronic commerce of the present technology, illustrating end user functionality with a browser extension.

Figure 9 is another exemplary user interface of a browser application for providing electronic coupon codes and cash back in electronic commerce of the present technology, illustrating end user functionality with a browser extension.

Figure 10 is another exemplary user interface of a browser application for providing a providing electronic coupon codes and cash back in electronic commerce of the present technology, illustrating end user functionality with a browser extension.

Figure 11 is another exemplary user interface of a browser application for providing a providing electronic coupon codes and cash back in electronic commerce of the present technology, illustrating end user functionality with a browser extension.

Figure 12 is a flow chart depicting steps of a method according to one embodiment of present technology.

Figure 13 is another exemplary user interface of an application for providing maximum benefit in electronic commerce of the present technology, illustrating end user functionality.

Figure 14 is another exemplary user interface of an application for providing maximum benefit in electronic commerce of the present technology, illustrating end user functionality. Figure 15 is another exemplary user interface of an application for providing maximum benefit in electronic commerce of the present technology, illustrating end user functionality.

Figure 16 is another exemplary user interface of an application for providing maximum benefit in electronic commerce of the present technology, illustrating end user functionality.

Figure 17 is a flowchart depicting operative logic of a method according to one software embodiment of the present technology.

Figure 18 is an exemplary user interface for an e-commerce site A with which the present technology may be implemented.

Figure 19 is an exemplary user interface including a checkout modal window prior to completion of a checkout process.

Figure 20 is an exemplary user interface including the checkout modal window subsequent to the completion of the checkout process. Figure 21 is an exemplary user interface for an e-commerce site B with which the present technology may be implemented.

Figure 22 is an exemplary user interface including a checkout modal window prior to completion of a checkout process.

Figure 23 is an exemplary user interface including the checkout modal window subsequent to the completion of the checkout process.

Figure 24 depicts another example checkout modal window.

Figure 25 depicts another example checkout modal window.

Figure 26 depicts an example method for facilitating e-commerce transactions by completing a checkout process via a checkout modal window. Figure 27 depicts an example method for executing a background process to facilitate an e-commerce transaction.

Like reference numerals refer to like parts throughout the several views of the drawings. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

The present technology may be implementable on an application server in a software-as-a-service (SaaS) mobile application, or desktop application environment in accordance with implementation on a system or application 100 as generally represented in Figure 1. Accordingly, the system 100 of the present technology generally comprises at least one client device 101 communicably connected to at least one application server 110 over a network 130. One or more third party server(s) 120 may further be communicably connected to the application server 110 and the at least one client device 101 over the same network 130.

The client device 101 may comprise a mobile device, tablet, computer, wearable electronic device, or any other device or combination of circuits structured and configured to communicate with another device, computer, or server over the network 130. The client device 101 may comprise application(s) and user interface(s) (front-end interface) that allows a user to interact with the application server(s) 110 and any third-party server(s) 120 and stored applications and programs thereon (back-end processing). The user interface may be proprietary and may comprise a custom developed mobile or desktop application(s). Alternatively, or in addition to, the user interface may comprise a web browser (including mobile browsers designed for use on a mobile device) or other application or executable code that allows for communication and visualization of information.

The term “application server” 110, “third party server” 120 refer to at least one computer having appropriate hardware and applications installed thereon for the provision of server services including web and other functional services described herein, such that a user may access, execute, and/or view the applications remotely from a client device 101. More specifically, the application server(s) 110 and third-party server(s) 120 may comprise general-purpose computers, specialized computers, or other hardware components structured and configured to receive, process, transmit, and store information to and from other devices. The application server 110 is further configured with executable or interpretable computer code that allows it to perform the processes described within this application.

For example, the application server 110 may comprise a general-purpose computer comprising a central processing unit (CPU) 111, which may be a single core or multi core processor, memory 114 (random-access memory, read-only memory, and/or flash memory) or primary memory for high-speed storage of executing programs, electronic storage unit 115 (e.g., hard disk) or secondary memory for storing data, communications interface 112 (e.g., network adapter) for communicating with other devices or computers over a network, and/or peripheral device(s) 113 in communication with the CPU 111 that enable input/output of the application server 110.

The application server 110 may implement the methodology of the present technology using any number of solution stacks (a set of software subsystems or components) known to an ordinary computer or web programmer skilled in the art. These solution stacks may include, without limitation, ZEND Server, APACHE Server, NODE. JS, ASP, PHP, Ruby, XAMPP, LAMP, WAMP, MAMP, WISA, LEAP, GLASS, LYME, LYCE, OpenStack, Ganeti, MEAN, MEEN, XRX, JAVASCRIPT and other past, present, or future equivalent solution stacks, or combinations thereof, known to those skilled in the art that allows a programmer to develop the methods and computer programs described within this application. The software stack might be implemented without third-party cloud platforms, for example using load balancing and virtualization software provided by Citrix, Microsoft, VMware, Map-Reduce, Google Filesystem, Xen, memory caching software such as Memcached and Membase, structured storage software such as MySQL, MariaDB, XtraDB, etc. and/or other appropriate platforms. Of course, these solution stacks may also be deployed in cloud platforms by using known development tools and server hosting services such as GitHub and Rackspace, as well as their equivalents.

The third-party server(s) 120 may comprise any combination of hardware and software (code segments in any number of programmable, executable, or interpretable languages that support the functionality of the methods described herein) configured to host and transmit items of a user. The third-party server(s) 120 may be configured to communicate directly to the application server 110 via application programming interfaces or upon the request of a user.

User account services may be implemented using one or more solution stacks as described above. Alternatively, third-party login services such as Facebook, Twitter, Linkedln, Google and other related services, may be utilized for user account login and authentication, such as via existing third-party server(s) 120 of other parties.

The network 130 may comprise at least two computers in communication with each other, which may form a data network such as via LAN, WAN, Serial, Z-WAVE, ZIGBEE, RS-485, MODBUS, BACNET, the Internet, or combinations thereof. The connections may be facilitated over various wired and/or wireless mediums or any combination thereof including interconnections by routers and/or gateways. Network 130 may comprise additional hardware components and/or devices appropriate for facilitating the transmission and communication between the various systems and devices of the present technology, such as those directed to integrated authentication, quality control or to improve content delivery such as via a content delivery network (CDN).

Various aspects of the present technology may be thought of as “products” or “articles of manufacture” typically in the form of machine (or processor) executable code, interpretable code, and/or associated data that is carried on or embodied in a machine- readable medium. Machine-executable code can be stored on an electronic storage unit, such memory (e.g., read-only memory, random-access memory, flash memory) or a hard disk, as described above.

All or portions of the software may at times be communicated through the Internet or other communication networks. Such communications, for example, may enable loading of the software from one computer or processor onto another, for example, from a management server or host computer onto the computer platform of an application server, or from an application server onto a client computer or device. Thus, another type of media that may bear the software elements includes optical, electrical and electromagnetic waves, such as used across physical interfaces between local devices, through wired and optical landline networks and over various air-links. The physical elements that carry such waves, such as wired or wireless links, optical links or the like, also may be considered as media bearing the software. As used herein, tangible “storage” media, terms such as computer or machine “readable medium”, refer to any medium that participates in providing instructions to a processor for execution. Further, the term “non-transitory” computer readable media includes both volatile and non-volatile media, including RAM. In other words, non- transitory computer media excludes only transitory propagating signals per se, but includes at least register memory, processor cache, RAM, and equivalents thereof.

Therefore, a machine-readable medium, such as computer-executable code and/or related data structures, may take many forms, including but not limited to, a tangible storage medium, a carrier wave medium or physical transmission medium. Non-volatile storage media include, for example, optical, magnetic, or solid-state disks, such as any of the storage devices in any computer(s) or the like, such as may be used to house the databases. Volatile storage media include dynamic memory, such as main memory of such a computer platform. Tangible transmission media may include coaxial cables, copper wire and fiber optics, communication buses. Carrier-wave transmission media may take the form of electric or electromagnetic signals, or acoustic or light waves such as those generated during radio frequency (RF) and infrared (IR) data communications. Common forms of computer- readable media therefore include for example: a floppy disk, a flexible disk, hard disk, magnetic tape, any other magnetic medium, a CD-ROM, DVD or DVD-ROM, any other optical medium, punch cards paper tape, any other physical storage medium with patterns of holes, a RAM, a ROM, a PROM and EPROM, a FLASH-EPROM, any other memory chip or cartridge, a carrier wave transporting data or instructions, cables or links transporting such a carrier wave, or any other medium from which a computer may read programming code and/or data. Many of these forms of computer readable media may be involved in carrying one or more sequences of one or more instructions to a processor for execution.

A web browser or downloadable application may embed and/or access a plug-in or extension 103. As known in the art, an extension may be implemented in different forms, including a callable script implemented using a scripting language, such as JavaScript. For example, a web browser 102 may call or invoke a script built and injected into a webpage and loaded by a browser-type application. As discussed hereinafter, an extension 103 may communicate with the application server 110 so as to send and retrieve e-commerce information relating to products and services of merchant e-retailers.

A client device 101 may include device specific storage functionality such as local storage capable of storing certain e-commerce information. For example, device local storage may be configured to store a plurality of electronic coupon codes or response data to codes checked against a website or application’s “checkout page”. However, local storage is not a necessary requirement of the present technology; e-commerce information, such as a plurality of coupon codes, may be stored and applied directly from the application server 110

In one embodiment, device local storage may submit response data to the application server 110, so as to store and maintain successful electronic coupon codes. Response submission may be initiated by the browser extension 103 and may be carried out as a background process. Unsuccessful electronic coupon code responses may flag an electronic coupon code to be deleted or human reviewed.

For the ease of illustration, the present disclosure primarily features a web browser application of a client device 101 used to conduct e-commerce website transactions, and a browser extension 103 used by the client device 101 to render client-side functionalities of the disclosed method. However, additional embodiments and implementations are envisioned by the present technology.

The present technology provides for a system, method, and computer program for providing, automatically trying, and applying electronic coupon codes and cash back in electronic commerce. Drawing attention to Figures 2 - 6, examples of the present technology are illustrated from an end user’s perspective.

Drawing attention to Figure 2, the present technology may comprise a browser plug in or extension that may appear dormant until being ‘activated’ and injected into the user interface upon navigation to a “checkout page” of a supported e-commerce website, as discussed in detail hereinafter. In at least one embodiment, the user may be provided with an icon plug-in 201, for example, displayed on the browser’s toolbar. The icon plug-in 201, may comprise specific e-commerce information regarding the currently navigated website via back-end communications with the application server 110, as discussed in greater detail hereinafter. The icon plug-in 201 may comprise a coupon code icon 202, representing a total amount of electronic coupon codes from the application server 110 for the current website. In another embodiment, the icon plug-in 201 may comprise a cash back icon 203, for example, indicated by dollar signs. The cash back icon 203, may indicate to the user that the current website offers some form of ‘cash back’ on purchases made via the current e- commerce website.

Upon initially navigating to a website, the application 100 may detect and capture URL information, such as the domain name, to send as a parameter to the application server 110 in order to validate that the website is supported, as known to those skilled in the art. If supported, the application 100 may retrieve specific e-commerce information and store it locally, such as, to the device’s temporary local storage until the user navigates to the current website’s “checkout page”. Upon navigation to a different website, the application 100 will repeat the above process.

For example, the coupon code icon 202, may display the number ‘5’ indicating that there are five merchant electronic coupon codes provided for the user by the application server 110. In one embodiment, the icon plug-in 201 may appear colorless and without the coupon code or cash back icons 202, 203. This may happen for example, upon navigation to an unsupported website or if the application 100 cannot communicate with the website due to operating system limitations. In at least one embodiment, the icons 201, 202, 203 may appear with color upon navigation to a supported website, in order to alert the user to possible savings. In some embodiments, the icon plug-in 201 may be an interactive user interface element, such as a button. Upon click through of this button 201, the user may be provided with e-commerce information, such as individual electronic coupon codes, which may be viewable and/or selectable. In one embodiment, the user may cut and paste coupon code(s) into a “Coupon Code” type input field of the website’s checkout page.

Drawing attention to Figure 3, when a “checkout page” of an e-commerce website is detected by the application 100, the dormant or embedded browser extension 103 may be activated or invoked into an already loaded webpage 102. As illustrated, the browser extension 103, here in the form of a user interface ‘panel’ 300, may be slid or injected into the current website’s “checkout page” in order to alert the user to possible savings. The browser extension 103, may take various shapes or colors and be injected into different areas of the current website 102 in order to best alert the user. The browser extension 103 may include a coupon code message 301 indicating to the user that the application 100 has provided the user with at least one electronic coupon code and an interactive button, such as a “Try Codes” button 302, prompting the user to try the codes against the items currently in the user’s shopping cart. In one embodiment, the browser extension 103 may automatically begin checking and applying electronic coupon codes against cart items upon activation.

In one embodiment, upon detecting a “checkout page” the application 100 may parse the user’s shopping cart and capture item specific information, such as description(s) or product identifier(s), send as parameters to the application server, and retrieve only product specific electronic coupon codes, as known to those skilled in the art.

Upon selecting the “Try Codes” button 302, the application 100 will check or test each electronic coupon code saved locally against the items within the user’s shopping cart. In one embodiment, the application 100 may check all the electronic coupon codes within a background process, hidden to the user. In other embodiments, the browser extension 103 may provide the user with the results on the UI panel 300 as each electronic coupon code is checked in sequence. As illustrated in Figure 4, the browser extension 103 may initially display a sequential list 303 of all electronic coupon codes to be tested, each code including a coupon code description 304. As each electronic coupon code is checked against the website, the application 100 may update the UI panel 300 with “live” results to allow the users to have updated feedback for each code tested in the process. For example, if an electronic coupon code is checked and found to be successful in saving the user money, the application 100 will calculate a coupon code savings 305, representing how much money the electronic coupon code will save the user. In one embodiment, the application will display the coupon code savings 305 next to the coupon code description 304 of the UI panel 300. In at least one embodiment, if an electronic coupon code has a negative or failure result, the application 100 may draw a line through the coupon code description 304 indicating to the user that the electronic coupon code does not save the user money on any items within the current shopping cart. In another embodiment, the application 100 may put an ‘X’ in the coupon code savings 305, indicating the failure of the electronic coupon code.

As illustrated in Figure 5, the application may rank the coupon code descriptions 304 by coupon code savings 305 in order of money that may be saved from highest to lowest. If the website’s checkout page only allows one coupon code description 304 per transaction, the application 100 will apply the highest or best ranked coupon code savings 305 into the ‘Coupon Code’ input field of the website’s checkout page. In one embodiment, where the website’s checkout page allows more than one coupon code description 304 to be applied, but has a ‘maximum’ electronic coupon code rule, the application 100 may check all electronic coupon code combinations from the prior ‘pool’ of the successful electronic coupon codes per the saved results, and apply the best code combination (that saves the user the most money). In another embodiment, where the website’s checkout page allows more than one coupon code description 304 to be applied and does not have a ‘maximum’ electronic coupon code rule, the application 100 may apply all successful electronic coupon codes in order from the best or highest coupon code savings 305 to the lowest.

Figure 6 illustrates the browser 102 and browser extension 103 after the application 100 has applied the best code(s) to the website. The UI panel 300 of the browser extension 103 may include the coupon code description(s) 305 of applied electronic coupon code(s) and the total coupon code savings 306 indicating how much money the user saved per applied electronic coupon code(s). The UI panel 300 may also include a button, such as ‘BACK TO CART’ button 307, which may put the UI panel back to a dormant state upon click through. In one embodiment, the application 100 may automatically enter the applied code(s) into the user’s shopping cart ‘Coupon Code’ input field of the website’s checkout page. In another embodiment, the application 100 may automatically update or reload the user’s view to properly reflect the results of applying electronic coupon code(s) and its changes on the ‘Discount’ and/or ‘Total’ fields, or equivalents, of the website’s checkout page.

In another embodiment, the present technology may be implementable on the application server 110 in a mobile environment in accordance with implementation on an application 100 as represented in Figure 1. This embodiment of the present technology may provide a method for automatically providing and applying e-commerce savings, such as electronic coupon codes and/or “cash back” in electronic commerce transactions, as described in greater detail hereinafter. Drawing attention to Figures 7 - 11, embodiments of the present technology are illustrated from an end user’s perspective.

Upon initially navigating to a website 1102, the application 100 may automatically detect and capture certain website URL information, such as the domain name, to send as a parameter to the application server 110 in order to validate that the website 1102 is supported by the application 100. If supported, the application 100 may automatically retrieve the electronic coupon codes and/or “cash back” associated with the website 1102. The application 100 may detect, capture, and/or retrieve within a background process, hidden to the user. In one embodiment, the application 100 may prompt the user to ‘manually’ detect the website URL information, via an interactive user interface element, such as a button, in order to retrieve the website e-commerce savings.

The application 100 may store the e-commerce savings information locally, such as, to the client device’s 101 temporary local storage until the user navigates to the current website’s “checkout page” which may alert the user to possible savings. Upon navigation to a different website, the application 100 will repeat the above process. A website’s “checkout page” may at least partially comprise a webpage of the website wherein the user is able to initiate an e-commerce transaction. In one embodiment, the “checkout page” may comprise one webpage. In other embodiments, the “checkout page” may comprise more than one webpage with differing names, for example, a “shopping cart page” and a “checkout page”.

In one embodiment, the application 100 may retrieve the website’s ‘ruleset’ from the application server 110. A ruleset may comprise certain website information, such as a webpage element. For example, the ruleset may comprise the location of a webpage field within a webpage(s), such as a coupon code input field, in order to determine if the user has navigated to the website’s “checkout page”. The application 100 may monitor the current website 1102 to determine if the user has navigated to the “checkout page” of the website, for example, via the coupon code input field. In another embodiment, the application 100 may retrieve an external provider ruleset from the application server 100 that is at least partially associated with the website’s ‘ruleset’.

Drawing attention to Figure 7, when the application 100 determines that the user has navigated to the supported website’s “checkout page”, the application 100 may ‘activate’ and inject an icon plug-in 1201 into the into an already loaded web browser in order to alert the user that electronic coupon codes and/or “cash back” are available. In one embodiment, the icon plug-in 1201 may automatically be injected on the user’s web browser, as is represented in Figure 7. In another embodiment, the icon plug-in 1201 may be injected within the browser and accessible to the user after selecting a web browser button, such as the “share” button.

The icon plug-in 1201 may comprise a coupon code icon 1202, representing a total amount of electronic coupon codes from the application server 110 for the current website. In one embodiment, the icon plug-in 1201 may also comprise a cash back icon, for example, indicated by dollar signs. The cash back icon 1203, may indicate to the user that the current website offers some form of ‘cash back’ on purchases made via the current e-commerce website. The icon plug-in 1201 may be an interactive user interface element, such as a ‘clickable’ or selectable button.

More specifically, for example, the coupon code icon 1202 may display the number ‘2’ indicating that there are two merchant electronic coupon codes provided for the user by the application server 110. Upon selection of the icon plug-in 1201, the user may be provided with specific e-commerce information, such as individual electronic coupon codes, which may be viewable and/or selectable. In one embodiment, the user may ‘cut and paste’ coupon code(s) directly into an input field of the website’s checkout page.

Drawing attention to Figure 8, the present technology may comprise a browser plug in or extension 1103 that may appear dormant until being ‘activated’ and injected into the web browser. More specifically, upon selection of the icon plug-in 1201, the dormant or embedded browser extension 1103 may be activated or injected into the already loaded “checkout page” 1102. As illustrated, the browser extension 1103, here in the form of a web browser ‘panel’ 1300, may be slid or injected into the current website’s “checkout page” in order to alert the user to specific possible savings.

The browser extension 1103, may take various shapes or colors and be injected into different areas of the current website 1102 in order to best alert the user. The browser extension 1103 may include a coupon code message 1301 indicating to the user that the application 100 has provided the user with at least one electronic coupon code and an interactive button, such as an “AUTO APPLY COUPONS” button 1302, prompting the user to check the coupon code(s) against the items currently in the user’s ‘shopping cart’ of the website’s “checkout page”. In one embodiment, the browser extension 1103 may automatically begin checking electronic coupon codes against cart items upon activation or injection. In another embodiment, upon detecting a “checkout page” the application 100 may parse the user’s shopping cart and capture item specific information, such as description(s) or product identifier(s), to send as parameters to the application server 110 and retrieve only product specific electronic coupon codes.

As illustrated in Figure 9, upon selecting the “AUTO APPLY COUPONS” button 1302, the application 100 will check or test each electronic coupon code against the items within the user’s shopping cart. The browser extension 1103 may provide the user with the results on the ‘panel’ 1300 as each electronic coupon code is checked in sequence. If there is more than one coupon code, the browser extension 1103 may initially display a sequential list 1303 of all electronic coupon codes to be tested. Each coupon code may include a coupon code description 1304. In one embodiment, the application 100 may check all the electronic coupon codes within a background process, hidden to the user.

As each electronic coupon code is checked against the website 1102, the application 100 may update the ‘panel’ 1300 with “live” results to allow the user to have updated feedback for each code tested in the process. For example, if an electronic coupon code is checked and found to be successful in saving the user money, the application 100 may calculate a coupon code savings, representing how much money the electronic coupon code will save the user. In one embodiment, the application will display the coupon code savings next to the coupon code description 1304 of the panel 1300.

In at least one embodiment, if an electronic coupon code has a negative or failure result, the application 100 may draw a line through the coupon code description 1304 indicating to the user that the electronic coupon code does not save the user money on any items within the current ‘shopping cart’. In another embodiment, the application 100 may put an ‘X’ near the coupon code description 1304, indicating the failure of the electronic coupon code.

The application 100 may check the coupon codes against the website by executing a background process to determine whether the electronic coupon code(s) is successful or fails to achieve a reduction of the user’s e-commerce transaction amount. The result of determining whether the electronic coupon code(s) is successful or fails to achieve a reduction in the user’s e-commerce transaction amount may comprise “response” information from the website, which may be stored locally on the user’s device.

As illustrated in Figure 10, the application 100 may display the total amount the user may save from the coupon code(s) that were checked against the website’s checkout page. An interactive button, such as an “UPDATE CART” button 1305, may prompt the user to apply the coupon code(s) against the user’s ‘shopping cart’ of the website’s “checkout page”. In one embodiment, the application 100 may apply the checked coupon code(s) automatically. Upon selection, the user’s shopping cart will be updated to reflect the savings provided by the applied coupon code(s).

In one embodiment, the application 100 may rank the coupon codes in order of money that may be saved, such as from highest to lowest. If the website’s checkout page only allows one coupon code per transaction, the application 100 will apply the highest or best ranked coupon code input field of the website’s checkout page. In another embodiment, where the website’s checkout page allows more than one coupon code to be applied, but has a ‘maximum’ electronic coupon code rule, the application 100 may check all electronic coupon code combinations from the prior ‘pool’ of the successful electronic coupon codes per the saved results, and apply the best code combination (that saves the user the most money).

In another embodiment, where the website’s checkout page allows more than one coupon code to be applied and does not have a ‘maximum’ electronic coupon code rule, the application 100 may apply all successful electronic coupon codes in order from the best or highest coupon code savings to the lowest. In one embodiment, the application 100 may prompt the user to apply at least one coupon code against the website’s checkout webpage. In another embodiment, the application 100 may automatically apply at least one coupon code against the website’s checkout webpage.

Figure 11 illustrates the e-commerce website 1102 after the application 100 has applied the best coupon code(s) to the shopping cart items of the website. As illustrated, the website 1102 may display a “new” total amount after applying the coupon code(s) and other discounts. In one embodiment, the application 100 may automatically enter the applied code(s) into the user’s ‘shopping cart’ coupon code input field of the website’s checkout page. In another embodiment, the application 100 may automatically update or reload the user’s view to properly reflect the results of applying electronic coupon code(s) and its changes, for example on a ‘Discount’ and/or ‘Total’ fields, of the website’s “checkout page”, as illustrated in Figure 11.

Additionally, when the user navigates to the checkout page, the application 100 may ‘activate’ the cash back functionality associated with the e-commerce transaction within a background process, hidden to the user. In one embodiment, while the application 100 ‘activates’ the cash back functionality, the application 100 may concurrently inject a browser plug-in into the checkout page of the web browser. The application 100 may automatically activate the cash back functionality. More specifically, when the user has navigated to the checkout page, as illustrated in Figure 11, the application 100 may capture certain information, such as the website domain name, the total amount of the purchase, user information (for example, user number, user name, user address, etc.) to send as a parameter(s) to the application server 110 in order to validate that the website 1102 is supported or affiliated by the application 100.

If supported, the cash back functionality may be ‘activated’ or saved to the application server 100 in order to provide the user with his or her cash back savings. If activated, e-commerce transaction information, such as the total amount of the purchase, user information, etc., may be saved to the application server 110. The application 100 may calculate and provide the user with the cash back savings, for example, in the form of a rebate check. In another embodiment, the application 100 may prompt the user to ‘manually’ activate the cash back functionality, via an interactive user interface element, such as a button. Upon activation, the application 100 may display the cash back savings in the web browser, for example, via a browser plug-in.

As mentioned above, the application server 110 may save or track the user’s e- commerce transaction, via user information, such as the user number, user name, etc. In one embodiment, the application 100 may track an ‘unknown’ user’s e-commerce transactions anonymously, in order to offer the user cash back on purchases. Tracking the e-commerce transaction anonymously may comprise calculating a ‘cash back’ amount earned associated with the e-commerce transaction. The application 100 may track the e-commerce transaction across a plurality of separate e-commerce transactions, calculating the cash back amount earned associated with each of the plurality of separate e-commerce transactions, and associating each of the cash back amounts with the user via an anonymous client device identifier, as known to those in the art.

In another embodiment, the present technology may be implementable on the application server 110 in a desktop or mobile environment in accordance with implementation on an application 100 as represented in Figure 1. Once downloaded to the user’s mobile or desktop device 101, the present technology will automatically detect when the user has initiated a shopping experience and activate. As such, it will not be necessary for the user to ‘open’ the present technology on his/her mobile or desktop device 101 prior to, or during, the shopping experience. This feature will save the user time and reduce “click counts” in their shopping experience, which will allow users to complete purchases faster which increases the chances for a sale.

Drawing attention to Figure 12, a method of the present technology may initially comprise detecting a URL or domain name of a website to determine if the webpage is supported by an application server by submitting parameters, such as a URL address or domain name, to the application server, as in 901. The application may continuously monitor for URI/URL changes and automatically access the application server to determine if the webpage is supported. The application may access the application server via a mobile application interface installed on the client device, or via a browser accessing the application server as described above. In some embodiments, websites may not be in ‘communication’ with the application due to operating system limitations and may require a manual detection to determine if the current website is supported by the application server. This manual detection may include another browser extension, designed to capture URL or domain name information, such as by DOM parsing of the website. This information may then be submitted to the application server.

Next, in 902, if the website is supported by the application server, specific stored merchant information, such as but not limited to, a website ruleset, electronic coupon codes, and cash back settings, is retrieved from the application server and saved locally on the user’s device. In one embodiment, all electronic coupon codes of the supported website may be retrieved from the application server. In another embodiment, all electronic coupon codes may be sorted by the application server based on factors such as past success or user feedback and retrieved. In other embodiments, electronic coupon codes that are more probable for success may be compiled by the application server into a specific list or queue designed to maximize the user’s savings, based on several factors of a predefined algorithm or procedure.

For example, some factors may be: success rates reported by users of the application; success of electronic coupon codes applied by the application processes; frequency of appearance of the electronic coupon code(s) on public website(s); or electronic coupon codes containing non-redundant keyword patterns. The electronic coupon codes stored on the application server may be harvested in various ways, such as, programmatically or manually provided by merchant websites via affiliate agreements; collected from general affiliate pools or networks; collected from the internet or other publicly available sources; or submitted by users.

Next, at 903, the application may continuously monitor the URI/URL and webpage elements to detect when a user has navigated to a checkout page or process of the website. If the application detects that the user has navigated to another website, such as by URI/URL changes, the application will repeat step 901. If the application detects certain page elements (based on the website’s retrieved ruleset) that indicate the user has navigated to the checkout page, the application may move on to the next step to check electronic coupon codes. In one embodiment, the retrieved ruleset may require item or product specific electronic coupon codes only to test. In such an embodiment, prior to checking the codes, the application may parse the user’s shopping cart, capture item information and submit to the application server, retrieve only the item specific electronic coupon codes, and save locally on the user’s device.

In some embodiments, websites may not be in ‘communication’ with the application due to operating system limitations and may require a manual detection as described above. In such embodiments, the application will immediately detect current page elements from the webpage, in which the manual detection was executed from, in order to determine if the user has navigated to the checkout page.

Users next may be prompted to check electronic coupon codes against the item(s) in the user’s electronic shopping cart, as in 904. In one embodiment, the application will automatically begin applying electronic coupon codes by executing a background process. In other embodiments, the application may inject a user interface element into the website’s checkout page prompting the user to begin checking all or specific electronic coupon codes. The check codes function of the application server may find the user the best possible electronic coupon code(s) with the most possible total savings. The application may save the current subtotal and/or total order amount of the user’s cart prior to checking the codes.

In some embodiments, the ruleset may define website provided coupon or promo codes. In such embodiments, where the codes have already been applied to the user’s shopping cart, the application may parse and save those applied codes in order to prevent interference with the electronic coupon codes retrieved from the application server.

Electronic coupon codes may be checked against the website’s checkout page individually through a defined background process, such as an Asynchronous Javascript and XML (AJAX) request. In one embodiment, some or all electronic coupon codes may be tried all at once by opening and parsing several processes. In another embodiment, some codes may be tried through a “form post” process. In one embodiment, some codes may be tried using device specific functionality, e.g., webview and parsing, such as due to mobile operating system limitations.

In certain embodiments, websites may not be able communicate with the application, or else the application may not be able to detect a URL, due to operating system limitations and may require an alternate way to check electronic coupon codes and determine whether the electronic coupon codes are successful or result in discounts being applied. Accordingly, the application may be configured to build and run a separate script or extension, encapsulating all logic elements and check code functionality as discussed herein, that will pass the electronic coupon codes to the script and check the codes in a submitted backend process, and inject the script into the frontend webpage without requiring the user to reload the webpage.

When an electronic coupon code is checked or validated against the website’s checkout page, each response may be saved locally to the user’s device and also submitted to the application server for analytic purposes. The application may capture the response, for example, by standard DOM parsing rules or may use site-specific provider rules. In some embodiments, such as websites that require checking electronic coupon codes independently, response information, such as coupon code description and the amount saved, or the rejection reason, may be saved to the local storage of the user’s device. In other embodiments, the application may parse the total amount of the user’s cart in conjunction with the checked electronic coupon code, and calculate the difference in price, and save this information locally on the user’s device. In one embodiment, the application may update the user interface with the results of the check code process in order to allow users to have updated feedback for each code tried in the process(es).

In one embodiment, the ruleset may require the application to copy the user’s shopping cart to verify whether the latest electronic coupon code has been applied successfully. In another embodiment, the ruleset may require the application to clear a checked code after the response information has been captured and before checking the next code in the list or queue.

The application may review the local storage on the user’s device, determine the best code(s), and apply the code(s) to the user’s shopping cart. In one embodiment, the user’s cart may only allow one electronic coupon code. If the cart automatically overrides or erases the applied code per the ruleset, the application may re-apply the best code to the user’s cart. If the cart requires that the code be cleared per the ruleset, the application may clear the existing code, and re-apply the best code to the user’s cart. In another embodiment, the user’s cart may allow more than one electronic coupon codes.

If the cart allows more than one code but has a maximum rule per the ruleset, the application may build a new queue of combinations of successful electronic coupon codes that may be applied together. In such an embodiment, the application may apply a plurality of code combinations, capturing the response information of each grouping as discussed above to accurately apply the best code or combination of codes. The best code or combination of codes may be ranked in order from highest to lowest amount saved. If the ruleset defines a limit to the amount saved by codes or total codes that may be applied to a user’s cart, the application may apply the best possible combinations to maximize the amount saved.

Next, in 905, the application may display the electronic coupon codes applied to the user’s cart and a “Total Amount Saved” message to the user interface. The application may allow the user to “retry” the codes, for example, after altering the cart. In one embodiment, additional savings may be available by manual application of codes to the user’s cart. In such embodiments, the application may display a message or highlight the availability to the user. In some embodiments, the user’s cart may require a webpage refresh to display the most recent application of electronic coupon codes applied, for example via a background process. The application may record the total amount saved, after the user completes the checkout, for historical purposes.

Next, optionally, in 906 the application may track the user’s e-commerce transactions in order to offer the user cash back on purchases anonymously. More specifically, in step 902, cash back settings of an e-commerce website may be retrieved from the application server. For example, an e-commerce website may offer 3% ‘cash back’ on purchases to the user, as known in the art. In the preferred embodiment, the application may track the user’s purchases or transactions anonymously, such that the user may use the cash back functionality after installing the application on his or her device, without divulging personal information to the application. For example, after installing the application, the application may generate a unique device identifier. When the user utilizes the application via the device, such as: purchases, API requests, selecting or clicking “Cash back” button(s), or logging in or creating an account with the application, the application server will detect the unique identifier and save the information. Next, the application will retrieve information, such as cash back earnings, from the application server to update the device’s local storage with the cash back earnings.

The application allows the user to later create an account through the application. On occurrence, the application server will compile all transactions assigned to the unique device identifier and re-assign them to the new user account. In one embodiment, if the user creates an account on another device with the application (or via the website), the user may link the account with the identifier via received “signed communications” such as emails or text links. More specifically, a user may receive signed communications on the device that the application is installed. These signed communications may be detected by application listeners on other devices, wherein the application will store the signed communication. Next, the application may send the signature to the application server (which the signature is attributed to the user) and retrieve user data to the application on the new device. The application may then store the user data in permanent storage.

In another embodiment, if the user logs in via the application website, the application may detect the login cookies and session data that is set by the website on the next visit, and logs in the user through the application by storing a permanent device identifier on the device’s local storage and on the application server. The user then may log in/out of the website and clear cookies, but the application will remain assigned to the appropriate user id by saving unique application keys in the device’s local storage as long as the application remains installed. This is because the user’s login status is “cookieless” once assigned to the application and stored permanently in the device’s storage.

Drawing attention to Figures 13 - 16, embodiments of the present technology are illustrated from an end user’s perspective. In order to begin a shopping experience, a user may initially navigate to or open a target e-commerce interface 2102 of a target merchant ‘store’. More specifically, the target e-commerce interface 2102 of a target merchant store may comprise the target merchant store’s website, such as a mobile website, or a native downloadable application, such as a native mobile application. Accordingly, for purposes of clarity and without limiting the scope of the present technology, this technology will be described with reference to the target e-commerce interface 2102 and a competing e- commerce interface 2202 of at least one competing merchant store being implemented in a desktop environment using a web browser. However, it is emphasized that the target e- commerce interface 2102 and/or the competing e-commerce interface 2202 of the at least one competing merchant store can be operable in addition to and other than a desktop environment (e.g., mobile web or native application environment).

Further, after the user navigates to or opens the target e-commerce interface 2102, the application 100 automatically detects when the user is viewing at least one product or service and automatically captures certain information, such as but not limited to, the product or service item listing. The item listing may contain specific information about the product or service and general information about the target e-commerce interface 2102, which can be sent as parameters to the application server 110 in order to validate that the target e-commerce interface 2102 is supported by the application server 110. If supported, the application server(s) 110 may compare the item listing(s) with item listing(s) of other e- commerce merchant ‘stores’ in order to find the lowest price available, as described in greater detail below. The item listing may include any conceivable product or service that the user is viewing during the shopping experience, including travel services for booking hotels, airfare, tours, etc.

For purposes of clarity and without limiting the scope of the present technology, this technology will be described with reference to an item price of an item listing being the current lowest price of said product or service after all price factors have been applied to the base price of same. As such, an item price may include price factors such as, but not limited to, sales tax amount, shipping cost amount, vendor fees amount, resort fees amount, coupon savings, cashback or rebate savings, or any combination of the above. It should be noted that a key component of any online transaction cost is sales taxes and shipping costs. In order to properly (and automatically) calculate these items, the user’s location needs to be determined. In one embodiment, the user’s location may be determined based on the IP address of his/her client device 101. In another embodiment, the user’s location may be determined based on his/her preferred shipping address, which may or may not be visually visible on the merchant website or application. After determining the location, the sales tax and shipping costs can be determined without requiring the user to navigate to the competing merchant store. This is unique because sales taxes and shipping costs may vary from merchant to merchant depending on the merchant’s location relative to the user (e.g., due to sales tax nexus, lower shipping costs due to warehouse location, etc.). Further, this may be accomplished in a “background” process, hidden from what the user can visually see on the screen.

As an example, referencing the hypothetical table below, Competing Merchant C has the highest base price of the competing merchants, but after applying the cashback savings and coupon savings, the present technology has automatically calculated that the lowest item price would currently come from Competing Merchant C. In addition, since Competing Merchant A and Competing Merchant B also have a lower item price than the Target Merchant, the present technology may retrieve and display all three item listings of the Competing Merchants to the client device 101. In one embodiment, the application 100 may provide the user with various item price factors (tax amount, etc.) that allows the user to manually select what he/she would like the item price to include prior to comparison.

Each item listing may comprise an e-commerce interface identifier and certain product and/or service information, such as but not limited to: item code, including a product or service identifier; product ID code; service ID code; Universal Product Code (UPC); SKU code; product name; service name; item state (e.g. , a new or used product); URL information (if a website is used); base price; check in date; check out date; hotel name; hotel address; hotel location based on a map; hotel star rating; customer ratings; user reviews; flight number; airline; departure date and time; arrival date and time; car rental pickup date and time; car rental drop-off date and time; car rental supplier; car rental provider; car rental category; car rental type; car make and model; number of travelers; number of passengers; number of bags; number of large bags; number of small bags; departure airport; layover airport; arrival airport; activity name; activity start date and time; activity end date and time; activity location; tour name; tour date; shipping from location; room type; number of beds; bed type; number of guests; number of adults; number of children; number of nights; room category; room name; cancellation policy; and latest cancellable date.

If the target e-commerce interface 2102 is supported by the application 100, the application 100 may automatically compare at least one item listing of the target merchant store with the item listing of at least one competing merchant store in order to determine whether a lower price exists for the product(s) and/or service(s). More specifically, the application server 110 may compare whether the item listing from at least one competing merchant store has a lower item price than the item listing from the target merchant store for the same product(s) and/or service(s). If the target merchant store’s item listing has the lowest item price, the application 100 may remain hidden to the user. However, if the item listing from at least one competing merchant store has a lower item price, the application 100 may automatically retrieve the lower-priced item listing(s) and display a message on the client device 101 in order to alert the user.

In at least one embodiment, the present technology may automatically retrieve an item listing from at least one competing merchant store that is similar to, but not the same as, the item listing from the target merchant store. More specifically, if a lower-priced item listing from at least one competing merchant store is found, it will typically be an exact match of the product or service that the user is viewing in the target merchant store (for example, an exact match may be matching the item codes of two televisions). However, a competing merchant store may not have the exact product or service, but does have a “similar” product or service (or has a lower-priced similar product or service in addition to the exact product or service). For example, a television brand may sell one unique model through Walmart and another unique model through Best Buy, but said models may have slight differences (such as one model including an additional HDMI port) and as such, have different item codes. Accordingly, if a “similar” item listing from at least one competing merchant store has a lower item price than the item listing of the target merchant store, the application 100 may automatically retrieve the “similar” item listing(s) to display on the client device 101 in order to alert the user.

The application 100 may detect, capture, calculate, compare, and retrieve the item listing(s) within a background process, hidden to the user. In one embodiment, the application 100 may prompt the user to ‘manually’ detect, capture, compare, and/or retrieve the item listing(s), via an interactive button.

As illustrated in Figures 13 - 14, when the application 100 determines that the item listing(s) from the at least one competing merchant store has a lower item price than the target merchant store, the application 100 may automatically display said item listing(s) within the target e-commerce interface 2102. This ‘display’ within the target e-commerce interface 2102 may be facilitated by a plug-in or extension 2103 that may appear dormant until being ‘activated’ by the application 100 and automatically “injected” into the native application or browser. More specifically, upon retrieval of a lower-priced item listing(s), the dormant or embedded extension 2103 may be automatically activated and displayed into the already loaded target e-commerce interface 2102. Moreover, the extension 2103 may be slid or injected into the target e-commerce interface 2102 in order to alert the user to possible savings at another store.

The extension 2103, may comprise at least one interactive user interface element, such as a button, take various shapes and colors, and be injected into different areas of the target e-commerce interface 2102 in order to best alert the user to possible savings. The extension 2103 may include a price compare message 2301 to alert the user that the application 100 has provided at least one lower-priced item listing. The price compare message 2301 may comprise an interactive button to allow the user to select the lower- priced item listing. As illustrated in Figure 14, if the user is viewing multiple item listings in the target e-commerce interface 2102, the application 100 may retrieve and display multiple extensions 2103 injected therein. Figure 13 also includes a similar injected extension button of “Save $48.60” that may be selected to launch the extension 2103. The application server 110 may retrieve and display the item listing of the at least one competing merchant store directly into the target e-commerce interface 2102. If the application 100 retrieves multiple item listings from the at least one competing merchant store, it may rank the retrieved item listings sequentially from lowest item price to highest item price. This may allow the user to “swipe” through the ranked item listings of the at least one competing merchant store, for example one by one, to view all options before making a selection. Moreover, if the user is shopping on a client device 101 that comprises a small screen (e.g., cell phone), it may not be optimal to display all ranked item listings due to the small-screen size. Upon navigation to a different item listing, the application 100 will repeat the above steps.

As illustrated in Figure 14, the application 100 may automatically display at least one extension 2103, each representing a retrieved item listing of an associated competing merchant store. Each extension 2103 may comprise an interactive button, such as the price compare message 2301 in order to prompt the user to select the displayed item listing of the at least one competing merchant store. Upon selection of the price compare message 2301 button, the application 100 may automatically redirect the user to the competing e- commerce interface 2202 (illustrated in Figure 16) associated with said competing merchant store, in order to initiate an e-commerce purchase.

As illustrated in Figure 13, in another embodiment, the application 100 may automatically display the extension 2103 representing a retrieved item listing of the associated competing merchant store. The extension 2103 may comprise an interactive button, such as the “Add to Cart” button 2302 in order to prompt the user to select the displayed item listing of the at least one competing merchant store. By selecting the “Add to Cart” button 2302, representing the lower-priced item listing of the associated competing merchant store, the application 100 may automatically apply the item listing into the associated competing e-commerce interface 2202, in a background process hidden to the user.

More specifically, the selected item listing of the competing merchant store may be automatically applied into the associated competing e-commerce interface 2202, in a background process that may be hidden to the user, to allow the user to continue the shopping experience prior to initiating an e-commerce purchase. The competing e- commerce interface 2202 may comprise the competing merchant store’s website, including a mobile website, or a native application, including a native mobile application. Accordingly, for purposes of clarity and without limiting the scope of the present technology, this technology will be described with reference to the competing e-commerce interface 2202 being in the form of a desktop website. However, it is emphasized that the competing e-commerce interface 2202 of the present technology can be operable in addition to and other than a desktop website. Moreover, the competing e-commerce interface 2202 may be in the form of a native mobile application, a mobile website, or a desktop application.

The application 100 may apply the selected item listing of the at least one competing merchant store into the associated competing e-commerce interface’s 2202 “virtual shopping cart” and display a reference to the applied item listing(s) within the target e- commerce interface 2102. For example, and as illustrated in Figure 15, the application 100 may comprise a cart message 2303 indicating that the application 100 has applied at least one item listing into the competing e-commerce interface 2202 of the at least one competing merchant store. The cart message 2303 may comprise listing item information, such as the item price and the name of the competing merchant store. In one embodiment, the application 100 may prompt the user to view the “virtual shopping cart”, via an interactive user interface element, such as a “See Cart” button 2304, in order to view all the selected item listings contained in each “virtual shopping cart”.

In another embodiment, the application 100 may apply the selected item listing(s) into the associated competing e-commerce interface’s 2202 “electronic shopping cart” and/or “checkout area”. As such, if the user independently (for example, not via the application 100) navigates to the associated competing e-commerce interface 2202, the selected item listing(s) may still be applied therein. A “checkout area” may at least partially comprise a web or native application ‘page’ wherein the user is able to initiate an e- commerce purchase.

As also illustrated in Figure 15, the application 100 may prompt the user to redirect to the competing e-commerce interface 2202 to initiate an e-commerce purchase. The application 100 may prompt the user to redirect to the associated competing e-commerce interface 2202, via an interactive user interface element, such as a “Checkout” button 2305, in order to initiate an e-commerce purchase.

As illustrated in Figure 16, upon redirection to the competing merchant interface 2202, the user may complete his/her e-commerce purchase. If the user has selected item listings from multiple competing merchant stores, the application 100 may direct the user to each competing e-commerce interface 2202 in order to complete all e-commerce purchases for the selected item listings. In one embodiment, after completing an e-commerce purchase at a competing e-commerce interface 2202, the application 100 may redirect the user back to the target e-commerce interface 2102 and prompt the user to ‘manually’ direct, via an interactive button, to the next competing e-commerce interface 2202 to initiate an e- commerce purchase therein.

Turning to Figure 17, a flow chart 1700 depicting operative logic of a software embodiment of the present technology, which optimizes a user experience is disclosed. While the disclosed embodiment contemplates coupons and cash back for purposes of facilitating disclosure, the inventive method may be employed with any user benefit contemplated by the disclosure of this technology. The software embodiment may comprise a mobile application, desktop application, or web extension, as disclosed and described herein. According to 1701, a user initiates a shopping trip by accessing a website or mobile application to engage in an e-commerce transaction as previously disclosed. The user may accomplish this via a web browser or via a merchant’s native retail application. According to 1702 the user determines which product or service the user will purchase and adds the product or service to a cart, in accordance with previously disclosed embodiments.

According to 1703, the user then navigates to the cart or other checkout interface to begin the transaction. In accordance with previously disclosed embodiments, a software embodiment of the present technology may operatively monitor a URL or page elements as the user navigates the e-commerce interface in order to determine when the user has landed on the page which will begin the transaction. The page elements may comprise keywords, images, or logos that are operatively associated with a checkout interface. Assuming coupons are available, as per 1704, the software embodiment of the method may be operative to initiate a ruleset to identify and apply benefits (coupon codes as depicted in the Figure) in a background process that is not visible to the user, and without prompting the user, as at 1705.

As the software embodiment conducts the identification and application of coupons in a background process 1705, the embodiment may be further operative to determine whether the merchant is affiliated with a cashback benefit 1707, as previously disclosed herein. If so, then the embodiment may present a modal image to the user inquiring as to whether the user would like to obtain coupons or cashback 1709. If the user affirmatively responds to the call to action 1710, then an expedited modal for applying coupons can be presented to the user 1711. Such an expedited modal may include an indication to the user that benefits are being identified and/or applied while the step 1705 completes operation in the background. If step 1705 has already completed by the time the user requests application of a benefit, then presenting a modal to the user 1711 may further include the step of presenting the modal to the user for a predetermined time period, which in a preferred embodiment, may be approximately 3-4 seconds. Accordingly, the user is left with the impression that step 1705, identification and application of coupons, was conducted in a much shorter time frame then may have been necessary. Furthermore, in the event that step 1705, identification and application of coupons, is completed prior to the user affirmatively responding to the call to action 1710, then the step of presenting an expedited modal for applying coupons to the user 1711 will also serve the purpose of assuring the user that this step was not inadvertently skipped.

Once the modal is presented to the user 1711, then the user may continue the transaction, substantially as disclosed in previous embodiments. This may include presentation of further modals to indicate how much money the user saved by utilizing the present technology. Alternatively, if no benefits were available, a further modal may indicate to a user that the present technology saved the user the time involved to manually search for, and confirm, the fact that no benefits were available with respect to the particular transaction.

Of course, the particular circumstances of a given transaction may not present the same set of factors as are disclosed in Figure 17, which is intended to be exemplary. If no coupons are available at step 1704, then the technology may continue on to ascertain and select other benefits, such as cashback, price comparison, and/or presentation of loyalty perks, substantially as disclosed in other embodiments. Additionally, if the merchant is not affiliated at step 1707, then no cashback may be available for a user. As such, the operative logic would proceed to step 1708, in which the modal presented to the user does not indicate that cash back is available. The call to action presented to the user, as at step 1710, would similarly not indicate that cash back is available.

In addition, the present technology provides for additional functionality to facilitate purchase or checkout from anywhere within an e-commerce website, including completing purchases from a different website, without having to visit a designated check-out portion of the e-commerce website. For example, upon a detection that a user is on a product landing page or that a user has added a product to a virtual shopping cart, a checkout interface may be automatically displayed in a pop-up, pop-over, modal window, or the like. The checkout interface may include a price for the product based on application of benefits, as discussed above. Accordingly, maximum benefit may be accorded to the user without the user ever having to reach a checkout page. In some websites, to compete a purchase or checkout process, the user must first add items to the virtual shopping cart, then proceed to a checkout page, and then proceed through the checkout process for the website. The checkout process may involve many steps and, in some cases, require the presentation of multiple webpages and input boxes before the transaction may actually be completed. Each step requires additional computing resources, including display resources, processing resources, input/output resources for each click and keyboard interaction, etc. With the present technology, these resources may be conserved by providing for the checkout process to be completed without having the user interact with all the pages required for a more traditional checkout. In addition, the discounts, coupon codes, cash back incentives, and other features described above may also be automatically applied — resulting in further resource conservation and reduced time to completion of a purchase.

Figure 18 is an exemplary user interface 1800 for an E-Commerce Site A with which the present technology may be implemented. The user interface 1800 may be a webpage for an E-Commerce Merchant A, which may be any type of merchant offering e-commerce purchases, such as Amazon.com, Macys.com, or the like. As an example, the user interface 1800 may be similar to the user interface of Amazon.com depicted in Figure 13 and discussed above. The user interface 1800 may be a product landing page for a particular product.

The user interface 1800 includes a page title section 1802 that identifies the E- Commerce Merchant A (e.g., Amazon.com). The user interface 1800 may also include additional site navigation section 1804 with selectable elements to navigate to different sections of the website. A product name section 1806 may also be included in the user interface 1800. The product name section includes the name of the product that is being displayed in the user interface 1800. A product image(s) section 1808 and a product description page 1810 may also be displayed in the user interface 1800. The product image(s) section 1808 displays one or more images of the product that is being offered for sale in the user interface 1800. The product description section 1810 provides a description of the product being offered for sale. A price information section 1814 may also be included in the user interface 1800. The price information section 1814 includes the price of the product being offered for sale and may also include information regarding shipping, taxes, or other factors that affect the total price of the product. The price information section 1814 may also include a selectable user interface element (e.g., button) 1816 to add the product to the virtual shopping cart. The product description section 1810 and/or the price information section 1814 may also include a unique identifier for the product, such as a stock-keeping unit (SKU), UPC, or other identifier for the product. In some examples, the unique identifier for the product may be in the URL or URI for the webpage. In addition, a related products section 1812 may also be displayed that includes addition products that are related to the product currently displayed.

Using the Amazon.com interface 2102 shown in Figure 13 as an example of a user interface 1800, the Amazon logo is displayed in the page title section 1802, and site navigation elements such as “Departments” and “Today’s Deals” are displayed in the site navigation section 1804. The interface 2102 also includes a product title (i.e., PLUSSINO Telescopic Fishing Rod and Reel Combos FULL KIT...), product images (i.e., the images of the fly rod and reel shown on the left-hand side), and a product description (i.e., the details shown to the right of the product images) that detail the fishing rod and reel product that is offered for sale in the interface 2102. The interface 2102 also includes price information and an option to add the product to the virtual shopping cart.

Figure 19 is an exemplary user interface 1800 including a checkout modal window 1902 prior to completion of a checkout process via the present technology. The checkout modal window 1902 facilitates the purchase of the product (e.g., checkout process) without the user ever having to navigate to the checkout page of the e-commerce site for Merchant A. The checkout modal window 1902 may be displayed based on the occurrence of a variety of triggers or conditions being met. As an example, an “Add to Cart” action may be detected, which may trigger the display of the checkout modal window 1902. For instance, the present technology may detect when a user has selected a user interface element to add the currently displayed product to the virtual cart. This may be detected by monitoring changes in URLs, monitoring changes in user interface elements displayed in the user interface 1800, and/or monitoring transmitted communication. In other examples, display of the checkout modal window 1902 may be triggered based on an amount of time spent on the current page. For example, if the user has been on the product landing page for a certain amount of time (e.g., 5 seconds, 10 seconds, 30 seconds, 1 minute, etc.), the checkout modal window 1902 may be triggered. In other examples, the checkout modal window 1902 may be displayed upon detecting that the page being displayed is a product landing page.

In still other examples, the checkout modal window 1902 may be displayed upon the selection of a user interface element. For instance, the application may detect that the user is on a product landing page and also identify the product being displayed and offered for sale, as discussed above. A selectable user interface element may then be injected into the user interface 1800, such as the injected extension elements 2103 shown in Figure 14 or the injected extension element of “Save $48.60” shown in Figure 13. Upon selection of that extension element, the checkout modal window 1902 may be displayed. An icon for a plug in for the application may also be displayed in or by the web browser, such as icon plug-in 1201 discussed above. When the icon is selected, the checkout modal window 1902 may be displayed.

The checkout modal window 1902 may include various types of information to facilitate the checkout process. For example, the checkout modal window 1902 may include a company identifier 1904 of the company operating the extension or application that is providing the checkout modal window 1902. In the example depicted, the company is Piggy, which in this example is not Merchant A. The company or entity operating the extension or application may be referred to as the operating entity. The checkout modal window 1902 may also include a checkout prompt 1906 that explains the purpose of the checkout modal window 1902 and provides additional context for the checkout modal window 1902. In the example depicted, the checkout prompt is “Want to checkout now?”. The checkout modal window 1902 also includes product details 1908 for the product to be purchased. The product details 1908 may include an image, title, and/or other information about the product that is to be purchased. The checkout modal window 1902 also includes a final price 1910 for the product after all benefits have been applied. For example, as discussed above, the application 100 may analyze and test coupon codes, discounts, and apply other incentives such as cash back in a background process that may not be seen by the user. The final price 1910 is the price of the product after all the applicable discounts have been applied so that the user may achieve the maximum benefit and the lowest possible price. The final price 1910 may also include applicable taxes and shipping charges.

The checkout modal window 1902 also displays additional information to facilitate the checkout process, such as payment information 1912, shipping address 1914, and shipping details 1916. The payment information 1912 may include a preferred credit card number for the user. The shipping address 1914 may include a preferred shipping address for the user. The payment information 1912 and the shipping address 1914 may be retrieved by the application 100 from a database or resource. For instance, the application server may include a database that stores payment information and shipping addresses for the users. That payment information and shipping address may be retrieved for the particular user when the checkout modal window 1902 is displayed. The application server may also retrieve that data from another service. For instance, in some examples, the application server may not directly store payment information for security purposes. Instead, the application server may retrieve the payment information from another service. The checkout modal window 1902 may also display additional shipping information 1916, such as the estimated arrival time and type of shipping (e.g., type of carrier, type of delivery (air, ground, etc.)). The payment information 1912, shipping address 1914, and/or additional shipping information 1916 may be selectable or include selectable elements that allow for the user to change the information displayed and ultimately used for purchase.

The checkout modal window 1902 also includes a selectable checkout element 1918. Upon selection of the checkout element 1918, the application 100 completes the checkout process for the user in the background. The checkout element 1918 may also display the amount of money that will be saved by completing the checkout. In some examples, the checkout process is completed without any further input from required from the user. Completion of the checkout process may be completed by the application server or by the client device on which the checkout modal window is displayed. For example, the application server may process the purchase with the payment information and shipping address that are displayed in the checkout modal window 1902. In some examples, to complete the checkout process, the application server may automatically enter the appropriate information in the checkout pages of the merchant, including entering discount and coupon codes. Thus, for the example depicted in Figure 19, the application server processes the checkout by automatically processing the checkout pages of e-commerce site A for Merchant A.

The application server is able to process the checkout pages in the background and without display of the pages. By having the checkout process be performed in the background by the application server, computing resources of the client device may be conserved (e.g., display resources, processing resources, etc.), which allows for thin clients with limited resources to still utilize the present technology. In addition, the application server generally has higher performance computing components than the client device. Accordingly, the computations and processing performed by the system as a whole are more appropriately distributed, which leads to improved overall performance of the system. While the application server is processing the checkout, a progress indicator (bar, circle, etc.) may be displayed in the checkout modal window 1902 so that the user is aware that the checkout process is progressing.

In other examples, part or all of the checkout process may be performed locally on the client device. In such examples, new windows, tabs, or instances of a web browser may be launched in the background of the client device to process the checkout pages for E- Commerce Site A. By processing the checkout pages as background processes, display resources are still conserved, and the local computing device is able to complete the process in a more computationally efficient manner.

Because different merchants and websites may have different configurations for checkout pages, the operations for completing the checkout process may be different for different merchants and/or different websites. Thus, when the selectable checkout element 1918 is selected, a checkout ruleset may be accessed for the current website. Different checkout rulesets may be generated for different websites. The checkout rulesets may form an algorithm, or provide inputs to an algorithm, that can be used to complete a checkout process for a website. The rulesets may be generated at least in part manually by having a programmer proceed through the checkout pages of a particular website and generate the ruleset. The ruleset may also be generated based on scraping or analyzing the webpages to identify the form or input elements of the webpages. Once the ruleset is generated, it may be stored for later use when a selection of a selectable checkout element 1918 is received. In other examples, the ruleset may be generated automatically, or at least partially automatically, by monitoring interactions from other users when completing checkout pages of a particular website.

By utilizing a checkout modal window 1902 to facilitate the checkout process, the user is no longer required to leave the product landing page to complete the checkout process because the checkout modal window 1902 may be displayed as an overlay or adjacent to the product landing page. While the checkout modal window 1902 has been described as a “modal window,” the term checkout modal window may include a pop-up window, a pop- over window, a panel (such as a panel similar to panel 300 depicted in Figure 8), or other similar display features.

While not depicted in the present drawings, the checkout modal window 1902 may also include additional selectable options for facilitating the purchase of the product. For example, the checkout modal window 1902 may display one or more additional payment options, such as payment options integrated with the merchant or third-party payment options, such as Amazon Pay, Google Pay, Verified by Visa, etc. The additional payment options may also include buy-now-pay-later (BNPL) options, such as those available from Affirm or Klama. When a user selects such additional payment option, the user may be prompted to enter authorization credentials (e.g., a username and password) to access the alternative payment option. In some examples, the application or extension of the present technology may store such authorization credentials and automatically log into or access the additional payment option. The checkout process may then be completed utilizing the selected additional payment option again without the user ever having to navigate to the checkout page of E-Commerce Site A.

Figure 20 is an exemplary user interface 1800 including the checkout modal window 1902 subsequent to the completion of the checkout process. After the checkout process is completed by the application server, the checkout modal window 1902 updates to confirm or display that the checkout process has been completed. For instance, upon completion of the checkout process, the checkout prompt 1906 changes to “Checkout Completed” or some other indicia or text to indicate that the checkout process has been completed. The product details 1908 and the final price 1910 may continue to be displayed in the checkout modal window 1902. The payment information 1912 may update to indicate how the payment was processed (e.g., charged to a particular credit card number). The shipping address 1914 may also update to indicate to which address the product is being shipped. The additional shipping information 1916 may continue to indicate the type of shipping and/or estimated arrival time for the product.

Figure 21 is an exemplary user interface 2500 for an E-Commerce Site B with which the present technology may be implemented. The user interface 2500 may be similar to the interface 1800 discussed above in that both user interface 2500 and user interface 1800 may display similar types of information. The user interface 2500, however, is presented by Merchant B rather than Merchant A. For instance, the user interface 2500 may be a product landing page for a product offered by Merchant B through E-Commerce Site B. As just one example, Merchant B may be Walmart where Merchant A may be Amazon.com. Like the user interface 1800, the user interface 2500 includes a page title section 2502, an additional site navigation section 2504, a product name section 2506, a product image(s) section 2508, a product description page 2510, a related products section 2512, and a price information section 2514. The price information section 2514 may also include an add to cart button 2516.

Figure 22 is an exemplary user interface including a competing checkout modal window 2602 prior to completion of a checkout process. The competing checkout modal window 2602 may be displayed based on the occurrence of a trigger or a condition, which may include the same or similar triggers or conditions discussed above relating to checkout modal window 1902. The competing checkout modal window 2602 includes information about the product being viewed in user interface 2500 but from a different merchant. For instance, where the user interface 2500 is a product landing page for Product X displayed by Merchant B, the competing checkout modal window 2602 may include information for Product X from Merchant A. Thus, the user can see details for the product from a different merchant that may be selling the product at a lower final price after applying discounts, coupons, cash back, etc. In some examples, the product available from the competing merchant may not be the exact same product as the one offered from the merchant displaying the user interface 2500. Rather, the product from the competing merchant may be a substantially similar product, as discussed above.

The competing checkout modal window 2602 includes a competing merchant identifier 2604. In the example depicted, the competing merchant is Merchant A. The competing checkout modal window 2602 may also include savings amount indicator 2606 and a cash back indicator 2608. The savings amount indicator 2606 may be displayed as an explanatory phrase such as “Will save you [$]” where the [$] is the amount of money that will be saved as compared to the purchasing from the E-Commerce Site B of Merchant B. The cash back indicator 2608 may indicate a percent or amount of cash back that is included in the savings amount.

The competing checkout modal window 2602 also includes a competing price analysis 2610. The competing price analysis 2610 includes a price analysis of the product from the competing merchant. The price information for the product from the competing merchant (e.g., Merchant A) may be determined utilizing any of the methods discussed above, and the price information may be based on applying available discounts, coupon codes, cash back offers, etc. to provide the maximum benefit to the user. The competing price analysis 2610 may include the base item price from the competing merchant, the shipping costs, the voucher or coupon discounts, the cash back amount, taxes, and the final or best price, which is the total price after application of shipping, taxes, discounts, and cash back. The competing price analysis 2610 may also show an estimated arrival date for delivered products.

The checkout modal window 2602 may also display payment information 2612 and the shipping address 2614 that are to be used for completing a checkout process. The payment information 2612 and the shipping address 2614 may be selectable such that the user may change the information if desired. The payment information 2612 and the shipping address 2614 may be retrieved and accessed as discussed above.

The checkout modal window 2602 also includes a selectable checkout element 2618, which may also display the total savings amount. Upon selection of the checkout modal window 2602, the application 100 completes the checkout process from the competing merchant (e.g., Merchant A in this example). To complete the checkout process, the application server may navigate to the competing merchant’s website (e.g., E-Commerce Site A) to process the checkout pages. The process may include adding the competing product to a virtual cart on the competing merchant’s website and then proceeding to the checkout pages of the competing merchant’s website. To complete the checkout process, the application server accesses the ruleset for the competing merchant’s website and processes the checkout pages according to the accessed rulesets. In other examples, a portion or all of the checkout process may be performed on the local device in the background, as discussed above.

Figure 23 is an exemplary user interface 2500 including the competing checkout modal window 2602 subsequent to the completion of the checkout process. Once the checkout process has been completed by the application and/or application server, the checkout modal window 2602 is updated to reflect the completed purchase. For instance, upon completion of the checkout process, a “Checkout Completed” indicator 2620 or some other indicia or text to indicate that the checkout process has been completed is displayed. Product details 2608 and a final price 2611 may also be displayed in the checkout modal window 2602. The payment information 2612 may update to indicate how the payment was processed (e.g., charged to a particular credit card number). The shipping address 2614 may also update to indicate to which address the product is being shipped. The additional shipping information 2616 may be displayed to indicate the type of shipping and/or estimated arrival time for the product. The checkout modal window 2602 may then be closed by the user by selection of the “x” indicator or similar element configured to close the checkout modal window 2602.

Figure 24 depicts another example of a checkout modal window 2603. The checkout modal window 2603 displays much of the same information and elements as the checkout modal window 2602 depicted in Figure 22. The checkout modal window 2603, however, also includes an add-to-cart element 2619. The user may select the add-to-cart element 2619 to add the product in the checkout modal window 2063 to a virtual cart of Merchant A. Accordingly, the checkout modal window 2603 may facilitate checkout of the product, and also manage a virtual cart of a merchant, even a merchant different from the website being viewed by the user. Once the add-to-cart element 2619 is selected, the product is added to a virtual cart. Figure 25 depicts another example of the checkout modal window 2603 after the add-to-cart element 2619 is selected. The checkout modal window 2603 displays a virtual cart with products that have been added to the virtual cart by the user. In the example depicted, the virtual cart includes user interface elements for Product X 2620 and Product Y 2622. For each of the products in the cart, a description or image of the product is listed, a price for the product is listed, a number of products in the cart may be listed, and a selectable modifier element may be displayed. The modifier element may include a selectable element to remove the product from the cart or alter the number of products within the cart. The data for the products stored in the cart (e.g., Product X and Product Y) may be stored by the application on the client device and/or the application server. In some examples, each time a product is added to the virtual cart, the application may create a data entry indicating the product and the respective merchant from which the product is to be purchased (e.g., Merchant A). The products added to the virtual cart of the application may also be added to the virtual cart of the merchant at substantially the same time the products are added to the virtual cart via the checkout modal window 2603. In other examples, the products added to the virtual cart via the checkout modal window 2603 may not be added to the virtual cart of the merchant until a selection of the selectable checkout element 2618 is received and the checkout process is performed.

The checkout modal window 2603 includes a selectable checkout element 2618 that, upon selection, causes the application to complete the checkout process. In addition, payment information 2612 and shipping address 2614 that will be used during the checkout process may also be displayed. After the checkout process is complete, a checkout modal window such as checkout modal window 2602 in Figure 23 may be displayed to indicate the checkout process has been completed and provide information about the products purchased.

While the foregoing examples depicted in Figures 18-25 and described above have been presented with respect to web browser example, the present technology may also be utilized in mobile applications or “apps,” such as described above with respect to Figures 7- 11. For instance, the present technology may detect that a user has navigated to a product landing page within an app and begin the processes discussed herein. The checkout modal window and/or competing checkout modal window may be presented as a side pane or an overlay pane that slides in from the periphery of the app, among other types of presentations.

Figure 26 depicts a method 2700 for facilitating e-commerce transactions by completing a checkout process via a checkout modal window. The operations of method 2700 may be performed by an application, such as an extension, as discussed above. The application may operate on a client device of the user that is being used to navigate the web or navigate an app on the client device. The application may also operate on an application server that is in communication with the client device. Accordingly, operations performed by the application may be performed on the client device and/or the application server. The application may be operated by an entity that is different from the merchants selling the products described herein. For instance, the application may be operated by an entity similar to the present applicant, Piggy.

At operation 2702, a product on a product landing page of a website is identified. The product may be identified by parsing or analyzing the URL or URI of the product landing page to which the user has navigated. In addition or alternatively, page elements of the product landing page may be analyzed to determine the product on the product landing page. For example, the product may be identified by a UPC or SKU listed on the webpage, as discussed above. The page elements may be located in the different sections of the landing page, such as the different sections discussed above with respect to Figure 18. In some examples, only a subset of the page sections, such as the product images, product description, and price sections of the pages are analyzed to identify the product. The website may be operated by an entity or merchant that is different than the entity operating the application.

At operation 2704, the same or similar product available from one or more additional entities is identified. The identification of products available from the one or more additional entities may include querying a database including product listings from multiple entities. The database may be populated by a service that aggregates product listings. For example, merchants may be report product listings to one or more services that can be accessed by the application or utilized to populate a database. The product listings from the merchants may be updated on a regular interval, such as once per day. The database may also include a pointer or location information, such as web address, to find the product landing page from the respective entity. The database may also list a current price for the product for the respective entity.

At operation 2706, at least one benefit to be applied to the purchase of the product is identified. The benefit may be a coupon code, cash back, or any of the other types of benefits discussed above. The at least one benefit may be identified according to any of the operations described above. Different benefits may also be identified for different entities. For example, each entity may accept different types of coupon codes or have different cash back options.

Further, the identification of benefits may be based on the particular user that using the application. For instance, the particular user may have loyalty rewards or cash back rewards with certain merchants based on the user previously registering with such merchants. In addition, the particular user may have additional third-party benefits based on the user’s previous registrations or subscriptions to such benefits. For example, the user may have a subscription to a shipping-savings program, such as ShopRunner, that provide for free or discounted shipping. The user may have pre-registered these additional third- party benefits with the application or configured the user profile to indicate these additional third-party benefits. Additional payment options may also be accessed, such as BNPL options that may be displayed in the checkout modal window and used to complete the purchase of the product.

At operation 2708, the at least one benefit is applied to determine the maximum benefit entity for which the product may be purchased. For example, the benefit may be applied for each entity that is offering the product for sale. The entity that ultimately would provide the lowest price for the product after application of the at least one benefit is identified as the maximum benefit entity. The application of the benefit may include actual testing of the coupon codes or by performing a calculation based on the assumption that the coupon codes will be accepted. In some cases, the maximum benefit entity is the same entity operating the website that is displaying the current product landing page. In other words, the page that the user has already navigated to is offering the lowest price and there would be no benefit in purchasing from another merchant.

At operation 2710, a checkout modal window is displayed. The checkout modal window may be displayed as an overlay of the product landing page being viewed by the user and/or as a pane or panel, as discussed above. Where the maximum benefit entity is the same entity that is operating the website displaying the product landing page (e.g., the website is E-Commerce Site A and the maximum benefit entity is Merchant A), the displayed checkout modal window may be similar to the checkout modal window 1902 discussed above with respect to Figures 19-20. Where the maximum benefit entity is a different entity than the entity operating the website displaying the product landing page (e.g., the website is E-Commerce Site B and the maximum benefit entity is Merchant B), the displayed checkout modal window may be similar to the competing checkout modal window 2602 discussed above with respect to Figures 22-25. In either case, the checkout modal window includes the display of a selectable checkout user-interface element that may be selected by the user to complete the purchase of the product from the respective entity.

Displaying the checkout modal window may also include accessing additional data for the user, such as a preferred payment method and/or shipping details, such as a shipping address. The additional data may be stored in a database or accessed from another service. For instance, credit card information for a particular user may be accessed through a credit card storage service. The additional data for the user may be stored in a user profile or otherwise previously configured in the application by the user.

The checkout modal window may be displayed in response to the occurrence of a variety of triggers or conditions being met. The conditions or triggers may include at least those discussed above with respect to Figure 19. Accordingly, operation 2710 may also include operations to monitor for the occurrence of on the conditions or triggers and detecting when such conditions or triggers are met.

At operation 2712, one or more virtual cart interactions may be received where such functionality is provided in a checkout modal window. For example, the virtual cart interaction may include receiving a selection of an add-to-cart element of the checkout modal window. Based on a selection of the add-to-cart element, the product may be added to a virtual cart managed by the application and/or a virtual cart of the corresponding merchant. The virtual cart interactions may also include a selection of a modifier element, displayed in a checkout modal window, to modify the number of products within the virtual cart.

At operation 2714, a selection of the checkout user interface element is received. The selection may be received based on a user clicking, touching, or otherwise selecting the checkout user interface element.

At operation 2716, in response to receiving the selection of the checkout user interface element, a background process is executed to complete the purchase of the product. The background process may be completed without any further or additional input from the user. In addition, the background process may be completed without displaying a checkout page of the website of the maximum benefit entity. Accordingly, the user may not see any additional operations being performed by the application until the purchase or checkout process is complete. Additional details regarding the background process are discussed further below with respect to Figure 27. At operation 2718, once the background process has finished and the purchase process is complete, the checkout modal window is updated to convey that the checkout process has completed. The updated checkout modal window displayed in operation 2718 may be similar to the checkout modal windows depicted in Figures 20 and 23.

Figure 27 depicts an example method 2800 for executing a background process to facilitate an e-commerce transaction. Similar to the operations in method 2700 described above, the operations of method 2800 may also be performed by the application, such as an extension, operating on a client device and/or an application server. At operation 2802, a checkout ruleset for completing a checkout or purchase process for the maximum benefit entity may accessed. The checkout rulesets may be stored at the application server, at the client device, and/or at another storage location in communication with the client device and/or the application server. Different checkout rulesets may be generated for different websites and thus different entities. For instance, a checkout process on Amazon.com may be substantially different from a checkout process on Walmart.com or Macys.com. The checkout rulesets may form an algorithm, or provide inputs to an algorithm, that can be used to complete a checkout process for a particular website. For instance, the rulesets may include scripts, such as a script programmed in Python or similar platform. Because different websites have different checkout processes and sequences of pages and/or steps to complete a purchase, the checkout rulesets capture the checkout progression for each different website. For instance, the ruleset may include the necessary user information (e.g., name, address, age, contact information, payment information, etc.) that is required to complete the checkout process.

The rulesets may be generated automatically or at least in part manually by having a programmer proceed through the checkout pages of a particular website and generate the ruleset. For instance, website may be analyzed or scraped to extract all the input fields or form tags from the checkout webpages. The input fields or descriptors along with the input method types may also be extracted. Different HTML parsing tools, such as Beautiful Soup or similar tools, may be utilized to parse the webpages. The identified fields, their tags, and/or their locations may then by used to generate the ruleset or script for automatically filling the form elements on the checkout pages with data for the purchase and the user. Execution of the script may use any suitable platform and may utilize a browser simulator, such as Selenium or other similar tools. Once the ruleset is generated, it may be stored for later use when a selection of a selectable checkout element is received. In other examples, the ruleset may be generated automatically, or at least partially automatically, by monitoring interactions from other users when completing checkout pages of a particular website. Where the ruleset includes a script or similar algorithm/program, the operations 2804-2814 discussed below may be performed as part of running or executing the ruleset.

At operation 2804, payment information for the user is accessed. The payment information may include credit card information or alternative payment information for the user, such as a BNPL provider or third-party payment platform (e.g., Amazon Pay, Google Pay, etc.). Where a third-party payment platform or BNPL provider is utilized, accessing payment information may also include accessing login or authorization credentials for user’s account with the third-party payment platform or BNPL provider. The payment information may be accessed from a database or service storing the information. The payment information may be the same information accessed and displayed in the checkout modal window.

At operation 2804, shipping details or other identifying information for the user are accessed. These details may include the same shipping details accessed and displayed in the checkout modal window. The types of shipping details, payment information, and other user data may be based on the checkout ruleset for the maximum benefit entity. For example, the checkout ruleset may set forth the types of data that are required for completing the checkout process on the website of the maximum benefit entity. The other user data accessed may also include login or authorization credentials for the website of the maximum benefit entity and/or other third parties for which benefits are being utilized (e.g., shipping subscription entities such as ShopRunner).

At operation 2808, the application navigates to the product page of a maximum benefit entity. The product page is for the product identified that is to be purchased. Navigation to the product page may be based on the identification of the product in operation 2704 of method 2700 where identification of the product from entity may also include an identification of the location or web address of the corresponding product page. Navigating to the product page may occur in a background operation or in a browser or browser tab launched in the background. The navigation may be performed on the client device or on the application server.

At operation 2810, the product is added to the virtual cart if the ruleset for the website of the maximum benefit entity requires such an operation to be performed on the product page prior to the checkout process. As an example, where the application is managing a virtual cart of products, such as shown in checkout modal window 2603 in Figure 25, the products in the virtual cart may be added to the virtual cart of the merchant (if they have not been previously added to the virtual cart of the merchant). The purchase process continues at operation 2812 where the fields on the checkout pages of the websites are automatically populated, according to the ruleset, with the payment information for the user, the shipping details for the user, and/or other user information accessed in operations 2804 and 2806. Populating the checkout fields may also include progressing through several pages of the checkout process if required by the website. In addition, populating the checkout fields may also include applying the coupon codes or other identified benefits, such as those benefits described above and/or identified in method 2700. Further, populating the checkout fields may also, or alternatively, include automatically logging into the user’s account with the maximum benefit entity (e.g., by filling in a username and password in the appropriate fields). By automatically logging into the user’s account, other checkout fields may be automatically populated by the website itself and additional benefits may be accessed. Once the checkout fields are populated, the checkout is submitted to complete the purchase at operation 2814.

In some examples, a particular merchant may provide for non-graphical user interface APIs or backend data exchanges that allow for the application to provide the purchase data (e.g., payment information, shipping information, product information, etc.) to the merchant or merchant website without having to fill in fields on webpages. Accordingly, in such examples, operations 2810 and/or 2812 may include providing information to the merchant via the interface provided by the merchant. Whether such an interface exists and how to interact with the interface may be stored in the ruleset for the merchant.

While the methods 2700 and 2800 have been described as being performed from a product landing page, the methods may be executed from any web page or app interface that displays information about a product. For instance, where the product information is sufficient for the present technology to identify the product, a checkout modal window may be displayed or presented to facilitate checkout from any website. Accordingly, in some examples, checkout or purchase of a product may be facilitated even from webpages that are not offering a product for sale but are instead merely describing the product, such as a product review. For instance, the application, such as a browser extension, may identify a product or products on a webpage. A checkout modal window may be displayed automatically or in response to a selection of user interface element (e.g., an extension icon or an injected user interface element). The user may then automatically complete the checkout by merely selecting the checkout element from the checkout modal window. The purchase process may then be completed with maximum benefit entity. Thus, the present technology is able to facilitate e-commerce transactions even where the currently viewed website has no e-commerce capabilities. In addition, for pages with multiple products, multiple checkout modal windows may be generated, or the checkout modal window may include different checkout elements or checkout options for purchasing one or more of the products displayed on the page.

Since many modifications, variations and changes in detail can be made to the described preferred embodiment of the technology, it is intended that all matters in the foregoing description and shown in the accompanying drawings be interpreted as illustrative and not in a limiting sense. In addition, the term exemplary as used herein is intended to convey an example, not that any particular example is necessarily the best or most desirable example. Further, as used herein and in the claims, the phrase “at least one of element A, element B, or element C” is intended to convey any of: element A, element B, element C, elements A and B, elements A and C, elements B and C, and elements A, B, and C.

In addition, some aspects of the present disclosure are described above with reference to block diagrams and/or operational illustrations of systems and methods according to aspects of this disclosure. The functions, operations, and/or acts noted in the blocks may occur out of the order that is shown in any respective flowchart. For example, two blocks shown in succession may in fact be executed or performed substantially concurrently or in reverse order, depending on the functionality and implementation involved. Moreover, while different examples and embodiments may be described separately, such embodiments and examples may be combined with one another in implementing the technology described herein.

Thus, the scope of the invention should be determined by the appended claims and their legal equivalents.

Claims (20)

CLAIMS What is claimed is:

1. A method for facilitating an e-commerce transaction, the method comprising: monitoring at least one of a URL or a page element to determine that a user has navigated to a product landing page, for a product, of a website; upon determining that the user has navigated to the product landing page, identifying and applying at least one benefit relative to a purchase of the product; after identification and application of the at least one benefit, displaying a checkout modal window, wherein the checkout modal window displays: a price for the product after application of the at least one benefit; and a selectable checkout user-interface element; receiving a selection of the checkout user-interface element; in response to receiving the selection of the checkout user-interface element, executing a background process to complete the purchase of the product without requiring additional input from the user or display of a checkout page on the website.

2. The method of claim 1, wherein the product landing page is provided by a first merchant, and the price for the product is provided for a second merchant.

3. The method of claim 2, wherein the background process completes the purchase via a website of the second merchant.

4. The method of claim 1, further comprising, upon completion of the purchase of the product, updating the checkout modal window to reflect that the purchase has been completed.

5. The method of claim 1, wherein the step of identifying and applying at least one benefit is conducted as another background process that is not displayed to the user.

6. The method of claim 1, wherein the page element comprises at least one of a keyword or an image.

7. The method of claim 1, wherein the at least one benefit comprises a coupon code operative to reduce the price of the purchase selected by the user.

8. The method of claim 1, wherein the at least one benefit comprises a cashback percentage provided from a merchant to the user relative to the purchase selected by the user.

9. The method of claim 1, wherein the checkout modal window is displayed on a local device of the user and the background process is performed by an application server in communication with the local device.

10. A method for facilitating an e-commerce transaction, the method comprising: identifying, by an application operated by a first entity, a product on a product landing page of a website operated by a second entity; identifying, by the application, a same or similar product available from additional entities; accessing, by the application, at least one benefit to be applied to a purchase of the product from at least one of the second entity or the additional entities; applying, by the application, the at least one benefit to determine a maximum benefit entity from which the product may be purchased; displaying, by the application, a checkout modal window, wherein the checkout modal window includes a price for the product from the determined maximum benefit entity after application of the at least one benefit, and a selectable checkout user-interface element; receiving, by the application, a selection of the checkout user-interface element; and in response to receiving the selection of the checkout user-interface element, executing, by the application, a background process to complete the purchase of the product from the maximum benefit entity without requiring additional input from the user or display of a checkout page of a website of the maximum benefit entity.

11. The method of claim 10, wherein executing the background process includes accessing, from a plurality of checkout rulesets, a checkout ruleset for the website of the maximum benefit entity and completing the purchase of the product based on the checkout ruleset.

12. The method of claim 11, wherein the checkout ruleset includes a script, and completing the purchase of the product includes executing the script.

13. The method of claim 10, wherein executing the background process causes the application to perform a set of operations including: accessing payment information for a user; accessing shipping details for the user; populating checkout fields of checkout pages with the accessed payment information and shipping details; and submitting the populated checkout fields to complete the purchase of the product.

14. The method of claim 10, wherein the maximum benefit entity is the second entity.

15. The method of claim 10, wherein the maximum benefit entity is a third entity that is different from the first entity and the second entity.

16. The method of claim 10, wherein the checkout modal window further displays a payment option for a third-party payment platform.

17. The method of claim 10, wherein the checkout modal window is displayed in response to detecting that the product has been added to a virtual cart of the website operated by the second entity.

18. A system for facilitating an e-commerce transaction, the system comprising: a processor; and memory storing instructions for an application that when executed cause the system to perform a set of operations comprising: identifying, by an application operated by a first entity, a product on a product landing page of a website operated by a second entity; identifying, by the application, a same or similar product available from additional entities; accessing, by the application, at least one benefit to be applied to a purchase of the product from at least one of the second entity or the additional entities; applying, by the application, the at least one benefit to determine a maximum benefit entity from which the product may be purchased; displaying, by the application, a checkout modal window, wherein the checkout modal window includes a price for the product from the determined maximum benefit entity after application of the at least one benefit, and a selectable checkout user-interface element; receiving, by the application, a selection of the checkout user-interface element; and in response to receiving the selection of the checkout user-interface element, executing, by the application, a background process to complete the purchase of the product without requiring additional input from the user or display of a checkout page of a website of the maximum benefit entity.

19. The system of claim 18, wherein the maximum benefit entity is a third entity that is different from the first entity and the second entity.

20. The system of claim 18, wherein the application is a browser extension.