WO2025222134A1

WO2025222134A1 - Methods and software for providing web-based incentivization programs, and user interfaces for the same

Info

Publication number: WO2025222134A1
Application number: PCT/US2025/025391
Authority: WO
Inventors: Steven ROBYOR
Original assignee: Individual
Current assignee: Individual
Priority date: 2024-04-18
Filing date: 2025-04-18
Publication date: 2025-10-23
Anticipated expiration: 2026-10-18

Abstract

Web-based incentivization (WBI) software that allows business startups, existing businesses, and/or other providers to create and maintain their own online incentivization programs. In some embodiments, the incentivization programs are incentivized-funding programs (e.g., for startups) and/or discount / rewards programs (e.g., for existing businesses). In some embodiments: the WBI software is configured to allow providers to create program banners that the WBI software deploys to provider websites (e.g., startup / business websites) for visitors (end-users) to the provider websites to view and/or interact with the program banners; the WBI software is configured to allow each provider to create a plurality of incentive levels / types in which end-users may choose to participate; and/or each program banner contains information about a corresponding incentive level / type and a hyperlink to a webpage that allows end-users to participate in the incentivization program according to the selected incentive level / type.

Description

METHODS AND SOFTWARE FOR PROVIDING WEB-BASED INCENTIVIZATION PROGRAMS, AND USER INTERFACES FOR THE SAME

RELATED APPLICATION DATA

[0001] This application claims the benefit of priority of U.S. Provisional Patent Application Serial No. 63/635,722, filed on April 18, 2024, and titled “METHODS AND SOFTWARE FOR PROVIDING WEB-BASED INCENTIVIZED FUNDING PROGRAMS, AND USER INTERFACES FOR SAME”, which is incorporated by reference herein in its entirety for all purposes.

FIELD

[0002] The present invention generally relates to the field of web-based fundraising. In particular, the present invention is directed to methods and software for providing web-based incentivization programs, and user interfaces for the same.

BACKGROUND

[0003] Many fundraising websites, such as Kickstarter, GoFundMe, Indiegogo, and Fundly, among others, have cropped up over the years. Generally, these fundraising websites are owned by fundraising service providers that host fundraising pages for others on their own websites. In a typical scenario, each person or entity desiring to raise funds for a particular reason, i.e., each “fundraiser”, sets up a fundraiser account on the fundraising website and builds a fundraising landing page that is hosted on the fundraising website. A fundraiser may provide a link to the fundraising landing page on its own website so that prospective funders can access the fundraising landing page to learn more about the fundraising, but any funder or prospective funder only learns details about the fundraising program at issue by navigating to the fundraising website.

SUMMARY

[0004] In one implementation, the present disclosure is directed to a method of providing one or more incentives to end-users via a business website associated with a business. The method being performed by a computing system includes providing a program-builder user interface (UI) that allows a configuring user to create an incentivization program, wherein the program -builder UI allows the configuring user to configure a program banner to present an incentive level / type to the end-users on the business website, wherein the incentive level / type has an associated benefit, and the program banner includes a hyperlink that, when selected by an end-user, navigates to a page that allows that end-user to receive the associated benefit; generating website-presentation code that, when executed, presents the program banner on the business website; and deploying the websitepresentation code to the business website so that the program banner is accessible to the end-users on the business website.

[0005] In another implementation, the present disclosure is directed to a computer-readable storage medium containing computer-executable instructions for performing the method described in the paragraph immediately above.

[0006] In yet another implementation, the present disclosure is directed to a computer-readable storage medium containing computer-executable instructions that embody web-based incentivization (WBI) software that provides a plurality of functionalities for a business having a business website. The functionalities include program-building functionality that allows the business to create and maintain at least one incentivization program selected from the group consisting of an incentivized- funding (IF) program and a discount/reward (D/R) program, wherein the at least one incentivization program contains a plurality of incentive levels / types; program-banner-generating functionality that generates a program banner for each of the incentive levels / types, wherein each program banner includes a hyperlink that allows an end-user to select to participate in the incentivization program; and program-banner-deploying functionality that deploys each program banner to the business website.

[0007] In still yet another implementation, the present disclosure is directed to a method of allowing a plurality of businesses, each having a corresponding business website operating on a respective business webserver, to each offer an incentivization program on the corresponding business website via web-based incentivization (WBI) software, wherein the WBI software includes program-building features that allow each business to create its own incentivization program that includes a plurality of incentive levels / types, with each incentive level / type having an associated program banner; and a website-presentation code generator that generates website-presentation code that, when executed, presents the program banners on frontends of the business websites; the method includes receiving requests from the plurality of businesses to use the WBI software; and in response to receiving the requests, pushing instances of the WBI software to the business webservers for deployment on respective backends of the corresponding business websites.

[0008] In another implementation, the present disclosure is directed to a computer-readable storage medium containing computer-executable instructions for performing the method described in the paragraph immediately above. [0009] In yet another implementation, the present disclosure is directed to a method of providing one or more funding incentives to end-users via a fundraiser website associated with a fundraiser. The method being performed by a computing system includes providing an incentivized funding (IF)-program-builder user interface (UI) that allows a configuring user to build an IF banner, wherein the IF -program -builder UI allows the configuring user to configure the IF banner to present a funding level to the end-users on the fundraiser website, wherein the funding level has a corresponding benefit value; generating website-presentation code that, when executed, presents the IF banner on the fundraiser website; and deploying the website-presentation code to the fundraiser website so that the IF banner is accessible to the end-users on the fundraiser website.

[0010] In another implementation, the present disclosure is directed to a method of enabling a plurality of fundraisers, having a plurality of differing fundraiser websites, to provide individualized fundraising programs. The method being performed by a computing system includes receiving, by a fundraiser-software server, from each of the plurality of differing fundraisers, a request to use fundraiser software, wherein the fundraiser software is configured to allow each of the fundraisers to create its own fundraising program; and in response to receiving each request to use the fundraiser software, electronically delivering, by the fundraising-software server, an instance of the fundraiser software to a backend of the fundraiser website of the requesting fundraiser.

BRIEF DESCRIPTION OF THE DRAWINGS

[0011] For the purpose of illustrating aspects of the disclosure, the drawings illustrate features and/or characteristics of one or more embodiments of the disclosure. However, it should be understood that the present disclosure is not limited to the precise arrangements and instrumentalities shown in the drawings, wherein:

[0012] FIG. l is a table illustrating an example structure of an example funding incentives campaign having a campaign goal of $500,000;

[0013] FIG. 2 is a high-level schematic diagram illustrating an example centralized architecture for implementing an example web-based incentivization (WBI) system of the present disclosure;

[0014] FIG. 3A is a high-level block diagram illustrating an example decentralized architecture for implementing another example WBI system of the present disclosure;

[0015] FIG. 3B is a high-level block diagram illustrating an example method and architecture for deploying instances of fundraising software onto differing fundraiser websites; [0016] FIG. 3C is a high-level block diagram illustrating example methods of end-user payment and receipt of an incentive benefit;

[0017] FIG. 4 is a view of a tablet computer displaying an example funding-program banner of the present disclosure that the WBI software of FIG. 1 has generated;

[0018] FIG. 5A is a mock screenshot of an example Add New Funding Type user-interface (UI) form that can be provided by WBI software of the present disclosure, such as the WBI software of FIG. 2 and the WBI app of FIG. 3, showing the UI in an Unlimited availability mode and a Reload with Unlimited Reloads mode;

[0019] FIG. 5B is a mock screenshot of the Add New Funding Type UI form of FIG. 5 A, showing the UI in a Limited availability mode and the Reload with Unlimited Reloads mode;

[0020] FIG. 5C is a mock screenshot of the Add New Funding Type UI form of FIGS. 5A and 5B, showing the UI in the Unlimited availability mode and a Reload with Limited Reload mode;

[0021] FIG. 5D is a mock screenshot of the Add New Funding Type UI form of FIGS. 5A through 5C, showing the UI in the Unlimited availability mode and a No Reload mode;

[0022] FIG. 6 is a screenshot of an example homepage of an incentivized-funding (IF) UI of WBI software configured for creating and maintaining an (IF) program using the WBI software;

[0023] FIG. 7A is a screenshot of an example homepage of a di scount/re wards (D/R) UI of WBI software configured for creating and maintaining a D/R program using the WBI software;

[0024] FIG. 7B is a screenshot of an example add-new-rewards UI of the D/R UI of FIG. 7A;

[0025] FIG. 7C is a screenshot of an example add-new-discounts UI of the D/R UI of FIG. 7A;

[0026] FIG. 8A is a screenshot of an example login landing page that WBI software can present to an end-user for a particular incentivization program for use by the end-user, for example, when wanting to participate in the incentivization program; and

[0027] FIG. 8B is a screenshot of an example incentivization-program home page that the WBI software may present to the end-user upon logging-in to the incentivization program.

DETAILED DESCRIPTION

[0028] GENERAL

[0029] In some aspects, the present disclosure is directed to web-based-incentivization (WBI) systems that allows providers, for example, business startups (hereinafter, simply “startups”) and established businesses, to provide one or more web-based incentivization programs for end-users, such as funders and prospective funders of startups, customers of recent startups and other established businesses. Examples of such web-based programs include, but are not necessarily limited to, incentivized funding (IF) programs and discount/reward (D/R) programs, among others. It is noted that as used herein and in the appended claims, the solidus (i.e., the “/”) appearing between two words, such as “discount” and “reward” in “discount/reward”, and a pair of letters, such as “D” and “R” in “D/R”, denotes both “and” and “exclusive or”. In some embodiments, an IF program allows the provider, i.e., the fundraiser (such as a startup or an established business), to design and implement its own IF programs to raise funds for a startup, or to raise capital for an existing business. In some embodiments, a D/R program allows the provider (such as an established business) to design and implement its own D/R program, for example, to incentivize existing and/or prospective customers to buy products and/or services from the provider. Detailed examples and use cases for IF programs and D/R programs are described below.

[0030] In some embodiments, implementing an incentivization program includes displaying a program banner on a provider’s own website (hereinafter, the “provider website”). As used herein and in the appended claims, which are incorporated into this section by reference, the term “program banner” denotes any text, graphical element, collection of graphical elements, combination of text and graphical element(s), displayed anywhere on a provider website that displays information about the corresponding web-based program and includes at least one hyperlink (hereinafter, simply “link”) that allows an end-user (e.g., a prospective funder, an existing funder, a prospective customer, or an existing customer, etc.) to navigate to an incentivization user interface (UI) that, for example, allows the end-user to select to participate in the corresponding incentivization program, renew participation in the incentivization program, and/or create an account under the incentivization program, for example, as a funder or loyalty member, among other things, and any practicable combination thereof.

[0031] In some embodiments, and as described below in more detail, a program banner may display “live” information obtained from either a backend of the provider website or a WBI server that is separate and distinct from the provider website that displays the program banner, depending on the architecture of the WBI software. Such live information may include, but not be limited to, the number of fundings, rewards, discounts, etc., remaining at a particular IF level or D/R level and/or the number of reloads (see below) of a reward and/or discount, etc., available to the current end-user, among other things. In some embodiments, a provider website is a website that the provider normally uses for conducting its business. In some embodiments, a provider website is a website that the provider sets up specifically for the web-based program at issue, such as a website that a startup creates for soliciting funding using an IF program of the present disclosure. In some embodiments, provider websites are not owned or otherwise controlled by a provider of the WBI system.

