INTEGRATION

Cross Reference to Related Application

This application is being filed on June 28, 2022, as a PCT International Patent Application that claims priority to and the benefit of U.S. Application No. 17/365,516, filed on July 1, 2021, which application is hereby incorporated herein by reference in its entirety.

This application is a Continuation-in-Part of U.S. Application 17/365,516, filed on July 1, 2021 which is a Continuation-in-Part of U.S. Application 17/196,365, filed March 9, 2021, which claims the benefit of U.S. Provisional Application No. 62/987,081, filed March 9, 2020, titled "System and Method for Improved Execution of Multiparty Transaction Involving Electronic Funds Disbursement," and U.S. Provisional Application No. 63/081,107, filed September 21, 2020, and titled "System and Method for a Payment Card-Based Execution of a Multiparty Transaction Involving Electronic Funds Disbursement," the disclosures of which are hereby incorporated herein by reference.

Technical Field

Herein is disclosed a system and method for introduction of a transaction mechanism to an e-commerce website, and more particularly a system and method for introduction of a transaction mechanism to an e-commerce website without requiring effort on the part of the operator of the aforementioned e-commerce website to participate in systems integration with the operator of the transaction mechanism.

Background

Increasingly, commerce is conducted online, with some estimates putting aggregate electronic commerce (e-commerce) volume at approximately $861 billion in the year 2020. Such electronic commerce is constituted predominantly of consumer transactions conducted at e-commerce sites, which may in some instances be the online counterpart to a retailer's brick-and-mortar presence. In order for such commerce to take place, it is essential that there exists a means by which a consumer may initiate payment to the retailer in the absence of a traditional point-of-sale system.

Most e-commerce websites are structured to present items offered for sale by the retailer, and to permit a consumer to add a given product to a digital "shopping cart" for subsequent purchase via an online checkout process. The checkout process is typically initiated from within the aforementioned shopping cart in response to a consumer selecting a "checkout" button, whereupon the consumer is led through a series of webpages wherein the consumer may enter, among other information, payment information. Such payment information typically includes a credit card number, security code, billing ZIP code, name of the person embossed on the credit card, and so on. The software constituting the shopping cart is structured to interact with systems operated by a third party, such as a payment processor, in order to initiate a consumer's desired payment via one of the major payment networks. Thus, today it is the case that most e-commerce websites offer consumers the opportunity to purchase products via a payment transacted with one of the major payment networks.

Some consumers may desire to acquire a product from an e-commerce site through an alternative arrangement or payment mechanism - not by a payment transacted through a major payment network. For example, some consumers may desire to acquire a product from an e-commerce website via a lease-to-own arrangement or other alternative transaction mechanism. Typically, to introduce an alternative transaction mechanism to an e-commerce site, the operator of the e- commerce site would have to engage with the provider of the alternative transaction mechanism. Such engagement would usually include agreeing upon an interface by which the systems operating the e-commerce site could communicate with the systems operating the alternative transaction mechanism, and further include agreeing upon a communication procedure to be conducted through such interface. In the wake of agreeing upon such matters, each party would develop software that behaved in accord with the aforementioned interface and communication procedure, and the parties would cooperate to test such software prior to making it available to the public for use via the e-commerce site. These activities constitute a multiparty systems integration effort.

The multiparty systems integration efforts required in connection with the provisioning of alternative transaction mechanisms to e-commerce websites are expensive, complicated, time-consuming and inefficient. Consequently, they are conducted infrequently and the public suffers in the form of reduced transaction offerings presented by e-commerce websites. There thus exists a need to address this problem.

Summary

Against this background, the present subject matter was developed. According to some embodiments a transaction system permits a user thereof to acquire at least one good marketed for sale on a website via a transaction offering that is not natively offered on the website. The website is operated by an operator of said website, such as an e-retailer. The transaction system includes a computing device that, in turn, includes a processing unit and a memory that is communicably connected with and readable by the processing unit. The memory contains instructions that, when executed by the processing unit cause the processing unit to execute a web browser application. The web browser application is configured to load a browser extension while the web browser application is navigated to the aforementioned website. The browser extension is executed in response to the browser extension having been loaded by the web browser application. The browser extension contains instructions that, when executed, cause said extension to add a user interface element that is not native to the aforementioned website to a page of that website. The browser extension presents a user interface that is not native to the website in response to the user interacting with the aforementioned user interface element. The user interface enables creation of the transaction between the user and a third party that is distinct from said operator of said website. The transaction pertains to a subject matter that includes the aforementioned good or goods. Finally, the extension initiates a purchase of the good or goods, in response to creation of the transaction by the user via the user interface presented by the browser extension.

According to other embodiments, a method is presented for permitting a user of a transaction system to acquire at least one good marketed for sale on a website via a transaction offering that is not natively offered on the website for acquisition of goods. The website is operated by an operator of the website. The method includes executing a web browser application, with the transaction system. The web browser application is configured to load a browser extension while the web browser application is navigated to the aforementioned website. The method further includes executing the browser extension, with the transaction system, in response to the browser extension having been loaded by the web browser application. The browser extension adds a user interface element that is not native to the website to a page of the website. The browser extension presents a user interface that is not native to the website, in response to the user interacting with the aforementioned user interface element. The user interface enables creation of the transaction between the user and a third party that is distinct from the aforementioned operator of said website. The transaction pertains to a subject matter including the aforementioned good or goods. Finally, the browser extension initiates a purchase of the aforementioned good or goods, in response to the creation of the transaction by the user via the user interface presented by the browser extension.

According to other embodiments, a transaction system is disclosed. The transaction system permits its user to acquire at least one good marketed for sale on a website via a transaction offering that is not natively offered on the website for acquisition of the aforementioned good or goods. The website is operated by an operator of said website. The transaction system includes a computing device, which, in turn, includes a processing unit and a memory that is communicably connected with and readable by the processing unit. The memory contains instructions that, when executed by the processing unit cause the processing unit to execute a web browser application. The web browser application is configured to launch a browser extension while the web browser application is navigated to the aforementioned website. The browser extension contains instructions that, when executed, cause said extension to add a user interface element to the website or web browser application. The browser extension presents a user interface that is not native to the website, in response to the user interacting with the aforementioned user interface element. The user interface enables creation of the transaction between the user and a third party that is distinct from the aforementioned operator of the website. The transaction pertains to a subject matter that includes the aforementioned good or goods.

According to some embodiments a transaction system permits a user thereof to acquire at least one good marketed for sale on a website via a transaction offering that is not natively offered on the website. The website is operated by an operator of said website, such as an e-retailer. The transaction system includes a computing device that, in turn, includes a processing unit and a memory that is communicably connected with and readable by the processing unit. The memory contains instructions that, when executed by the processing unit cause the processing unit to execute a web browser application. The web browser application is configured to load a browser extension while the web browser application is navigated to the aforementioned website. The browser extension is executed in response to the browser extension having been loaded by the web browser application. The browser extension contains instructions that, when executed, cause said extension to add a user interface element that is not native to the aforementioned website to a page of that website. The browser extension presents a user interface that is not native to the website in response to the user interacting with the aforementioned user interface element. The user interface enables creation of the transaction between the user and a third party that is distinct from said operator of said website. The transaction pertains to a subject matter that includes the aforementioned good or goods. Finally, the extension initiates creation of a payment card number. The payment card number is to be used by the user to effect payment for the aforementioned good via said website, and via a payment transaction drawing upon funds of the aforementioned third party.

According to other embodiments, a method is presented for permitting a user of a transaction system to acquire at least one good marketed for sale on a website via a transaction offering that is not natively offered on the website for acquisition of goods. The website is operated by an operator of the website. The method includes executing a web browser application, with the transaction system. The web browser application is configured to load a browser extension while the web browser application is navigated to the aforementioned website. The method further includes executing the browser extension, with the transaction system, in response to the browser extension having been loaded by the web browser application. The browser extension adds a user interface element that is not native to the website to a page of the website. The browser extension presents a user interface that is not native to the website, in response to the user interacting with the aforementioned user interface element. The user interface enables creation of the transaction between the user and a third party that is distinct from the aforementioned operator of said website. The transaction pertains to a subject matter including the aforementioned good or goods. Finally, the browser extension initiates creation of a payment card number. The payment card number is to be used by the user to effect payment for the aforementioned good via said website, and via a payment transaction drawing upon funds of the aforementioned third party.

According to other embodiments, a transaction system permits a user thereof to acquire at least one good marketed for sale on a website via a transaction between the user and a third party. The transaction is not natively offered on the website. The website is operated by an operator of said website. The transaction system includes a web browser application presenting said website. The transaction system also includes a browser extension that interoperates with the web browser application. The browser extension is arranged to present a user interface that enables creation of the transaction between the user and the third party. The transaction results in the aforementioned at least one good being provided to said user. The browser extension is further arranged to initiate creation of a payment card number that is usable by the user on the website to conduct a payment operation pertaining to the aforementioned at least one good.

Brief Description of the Drawings Figure 1 depicts an exemplary system for introduction of a non-native transaction offering to an e-commerce website, in accordance with certain embodiments.

Figure 2 depicts an exemplary method carried out in connection with the system of Figure 1, in accordance with certain embodiments.

Figure 3 depicts an exemplary system for introduction of a non-native transaction offering to an e-commerce website, in accordance with certain embodiments.

Figures 4A-4G depict an exemplary method carried out in connection with the system of Figure 3, in accordance with certain embodiments.

Figures 5A-5S depict an exemplary e-commerce website and user interface presented by a browser extension pursuant to the method of Figures 4A-4G, in accordance with certain embodiments.

Figure 6 depicts an exemplary method for providing validation services in connection with the system of Figure 3, in accordance with certain embodiments.

Figure 7A depicts an exemplary system for carrying out a robotic process automation function to conduct purchases of goods or services, in accordance with certain embodiments.

Figures 7B-7C depict an exemplary method for carrying out a robotic process automation function to conduct purchases of goods or services in connection with the system of Figure 7A, according to certain embodiments.

Figures 8A and 8B depict an exemplary method for relaying email correspondence from an e-retailer to a user of the system of Figure 3, according to certain embodiments.

Figures 9A-9E depict an exemplary method carried out in connection with the system of Figure 10, according to certain embodiments.

Figure 10 depicts an exemplary system for introduction of a non-native transaction offering to an e-commerce website and for interoperation with an issuer processor platform to initiate creation of payment cards useful in connection with funding alternative transactional arrangements, in accordance with certain embodiments. Figures 11A-11D depict exemplary methods carried out in connection with the system of Figure 10, according to certain embodiments.

Figure 12 depicts an exemplary user interface element presenting a payment card number useful in connection with funding alternative transactional arrangements, in accordance with certain embodiments.

Figure 13 depicts an exemplary computing device for use in connection with any of the embodiments disclosed herein, in accordance with certain embodiments.

Detailed Description

Figure 1 depicts an embodiment of a system 100 that introduces a third-party transaction offering into an e-commerce website 102 without necessitation of a multiparty integration. As can be seen from Figure 1, the e-commerce website 102 is displayed to a user (not depicted) via a web browser 104. The web browser 104 may be executing on a personal computer, laptop computer, tablet, smartphone (such as a device running the iOS® or Android® operating systems) or other mobile device or computing platform. For the sake of simplified discussion, the document may refer to the web browser as executing on a personal computer.

The e-commerce website 102 may be any website 102 that offers a product or service for sale via such website 102. For example, the websites associated with uniform resource locators (URLs) such as https://www.amazon.com, https://www.bestbuy.com, https://www.wayfair.com, https://www.homedepot.com, or https://www.walmart.com are examples of e-commerce websites 102, to name but a few. An e-commerce website 102 is typically structured to permit a user of the web browser 104 to select goods or services for purchase by adding such goods to a digital shopping cart accessible via the website 102, and to permit the user to pay for such goods or services within the cart via a checkout process. The checkout process typically permits the user to enter payment information pertaining to payment cards operable on the major payment networks to pay for the goods or services within the cart. The payment information is typically communicated to a payment processor to structure such information appropriately for the execution of a payment transaction and to direct such payment transaction to the appropriate payment network in accordance with its particular rules, in order to effectuate payment to the e-retailer. The user may have the purchased goods or services delivered to their residence or another location of their choosing, or may pick them up (for example, at a chosen brick-and-mortar retail location).

It may be the case that the user desires to obtain, but not necessarily purchase, goods or services from an e-commerce website 102 pursuant to a transaction structure not offered by the website 102. For example, the user may desire to acquire the goods pursuant to a lease-to-own arrangement, a subscription arrangement, an installment loan arrangement, or any other form of lease, payment or financing arrangement not serviced by major payment networks or not otherwise natively offered via the e-commerce website 102. For the sake of simplified discussion, the particular species of third-party transaction introduced into the e- commerce website 102 is described herein as a lease-to-own arrangement. However, those of skill in the art will understand that the principles disclosed herein are applicable to other varieties of transactional arrangements. Additionally, the goods or services acquired from the e-commerce website 102 are described as goods. Those of skill in the art will understand that certain varieties of transactional arrangements contemplate services as well as goods as the proper subjects of such transactions.

