WO2017151927A1

WO2017151927A1 - Closed-loop donation arbitration system

Info

Publication number: WO2017151927A1
Application number: PCT/US2017/020457
Authority: WO
Inventors: Allen Stern BRASWELL III
Original assignee: Tecdonor
Priority date: 2016-03-02
Filing date: 2017-03-02
Publication date: 2017-09-08

Abstract

Embodiments include systems and methods for arbitration of donor transactions in a closed-loop arbitration system among different categories of entities: the non-profit entities (NPEs), volunteers, and for-profit entities (FPEs). The arbitration uses a customized currency that is valid within the closed-loop platform, referred to as a closed-loop currency unit (CLCU). For example, NPEs can create engagement opportunities in the system, and volunteers can selectively engage with those opportunities in exchange for a defined CLCU value. The volunteers can donate their obtained CLCUs to NPEs and/or can redeem their obtained CLCUs for incentives created by FPEs in the system. FPEs can also create request-for-donation (RFD) records (e.g., as guaranteed donation offers) in the system, and NPEs can exchange their CLCUs (e.g., donated to them by volunteers) to receive cash-equivalent donations from the FPEs according to the RFD records.

Description

CLOSED-LOOP DONATION ARBITRATION SYSTEM

FI ELD

[0001] Embodiments relate generally to arbitration of transactions, and, more particularly, to techniques for arbitrating donation transactions between volunteers, not-for-profits, and for-profits in a in a closed-loop system.

BACKG ROU N D

[0002] Today, the vast majority of charitable contributions from for-profit entities (e.g., large corporations) are going to a very small percentage of non-profit entities. Even though a smaller and/or less-known nonprofit does an excellent job in its mission and potentially has a larger beneficial impact on our economy, it may not get sufficient support because of its lesser notoriety. For example, smaller non-profits tend to have smaller geographic scope, smaller marketing budgets, smaller staffs, and less clout, which can limit their ability to attract donors and funds. Further, it can be cumbersome (and often impractical or unattractive) for larger for-profit entities to donate to, and/or otherwise engage with, large numbers of smaller non-profits, and/or non-profits that lack certain donor infrastructures. Even further, it is typically difficult for non-profits to find and retain volunteers and to incentivize those volunteers to stay engaged and active over time.

BRI EF SUM MARY

[0003] Among other things, embodiments provide novel systems and methods for arbitration of donor transactions in a closed-loop arbitration system. The arbitration system can include an opportunity arbitration system, an incentive arbitration system, and a request arbitration system, which can arbitrate donation transactions among different categories of entities: the non-profit entities (N PEs), volunteers, and for-profit entities (FPEs). The arbitration uses a customized currency that is valid within the closed-loop platform, referred to as a "closed-loop currency unit" (CLCU). For example, N PEs can create engagement opportunities in the system, and volunteers can selectively engage with those opportunities in exchange for a defined CLCU value. The volunteers can donate their obtained CLCUs to NPEs and/or can redeem their obtained CLCUs for incentives created by

FPEs in the system. FPEs can also create request-for-donation (RFD) records (e.g., as guaranteed donation offers) in the system, and N PEs can exchange their CLCUs (e.g., donated to them by volunteers) to receive cash-equivalent donations from the FPEs according to the RFD records. BRIEF DESCRIPTION OF THE DRAWINGS

[0004] The present disclosure is described in conjunction with the appended figures:

[0005] FIG. 1 shows a block diagram of an illustrative closed-loop donation arbitration environment, according to various embodiments;

[0006] FIG. 2 shows an illustrative opportunity arbitration environment, according to various embodiments;

[0007] FIG. 3 shows an illustrative request-for-donation (RFD) arbitration environment, according to various embodiments;

[0008] FIG. 4 shows an illustrative incentive arbitration environment, according to various embodiments;

[0009] FIG. 5 shows an illustrative computational system for implementing certain functionality of a design optimization system, according to various embodiments;

[0010] FIG. 6 shows a flow diagram of a method for arbitration of donation transactions in a closed- loop network, according to various embodiments;

[0011] FIG. 7 shows an example screenshot of a home dashboard of an illustrative volunteer sub- portal;

[0012] FIG. 8 shows example screenshots for obtaining and/or editing volunteer profile information via the illustrative volunteer sub-portal of FIG. 7;

[0013] FIG. 9 shows example screenshots for publicly providing volunteer profile information via the illustrative volunteer sub-portal of FIG. 7;

[0014] FIG. 10 shows an example screenshot of a home dashboard of an illustrative for-profit sub- portal;

[0015] FIG. 11 shows example screenshots for obtaining and/or editing for-profit entity profile information via the illustrative for-profit sub-portal of FIG. 10;

[0016] FIG. 12 shows example screenshots for publicly providing for-profit entity profile information via the illustrative for-profit sub-portal of FIG. 10;

[0017] FIG. 13 shows an example screenshot of a home dashboard of an illustrative non-profit sub- portal; [0018] FIG. 14 shows example screenshots for obtaining and/or editing non-profit entity profile information via the illustrative non-profit sub-portal of FIG. 13;

[0019] FIG. 15 shows example screenshots for publicly providing non-profit entity profile information via the illustrative non-profit sub-portal of FIG. 13;

[0020] FIG. 16 shows example screenshots for obtaining parameters for opportunities via an illustrative non-profit sub-portal;

[0021] FIG. 17 shows an example screenshot of a created opportunity displayed via an illustrative non-profit sub-portal;

[0022] FIG. 18 shows example screenshots of opportunities available to a volunteer displayed via an illustrative volunteer sub-portal;

[0023] FIG. 19 shows an example screenshot of submitted volunteer applications, and their respective statuses, displayed via an illustrative volunteer sub-portal;

[0024] FIGS. 20A and 20B show example screenshots of volunteer applications received by a nonprofit entity via an illustrative non-profit sub-portal;

[0025] FIG. 21A shows an example screenshot of a portion of an illustrative non-profit sub-portal through which non-profit entities can verify fulfillment of an opportunity by a volunteer;

[0026] FIG. 21B shows an example screenshot that indicates a present CLCU count of a volunteer displayed via an illustrative volunteer sub-portal;

[0027] FIG. 22 shows example screenshots of a volunteer donation of CLCUs to a non-profit entity 15 from the volunteer's perspective;

[0028] FIG. 23 shows an example screenshot of a portion of an illustrative non-profit sub-portal showing donation offers (RFDs) created by for-profit entities;

[0029] FIG. 24 shows example screenshots of a portion of an illustrative for-profit sub-portal showing donation requests from non-profit entities in response to the donation offers (RFDs) created by a for-profit entity;

[0030] FIG. 25 shows example screenshots of a portion of an illustrative for-profit sub-portal for creating incentive records, and example screenshot providing search and display of a for-profit entity's created incentives via a portion of the illustrative for-profit sub-portal; [0031] FIG. 26 shows example screenshots of a portion of an illustrative for-profit sub-portal 160 showing incentives obtained by volunteers that are valid, already redeemed, and expired, respectively;

[0032] FIG. 27 shows an example screenshot of a portion of an illustrative volunteer sub-portal showing incentives obtained by an associated volunteer; an

[0033] FIG. 28 shows an example screenshot of an illustrative portions of a non-profit sub-portal or for-profit sub-portal for managing employees.

[0034] In the appended figures, similar components and/or features may have the same reference label. Further, various components of the same type may be distinguished by following the reference label by a second label that distinguishes among the similar components. If only the first reference label is used in the specification, the description is applicable to any one of the similar components having the same first reference label irrespective of the second reference label.

DETAI LED DESCRI PTION