[0032] An example of a program banner of the present disclosure is a textual, graphical, and/or interactive banner that is invoked on a webpage by any suitable webpage-presentation code(s), such as, for example, hypertext markup language (HTML) code, cascading stylesheet (CSS) code, and/or object-oriented-programming (OOP) code (e.g., JavaScript, etc.) that the WBI software of the WBI system deploys to a provider website. As will be apparent from reading this entire disclosure, including the descriptions below of accompanying FIG. 2 and FIG. 3, a program banner of the present disclosure can be dynamic in terms of the information it displays, and this dynamicism may be driven by OOP code, as those skilled in the art will readily appreciate. The WBI software generates the program-banner code based on funding-, reward, and/or discount-type parameters that a configuring user (e.g., a fundraiser, business owner, administrator, etc.) enters into the WBI software, which the WBI software then deploys to the provider website, for example, by embedding the program-banner code into webpage-generating code that displays pages of the provider website.

[0033] In some embodiments, each program banner is directed to a single funding type, reward type, and/or discount type. In some embodiments, each program banner may be directed to a set of two or more funding types, reward types, and/or discount types, among other incentive types. In some embodiments, each program banner may include one or more user-selectable links, such as one or more URLs, that upon selection by an end-user (e.g., a funder, a prospective funder, a member, a customer, etc.) navigates the end-user’s browser to a WBI website and/or to a WBI software application (hereinafter, simply “app”) that may reside on the backend of an individual provider webserver. In some embodiments, the first time an end-user navigates to the WBI website or WBI app, the WBI website or WBP app may require the end-user to establish an account on the WBI website or WBI app that allows the end-user to become a member of the corresponding web-based program and to interact with the WBI website or WBI app, for example, for the current web-based program and/or any other web-based program administered by the WBI website or WBP app that the end-user may have chosen to be part of. [0034] In the context of an IF program, a “fundraiser” can be any person, group of people, entity, group of entities, etc., that desires to raise funds for any legal purpose and/or to incentivize funders for participating in an IF program. Examples of fundraisers include, but are not limited to, any product and/or service provider, such as, for example, restaurants, retailers, grocery stores, and convenience stores, among many others, whether family owned, local, regional, etc. In many cases, the fundraiser will be a startup raising funds to allow the startup to grow. In some cases, the fundraiser is an established business that wants to raise funds, such as for a new venture that the business wants to pursue. In some embodiments, an IF program may comprise a set of one or more funding types (see below) that the corresponding fundraiser desires for raising funds and/or for incentivizing fundraisers to participate in the IF program. A nonlimiting set of examples of IF programs includes programs that provide discounted certificates (e.g., pay $50 for a $75 incentive certificate) for the fundraiser. As those skilled in the art will readily appreciate, there is fundamentally no limitation on the type of a fundraiser, nor on the type of IF program that WBI software of the present disclosure can be used to administer other than it be lawful and amenable to the functionalities of the WBI software. In addition, the reward(s), discount(s), and/or other incentives provided by the fundraiser (i.e., provider) can be any that is/are appropriate to the IF program.

[0035] In the context of a D/R program, an end-user can be any person, group of people, entity, group of entities, etc., that may be, for example, a member of a membership program, such as, a rewards program, a discount program, a loyalty program, or the like, and any practicable combination thereof, offered by a provider, which, again is typically any type of business. Examples of business-type providers include, but are not limited to, any product and/or service provider, such as, for example, restaurants, retailers, grocery stores, and convenience stores, among many others, whether family owned, local, regional, etc. In some embodiments, a D/R program may comprise a set of one or more membership levels (see below) that the corresponding provider desires to provide to its customers. A nonlimiting set of examples of D/R programs includes programs that provide discounted certificates (e.g., a certificate to pay $8 for a $15 hamburger) for the fundraiser. As those skilled in the art will readily appreciate, there is fundamentally no limitation on the type of a fundraiser, nor on the type of D/R program that WBI software of the present disclosure can be used to administer other than it be lawful and amenable to the functionalities of the WBI software. In addition, the reward(s), discount(s), and/or other incentives provided by the business (i.e., provider) can be any that is/are appropriate to the D/R program. [0036] That said, in some embodiments, WBI software of the present disclosure and its functionalities can be particularly useful for local startups and local businesses to provide IF programs and/or D/R programs targeted to funders, prospective funders, customers, and/or prospective customers in a limited, or “local” geographic region. For example, and in a fundraising context, many of the conventional fundraising websites have a national or global reach so as to provide the fundraiser with the largest pool of potential funders possible. For example, and in general, anyone can navigate to one of those websites from anywhere in the world to peruse the funding opportunities available on such websites. However, that model does not make sense for local / small businesses and startups that, by their nature, serve, or would serve, only a limited set of customers and/or limited geographical region, such as single-location family-owned restaurants, small regional coffee chains, charming regional coffee shops, neighborhood bakeries, other local ventures that serve their communities with personalized services, and the like, among many others, because those businesses only serve limited or otherwise relative small regions, when compared to national or global scales. Because embodiments of WBI software of the present disclosure deploys one or more incentivization banners directly on a provider’s own locally or regionally focused website, the effective reach is primarily local or regional due to the nature of the goods / services that the fundraiser’s business provides.

[0037] In a fundraising example, in some embodiments the WBI software allows a fundraiser to create an IF program having one or more unique funding incentivization attributes. For example, an IF program may be a fundraising campaign having a campaign-goal amount, as with any typical funding campaign. In this funding campaign, the WBI software allows a fundraiser to set one or more funding levels / funding types for each of which the WBI software allows the fundraiser to: set a reward, thereby providing an incentive; set multiple rewards via differing funding levels / types; assign differing rewards to the differing funding levels / types, which adds another incentive to fund at a higher level / type); name each reward; set an availability for each reward; set a price for each reward; define the number of reloads, if any, for each funding level / type, which provide still another incentive, including an incentive to fund at a higher funding level / type. Regarding reloads, when a funding level / type allows a funder to reload that funding level’s / type’s reward, the funder can reload the reward by again paying the price for that funding level / type. The reload feature can be quite useful, especially for prospective funders / funders that particularly enjoy the products and/or services of the fundraiser. For example, a customer that frequents a family-run restaurant running an IF program of the present disclosure that doubles the value of the price may want to fund a campaign at a level having a relatively large number of reloads so as to obtain more of the “double-value” rewards that the funder can use for additional visits to the restaurant. Many other possibilities exist. FIG. 1 of the appended drawings, described below, illustrates, for the sake of illustration and not limitation, a table containing an example of such an IF program 100. As will become apparent from reading this entire disclosure, including the example D/R use case described below in the section titled “EXAMPLE USE CASES”, a D/R program of the present disclosure can have many features in common with an IF program of the present disclosure, including the IF program 100 of FIG. 1 The foregoing and other aspects and features of WBI systems of the present disclosure are described in detail below.

[0038] EXAMPLE IMPLEMENTATIONS

[0039] Example IF Program

[0040] Referring to FIG. 1, in this example the IF program 100 has seven funding levels / types (column 104) having increasing prices (column 108) that a funder must pay, with the number of availabilities (column 112) at each funding level / type decreasing with the increasing prices. In this example, each funding level / type (column 104) has a corresponding name (column 104N) that, as discussed below, is displayed to a funder / prospective funder. Also in this example, the reward (column 116), which is an incentive, provided at each funding level / type (column 104) is equal to the price (column 108) of that funding level / type, here expressed as a percentage of the price, i.e., 100%. In other words, the reward is the same amount as the price in column 108. Consequently, and as shown in column 120, the total value to a funder of a single funding at any particular funding level / type (column 104) is the total of the price (column 108) plus the reward (column 116). For example, at funding level / type 2 (column 104), the price (column 108) is $20 and the reward (column 116) is also $20 (i.e., 100% of the $20 price), so the total value (column 120) is $40. In this example, a funder gets not only the value of the price (column 108) toward purchasing from the fundraiser but also the value of the reward (column 116) toward purchasing from the fundraiser, so that total value to the funder (column 120) is considered the sum of the price and the reward. In other embodiments, the percentages of the rewards (column 116) can differ among the differing funding levels / types (column 104). In some embodiments, rewards (column 116) can be expressed as amounts (e.g., $50, $75, $200, etc.) and/or non-monetary rewards, such as vouchers for one or more products and/or one or more services, among others, and any practicable combination thereof.

[0041] In addition to the prices (column 108) increasing with the increasing funding level / type (column 104), the number of reloads (column 124) that each funder can make increases with the increasing levels. This reload opportunity can provide a funder with an additional incentive beyond the reward incentive (column 116) to fund at a higher level. In the present example, FIG. 1 shows the maximum base funding, here, the “campaign goal” (column 128), that can occur at each level when funders have purchased all of the available opportunities at that level, as well as a maximum total base funding 128T. The maximum base funding amount at each level (column 128) is determined by multiplying the maximum funding availabilities (column 112) at that level / type (column 104) by the price (column 108) at that level / type, and the maximum total base funding 128T is the sum of the maximum base funding amounts of all seven levels, which in this example is $500,000.

[0042] The example IF program 100 of FIG. 1 also shows an impact that the reload incentive can have on fundraising. The Reloads + Goal column 132 in FIG. 1 shows, for each level / type (column 104), the total maximum funding that can be achieved when each level reaches the maximum availability (column 112) and every funder at that level executes the maximum number of reloads (column 124) for that level / type. For example, for “Gold” level / type 6 (columns 104N and 104, respectively) that has 5 reloads for each of the 200 funding availabilities (column 112) at that level / type, if every one of the 200 funders at that level / type executes all 5 reloads, then the additional funding from the reloads will be (200 funders x $350) x 5 reloads/funder = $350,000, and the total of the reloads + goal (column 132) will be $350,000 + $70,000 = $420,000. The maximum total campaign goal + reloads funding 132T is the sum of all maximum-reload funding amounts (column 132) for all seven levels (column 104) + the sum of all maximum goal funding amounts (column 128) for all seven levels, which in this example is $1,930,000. The additional incentive that the reloads provides, in combination with providing increasing numbers of reloads with increasing price, can result in a significant boost to overall funding. In addition, increasing the number of reloads (column 124) with increasing funding levels / types (column 104) can incentivize a prospective funder / funder to participate at a higher level, especially when the fundraiser offers goods and/or services that the prospective funder / funder is particularly fond of. Those skilled in the art will readily appreciate that many other IF programs that utilize one or more funding types / levels similar to funding types / levels shown in FIG. 1 can be created using any one or more of the incentivizing features disclosed herein.

[0043] Again, it is noted that while the example incentivization program of FIG. 1 is an IF program, those skilled in the art will readily understand that a D/R program of the present disclosure can have many similarities and some differences. Examples of such similarities and differences are described below in the section titled “EXAMPLE USE CASES”.

[0044] Example Centralized Architecture for WBI Software

[0045] FIG. 2 illustrates an example centralized architecture 200 for implementing a WBI system 204 of the present disclosure. As will become apparent from reading this entire disclosure, the WBI system 204 can be configured for use only with IF programs, only with D/R programs, or for use with both IF programs and D/R programs. Differences between/among these configurations are illustrated in the section below titled “EXAMPLE USE CASES”.

[0046] In this example of FIG. 2, the centralized architecture 200 is a cloud-based, multitenant architecture that includes a communications network 208, which, as those skilled in the art will readily appreciate, can be an amalgamation of a variety of networks of differing types, including, but not limited to, the Internet, wide-area networks, local-area networks, and telecommunications networks, among others. The WBI system 204 may be resident, for example, on one or more servers, singly and collectively represented in FIG. 2 by a webserver 212. As discussed above, the WBI system 204 and the WBI software 216 that it executes, allows configuring users (e.g., providers, such as fundraisers, startups, businesses), represented in FIG. 2 by provider websites 220(1) through 220(N), to build their own incentivization programs 224(1) through 224(N), which the WBI system 204 stores in a datastore 228, that are then presented on their own websites, i.e., their respective provider websites, as program banners 232(1) through 232(N). Example program banners 416(1) through 416(3) are described below in connection with FIG. 4. Referring still to FIG. 2, as described above, each program banner 232(1) through 232(N) may be, for example, an HTML banner having underlying HTML code that the corresponding provider website 220(1) through 220(N) uses to build the corresponding webpages (not shown) that are presented to anyone navigating to those webpages, such as prospective end-users (represented by devices 236(1) through 236(M)) and existing end-users (represented by devices 240(1) through 240(P)), wherein M and P can be any integer.

