Patent Application
20080015980
In the following detailed description, reference is made to the accompanying drawings that form a part hereof, and in which is shown by way of illustration specific illustrative embodiments in which the invention may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention, and it is to be understood that other embodiments may be utilized and that various changes may be made without departing from the spirit and scope of the present invention. The following detailed description is, therefore, not to be taken in a limiting sense.
The following terms will be used throughout the detailed description. “Beneficiary Organization” or “Beneficiary” is defined as any legal non-profit organization, for-profit organization, government agency or enterprise, or an individual who will receive net proceeds as the result of one or more donations or gifts. “Donor” is defined as any individual, non-profit organization, for-profit organization, government agency or enterprise that is donating or gifting goods, services or cash to one or more Beneficiary Organizations. “Property” or “Donated Property” is defined as any item with commercial value including, but not limited to, personal property, real estate, trade services, consumer services, professional services, store credits and cash. “Member” or “Beneficiary Organization Member” is defined as the lowest level of recipient for donations (in many cases, an individual person), that is targeted for the receipt of specific donations. “Donation” or “Donate” is defined as the act of a Donor gifting property to benefit one or more Beneficiary Organizations and/or their Members.
“Donation System” or “System” is used to designate the disclosed system for managing donations, as described in more detail below. This Donation System can exist in a variety of business models including, but not limited to: 1) a web application service offered directly to Beneficiary Organizations and prospective Donors; 2) a web service extension supporting third party commerce and auction management system platforms; and/or 3) an added value consumer service offered by traditional retailers to their patrons.
“Third Party Services” are defined as services with which the Donation System integrates in order to implement business models including, but not limited to: 1) commerce and auction management systems; 2) merchant services; 3) shipping services; 4) research databases; 5) Beneficiary Organization websites and databases; 6) communication services and 7) syndication and marketing services.
A “Hierarchical Tree” is defined as a hierarchical mapping of a Beneficiary Organization showing the organizational structure of the Beneficiary Organization, detailing programs and recipients eligible for donations. This “Tree” may have an arbitrary number of “Branches” at each level within the tree.
“Hierarchical Tree Template” is defined as a template used by Beneficiary Organizations to facilitate easier mapping of campaigns, sub-campaigns and members into a donation database.
“Campaign” or “Account” is defined as a specific program, activity, project, need, or any grouping of these that a Beneficiary Organization creates to be eligible for targeted fundraising. A Campaign may be temporary, periodic (e.g., annual), or ongoing. “Sub-Campaign” or “Sub-Account” or “Program” is defined is a specific subset of a Campaign or a broader Sub-campaign with a narrower or more specific focus. “Drill-down” is defined as the act of moving deeper and more specifically through sub-campaigns and members within a “Hierarchical Tree” or actual Beneficiary Organization hierarchical tree. “Beneficiary ID” or “Beneficiary Code” is defined as the unique identifier associated with individual “Campaigns”, “Sub-campaigns”, and “Members” within a Beneficiary Organization in the Donation System. The Beneficiary ID may be created by any number of methods including, but not limited to, assigning unique numerical and/or character codes to campaigns, sub-campaigns and members.
The Donor 110 interacts directly with the Donation System 120. In some embodiments, it may appear to the Donor 110 that the Donor 110 is dealing directly with either the Selling Agent 130 or the Beneficiary Organization 150. The Donation Management System 120 interacts with the Selling Agent 130, the Marketplace 140, and the Beneficiary Organization 150. The Donation Management System 120 in some embodiments may also interact directly with the Buyer 160. The Selling Agent 130 interacts with the Donation Management System 120 and the Marketplace 140. In some embodiments, the Selling Agent 130 may also interact with the Beneficiary Organization 150.
The Marketplace 140 is where the donated property changes hands and may represent any combination of selling environments. In some embodiments, Marketplace 140 is an online marketplace, such as eBay™, Ubid™ and the like. It is understood that Marketplace 140 includes not only the auction platform (e.g. eBay™, Ubid™, etc.), but also includes any other marketplace management layers that may be utilized by sellers within the Marketplace 140, such as Infopia™ and Marketworks™. These marketplace management layers are utilized by many “power-sellers” within the online marketplace and are well known to those skilled in the art.
The Beneficiary Organization 150 primarily interfaces with the Donation Management System 120, but may also interact directly with the Selling Agent 130 in some embodiments. The Buyer 160 interacts with the Marketplace 140 when buying donated property. The Buyer 160 may also interact with the Donation Management System 120 in some more sophisticated embodiments, as will be discussed further. Interfaces between major components are shown in the diagrams as single interfaces for simplicity. In actual practice, there may be multiple interfaces between these components. For example, Beneficiary Interface 250 used to transfer funds from the Donation Management System 120 to the Beneficiary Organization's Merchant Account 380 and used for the Beneficiary Organization 150 to manage the Beneficiary Data Base 255, could in practice be different interfaces.
In the embodiment shown in
In operation, the Donor Interface 210 allows the Donor 110 to select one or more Beneficiaries from the Beneficiary Database 255. In some embodiments, the Donor Interface 210 is browser-based. The Donor Database 215 tracks the Donors 110 and associated donor information, allowing receipts and other information, such as thank you notes, to be provided to the Donors 110.
In the illustrated embodiment, System 120 includes an optional Rewards Database 220. The Rewards Database 215 keeps track of any rewards that may be offered to Donors 110. These rewards may be offered by the Beneficiary Organization 150 or by a Selling Agent 130 or by the Donation Management System 120 itself as a way to provide Donors 110 with incentive to give more. Examples of rewards include a coffee mug from the Beneficiary Organization 150 for any Donor 110 donating more than $100 worth of property and a tote bag for donations of property exceeding $1,000.
Donation System 120 of
The Selling Agent 130 represented in this simplified diagram may actually represent more than a single entity. For example, there may be a Selling Agent 130 that actually lists and sells the donated property, such as iSoldit™, and one or more additional Selling Agents 130 that provide a value-added service to enhance the value of the donated property. For example, a bike shop may provide safety and certification inspections for donated bicycles, or a guitar retailer may provide a Luthier certification for a donated guitar. By providing these added-value donation services to their customers, retailers, such as bike shops and music stores, will indirectly increase sales as a result of goodwill and loyalty.
The System 120 shown in
The System 120 of
The System 120 of
The System 120 of
The Beneficiary Organization 150 has a Beneficiary Organization Database 355, which contains data about Beneficiary Organization's Campaigns 356, Programs 357, and Members 358. This database 355 will normally be a superset of the Beneficiary Database 255 in the Donation Management System 120 with respect to the particular Beneficiary Organization 150. The Beneficiary Organization Database 355 may have entries for Campaigns 356, Programs 357 and individual Members 358.
At Block 415, the Donor 110 interacts with the Donation Management System 120 through the Donor Interface 210. In this example, the interface 210 comprises a browser based interface that is connected to the Donation Management System 120 via the Internet.
At Block 420, the Donor 110 is queried about being a registered user of the Donation Management System 120. If they are not, they are presented with a new user account login at Block 425. Part of this login process involves determining the account type for the user. In this example, the account type is for a Donor/Seller. Other account types may include Beneficiary Organization, Beneficiary Member, Agent/Power Seller, and Administrative account; other account types not listed could also be implemented. At Block 430 the Donor 110 logs onto their account. The user may update, edit or delete the information in their donor account.
At Block 435, the Donor 110 selects one or more beneficiaries from the Beneficiary Database 255 within the Donation Management System 120. In some embodiments, the Donor 110 may also select multiple beneficiaries and an order in which they receive funds from the donated property that are conditional, based on one or more customized rules created by the Donor 110. For example, a Donor 110 could select their grandson's hockey registration fees as a first recipient and the American Lung Association's Anti-Smoking Campaign as a second recipient. In this example, the proceeds from the donated property would first cover the hockey registration fees and then any additional funds beyond this fee would be donated to the American Lung Association™, specifically, their Anti-Smoking Campaign as a tax deductible charitable contribution.
This optional feature is useful in cases where a specific individual beneficiary account may have a maximum value, such as registration for a particular event or activity. In cases where the donated property exceeds this maximum value from either a single Donor's 110 contribution or from multiple Donors' 110 contributions, the excess proceeds need to be distributed. It is envisioned that excess proceeds may also be transferred back to the Donors 110 themselves. This could be accomplished by a payment back to the Donor 110 or by the Donor 110 actually having their own unique Beneficiary ID and receiving the proceeds into their own recipient account.
In this way, it can be seen that the proceeds from the sale of donated property might result in a distribution of funds that has a portion that is charitable and tax deductible, as well as a portion that is not tax deductible. The specific distribution of funds to various accounts is tracked within the Transaction Database 270, and the Donation Management System 120 uses this data to provide detailed receipts to the Donor 110.
At Block 440, the Donor 110 decides whether they will be using a Selling Agent 130 or selling the donated property themselves. If the Donor 110 is using a Selling Agent 130, then the flow goes to Block 445 where the Donor 110 gives possession, but not title, of the property to the Selling Agent 130. The Donor 110 will also agree to costs and fees associated with using the selling agent's services and what will happen to the donated property if it does not sell in Marketplace 140. In the event that the donated property does not sell, the Donor 110 may in some instances receive the donated property back and in some instances have the Selling Agent 130 dispose of the unsold property on their behalf, such as donating the property outright to another charitable organization, which accepts donated property. If the Donor 110 is not using a Selling Agent 130, the donated property is listed in the Marketplace 140 at Block 450.
At Block 455, the property sells to a Buyer 160 and the flow moves to Block 460. If a Selling Agent 130 was used, the flow moves to Block 465 where payment from the Buyer 160 is sent to the Selling Agent 130. At Block 465, the Selling Agent 130 collects any additional fees associated with the sale of the donated property. Flow then moves to Block 470, or if no Selling Agent 130 was used, flow moves from Block 460 to Block 470. Money from the sale of donated property goes to Donation System Merchant Account 280 from the Buyer 160. At Block 470, any applicable fees are collected by the Donation Management System 120.
At Block 475, money is transferred from the Donation System Merchant Account 280 to the specific Beneficiary Merchant Account 380. These accounts can include checking accounts, PayPal™ accounts, or any other type of account. In some embodiments, there will be a specific account for each targeted Beneficiary Organization Member 358; in other embodiments, the Beneficiary Organization 150 may not have a specific account for each individual Beneficiary Organization Member 358. In the latter case, the Donation Management System 120 would transfer the money to the general Beneficiary Merchant Account 380 with the associated information detailing the specific Beneficiary Organization Member 358 who is the intended recipient of this donation (if appropriate). The Beneficiary Organization 150 would then handle the internal accounting and distribution of funds to Beneficiary Organization Members 358.
At Block 480, the Donor 110 is provided with receipts detailing the donation for tax and accounting purposes. In some embodiments, the Donor 110 may receive one or more receipts for donated property based on assessed fair market value at the time of donation, but prior to final sale and disposition of the property. After the sale of the property, the System 120 may generate a new receipt based on the actual final sale value of the donated property. In some embodiments, this new receipt is generated and provided to the Donor 110 only if the selling price of the donated property differs from the estimated fair market value by more than a selected threshold amount (e.g., 15%, 10%, 5%, zero, etc.). Receipts may be provided by a number of different methods including, but not limited to, email, online user accounts, paper reports and any other suitable communication method.
The process ends at Block 485, where the Transaction Database 270 is updated. The actual flow may be different from the flow presented in
At Block 515, the Beneficiary Organization 150 interacts with the Donation Management System 120 through the Beneficiary Interface 250. In this example, the interface 250 is a browser based interface that is connected to the Donation Management System 120 via the Internet. This connection to the Donation Management System 120 may happen directly or indirectly. The Beneficiary Organization 150 might, in some implementations, arrive at the Beneficiary Interface 250 through an agent, such as Selling Agent 130. This could be accomplished through an affiliated website and might be branded as the Selling Agent's 130 service.
At Block 520, the Beneficiary Organization 150 is queried about being a registered user of the Donation Management System 120. If they are not, they are presented with a new user account login at Block 525. Part of this login process involves determining the account type for the user. In this example, the account type is for a Beneficiary Organization 150. Other account types may include Donor/Seller, Beneficiary Member, Selling Agent/Power Seller, and Administrative account; other account types not listed could also be implemented.
At Block 530, the Beneficiary Organization 150 logs onto their account. The Beneficiary Organization 150 may update, edit or delete the information in their Beneficiary Organization account information contained in the Beneficiary Database 255.
At Block 535, the Beneficiary Organization 150 either selects a pre-existing setup hierarchical tree template or creates a new tree template in order set up a specific campaign. These templates define a drill-down hierarchy, detailing the various levels at which donations may be targeted. Examples of templates will be discussed later in reference to
At Block 540, the Beneficiary Organization 150 populates the template with specific campaign attributes 356, program attributes 357, specific Beneficiary Member lists 358, associated Merchant Accounts 380 and any other relevant data. The campaigns entered may have any number of levels and associated Beneficiary Merchant Accounts 380. More detail about Beneficiary Organization levels will be discussed in reference to
The Beneficiary Organization 150 can add, modify and delete programs, campaigns, sub-campaigns and member accounts at any time. In some embodiments, the Beneficiary Organization 150 has the option to classify and tag a program, campaign, sub-campaign or target member account as private or public. If public, when the Donor 110 queries the database, the account search results are eligible for display to the Donor 110. If private, when the Donor 110 queries the database the target account may be filtered by the Beneficiary Organization 150 for display only to a subset of the public, or even outright blocking of display to the public, or to display only a subset of the information. For a member account, the member may have the ability to change account status to public or private, as well as deleting their account.
Block 545 is an optional block where the Donation Management System 120 or a third party can vet the proposed campaign before making it available for Donors 110 to access. This could be used to verify, for example, the tax exempt, non-profit status of Beneficiary Organization 150. Block 550 is an optional block related to Block 545. If the campaign is considered unacceptable for any reason, the Beneficiary Organization 150 may go back to Block 545 to make changes and resubmit the campaign for approval.
At Block 555, the Donation Management System Beneficiary Database 255 is updated with the new information and made available to Donors 110. At Block 560, a Donor 110 targets a donation of property to a Beneficiary Organization 150. In some cases, the Donor 110 can target the donation to specific Campaigns 356, Programs 357, and/or Members 358. A targeted Member 358 may be one of a plurality of recipient Members 358 for the proceeds from the sale of the property, and may also be a conditional recipient of the proceeds, as in the previously cited example involving a Donor's grandson and the American Lung Association™.
At Block 565, the property sells in the Marketplace 140. The property may have been sold directly by the Donor 110 or by a Selling Agent 130; in either case, the flow moves to Block 570 where the proceeds of the sale are transferred to the Donation Management System Merchant Account 280. In the case where the Donor 110 is the seller, the money may come directly from the Buyer 160 to the Donation Management System Merchant Account 280. In the case where there is a Selling Agent 130, the net proceeds, less the selling agent fees will be deposited into the Donation Management System Merchant Account 280. After collecting any costs/fees the money is transferred to the appropriate Beneficiary Merchant Account 380 at Block 575.
Although this example shows all funds going through the Donation Management System Merchant Account 280 before being transferred to the Beneficiary Organization Merchant Account 380, there are other possible configurations. For example, funds from either the Buyer 160 or the Selling Agent 130 may be deposited directly into Beneficiary Organization Merchant Accounts 380, with optional fees later remitted to the Donation Management System Merchant Account 280 by the Beneficiary Organization 150. It is understood that the Donation Management System 120 may apply different optional rates/fees for different types of donations. For example, the fee applied to cash donations may be different than those applied for donated non-cash property.
At Block 580, receipts are provided to the Donor 110 and to the Beneficiary Organization 150 giving the details of the transaction. The flow ends at Block 585, when the Transaction Database 270 is updated. The actual flow may be different from the flow presented here, with additional steps, steps happening in a different order or steps being executed concurrently. For example, the Transaction Database 270 may be updated in a number of places throughout the process.
At Block 625, at the point where the Buyer 160 is in the checkout phase of the purchase, they are presented with an offer to donate. There are a number of ways to initiate this offer. In one embodiment, the Buyer 160 is, at the time of checkout, presented with a message stating that the proceeds from this auction are going to benefit a specific Beneficiary Organization 150 and presented with an offer to make a charitable contribution to that same Beneficiary Organization 150 or to a specific Beneficiary Organization Member 358. In cases where the donation is tax deductible, the Donor 110 would be notified of this and presented with information about receiving receipts for the donation.
If the Buyer 160 does not wish to support the Beneficiary Organization 150 that was already benefiting from the sale of the donated property just purchased by them, they could be presented with the entire Beneficiary Database 255 to select a different Beneficiary Organization 150 or specific Beneficiary Organization Member 358 to which to target a donation. It is also possible to present the option to donate to the specific Beneficiary Organization 150 benefiting from the sale or other Beneficiary Organizations 150 to all “potential purchasers” of the donated property. For example, in an auction context, potential purchasers could include any individuals who bid on the donated property, but did not win the bid. In other settings, potential purchasers could include any individuals who learn that the donated property is for sale, for example, by seeing the property displayed on a shelf at a physical store, by reviewing an advertisement about the property, etc. In this way, the potential donor pool is greatly increased for all Beneficiary Organizations 150 that are in the Beneficiary Database 255 in the Donation Management System 120.
At Block 630, the Buyer 160 decides whether or not they wish to make a donation to the specific Beneficiary Organization 150 or any other Beneficiary Organization 150. If the Buyer 160 does decide to make a donation, flow moves to Block 635. Also, in some implementations a Buyer 160, who did not make the winning bid may also decide to donate and would enter the flow at Block 630.
At Block 635, the Buyer 160 decides whether to donate to the same Beneficiary Organization 150 that is benefiting from the donated property sale. As discussed above, this beneficiary may be an organization 150, a specific Campaign/Sub-campaign 356/357 by that organization or even a specific Member 358 of a Beneficiary Organization 150. If the Buyer 160 decides to select a different recipient, the flow moves to Block 640 where the Buyer 160 is presented with other Beneficiary Organizations 150 in the Beneficiary Database 255 through Buyer Interface 260.
After selecting a Beneficiary Organization 150, either the original or a different beneficiary, the flow moves to Block 645 where the donation is made. This donation could be made in a number of ways, for example, by making a payment to the Donation Management System Merchant Account 280 targeted to the specific beneficiary. This payment might be a PayPal™ transaction. After the donation is made, flow continues to Block 650. If at Block 630, the Buyer 160 chooses not to make a donation, the flow moves directly from Block 630 to Block 650.
At Block 650, the money from the purchase of the donated property is transferred to the Donation Management System Merchant Account 280. As previously stated, the money may first go through a Selling Agent 130, who collects costs/fees associated with the sale of the donated property.
At Block 655, the net proceeds are transferred to the appropriate Beneficiary Merchant Account 380, after any optional costs/fees are collected by the Donation Management System 120. Although this example shows all funds going through the Donation Management System Merchant Account 280 before being transferred to the Beneficiary Organization Merchant Account 380, there are other possible configurations. For example, funds from either the Buyer 160 or the Selling Agent 130 may be deposited directly into Beneficiary Organization Merchant Accounts 380, with optional fees later remitted to the Donation Management System Merchant Account 280 by the Beneficiary Organization 150.
At Block 660, receipts are provided to the Donor 110 and to the Beneficiary Organization 150 giving the details of the transaction. The flow ends at Block 665 when the Transaction Database 270 is updated. The actual flow may be different from the flow presented here, with additional steps, steps happening in a different order or steps being executed concurrently. For example, the Transaction Database 270 may be updated in a number of places throughout the process.
At Block 710, the Beneficiary Organization 150 has decided to use the Donation Management System 120 to accept proceeds from donated property. At Block 715, Beneficiary Organization 150 creates the hierarchical tree templates to be used for managing targeted donations. These templates may also be created by a Donation Management System 120 professional services arm or a third party such as Selling Agent 130.
At Block 720, a specific campaign is created which includes all attribute descriptions of the campaign. At Block 725, a tree template is selected which is then associated with the newly created campaign. At Block 730, individual member lists (containing multiple Members 358) can be applied to the template tree at any insertion point level. For example, a Beneficiary Organization 150 like Little League Baseball may have a campaign that uses a hierarchical tree template that has six drill-down sub-levels. (Little League: Region: State: Division: League: Team: Player). A list of Members 358 can be applied to one or more drill down levels, at any level of the hierarchical tree template. Furthermore, a list of Members 358 is not required to be applied to every level. Thus, a Donor 110 can give at any level of the tree hierarchy, even to specific individuals.
At Block 735, after any optional vetting and fine tuning of member lists at any level of the hierarchical tree, the Donation Management System 120 will generate a unique identifier for each level and each individual Member 358 associated at each level of the hierarchy. The Beneficiary Database 255 is then populated and activated and made available to Donors 110.
A sub-level of the Angels team 930 is a beneficiary member list 940. The beneficiary member list 940 is also represented in
Different portions of the same Beneficiary Organization 150 may register together or separately at the discretion of the Beneficiary Organization 150 itself. For example, the California Little League 910 and Idaho Little League 910 may register together or separately and manage their own member lists independently. They may also choose a different number of levels, to which Donors 110 may donate. For example, Idaho Little League 910 may choose to accept donations only at the Idaho state level 910, whereas the California Little League 910 may accept donations at the League Level 920, the Team level 930, and the individual player level 940.
A Donor 110 may choose to donate at any level provided by the Beneficiary Organization 150. For example, a Donor 110 may donate specifically to an individual player 940 such as Billy (9002), to a Team 930 (such as the Angels), to a League 920 (such as West League), to the State 910 (such as California), or to the general fund of the Beneficiary Organization 150 at level 900 of
In some embodiments, the Donor 110 could donate at multiple levels or donate conditionally across one or more levels, and one or more Beneficiary Organizations 150. As an example of a conditional donation, a Donor 110 could donate property to cover the costs of Little League fees for their grandson Billy 940 (9002) of
Although in a preferred embodiment, the System 120 is implemented in an online auction setting, any number of selling methods may be used with the System 120 including, but not limited to, consignment sales, live auctions, fixed priced auctions, silent auctions and traditional e-commerce storefronts. In addition, the System 120 may have different commission or payment models based on the type, condition and other product attributes as well as cash donations.
Hierarchical database schemas of organizations structure may vary from organization to organization. For example, some organizations may establish schemas to the sub-campaign level, while others may establish member accounts that are linked to a sub-campaign level, creating targeted accounts.
The System 120 presented may in some embodiments provide the ability for Donors 110 and for individual Beneficiary Members 358 to remain anonymous. In these cases the Beneficiary Database 255 and the Donor Database 215 would provide filtered data to the rest of Environment 100.
Although this invention has been described in terms of certain preferred embodiments, other embodiments that are apparent to those of ordinary skill in the art, including embodiments that do not provide all of the features and advantages set forth herein, are also included within the scope of this invention. Accordingly, the scope of the present invention is defined only by reference to the appended claims and equivalents thereof.
This application claims priority under 35 U.S.C. 119(e) to U.S. Provisional Patent Application Ser. No. 60/807,029 filed Jul. 11, 2006 and entitled SYSTEM AND METHOD FOR MANAGING TARGETED DONATIONS AND GIVING, the disclosure of which is incorporated herein in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| 60807029 | Jul 2006 | US |