[0035] Charitable activities generally involve a number of different types of transactions and interactions between a number of different types of parties. For the sake of simplicity, the parties can be placed in three general categories: non-profits, for-profits, and volunteers. In the first category, non-profit entities typically want to incentivize volunteers to become engaged, and to stay engaged, in helping fulfill their goals. However, it can be difficult for non-profit entities to find and retain volunteers (or for volunteers to find the non-profit entities), as it can take appreciable time and money resources to advertise the entity and its present volunteer opportunities to potential volunteers. Non-profit entities also typically desire goods, services, or money from for-profit entities to support their operations. However, it can be difficult for the non-profit entities to find willing for- profits, to compete with other non-profits for the resources of those for-profits, to develop and maintain relationships with those for-profits, etc. Accordingly, much of the operating resources (including budget, staff, time, etc.) of non-profit entities, particularly smaller non-profit entities, can be consumed in attracting, developing, and maintaining transactional relationships with volunteers and for-profit entities.

[0036] The second and third categories tend to have corresponding difficulties to those of the nonprofit entities. In the second category, many for-profit entities wish to donate a certain amount of goods, services, and/or money to non-profit entities; but it is often cumbersome (and even impractical) for them to engage with large numbers of small non-profit entities, to track large numbers of smaller donation transactions (e.g., for tax purposes), etc. As such, for-profit entities, particularly larger for-profit entities, often tend to engage only with the largest non-profit entities with the most established donation infrastructures. Similarly, many for-profit entities desire to incentivize volunteers (e.g., employees, customers, etc.) to engage with non-profit entities, but it can be difficult to provide and manage such incentives. For example, there can be nuanced legal distinctions about what types of benefits can be provided to those volunteers, it can be difficult to track whether the volunteers actually had meaningful engagements with the non-profit entities, it can be difficult for the for-profit entities to know what opportunities are available from non-profit entities and how to publicize those opportunities to potential volunteers, etc. In the third category, many individuals desire to engage with non-profit entities as volunteers, but they can tend to run into a number of difficulties. For example, it can be difficult to search for, find details for, and participate in, volunteer opportunities; it can be difficult to translate those engagements into quantifiable donations to non-profit entities, or for non-profit entities to obtain quantifiable returns for those engagements; it can be difficult for those volunteers to feel incentivized to continue volunteering; etc.

[0037] Accordingly, embodiments described herein provide systems and methods for arbitrating donation transactions between volunteers, non-profit entities, and for-profit entities in a in a closed- loop platform. In the following description, numerous specific details are set forth to provide a thorough understanding of the present invention. However, one having ordinary skill in the art should recognize that the invention may be practiced without these specific details. In some instances, circuits, structures, and techniques have not been shown in detail to avoid obscuring the present invention.

[0038] Turning first to FIG. 1, a block diagram is shown of an illustrative closed-loop donation arbitration environment 100, according to various embodiments. The environment 100 can be implemented as an arbitration portal 105 that provides various categories of users with access to various systems. For example, the arbitration portal 105 can provide volunteers 145, non-profit entities 155, and for-profit entities 165 with access to an opportunity arbitration system 110, an incentive arbitration system 120, and a request arbitration system 130 via a volunteer sub-portal 140, a non-profit sub-portal 150, and a for-profit sub-portal 160, respectively. The various systems can arbitrate donation transactions among the different categories of entities (i.e., the non-profit entities 155, volunteers 145, and for-profit entities 165) using a customized currency that is valid within the closed-loop platform. The customized currency is referred to herein as a "closed-loop currency unit" (CLCU) 180. In some embodiments, the CLCU 180 is implemented as points, or as a "tax-exempt coin" (i.e., representing that the CLCU 180 is customized for use with tax-exempt donation transactions). The CLCU 180 may or may not convert directly (within the closed-loop system) to a standard monetary currency (e.g., 1 CLCU = 1 U.S. dollar). Notably, the CLCUs are intended only for use within the closed-loop system and are not intended to have any cash (or cash- equivalent) value outside the closed-loop system.

[0039] Use of CLCUs 180 can allow each entity category, via the closed loop platform, to engage with the other entity categories in a manner that increases the desired impact of the transaction, while mitigating inefficiencies that tend to frustrate such transactions. For example, the opportunity arbitration system 110 can enable non-profit entities 155 (via the non-profit sub-portal 150) to create, manage and validate volunteer opportunities; and can enable volunteers 145 (via the volunteer sub-portal 140) to fulfill those opportunities in exchange for CLCUs 180. The incentive arbitration system 120 can enable for-profit entities 165 (via the for-profit sub-portal 160) to create and manage incentives for volunteers 145; and can enable volunteers 145 (via the volunteer sub- portal 140) to exchange their CLCUs 180 for those incentives. The request arbitration system 130 can enable for-profit entities 165 (via the for-profit sub-portal 160) to create and manage request- for-donation thresholds to encourage donation requests from non-profit entities 155; and can enable non-profit entities 155 (via the non-profit sub-portal 150) to exchange CLCUs 180 (e.g., donated by volunteers 145) for donations from those for-profit entities 165.

[0040] As used herein, "non-profit entities" 155 can include any entity classified as a non-profit, not- for-profit, or other similar business entity under the applicable tax code (e.g., as defined under Section 501(c)(3) of the United States Internal Revenue Code, or the like), such that the entity is eligible to receive tax-deductible charitable donations. The terms "volunteer" and "for-profit entity," as used herein, are intended to refer to their respective transactional role and goals, and not to be limited to a particular individual or entity status. For example, a volunteer 145 can be any individual or entity desiring to engage as an individual party in an opportunity offered by a nonprofit entity 155, such that "payment" (as explained herein) for fulfilling the opportunity is accounted with respect to that volunteer 145 as an individual party (as opposed to being distributed among multiple parties, which would be considered as multiple volunteers 145). Similarly, a for- profit entity 165 can be any type of business entity or individual desiring to provide tax-deductible goods, services, or money to non-profit entities 155; and/or to incentivize volunteers 145 to engage with those non-profit entities 155. [0041] Each volunteer 145 can interface with the volunteer sub-portal 140 (or with a respective instance of the volunteer sub-portal 140) via any suitable communications network 170a; each nonprofit entity 155 can interface with the non-profit sub-portal 150 (or with a respective instance of the non-profit sub-portal 150) via any suitable communications network 170b; and each for-profit entity 165 can interface with the for-profit sub-portal 160 (or with a respective instance of the for- profit sub-portal 160) via any suitable communications network 170c. The networks 170a, 170b, and 170c can be portions of a same network (e.g., the Internet), or can be, or can include, different networks. The networks 170 can include any suitable public or private networks, and can include any suitable wired or wireless connections. Each sub-portal (the volunteer sub-portal 140, nonprofit sub-portal 150, and for-profit sub-portal 160) can be implemented in any suitable manner that provides a network interface between the respective users and one or more of the opportunity arbitration system 110, incentive arbitration system 120, and request arbitration system 130. For example, each sub-portal (or each instance thereof) can be implemented in-whole or in-part as a served application accessible over the network (e.g., cloud based, hosted on a network server, etc.), as a client application (e.g., as a resident application running on a computational device of the user), as a client-server application (e.g., as a thin client, app, etc.), or in any other suitable manner.