[0047] The datastore 228 may be any suitable datastore, including a local datastore or a distributed datastore. Fundamentally there are no limitations on the type and nature of the datastore 228 other than that it be amenable to allowing the WBI system 204 to provide the functionality described herein. Referring still to FIG. 2, the number, N, of provider websites 220(1) through 220(N) and corresponding related items can be any number and may depend only on the number of providers wanting to use the WBI system 204. In this example, the number, 5N, of program banners 232(1) through 232(5N) is arbitrarily equal to the number of provider websites 220(1) through 220(N). However, this need not be the case, such as when differing levels of one or more of the incentivization programs 224(1) through 224(N) are presented by separate program banners and/or when one or more of the provider websites 220(1) through 220(N) has more than one incentivization program. Relatedly, the number of incentivization programs 224(1) through 224(N) need not match the number of provider websites 220(1) through 220(N).

[0048] The WBI system 204 and WBI software 216 includes a program-builder UI 244 that allows each provider, here represented by provider websites 220(1) through 220(N), to build its own incentivization program(s) 224(1) through 224(N). In this example, the program-builder UI 244 is accessible to the providers 220(1) through 220(N) via their respective web browsers (not shown) in a conventional browser-based interactive manner. For example, each provider 220(1) through 220(N) may set up an account within the WBI system 204, through which account that provider may set up one or more incentivization programs. Accounts information 248 for the member providers 220(1) through 220(N) may be stored in the datastore 228. Examples of features of a program -builder UI, such as the program-builder UI 244 of FIG. 2, that allow each provider 220(1) through 220(N) to build an incentivization program, such as an IF program or a D/R program, are described below in connection with FIGS. 5A through 5D.

[0049] In this example, the WBI software 216 also includes a banner generator 252 that generates the code (not shown), for example, HTML-banner code, that the WBI software then sends to the respective provider websites 220(1) through 220(N) for implementing the corresponding incentivization banners 232(1) through 232(N). Those skilled in the art will readily understand how to implement the banner generator 252 according to the requirements of the program banners 232(1) through 232(N). In connection with the banner generator 252 and the program builder UI 244, those skilled in the art will readily appreciate that these terms are used merely for convenience of describing certain functionalities and not to necessarily describe the way in which the underlying software code is structured. Indeed, the software coding for these functionalities can be executed in any suitable manner.

[0050] In this example, each of the provider websites 220(1) through 220(N) may be hosted by a corresponding provider server 256(1) through 256(N). However, in other embodiments, the provider websites 220(1) through 220(N) may be hosted on one or more other servers (not shown). Also in this example, each of the prospective and existing end-user devices 236(1) through 236(M) and 240(1) through 240(P), respectively, may be any suitable device that has a browser that allows the corresponding user to navigate to any one or more of the provider websites 220(1) through 220(N) and is able to display any one or more of the program banners 232(1) through 232(N). Examples of such devices include, but are not limited to smartphones, tablet computers, laptop computers, desktop computers, etc., as those skilled in the art will readily understand.

[0051] In the example embodiment of FIG. 2, the webserver 212 includes one or more processors 260 and memory 264 operatively connected to the processor(s). Each processor 260 may be any suitable processor, such as a general-purpose microprocessor, among others. The memory 264 may be any suitable hardware memory, including, but not limited to RAM of any type, ROM, cache, working memory, long-term storage memory, short-term storage memory, volatile memory, nonvolatile memory, removable memory, etc. Any method disclosed in this disclosure, any portion thereof, and any combination of methods disclosed herein and/or otherwise needed to effect any aspect discussed in this disclosure may be implemented using any suitable software containing appropriate machine-executable instructions stored in the memory 264 and executed by the processor(s) 260. For the sake of convenience any hardware storage memory of any one or more types is referred to herein and in the appended claims as “computer-readable storage medium”, which excludes any transitory storage that can occur on transitory signals, including, digitally encoded carrier signals and pulsed signals encoded with digital data. In addition, while “medium” in “computer-readable storage medium” is singular, it is to be construed to include the plural, as differing parts of machine-executable instructions embodied in the “medium” may reside in differing hardware memories, which may be, for example, parts of the same computing / network device or parts of differing computing / network devices, and not in a common hardware memory. It is also noted that wherever the term “server” appears in this disclosure and in the appended claims, it shall cover, as the case may be, a single server device, multiple server devices, and a virtual server.

[0052] Example Decentralized Architecture for WBI Software

[0053] FIG. 3A illustrates an example decentralized architecture 300 that is an alternative to the example centralized architecture 200 of FIG. 2. The centralized architecture 200 of FIG. 2 is centralized in that it is a cloud-based, multitenant architecture wherein the WBI software 216 and most of the functionality of the overall WBI system 204 is performed on one or more webservers 212 that do not host any of the provider websites 220(1) to 220(N). Rather, the provider websites 220(1) to 220(N) reside on provider servers 256(1) to 256(N) that are separate and distinct from the webserver(s) 212 hosting the WBI software 216. In contrast, the decentralized architecture 300 of FIG. 3 A deploys a WBI app 304 onto a provider server 308 that is associated with a provider (not illustrated) that uses the WBI app to implement an incentivization program such as, for example, the IF program 100 illustrated in FIG. 1 and described above, or a generally similar D/R program (not shown) as described below in the section titled “EXAMPLE USE CASES”, among many others that can implement one or more features of the present disclosure. As with the WBI software 216 of FIG. 2, the WBI app 304 of FIG. 3 A can be configured for use only with IF programs, only with D/R programs, or with both IF programs and D/R programs. Differences between/among these configurations are illustrated in the section below titled “EXAMPLE USE CASES”.

[0054] Referring to FIG. 3A, and also to FIG. 2 as the leading digit of each referenced element identifier indicates, as described above, the provider server 308 provides a provider frontend 312, i.e., serves webpages of the provider’s website 316. In this example, the provider is a startup, and its website 316 is dedicated to, among other things, promoting its business and, in this example, has the uniform resource locator (URL) www.starteupboslnesspatent.com. As those skilled in the art will understand, the provider server 308 can be associated with the provider in any one of many ways. For example, the provider may own and maintain the provider server 308, the provider may lease the provider server from a third party, or the provider may pay a third party to maintain the provider’s website 316 and provide and/or host any backend functionality(ies) required, such as a provider backend 320 that enables functionalities of the overall WBI system, here, embodied generally in the WBI app 304 for this particular provider server 308.

[0055] In the example of FIG. 3 A, the provider backend 320 allows the provider to create and/or customize an incentivization program (not shown) that integration software code 324 uses to display an end-user UI 328 that an end-user (not shown) navigating to the fundraiser’s website 316 will see and use to decide whether or not to be a funder of the incentivization program depicted in the UI. In this example, the provider backend 320 includes machine-executable instructions (not shown), which are part of the WBI app 304, that allows the provider, or an agent thereof, to create and/or customize, for example, via a program-builder UI (not shown, but see, e.g., the programbuilder UI 244 of FIG. 2), the incentivization program by setting/selecting the number of funding levels, the number of discounts / rewards, and naming each one and, for each funding level / incentive type, setting/selecting a price, setting/selecting an availability, setting/selecting a reward, and/or setting/selecting the number of reloads, among others. Each of these features is described above in detail, for example, in the context of accompanying FIGS. 1 and 5A-5D and the example use cases described below in the section titled “EXAMPLE USE CASES”. The integration code 324 uses the information of the created incentivization program to create the user-facing end-user UI 328, which in this example, includes three program banners 332(1) through 332(3) that display, respectively, information for three funding levels of an example IF program, namely, “Level 1”, “Level 2”, and “Level 3”, which have three differing prices, here, denoted by “$x”, “$y”, and “$z”, respectively. The integration code 324 may be, for example, HTML code, CSS code, and/or OOP code (e.g., JavaScript, etc.). Each program banner 332(1) through 332(3), or portion thereof, may be a link that, upon end-sure selection, navigates the end-users’ browser to a webpage (not shown) of the WBI app 304 wherein the end-user is presented with further information about the selected funding level, and, if the end-user is not already registered with the WBI app, provides a UI (not shown) that allows the end-user to register to participate in the incentivization program, here, an IF program.

[0056] While not illustrated in FIG. 3A, those of ordinary skill in the art will understand that the provider server 308 may include one or more processors, memory, one or more datastores, a program-builder UI, and a banner generator that are the same as or similar to the processor(s) 260, memory 264, datastore(s) 228, program -builder UI 244, and banner generator 252 of FIG. 2, among other hardware and software needed for the provider server to function. In addition, those skilled in the art will readily appreciate that, in the context of FIG. 2, the provider server 308 of FIG. 3 A may be any one of the provider servers 256(1) through 256(N) of FIG. 2. Moreover, those skilled in the art will readily appreciate that the provider frontend 312 / provider’s website 316 of FIG. 3A may be accessible / viewable via a browser on any one of the devices 236(1) through 236(M) and 240(1) through 240(P) of FIG. 2.

[0057] FIG. 3B visualizes a method of enabling a plurality of differing providers 350(1) to 350(N) to provide their own individualized incentivization programs (not shown, but see, e.g., IF program 100 of FIG. 1 as a general example). In this example, each provider 350(1) to 35O(N) has its own server 354(1) to 354(N) that provides a website (not individually shown) having a frontend 358(1) to 358(N) accessible to end-users, such as, potential funders, existing funders, potential customers, existing customers, and other site visitors, and a backend 362(1) to 362(N) that, for example, serves webpages (not shown) to the frontend and enables functionalities of the website. In the present context, such functionalities include allowing each provider 350(1) to 350(N) to create an incentivization program customized to the provider’s needs and, once the provider has created that incentivization program, visitors can access the website to participate in the incentivization program as they desire.

[0058] To enable such functionalities, the architecture of this example includes a WBI-software vendor 364 that operates a vendor server 368 that each provider 350(1) to 350(N) can access via a network 372, which, collectively, can include the Internet and any additional network(s) on either end of the Internet that may be present for each of the provider servers 354(1) to 354(N) and the vendor server 368 to connect to the Internet, including local -area networks, wide-area networks, cellular networks, etc. In this example, the vendor server 368 contains registration software 376 that, among other things, provides a registration website 380, as well as WBI software 384 that providers 350(1) to 350(N) download to create WBI-software instances 384(1) to 384(N) of the WBI software that are deployed individually onto the provider servers 354(1) to 354(N) after the providers have registered to use the WBI software. In the context of the example of FIG. 3A, the WBI app 304 shown there would be one of the WBI-software instances 384(1) to 384(N) when the provider of FIG. 3 A is one of the providers 350(1) to 350(N) of FIG. 3B.

[0059] Referring again to FIG. 3B, for each provider 350(1) to 350(N) to acquire the corresponding WBI-software instance 384(1) to 348(N) of the WBI software 384, the provider registers with the WBI-software vendor 364. In an example, by registering and paying the WBI- software vendor 364 a licensing fee to use the WBI software 384, the provider 350(1) to 350(N) can then download an encrypted, corresponding WBI-software instance 384(1) to 384(N) to the respective provider server 354(1) to 354(N). In some embodiments, the WBI-software vendor 364 may additionally vet each potential provider 350(1) to 35O(N) before allowing that provider to install a WBI-software instance 384(1) to 384(N) on its provider server 354(1) to 354(N) so as to ensure the reputation of the WBI-software provider.