The system 100 includes a browser extension 106 that interoperates with the web browser 104 and certain e-commerce sites 102 that the browser 104 may render. According to some embodiments, the web browser 104 has been configured to launch the extension 106 in response to a user having entered a URL into the browser's 104 URL bar, if the particular URL includes a particular domain. For example, if the URL entered into the URL bar includes the domain "wayfair.com" or "bestbuy.com" and so on, the web browser 104 will respond by launching the extension, typically after having loaded the ecommerce site. The extension 106 may include a configuration file, such as a manifest file, that may describe the conditions under which the web browser 104 is to launch the extension. (Conceptual example: "launch the extension by the name of such-and-such if the URL entered in the URL bar contains the domain "bestbuy.com" or "wayfair.com" or so on.) The configuration file may describe other conditions for launch of the extension, in addition to a particular URL or domain having been entered into the browser's 104 URL bar. The extension 106, itself, may be structured as a JavaScript file, and may interact with the e-commerce site 102 presented via the web browser 104, such as through the JavaScript document object model. According to some embodiments, the user of the web browser 104 will have granted appropriate permissions to the extension 106 to permit its proper operation on the web browser 104.

The system 100 further includes a backend computing platform 108 operated by or on behalf of the third-party entity offering an alternative transactional arrangement such as a lease-to-own arrangement. Continuing with the example wherein the particular species of third-party transaction to be introduced into the e- commerce website 102 is a lease-to-own arrangement, the backend computing platform 108 executes various processes and exposes various application interfaces (APIs), such as web APIs, that cooperate to originate, effectuate and service lease-to- own arrangements. More broadly considered, the backend computing platform 108 executes various processes and exposes various APIs, such as web APIs, that cooperate to originate, effectuate and service alternative transaction structures suitable for conveying goods or services to a third party such as a consumer from an e- commerce website. Carrying on with the exemplary embodiment wherein the alternative transaction is a lease-to-own arrangement, the platform 108 may contain APIs by which the extension 106 interacts with the backend platform 108 to perform such tasks as: identify a pre-existing customer of the lease-to-own company (including retrieving the customer's personally identifiable information, his or her open-to-lease line, his or her remaining open-to-lease line, and so on); validate a particular good as being the appropriate subject of a lease-to-own arrangement, as discussed in more detail below; determine the terms pursuant which the lease-to-own company is willing to lease a particular good (example: monthly payment amount, and number of such monthly payments); construct a contract creating a lease-to-own relationship between a customer and the lease-to-own company, the subject of which is a particular validated good or goods, and the terms of which have been determined by the aforementioned service; and so on. Finally, according to some embodiments, the system 100 includes third-party services 110 that may interoperate with the extension 106 and backend platform 108 in the course of effectuating a lease-to-own arrangement (example: such third party services may include payment processing services extended by a payment processor; document cloud hosting services extended by a document cloud company; and so on).

In use, the system 100 may operate as depicted in Figure 2. The user of the system 100 may begin his or her shopping experience by navigating to an e-commerce website 102 via a web browser 104 running on his or her computer (not depicted). The web browser 104 detects that the user has navigated to an e-commerce website 102, and responds by launching the extension (operation 200).

As show in operation 202, the extension 106 monitors the actions of the user while he or she shops on the e-commerce website 102. As a part of such activity, the extension 106 interacts with the e-commerce website 102 so as to determine which particular products the user intends to obtain. For example, the extension 106 may scrape such information from the website 102. Note that scraping operations do not require the operator of the e-commerce website 102 to deliberately expose an interface by which such information is conveyed.

The extension monitors the path of navigation of the user through the website 102 in order to determine whether the user has arrived at an appropriate point at which to insert a user interface element, such as a button, offering a lease-to-own arrangement to the user (operations 204 and 206). For example, most digital shopping carts employed by e-commerce websites 102 contain an entry point page, wherein the user can review which particular products are in his or her cart, can remove any unwanted items, and can opt to proceed to check out and therefore pay for the items within the cart. The aforementioned entry point page of the shopping cart may be altered by the extension 106 to include a button offering a lease-to-own arrangement to the user as an alternative option to checking out via the website's 102 native capabilities (meaning that the user will have to pay for the items via one of the major payment networks). Note that by virtue of the aforementioned user interface element (e.g., a button) having been introduced by the extension, the operator of the e-commerce website 102 is relieved of having to take any step whatsoever to cause such introduction of the element or otherwise accommodate it. According to some embodiments, the extension 106 adds the aforementioned user interface element (example: a button) to the web browser 104, itself, such as to a tool bar of the web browser 104.

The extension 106 detects a "click event" pertaining to the user interface element it added during operation 206 (operation 208). If the user clicks the aforementioned user interface element to explore a lease-to-own arrangement, operational flow is passed to operation 210. (If the user elects to check out using the website's 104 native checkout function, then the extension 106 does not interfere.) In operation 210, the extension 106 determines whether the product or products contained within the cart are eligible to be the subject of a lease-to-own relationship. Typically, consumable goods, permanently installed goods, or goods having a sales price less than a particular threshold value are not considered appropriate subjects of a lease-to-own arrangement. To identify the particular goods eligible to be the subject of a lease-to-own relationship, the extension 106 may send a message to the backend computing platform 108 identifying the items within the cart. The backend platform 108 may respond by indicating for each such item whether or not such item is eligible (operation 210). Note that no cooperation with the systems operating the e-commerce website is required to enable such eligibility inquiry - the inquiry and determination may be made on the basis of information scraped from the e- commerce website 102.

With respect to those items that are, in fact, eligible to be the proper subjects of a lease-to-own arrangement, the extension 106 cooperates with the backend platform 108 and perhaps other third-party services 110 to effectuate the lease-to- own arrangement (operation 212). For example, the extension 106 may: (1) present a user interface by which the user may identify himself or herself as an existing user and login to an account maintained by the backend platform 108; (2) retrieve information from the backend platform 108 concerning the user in the event he or she logs in as an existing user, including, for example, his or her open-to-lease line value and remaining open-to-lease line value; (3) determine whether the user has a sufficient remaining open-to-lease line value to permit the eligible goods to be leased; (4) in the event that the user was not a pre-existing customer, present a user interface and interact with the backend platform 108 so as to enroll the user as a customer of the lease-to-own company, and decision that user for a lease-to-own line (and determine whether such line is sufficient to permit the contemplated transaction); (5) interact with the backend platform 108 to retrieve an estimate of the terms of the contemplated transaction, and present such estimated terms to the user via a user interface; (6) optionally offer companion services (example: a damage liability waiver or a benefits package) to the user; (7) interact with the backend platform 108 to retrieve a definitive set of terms of the transaction in view of the user's selection of any aforementioned companion services; (8) interact with the backend platform 108 and optionally a third-party service 110 to create a contract document describing a lease-to-own arrangement for the eligible products pursuant to the aforementioned terms, and present a user interface to present such contract document to the user and permit the user to digitally initial and sign such document; (9) interact with the backend platform 108 or third-party service to store such contract document in the wake of it having been presented to the user for initialization or signature; and (10) interact with the backend platform 108 to obtain reference information, such as a lease identification number, and present such information to the user via a user interface. Note that none of the just-recited steps require interaction with the systems operating the e-commerce website 102.

In the wake of having effectuated the lease-to-own arrangement for the eligible goods (operation 212), the extension 106 initiates a process by which the leased good or goods are purchased by the lease-to-own company from the particular e-retailer operating the website 102, and delivered to the user (operation 214). For example, the extension 106 may initiate an automated process conducted by a remote computing platform (such as the backend computing platform 108) to purchase such goods via the e-commerce website 102 using a payment card titled in the name of the transaction company (example: lease-to-own company), and to have those goods delivered to the user's residence or another location, such as a location determined by the user. (Exemplary embodiments of such a process are disclosed herein, below). Note that the goods may be purchased by the transaction company (example: lease-to-own company) via the e-commerce website 102 without necessitation of any alteration to the website 102, itself, or the systems that operate it.

The upshot of the structure of the system embodiments of Figure 1 and the method embodiments of Figure 2 is that all of the operations required for creation of the alternative transaction, itself, and all of the operations required for delivery of the goods or services that are the subject of the alternative transaction, can be performed by the concerted actions of the extension 106, backend platform 108 and (optionally) the third-party service platforms 110 - either without involvement of the e-commerce website 102 or the systems that operate it, or via involvement of it in such a way that requires no alteration to the website 102 or the systems that operate it. Hence, no multiparty integration effort is required by a system designed in accord with the principles of Figures 1 and 2.

Although Figure 1 depicts the backend computing platform 108 as being singular, it may be constituted of plural platforms that cooperate to perform the previously described operations. Moreover, the third-party services 110 of Figure 1 may be performed by the backend platform 108, itself. It is also the case that some of the operations described as having been performed by the backend computing platform 108, itself, may optionally be performed by a third-party platform, such as via consumption of a third-party service 110.

Figure 3 depicts exemplary alternative embodiments of the system 100 of Figure 1. As was the case with respect to system 100 (Figure 1), the system 300 of Figure 3 includes an e-commerce website 302 presented to a user via a web browser 304. The system 300 also includes an extension 306 that can interact with the e- commerce site 302, the web browser 304, a backend computing platform 308 operated by or on behalf of a transaction company (example: a lease-to-own company), a document cloud service 310, and a payment processor 312.

In use, the system 300 operates as depicted and described with regard to the methodological embodiments of Figures 4A-4G. An example of a customer's use of an e-commerce website 302 is depicted with respect to Figures 5A-5S. Figures 4A-4G and 5A-5S are referred to alternately in the following discussion. Figure 5A depicts a web browser 304 that a user has navigated to an exemplary e-commerce website 302. As can be seen from Figure 5A, the URL bar 500 contains the domain 502 "wayfair.com". The web browser 304 has been configured to launch the extension 306 in response to the particular domain 502 contained within the URL bar 500 being equal to one of plural domains with which the extension 306 is designed to interoperate (example: the extension 306 is launched if the domain 502 is equal to "wayfair.com", "bestbuy.com" or "homedepot.com", and so on). In response to the extension 306 being launched, the JavaScript constituting the extension executes on the JavaScript engine of the web browser 304 and begins to interact with the HyperText Markup Language (HTML) document of the e-commerce website 302. In operation 400, the extension adds an informational button 504 (see Figure 5B) to the website 302. According to some embodiments, the informational button 504 is added to every page of the website 302 to which the user navigates. According to other embodiments, the informational button 504 is added to only a subset of the pages. For example, the button 504 may be added to only the first page loaded within the targeted domain (in this example, "wayfair.com"), or may be added to only the first x number of such pages, where x is an integer. When the informational button 504 is clicked, such click is detected (operation 402), and an informational window is presented by the extension (operation 404). The informational window (not depicted) explains that a lease-to-own arrangement is offered to the user vis-a-vis certain products marketed via the e-commerce website 302, explains the general nature of a lease-to-own arrangement, explains that the lease-to-own arrangement is being offered by a third-party, as opposed to being offered by the operator of the website 302, and explains that a lease-to-own arrangement is different from outright ownership of a product, among other such informational disclosures. The user may close the information window presented by operation 404 by clicking a "close" button or "X" button, and may re-open it by re-clicking the informational button 504 for so long as it is displayed on the website 302.

Query operations 402, 406, 408 and 410 test for the occurrence of events that may occur as the user navigates the e-commerce website 302. As these events occur, the operations 404, 412, 414, 416, 418 et seq. to which the queries 402, 406, 408 and 410 refer are executed promptly. The extension 306 may embody such operations 404, 412, 414, 416, 418 et seq. as functions or methods that are called invoked upon the occurrence of the events tested for by queries 402, 406, 408 and 410, rather than explicitly tested for.

After having navigated to the e-commerce site 302, the user engages in shopping activities and eventually navigates to the product description page 506 depicted in Figure 5C. The user elects to add the product depicted and described with reference to the page 506 (a sofa) to his or her cart by selecting the "Add to Cart" button 508 native to the e-commerce website 302. The user's click of the "Add to Cart" button 508 is detected by query operation 406, which tests for occurrence of a click of an "Add to Cart" button 508 on a product description page. According to some embodiments, the extension 306 tests for whether or not the website 302 is navigated to a product description page 506 by examining the structure of the URL 502 in the URL bar 500. As can be seen from the example in depicted in Figure 5C, the URL 502 contains a subdirectory labeled "pdp". The exemplary website 302 is organized such that all product description pages 506 correspond to a URL having a subdirectory labeled "pdp", meaning the extension 306 can test for this condition. A different e- commerce website may exhibit a different condition that the extension 306 should monitor to make this determination. In general, the extension 306 tests for a condition common to product description pages on a given website 302 to determine that the website 302 is navigated to a product description page. Moreover, all product description pages of the exemplary website 302 apply a common class name to the "Add to Cart" button 508, meaning that the extension can test for click events pertaining to buttons identified by the aforementioned class name. Again, the particular attribute commonly assigned to an "Add to Cart" button on any given e- commerce website may vary from website-to-website. In general, the extension 306 tests for click events occurring on elements having an attribute common to the "Add to Cart" buttons 508 on all product description pages of the website 302. Thus, the strategy for implementing query operation 406 begins by determining the particular domain to which the web browser 304 has been navigated. Based upon the domain, the appropriate strategy for identifying that the rendered page is a product description page 506 is invoked, and the appropriate strategy for identifying a click event of the "Add to Cart" button 508 is invoked.

Upon determination that a click event of an "Add to Cart" button has occurred from a product description page, operation 412 is invoked. In operation 412, information pertaining to the product that is the subject of the product description page 506 is scraped. For example, the extension 306 may scrape: product name 508, product shop keeping unit (SKU) 510, product price 512, product quantity 514, a set of category information, such as product categoryi 516, product category? 518, product category? 520, and product brand 522. As was the case in previous interactions with the HTML document comprising the page 506, the extension first determines the domain of the URL 502 in the URL bar 500. Based on the domain of the website 302 being presented by the browser 304, a domain-specific scraping strategy is employed (domain-specific scraping functions or methods may be contained within the extension 306 and called in the course of scraping operation 412). For example, for a given domain, the extension 306 may examine the HTML document comprising the product detail page 506 to extract elements with a given class name or element ID attribute or other attribute to extract the desired unit of data. (For example, it may be the case that product names across all product detail pages 506 have the same class name or element ID attribute or other attribute, meaning that to scrape the product name, the extension 306 need only extract the element identified by the aforementioned class name or element ID attribute or other attribute.) In addition to using the domain of the URL 502 in the URL bar 500 to determine the scraping strategy to be used to extract each particular unit of data, the domain may be used to determine which units of data are available to be extracted from a given e-commerce website 302. For example, some websites may only have one or two levels of product category data, meaning that the extension 306 would only scrape product categoryi, or product categoryi and product category? when scraping from a given site. According to some embodiments, in the event that a given product is associated with more than a certain threshold quantity of categories (example: three categories), a quantity of categories no greater than the aforementioned threshold are scraped for each given product, beginning with the highest-level category. (Example: assume a

Y1 sound bar is associated with categories such as "audio" (categoryi), "home audio" (category?), "speakers" (category?) and "sound bars" (category^, then only categoryi, category? and category? would be scraped). For the sake of clarity, the term "highest level category" refers to the broadest category ("audio"), while the next highest-level category refers to the next broadest category ("home audio"), and so on.

In the wake of having scraped the product data (operation 412), the extension 306 constructs a product object corresponding to the product that is the subject of the product detail page 506. Thus, a first unit of scraped data (example: product name) is assigned to a first attribute of the aforementioned product object, and a second unit of scraped data (example: product SKU) is assigned to a second attribute of the aforementioned product object, and so on. The product object may also include other data obtained from the web browser 304 as opposed to having been scraped from the e-commerce website 302, such as the particular URL corresponding to the product detail page of the product described by the product object. After having constructed the product object, the product object is added to a product object array that is stored in local memory in the browser, such as by use of the sessionstorage API (operation 414). Thus, there is one product object stored in the product object array for each product that was added to the cart by virtue of the user having clicked the "Add to Cart" button 508 from a product detail page.

According to some embodiments, the various scraping strategies pertaining to various e-commerce domains are hard-coded into the extension 306, itself. According to other embodiments, the extension 306 uses the domain (or a value derived therefrom such as a retailer ID, discussed later) to retrieve the scraping strategy from a remote computing platform, such as backend platform 308. For example, the extension 306 may call the backend platform 308 with a retailer ID identifying the particular e-commerce site 302 to be scraped, and the platform 308 may respond with an array or other data structure identifying the particular class name associated with a given unit of product data to be scraped. These embodiments have the advantage of providing flexibility in the event that the operator of the e-commerce website 302 alters the structure of the site 302 so as to disrupt the present-tense scraping strategy. The scraping strategy can simply be updated at the remote computing platform, and the extension will scrape pursuant to the updated strategy without necessitation of updating the extension 306, itself.

After having navigated to product detail page 506 and adding the sofa to the digital shopping cart, the user next navigates to the product detail page 507 shown in Figure 5D. The user once again adds the product that is the subject of the product detail page 506 (an end table) to the digital shopping cart by clicking the "Add to Cart" button 509, and the extension once again responds by detecting a click event on an "Add to Cart" button 509 on a product detail page 507, and traversing operations 412 and 414, thereby scraping the relevant product data, constructing a product object and saving the product object in the aforementioned product object array, meaning that pursuant to this example, the array now has two objects within it.

As a consequence of having clicked the "Add to Cart" button 510, the product description page 508 presents a sidebar 513 that displays the item just added to the cart, i.e., the end table (see Figure 5E). The sidebar 513 includes a "Review Cart" button 511, which the user clicks, causing the website 302 to load and display the entry point page for the digital shopping cart (see Figure 5F).

When the entry point page of the shopping cart is loaded, the URL 502 in the URL bar 500 is "wayfair.com/v/checkout/basket/show". Loading of the shopping cart is detected by the extension 306 (query operation 408) by virtue of testing the URL 502 against the string known to be equal to that of the shopping cart for the wayfair.com domain. Thus, operation 408 is uniquely structured for each e-commerce site 302 with which the extension 306 interoperates. In other words, the extension 306 examines the domain of the URL 502 and determines what string the URL 502 should be tested against with the occurrence of each page load in order to determine whether the shopping cart has been entered. For the "wayfair.com" domain, the aforementioned string will equal one particular value (i.e., "wayfair.com/v/checkout/basket/show"), while for the "bestbuy.com" domain, the aforementioned string would equal another value (e.g., "bestbuy.com/cart"), and so on.

As a consequence of the extension 306 detecting the load of the shopping cart in query operation 408, operational flow is passed to operation 416. In operation 416, a transactional button 515 is added to the shopping cart page by the extension 306. In the particular example depicted in Figure 5F, the transactional button 515 reads

"Preferred Lease Checkout" which indicates to the user that a lease-to-own arrangement offered by Preferred Lease can be sought vis-a-vis the items in the cart (the sofa and end table) by clicking the button 515. Operation 416 is unique to each particular e-commerce site 302 with which the extension 306 interoperates. The extension 306 examines the domain 502, and in the context of the particular example being discussed presently, determines that the domain is "wayfair.com." Based upon the domain, the extension calls a particular function or method that is structured to introduce the transactional button 515 on to the shopping cart page of the Wayfair e- commerce website 302. According to some embodiments, the extension 306 includes a plurality of such functions or methods, each of which corresponds to one particular e-commerce website 302 with which the extension 306 is intended interoperate (example: one such function or method for the "wayfair.com" domain, another such function or method for the "bestbuy.com" domain, and so on). As can be seen from Figure 5F, the function or method adds the button 515 in such a manner that it does not overlap other native elements of the shopping cart page, and is intuitively located from the perspective of the user.

Continuing on with the exemplary use case presently being discussed, the user clicks the transactional button 515, and the click event is detected by query operation 410, causing operational flow to transition to operation 418 (Figure 4B). In operation 418, the extension 306 scrapes the product information from the shopping cart page depicted in Figure 5F. Recall: the extension is structured to add a product object to the product object array only in the event that the user clicks an "Add to Cart" button (such as button 510 depicted in Figure 5D) from a product detail page (such as product detail page 508 depicted in Figure 5D). The e-commerce website 302 may contain "Add to Cart" buttons on pages other than its various product detail pages. Should the user click an "Add to Cart" button located on one of those other pages, the extension 302 as depicted in Figures 4A-4G does not respond by adding a product object to the product object array. The reason for this is that, given the structure of the particular e-commerce website 302 that is the subject of this example, the other pages from which the user may have clicked an "Add to Cart" button contain considerably less product information, meaning that scraping operation 412 (Figure 4A) could not extract much information for creation of a product object if it were called in response to click events on "Add to Cart" buttons location on such other pages. For example, such other pages may not present a product SKU or product categories, and so on, meaning that those particular product objects attributes would not be populated by the extension 306 and would therefore contain no data. To accommodate a strategy in which scraping is performed only in response to click events on "Add to Cart" buttons located on product detail pages, the extension 306 is structured to scrape (operation 418) product data from the shopping cart page (Figure 5F). The result is that a more consistent quantity of product data is extracted from product-to-product within the shopping cart. For example, according to some embodiments, the product data may be entirely consistent with the exception that, in the context of certain e-commerce sites, product category information may be excluded from the HTML document comprising the shopping cart page, meaning that the scraping operation 418 is unable to extract such information. According to some embodiments, the extension does, in fact, respond to a click event of "Add to Cart" buttons located on pages other than product detail pages by initiating execution of operations 412 and 414. Scraping operation 418 functions similarly to the scraping operation 412 of Figure 4A (strategy varies from site-to-site, and is based on class names, element ID's, or other attributes known to accompany the sought-after information), and for the sake of brevity is not re-described here.

In the wake of having scraped the product data from the cart (and organized it into one or more product object - one such object for each item in the car), the just- scraped data is compared to the product object array (operation 420). The purpose of operation 420 is to: (1) account for objects that may have been removed from the cart after having been added by virtue of a user having clicked an "Add to Cart" button from a product detail page - note that as presented in Figure 4A, the extension 306 adds product objects to the product object array but does not contain operations to remove such objects from the array; and (2) to account for any products that may have been added to the cart by virtue of the user having clicked on an "Add to Cart" button located on a page other than a product detail page. Thus, in operation 422 the extension 306 adjusts the product object array to reflect the items actually contained in the digital shopping cart: it removes any product objects that are in the array but not present in the dataset generated from scraping the cart (operation 418), and adds product objects to the array for any objects present in the dataset generated from operation 418 but not already present in the product object array.

In the wake of having performed adjustment operation 422, the extension 306 presents the user with a login screen, depicted in Figure 5G. Continuing on with the exemplary use case, the user enters his or her login credentials into the screen of Figure 5G and clicks the "Login" button 517. In operation 426, the extension 306 responds by accessing a single-sign-on service 314 executing on the backend computing platform 308 and exposed to a network such as the Internet via an API (example: the service 314 may be a web service exposed via a RESTful API, for example). (The backend platform 308 exposes other services 316-334, discussed below, which may also be configured as web services exposed via RESTful APIs, or otherwise made available for access by the extension 306 via a network connection.) The extension 306 sends the login credentials entered by the user to the aforementioned service 314, which responds with: (1) an indication of success or failure of the login attempt; and, (2) assuming a successful login attempt, a global unique identification number (GUID) identifying the user to the various data systems making up the backend computing platform 308. (While operation 426 is being performed, the "Just a Moment" screen of Figure 5H is presented to the user; the screen of Figure 5H continues to be presented to the user during the execution of operations 428-436.)

Next, in operation 428, the response of the single-sign-on service 314 is examined by the extension 306, and if the response indicates a failure, the extension 306 does not permit advancement beyond the login screen of Figure 5G. On the other hand, if the response of the single-sign-on service 314 indicates a success, then control is passed to operation 430. In operation 430, the extension 306 accesses a validation service 316 executing on the backend platform 308. The purpose of the validation service 316 is to return a determination, for each product object within the product object array, pertaining to whether or not such product object corresponds to a product that is eligible for the sought-after transaction (in the context of this example, a lease-to-own arrangement). The extension 306 sends the product object array and an indication of the particular e-commerce site 302 from which the extension 306 scraped the product array (for example: the extension 306 may send the domain name of the e-commerce site or a retailer ID, such as an integer that that uniquely identifies the e-commerce site 302) to the validation service 316, such as via a JavaScript Object Notation (JSON) message, and the service 316 responds by returning the product object array with an indication - on a product-object-by-product-object basis - of whether each product in the cart is eligible to be the subject of a lease-to- own arrangement with the lease-to-own company. The operations related to the validation service 316 are discussed in greater detail, below.

In the wake of having accessed the validation service 316 (operation 430), the extension 306 accesses a tax estimation service 318 executing on the backend platform 308. The extension sends the GUID and product object array to the tax estimation service 318, and, supplied with residency information pertaining to the user (obtained by the service 318 by virtue of accessing the user's account information with the GUID), and further supplied with the price of each product based on the information in the product array, the service 318 responds with an estimate of the various taxes (example: sales tax, use tax, and so on) on a product-by-product basis, for each product that was indicated as being eligible for a lease-to-own arrangement during operation 430.

Next, in operation 434, the extension accesses a get-customer-information service 320 executing on the backend computing platform 308. The extension sends the service 320 the aforementioned GUID identifying the user, and the service 320 responds by returning information pertaining to the user, including: the user's open- to-lease line (which indicates the aggregate value of products, including tax, that the lease-to-own company is willing to spend to purchase eligible goods which are then leased by the lease-to-own company to the user), the amount of the user's lease-to- own line that remains available to fund future lease arrangements, the user's address, telephone number, and a lease ID identifying the contemplated lease transaction to the various data systems making up the backend platform 308. The information returned by the service 320 is converted into a customer object with object attributes equal to the various units of customer data returned by the service 320, and the customer object is stored (operation 436). According to some embodiments, the customer object is stored using the JavaScript sessionstorage API.

In the wake of having completed operation 434, the extension 306 constructs and presents the custom cart screen depicted in Figure 51 (operation 438). As can be seen from Figure 51, the screen contains data developed or obtained during execution of operations 430-434. The screen presents: (1) an indication of which particular items are eligible to be the subject of the contemplated lease-to-own arrangement (i.e., the sofa) - derived from operation 430; (2) the price of each such eligible item that is applied against the user's open-to-lease line, grossed up to include the tax estimate - derived from operation 432; (3) the user's open-to-lease line (in this case equal to the user's remaining open-to-lease line in advance of the contemplated transaction and therefore not presented separately from the user's pre-transaction remaining open-to-lease line) - derived from operation 434; (4) the total cost that is applied against the user's open-to-lease line (including tax estimations) of all products eligible to be the subject of the contemplated lease-to-own arrangement, which is calculated by the extension 306 by summing each of the aforementioned grossed-up prices of each of the eligible products; (5) the user's remaining open-to-lease line in the wake of the contemplated lease-to-own transaction, which is calculated by subtracting the aforementioned total cost described with reference to the fourth item in this list from the user's open-to-lease line; (6) with respect to the eligible item(s), the lease rate, initial lease term, and total cost to the user if the user renews the lease for a sufficient duration to ultimately obtain ownership, along with other consumer disclosures; and (7) an indication of which particular items are ineligible to be the subject of the contemplated lease-to-own arrangement (e.g., a consumable item or an item having a price that fails to exceed a threshold price for eligibility), meaning that the user will have to purchase the ineligible items if he or she is intent on obtaining them, because the lease-to-own company will not agree to lease those products to the user - this list of items (in this case, only a single such item) is derived from operation 430. Carrying on with the exemplary use case, the user reviews the information presented via the custom cart screen of Figure 51, and then clicks the "Continue" button 519 (depicted, for the sake of clarity, as operation 440, although it is an act performed by the user, as opposed to an action performed by the extension 306 - other actions of the user are presented in the operations flow of Figures 4A-4G for the sake of clarity).

In response to the user clicking the "Continue" button 519, the extension 306 presents the "Just a Moment" screen of Figure 5H, and accesses a transaction-terms service 324 executing on the backend platform 308 (operation 442). The extension 306 communicates to the transaction-terms service 324 a dataset that is sufficient for it to determine the transaction terms. Thus, in the context of the present lease-to- own example, the extension 306 communicates the product name, product categories (if they are known), product price, the aforementioned lease ID. According to some embodiments, the lease-to-own company may offer companion services that the user may elect to purchase in connection with his or her lease of eligible products. For example, the lease-to-own company may offer a limited damage waiver (to protect the user against costs that may arise from certain varieties of damage to the leased goods, should it be the case that the user were to terminate (i.e., not renew) the lease prior to obtaining ownership of the goods, and would therefore be returning damaged goods), or may offer a benefits package to the user. In the context of such embodiments, the extension 306 also communicates to the transaction-terms service 324 that the user desires to purchase both such companion services. The service 324 replies with the terms under which the transaction company will offer the transaction, which in the context of the current exemplary lease-to-own arrangement, include: (1) a monthly (or other offered short term lease renewal basis) lease payment estimate (example: a monthly payment of $133.89); (2) term of all lease renewals, if elected by the user, to obtain ownership over the product (example: 12 monthly payments); (3) the total cost to the user if the user renews the lease for a sufficient duration to ultimately obtain ownership; and (4) for each companion service, a monthly price and tax associated therewith (example: monthly cost of $12.28 for the limited damage waiver, plus tax of $1.11, and a monthly cost of $11.92 for the benefits package, plus tax of $1.07).

In the wake of receiving the response from the transaction-terms service 324, a transaction details screen, such as the one depicted in Figure 5J, is constructed and presented by the extension (operation 444). The transaction details screen presents: (1) the email address to which communications pertaining to the leased products will be sent - obtained during operation 434; (2) the phone number that the lease-to-own company would call in connection with any issues related to the contemplated lease- to-own arrangement - obtained during operation 434; (3) the address to which the leased items will be shipped - obtained during operation 434; (4) a pair of toggle buttons 521 and 524 by which the user may indicate his selection of either companion service - toggled on during the initial presentation of the transaction details screen, according to some embodiments; (5) an estimate of the monthly (or other short term lease renewal basis) lease payment that the user would owe, if the user elects to renew the lease and companion services each term, assuming the companion service selection indicated by the toggle buttons - $160.27 = $133.89 monthly cost for the sofa + $12.28 monthly for the limited damage waiver + $1.11 monthly tax on the limited damage waiver + $11.92 monthly for the benefits package + $1.07 monthly tax for the benefits package). The aforementioned estimated monthly payment is adjusted by the extension 306 as the user toggles the toggle buttons 521 or 524 (operations 446 and 448). For example, if the user were to de-select toggle button 524 (related to the benefits package), then the extension 306 would re-calculate the estimated monthly payment as: $147.28 = $133.89 monthly cost for the sofa + $12.28 monthly for the limited damage waiver + $1.11 monthly tax on the limited damage waiver. The transaction details screen of Figure 5J also contains a user input element 526 by which the user may indicate his next pay date. The user's pay date may be used to determine the particular date within each month upon which the user's payments will be due. This date will be stated in a transaction agreement (example: lease-to-own agreement) - discussed herein, below.

Continuing on with the exemplary use case presently being discussed, the user indicates his next pay date using user input element 526 (operation 450), and then clicks the "Continue" button 528 (operation 452). In response, the extension stores the payment date entered via user input element 526 as a payment date object (operation 454). According to some embodiments, the payment date object is stored using the JavaScript sessionstorage API. Thereafter, the extension 306 re-accesses the aforementioned transaction-terms service 324, this time communicating to it the user's actual selection of companion services, as indicated by toggle buttons 521 and 524 (operation 456). The service 324 replies with the monthly lease payment, the initial terms of the lease, the term of the lease assuming the user elects to renew the lease for all required terms to ultimately obtain ownership of the product, an application fee associated with the contemplated transaction, and, for each selected companion service (if any), a monthly price and tax associated therewith. According to some embodiments, the extension presents the "Just a Moment" screen of Figure 5H during the execution of operations 454 and 456.

Next, in operation 458, the extension uses the information returned from the transaction-terms service 324 in operation 456 to construct and present the review- of-terms screen depicted in Figure 5K. As can be seen from Figure 5K, the screen presents: (1) the application fee or initial lease payment retrieved from the transaction-terms service 324 in operation 456 (i.e., $49 in the exemplary screen depicted in Figure 5K); (2) the monthly lease payment retrieved from the transactionterms service 324 in operation 456 (i.e., $133.89 in the exemplary screen depicted in Figure 5K); (3) the monthly cost, including taxes, associated with the aforementioned companion services, retrieved from the transaction-terms service 324 in operation 456 (i.e., $13.39 per month for the limited damage waiver, and $12.99 per month for the benefits package); (4) the total monthly lease payment, which is the sum of the values from items 1, 2 and 3 from this list; (5) the initial lease term and lease term that would be required to obtain ownership of the product if the user elects to renew for all such lease terms, retrieved from the transaction-terms service 324 in operation 456 (i.e., 12 months); and (retrieved from the transaction-terms service 324 in operation 456 (i.e., $49 in the exemplary screen depicted in Figure 5K); and (6) the total lease cost, which is calculated by the extension 306 as the lease term from item 5 of this list multiplied by the monthly lease payment from item 2 of this list. In other words, the review-of-terms screen depicted in Figure 5K contains the financial terms of the contemplated transaction (a lease-to-own arrangement, in the context of the present example), which were part of the response from the transaction-terms service 324 in operation 456 (or derivable therefrom).

Continuing on with the exemplary use case presently being discussed, the user reviews the terms presented via the review-of-terms screen depicted in Figure 5K, finds them to be acceptable, and clicks the "Continue" button 530 (operation 460). The extension 306 responds to the user having clicked the "Continue" button 530 by accessing an API exposed by a payment processor 312 (depicted in Figure 3). For example, the extension 306 may post to the aforementioned API the information required for the payment processor 312 to construct a payment screen such as the one depicted in Figure 5L (example: the extension 306 posts the application fee or initial lease payment, i.e., $49 in the context of this example, to the API). The payment processor 312 responds by constructing the payment page of Figure 5L, set up to receive payment information required to pay the application fee or initial lease payment, and returns to the extension a URL referencing the just-constructed screen (operation 462). (According to some embodiments, the extension presents the "Just a Moment" screen of Figure 5H during the execution of operation 462.) The extension 306 responds to receipt of the URL from the payment processor 312 by presenting an iFrame referencing the just-returned URL (operation 464). In other words, the payment screen constructed by the payment processor 312 and depicted in Figure 5L is presented to the user by the extension 306 in an iFrame, using the URL to access the payment screen.

Continuing on with the exemplary use case presently being discussed, the user enters his or her payment information into the iFrame depicted in Figure 5L (operation 466), and clicks the "Continue" button 532 (operation 468). The iFrame is constructed so as to respond to the user having clicked the "Continue" button 532 by posting the information entered therein to the payment processor 312, so that the processor 312 can, in turn, route the payment to the correct payment network in accordance with that network's rules, thereby initiating the payment for the application fee or initial lease payment. In the wake of having routed the payment, the payment processor 312 accesses a payment-processor-interface 332 (see Figure 3) executing on the backend computing platform 308 to indicate that the payment was successfully posted to the appropriate network (operation 470). In response, the payment-processor-interface 332 stores this information in a manner accessible to the get-customer-progress service 322, which is also executing on the backend computing platform 308. As discussed below, the purpose of the get-customer-progress service 322 is to make available information to the extension 306 concerning aspects of the user's progress through the transaction-creation process (in this example, the process by which a lease-to-own arrangement is created) that would be otherwise inaccessible to the extension 306 by virtue some aspect of the process being performed by a third- party service (example: the payment processing operations are performed by the payment processor 312, meaning the extension 306 would typically have no access to information concerning whether the user's intended payment had, in fact, been posted).

In the wake of operation 470, the extension presents a "Success" screen, such as the one depicted in Figure 5M (operation 472), and the user responds by clicking the "Continue" button 534 (operation 474). In response to the user having clicked the "Continue" button 534, the extension 306 polls the aforementioned get-customer- progress service 322 using the aforementioned GUID associated with the user to enquire about the progress of the particular user identified by the GUID as it pertains to the payment to be made via the payment screen of Figure 5L, and awaits an indication from the service 322 that the customer's intended payment was, in fact, posted (operation 476). In response, the service 322 accesses a storage location, such as a database record or a particular file or directory, for example, where such information concerning the successful processing of the payment is to be stored by the aforementioned payment-processor-interface 332. If the storage location contains information indicating that the payment was posted, then the get-customer- progress service 322 responds to the extension 306 with a reply message indicating that the user's payment has been posted. Otherwise, it replies with a message indicating that the user's payment has not yet been posted. If the reply message indicates that the payment has not been posted, and if a threshold number of poll attempts have been made, the extension 306 does not permit advancement through the process, and, according to some embodiments, returns operational flow to operation 462 to re-initiate presentation of a payment screen (such as one depicted in Figure 5L). According to other embodiments, the process of Figures 4A-4G is exited altogether. On the other hand, if the response from the get-customer-progress service 322 indicates that the payment was, in fact, posted, then operational flow advances operation 478.

In operation 478, the extension 306 calls a generate-contract service 326 executing on the backend platform 308. The extension 306 sends the generatecontract service 326 information required to generate a contract between the user and the provider of the sought-after transaction (in this example, a lease-to-own company). According to some embodiments, this means that the extension 306 communicates the following informational elements to the service 326: (1) the lease ID returned during execution of operation 434 (Figure 4C); (2) the product object array, as adjusted during operation 422 (Figure 4B); and (3) the pay date object stored during execution of operation 454 (Figure 4D). In response, the generate-contract service 326 uses the lease ID to access the user's information (recall: the lease ID was created during the initial call to the get-customer-information service 320, in the course of operation 434, and is associated with the customer's information on the backend platform 308), generates the contract, filling in such information as the user's name and address, the particular products that are the subject of the lease, the payment terms (which may be looked up using the lease ID), the contractually- obligated due dates of the payments, and so on. According to some embodiments, the document is created as a portable document format (PDF) document, which is then uploaded by the backend platform 308 to a document storage cloud service 310, which stores the document, and returns a URL to the backend platform 308. (According to some embodiments, the extension 306 presents the "Just a Moment" screen of Figure 5H during the execution of operations 476 and 478.)

Next, in operation 480, the extension 306 opens an iFrame referencing the aforementioned URL, and the contract created during operation 478 and hosted by the document storage cloud service 310 is presented to the user in the iFrame, as depicted in Figure 5N. The document is signable (may be interacted with by the user to introduce his or her signature or initials), and according to some embodiments, is formatted as a signable PDF document. The user scrolls through the contract and initials and signs it in the appropriate locations (operation 482). Upon reaching the end of the contract, the user clicks to sign the final signature block 536 (operation 484) (see Figure 50), and the iFrame reponds by presenting a footer asking the user to check a checkbox 538 and click a "Click to Sign" button 540 to agree to the terms of service of the transaction provider (in this example, a lease-to-own company), and to ratify the various initials and signatures introduced by the user during the course of operations 482 and 484 (operation 486). The user checks the checkbox 538 and clicks the "Click to Sign" button 540 (operation 488).

In the wake of operation 488, the iFrame communicates the document - now initialed and signed - to the document storage cloud service 310, to be stored (operation 490). Receipt of the document by the document storage cloud service 310 causes the service 310 to access a document-cloud-service interface 334 executing on the backend platform 308 to deliver a message indicating that the contract has been signed by the user. In response, the document-cloud-service interface 334 stores this information in a manner accessible to the get-customer-progress service 322, which is also executing on the backend computing platform 308. While operation 490 is occurring, the "Processing" screen depicted in Figure 5Q may be presented (operation 492).

In the wake of operation 492, the extension presents a "Success" screen, such as the one depicted in Figure 5R (operation 494), and the user responds by clicking the "Continue" button 542 (operation 496). In response to the user having clicked the "Continue" button 542, the extension 306 polls the aforementioned get-customer- progress service 322 using the aforementioned GUID associated with the user to enquire about the progress of the particular user identified by the GUID as it pertains to execution of the contract, and awaits an indication from the service 322 that the customer, in fact, executed the contract (operation 498). In response, the service 322 accesses a storage location, such as a database record or a particular file or directory, for example, where such information concerning the successful execution of the contract is to be stored by the aforementioned document-cloud-service interface 334. If the storage location contains information indicating that the contract was executed, then the get-customer-progress service 322 responds to the extension 306 with a reply message so. Otherwise, it replies with a message indicating that the contract has not yet been fully executed. If the reply message indicates that the contract has not yet been fully executed, and if a threshold number of poll attempts have been made, the extension 306 does not permit advancement through the process, and, according to some embodiments, returns operational flow to operation 480 to reinitiate presentation of the contract. According to other embodiments, the process of Figures 4A-4G is exited altogether. On the other hand, if the response from the document-cloud-service interface 334 indicates that the contract was, in fact, executed, then operational flow advances operation 499.

At this stage of the process, the user has indicated which products he or she desires to lease, the products have been validated to determine which of them are eligible to be leased, and a contract has been signed between the user and the lease- to-own company establishing a lease-to-own arrangement between the user and the lease-to-own company relating to the eligible products. Next, according to some embodiments, the eligible products must be purchased by the lease to own company and delivered to the user. According to some embodiments, purchase of the products is conducted via a robotic process automation (RPA) system that operates upon the e- commerce website 302. In operation 499, the extension 306 initiates creation of a record within a database of an order to be effectuated by the aforementioned RPA. Specifically, in operation 499, the extension 306 accesses a create-order service executing on the backend platform 308 the information required to create the order record. According to some embodiments, the dataset includes: (1) the customer object stored by the extension in operation 436 (Figure 4C); (2) the product object array, as adjusted during operation 422 (Figure 4B); (3) lease ID returned in operation 434; (4) the total order cost calculated in connection with the construction of the screen of Figure 5K; (5) estimated agreement taxes (i.e., the sum of all taxes associated with eligible products and selected companion services), calculatable from the information returned by the transaction-terms service 324 in operation 456; (6) the date of the creation of the agreement, i.e., the current date; and (7) the agreement's total cost, as determined during the construction of the screen of Figure 5K.

Next, in operation 4990, the extension 306 posts a message to a messaging queue 702 of an RPA system executing on the backend computing platform (depicted in Figure 7A). (The messaging queue 702 and Figure 7A are discussed in more detail herein, below.) The message contains the information necessary for the RPA system to navigate the e-commerce website to conduct a purchase of the eligible products and to navigate the checkout process so as to pay for those products and have them delivered to the user's residence. According to some embodiments, the dataset communicated to the queue by the extension 306 includes the retailer ID, a lease ID, and the product object array. By virtue of having posted the aforementioned message to the messaging queue, the extension 306 has initiated the aforementioned RPA process. (According to some embodiments, the "Just a Moment" screen of Figure 5H is presented by the extension during the execution of operation 4990.)

In the wake of operation 4990, operational control is passed to operation 4992, in which the extension 306 constructs and presents the confirmation screen, as depicted in Figure 5S. The confirmation screen includes a statement confirming to the user that his or her order is being processed (i.e., the aforementioned RPA process has been initiated and is underway), and also presents the lease ID (example: 810708) and a reiteration of the user's remaining open-to-lease line, which was presented previously to the user on the screen depicted in Figure 51. The screen contains a "Continue Shopping" button 544. The user clicks the button 544 (operation 4994), and the extension 306 responds by removing the eligible items from the digital shopping cart. Thus, the digital shopping cart native to the e-commerce website 302 now contains only those items that could not be acquired via the sought-after transaction (i.e., the lease-to-own arrangement, according to this example). Finally, the extension 306 closes, removing its user interface from the web browser 304 (operation 4998), thus revealing the shopping cart, and thereby giving the user the opportunity to purchase the remaining items in the shopping cart via the native checkout process. According to some embodiments, the user conducts the purchase of the product himself or herself, instead of the purchase being conducted by the transaction system 300. For example, to effect payment, the customer may use a payment mechanism that draws upon funds of the transaction company (e.g., a lease-to-own company) or creates a debt for which the transaction company is responsible. Pursuant to these sorts of embodiments, the user completes the various data input fields on the various shopping cart pages and therefore may be free to arrange for delivery of the products to an address of his or her choosing, but the underlying products or services that are the subject of the alternative transaction (e.g., lease-to- own transaction) are paid for by the transaction company, and the transaction company ordinarily initially takes title to such products or services. These embodiments may also be advantageous for other reasons, discussed below. Such other embodiments wherein the customer is given autonomy over the data entered into the various shopping cart pages are discussed in detail, below.

Discussion now turns to operation of the validation service 316 (depicted in Figure 3), which was previously referenced in connection with operation 430 (depicted in Figure 4B). Figure 6 depicts the validation service 316, according to certain embodiments. As discussed in connection with Figure 4B, the extension (such as extension 306) sends a set of data 600 to a validation service to identify the eligible items from amongst those in the shopping cart of the e-commerce website. The data set 600 may include, for example, the aforementioned product object array and an indication of the particular e-commerce site with which the extension is interoperating (example: a retailer ID or domain of the e-commerce site).

In operation 602, the validation service of Figure 6 responds by using the indication of the of the particular e-commerce site with which the extension is interoperating to access a whitelist customized for that particular e-retailer. The whitelist is a set of SKUs corresponding to eligible products from amongst the aforementioned e-retailer's product offering. Thus, the validation service uses the indication of the of the particular e-commerce site with which the extension is interoperating to access the particular whitelist corresponding to that particular e- retailer, and determines whether or not the SKU is on the whitelist. If it is, then the product is declared eligible (operation 604).

On the other hand, if the SKU is not on the aforementioned whitelist, it may be the case that the whitelist is not exhaustive, for one reason or another (example: perhaps the e-retailer recently altered its product offering to include new products, which have not been evaluated for inclusion on the whitelist). To address the issue of potential incompleteness of the whitelist, control is passed to operation 606, wherein the dataset 600 is examined to determine whether it includes category data. If so, operational flow is passed to operation 608. In operation 608, the category information pertaining to a particular product is compared to a whitelist of categories uniquely created for each particular e-commerce website with which the extension may interoperated with. Thus, assuming, for example, that the dataset 600 revealed that the e-retailer was Best Buy, and assuming that the category information was categoryi = "Audio", category? = "Home Audio", category? = "Speakers", then in operation 608, the whitelist pertaining to Best Buy is examined to see whether products categorized under the trio of "Audio", "Home Audio", "Speakers" are eligible (i.e., is there a record in the category whitelist corresponding to Best Buy containing "Audio" in a categoryi field, "Home Audio" in a category? field, and "Speakers" in a cagegory? field?). If so, then the dataset is examined to determine the price of the product, and it is compared to a threshold (example: $300) (operation 610). If both (1) the product categories are whitelisted, and (2) the price of the product exceeds the aforementioned threshold (see "AND" gates 612 and 614), then the product is approved as eligible (operation 616). Thereafter, if a particular product was declared eligible on the basis of its category information, the aforementioned SKU whitelist for the relevant e-retailer is updated to include the SKU contained in the dataset 600 (operation 618). If, on the other hand, either test fails, then the product is declared ineligible.

In the event that the dataset 606 does not include category data, then the product name or description is examined instead of category data (operation 620). In operation 620, the product name or description is compared against a blacklist of keywords or phrases uniquely created for each e-commerce website with which the extension may interoperate (i.e., one blacklist for each such site), and it is required that the product name or description contain no such blacklisted keyword or phrase. Additionally, the product name or description is compared against a whitelist of keywords or phrases uniquely created for each e-commerce website with which the extension may interoperate (i.e., one keyword whitelist for each such e-commerce website), and it is required that the product name or description contain at least one whitelisted keyword or phrase. If both conditions are met, and if the price of the product exceeds the aforementioned threshold (see "AND" gates 622 and 624), then the product is approved as eligible (operation 626). As was the case in the wake of operation 616, in the wake of operation 626, if a particular product was declared eligible on the basis of its keyword information, the aforementioned SKU whitelist for the relevant e-retailer is updated to include the SKU contained in the dataset 600 (operation 618).

Discussion now turns to an embodiment of the aforementioned RPA process for purchasing the eligible goods from the e-commerce website in the wake of having completed the sought-after transaction. Figure 7A depicts an embodiment of a computerized system 700 for performing such a process. The system includes a messaging queue 702 that receives the messages sent from the extension to initiate execution of the process, such as may occur during execution of operation 4490 (Figure 4G). Introduction of a new message into the queue 702 generates an event that is responded to by an event-drive process 704, which, according to some embodiments, is dynamically allocated computing resources and executed in response to the occurrence of such an event. The process extracts the aforementioned message from the queue and enters into a database 706 as a new record. A computerized robot ("bot") 708 responds to the creation of such a new record by reading the record, and performing an RPA process to purchase the goods described by the record. According to some embodiments, the bot may be embodied as a web browser automation system, such as Selenium web browser automation tool, which performs actions within web browsers without necessitation of human effort, i.e., "robotically." Certain embodiments of the process performed by the bot are depicted in Figures 7B and 7C. Initially, the hot responds to the acquisition of a new record from the database 706 by examining the record to determine from which particular e-commerce website the products within the record are to be purchased. The bot 708 launches a (headless, according to some embodiments) instance of a web browser, navigates to the particular e-commerce site from which the products that are the subject of the record are to be bought, and logs into a user account pre-established in the name of the transaction company (lease-to-own company, in the context of the present example) on the aforementioned e-commerce site (operation 710).

In the wake of operation 710, the bot performs a loop defined by loop limit indicators 712 and 728 for each of the products referenced in the record. In operation 714, the bot 708 determines whether the product to be purchased should be accessed by use of a URL directly referencing a given product's product detail page, or whether a search function native to the e-commerce site should be used. In the event that a URL is to be used to access the product detail page corresponding to the particular product referenced by the loop limit indicator 712, the bot 708 navigates to the product detail page by entering the aforementioned URL into the URL bar of the web browser (operation 716), and then adds the product to the cart by clicking an "Add to Cart" button located on the product detail page (operation 726). Thereafter, the next product referenced in the record is operated upon (see loop limit indicator 728), if such next product exists. On the other hand, if in the course of operation 714 it is determined that the search function native to the e-commerce website should be used to navigate to the product description page, the operational flow is passed to operation 718.

In operation 718, the aforementioned search function is employed using a unit of data extracted from the aforementioned record. For example, the bot 708 may enter the SKU of the product to be purchased into the search function of the e- commerce website. Alternatively, the bot 708 may enter the product name into the search function, and any other unit of data within the record that will cause the search function to uniquely present the product description page corresponding to the product. After having used the employed function in operation 718, the bot 708 examines the page returned by the function to determine whether it presents more than a single product (for example, a product description page may, in some instances, present multiple products, such as different colors of the same sofa - all of which are associated with the same product name, SKU, and so on) (operation 720). If the product description page presents more than one product, the hot 708 is presented with an ambiguous scenario, and control is therefor passed to operation 722, wherein the bot 708 examines the aforementioned record to determine if there is another unit of data in the record as yet unused as a search term in operation 718 (operation 722). If so, the search process of operation 718 is repeated. If not, then the bot 708 declares an exception (operation 724), which is recorded in the aforementioned database 706, in order to indicate: (1) that the order was not placed robotically; and (2) the particular reason that the bot 708 did not place the order. According to some embodiments, personnel of the transaction company (in the context of this example, a lease-to-own company) then handle the process of acquiring the product from the website manually. Returning to the topic of operation 720, if in the course of that operation it is determined that the product description page contains only a single product, then the scenario does not present the bot 708 with ambiguity, and the bot 708 adds the product to the cart (operation 726) and proceeds on to the next product (see loop limit indicator 728). Assuming that there exists no next product, then operational flow is passed to operation 730 (see Figure 7C).

In operation 730, the bot 708 enters the cart and initiates the checkout process. In response, the e-commerce website presents a summary screen that details the particular items in the cart and the total cost of the check process, including tax (i.e., the aggregate cost of each product, including tax), so that the user - in this case, the bot 708 - can review the information to ensure it is correct. The bot 708 examines the information on the screen to ensure that it does not violate any business rules (operation 732). For example, if the total cost, including tax, is greater than that which was presented to the user during the transaction process (such as via the "Total Cost of Items" element on screen depicted in Figure 51), or greater than such amount by a threshold quantity, then control is passed to operation 724, and an exception is declared, with the same consequences as described previously (recall: the "Total Cost of Items" value was based, in part, on an estimated tax value delivered by a tax estimation service 318, and may be different than the actual tax value calculated by the e-commerce website). On the other hand, if no business rule is violated, then control is passed to operation 734, and the bot completes the checkout process by setting the delivery location equal to the user's residence, and paying for the item. According to some embodiments, the item is paid for with a purchasing card (P-card) titled in the name of the transaction company. According to some embodiments, the delivery location may be set equal to another location, such as another address determined by the user. Finally, in operation 736, it is determined whether the total cost, including tax, is less than that which was presented to the user during the transaction process. If this is the case, then the user would have been over-charged for the transaction (such as the exemplary lease-to-own transaction), and the contract establishing the transaction is updated to reflect the proper price, thereby rectifying any such over-charge situation (operation 738).

Figures 8A and 8B depict certain exemplary embodiments of a communication relay process 336 executing on the backend platform 308. The purpose of the communication relay process 336 is to receive emails that are sent by the various e-retailers for which the products were purchased on behalf of users, to restructure those emails so as to be appropriate for receipt by the users, and to send such restructured emails to the users.

According to some embodiments, a unique email address is created to correspond to each e-retailer with which the extension is designed to interoperate with. Thus, the user account created on behalf of the transaction company at e- commerce website #1 identifies email address #1 as the appropriate contact email address, while the user account created on behalf of the transaction company at e- commerce website #2 identifies email address #2 as the appropriate contact email address, and so on. Therefore, at any such given email address, all of the inbound email originates from a single particular e-retailer, and therefore conforms to a single, known, structure at any given point in time. The process of Figure 8A operates upon each such email inbox. The process begins by observing a given email inbox (operation 800) and determining whether a new email has been delivered thereto (operation 802). In response to a new email having been received, the particular variety of email is determined (operation 804). If the email is of certain varieties, the relevant data from the email will be parsed from it and stored in a database. For example, if the email is if a variety indicating that a given retailer has shipped the ordered product, the information pertaining to the shipment (order number, delivery address, shipping date, anticipated delivery date, tracking number, carrier, and so on) is parsed from the email and stored as a record in the data base (operation 806). As another example, if the email is if a variety indicating that a given order has been delivered, the information pertaining to the delivery (date, order number, carrier, tracking number, and so on) is parsed from the email and stored as a record in the data base (operation 808).

Another process observes the database (operation 810) and awaits the creation of a new record therein (operation 812). In response to a new record having been created, the proper recipient of the email is determined (example: by using the order number to trace the order to a given user), and the information from the record is sent as a message to an email delivery engine (operation 814). The engine uses the information to populate a normalized email body corresponding to each type of email intended to be forwarded to users (example: shipping emails and delivery emails). According to some embodiments, the aforementioned order number assigned to a given order by an e-retailer is not included in the information set used to populate such email bodies, so that the users receiving such emails possess neither a receipt, nor sufficient information to complete a return process with an e-retailer. Such embodiments may be appropriate for lease-to-own companies, for example, wherein a return of a leased product by a user to the e-retailer (versus a return to the lease-to- own company) is antithetical to the underlying transaction. According to other embodiments, the aforementioned order number assigned to a given order by an e- retailer is, in fact, included in the information set used to populate such email bodies.

Previously, it was mentioned that according to certain embodiments, the customer is permitted freedom to autonomously complete the various pages of the e- commerce site's digital shopping cart. One previously mentioned advantage to such embodiments is that the customer is free to designate a delivery address or method of his or her choosing method (example: arrange for a pick up at a retailer location, arrange for overnight delivery or standard delivery, and so on). Another advantage arises from the possibility that, pursuant to previous embodiments, the various goods and services that are paid for by the transaction system on behalf of the customer (such as via the previously described RPA scheme) may be paid for using the transaction card number that does not vary significantly from payment to payment (example: all such payments may be conducted using a single payment card number, or may be conducted using a payment card number selected from a relatively small fleet of cards). Moreover, such payment operations may be conducted via communication sessions with an IP address that does not vary significantly from payment to payment (example: all such payments may be conducted via communication session with an IP address corresponding to the computing facility at which the RPA system is operating, or from an IP address determined by an IP rotation scheme employing a relatively unnumerous quantity of IP addresses in comparison to the quantity of payment transactions to be conducted). Still further, such payment transactions may be conducted by a same user account of the e-commerce site that does not vary significantly from payment to payment (example: all such payments may be conducted by a single user account held by the transaction company, or by a relatively unnumerous pool of such accounts in comparison to the quantity of payment transactions to be conducted). Under such circumstances, if on a given day a quantity of one-thousand products were to be transacted to various customers by the transaction system from a given e-commerce site with which the transaction system interoperated, then it could be the case that from the vantage of the operator of the e-commerce site, during the course of the aforementioned given day, a singular user account on the e-commerce site, connected thereto from a singular IP address, paid for one-thousand products using the same transaction card, but arranged for those products to be delivered to various (perhaps geographically diverse) addresses. Such a scenario could present the appearance of fraud, despite the reality that no fraudulent activity was transpiring. In response, the operator of the e-commerce site, or the security systems overseeing the operation of the site, may suspend the operation of the aforementioned user account, or suspend inbound connections from the aforementioned IP address, or refuse payments from the aforementioned transaction card, or otherwise take steps to prevent payment transactions initiated by the transaction system from taking place. Such a response would be detrimental to the transaction system, as it would become unable to acquire the goods that were required for fulfillment of the underlying transactions with its customers. However, according to embodiments wherein each customer is permitted autonomy to complete such online transactions using a payment card with a card number corresponding uniquely to each such customer or each such payment transaction, then each payment transaction will be conducted by a unique user account (corresponding to the particular customer conducting each such payment), from a unique IP address (corresponding to the particular IP address from which each such customer is connected to the e-commerce site), using a unique transaction card number (corresponding to the particular customer conducting each such payment, or corresponding to the particular payment transaction being conducted). This outcome would present a normal outward appearance, and would not raise the prospect of the operator of the e-commerce site, or the security system overseeing its operation, interfering with the payment transactions intended to fulfill the needs of the transaction system.

The operational flow of exemplary embodiments of such a system is depicted in Figures 9A-9E (depicting operational steps carried out by a browser extension, according to such embodiments) and 11A-11D (depicting operational steps carried out by a backend platform of the transaction system), and a depiction of embodiments of such a system is depicted in Figure 10. For the sake of brevity, Figures 9A-9E, 10, and 11A-11D chiefly focus on operations and aspects that have not been previously described. Material previously described is either referenced briefly for the sake of narrative completeness, or omitted where narratively feasible.

Turning to Figure 10, the system includes a web browser 1000, that is accessed by a user in order to shop online via an e-commerce site 1002 presented by the browser 1000. An extension 1004 executes on the browser 1000 and interacts with the e-commerce site 1002 in order to provide the user with an option to acquire products and services offered for sale by the e-retailer via an alternative transaction arrangement (such as via a lease-to-own or subscription-based arrangement, or other arrangements of the sort). The extension 1004 is generally structured (and operates) according to principles described previously herein, and for the sake of brevity, these details are not repeated. The system of Figure 10 also includes a backend computing platform 1006 operated by or on behalf of the transaction company. Although depicted as singular platform, the backend platform 1006 may be constituted of several different computing platforms hosted at physically separate locations that cooperate with one another to function as described herein. The platform 1006 provides the capabilities previously described, unless stated otherwise, and details relating to such capabilities are not reiterated here, for the sake of brevity. The system also includes a payment processor platform 1016 that performs a role that is parallel to the role performed by the payment processor platform 312 (Figure 3) described previously, and also includes an issuer processor platform 1018, the purposes of which are described herein, below.

During operation of the system of Figure 10, the web browser 1000 launches the extension 1004 in response to the user having navigated to an e-commerce website 1002 with which the extension 1004 interoperates, as described previously, and as depicted in operation 900 of Figure 9A. In the wake of having been launched, the extension 1004 monitors the user's actions and navigational path through the e- commerce website 1002, and detects events in which the user adds products or services to website's 1002 digital shopping cart, using techniques parallel to those described previously (operation 902). In response to having detected an item having been added to the digital shopping cart, the extension 1004 scrapes information from the active page (such as a product detail page), assembles it into a product object, and adds it to a product object array, again, in a manner parallel to that which was described previously. According to some embodiments, this aspect of operation 902 is optional, and the various product objects corresponding to the products in the digital shopping cart are constructed and populated into the product object array at a later step, such as during an operation performed when the entry page of the digital shopping cart is active (see, for example, operation 910 - discussed below). In the event that the informational content available to be scraped by the extension 1004 at such later point is the same as - or lesser than only in unimportant ways - that which is available if scraping were to be performed in operation 902, then the scraping operation of 902 would be largely redundant of a scraping operation performed at a later stage, and it may be omitted from the process in favor of such later scraping process.

In operation 904, the URL bar of the web browser 1000 is examined to determine whether it contains the URL corresponding to the entry point page of the digital shopping cart of the particular e-commerce web site 1002 currently interoperating with the extension 1004 (details pertaining to this inquiry were presented previously). If not, then operational control returns to operation 902, and the actions and navigational path of the user are monitored until such time as the user navigates to the entry point page of the shopping cart. Upon entering the shopping cart, control is passed to operation 906, whereupon the extension 1004 adds a userinput element, such as a button, to the entry point page of the digital shopping cart in order to permit the user to elect to acquire the goods and services in the shopping via the alternative transactional arrangement, if they are of a suitable nature. Addition of such a user-input element was discussed previously.

In the wake of having added the aforementioned user-input element to the shopping cart page, the extension 1004 awaits an event in which the user clicks such element (operation 908), and in response thereto, the extension 1004 passes control to operation 910 (otherwise, the user's progress through the shopping cart progresses according to the native design of the shopping cart, itself). In operation 910, the active shopping cart page is scraped for its item content. According to embodiments wherein the scraping activity of operation 902 is omitted, the informational content pertaining to each item presented on the entry point page of the shopping cart is used to construct a product object on a one-product-object-per-item basis, in a manner parallel to that described previously. Each product object is then added to the aforementioned product object array. These steps have been previously described in detail and for the sake of brevity are not elaborated upon here. According to embodiments in which the scraping activity of operation 902 is not omitted, then the product objects already in the product object array prior to performance of operation 910 are compared to the informational content developed by the scraping operation of the present operation 910. If any items identified during the present scraping operation 910 are absent from the product object array, then their information content is assembled into a product object and added to the array. If the product object array contains product objects that do not correspond to any item identified during the scraping action of operation 910, then any such product objects are removed from the array. Details pertaining to these operation (including the purposes thereof) have been described previously and are not repeated here. In the wake of operation 910, then, the product objects of the product array correspond to the items contained in the digital shopping cart.

Next, in operation 912, the extension 1004 communicates with the backend computing platform 1006, such as with a validation service hosted by the platform 1006, in order to determine what portion of the product objects within the array corresponds to items that are eligible as subjects of the sought-after alternative transaction arrangement. Details pertaining to this have been presented previously and are not reiterated here. In operation 914, it is determined whether the product object array contains any ineligible items. If so, then the extension 1004 presents a screen (in a lightbox, for example) atop the digital shopping cart, identifying the ineligible items and instructing the user to remove those items from the digital shopping cart (operation 916). The user closes the aforementioned window, and is returned to the shopping cart to either comply, and then re-initiate the alternative transaction arrangement via the user-input element added to the entry point page in operation 906, or to checkout using the native capabilities of the shopping cart (operation 908). On the other hand, if the product object array does not contain any ineligible products, then control is passed to operation 918.

Operation 918 is optional. In operation 918 a speedbump screen is presented. A speedbump screen is a screen that explains the nature of the alternative transaction in simple terms. The purpose of such a screen is to ensure that the user understands that he or she is embarking on a path to acquire the items in the digital shopping cart pursuant to an alternative transactional arrangement, rather than purchasing the items. Other means of ensuring consumer awareness of the nature of the alternative transactional arrangement are possible and will readily present themselves to the minds of those of ordinary skill in the art.

In the wake of the user dismissing the speedbump screen, the extension 1004 programmatically clicks the shopping cart's native "checkout" button, meaning that the user is presented with the various pages of the shopping cart in a manner determined by the native software instructions making up the digital shopping cart. The user interacts with the shopping cart pages as though he or she were conducting an ordinary payment transaction. As the user does this, the extension 1004 monitors the user's progress through the shopping cart (operation 922), and determines when the user has reached the particular page of the shopping cart at which payment information is to be entered (see operation 924). Such a determination may be made, for example, by monitoring the URL in the web browser's 1000 URL bar, and determining whether it matches the URL corresponding to the "payments" page. When it is determined that the user has reached the "payments" page of the shopping cart, control is passed to operation 926.

Operation 926 is parallel to operation 910: the item information presented on the "payments" page of the shopping cart is scraped, and used to adjust the product object array, as described previously. The purpose of this operation 926 is account for any items, including service items or companion items, that may have been added to the shopping cart in the intervening navigational journey between the entry point page (when the product object array was last adjusted so as to correspond with the items in the shopping cart) and the "payments" page. Operation 926 may be necessary, for example, because the shopping cart may be structured to permit the user to add service items or companion items to the shopping cart prior to payment. (Example: in the event that a user initially had added a flatscreen television to his shopping cart prior to initiating the checkout procedure, then in between his or her journey from the entry point page to the "payments" page, the user may be offered the opportunity to add service items or companion items, such as installation services or an extended warranty to protect the television - such items would not be reflected in the product object array as it was constituted in the wake of operation 910, and, furthermore, such items may not be the proper subjects of the sought-after alternative transactional arrangement, necessitating the ensuing operations 928, 930, 932 and 934.)

In the wake of adjusting the product object array in operation 926, each product object therein is inspected to determine whether it corresponds to a product or service that is the proper subject of the sought-after alternative transactional arrangement (operation 928). Operation 928 is performed by the extension 1004 via communication with the backend platform 1006, in a manner parallel to that which was discussed previously. Next, in operation 930, it is determined whether the product object array contains any product objects corresponding to products or services that are ineligible for the sought-after alternative transaction arrangement. If so, a screen is presented (for example, in a lightbox) identifying such ineligible items, and directing the user to remove such items from the shopping cart before proceeding, as a condition of creation of the alternative transactional arrangement (operation 932). After dismissal of the aforementioned screen by the user, the user is once again presented with the "payments" screen. The user may elect to ignore the instructions to remove the items, and may simply pay for the items by filling in the "payments" screen with information corresponding to a payment card belonging to him or her, and the result is that the remainder of the digital shopping cart experience will unfold as natively determined by the software instructions natively making up the shopping cart, thereby resulting in a purchase of the items by the user, funded by the aforementioned transaction card. On the other hand, the user may elect to remove such ineligible items, and thereafter may re-initiate pursuit of the alternative transactional arrangement by clicking a user-input element placed on the "payments" screen by the extension 1004. Such user-input element may be structured as a "bug," which is a small, non-intrusive element, typically located along the periphery of a webpage. If the extension 1004 detects the occurrence of an event whereby the user has clicked the aforementioned user-input element (operation 934), control is returned to operation 930, whereupon the product object array is reinspected for the presence of ineligible product objects. If no such ineligible product objects are present in the array, then control is passed to operation 936. In operation 936, a lightbox is presented atop the "payments" screen, thereby preventing the user from interacting with the "payments" screen while the lightbox is presented. Within the lightbox, the extension 1004 presents a succession of screens to guide the user through the process of: (1) logging in; (2) reviewing his or her open-to-transact line (discussed previously); (3) reviewing a summary of the proposed terms of the alternative transactional arrangement concerning the goods or services in the product object array; (4) reviewing and executing a contract that effects a contractual arrangement between the user and the alternative transaction company, so as to create the aforementioned transactional arrangement concerning the goods or services in the product object array; and (5) initiating an initial payment to the alternative transaction company, pursuant to the aforementioned contract. Examples of operational flows to support such actions have been previously presented herein, and for the sake of brevity are not repeated here.

In operations 938 and 940, the extension polls a user progress service hosted by the backend platform 1006, awaiting a response from the platform 1006 that indicates that the initial payment conducted by the user during operation 936 has, in fact, been completed. Details pertaining to exemplary interactions between the extension 1004 and backend platform 1006 so as to provide the extension 1004 with updates concerning the occurrence or non-occurrence of certain events related to the alternative transaction that were conducted on other platforms (such as on the payment processing platform 1016, which, in this case, participated in the transaction by processing the aforementioned initial payment) have been described previously and are not repeated here. Upon receiving a response from the backend platform 1006 indicating that the initial payment was, in fact, completed, then it would be the case that: (1) the user selected one or more items from the e-commerce website 1002 to acquire via an alternative transactional arrangement; (2) each of the items were validated, thereby confirming that they are the proper subject of such alternative transactional arrangement; (3) the user and transaction company entered into a contract effecting such alternative transactional arrangement, with the aforementioned items being the subject of such contract; and (4) an initial user payment required by such contract was confirmed to have been completed. At this stage, the particular actions that are the prerequisites of initiating a process to provide the user with means by which he or she may complete the "payments" page have been completed. Thus, the extension 1004 may proceed with actions that will result in the provision of a payment card number to the user, to permit the user to make payment for the items on behalf of the transaction company (the transaction company will pay for the items, take title to the items, and make the items available to the user pursuant to the alternative transactional arrangement - the items will be delivered to the user by the e-retailer according to the delivery option selected by the user during the course of his navigation through the digital shopping cart).

To initiate the process of providing the customer with a payment card number that he or she may use in connection with obtaining the items that are the subject of the alternative transactional arrangement, the extension 1004 communicates with the backend platform 1006, sending it a contract approval data set (operation 942). A contract approval data set is a set of data that indicates: (1) that a particular customer entered into a contract on a particular time and date; (2) concerning items from a particular e-retailer; (3) wherein such items have particular prices indicated in the contract approval data set. According to some embodiments, the backend computing platform 1006 hosts a contract status tracking service 1010, with which the extension 1004 interacts with in order to communicate the fact that a contract has been entered into, and to acquire the capacity to provide the user with the aforementioned payment card number.

In response to receiving the contract approval data set, the backend platform 1006 performs the operations depicted in Figure 11A. The act of receiving the contract approval data set, such as via a web-accessible API exposed as an endpoint by the backend platform 1006, is depicted as operation 1100. Next, in operation 1102, the contract status tracking service 1010 creates a contract object containing the information from the contract approval data set, and commits the object to a data store, such as a database, accessible by the service 1010. The contract status tracking service 1010 sets a status attribute or field associated with the contract object to a value indicating that the contract is not yet ready to fund, i.e., conditions are not yet proper for the platform 1006 to initiate transfer of funds to an account designated for payment of e-retailers (such accounts are discussed herein, below).

Next, in operation 1104, the contract status tracking service 1010 sends a message to an authorization interface service 1012 to instruct it to initiate the creation of a payment card for the user, and to fund an account associated with the aforementioned payment card. Prior to further discussion of operation 1104, some background information is required.

According to some embodiments, the aforementioned payment card is issued by a financial institution (example: a bank) associated with the issuer processor that operates the issuer processor platform 1018. Each payment card may be associated with a particular user and bear (or be associated with) a unique card number associated with the aforementioned user. Each such card may be titled in the name of the alternative transaction company, with the aforementioned particular user being specified as an authorized user of the particular payment card that has the card number associated with him or her. Thus, a user may use the particular aforementioned payment card (as an authorized user), with the funds drawn upon for effecting payment from such card being sourced from the transaction company. For example, each such card may be a stored-value card, meaning that each such card is associated with a financial account - a stored value account - that is to contain the necessary funds to properly source money for the particular payment transaction initiated by the user. The transaction company may store money that it has designated for funding of such stored value accounts in a master account maintained at the financial institution that issues the stored value cards and maintains their corresponding stored value accounts. Each time the issuer processor platform 1018 receives an instruction to create a payment card for a particular user (for use by the user to conduct a particular payment transaction of a particular aggregate amount), the aforementioned financial institution (via the issuer processor platform 1018) may, in near real-time, open a new stored value account for that particular user, and fund it with money in an amount equal to the aforementioned particular aggregate amount (or in an amount slightly greater than the aforementioned aggregate amount, to allow for any imperfections in correctly specifying the aggregate payment amount). Thus, each payment card is created for a user and funded in a just-in-time fashion, in response to receipt of a command to do so by the issuer processor platform 1018. Each such card may be virtual, meaning that it exists as an account number in a data store maintained and operated by the issuer processor via its platform 1018, but is not associated with a physical card. Alternatively, each such payment card may indeed be embodied as a physical card that is delivered to the user in a follow-up operation performed at a later time. Each such card may be usable a single time (a "one-time card") or may be usable over the course of a plurality of transactions until such time as it expires or is canceled or otherwise suspended by the issuer. For the sake of grounding the present discussion in a concrete example, the cards herein are assumed to be virtual one-time cards. The invention is not limited to virtual one-time cards, and the principles and teachings disclosed herein will be understood by those of skill in the art to apply to physical cards, as well as reusable cards.

With this background in place, discussion now returns to operation 1104. The authorization interface service 1012 is a unit of software operating on the backend platform 1006 that is responsible for interacting with the issuer processor platform 1018, in order to: (1) command it to create a payment card for use in connection with a payment transaction required to acquire an item for a customer pursuant to an alternative transactional arrangement concerning one or more items desired by the user from an e-commerce site 1002; and (2) to handle authorization requests directed to such card as they are routed inbound from a payment network on which such cards are operable (example: Mastercard, Visa, etc.). The authorization interface service 1012 therefore responds to receipt of the message described with reference to operation 1104 by sending a command to a card creation service 1020 operating on the issuer processor platform 1018, instructing it to issue a one-time virtual card to a particular user, and to fund a payment to be conducted with the just-created card in a particular aggregate amount (operation 1106). The issuer processor platform 1018 responds by opening a stored-value account for the designated user, and transferring money from the aforementioned master account into the stored value account, in an amount equal to (or greater than by a designated tolerance - example: 2% or 5%, etc.) such aggregate amount. In response to sending a command to the card creation service 1020 in operation 1106, the authorization interface service 1012 receives a reply therefrom with an access token (operation 1108). An access token is a unit of data that is usable by software within the browser extension 1004 to present an iFrame containing the card number associated with the one-time virtual card just created for the user, so that the user may learn of the card number that has been just issued to him or her and thereby utilize it in connection with completing the "payment" screen of the digital shopping cart. The iFrame is discussed further, below. In response to receiving the access token, the authorization interface service 1012 communicates it to the contract tracking service 1010, which, in turn, makes the access token available to the browser extension 1004 at a secure web-accessible endpoint (i.e, an API) exposed to a network such as the Internet via the backend computing platform 1006.

Discussion now returns from its focus on the response of the backend platform 1006 to having received the contract approval data set from the extension 1004 in connection with operation 942 of Figure 9D, to the operations the extension 1004 performs in the wake of having completed operation 942. In the wake of having sent the contract approval data set to the backend platform 1006, the extension 1004 polls the authorization interface service 1012 for the access taken (operations 944 and 946). Although Figure 9D depicts a potentially interminable polling process - as literally depicted, the extension will poll endlessly awaiting the availability of the access token - such depiction is for the sake of simplicity. The polling process depicted by operation 944 and 946 should be understood to include logic to impose a time-out exception, wherein after a period of time the polling process halts if the access token is not made available, and an error message is presented to the user.

When the access token is made available, the polling process is exited, and control is passed to operation 948. In operation 948, the access token is used as an input or argument to a function or method call in order to present a screen that presents the card number that was issued to the user in response to the extension having supplied the backend platform 1006 with the contract approval data set in operation 942. For example, according to some embodiments, the extension 1004 may include a software development kit (SDK) published by the issuer processor that operates the issuer processor platform 1018. The SDK may be structured to accept the access token as an input or argument, and, upon its invocation, use the access token to securely communicate with the issuer processor platform 1018, retrieve data constituting a screen arranged to present the aforementioned card number, and thereafter to present an iFrame containing such screen in order to inform the user of the card number. The lightbox that was introduced in operation 936 is closed in connection with the presentation of the screen containing the card number, so that the user may interact with the "payments" screen, i.e., so that the user may fill in its various fields, including using the card number to fill in the particular field asking the user to supply a payment card number for use in connection with the payment transaction. An example of an iFrame 1200 presenting such card number data 1202, for the user to enter into a payment card field 1204 of a "payments" page 1206 is depicted in Figure 12.

The user responds to presentation of the screen 1200 bearing the card number 1202 by copying the card number 1202 into the payment card field 1204 (operation 950). In the wake of completely filling out the "payments" screen 1206 and clicking a button 1208 provided on the page 1206 (entitled "place my order") to indicate that the user is ready to initiate payment, the digital shopping cart interacts with a payment processor, sending it the required payment information (payment card number, payment amount, etc.), which, in turn, communicates such information to the payment network on which the payment card is operable. The payment network responds to this by directing an authorization request to the issuer processor platform 1018, which is operating on behalf of the issuer of the payment card. An authorization request is a data exchange in which the payment processor is asked to authorize or decline the payment transaction on the basis of the information supplied to the payment processor by the shopping cart (example: the retailer ID code that identifies the retailer at which the payment transaction is being conducted, the payment card number, the payment amount, the date and time of the transaction, and so on). In the context of the exemplary embodiment of Figure 10, the authorization request is routed from the issuer processor platform 1018 to the authorization interface service 1012, which receives the request and responds thereto in near real-time (operation 1112, Figure 11B). According to some embodiments, the authorization interface service 1012 uses the information communicated to it by the contract tracking service 1010 during operation 1104 to establish authorization criteria. According to some embodiments, the authorization interface service 1012 creates a whitelist entry in a list that it maintains, such as in a table within a database. Each entry or record in the list corresponds to a transaction that is to be approved, on account of its correspondence with a contract object. Each entry may include: a date and time of its creation (example: the approximate date and time of execution of operation 1104); a merchant identifier associated with the retailer at which the user was shopping; the payment card number; and the payment amount. According to some embodiments, the authorization interface service 1012 may authorize a given authorization request if: (1) the authorization request includes a payment card number that matches an entry in the whitelist having the same card number, and, optionally, has never previously been the subject of an authorized transaction (in the case of a one-time card); (2) the aforementioned authorization request was received within a specified timeframe (example: 15 minutes) of the date and time information stored in the aforementioned whitelist entry; (3) the aforementioned authorization request includes a merchant ID that matches the merchant ID data stored in the aforementioned whitelist entry; (4) the aforementioned authorization request is for a payment amount that matches the payment amount data in the aforementioned whitelist entry; and (5) the billing address information entered by the user via the "payment" screen of the shopping cart passes an address verification service (AVS) check. According to some embodiments, a merchant category code (MCC) blacklist may be imposed by the authorization interface service 1012 so that if an authorization request includes MCC data that is included in the aforementioned blacklist, the authorization request is declined. Thus, according to some embodiments, an authorization request must match an entry within the whitelist pursuant to matching criteria described above, and, further, must not include MCC data included in the aforementioned blacklist, as a condition of the authorization interface service 1012 responding with an authorization. Finally, after approving an authorization request, the authorization interface service 1012 registers with a settlement webhook service 1024 executing on the issuer processor platform 1018, requesting that the service 1024 call back the authorization interface service 1012 in the event that the payment associated with the authorization request is settled, or in the event that such settlement fails, in order to inform the authorization interface service 1012 of either outcome (operation 1116).

In the wake of the payment being authorized, the e-commerce website 1002 presents the user with an order confirmation screen that confirms that the payment for the product was received, and the customer's items are being shipped. The presentation of such screen is detected by the extension in operation 952 (Figure 9E), such as by monitoring the URL data in the URL bar of the web browser 1000, as has been described previously. According to some embodiments, the extension 1004 scrapes an order ID number associated with the user's order and presented on the order confirmation screen (operation 954). Operation 954 is optional. Finally, in operation 956, information concerning the order is communicated to the backend platform 1006 for storage in an order database service 1014, such as by creation of a record therein corresponding to the aforementioned order. The record may include information identifying the e-retailer, the items that were the subject of the order; the date and time of the order; the address to which the items were shipped; the price of each item; a contract identifier associated with the particular contract that the order was intended to fulfill; and the order ID, among other information.

Previously, in connection with operation 1116, the authorization interface service 1012 was described as registering for a callback from the issuer processor platform 1018 in the event that the payment transaction was either successfully settled, or in the event that such settlement failed. Figure 11C depicts the operations of the backend platform 1006 in response to having received such a callback. The method of Figure 11C begins by the authorization interface service 1012 receiving a callback from the issuer processor platform 1018 carrying a set of data in its payload indicating either that a particular authorized payment was either successfully settled, or that such settlement failed (operation 1118). According to some embodiments, settlement of an authorized payment may be attempted in a batch process executed, for example, at some predetermined point in a business day. Thus, a period of several hours may elapse between authorization of a payment (operation 1112) and receipt of a callback related to such authorized payment. In operation 1120, the payload of the callback is examined to determine whether or not the settlement operation attempted in connection with the particular authorized payment referred to in the payload was successful.

In the event that the settlement operation failed, then control is passed to operation 1122, and the authorization interface service 1012 sends a message to the contract tracking service 1010 indicating that the settlement operation attempted in connection with a particular payment operation or contract identifier failed. In response, the contract tracking service 1010 initiates cancellation of the corresponding contract with the user by setting the status of contract object associated with the contract identifier or payment operation or identifier to a status indicating cancellation (example: a status of "canceled") (operation 1124).

On the other hand, if it is the case that the settlement operation succeeded, then control is passed to operation 1126, and the authorization interface service 1012 sends a message to the contract tracking service 1010 indicating that the settlement operation attempted in connection with a particular contract identifier or payment operation or identifier succeeded. In response, the contract tracking service 1010 updates the status the contract object associated with the contract identifier or payment operation or identifier contained in the payload of the callback to a status indicating successful settlement (example: a status of "settled") (operation 1128). Thereafter, the contract tracking service 1010 uploads the contract to a contract management system 1008 executing on the backend platform 1006 (operation 1130). The contract management system 1008 is used by systems and personnel of the transaction company to manage receipt of customer payments in connection with contracts stored therein, track late payments, initiate response activities to such late payments, and perform other such management activities related to tracking performance of the contract by the user. Finally, the authorization interface service 1012 registers with a payment refund webhook service 1026 executing on the issuer processor platform 1018, requesting that the service 1026 call back the authorization interface service 1012 in the event that the payment associated with the authorization request is refunded. Such a refund may occur in response to the user returning the item that was the subject of the alternative transactional arrangement. Recall: unlike the embodiments wherein the backend platform performed the payment operations and arranged for the items to be delivered to the customer, according to the present embodiments, the user does so, and is therefore furnished with the receipt for such item from the e-retailer (and other documentation pertaining to the payment transaction). According to the present embodiments, then, the user is therefore in the position to return the items to the e-retailer, whereas such return would not be possible pursuant to the previous embodiments because the user would not be able to demonstrate that he paid for the items, nor trace the payment of the items to a particular payment transaction that could be refunded.

In the event that the user returns an item that was the subject of an alternative transaction arrangement, thereby generating a refund of its related payment, or in the event that such payment was refunded for any other reason, the backend platform 1006 is called back by the issuer process platform 1018, and responds as depicted in Figure 11D. The method of Figure 11D begins by the authorization interface service 1012 receiving a callback from the issuer processor platform 1018 (operation 1134). The callback carries a set of data in its payload indicating that a particular previously settled payment was refunded, including, according to some embodiments, an indication of the monetary amount of such refund. Next, control is passed to operation 1136, and the authorization interface service 1012 sends a message to the contract tracking service 1010 indicating a refund of a particular amount was processed in connection with a particular previously settled payment or contract identifier. In response, in operation 1138, the contract tracking service 1010 either: (i) initiates cancellation of the corresponding contract with the user by setting the status of contract object associated with the payment operation or contract identifier to a status indicating cancellation (example: a status of "canceled"); or (ii) flags it for adjustment, such as manual adjustment performed by personnel of the alternative transaction company, by, for example, setting the status of contract object associated with the payment operation or contract identifier to a status indicating that adjustment is required (example: a status of "adjustment_required"). According to some embodiments, in the event that a user were to have entered into an alternative transactional arrangement pertaining to a plurality of items, and in the further event that such user returned only a subset of the aforementioned items, then the contract object corresponding to the aforementioned transactional arrangement may be flagged for adjustment, in order to rescind its applicability to the returned item(s), while maintaining its applicability to the particular item(s) that was not returned.

To perform the actions of the computer, laptop, tablet, smartphone, or portable device on which the web browser 104, 304 or 1000 executes, host the backend platform 108, 308 or 1006, the payment processor 312 or 1016, document cloud server 310, third party services 110, or issuer processor platform 1018, or execute any of the methods or schemes herein and/or embody any of the other previously mentioned computing devices, a computer or server system as illustrated in Figure 13 may be used. A networked system of such computers, devices or server systems may likewise be used. Figure 13 depicts a schematic illustration of one embodiment of a computer system 1300 that can perform the methods provided by various other embodiments, as described herein, and/or can function as the host computer system, a server system, a laptop, tablet, smartphone, a mobile device, and/or a computer system. It should be noted that Figure 13 is meant only to provide a generalized illustration of various components, any or all of which may be utilized as appropriate. Figure 13, therefore, broadly illustrates how individual system elements may be implemented in a relatively separated or relatively more integrated manner.

The computer system 1300 is shown comprising hardware elements that can be electrically coupled via a bus 1305 (or may otherwise be in communication, as appropriate). The hardware elements may include one or more processors 1310, including without limitation one or more general-purpose processors and/or one or more special-purpose processors (such as digital signal processing chips, graphics acceleration processors, and/or the like); one or more input devices 1315, which can include without limitation a mouse, a keyboard, touchscreen and/or the like; and one or more output devices 1320, which can include without limitation a display device, a printer and/or the like. The computer system 1300 may further include (and/or be in communication with) one or more storage devices 1325, which can comprise, without limitation, local and/or network accessible storage, and/or can include, without limitation, a disk drive, a drive array, an optical storage device, a solid-state storage device such as a random access memory ("RAM") and/or a read-only memory ("ROM"), which can be programmable, flash-updateable and/or the like. Such storage devices may be configured to implement any appropriate data stores, including without limitation, various file systems, database structures, and/or the like.

The computer system 1300 may also include a communications subsystem 1330, which can include without limitation a modem, a network card (wireless or wired), an infrared communication device, a wireless communication device and/or chipset (such as a BLUETOOTH™ device, an 802.11 device, a WiFi device, a WiMax device, cellular communication facilities, etc.), and/or the like. The communications subsystem 1330 may permit data to be exchanged with a network (such as the network described below, to name one example), other computer systems, and/or any other devices described herein. In many embodiments, the computer system 1300 will further comprise a working memory 1335, which can include a RAM or ROM device, as described above.

The computer system 1300 also can comprise software elements, shown as being currently located within the working memory 1335, including an operating system 1340, device drivers, executable libraries, and/or other code, such as one or more application programs 1345, which may comprise computer programs provided by various embodiments, and/or may be designed to implement methods, and/or configure systems, provided by other embodiments, as described herein. Merely by way of example, one or more procedures described with respect to the method(s) discussed above might be implemented as code and/or instructions executable by a computer (and/or a processor within a computer); in an aspect, then, such code and/or instructions can be used to configure and/or adapt a general purpose computer (or other device) to perform one or more operations in accordance with the described methods. A set of these instructions and/or code might be stored on a computer- readable storage medium, such as the storage device(s) 1325 described above. In some cases, the storage medium might be incorporated within a computer system, such as the system 1300. In other embodiments, the storage medium might be separate from a computer system (e.g., a removable medium, such as a compact disc), and or provided in an installation package, such that the storage medium can be used to program, configure and/or adapt a general purpose computer with the instructions/code stored thereon. These instructions might take the form of executable code, which is executable by the computer system 1300 and/or might take the form of source and/or installable code, which, upon compilation and/or installation on the computer system 1300 (e.g., using any of a variety of generally available compilers, installation programs, compression/decompression utilities, etc.) then takes the form of executable code.

It will be apparent to those skilled in the art that substantial variations may be made in accordance with specific requirements. For example, customized hardware might also be used, and/or particular elements might be implemented in hardware, software (including portable software, such as applets, etc.), or both. Further, connection to other computing devices such as network input/output devices may be employed.

As mentioned above, in one aspect, some embodiments may employ a computer system (such as the computer system 1300) to perform methods in accordance with various embodiments of the invention. According to a set of embodiments, some or all of the procedures of such methods are performed by the computer system 1300 in response to processor 1310 executing one or more sequences of one or more instructions (which might be incorporated into the operating system 1340 and/or other code, such as an application program 1345) contained in the working memory 1335. Such instructions may be read into the working memory 1335 from another computer-readable medium, such as one or more of the storage device(s) 1325. Merely by way of example, execution of the sequences of instructions contained in the working memory 1335 might cause the processor or processors 1310 to perform one or more procedures of the methods described herein.

The terms "machine-readable medium" and "computer-readable medium/' as used herein, refer to any medium that participates in providing data that causes a machine to operate in a specific fashion. In an embodiment implemented using the computer system 1300, various computer-readable media might be involved in providing instructions/code to the processor or processors 1310 for execution and/or might be used to store and/or carry such instructions/code (e.g., as signals). In many implementations, a computer-readable medium is a physical and/or tangible storage medium. Such a medium may take many forms, including but not limited to, nonvolatile media, volatile media, and transmission media. Non-volatile media include, for example, optical and/or magnetic disks, such as the storage device(s) 1325. Volatile media include, without limitation, dynamic memory, such as the working memory 1335. Transmission media include, without limitation, coaxial cables, copper wire and fiber optics, including the wires that comprise the bus 1305, as well as the various components of the communication subsystem 1330 (and/or the media by which the communications subsystem 1330 provides communication with other devices). Hence, transmission media can also take the form of waves (including without limitation radio, acoustic and/or light waves, such as those generated during radio-wave and infrared data communications).

Common forms of physical and/or tangible computer-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, or any other magnetic medium, a CD-ROM, any other optical medium, punchcards, papertape, any other physical medium with patterns of holes, a RAM, a PROM, EPROM, a FLASH- EPROM, any other memory chip or cartridge, a carrier wave as described hereinafter, or any other medium from which a computer can read instructions and/or code.

Various forms of computer-readable media may be involved in carrying one or more sequences of one or more instructions to the processor or processors 1310 for execution. Merely by way of example, the instructions may initially be carried on a magnetic disk and/or optical disc of a remote computer. A remote computer might load the instructions into its dynamic memory and send the instructions as signals over a transmission medium to be received and/or executed by the computer system 1300. These signals, which might be in the form of electromagnetic signals, acoustic signals, optical signals and/or the like, are all examples of carrier waves on which instructions can be encoded, in accordance with various embodiments of the invention.

The communications subsystem 1330 (and/or components thereof) generally will receive the signals, and the bus 1305 then might carry the signals (and/or the data, instructions, etc. carried by the signals) to the working memory 1335, from which the processor(s) 1305 retrieves and executes the instructions. The instructions received by the working memory 1335 may optionally be stored on a storage device 1325 either before or after execution by the processor(s) 1310.

The various embodiments described above are provided by way of illustration only and should not be construed to limit the invention. Those skilled in the art will readily recognize various modifications and changes that may be made to the present invention without departing from the true spirit and scope of the present invention, which is set forth in the following claims.