[0042] According to some embodiments, prior to interacting with the environment 100, a user registers with the environment 100 (e.g., with the portal 105) and creates an account. The accounts can be created differently and can include (and/or require) different types of information for different categories of user. Volunteers 145 can use the volunteer sub-portal 140 to create an account with information relevant for volunteering. In some implementations, only a minimal amount of information is entered by the user and stored in association with the volunteer 145 account, such as a user name and password. In other implementations, additional information can be provided to assist the volunteer 145 and/or the environment 100 in identifying relevant opportunities. For example, in some implementations the volunteer 145 account can include demographic information (e.g., the user's location to identify local opportunities), personal information (e.g., certain opportunities may require, or be more appropriate for, certain minimum age, height, weight, educational background, physical background, etc.), preferences (e.g., the user can select which categories or types of opportunities are of interest), etc.

[0043] FIG. 7 shows an example screenshot 700 of a home dashboard of an illustrative volunteer sub-portal 140. The illustrated dashboard indicates, for an associated volunteer 145, summary information and top-level navigation control. For example, the dashboard indicates hours worked (e.g., in relation to fulfilling opportunities), reward points (e.g., CLCUs 180 obtained from fulfilling opportunities that have not been donated or spent), points donated (e.g., CLCUs 180 donated to non-profit entities 155), money donated (e.g., for embodiments that permit direct cash donations), etc. Some implementations can also provide top-level navigation access to information relating to the user as a volunteer 145, to the user as affiliated with one or more non-profit entities 155 (e.g., as an employee), to the user as affiliated with one or more for-profit entities 165 (e.g., as an employee), etc. FIG. 8 shows example screenshots 800a, 800b, and 800c for obtaining and/or editing volunteer 145 profile information via the illustrative volunteer sub-portal 140 of FIG. 7 (e.g., privately visible only to the volunteer 145 and/or other authorized users). For example, screenshot 800a provides access to basic account information (e.g., user name or email and password), screenshot 800b provides access to basic profile information (e.g., name, bio, photo, resume, etc.), and screenshot 800c provides access to basic interests information (e.g., geographic location, categories of interest, etc.). FIG. 9 shows example screenshots 900a and 900b for publicly providing volunteer 145 profile information via the illustrative volunteer sub-portal 140 of FIG. 7. For example, after having created a profile using portions of the volunteer sub-portal 140, such as those illustrated in FIG. 8, a public-facing profile is generated that can be viewed by others (e.g., other volunteers 145, non-profit entities 155, for-profit entities 165, etc.). As illustrated, the public profile can include information, such as photo, name, interests, volunteer experience, donation history, etc.

[0044] Returning to FIG. 1, for-profit entities 165 can use the for-profit sub-portal 160 to create an account with relevant for-profit-related information. In some implementations, only a minimal amount of information is entered and stored in association with the for-profit entity 165 account, such as a user name, entity name, and password. In other implementations, additional information can be provided to assist the for-profit entities 165 and/or the environment 100, such as official entity information (e.g., official entity name, doing business as ( DBA) name, state of incorporation, tax identification number, entity description, logo, etc.), contact information (e.g., primary contact name, phone numbers, email addresses, web addresses, etc.), employee affiliations (e.g., identifying volunteers 145 as employees for purposes of incentives, as described below), etc.

[0045] FIG. 10 shows an example screenshot 1000 of a home dashboard of an illustrative for-profit sub-portal 160. The illustrated dashboard indicates, for an associated for-profit entity 165, summary information and top-level navigation control. For example, the dashboard indicates number of hours worked (e.g., verified hours worked by volunteers 145 as employees or other affiliates of the for-profit entity 165 in relation to fulfilling opportunities created by non-profit entities 155), number of points donated (e.g., CLCUs 180 donated to non-profit entities 155 by volunteers 145 as employees or other affiliates of the for-profit entity 165), coupons sold (e.g., incentives provided to volunteers 145 in exchange for CLCUs 180), etc. Some implementations can also show messages indicating tasks, or the like, such as updates from affiliated volunteers 145, requests for incentives, etc. FIG. 11 shows example screenshots 1100a and 1100b for obtaining and/or editing for-profit entity 165 profile information via the illustrative for-profit sub-portal 160 of FIG. 10 (e.g., privately visible only to the for-profit entity 165 and/or other authorized users, such as authorized employees of the for-profit entity 165). For example, screenshot 1100a provides access to basic profile information (e.g., name, mission, description, website, logo, etc.), and screenshot 1100b provides access to basic contact information (e.g., email address, phone number, address, etc.). FIG. 12 shows example screenshots 1200a, 1200b, and 1200c for publicly providing for-profit entity 165 profile information via the illustrative for-profit sub-portal 160 of FIG. 10. For example, after having created a profile using portions of the for-profit sub-portal 160, such as those illustrated in FIG. 11, a public-facing profile is generated that can be viewed by others (e.g., other volunteers 145, non-profit entities 155, for-profit entities 165, etc.). As illustrated, the public profile can include information, such as logo, name, description, incentive (e.g., coupon) offers, donation history, contact information, etc.

[0046] Returning to FIG. 1, non-profit entities 155 can use the non-profit sub-portal 150 to create an account with relevant non-profit-related information. In some implementations, only a minimal amount of information is entered and stored in association with the non-profit entity 155 account, such as a user name, entity name, and password. Certain implementations require that a non-profit provides certain information to support its non-profit status (e.g., its tax identification number, a signed certification statement, and/or other documentation); and some such implementations further require that the non-profit is validated (e.g., automatically by components of the platform 105, manually by individuals associated with the platform 105, etc.) prior to engaging with the platform 105 as a non-profit entity 155. Other implementations can request additional information to assist the non-profit entities 155 and/or the environment 100, such as official entity information (e.g., official entity name, doing business as (DBA) name, state of incorporation, tax identification number, entity description, logo, etc.), contact information (e.g., primary contact name, phone numbers, email addresses, web addresses, etc.), entity mission (e.g., goals, geographic reach, etc.), etc.

[0047] FIG. 13 shows an example screenshot 1300 of a home dashboard of an illustrative non-profit sub-portal 150. The illustrated dashboard indicates, for an associated non-profit entity 155, summary information and top-level navigation control. For example, the dashboard indicates number of engaged volunteers (e.g., engaged with opportunities created by the non-profit entity 155), number of verified hours (e.g., verified hours worked by volunteers in relation to fulfilling the non-profit entity's 155 opportunities), number of points (e.g., CLCUs 180 donated by volunteers 145), etc. Some implementations can also show messages indicating tasks, or the like, such as received, pending volunteer applications for opportunities created by the non-profit entity 155. FIG. 14 shows example screenshots 1400a, 1400b, and 1400c for obtaining and/or editing non-profit entity 155 profile information via the illustrative non-profit sub-portal 150 of FIG. 13 (e.g., privately visible only to the non-profit entity 155 and/or other authorized users, such as authorized employees of the non-profit entity 155). For example, screenshot 1400a provides access to basic contact information (e.g., email address, phone number, address, 501(c)(3) information, tax identification number, etc.), screenshot 1400b provides access to basic interests information, and screenshot 1400c provides access to basic profile information (e.g., name, mission, description, website, logo, etc.). FIG. 15 shows example screenshots 1500a and 1500b for publicly providing non-profit entity 155 profile information via the illustrative non-profit sub-portal 150 of FIG. 13. For example, after having created a profile using portions of the non-profit sub-profile 150, such as those illustrated in FIG. 14, a public-facing profile is generated that can be viewed by others (e.g., other volunteers 145, non-profit entities 155, for-profit entities 165, etc.). As illustrated, the public profile can include information, such as logo, name, description, interests, volunteer opportunities, donation history, contact information, etc.

[0048] FIG. 2 shows an illustrative opportunity arbitration environment 200, according to various embodiments. The opportunity arbitration environment 200 includes an embodiments of the opportunity arbitration system 110, and the incentive arbitration system 120 and the request arbitration system 130 are also shown for context. The opportunity arbitration system 110 can include an opportunity data store 210, an opportunity creation subsystem 212, an opportunity provision subsystem 214, an opportunity fulfillment subsystem 216, and an opportunity verification subsystem 218. As described with reference to FIG. 1, three categories of users can interact with various functions of embodiments described herein: volunteers 145, non-profit entities 155, and for- profit entities 165. Generally, the volunteers 145 and the non-profit entities 155 can interact with the opportunity arbitration system 110 via the volunteer sub-portal 140 and the non-profit sub- portal 150, respectively. The for-profit entities 165 can interact with other systems via the for-profit sub-portal 160, respectively. As described above, each user can have a stored profile, including any suitable profile information. Profile information of the volunteers 145, non-profit entities 155, and for-profit entities 165 are stored in volunteer data stores 240, non-profit data stores 250, and for- profit data stores 360 (shown in FIG. 3), respectively. [0049] As illustrated, non-profit entities 155 can interface, via the non-profit sub-portal 150, with the opportunity creation subsystem 212 to create volunteer opportunities. Creating the volunteer opportunities can include defining any suitable parameters for the opportunity, such as a title, description, primary contact information, time and date, duration, recurrence, rate (e.g., number of CLCUs 180 offered for completion, per hour, etc.), volunteer requirements (e.g., number of volunteers needed, minimum age, etc.), etc. The created volunteer opportunities can be stored in the opportunity data store 210 in relation to the defined parameters. Some example opportunities can include food sorting for a food bank, or making calls for fundraising or advocacy.

[0050] FIG. 16 shows example screenshots 1600a and 1600b for obtaining parameters for opportunities via an illustrative non-profit sub-portal 150. For example, as illustrated, opportunities can be defined with information including title, description, photo, relevant categories, location (e.g., whether remote work is permitted), date and time, estimated duration, contact information, etc. FIG. 17 shows an example screenshot 1700 of a created opportunity displayed via an illustrative non-profit sub-portal 150. For example, after having created and stored an opportunity record, a public-facing version of the opportunity record can be generated for viewing with information, such as photo, name, interests, details, etc.

[0051] Returning to FIG. 2, volunteers 145 can interface, via the volunteer sub-portal 140, with the opportunity provision subsystem 214, which can provide access to some or all of the stored opportunities. For example, the volunteer sub-portal 140 can include a search function that assists the volunteers 145 with identifying relevant opportunities. Some implementations automatically filter the opportunities provided to each volunteer 145 based on the volunteer's 145 profile information (e.g., location, preferences, skills, age, etc.). Via the volunteer sub-portal 140, the volunteers 145 can view detailed stored in association with the opportunities, such as description, time, place, duration, etc. If a volunteer 145 desires to engage with an opportunity, the volunteer 145 can apply for the opportunity. In some implementations (and/or in some cases), the application is automatically accepted. In other implementations (and/or in other cases), the opportunity is stored in association with defined applicant parameters, and the opportunity arbitration system 110 can automatically determine whether the applicant volunteer 145 meets the criteria and can automatically approve or deny the application, accordingly. In other implementations (and/or in other cases), an application is generated and provided to the non-profit entity 155 that created the opportunity. For example, the opportunity provision subsystem 214 can generate prompts for the volunteer 145 to fill out via the volunteer sub-portal 140, and/or the opportunity provision subsystem 214 can automatically gather relevant information from the volunteer 145 profile, which it can use to generate an application. The application can automatically be transferred to an inbox, notification, task, or the like, for the non-profit entity 155 that owns (e.g., typically, that generated) the opportunity. The owning non-profit entity 155 can accept or deny the application, and the applicant volunteer 145 can receive a notification (e.g., as a message via the volunteer sub-portal 140, via email, via short message service (SMS), etc.) of whether the application was accepted or denied.

[0052] FIG. 18 shows example screenshots 1800a and 1800b of opportunities available to a volunteer 145 displayed via an illustrative volunteer sub-portal 140. Screenshot 1800a shows one illustrative type of opportunity display that includes a search bar, filter controls, opportunity record thumbnails, etc. Screenshot 1800b shows details of a selected one of the opportunity records (e.g., selected from the display illustrated in screenshot 1800a). FIG. 19 shows an example screenshot of submitted volunteer 145 applications, and their respective statuses, displayed via an illustrative volunteer sub-portal 140. For example, after a volunteer 145 has applied for a number of opportunities, the applications can be in various statuses, such as accepted, rejected, pending approval, etc.

[0053] FIGS. 20A and 20B show example screenshots 2000a, 2000b, and 2000c of volunteer 145 applications received by a non-profit entity 155 via an illustrative non-profit sub-portal 150. For example, screenshot 2000a shows an application that has been received by a non-profit entity 155 from a volunteer 145 and is still pending approval by the non-profit entity 155. The non-profit entity 155 can view details relating to the volunteer 145, send the volunteer a message, accept or reject the application, etc. Screenshot 2000b shows a list of the opportunities created by a non-profit entity 155 and provides controls for editing the opportunities, viewing submitted applications for the opportunity, verifying hours of volunteers 145 that engaged with the opportunities, creating new opportunities, etc. Screenshot 2000c shows an overview of received applications for opportunities and their respective statuses. For example, controls and indications are provided to allow access to application details, to show whether applications are accepted or rejected (or pending), etc.

[0054] Returning to FIG. 2, if (and/or once) the application is accepted, the applicant volunteer 145 can engage in (e.g., perform) the volunteer opportunity. When the opportunity has been performed, the performance of the opportunity can be captured by the opportunity fulfillment subsystem 216. In some embodiments, the volunteer 145 can indicate to the opportunity fulfillment subsystem 216 that the opportunity was completed. A trigger can be sent to the opportunity verification subsystem 218 to request verification of fulfillment of the opportunity from the owning non-profit entity 155 (e.g., via the non-profit sub-portal 150). In response thereto, the non-profit entity 155 can be informed of the verification request, and the non-profit entity 155 can respond with an indication of whether the fulfillment is verified. Alternatively, the opportunity can be created and stored in association with particular completion criteria that can be automatically monitored for automatic verification of fulfillment. For example, fulfillment of the opportunity may be automatically verified by monitoring the location of the volunteer's 145 mobile device (e.g., using global positioning satellite (GPS) data, geo-fencing, etc.) during a time window, and for at least a minimum duration, associated with the opportunity. As described above, fulfillment of the opportunity can be pre-associated with a value in CLCUs 180. For example, the opportunity may be worth some number of CLCUs 180 per hour, a total number of CLCUs 180 upon completion of a particular task, or some number of CLCUs 180 per some relevant increment associated with the opportunity (e.g., per potential donor contacted, per box filled with sorted donations, etc.). The CLCUs 180 received from verified fulfillment of the opportunity can be stored in the volunteer data store 240 for that volunteer 145 (e.g., an indication of a number of CLCUs 180 that the volunteer 145 has can be updated in any suitable manner).

[0055] FIG. 21A shows an example screenshot 2100a of a portion of an illustrative non-profit sub- portal 150 through which non-profit entities 155 can verify fulfillment of an opportunity by a volunteer 145. For example, the illustrated verification includes the non-profit entity 155 verifying that a particular volunteer 145 worked four hours in engagement with a particular opportunity. FIG. 21B shows an example screenshot 2100b that indicates a present CLCU 180 count of a volunteer 145 displayed via an illustrative volunteer sub-portal 140. The CLCUs 180 are indicated in the illustrative portal as "points earned." The CLCUs 180 were earned at a rate of 20 per hour, so that the volunteer 145 is shown as having 80 CLCUs 180 earned for four hours of engagement with two opportunities.

[0056] Returning to FIG. 2, embodiments can enable use of CLCUs 180 acquired by the volunteers 145 from fulfilling opportunities (e.g., via the volunteer sub-portal 140). As illustrated, some embodiments include a donation subsystem 142 that enables volunteers 145 to donate their CLCUs 180 to a non-profit entity 155 (the non-profit entities 155 that created the opportunity for which the CLCUs 180 were earned, or any other non-profit entity 155 having an account in the closed loop system). For example, a specified number of CLCUs 180 is transferred from the volunteer data store 240 to the designated non-profit data store 250 (e.g., a CLCU 180 count associated with the volunteer 145 is decremented, and a CLCU 180 count associated with the recipient non-profit entity 155 is incremented). FIG. 22 shows example screenshots 2200a and 2200b of a volunteer 145 donation of CLCUs 180 to a non-profit entity 155 from the volunteer's 145 perspective (via an illustrative volunteer sub-portal 140). For example, screenshot 2200a indicates a current CLCU balance for a particular volunteer 145 with a prompt for a donation amount, and screenshot 2200b shows an indication of a completed CLCU donation from a volunteer 145 to a selected non-profit entity 155.

[0057] Returning to FIG. 2, some embodiments can include a redemption subsystem 144 that permits volunteers 145 (e.g., via the volunteer sub-portal 140) to redeem CLCUs 180 for incentives, as described more fully below. Typically, incentives are redeemed from for-profit entities 165; but some embodiments permit incentives to be redeemed from non-profit entities 155, as well. In some embodiments, the donation subsystem 142 and/or the redemption subsystem 144 can be implemented as part of the opportunity arbitration system 110. In other embodiments, the donation subsystem 142 and/or the redemption subsystem 144 can be implemented as part of the incentive arbitration system 120 or the request arbitration system 130. Embodiments and examples of the redemption subsystem 144 are described more fully with reference to the incentive arbitration system 120 below.

[0058] FIG. 3 shows an illustrative request-for-donation (RFD) arbitration environment 300, according to various embodiments. The RFD arbitration environment 300 includes an embodiment of the request arbitration system 130. The request arbitration system 130 can include an RFD data store 310, an RFD creation subsystem 312, and an RFD auto-fulfillment subsystem 314. The request arbitration system 130 provides an interface for arbitrating donation transactions between nonprofit entities 155 and for-profit entities 165. As described above, each non-profit entity 155 can interact with the request arbitration system 130 via the non-profit sub-portal 150, and each for- profit entity 165 can interact with the request arbitration system 130 via the for-profit sub-portal 160. As described above, profile information for each non-profit entity 155 and for each for-profit entity 165 can be stored in non-profit data stores 250 and for-profit data stores 360, respectively.

[0059] As illustrated, for-profit entities 165 can interface, via the for-profit sub-portal 160, with the RFD creation subsystem 312 to create RFD thresholds. For example, a for-profit entity 165 can desire to make tax-deductible donations totaling up to a threshold amount of $1,000 per month. The donations can be issued in cash, in gift card value, or in other suitable ways. That information can be defined and stored in the RFD data store 310 as a RFD with the associated RFD threshold and/or any other relevant information. Some implementations permit restrictions to be placed on the RFD. For example, the for-profit entity 165 can indicate a total RFD threshold of some amount per month and can further indicate that no single non-profit entity 155 can request more than 25 percent of the RFD threshold amount each month. Similarly, the for-profit entity 165 can permit requests only from certain categories of non-profit entity 155, such as only local non-profit entities 155, only non-profit entities 155 engaged in a certain type of mission, etc.

[0060] The stored RFDs in the RFD data store 310 can be viewed by non-profit entities 155 via the non-profit sub-portal 150. As illustrated, embodiments of the RFD auto-fulfillment subsystem 314 can provide non-profit entities 155 with access to the stored RFDs. In some cases, the displayed RFDs can be automatically selected, filtered, sorted, etc. with respect to relevant parameters, such as according to a non-profit entity's 155 profile preferences, for-profit entities 165 with which the non-profit entity 155 has previously engaged, RFDs having a remaining balance, etc. According to some embodiments, when the non-profit entities 155 select a listed RFD (e.g., assuming the request is for no more than the remaining RFD amount), the request is automatically approved, the CLCU 180 count for the non-profit entity 155 is automatically decremented, and the remaining RFD amount is automatically decremented. Effectively, CLCUs 180 are transferred from the non-profit entities 155 to the for-profit entities 165 (or simply decremented from the non-profit entities 155, in some implementations), and donations 320 (e.g., in cash, gift cards, etc.) can then be paid from the for-profit entities 165 to the requesting non-profit entities 155 in fulfillment of the RFD.

[0061] For example, a for-profit entity 165 called "Superstore" uses the RFD creation subsystem 312 to define an RFD with a threshold of 500 CLCUs 180 worth of donations 320 (e.g., $500 dollars, or whatever is the accepted conversion rate) per month. This month, 90 of the 500 CLCUs worth remains to be donated. A non-profit entity 155 called "Givers" uses the RFD auto-fulfillment subsystem 314 to request 40 CLCUs worth of donation from "Superstore." Embodiments of the RFD auto-fulfillment subsystem 314 can send the request to "Superstore," automatically deduct 40 from the RFD balance (leaving 50 CLCUs worth remaining), and automatically reduce the CLCU 180 count for "Givers" (e.g., stored in their non-profit data store 250 by 40 CLCUs 180. In some embodiments, "Superstore" is notified via their for-profit sub-portal 160 that the request is now pending fulfillment, so that "Superstore" can send cash, a gift card, or other suitable payment to "Giver" to complete the transaction. For example, even though the request is automatically approved, and the deductions automatically occur in CLCUs 180, the actual payment of the donation 320 may be an additional (e.g., manual, or otherwise non-automatic) step. In other embodiments, the non-profit entities 155 and/or for-profit entities 165 can provide payment account information as part of their profile data, as part of the RFD creation and/or request, etc.; so that payment of the donation 320 can also be automatically fulfilled by the RFD auto-fulfillment subsystem 314. For example, the for- profit entities 165 and/or non-profit entities 155 can provide wire transfer information, withdrawal and/or deposit account information, a virtual gift card identifier, and/or any other information usable to automatically complete the donation transaction.

[0062] FIG. 23 shows an example screenshot 2300 of a portion of an illustrative non-profit sub- portal 150 showing donation offers (RFDs) created by for-profit entities 165. Each can be selected to request the offered donation. In some implementations, non-profit entities 155 can select the offers (or other sub-portal controls) to find more details about the offers, about the for-profit entities 165, etc. FIG. 24 shows example screenshots 2400a and 2400b of a portion of an illustrative for-profit sub-portal 160 showing donation requests from non-profit entities 155 in response to the donation offers (RFDs) created by a for-profit entity 165. For example, screenshot 2400a indicates that the for-profit entity 165 set an RFD threshold of 100 points (e.g., 100 CLCUs 180) and zero has been spent to date that month. The screenshot 2400a also indicates a number of requests for that remaining RFD balance, some pending and others paid. Screenshot 2400b shows details of one of the requests received from a non-profit entity 155. As described above, the "pending" status can indicate that, though automatically approved and accounted for in CLCUs 180 (e.g., in available balance, etc.), the actual donation 320 (e.g., the cash, gift card balance, etc.) has not yet been paid to the requesting non-profit entity 155.

[0063] FIG. 4 shows an illustrative incentive arbitration environment 400, according to various embodiments. The incentive arbitration environment 400 includes an embodiment of the incentive arbitration system 120. The incentive arbitration system 120 can include an incentive data store 410, an incentive creation subsystem 412, and an incentive auto-fulfillment subsystem 414. The incentive arbitration system 120 provides an interface for arbitrating donation transactions between for-profit entities 165 and volunteers 145. As described above, each for-profit entity 165 can interact with the incentive arbitration system 120 via the for-profit sub-portal 160, and each volunteer 145 can interact with the incentive arbitration system 120 via the volunteer sub-portal 140. As described above, profile information for each volunteer 145 and for each for-profit entity 165 can be stored in volunteer data stores 240 and for-profit data stores 360, respectively.

[0064] As illustrated, for-profit entities 165 can interface, via the for-profit sub-portal 160, with the incentive creation subsystem 412 to create incentives 420. A for-profit entity 165 can desire to offer certain types of incentives 420 to volunteers 145 to encourage their engagement with volunteer opportunities, and those incentives 420 can be obtained by volunteers 145 in exchange for CLCUs 180. Certain legal or other restrictions may be placed on the types of incentives that can be offered by a for-profit entity 165 in exchange for encouraging engagement with non-profit entities 155. For example, for-profit entities 165 may not be allowed directly to provide goods or services to volunteers, but they may be able to provide discounts, deals, coupons, access privileges, etc. The incentives 420 can be created by the for-profit entities 165 to include any suitable information, such as description, value (e.g., cost of the incentive 420 in CLCUs 180), usage restrictions (e.g., limited duration, limited geography, certain days and/or times, etc.), codes (e.g., alphanumeric identifiers, barcodes, etc.), and/or any other desired information.

[0065] The stored incentives 420 in the incentive data store 410 can be viewed by volunteers 145 via the volunteer sub-portal 140. As illustrated, embodiments of the incentive auto-fulfillment subsystem 414 can provide volunteers 145 with access to the stored incentives 420. In some cases, the displayed incentives 420 can be automatically selected, filtered, sorted, etc. with respect to relevant parameters, such as according to a volunteer's 145 profile preferences, for-profit entities 165 with which the volunteer 145 has previously engaged or is affiliated (e.g., as an employee), incentive 420 details (e.g., duration, geography, keywords, etc.), etc. According to some embodiments, when the volunteers 145 select a listed incentives 420 (e.g., assuming the request is for a valid incentive 420), the request is automatically approved, the CLCU 180 count for volunteer 145 is automatically decremented, and an indication is provided to the volunteer 145 regarding access to the incentive 420. Effectively, CLCUs 180 are transferred from the volunteers 145 to the for-profit entities 165 (or simply decremented from the non-profit entities 155, in some implementations), and incentives 420 can then be issued from the for-profit entities 165 to the requesting volunteers 145 in exchange for the CLCUs 180. Similar to donations 320 described with reference to FIG. 3, some embodiments of the incentive auto-fulfillment subsystem 414 automatically provide volunteers 145 with access to their acquired incentives 420. For example, various implementations can automatically provide both notification of, and access to, acquired incentives 420 via the volunteer sub-portal 140, by email, by SMS, etc. In other embodiments, the incentive auto-fulfillment subsystem 414 can automatically inform the volunteer 145 of the acquired incentives 420, and a corresponding incentive 420 request can be indicated to the for-profit entity 165 that owns the incentive 420; and the for-profit entity 165 may have to take additional steps (e.g., confirmation, manual sending or other issuance, etc.) to finalize the incentive transaction.

[0066] FIG. 25 shows example screenshots 2500a and 2500b of a portion of an illustrative for-profit sub-portal 160 for creating (e.g., defining, editing, etc.) incentive records, and example screenshot 2500c providing search and display of a for-profit entity's 165 created incentives via a portion of the illustrative for-profit sub-portal 160. As illustrated, incentive records can be defined to include any suitable information, such as title, description, summary, exchange value, barcode, restrictions, etc. FIG. 26 shows example screenshots 2600a, 2600b, and 2600c of a portion of an illustrative for-profit sub-portal 160 showing incentives obtained (e.g., purchased) by volunteers 145 that are valid, already redeemed, and expired, respectively. FIG. 27 shows an example screenshot 2700 of a portion of an illustrative volunteer sub-portal 140 showing incentives obtained (e.g., purchased) by an associated volunteer 145. Controls permit the volunteer 145 to download the incentive, send it by email, view its details, see incentives of particular status (e.g., valid, redeemed, expired, etc.), etc.

[0067] Some embodiments enable for-profit entities 165 (and/or non-profit entities 155, in some implementations) to issue particular incentives to their employees (e.g., used generally to refer to their registered affiliates, which can include employees, partners, members, agents, etc.). Further, some embodiments can credit for-profit entities 165 and/or non-profit entities 155 with the transactional achievements of their registered employees. For example, embodiments can indicate a total number of volunteer hours attributed to a particular for-profit entity 165 by accumulating the verified hours worked in relation to non-profit entity 155 opportunities by all volunteers 145 that are registered employees of the for-profit entity 165. To support such employee-related features, some embodiments provide employee management systems that can be accessed via the non-profit sub- portal 150 and/or the for-profit sub-portal 160. For example, FIG. 28 shows an example screenshot 2800 of an illustrative portions of a non-profit sub-portal 150 or for-profit sub-portal 160 for managing employees. As illustrated, controls can be provided to search for employees, add employee records, send out invitations to employees (e.g., to volunteers 145 registered in the system), upload lists of employees (e.g., as a spreadsheet, character-delimited text file, or in any other suitable manner), indicate access privileges for employees (e.g., setting an employee as a manager to allow them access to the full capabilities of the for-profit sub-portal 160 or the nonprofit sub-portal 150), etc.

[0068] As described above, the CLCUs 180 enable donation transactions to be arbitrated in the novel, closed-loop arbitration environments described herein. Non-profit entities 155 create opportunities, and volunteers 145 engage in those opportunities in exchange for CLCUs 180 using the opportunity arbitration system 110. The CLCUs 180 can be donated back to the non-profit entities 155, and the non-profit entities 155 can exchange those donated CLCUs 180 for automatically approved cash (or cash-equivalent) donations 320 from for-profit entities 165 using the request arbitration system 130. By using the request arbitration system 130 and the CLCUs 180 to request and fulfill donations, non-profit entities 155 can identify for-profit entities 165 desiring to donate, and can receive donations from those entities, without spending their operational resources developing and maintaining those transactions and relationships. Similarly, by using the request arbitration system 130, for-profit entities 165 can provide tax-qualifying charitable donations 320 to non-profit entities 155 that need them (even large numbers of non-profit entities 155, small nonprofit entities 155 otherwise unknown to them, non-profit entities 155 lacking sophisticated donation infrastructures, etc.) without having to find, vet, and/or create individual relationships with those non-profit entities 155. By using the incentive arbitration system 120, for-profit entities 165 (and non-profit entities 155, in some cases) can incentivize volunteers 145 (e.g., including employees and/or others) to engage with non-profit entities 155 in a manner that enables tracking of those engagements, encourage further engagements between the non-profit entities 155 and volunteers 145, and other features.

[0069] The various systems described above in FIGS. 1 - 4 can be implemented in various ways, including in hardware and/or software, each in a single device, or with functions spread among multiple devices, components, systems, etc. Some implementations can include one or more Application Specific Integrated Circuits (ASICs) adapted to perform a subset of the applicable functions in hardware. Other implementations can have functions performed by one or more other processing units (or cores), on one or more integrated circuits (ICs). In other embodiments, other types of integrated circuits can be used (e.g., Structured/Platform ASICs, Field Programmable Gate Arrays (FPGAs), and other Semi-Custom ICs), which can be programmed. Each can also be implemented, in whole or in part, with instructions embodied in a computer-readable medium, formatted to be executed by one or more general or application specific controllers.

[0070] FIG. 5 shows an illustrative computational system 500 for implementing certain functionality of a design optimization system, according to various embodiments. The computational system 500 can include or perform functionality of components of the arbitration environment of FIG. 1, such as those described above. For the sake of simplicity, the computational system 500 is shown including hardware elements that can be electrically coupled via a bus 555. However, embodiments of the computational system 500 can be implemented as or embodied in single or distributed computer systems, in one or more locations, or in any other useful way.

[0071] The hardware elements can include a set of (e.g., one or more) central processing units (CPUs) 505, one or more input devices 510 (e.g., a mouse, a keyboard, etc.), and one or more output devices 515 (e.g., a display device, a printer, etc.). The computational system 500 can also include one or more storage devices 520. By way of example, storage device(s) 520 can be disk drives, optical storage devices, solid-state storage device such as a random access memory (RAM) and/or a read-only memory (ROM), which can be programmable, flash-updateable and/or the like. In some embodiments, the storage devices 520 can include, or be in communication with, the volunteer data stores 240, non-profit data stores 250, and for-profit data stores 360. The storage devices 520 can also include, or be in communication with, the opportunity data store 210, the RFD data store 310, the incentive data store 410, and/or any other suitable data, for example, as described above.

[0072] The computational system 500 can additionally include a computer-readable storage media reader 525a, a communications system 530 (e.g., a modem, a network card (wireless or wired), an infra-red communication device, etc.), and working memory 540, which can include RAM and ROM devices as described above. In some embodiments, the computational system 500 can also include a processing acceleration unit 535, which can include a DSP, a special-purpose processor and/or the like. The computer-readable storage media reader 525a can further be connected to a computer- readable storage medium 525b, together (and, optionally, in combination with storage device(s) 520) comprehensively representing remote, local, fixed, and/or removable storage devices plus storage media for temporarily and/or more permanently containing computer-readable information. The communications system 530 can permit data to be exchanged with a network and/or any other computer described above with respect to the computational system 500. For example, as described with reference to FIGS. 1 - 4, volunteers 145, non-profit entities 155, and/or for-profit entities 165 can communicate, via one or more networks 170, with the computational system 500.

[0073] The computational system 500 can also include software elements, shown as being currently located within a working memory 540, including an operating system 545 and/or other code 550, such as an application program (which can be a client application, web browser, mid-tier application, relational database management system (RDBMS), etc.). In some embodiments, one or more functions of the arbitration portal 105 can be implemented as application code 550 in working memory 540. For example, working memory 540 (or any other suitable non-transient memory) can store instructions, which, when executed, can cause the set of processors 505 to perform functions of the opportunity arbitration system 110, the incentive arbitration system 120, the request arbitration system 130, the volunteer sub-portal 140, the non-profit sub-portal 150, and the for- profit sub-portal 160.

[0074] It will be appreciated that the arbitration systems shown in FIGS. 1 - 5 illustrate only some of many implementations of such systems for providing the functionality described herein. Further, the embodiments described above and/or other embodiments can be used to provide various types of functionality, including functionality of the methods described below. The method embodiments described below can also be performed using system embodiments other than those described above.

[0075] FIG. 6 shows a flow diagram of a method 600 for arbitration of donation transactions in a closed-loop network, according to various embodiments. Embodiments can begin at stage 610 by receiving (e.g., over a communications network via a volunteer sub-portal) an opportunity fulfillment trigger indicating completion by one of a number of volunteer users of fulfillment criteria associated with a selected one of a plurality of stored opportunity records created by a plurality of non-profit entity (N PE) users. At stage 620, embodiments can add closed-loop currency unit (CLCU) value to a stored account of the one of the volunteer users in response to the opportunity fulfillment trigger, the added CLCU value corresponding to a fulfillment value defined by the selected stored opportunity record. In some embodiments, prior to stage 610 (at stage 615), embodiments can receive, via the N PE sub-portal for each of the plurality of opportunity records, an opportunity record definition indicating the respective associated fulfillment criteria and the respective associated fulfillment value in CLCUs for the opportunity record, and embodiments can store the opportunity records in an opportunity data store according to the respective received opportunity record definitions. In some embodiments, the volunteer users only receive CLCUs after fulfillment of the opportunity is verified by the N PE user that created (or otherwise owns) the fulfilled opportunity. For example, embodiments can further include receiving, via the NPE sub-portal, a verification trigger indicating verification of the received opportunity fulfillment trigger by one of the NPE users that created the selected stored opportunity record, wherein the CLCU value is added to the stored account of the one of the volunteer users only when the verification trigger indicates verification of the received opportunity fulfillment trigger.

[0076] At stage 630, embodiments can receive (e.g., over the communications network from a requesting one of the N PE users via a N PE sub-portal) a donation request indicating a donation value corresponding to one of a plurality of stored request-for-donation (RFD) records created by a number of for-profit entity (FPE) users. At stage 640, automatically in response to the donation request, embodiments can reduce CLCU value from a stored account of the requesting NPE user and adding cash-equivalent value to the stored account of the requesting N PE user. In some embodiments, prior to stage 630 (at stage 635), embodiments can receive, via a FPE sub-portal for each of the plurality of RFD records, an RFD record definition indicating the respective associated donor FPE and the respective associated RFD threshold for the RFD record, and embodiments can store the RFD records in an RFD data store according to the respective received RFD record definitions. In some embodiments, the CLCUs exchanged by the N PEs for donation value are received by the N PEs from volunteer users as CLCU donations (e.g., after the volunteer users have obtained CLCUs from engaging in opportunities). For example, some embodiments can further include receiving a CLCU transfer request from a requesting one of the plurality of volunteer users via the volunteer sub-portal, the CLCU transfer request indicating a CLCU donation value and a recipient one of the plurality of N PE users; and transferring the CLCU donation value from a stored account of the requesting volunteer user to a stored account of the recipient N PE user in response to, and in accordance with, the CLCU transfer request.

[0077] Some embodiments can continue at stage 650 by receiving (e.g., over the communications network from a requesting one of the volunteer users via the volunteer sub-portal) an incentive request indicating a selected one of a plurality of stored incentive records created by a number of for-profit entity (FPE) users, each incentive record defining an associated incentive offered by a provider FPE and an associated exchange value in CLCUs. In such embodiments, at stage 660, automatically in response to the incentive request, CLCU value can be reduced from a stored account of the requesting volunteer user in accordance with the exchange value associated with the selected incentive record, and access by the requesting volunteer user can be authorized to the incentive associated with the selected incentive record. In some embodiments, prior to stage 650 (at stage 655), embodiments can receive, via a FPE sub-portal for each of the plurality of incentive records, an incentive record definition indicating the respective associated incentive and the respective associated exchange value in CLCUs, and embodiments can store the incentive records in an incentive data store according to the respective received incentive record definitions.

[0078] The steps of a method or algorithm or other functionality described in connection with the present disclosure, may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module may reside in any form of tangible storage medium. Some examples of storage media that may be used include random access memory (RAM), read only memory (ROM), flash memory, EPROM memory, EEPROM memory, registers, a hard disk, a removable disk, a CD-ROM and so forth. A storage medium may be coupled to a processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. A software module may be a single instruction, or many instructions, and may be distributed over several different code segments, among different programs, and across multiple storage media. Thus, a computer program product may perform operations presented herein. For example, such a computer program product may be a computer readable tangible medium having instructions tangibly stored (and/or encoded) thereon, the instructions being executable by one or more processors to perform the operations described herein. The computer program product may include packaging material. Software or instructions may also be transmitted over a transmission medium. For example, software may be transmitted from a website, server, or other remote source using a transmission medium such as a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technology such as infrared, radio, or microwave.

[0079] Other examples and implementations are within the scope and spirit of the disclosure and appended claims. For example, features implementing functions may also be physically located at various positions, including being distributed such that portions of functions are implemented at different physical locations. Also, as used herein, including in the claims, "or" as used in a list of items prefaced by "at least one of" indicates a disjunctive list such that, for example, a list of "at least one of A, B, or C" means A or B or C or AB or AC or BC or ABC (i.e., A and B and C). Further, the term "exemplary" does not mean that the described example is preferred or better than other examples.

[0080] Various changes, substitutions, and alterations to the techniques described herein can be made without departing from the technology of the teachings as defined by the appended claims. Moreover, the scope of the disclosure and claims is not limited to the particular aspects of the process, machine, manufacture, composition of matter, means, methods, and actions described above. Processes, machines, manufacture, compositions of matter, means, methods, or actions, presently existing or later to be developed, that perform substantially the same function or achieve substantially the same result as the corresponding aspects described herein may be utilized.

Accordingly, the appended claims include within their scope such processes, machines, manufacture, compositions of matter, means, methods, or actions.

Claims

WHAT IS CLAI MED IS:

1. A system for arbitration of donation transactions in a closed-loop network, the system comprising:

a communications network portal having a volunteer sub-portal, a non-profit entity (N PE) sub-portal, and a for-profit entity FPE sub-portal;

an opportunity arbitration subsystem comprising an opportunity data store having stored thereon a plurality of opportunity records, each opportunity record defined via the N PE sub-portal to have associated fulfillment criteria and an associated fulfillment value in closed-loop currency units (CLCUs), the opportunity records accessible for fulfillment by volunteer users via the volunteer sub-portal, fulfillment of each opportunity record comprising transfer of the fulfillment value associated with the opportunity record to one of the volunteer users in exchange for fulfillment by the volunteer user of the fulfillment criteria associated with the opportunity record; and

a request-for-donation (RFD) arbitration subsystem comprising an RFD data store having stored thereon a plurality of RFD records, each RFD record defined via the FPE sub-portal to have an associated donor FPE and an associated RFD threshold, the RFD records accessible for fulfillment by NPE users via the N PE sub-portal, fulfillment of each RFD record comprising transfer of a donation value to a requesting N PE user in exchange for transfer of a corresponding value of CLCUs from the requesting N PE user to the donor FPE associated with the RFD record.

2. The system of claim 1, wherein the opportunity arbitration subsystem further comprises an opportunity fulfillment subsystem having:

an opportunity verification input; and

an opportunity fulfillment output,

wherein, in response to the verification input indicating verified fulfillment of the fulfillment criteria associated with one of the opportunity records selected by one of the volunteer users, the opportunity fulfillment output indicates a transfer of the fulfillment value associated with the selected opportunity record to a stored account of the one of the volunteer users.

3. The system of claim 1, wherein the opportunity arbitration subsystem further comprises an opportunity creation subsystem having:

an opportunity creation input coupled with the N PE sub-portal; and

an opportunity creation output coupled with the opportunity data store, wherein the opportunity creation output comprises an opportunity record in response to receiving an opportunity record definition at the opportunity creation input, the opportunity record definition comprising the associated fulfillment criteria and the associated fulfillment value in CLCUs.

4. The system of claim 1, wherein the RFD arbitration subsystem further comprises an RFD fulfillment subsystem having:

an RFD verification input; and

an RFD fulfillment output,

wherein, in response to detecting a transfer of a CLCU value from a stored account of one of the N PE users to the donor FPE associated with one of the RFD records selected by the one of the NPE users, the RFD fulfillment output automatically indicates a transfer of a donation value from the associated FPE donor to the stored account of the one of the N PE users in accordance with the selected RFD record and with the transferred CLCU value.

5. The system of claim 1, wherein the RFD arbitration subsystem further comprises an RFD creation subsystem having:

an RFD creation input coupled with the FPE sub-portal; and

an RFD creation output coupled with the RFD data store,

wherein the RFD creation output comprises an RFD record in response to receiving an RFD record definition at the RFD creation input, the RFD record definition comprising the associated donor FPE and an associated RFD threshold.

6. The system of claim 1, further comprising:

an incentive arbitration system comprising an incentive data store having stored thereon a plurality of incentive records, each incentive record defined via the FPE sub-portal to have an associated incentive offered by a provider FPE and an associated exchange value in CLCUs, the incentive records accessible for fulfillment by the volunteer users via the volunteer sub-portal, fulfillment of each incentive record comprising authorizing access by the requesting volunteer user to the incentive associated with the incentive record in exchange for transfer of the exchange value associated with the incentive record from the requesting volunteer user to the provider FPE associated with the incentive record.

7. The system of claim 6, wherein the incentive subsystem further comprises an incentive fulfillment subsystem having:

an incentive verification input; and an incentive fulfillment output,

wherein, in response to detecting a transfer of the exchange value associated with one of the incentive records selected by the volunteer user from the stored account of the volunteer user to the provider FPE associated with the selected incentive record, the incentive fulfillment output automatically indicates authorization in the stored account of the volunteer user to access the incentive associated with the selected incentive record.

8. The system of claim 1, further comprising:

a CLCU donation system coupled with a plurality of stored accounts associated with volunteer users and N PE users, and having a transfer request input,

wherein a CLCU value is transferred from a first stored account to a second stored account in response to receiving a transfer request from one of the volunteer users, the requesting volunteer user associated with the first stored account, the transfer request indicating the CLCU value and the NPE user associated with the second account.

9. A method for arbitration of donation transactions in a closed-loop network, the method comprising:

receiving, over a communications network via a volunteer sub-portal, an opportunity fulfillment trigger indicating completion by one of a plurality of volunteer users of fulfillment criteria associated with a selected one of a plurality of stored opportunity records created by a plurality of non-profit entity (N PE) users;

adding closed-loop currency unit (CLCU) value to a stored account of the one of the volunteer users in response to the opportunity fulfillment trigger, the added CLCU value corresponding to a fulfillment value defined by the selected stored opportunity record;

receiving, over the communications network from a requesting one of the plurality of N PE users via a N PE sub-portal, a donation request indicating a donation value corresponding to one of a plurality of stored request-for-donation (RFD) records created by a plurality of for-profit entity (FPE) users; and

automatically in response to the donation request, reducing CLCU value from a stored account of the requesting NPE user and adding cash-equivalent value to the stored account of the requesting N PE user.

10. The method of claim 9, further comprising: receiving, via the NPE sub-portal for each of the plurality of opportunity records, an opportunity record definition indicating the respective associated fulfillment criteria and the respective associated fulfillment value in CLCUs for the opportunity record; and

storing the opportunity records in an opportunity data store according to the respective received opportunity record definitions.

11. The method of claim 9, further comprising:

receiving, via a FPE sub-portal for each of the plurality of RFD records, an RFD record definition indicating the respective associated donor FPE and the respective associated RFD threshold for the RFD record; and

storing the RFD records in an RFD data store according to the respective received RFD record definitions.

12. The method of claim 9, further comprising:

receiving a CLCU transfer request from a requesting one of the plurality of volunteer users via the volunteer sub-portal, the CLCU transfer request indicating a CLCU donation value and a recipient one of the plurality of N PE users; and

transferring the CLCU donation value from a stored account of the requesting volunteer user to a stored account of the recipient N PE user in response to, and in accordance with, the CLCU transfer request.

13. The method of claim 9, further comprising:

receiving, over the communications network from a requesting one of the plurality of volunteer users via the volunteer sub-portal, an incentive request indicating a selected one of a plurality of stored incentive records created by a plurality of for-profit entity (FPE) users, each incentive record defining an associated incentive offered by a provider FPE and an associated exchange value in CLCUs; and

automatically in response to the incentive request, reducing CLCU value from a stored account of the requesting volunteer user in accordance with the exchange value associated with the selected incentive record, and authorizing access by the requesting volunteer user to the incentive associated with the selected incentive record.

14. The method of claim 13, further comprising: receiving, via a FPE sub-portal for each of the plurality of incentive records, an incentive record definition indicating the respective associated incentive and the respective associated exchange value in CLCUs; and

storing the incentive records in an incentive data store according to the respective received incentive record definitions.

15. The method of claim 9, further comprising:

receiving, via the NPE sub-portal, a verification trigger indicating verification of the received opportunity fulfillment trigger by one of the NPE users that created the selected stored opportunity record,

wherein the CLCU value is added to the stored account of the one of the volunteer users only when the verification trigger indicates verification of the received opportunity fulfillment trigger.

16. A system for arbitration of donation transactions in a closed-loop network, the system comprising:

a set of processors; and

a non-transient memory system having instructions stored thereon, which, when executed, cause the set of processors to perform steps comprising:

receiving, over the communications network from a requesting one of the plurality of N PE users via a NPE sub-portal, a donation request indicating a donation value corresponding to one of a plurality of stored request-for-donation (RFD) records created by a plurality of for-profit entity (FPE) users; and

automatically in response to the donation request, reducing CLCU value from a stored account of the requesting N PE user and adding cash-equivalent value to the stored account of the requesting N PE user.

17. The system of claim 16, wherein the steps further comprise: receiving, over the communications network from a requesting one of the plurality of volunteer users via the volunteer sub-portal, an incentive request indicating a selected one of a plurality of stored incentive records created by a plurality of for-profit entity (FPE) users, each incentive record defining an associated incentive offered by a provider FPE and an associated exchange value in CLCUs; and

18. The system of claim 16, wherein:

the non-transient memory system comprises an opportunity data store and an RFD data store; and

the steps further comprise:

receiving, via the N PE sub-portal for each of the plurality of opportunity records, an opportunity record definition indicating the respective associated fulfillment criteria and the respective associated fulfillment value in CLCUs for the opportunity record;

storing the opportunity records in the opportunity data store according to the respective received opportunity record definitions;

storing the RFD records in the RFD data store according to the respective received RFD record definitions.

19. The system of claim 16, wherein the steps further comprise:

20. The system of claim 16, wherein the steps further comprise: receiving, via the NPE sub-portal, a verification trigger indicating verification of the received opportunity fulfillment trigger by one of the NPE users that created the selected stored opportunity record,

30