[0060] FIG. 3C illustrates example methods in which an end-user 354 may make a payment for the benefit 358 corresponding to the incentive level / type that the end-user has selected to participate in and by which the end-user can receive the benefit. In this example, the benefit 358 is the total value corresponding to the incentive provided at the selected incentive level / type. For example, if the incentive is an amount of money to spend that is 50% of the payment that the enduser 354 makes to participate, then the benefit 358 equals the payment plus 50% of the payment. As a simple example, if the payment to participate is $100 and the incentive is 50% of the payment, then the benefit 358 is $150. As another example, if the incentive is buy one hamburger and get a second one at 50% off the price of a hamburger, then the benefit 358 is receiving two hamburgers for only 1.5 times the price of one hamburger. As discussed below, the benefit 358 may, in some cases, be handled by the WBI software instance 3841 issuing a certificate 362 to the end-user 354, for example, digitally and/or in hardcopy form. Those skilled in the art will readily appreciate that there are other ways of handling each benefit, such as the benefit 358, that an end-user, such as enduser 354, is to receive based on participation in the incentivization program being offered by the provider 350 via the WBI software instance 3841 that it downloaded from the WBI-software vendor 364 of FIG. 3B.

[0061] Referring still to FIG. 3C, in some embodiments, the end-user 354 can only pay digitally, as represented by digital payment 366 from the end-user device 370 to the WBI software instance 3841 over the network 372. The digital payment 366 may take any suitable form, such as an electronic bank transfer, an online payment service, or a digital credit/debit form, among others, and any combination thereof. In some embodiments, the provider 350 may permit the end-user 354 to pay by cash, for example, at the provider’s place of business 350B, if one exists, via an offline cash payment option 374. The WBI-software instance 3841 records the end-user’s 354 offline cash payment, as if it were any other type of payment. In this example, the provider 350 sends a payment indicator 374P to the WBI-software instance so that it knows that the payment was made to the enduser’s order page within the end-user’s profde. When the end-user 354 chooses offline cash payment 374 over a digital payment option 366, the provider 350 may automatically implement a timer feature (not illustrated) within the end-user’s profile order-information display that will cancel the participation by the expiration of the timer if the end-user fails to show up in-person at the provider’s establishment, or a place the provider has set up as a means to collect and record the payment if such provider has not yet established a place of business, as in a startup scenario.

[0062] In an example, when the end-user makes the payment in-person, the provider records the transaction by toggling a soft control of a “Funds Added” feature in the backend of the end-user’s profile-information, which ends the cancellation process, and removes the timer. This can be particularly useful when the incentivization program is an IF program, i.e., startup, when the provider requires the outstanding amount by a fixed time. The implemented timer feature in the WBI-software instance 3841 may send one or more payment-due reminders (not shown) to the enduser 354, for example, via electronic messaging, such as via SMS messaging, MMS messaging, email messaging, direct messaging, etc. To handle payments in the above-described and/or other manners, the WBI-software instance 3841 may include a payments engine 378 that anyone skilled in the art would be able to code once the desired functionalities for a particular instantiation have been determined.

[0063] In some embodiments, the “Funds Added” feature also allows a funder (i.e., end-user) to cancel their selection before completing a payment if they believe they made an incorrect choice. This can be done, for example, using the “Cancel” button visualized on the end-user’s profile page, enabling her / him to make a new selection after cancellation. However, once a payment is processed without any changes to the original selection, the WBI software may automatically remove the “Cancel” button when the “Add Funds” feature is toggled to a “Yes” position. In this example, the “Add Funds” feature is multi-functional. It does add a timer; however, its main purpose is to remove the cancel option. In an example, the timer is a preset functionally in a suitable menu. For example, the menu may provide a field labeled: “The order will get canceled if funds are not added in X amount of time ”, with X being user settable, for example, in day increments.

[0064] In this example, the WBI-software instance 3841 issues the certificate 362 to the enduser device 370 via a digital certificate 362D that the WBI-software effectively transmits to the enduser device via the network. The digital certificate 362D may be in any suitable form, such as, for example, a QR or other type of scannable code and/or a unique certificate identifier (e.g., number) captured in an email message, an MMS message, or any other type of digital message that the WBI- software-instance 3841 transmits to the end-user device 370. As another example, the digital certificate 362D may be on a webpage (not shown) provided by the WBI-software instance 3841 that the end-user 354 can access when it wants to use it, for example, via a browser 382 on the end-user device 370.

[0065] As another example, each participant in any type of incentivization program of the present disclosure receives a membership card containing a magnetic strip and/or a QR code linked to a Unique Member Identification (UMID) number that the WBI software assigns to him/her. This membership card can track the initial payments as well as any rewards, which may be added through a Point of Sale (POS) system of the corresponding provider. The same or similar process can be applied to online credit-card payments via the incentivization programs, which can be integrated via an Application Programming Interface (API) directly with providers’ POS systems. In an example, the participant must present his/her membership card for any transaction involving the redemption of monetary value for products and/or services. The appropriate amount will be deducted or added automatically as purchases or reloads take place. Those skilled in the art will readily appreciate the various ways that the WBI-software instance 3841 can issue the digital certificate 362D to the enduser 354 and/or handle payments, rewards, and/or discounts.

[0066] In addition to, or alternatively to, the WBI-software instance 3841 issuing the digital certificate 362D, the WBI-software instance may issue a certificate acknowledgement 392 to the provider 350 so that the provider has a record of the issuance of the certificate 362. This record can be used for any one or more purposes, such as for providing the benefit 358 only upon the enduser 354 providing personal identification and/or recordkeeping to record when the end-user has received the benefit, among others. In some embodiments, the WBI-software instance 3841 may issue the certificate acknowledgement 392 digitally to the provider 350. Depending on the locations of the WBI-software instance 3841 and the recordkeeping software (not shown) of the provider 350, the issuance of the certificate acknowledgement 392 may be internal to the provider’s computing system(s) (not shown) or require transmission across the network 272.

[0067] As another example, the WBI-software instance 3841 may cause a hard certificate 362H to be issued. Example forms of the hard certificate 362H include a plastic card (e.g., a membership card) or a sheet of paper, among others. The hard certificate 362H may be provided to the end-user 354 in any suitable manner, such as via the postal service or as a pickup item at the provider’s place of business 250B, among others. To handle certificates in the above-described and/or other manners, the WBI-software instance 3841 may include a certificates engine 388 that anyone skilled in the art would be able to code once the desired functionalities for a particular instantiation have been determined.

[0068] Those skilled in the art will readily appreciate that these example methods for payment and certificate handling are merely illustrative and nonlimiting. Indeed, skilled artisans will be able to devise many alternatives without undue experimentation using only routine knowledge in the art, and, consequently, these alternatives fall within the scope of the appended claims. In addition, it is noted that while the methods are described relative to FIG. 3C and the WBI-software instantiation 3841 thereof (and correspondingly the source WBI software 384 provided by the WBI- software vendor 364 of FIG. 3B), these and/or alternative methods can be implemented in any WBI software of the present disclosure, including the WBI software 216 of FIG. 2, among other versions described herein. [0069] Example Display to an End-User of IF Banners

[0070] FIG. 4 illustrates a device 400, here, a smartphone, displaying, on a webpage 404 of the provider’s website 408 via a suitable browser 412, three example program banners 416(1) through 416(3), here IF-program banners, which correspond to the Starter, Basic, and Elite funding levels / types in column 104N of the table of FIG. 1, described above. In accordance with the foregoing description, each of the program banners 416(1) through 416(3) of FIG. 4 may be an HTML banner provided, for example, by a banner generator, such as the banner generator 252 of FIG. 2, to the provider’s website 408, which can be any one of the provider websites 220(1) through 220(N) of FIG. 2 or the provider’s website 316 of FIG. 3 A, for example. In the example of FIG. 4, each program banner 416(1) through 416(3) displays various information about the corresponding funding level / type. Here and with only the program banner 416(1) labeled because the program banners 416(2) and 416(3) are similar, each program banner 416(1) through 416(3) displays the level name 420, the level price 424, the availability remaining 428, a percentage 432 of the match, the total reward 436, the number of reloads 440, and the VIP status 444. It is noted that in this embodiment, the availability remaining 428 indicator is a dynamic, i.e., live, indicator that changes each time another funding by any funder occurs on the corresponding funding level. The data driving this dynamic indicator is maintained by the underlying WBI software (not shown), such as the WBI software 216 of FIG. 2 and the WBI app 304 of FIG. 3 A.

[0071] In this example, each program banner 416(1) to 416(3) also includes a “Select This Level” soft button 448 (only one of three labeled) that allows the end-user to elect to fund at the corresponding funding level. Upon the end-user selecting any of the “Select This Level” soft buttons 448, the browser 412 of the device 400 navigates to an end-user UI of WBI software made in accordance with the present disclosure, such as the end-user UI 268 of FIG. 2. As those skilled in the art will readily appreciate, the name of the soft button 448 (or other hyperlinking control) can be any name desired. It is noted that this example is for an IF program; hence its example name. If the incentivization program were a rewards program, then the name of the control may be, for example, “Choose this Membership”, and if the incentivization program were a discount program, then the name of the control may be, for example, “Select this Discount”, among many others.

[0072] When the incentivization program is an IF program, the WBI software may provide the option of allowing a participant (i.e., end-user) to become a member of a D/R membership program. For example, an end-user may need to click on a website-menu-driven link to be redirected to a login page, or click on a “Create an Account” link to enter an end-user UI, similar to the end-user UI 268. In other words and in an example, the end-user must be a member to see the incentive levels / types or a profile page. In some embodiments, the WBI software allows only one purchase per end-user. The end-user selects a funding type, and if reloads exists, the end-user can initiate reloads within his/her profile page if a previous reloads is complete; however, if no reloads exist, the end-user will make a payment, and the purchase will revert from “Active” to “Complete”, and the end-user is done. In an example, the end-user will then receive a membership card, and when the funds are depleted, that is it; the end-user may not make another selection purchase. Similarly for a D/R program, once in the end-user UI 268, the end-user may become a member of the corresponding incentivization program, for example, to participate in another reward / discount type and/or perform a reload, among other things.

[0073] Example Generic UI for Creating Incentivization Programs

[0074] FIGS. 5 A through 5D illustrate an example level / type-configuring UI, here, designated as an “Add New Incentive Level / Type” UI 500, that presents a form 504 that allows a user to configure a new incentive level or type for either an IF program or a D/R program, as the case may be. Those skilled in the art will readily understand that the level / type-configuring UI 500 of FIGS. 5A through 5D is merely one example of the many ways that the underlying functionalities can be embodied into a level / type-configuring UI of WBI software made in accordance with the present disclosure. It is noted that the level / type-configuring UI 500 illustrated includes functionalities for creating both IF programs and D/R programs. As will become most apparent after reading the section below titled “EXAMPLE USE CASES”, WBI software of the present disclosure, and correspondingly the level / type-configuring UI may be differently configured, such as to create only IF programs or only D/R programs. In such cases, the necessary functionalities as between these two configurations may differ from one another. In the example shown, the form 504 is configured to allow the user to create an incentive type, which can be, for example, a new funding level of a multi-level IF program (see, e.g., the table of FIG. 1), a funding type for a single-level IF program, or a reward / discount of a D/R program, among others. As alluded to above, the “Add New Incentive Level / Type” UI of FIGS. 5A - 5D include various features that may be included in WBI software of the present disclosure, such as in the program-builder UI 244 of the WBI software 216 of FIG. 2 or the WBI app 304 of FIG. 3A, among others.

[0075] Referring first to FIG. 5A, in this example the form 504 includes a “Status” toggle control 508, a “Name” field 512, a “Short Description” field 516, an “Is Unlimited?” toggle control 520, a “Price” field 524, a “Reward” field 528, an “Is VIP?” toggle control 532, an “Is Reload?” toggle control 536, an “Unlimited Reloads” toggle control 540, an “Image” selection control 544, a “Save” control 548, and a “Cancel” control 552, each of which is described below. Depending on the setting of a particular toggle control, such as the “Is Unlimited?” toggle control 520, the form 504 displays one or more additional fields, as described below in more detail. In this context, a “toggle control” is any type of soft control, for example, slider, pair of radio buttons, etc., that provide a binary choice indicating either on or off, yes or no, etc.

[0076] In this example, the “Name” field 512 allows a user to provide any suitable name for the incentive and the “Short Description” field 516 allows the user to provide a short description for the current incentive. In some embodiments, the WBI software inserts the name and short description that the user inputs via the fields 512 and 516 into the corresponding program banner (not shown) that gets displayed to end-users on a provider website. An example program banner showing a name and short description is shown in FIG. 7C and described below in the subsection titled “D/R Programs for Established Businesses”. The “Status” toggle control 508 allows a user to set the status of the incentive level / type under consideration with a status of either “ACTIVE” or “INACTIVE” by sliding a soft slider. If the status is set to active, then in some embodiments the WBI software, such as the WBI software 216 of FIG. 2 or the WBI app 304 of FIG. 3A, makes the incentive level / type available for use in an incentivization program. If the status is set to inactive, then in some embodiments the WBI software, such as the WBI software 216 of FIG. 2 or the WBI app 304 of FIG. 3 A, may not make the incentive level / type available for use in an incentivization program.

[0077] The “Price” field 524 in the example form 504 of FIG. 5 A allows the user to set the price of the incentive level / type, which is the cost to an end-user (i.e., an existing funder, prospective funder, existing customer, prospective customer, etc.). In this example, the “Price” field 524 is a numeric field. However, in other embodiments the “Price” field 524 can be replaced by another type of control, such as a dropdown control or a radio-button control, among others. In this example, the “Reward” field 528 is a numeric field that allows a user to input a percentage that is applied to the monetary value in the “Price” field 524 to determine the monetary amount of the reward. For example, if the user inputs $200 into the “Price” field 524 and 50 (%) into the “Reward” field 528, then the reward will be 50% of $200, i.e., $100. In this example, the total benefit accrued to the enduser under this funding type will be $200 + $100 = $300. [0078] FIG. 5A shows the “Is Unlimited?” toggle control 520 as being in the “YES” position, which means that the incentivization program that uses the incentive level / type being created will accept any number of selections by end-users. However, if the configuring user sets the “Is Unlimited?” toggle control 520 to its “NO” position as seen in FIG. 5B, then the funding-types UI displays an “Availability” field 556 in the form 504, which allows the configuring user to set the number of the incentive level / type that is available for end-users to purchase. As those skilled in the art can appreciate, the “Availability” field 556 can be a numeric field, a dropdown control, or a radio-button control, among others. As described below in the subsection titled “IF Programs for Startups”, IF programs typically have predetermined durations with a fixed fundraising goal, and it is undesirable to provide an unlimited number of user-selections of any incentive level/type because the fundraiser would not have a definitive end. Consequently, if the level / type-configuring UI 500 were to be for IF programs only, then the “Is Unlimited?” toggle control 520 need not be provided.

[0079] FIGS. 5A and 5B show the “Unlimited Reloads” toggle selector 540, here, a soft slider control, in its “YES” position, meaning that each end-user that has selected the corresponding incentive level / type in a particular incentivization program has the ability to reload the incentive level / type, i.e., receive another reward of the same amount by again paying the price of the incentive level / type. However, a configuring user can change the “Unlimited Reloads” toggle control 540 to its “NO” position, as seen in FIG. 5C, which causes the form 504 to display a “Reloads” field 560 by which the configuring user can set a number of times that any end-user selecting this incentive level / type can reload, i.e., repurchase, the incentive level / type. As those skilled in the art can appreciate, the “Reloads” field 560 can be a numeric field, a dropdown control, or a radio-button control, among others.

[0080] When an end-user selects an incentive level / type having a limited number of reloads available, the WBI software, for example, the WBI software 216 of FIG. 2 or the WBI app 304 of FIG. 3A, may track the number of reloads remaining and causes the program banner (not shown, but see, e.g., program banners 332(1) through 332(3) of FIG. 3A and 416(1) through 416(3) of FIG. 4) for that end-user to display the number of reloads remaining for the incentive level / type at issue. Relatedly, each of FIGS. 5A through 5C show the “Is Reload?” toggle control 536 in its “YES” position thereby allowing for reloads for the incentive level / type being configured using the form 504. Alternatively, the configuring user may set the “Is Reload?” toggle control 536 to its “NO” position, as shown in FIG. 5D, to indicate that this incentive level / type will not have any reloads. In this example and as seen by comparing FIG. 5D to FIGS. 5B and 5C, if the configuring user sets the “Is Reload?” toggle control 536 to “NO”, then the form 504 no longer displays the “Unlimited Reloads” toggle control 540 and, if the “Unlimited Reloads” toggle control had been set to its “NO” position (FIG. 5C), then the form no longer displays the “Reloads” field 560. As described below in the subsection titled “IF Programs for Startups”, IF programs typically have predetermined durations with a fixed fundraising goal, and it is undesirable to use the unlimitedreloads feature because the fundraiser would not have a definitive end. Consequently, and similar to the “Is Unlimited?” toggle control 520 discussed above, if the level / type-configuring UI 500 were to be for IF programs only, then the “Unlimited Reloads” toggle control 540 need not be provided.

[0081] As seen in each of FIGS. 5A through 5D, and as particularly labeled in FIG. 5C, the form 504 includes a “Select Image” control 544, here, a soft button, that allows the configuring user to select an image for the program banner (not shown) that the WBI software will display to endusers via a provider website. As noted above, the WBI software uses information input via the form 504 to create a program banner, such as the name and short description input into, respectively, the “Name” field 512 and the “Short Description” field 516. As indicated by the program banners 416(1) to 416(3) of FIG. 4, other information from the form 504 that the WBI software may use to build a program banner includes, but is not limited to, information from the “Reward” field 528, the price field 524, the “Is VIP” toggle control 532, and the “Reloads” field 560, among others. A program banner can be composed of the above or less information and a hyperlink that, when selected by an end-user navigates the end-user’s browser to a webpage of the WBI software that allows the end-user to interact with the WBI software, for example, to sign up for the incentive program, access an existing account, and/or make one or more selections relative to the current incentive level / type. However, the configuring user may want to add a graphical element to the program banner, such as a single or multicolor background image, a graphical image, or a combination of a graphical image and a background image, among others. Fundamentally, there is no limitation on the types of images that a configuring user can add to a program banner. The “Select Image” control 544, when user selected, may navigate the configuring-user’s browser to an image-selection page (not shown) that contains multiple differing images for the configuring user to choose from, if / as desired.

[0082] Although not shown, the form 504 may include other fields and/or other controls for configuring one or more other parameters of an incentive level / type. For example, the form 504 may include an “Expire?” toggle control that allows a configuring user to decide whether or not to set an expiration for the incentive level / type once an end-user has accepted the incentive type in a particular incentivization program. If the configuring user were to set the “Expire?” toggle control to its “NO” position, then the funding-types UI will not apply any expiration to the incentive level / type. However, if the configuring user were to set the “Expire?” toggle control to its “YES” position, then “Add New Incentive Level / Type” UI 500 may cause the form 504 to display an “Expiration” field, or “Expiration” control more generally, that allows the configuring user to set an expiration in any suitable manner. For example, the expiration may be set by a certain passage of time (e.g., week(s), month(s), year(s), etc.) from the date of the original corresponding selection of the incentive type, or it may be set by a fixed date certain. The WBI software, for example, the WBI software 216 of FIG. 2 or the WBI app 304 of FIG. 3 A, would then keep track of the expiration and, in some embodiments, either provide each corresponding end-user with a warning of expiration or provide each corresponding user with an indication of expiration (e.g. countdown timer), or both, among other things. Additional features and functionalities are described below in the following sections. In addition, it is noted that the names shown for the various fields and soft controls illustrated in FIGS. 5A through 5D, such as “Status”, “Name”, “Short Description”, “Is Unlimited?”, “Price”, etc., are merely examples and can be any other suitable names indicative of the corresponding underlying functionalities, which are readily discerned from the example names shown.

[0083] EXAMPLE USE CASES

[0084] Following are example use cases of WBI software made in accordance with aspects of the present disclosure. Specifically, these use cases are directed to local startups (which are the “providers” in the parlance of the descriptions above) that initially want to raise funds to grow and become an established business in a local community by seeking local funding. Every year typically sees millions of startups emerge, with the majority of these being for small businesses that want to serve a local community. Examples of such local businesses are provided above in the section titled “GENERAL”. By far, the biggest reason that local startups fail is lack of sufficient funding. WBI software of the present disclosure, which the startup can integrate directly into its community-centric website, provides a straightforward way for the startup to raise funds by setting up its own, customized, IF program. Consequently, the reach of the IF program is consistent with the reach of the startup’s website, and the incentives and benefits are commensurate with the nature of the startup’s business.

[0085] In a typical example, the startup will need to implement an IF program of the present disclosure for a specific fundraising goal and for a specific amount of time. Consequently, one financial model of a WBI-software vendor requires the startup to pay a flat fee for a single IF program. Of course, the startup, or resulting established business, may desire to implement another IF program and so would pay another flat fee, which may be the same as the first-time flat fee or a discounted fee, as the WBI-software vendor desires for its business model.

[0086] Once the startup has reached its funding goal via the IF program and has become an established business, the business may decide to implement one or more D/R programs, each of which may be ongoing for an unlimited amount of time and/or may be changed on a regular basis, among other possibilities. Consequently, another financial model of a WBI-software vendor requires the business to pay a period subscription fee, such as a monthly or yearly fee, among others. Some differences between the WBI-software functionalities for implementing a limited-goal and/or limited-time IF program on the one hand and for implementing a more open-ended D/R program are described below in the following subsections.

[0087] Of course, the following use cases and their general descriptions immediately above, are merely examples for the sake of illustration and are not limiting in any way.

[0088] IF Programs for Business Startups

[0089] FIG. 6 illustrates an example IF-program homepage of an IF UI 600 of WBI software configured to at least allow startups to create their own customized IF programs to raise money for themselves. In the example shown, the homepage includes a dashboard 604 and a menu 608 that allows a startup to navigate to various features of the IF UI 600. The example dashboard includes, among other things: a name field 612 that allows the startup to name the IF program (a/k/a “Campaign”); a funding goal field 616 that allows the startup to input a funding goal amount; a startdate field 620 that allows the startup to enter a start date for the IF program; an end-date field 624 that allows the startup to enter an end date for the IF program; an actual-funds-collected region 628 that displays both initial funds collected without reloads (field 6281) and total funds collected (field 628T, but excludes outstanding cash payments); a total-funding field 632 that shows total collected, including the outstanding cash payments; and various region showing real-time data on funding selections by end-users (region 636), funding members (i.e., end-user members) (region 640) and funding type (i.e., the differing incentive levels / types used in the current IF program (region 644). In relevant part, the menu 608 includes, among others, a “Dashboard” selector 648, a “Funding Selections” selector 652, and a “Funding Types” selector 656. It is noted that some of the data inputs above, such as the funding-goal field 616, and the start- and end-date fields 620 and 624, are called “fields”, those skilled in the art will readily appreciate that other data- input means, such as drop-down selectors and popup boxes, among others, can be used.

[0090] Relative to embodiments that allow cash payments, as noted immediately above relative to field 628T, outstanding cash payments are not included in the total funds collected displayed there. In the embodiment of FIG. 6, the uncollected funds are displayed in a “Total Funds Uncollected field 628U. The “Total Funds Uncollected” field shows the provider, or Campaign Owner, the specific, uncollected cash amount, which has been paid offline, but not yet collected in- person. The “Total Amount Uncollected” functionality is important to the Campaign Owner, and will not trigger the “End Date” until the residual, uncollected amount is fully received.

[0091] Some embodiments of the WBI software may be configured to require the cash-paying end-user to make the payment within a certain amount of time, such as two days, a week, etc. In such embodiments, when the cash-paying end-user commits to participating in the IF program, the WBI software starts a timer, such as a countdown timer or a count-up timer. If the WBI software receives a payment indicator (see, e.g., payment indicator 374P of FIG. 3C) that the cash has been paid, the WBI software stops the timer and adds the payment to the total funds collected shown in field 628T. However, if the end-user does not make the payment in time, the timer times out, and the held availability of the corresponding level / type is released for another end-user to select and commit to. The WBI software may also be configured to send one or more reminders to the cashpaying end-user at one or more times within the payment time window and/or to send a notice to the end-user of the loss of the held funding opportunity.

[0092] It is noted that the menu 608 remains fixed, while the region currently occupied by the dashboard 604 changes depending on the selections that the startup makes from the menu. For example, when the startup selects the “Funding Selections” selector 652, the WBI software changes the region currently occupied by the dashboard 604 to a funding-selections graphical UI (GUI) (not shown). In an example that those skilled in the art can readily envision, the funding-selections GUI displays, for example, in list form, all of the incentive funding levels / types that are part of the current IF program (campaign). The funding-selections GUI also includes soft control and/or other features that allow the startup to add and remove incentive levels / types to the current campaign as desired. In another example that those skilled in the art can readily envision, when the startup selects the “Funding Types” selector 656, the WBI software changes the region currently occupied by the dashboard 604 to a funding-types GUI (not shown). In one example, the funding-types GUI displays, for example, in list form, all of the incentive funding levels / types that are available for use in the current IF campaign. The funding-types GUI also includes soft control and/or other features that allow the startup to add and remove incentive levels / types to the availability list as desired. Regarding adding new incentive levels/ types, the funding-types GUI may include a selector that, upon startup selection, navigates the startup to the “Add New Incentive Level / Type” UI 500 of FIGS. 5 A through 5D or similar GUI.

[0093] In some embodiments, a funding-types GUI can allow the startup to select a bannerless- participation feature that allows a funder or prospective funder to participate in the underlying IF program at that funding type / level without needing an end-user device that displays the program banners of the funding program. For example, an end-user may not have immediate access to a computer or smartphone, but, when the bannerless-participation feature is turned on, that end-user can call via a landline, or can place an order in-person, at a POS within the establishment. The person placing the order with the WBI software fills in the relevant information from the funder (end-user), and the WBI software captures and shows the order, by notes, how the order was taken, and by whom.

[0094] As noted in other sections above, IF programs are often closed-ended in terms of reaching a predetermined goal amount to be raised or by reaching a predetermined endpoint in time, or as a function of both of these conditions, with an IF program ending due to the first of the conditions to be satisfied. Consequently, the homepage 600 of FIG. 6 includes the funding-goal field 616 and the end-date field 624 that allows a startup to provide, respectively, a monetary amount for the fundraising goal and a date that the IF program will end. In an example, which one(s) of the conditions the startup that the underlying WBI software (not shown, but see, e.g., WBI software 216 of FIG. 2 and WBI software 384 of FIG. 3B) recognizes depends on which one(s) has/have valid values. For example, in some embodiments, the WBI software uses only a goal amount. In this example, the backend determines the rest of the functionalities based on the goal amount, such as the program-setup-assist feature described below and an automatic-end-date feature. Regarding the latter, the WBI software may be configured to automatically populate an end-date field when the total funds collected equals the goal amount, i.e., that a remaining goal amount reaches zero. The provider can use this end date for recordkeeping. In some embodiments, this end date can also trigger an end to the lease of and/or an access lockout to the WBI software. For example, the vendor of the WBI software can set a lease-end / access-lockout time for 7 days after the auto-populated end date, or any other desired time period. In an example of some startups, when a funding goal has been reached and the program has ended, a startup can set in motion the standard business setup procedures, like a location-buildout phase, equipment purchases, etc., to go into business with the newly raised funds. The startup, once open for business, may then have the option to upgrade to using the D/R features of WBI software made in accordance with aspects of the present disclosure. See, for example, the subsection below titled “D/R Programs for Established Businesses” for some additional details.

[0095] As another example, if the startup enters both a goal amount and an end date in the respective funding-goal and end-date fields 616 and 624, then the WB1 software will end the IF program when the first of these two conditions is met. In another example, if the startup enters only a goal amount in the funding-goal field 616 and leaves the end-date field 624 blank, then the WBI software will end the IF program only when the goal amount has been reached. On the other hand, if the startup provides and end date in the end-date field 624 and leaves the funding-goal field 616 blank, then the WBI software will leave the IF program open until the end date, regardless of the amount of funds that have accrued up to the end date. Other possibilities exist for selecting which condition(s) to use. For example, any one or more of various type of soft controls can be used to set the condition(s), such as a toggle control for each condition, among others, as those skilled in the art will readily appreciate.

[0096] When a startup has entered a goal amount in the funding-goal field 616, the WBI software may use that amount in a program-setup-assist feature to assist the startup in configuring the IF program. For example, if the startup has provided a funding goal of $100,000 and has created multiple incentive levels / types having differing payment amounts (e g., $10, $20, $50, $100, $500, $1,000), each having a selectable number of availability, then as the startup selects the availabilities, and reloads, if used, of the differing incentive levels / types, the WBI software may display an amount remaining in a remaining-amount region (not shown) as the user populates a fundingselections GUI (not shown, but accessible via the “Funding Selections” selector 652 on the menu 608. The startup then customizes the availabilities so that the amount remaining in the remaining- amount region is “$0”. In some embodiments, the program-setup-assist feature is always on, while in some embodiments, the program-setup-assist feature is user selectable.

[0097] As discussed above, in some IF programs it would be undesirable to allow an unlimited number of reloads for any of the incentive levels / type (see, e.g., FIG. 5B and corresponding description of the “Unlimited Reloads?” toggle 540) and/or to allow an unlimited number of availabilities of any of the incentive levels / types (see, e.g., FIG. 5B and corresponding description of the “Is Unlimited?” toggle 520). This may be particularly true when the IF program at issue needs to have a definitive end, either by reaching a goal amount or by reaching an end date. For example, if the startup is using the program-setup-assist feature wherein the configuration of the incentive levels /types is such that it exactly matches the goal amount, having any unlimited number of availabilities and/or reloads will thwart that exact match. Consequently, in some embodiment, the WBI software may be configured to never provide an unlimited option for availabilities and reloads. Alternatively, the WBI software may determine whether or not a startup can select an unlimited option based on whether or not a startup has provided a goal amount. Here, if the startup has input a goal amount into the goal field 616, then the WBI software will automatically disable all unlimited options.

[0098] In some embodiments, the WBI software can allow a startup to provide unlimited availability for each of one or more incentive levels / types. For example, if the startup does not know how many funders will participate at any one or more incentive levels / types, has not set a firm goal amount, and has set an end date, then the startup may set the number of availabilities of one or more of the incentive levels / types to be unlimited to allow as many funders as possible to participate, with the only limit being the time limit set by the end date. Alternatively, if the WBI software does not provide an unlimited option for availabilities, to achieve the same effect, the startup may select a comfortably high number of the availabilities for each of one or more of the incentive levels / types.

[0099] In some embodiments, the WBI software can allow a startup to provide unlimited availability for reloads on any one or more incentive levels / types. For example, if the startup has not set a firm goal amount and has set an end date, then the startup may set the number of availabilities of reloads on any one or more of the incentive levels / types to be unlimited. This allows each funder of a corresponding incentive level / type to reload that incentive level / type to reload as many times as it wants, with the only limit being the time limit set by the end date. Alternatively, if the WBI software does not provide an unlimited option for reloads, to achieve the same effect, the startup may select a comfortably high number for the availability of reloads.

[0100] D/R Programs for Established Businesses

[0101] As mentioned above, once a startup has become an established business, it can decide to implement one or more D/R programs using WBI software of the preset disclosure, such as WBI software 216 of FIG. 2 or WBI software 284 of FIG. 3B, among others, and variations thereof. As also mentioned above, the purpose of D/R programs can be distinctly different from IF programs, for example, in terms of length of deployment. Whereas IF programs are typically deployed only for relative short periods of time (e.g., during startup funding), D/R programs can be ongoing for long periods of time and indefinite periods of time. Correspondingly, the incentives and benefits provided by a D/R program can be distinctly different from IF programs. IF programs are generally intended to raise funds for startups, as well as established businesses that may want to obtain funding for launching a new venture, among other things. In contrast, D/R programs are often targeted more toward capturing and maintaining customer loyalty, often by means of membership / loyalty programs.

[0102] In this connection, FIG. 7A illustrates a homepage of a D/R UI 700 of WBI software configured to at least allow businesses to create their own customized D/R programs, for example to foster customer loyalty. In the example shown, the homepage includes a dashboard 704 and a menu 708 that allows a business or other provider to navigate to various features of the D/R IU 700. The example dashboard includes, among other things: a D/R summary region 712 that shows the total 712T of active rewards and discounts, as well as the constituent numbers 712R and 712D of active rewards and discounts, respectively; a funds-collected field 716 that summarizes the funds collected across all active rewards and discounts; a maximum-collectable-funds field 720 that shows a monetary total of all funds that can possibly be collected, including reloads; and various region showing real-time data, here, data on total selections by end-users (region 724), data on reward selections (region 728), data on discount selections (region 732), data on members (region 736), data on latest rewards (region 740) and data on latest discounts (region 744). In relevant part, the menu 708 includes, among others, a “Dashboard” selector 748, a “Selections” selector 752, a “Rewards” selector 756, and a “Discounts” selector 760.

[0103] It is noted that the menu 708 remains fixed, while the region currently occupied by the dashboard 704 changes depending on the selections that the business makes from the menu. For example, when the business selects the “Selections” selector 752, the WBI software changes the region currently occupied by the dashboard 704 to a selections GUI (not shown). In an example that those skilled in the art can readily envision, the selections GUI displays, for example, in list form, all of the rewards and discounts, i.e., the incentive levels / types, that are active in the current D/R program. The selections GUI also includes soft control and/or other features that allow the business to add and remove incentive levels / types (rewards and/or discounts) to the current D/R program, as desired. In another example that those skilled in the art can readily envision, when the business selects either one of the “Rewards” and “Discounts” selectors 756 and 760, the WBI software changes the region currently occupied by the dashboard 704 to the respective one of a rewards GUI or a discounts GUI (not shown). In one example, each of the rewards GUI and discounts GUI displays, for example, in list form, all of the incentive funding levels / types of the corresponding type (i.e., discounts or rewards) that are available for use in the current D/R program.

[0104] Each of the rewards and discount GUIs also includes soft control and/or other features that allow the business to add and remove incentive levels / types to the corresponding availability list as desired. Regarding adding new incentive levels/ types, in one example, each of the rewards and discounts GUIs may include a selector that, upon business selection, navigates the business to the “Add New Incentive Level / Type” UI500 of FIGS. 5A through 5D or similar GUI. In another example, when the business selects an add-new-reward selector (not shown) on the rewards GUI accessed via the “Rewards” selector 756 on the menu 708, the WBI software displays the add-new- rewards GUI 764 shown in FIG. 7B.

[0105] Referring to FIG. 7B, in this example, the add-new-rewards GUI 764 includes a variety of input fields and control similar to corresponding ones of the input fields and control illustrated in FIGS. 5 A through 5D, described above. As those skilled in the art will readily understand, while this embodiment refers to “rewards”, rewards are just one species of an incentive level / type. FIG. 7B shows a preview of a reward-type program banner 768 corresponding to the reward being added as the program banner will be displayed to end-users on the business’s website. As with other program banners described herein, the program banner 768 of FIG. 7B will include a hyperlink to the backend of the WBI software for proper handling, as discussed above. In this example, the program banner 768 includes a name 768N, a brief description 768D, and information 7681 about availability (here, unlimited), reward (here, $14, i.e., 40% match, stated in the brief description, on the base $10 stated in the name), reloads (here, unlimited), and VIP status (here, no).

[0106] As also shown in FIG. 7B, the embodiment of add-new-rewards GUI 764 includes a timer feature that allows the configuring user (e.g., business) to select whether or not to set an expiration for the reward and, if so, set the expiration. In this example, the add-new-rewards GUI 764 includes a timer toggle 772 user-switchable between “Yes” and “No” (not shown) for the former and a set-timer control 776 for the latter. It is noted that while the illustrated set-timer control 776 allows the configuring user to set the expiration in terms of a countdown timer by inputting the number of days, hours, and minutes, in other embodiments the add-new-rewards GUI 764 may have another type of input for setting the expiry, such as an end-date input. In this example, when the timer toggle 772 is set to “No”, the add-new-rewards GUI 764 does not show the set-timer control 776. When the configuring user sets an expiry, the program-banner generator (not shown) includes an expiration indicator 768E, here, a countdown indicator, that, when ultimately displayed on the provider website (not shown), displays real-time expiration information.

[0107] Similarly, when the business selects an add-new-discount selector (not shown) on the rewards GUI accessed via the “Discounts” selector 760 on the menu 708 of FIG. 7A, the WBI software displays the add-new-discounts GUI 780 shown in FIG. 7C. Referring to FIG. 7C, in this example, the add-new-discounts GUI 780 includes a variety of input fields and control similar to corresponding ones of the input fields and control illustrated in FIGS. 5A through 5D, described above. In addition, similarly to the add-new-rewards GUI 764 of FIG. 7B, the add-new-discounts GUI 780 includes the same timer functionality, namely, the timer toggle 772 and the set-timer control 776, which function the same way as described above and can have the same alternatives as described above. As those skilled in the art will readily understand, while this embodiment refers to “discounts”, discounts are just one species of an incentive level / type. FIG. 7C shows a preview of a discount-type program banner 784 corresponding to the discount being added as the program banner will be displayed to end-users on the business’s website. As with other program banners described herein, the program banner 784 of FIG. 7C will include a hyperlink to the backend of the WBI software for proper handling, as discussed above. In this example, the program banner 784 includes a name 784N, a brief description 784D, and information 7841 about availability (here, unlimited), reward (here, second one at 40% off, stated in the brief description, of the regular $4.95 price stated in the name and in the brief description), reloads (here, unlimited), and VIP status (here, no), as well as an expiration indicator 784E, here, a countdown indicator, that, when ultimately displayed on the provider website (not shown), displays real-time expiration information.

[0108] In some embodiment, the WBI software and D/R GUI 700 can be configured to allow the business to set a time limit for each reward and/or discount. This can reduce the burden on the business of tracking all of the reward and discount offerings and/or allow the business to provide further motivation for end-users to participate. For example, a business may desire a particular discount or reward to be active for a certain amount of time, such as a day, a week, a month, etc. As another example, rewards may not utilize timers, as a business may change them frequently. However, and in this example, discounts will have timers to incentivize end-users to react, as discounts will come and go on a frequent basis, more so than rewards, and may be timed in hours, as discounts may /can be a daily occurrence depending on an operator’s preferences. Although not shown, the D/R GUI 700 may include, for example, on the selections GUI (not shown) accessible using the “Selections” selector 752 of FIG. 7A, a field, selector, or other control that allows the business to set an active time period for each reward and discount. The control may be configured for example, to allow the business to input or set a length of time or input or select an end date and/or time. In some cases, such as in the monetary reward illustrated in FIG. 7B, the business may always want to offer that reward. In such a case, the timer feature would not be used.

[0109] Point-of-Sale Integration

[0110] In some embodiments, various features and functionalities of WBI software of the present disclosure is integrated with a business’s point-of-sale (POS) system, for example, via an API of the POS software, as noted above. For example, if the POS system includes a code scanner, a POS operator can use the code scanner to scan codes on certificates (digital or hard (e.g., membership cards, etc.); see, e.g., FIG. 3C and the accompanying description above), and the POS system would communicate the use of the certificate to the WBI software to update its logs on certificate usage. As another example, the business’s POS system may be integrated so as to receive and/or process payments (cash and/or digital) and, in response to receiving and/or acknowledging those payments, automatically update the WBI software. As a further example, the POS system may have a WBI portal that provides functionality of the WBI software useful to a POS operator. Those skilled in the art will readily appreciate that other integrations between POS systems and WBI software of the present disclosure are possible.

[0111] EXAMPLE UI FOR END-USER PARTICIPATION

[0112] When an end-user decides to participate in an incentivization program at a particular incentive level / type, in some embodiments the end-user selects a hyperlink on the provider website, such as a button-type hyperlink that displays “Fund Us” or something similar or otherwise relevant to the incentivization program at issue. In response to that selection, the WBI software presents on the end-user’s browser a landing page for the incentivization program, such as the login landing page 800 shown in FIG. 8A. If the end-user has an existing account for the incentivization program, then the end-user enters her/his login credentials into the credentials field(s), here an email field 804 and a password field 808, or logs-in using any other suitable method. If the end-user does not yet have an account for the incentivization program containing the selected incentive level / type, then she / he can create an account using the “Create Account” link that links the end-user to a separate page (not shown) that the user populates with information to create an account. As those skilled in the art will readily appreciate, such information may include some or all of the following information, among other pieces of information: name, email address, physical address, payment information (e.g., credit/debit card(s) information, bank account information, payment service (e.g., PayPal) information, among others. Once the end-user has entered the correct login credentials and selected the “Login” soft button 812, the WBI software may then display an account homepage, such as the example account homepage 820 shown in FIG. 8B. It is noted that some end-users may bookmark the login page for each account they may have for quick future access to the corresponding account.

[0113] In another example, the provider website may display program banners for the individual incentive levels / types, and when an end-user selects the hyperlink of a desired one of the program banners, that link may direct the end-user to the above-mentioned login page. If the provider website has saved certain cookies for the end-user’s device from a previous session in which the end-user was logged in to her / his incentivization-program account, then the selecting of one of the program banner hyperlinks may land the end-user on the account homepage, such as the account homepage 820 of FIG. 8B or a different landing page, such as a landing page that corresponds to the incentive level / type that the end-user originally selected on the provider website, among other possibilities.

[0114] As an alternative to presenting the login landing page 800 of FIG. 8A in response to the end-user selecting the hyperlink in one of the program banners, the WBI software may present a different landing page (not shown), such as a confirmation landing page that allows the end-user to confirm that she / he indeed intends to participate in the program. In one example, the confirmation landing page may effectively redisplay the program banner of incentive level / type of the initial program banner from which the end-user initially made the selection and ask the end-user to confirm the selection. In some embodiments, the confirmation landing page may allow the end-user to choose another incentive level / type or choose to not participate. If the end-user chooses the same or different incentive level / type via the corresponding program banner or other selector on the confirmation landing page, the WBI software may then present the login landing page 800 of FIG. 8A.

[0115] As noted above, FIG. 8B shows an example account homepage 820 that the WBI software may display to the end-user after the end-user has logged into her / his account. In the example of FIG. 8B, the account homepage provides a listing of all of the incentive levels / types available for the current incentivization program. In this example, the account homepage 820 includes a program, or campaign, identification region 824 that includes the campaign name 828 (here, just the placeholder “Campaign”), the campaign goal 832, and the current funds collected 836. It is noted that the numerical values presented in FIG. 8B are just for visual purposes and do not necessarily reflect any real-world scenario. Also in this example, the account homepage 820 includes an incentive level / type region 840 that displays a program banner for each of the incentive levels / types that are part of the subject campaign.

[0116] Here, the campaign includes three incentive levels / types and, therefore, has three corresponding program banners 844(1) through 844(3). Each of the program banners 844(1) through 844(3) displays static information (e g., name, reward amount, VIP status) and live information (e.g., availability) about the corresponding incentive level / type, as well as a link, here in the form of a corresponding soft button 844B(1) through 844B(3) that, when there is still availability, allows the end-user to confirm that she / he wants to participate in that incentive level / type. In this example, the program banner 844(1) indicates that “Type 1” has no remaining availability. Consequently, the WBI software displays the soft button 844B(1) as showing “No Longer Available” and well as in grayed-out form indicating user non-selectability. In contrast, both of the incentive levels / types of the program banners 844(2) and 844(3) have remaining availability, and, so, the WBI software displays the corresponding soft buttons 844B(2) and 844B(3) as being active and containing the prompt “Select this Funding Type”.

[0117] Upon the end-user selecting one or the other of the soft buttons 844B(2) and 844B(3), the WBI software performs one or more selection algorithms (not shown) that perform(s) a variety of functions, such as processing end-user payment according to any prearranged payment method, causes the WBI software to decrement the availability of that incentive level / type, and post the purchase to an order history (see, e g., the “Order History” tab 848 that the end-user can use to access such history), among other things. Those skilled in the art will readily appreciate the operations that the WBI software would need to perform once an end-user has chosen to participate in the incentivization program, as well as know how to write the required software for performing those operations. Many alternative embodiments and examples are possible using only fundamental principles disclosed in this disclosure. [0118] Any trademark used herein, including each of the word and design marks included in some of the accompanying figures, is owned by the respective owner, who retains all rights in such mark under Federal law, state law, and / or common law.

[0119] Various modifications and additions can be made without departing from the spirit and scope of this invention. Features of each of the various embodiments described above may be combined with features of other described embodiments as appropriate in order to provide a multiplicity of feature combinations in associated new embodiments. Furthermore, while the foregoing describes a number of separate embodiments, what has been described herein is merely illustrative of the application of the principles of the present invention. Additionally, although particular methods herein may be illustrated and/or described as being performed in a specific order, the ordering is highly variable within ordinary skill to achieve aspects of the present disclosure. Accordingly, this description is meant to be taken only by way of example, and not to otherwise limit the scope of this invention.

[0120] Exemplary embodiments have been disclosed above and illustrated in the accompanying drawings. It will be understood by those skilled in the art that various changes, omissions, and additions may be made to that which is specifically disclosed herein without departing from the spirit and scope of the present invention.

Claims

Claims:

1 . A method of providing one or more incentives to end-users via a business website associated with a business, the method being performed by a computing system and comprising: providing a program -builder user interface (UI) that allows a configuring user to create an incentivization program, wherein the program-builder UI allows the configuring user to configure a program banner to present an incentive level / type to the end-users on the business website, wherein the incentive level / type has an associated benefit, and the program banner includes a hyperlink that, when selected by an end-user, navigates to a page that allows that end-user receive the associated benefit; generating website-presentation code that, when executed, presents the program banner on the business website; and deploying the website-presentation code to the business website so that the program banner is accessible to the end-users on the business website.

2. The method of claim 1, wherein the incentivization program is an incentivized-funding (IF) program, and the incentivization level / type is a funding level.

3. The method of claim 2, wherein the program -builder UI includes an end field into which the configuring user inputs an end date and/or time for the incentivization program.

4. The method of claim 2, wherein the program-builder UI includes: a funding-goal field into which the configuring user inputs a goal amount for the IF program; and an IF-program configurator that displays to the configuring user the impact of adding a new funding level to the IF program.

5. The method of claim 2, wherein, in the IF program, the funding level has a real-time availability, and the program banner displays the real-time availability.

6. The method of claim 2, wherein the program -builder UI includes a level-configuration UI configured to allow the configuring user to: set a price for the funding level; and set, for the funding level, a reward amount corresponding to the price; wherein the benefit is the sum of the price and the reward amount.

7. The method of claim 6, wherein the level-configuration UI is configured to allow the configuring user to set the reward amount as a percentage of the price.

8. The method of claim 6, wherein, after the website-presentation code is deployed to the fundraiser website, the program banner displays the price and the reward amount.

9. The method of claim 2, wherein the hyperlink links to a backend of the business website that allows each end-user to participate in funding at the funding level so as to obtain the benefit value.

10. The method of any one of claims 2-9, wherein the level-configuration UI further includes an availability control that allows the configuring user to set a maximum number of fundings at the funding level available to the end-users.

11. The method of claim 10, wherein, after the website-presentation code is deployed to the fundraiser website, the program banner initially displays the maximum number and thereafter displays an updated number of fundings remaining after each selection of the funding selection by one or more of the end-users.

12. The method of claim 10 or 11, wherein the level-configuration UI further includes a reload control that allows the configuring user to set a maximum number of times that a selecting enduser of the end-users that has selected the funding level can reload the benefit value.

13. The method of claim 12, wherein after the website-presentation code is deployed to the business website, the program banner initially displays the maximum number of times that the selecting user can reload the benefit value and thereafter displays an updated number of reloads remaining after each reload selection by a corresponding end-user.

14. The method of claim 1, wherein the incentivization program is a discount / reward (D/R) program, and the incentivization level / type is either a discount type or a reward type.

15. The method of claim 14, wherein the program -builder UI includes an expiration field into which the configuring user inputs expiry information indicating when the discount type or the reward type expires.

16. The method of claim 14, wherein, in the D/R program, the discount type or the reward type has a real-time availability, and the program banner displays the real-time availability.

17. The method of claim 14, wherein the program-builder UI includes a level-configuration UI configured to allow the configuring user to, when the incentive level / type is a reward type: set a price for the reward type; and set, for the reward type, a reward amount corresponding to the price; wherein the benefit is the sum of the price and the reward amount.

18. The method of claim 17, wherein the level-configuration UI is configured to allow the configuring user to set the reward amount as a percentage of the price.

19. The method of claim 17, wherein, after the website-presentation code is deployed to the fundraiser website, the program banner displays the price and the reward amount.

20. The method of claim 14, wherein the hyperlink links to a backend of the business website that allows each end-user to participate in the D/R program.

21. The method of any one of claims 14-20, wherein the level-configuration UI further includes an availability control that allows the configuring user to set a maximum number of availabilities of the discount type or the reward type available to the end-users.

22. The method of claim 21, wherein the level-configuration UI allows the configuring user to set the maximum number to unlimited.

23. The method of claim 21, wherein, after the website-presentation code is deployed to the fundraiser website, the program banner initially displays the maximum number and thereafter displays an updated number of fundings remaining after each selection of the discount type or the reward type by one or more of the end-users.

24. The method of any one of claims 21-23, wherein the level-configuration UI further includes a reload control that allows the configuring user to set a maximum number of times that a selecting end-user of the end-users that has selected the discount type or the reward type can reload the benefit.

25. The method of claim 24, wherein after the website-presentation code is deployed to the business website, the program banner initially displays the maximum number of times that the selecting user can reload the benefit and thereafter displays an updated number of reloads remaining after each reload selection by a corresponding end-user.

26. A computer-readable storage medium containing computer-executable instructions for performing the method of any one of claims 1-25.

27. A computer-readable storage medium containing computer-executable instructions that embody web-based incentivization (WBI) software that provides a plurality of functionalities for a business having a business website, the functionalities comprising: program-building functionality that allows the business to create and maintain at least one incentivization program selected from the group consisting of an incentivized-funding (IF) program and a discount/reward (D/R) program, wherein the at least one incentivization program contains a plurality of incentive levels / types; program-banner-generating functionality that generates a program banner for each of the incentive levels / types, wherein each program banner includes a hyperlink that allows an end-user to select to participate in the incentivization program; and program-banner-deploying functionality that deploys each program banner to the business website.

28. The computer-readable storage medium of claim 27, wherein the at least one incentivization program is an IF program, and the functionalities further comprise time-limiting functionality that ends the IF program in a predetermined manner.

29. The computer-readable storage medium of claim 27, wherein the at least one incentivization program is an IF program, and the functionalities further comprise program-setup-assist functionality that, when the business is creating the IF program, shows the business a real-time impact on a funding goal by adding or modifying any of the incentive levels / types.

30. The computer-readable storage medium of claim 29, wherein the WBI software allows the business to input a funding-goal amount, and the program-setup-assist functionality calculates and displays a remaining amount of the funding-goal amount that needs to be accounted for by an addition of one or more incentive availabilities to the IF program.

31 . The computer-readable storage medium of claim 27, wherein the at least one incentivization program is a D/R program, and the functionalities further comprise unlimited-availability functionality that allows the business to specify unlimited availability for any one or more of the plurality of levels / types.

32. The computer-readable storage medium of claim 27, wherein the at least one incentivization program is a D/R program, and the functionalities further comprise time-limiting functionality that allows the business to specify a limit on the amount of time that each of the incentive levels / types is part of the D/R program.

33. The computer-readable storage medium of claim 27, wherein the business has a business server that provides the business website, and the WBI software is a software instance loaded onto the business server from a WBI-software-vendor server.

34. The computer-readable storage medium of claim 27, wherein the business website has a backend and a frontend, wherein: the WBI software is located on the backend of the business website; and the program-banner-deploying functionality that deploys each program banner to the business website deploys each program banner so that it is accessible to end-users of the business website.

35. The computer-readable storage medium of claim 27, wherein the program-building functionality includes at least one of 1) an IF dashboard that allows the business to build the IF program and 2) a D/R dashboard that allows the business to build the D/R program.

36. The computer-readable storage medium of claim 35, wherein the program-building functionality includes both of the IF dashboard and the D/R dashboard.

37. A method of allowing a plurality of businesses, each having a corresponding business website operating on a respective business webserver, to each offer an incentivization program on the corresponding business website via web-based incentivization (WBI) software, wherein the WBI software includes: program-building features that allow each business to create its own incentivization program that includes a plurality of incentive levels / types, with each incentive level / type having an associated program banner; and a website-presentation code generator that generates website-presentation code that, when executed, presents the program banners on frontends of the business websites; the method comprising: receiving requests from the plurality of businesses to use the WBI software; and in response to receiving the requests, pushing instances of the WBI software to the business webservers for deployment on respective backends of the corresponding business websites.

38. The method of claim 37, wherein the incentivization program is an incentivized-funding (IF) program, and each incentivization level / type is a funding level.

39. The method of claim 38, wherein the program -building features include: a funding-goal field into which each business inputs a goal amount for the IF program; and an IF-program configurator that displays to the corresponding business the impact of adding a new funding level to the IF program.

40. The method of claim 38, wherein, in the IF program, each funding level has a real-time availability, and the corresponding program banner displays the real-time availability.

41. The method of claim 37, wherein each program banner includes a hyperlink that links to the backend of the corresponding business website to allow each end-user to participate in the incentivization program at the incentive level / type.

42. The method of claim 37, wherein the incentivization program is a discount / reward (D/R) program, and the incentivization level / type is either a discount type or a reward type.

43. The method of claim 42, wherein the program -building features include an expiration field into which the configuring user inputs expiry information indicating when the discount type or the reward type expires.

44. The method of claim 43, wherein, in each D/R program, the discount type or the reward type has a real-time availability, and the program banner displays the real-time availability.

45. A computer-readable storage medium containing computer-executable instructions for performing the method of any one of claims 37-45.

46. A method of providing one or more funding incentives to end-users via a fundraiser website associated with a fundraiser, the method being performed by a computing system and comprising: providing an incentivized funding (IF)-program-builder user interface (UI) that allows a configuring user to build an IF banner, wherein the IF -program -builder UI allows the configuring user to configure the IF banner to present a funding level to the end-users on the fundraiser website, wherein the funding level has a corresponding benefit value; generating website-presentation code that, when executed, presents the IF banner on the fundraiser website; and deploying the website-presentation code to the fundraiser website so that the IF banner is accessible to the end-users on the fundraiser website.

47. The method of claim 46, wherein the IF-program -builder UI includes a lev el -configuration UI configured to allow the configuring user to: set a price for the funding level; and set, for the funding level, a reward corresponding to the price.

48. The method of claim 47, wherein the level-configuration UI is configured to allow the configuring user to set the reward as a percentage of the price.

49. The method of claim 47, wherein, after the website-presentation code is deployed to the fundraiser website, the IF banner displays the benefit value as a sum of the price and the reward.

50. The method of claim 46, wherein the IF banner includes a link to a backend of the fundraiser website that allows each end-user to participate in funding at the funding level so as to obtain the benefit value.

51. The method of any one of claims 1 through 5, wherein the level-configuration UI further includes an availability control that allows the configuring user to set a maximum number of fundings at the funding level available to the end-users.

52. The method of claim 51, wherein, after the website-presentation code is deployed to the fundraiser website, the IF banner initially displays the maximum number and thereafter displays an updated number of fundings remaining after each selection of the funding selection by one or more of the end-users.

53. The method of claim 51 or 52, wherein the level-configuration UI further includes a reload control that allows the configuring user to set a maximum number of times that a selecting enduser of the end-users that has selected the funding level can reload the benefit value.

54. The method of claim 53, wherein after the website-presentation code is deployed to the fundraiser website, the IF banner initially displays the maximum number of times that the selecting user can reload the benefit value.

55. A method of enabling a plurality of fundraisers, having a plurality of differing fundraiser websites, to provide individualized fundraising programs, the method being performed by a computing system and comprising: receiving, by a fundraiser-software server, from each of the plurality of differing fundraisers, a request to use fundraiser software, wherein the fundraiser software is configured to allow each of the fundraisers to create its own fundraising program; and in response to receiving each request to use the fundraiser software, electronically delivering, by the fundraising-software server, an instance of the fundraiser software to a backend of the fundraiser website of the requesting fundraiser.

56. The method of claim 55, wherein the fundraiser- software server includes registration software designed and configured to allow each of the fundraisers to register so as to obtain a corresponding instance of the fundraiser software.

57. The method of claim 55, wherein the fundraiser software is web-based incentivized (WBI) funding software that allows each fundraiser to create an individualized IF program for deployment in the corresponding fundraiser website.

58. The method of claim 55, wherein each instance of the fundraiser software is designed and configured to generate website-presentation code that, when executed by a backend of the fundraiser website, displays a fundraising banner for the individualized fundraising program on a frontend of the fundraiser website.

59. The method of claim 58, wherein the fundraiser software is web-based incentivized (WBI) funding software, and the fundraising banner is an IF banner.

60. The method of claim 59, wherein each instance of the fundraiser software includes an incentivized-funding (IF)-program-builder user interface (UI) having a level-configuration UI configured to allow a configuring user: to set a price for a funding level; and to set, for the funding level, a reward corresponding to the price.

61. The method of claim 60, wherein the level-configuration UI is designed and configured to allow the configuring user to set the reward as a percentage of the price.

62. The method of claim 60, wherein, after the website-presentation code is deployed to the fundraiser website, the IF banner displays a benefit value that is a sum of the price and the reward.

63. The method of claim 59, wherein the IF banner includes a link to the backend of the fundraiser website that allows each end-user to participate in funding at the funding level so as to obtain a benefit value associated with a funding level of the funding program.

64. The method of claim 59, wherein each instance of the fundraiser software includes an incentivized-funding (IF)-program-builder user interface (UI) having a level-configuration UI that includes an availability control that allows the configuring user to set a maximum number of fundings, at the funding level, available to the end-users.

65. The method of claim 64, wherein, after website-presentation code is deployed to the fundraiser website to display an IF, the IF banner initially displays the maximum number and thereafter displays an updated number of fundings remaining after each selection of the funding selection by one or more of the end-users.

66. The method of claim 64 or 65, wherein the level-configuration UI further includes a reload control that allows the configuring user to set a maximum number of times that a selecting enduser of the end-users that has selected the funding level can reload the benefit value.

67. The method of claim 66, wherein after the website-presentation code is deployed to the fundraiser website, the IF banner initially displays the maximum number of times that the selecting user can reload the benefit value.

68. A computer-readable storage medium containing machine-executable instructions for performing the method of any one of claims 46-67.