WO2017196565A1

WO2017196565A1 - Method for coordinating charitable donations between donors and recipients

Info

Publication number: WO2017196565A1
Application number: PCT/US2017/030305
Authority: WO
Inventors: Michael J. LINDELL
Original assignee: Lindell Technologies, Llc
Priority date: 2016-04-29
Filing date: 2017-04-29
Publication date: 2017-11-16

Abstract

A method matches a donor with a recipient from a list of multiple recipients having a plurality of needs. The method includes receiving a donation from the donor. The method also receives a request for funds from a recipient having at least one identified need. The recipient provides information supporting the identified need. The donation from the donor is then matched to funds requested from a recipient. The need of the recipient to receive the funds is validated by creating proof of the identified need independent from the provided information from the recipient. The need the need and availability of funds are then verified. The method concludes with transferring the funds to the recipient.

Description

Method for Coordinating Charitable Donations between Donors and Recipients

[0001 ] This patent application is claims priority to a United States provisional patent application filed on April 29, 2016 having application serial number 62/330,015, which is incorporated herein by reference.

Background Art

[0002] 1. Field of the Invention

[0003] The invention relates to a method for coordinating charitable donations.

More particularly, the invention relates to a method for coordinating donors and recipients in a manner that maximizes the benefit for both the recipient and the donor.

[0004] 2. Description of the Related Art

[0005] Charitable organizations are everywhere. All receive donations from donors and transform those donations into some form of good or another, and pass along to the recipient a benefit in one form or another. The donation process is nothing like a normal gift giving process because the donors and the recipients never know each other. Additionally, the donations are marginalized by the portion of the donation that is allocated to overhead. Current methods and systems allow for donations to be contributed for one of several identified causes on a website. However, these contributions are not personal to a recipient, but to an organization that uses a significant percentage of each donation to pay for of the organization or the website.

SUMMARY OF THE INVENTION

[0006] A method matches a donor with a recipient from a list of multiple recipients having a plurality of needs. The method includes receiving a donation from the donor. The method also receives a request for funds from a recipient having at least one identified need. The recipient provides information supporting the identified need. The donation from the donor is then matched to funds requested from a recipient. The need of the recipient to receive the funds is validated by creating proof of the identified need independent from the provided information from the recipient. The need and availability of funds are then verified. The method concludes with transferring the funds to the recipient.

Figures of the Invention

[0007] Advantages of the invention will be readily appreciated as the same becomes better understood by reference to the following detailed description when considered in connection with the accompanying drawings, wherein:

[0008] Figure 1 is a simplified flow-chart of the invention;

ates with each sub-system to process donations and fund recipients.unded tigure 1 is a system diagram of the invention:

[0009] Figure 2 is a simplified flow-chart of the invention;

[0010] Figure 3 is a flowchart for a donor profile;

[001 1 ] Figure 4 is a flowchart for identifying giving preferences;

[0012] Figure 5 is a flowchart for receiving and coordinating donor payments;

[0013] Figure 6 is a flowchart for creating a recipient file;

[0014] Figure 7 is a flowchart for matching a recipient with a validator;

[0015] Figure 8 is flowchart for setting up a validator;

[0016] Figure 9 is a flowchart for matching a validator; [0017] Figure 10 is a flowchart for lead generation for a validator;

[0018] Figure 1 1 is a flowchart to verify needs of recipient;

[0019] Figure 12 is a flowchart for gathering information of a recipient;

[0020] Figure 13 is a flowchart for the payment of funds;

[0021 ] Figure 14 is a flowchart for verifying a profile of a recipient;

[0022] Figure 15 is a flowchart to determine whether a simple or a complex verification is required;

[0023] Figure 16 is a flowchart for a simple verification;

[0024] Figure 17 is a flowchart for a complex verification; and

[0025] Figure 18 is a flowchart for resolving verifier conflicts.

Detailed Description of the Preferred Embodiment

[0026] The inventive method allows donors of charitable contributions to globally impact people in need in a brand-new way, allowing 100% of donated funds to go directly to the cause. The platform provides a host of state-of-the-art functionalities, which include giving both donor and recipient the ability to connect on a personal level, as well as the ability to see how their contributions trickle down and impact multiple lives over time. Additionally, recipients are automatically connected to a network of organizations that serve as facilitators, as well as life coaches.

[0027] The method is implemented in a web based application. A central computer system 10 is shown in Figure 1 and controls various web accesses by defined users from the web. The central computer system 10 stores the software to implement the method steps as further defined hereinafter.

[0028] The web application supports four major transaction types/roles which are indicated in Figure 1 as sub-systems, as follows:

[0029] The method and system allow at least four types of web or mobile app access points by the above roles. There is a donor sub-system 12, recipient sub-system 14, validator sub-system 16, and verifier sub-system 18. A central administrator system 20 controls and communicates with each sub-system to process donations and fund recipients. The overall, simplified method is shown in Figure 2.

[0030] To be considered a donor, the donor is required to enter donor information and set up an account in the donor sub-system 12. The donor is requested to set up giving preferences, as further described below. The donor is prompted for payment information to supply the funds to the system. Once the funds are received 22, the funds are listed 24 on a Donor Funds list as available for matching to a recipient. A donor dashboard 26 is set up to display history information as later described to show all the benefits satisfied by the donor's funds. When a donor deposits funds, the funds along with donor and preferences are added to a Funds list. The donor may select which recipient will receive the donated funds from a Needs database 28, or a donor may specify giving preferences, if any, and the administrator system 20 will assign a recipient from the Needs database 28 to donated funds. The donor may also select from a validators dashboard 30, which validator to use in the verification process. Otherwise, the administrator system will assign a validator.

[0031 ] To be a recipient, an account is also required to be set up through the recipient sub-system 14. The recipient account includes profile information as to the need request. Upon setting up the recipient account, the amount of the recipient requested funds 32 is placed in the Needs database 28. Based on the recipient profile, a recipient dashboard 34 is created to allow status reports for the donor to view. The system seeks to match donated funds with a recipient's requested funds 36. Such matching may occur by the donor reviewing the Needs database and selecting a match for funding, or the administrator system automatically matching donor/recipient based on each profile designating needs and donor's giving preferences.

[0032] After a donor/recipient match is made, a validator may either be: a) assigned to a recipient based on a variety of parameters automatically; or b) manually matched with a validator by a customer service representative through the validator sub-system 30; or c) selected by the donor. Initial assignments are based on location. The services of a validator are requested upon a match 38 and the validator is provided with the recipient's information. The validator can accept or pass on any assignment. Upon acceptance 40, the validator connects with and provide service to validate the request. The validator reviews the recipient's needs and provides proof of needs including photos, video, and other proof of need 42 providing a recipient's profile. Upon completion of review, the validator lists 44 the recipient's profile on a queue board 46 awaiting review by a verifier 54.

[0033] A verifier reviews the queue board 48 and accepts assignments 50. The verifier reviews the selected recipient's profile to determine the level of verification process based on a preset dollar threshold level. At the highest level, a verifier is required to conduct further investigation and request an on-site visit 60 between a local verifier and the recipient. This helps ensure the need truly matches the fund request. Below the threshold level, the verifier can determine the accuracy authenticity of the request, and approve funds be dispersed. Status of the process is updated in the queue 52. After review and approval by the verifier, the funds are requested 56 will be transferred to the validator, who in turn transfers the funds to the recipient 58. The central system 20 updates both donor 26 and recipient 34 dashboards to show funds usage.

[0034] The Donor sub-system 12 allows for new donors to register via a web portal as shown in Figures 3-5. Donors can set up a new account with a unique email address and password, or other social media as is commonly known in the art. Once a new account is set up, donors can login as an existing account. Upon successful login, Donors are prompted for profile information as illustrated in Figure 3 to complete set up and create the donor dashboard 26. Upon login 70, the donor is prompted to complete required fields 72. If validation error occurs 74, the donor is required to make changes to correct the error 76 before proceeding. Optional fields are also prompted at 78 and validation errors are also checked at 80 to allow changes as required at 82. The following information is representative of the required and optional information requested during donor profile creation: Email Address, Password, Name, Date of Birth (Date Picker), Gender (Male/Female/Prefer not to answer), Primary Contact Number, Alternate Contact Number, Country, Address, Notification Options, Notifications by SMS (On/Off), Notifications by Email (On/Off), Marital Status

(Single/Married/Widowed/Divorced/Separated/Other), Dependent Children (Yes/No), Number of Children, Age of Children, Ethnicity, and How did you hear about the inventive method?. Once the questions are successfully answered, the donor saves its donor profile 84 and the entry ends 86. All information provided in the Donor profile is updatable once authenticated upon subsequent visits by the Donor to his or her profile.

[0035] Upon successful completion of the donor profile in Figure 3, the donor is directed tothe input giving preferences shown in Figure 4. The method starts at 90. The donor is required to complete the giving preference fields 92, such fields are validated for errors 94, and requests changes 96 from the donor if an error occurs. Upon successful entry of all fields, the donor may save their preferences 98 and the method ends 100. Examples of optional Giving Preferences include: Hardship Theme (TBD), Hardship Type (Multi-select: Food/Shelter/Education/ Medical/Clothing/ChildCare/Prayer), Hardship Location (City/County/State/ Regional/Country/Anywhere), Recipient Age Range, Recipient Marital Status, Recipient Gender, Recipient Children (Yes/No), Recipient Ethnicity, Minimum Need (in US Dollars), Maximum Need (in US Dollars).

[0036] After completing donor profile and giving preferences of Figures 3-4, the donor may select to donate funds. Figure 5 illustrates the donor sub-system 12 steps to receive funds from a donor after login 102. The donor is prompted to select type of donation 104 as recurring or one time. If a recurring donation is selected 106, the donor is prompted to select start today 108 or to enter a future date 1 10. If a future date is established, the donor profile is sent to a Payment Processing Queue 1 12 for later processing. If the start date is today, or if a one-time donation is selected at 1 14, the donor is prompted to select payment method 1 16. Funding method may include any commonly used form such as credit card, e-check, PayPal, Bitcoin or other private currency or money exchange. If credit cards or e-checks are used 1 18, the appropriate information is entered for withdrawal of funds, and the donor is prompted to save the payment method 120. If the payment method is to be saved, it is saved at 122 in Payment processor. If not requested to save, the data is deleted 124. In regard to the Paypal or Bitcoin or other online payer, the donor is prompted to login in to their account for payment 126. After each payment, the donor is prompted 128 to determine if another donation is desired to start again or end 130.

[0037] The donor sub-system 12 creates the donor dashboard 26 from the donor profile information and uses past and current donations to contain history and statuses, though not limited thereto. The donor dashboard 26 displays: Giving History which lists recipients who have received donations contributed by donor; cumulative impact of contributions; a list of active and ongoing contributions; achievements earned; an area to set and track contribution goals; and a genealogy/matrix.

[0038] Donors can access the Needs database 28 to allow them to view and search for active recipient looking for charitable donations. Donors can select one or more needs and choose to donate immediately or setup a new recurring donation. Donors have access to the Validators dashboard 30 to allows them to view and search through active validators. Donors can select one or more validators, see their active recipients and choose to donate immediately or setup a new recurring donation.

[0039] Donors have a one click "brag" feature that posts their contribution (default and personalized message) to their social media pages (Facebook/Twitter/etc). Information available on donor dashboard 26 supports filtering and sorting where applicable, such sorting as is known in the art. Donors receive notifications when any donation (one-time or recurring) posts to the system and when funds are approved and dispersed to recipients. Donors receive a confirmation notification when any configuration change is made to their profile or giving preferences.

[0040] The Recipient sub-system 14 allows for recipients to register and request assistance via the web or a phone app or a mobile application as shown in Figures 6-7. Login and initial login set up is as commonly known in the art requiring unique email/password or other social media login. Upon successful login creation, recipients supply personal information to substantiate the need and creates a recipient profile and dashboard. As indicated in Figure 6, upon successful login 132, the recipient sub-system 14 prompts a new login recipient to enter personal information 134, enter brief biography 136 to include need request, which includes explaining the need request 138. Next, recipients are prompted to select how they heard 140 about the system 10 and allow a text explanation 142. Then, the recipient is prompted to submit their profile 144 before ending their profile creating session 146.

[0041 ] The personal information collected during the recipient is similar to the donor information requested and prompts to create the profile includes, though not limited to: Email Address; Password; Name; Nickname; Date of Birth; Gender (Male/Female/Prefer not to answer); Primary Contact Number; Alternate Contact Number; Country (This field determines the format of the address fields based on selection); Address; Marital Status (Single/Married/Widowed/Divorced/Separated/Other); Children (Yes/No); Number of Children; Age of Children; Ethnicity; Preferred Method of Contact (Email/Phone); Information specific to the recipient's needs may include: What type of assistance are you seeking? (Financial/Goods/Services/Prayer); Select the area of need? (Multi-select /TBD); and Tell us about your specific need? (Text Field). Validation is required for all fields where applicable. Masking is also required for all fields where applicable.AII information collected is provided in the Recipient profile and is locked once submitted and transmitted to a Validator for confirmation and review, as later discussed. The recipient sub-system 14 creates the recipient dashboard 34 that provides status on their request for assistance. Once a validator is assigned, recipients have a section of their dashboard 34 showing the validator biography, credentials and contact information. Recipients then receive notifications once their request is received. Recipients receive notifications once a validator is assigned. Recipients receive notifications once their need is approved. Recipients have a built-in messaging capability that allows them to communicate via the dashboard 34 with their validator. A Recipient can cancel their active/open need from their dashboard.

[0042] As illustrated in Figure 7, the administrator system 20 matches a recipient based on specified criteria to a validator. Such criteria include matches typically based on which validator is closest to the recipient in terms of geography and secondarily, which validator has the lightest workload. However, other criteria may be added or used. Upon a donor/recipient match (or upon new recipient profile created), the administrator system 20 starts 150 and automatically matches a recipient with a validator 152. A display message is sent 154 to the recipient dashboard 34 may message the recipient to notify that a validator match is in progress156, and that they will hear from the validator 158 before ending 160.

[0043] The Validator sub-system 16 and method are shown in Figures 8 - 10. In

Figure 8, the validator sub-system 16 set up of validators. Upon starting allows administrators are allowed to upload or input validator profiles 164 via the web portal, such information from a trusted source or other reliable information or preferences. The system auto-generates a temporary password valid for 48 hours. Upon its creation, a validator is sent an email address with their new credentials, the temporary password, and access link 166. The validator can then login to central system with provided login information, i.e., username and password 168. If the login information is correct, the validator is required to retype or change password and user name 170 and then the process ends 172. If there is an error 174, the validator is prompted to check their email address or password 176 and may retry to type in correct password and email 178. The system can prompt for a forgotten password 180 and email validator a temporary password or new link 182.

[0044] To upload a validator during initial setup 164, the system prompts for the following information: Email Address; Salutation (None/Mr./Ms./Mrs./Miss/Dr.); Name; Occupation/Title; Date of Birth (Date Picker); Gender (Male/Female/Prefer not to answer); Primary Contact Number; Alternate Contact Number; Country (This field determines the format of the address fields based on selection); Address; Ethnicity; Areas of Compassion (Multi-select TBD); Languages Spoken (Multi-select TBD); Affiliation (Multi-select - TBD).

[0045] The validator sub-system 16 matches possible recipients to a validator based on auto-assign criteria as indicated in Figure 9. The matching method starts 190 by prompting a validator to log in 192 and prompting selection of the auto validator 194 to receive an assignment. A match may be found based on the auto-assign criteria, such as demographics, expertise/passions, and language. Upon a match, a recipient is assigned to a validator 196 and the validator is sent an email 198 with the assigned recipient, which the validator may accept or deny 200. If accepted, the validator may contact the recipient 202 to initiate review and downloads the recipient profile, and this process is ended and moves on to "B" 210, which connects with B 222 in Figure 1 1. If declined 204, or no recipient is provided, customer service or administrator may manually identify closest validator 206 and make a match 208 to initiate it in the system.

[0046] Figure 10 illustrates the process of a validator selecting a recipient. Upon starting 212, a validator logs in 214. The validator may select a recipient 216 from the needs board, and then contact the recipient to initiate review. The process ends 218 and moves on to "B" 222 in Figure 1 1. [0047] Figure 1 1 illustrates the process to allow a validator to initiate review of a recipients need request. This process starts at "B" 222 which comes from Figures 9-10. The validator reviews the recipients need request 224 and verifies 226 that needs meet defined parameter (such as ???) and requests a meeting with the recipient 228. If the needs do not meet defined parameters, the validator can log a new need request 230 for approval from an administrator. If approved 232, the validator can continue to the meet request 228. If the new need parameters are not approved, the process is ended 234. Based on meeting the recipient and other external investigation, the validator collects proof 236 of need which includes, but not limited to, accurate recipient information, pictures, create video, family history, etc. A secure device 238 is used to take pictures and video supporting the need. The process proceeds to "C" 240 and onto Figure 12.

[0048] The validator sub-system16 updates/creates the recipient profiles based on the information collected by a validator as illustrated in Figure 12.

[0049] Referring to Figure 12, upon completion of review of a recipient, the validator logs in and is prompted to fill in an intake form 244 in the system for each recipient assigned to the validator to obtain recipient data (demographics). The input is typically manual entry 246 either free form or selection of options or drop down box. Validation of entry is checked 248: if errors exist, the validator is allowed to make changes 250. The validator is requested to upload 252 proof of need including pictures, video, family history, testimonial, etc. which is typically manually entered 254. The validator is prompted to select 256 if relief is a one-time request or whether it is recurring. If it is a recurring request, prompts for date range and frequency are displayed 258 and may include a drop down box for such information 260. A save button is activated to ask if finished 262. If requests are saved, the recipient profile is completed and submitted 264 for verification and the process ends 266 to await approval by the verifier sub-system 18. If the save button is not activate, additional information may be provided in the fields if necessary 268.Specific fields on the intake form, which are filled at 244 include, but are not limited to, the following: Full Name; Nickname; Date of Birth (Date Picker); Gender (Male/Female/Prefer not to answer); Primary Contact Number; Alternate Contact Number; Country (This field determines the format of the address fields based on selection); Address; Marital Status; Significant Other's Name; Children (Yes/No); Names of Children; Number of Children; Age of Children; Other family members/persons living with recipient; Ethnicity; Preferred Method of Contact (Email/Phone); Living Arrangements (Own/Rent/Other/Homeless); Temporary Living Situation (Yes/No); Details on Living Situation; Type of Housing (Apt/House/Hotel/Projects/Section 8/Shelter/Other); Type of assistance needed? (Financial/Goods/ Services/Prayer); Area of need? (Multi- select /TBD); Details about the specific need? (Text Field); How long has the problem been going on?; Need Type (Recurring/One-Time); If recurring, Duration of Need; Frequency of Need (Weekly/Monthly/Annually/Other); History of abuse or victimization?; Has the recipient taken any steps to remedy the situation? (Yes/No) and Details?; Recipient Education and Work History; Current Job; Duration at Job; Work History Detail; Allow for previous jobs to be added to this profile; Recipient Level of Education; Degrees, Certifications, Programs Completed; Recipient Financial Information; Income Type (Allow Multiple); Options: Employment, Government Assistance, Pension/Retirement, Child; Support/Alimony, Gifts, Social Security, Disability, Food Stamps, Other; Monthly Expenses (Allow Multiple); Options: Rent/Mortgage, Electricity, Gas, Water, Phone, TV, Internet, Laundry, Groceries, Vices, Medicine/Prescriptions, Household, Pet, Childcare, Child Support/Alimony, Meals, Transportation, Clothing, School Expensive, Debt/Credit Payments, Other Fees, Giving, Entertainment, Subscriptions/Dues, Insurance, Misc., Other. The System 10 allows for the entry of proposed budgets and spending plan. The system 10 displays side by side view of current vs. proposed budget; Recipient religious affiliation (TBD); Details on the recipient's spiritual journey; Recipient support system; Details on the support system; family Nearby (Yes/No); If yes, list family member and contact info; Does the recipient have a close relationship with family? (Yes/No); If yes, list family member and contact info, Attends church or other support group?; If yes, list detail and contact info for group leader; Does the recipient have any friends who are aware (Yes/No); Is the recipient seeking counseling?; If yes, details; Has the recipient ever been diagnosed and/or treated for mental illness? (Yes/No); If yes, explain?; Is the recipient currently taking any prescribed medications? (Yes/No); If yes, list medications; If yes, description of medication and purpose for taking it; Has the recipient ever been hospitalized for depression, suicide or mental illness? (Yes/No); If yes, when, where and what for?; Has the recipient experienced trauma at some point in their life? (Yes/No); If yes, explain. Validation is required for all fields where applicable. Masking is also required for all fields where applicable.

[0050] The Validator sub-system 16 creates the validator dashboard 30 that provides status on their assigned recipients and profile information about the validator. The validator can modify his/her contact details in his/her profile. The Validator has the ability to schedule tasks, follow ups, meetings and critical support items and have it display in both an agenda and calendar format. Validators receive notifications once a recipient is assigned or queued. Validators have a built-in messaging capability that allows them to communicate via the portal with their recipients. Validators post their recipient profiles on the queue board 46 so that the verifiers can initiate work. Validators receive a notification when verifiers make comments, notes or request additional information for research profiles and supporting data through the queue board. Validators can respond to comments made by verifiers and update data as needed for verifier approval. [0051 ] Illustrated in Figure 13, the final validator sub-system 16 method steps that includes the verifier notifying the validator of approval. The steps are started 268 and validators receive notification 270 once their recipient's need is approved by a verifier. The sub-system 16 creates a message to the validator and the status is changed in the recipient's profile on the queue board, as subsequently discussed. Validators request and receive the funds 272 or remedy for the recipient, and then distributes the funds 274 to the recipient through the central system 10. Validators are prompted to collect and input proof of distribution of funds 276 to the recipient and uploads same to their recipient's profile. The validator is requested to schedule and input follow up with the recipient 278, and the process ends 280.

[0052] The Verifier sub-system 18 and method allows administrators to create and input verifier profiles via the web portal to establish a verifier, in a similar manner as with the validators setup. The System 10 auto-generates a temporary password valid for 48 hours. Upon creating, a verifier receives an email address with their new credentials, temp password, and access.

[0053] The Verifier sub-system 18 provides an interface that accesses a queue board 46 where validators can see pending recipient profiles that have been completed by a validator. The Verifier interface allows verifiers to access the recipient profile and records with the following capabilities: Make edits and corrections to existing data; and Make comments/notes on data and media for validator review and response. Verifiers have intent to approve completed items on the queue board 46.

[0054] Verifiers set the following statuses in a recipient profile on the queue board

46: [0055] Pending Information - Status given when verifier requests more information from validator. This causes the status to change for validator, a notification to be sent and the recipient request to be filtered from the verifier view.

[0056] Approved - Status given when a verifier confirms everything is in order and approves the request for funding.

[0057] Escalated - Status given when a verifier identifies an issue not addressable by the validator. This goes to a second verifier queue or to a management individual. It is also assigned for fraud and dispute issues.

[0058] Pending Onsite Review - Status given when a verifier needs a field agent to verify the need or request in person. This goes to a special verifier queue and assigned to a verifier who is local to the validator and can meet with the validator and/or the recipient.

[0059] Pending Approval - Status given when a recipient issue is placed in the queue for review.

[0060] Initially, the recipient profile is reviewed by the verifier in Figure 14. Upon submission 290 of the recipient profile to the queue board 46 by a validator, the process is started 292. Verifiers may be notified when new recipient profiles are added to the queue board 46 for review. A verifier accepts a recipient profile 294 when the status is set to "pending review." The verifier selects the recipient profile from the queue 46 and begins review. The verifier is asked if the profile requires edits 298, and if so, makes appropriate edits 300. Thereafter, the verifier is asked if more information 302 is required. If yes, the verifier changes the status of the recipient profile to "pending information" 304 and comments added and messages the validator to continue investigating 306. If no, the verifier creates an external profile 308 (need more information on what is this and its purpose) and then changes the status of the profile to "complete" 310 for funding determination and the process is ended 312.

[0061 ] The verifier sub-system 18 proceed to a determination using the flow chart of Figure 15 as to whether the Simple or Complex Verification is required. A threshold of funds is set and may be reconfigured by demographic location. The validator submits the recipient profile to the queue board 46 initially with a status of "pending approval" 314. The threshold of the need is checked 316. If the need is above the threshold 318, the complex verification is required in Figure 17. If the need is below the threshold 320, a simple verification is required as in Figure 16.

[0062] Figure 16 illustrates the final verification of a recipient profile as a simple verification (less than the threshold). The process is started 322 and the verifier receives notification of "pending verification" 326 as a status of the recipient profile on the queue board 46. The verifier selects the recipient profile from the queue board 326 and begins review. The verifier sub-system 18 checks to see that the funds are available and received 328 from the donor. If not, the verifier changes the profile status to "pending information" 330 and adds notes, messages the validator 332 to add information, who in turn edits the recipient's profile 334 and resubmits the profile as "pending verification." If the verified funds are determined to be received 328, the verifier checks to see if the funds were used 336. If the funds are not used properly 336, the status is changed to "pending information" 338 and again sent back to validator to update. If the verified funds are used properly, the verifier checks for any other issues 340, and if none, changes the status to "approved" 342. The process ends 348 and feedback can be requested 350, as commonly known in the art. If the verifier finds issues, the status is changed to "flagged" 344 and the system moves to "D" 346 and Figure 18 is implemented. [0063] Figure 17 illustrates the method of complex verification and is started 352 when the requested funds are above a threshold in Figure 15. The verifier receives notification of "pending verification" 354 as a status of the recipient profile on the queue board 46. The verifier selects the recipient profile from the queue board 46 and begins review. The verifier locates nearest local verifier 356 to coordinate an on-site visit. If a local verifier is available 358, the status of the recipient profile is changed to "pending onsite verification" 360. If no local verifier is available, the status is changed to "pending information" 362 and sent back to find local verifier 366. Upon the status changing to "pending onsite verification" 360, the local verifier and the validator and the recipient arrange a meeting 364. If the local verifier signs off 366 on the recipient's profile after the meet, such approval is sent to the verifier 368 who in turn changes the status to "approved" 370 causing the process to end 372 and can process feedback 350. If the local verifier does not sign off on the recipient's profile, the status of the profile is set to "flagged" 374 and the process continues to "D" 346 and Figure 20 controls.

[0064] Figure 18 illustrates the flowchart for conflict resolution when the recipient status is changed to "flagged" or "D" 346. In this case, the process is started 376, the verifier receives notification of "escalation" 378 through messaging and status change on recipient's profile. The verifier checks to see if the funds were not received 380. If no, the verifier checks to see if the issue was the funds weren't used 382. If no again, the dispute is closed 384 and the process ended 386. If either the funds weren't used 380 or the funds weren't received 382, the verifier checks to see if the validator has proof 388. If yes, the dispute is closed. If no, the validator's profile is locked 390 to prevent further access and a refund is triggered 392. [0065] The invention has been described in an illustrative manner. It is to be understood that the terminology, which has been used, is intended to be in the nature of words of description rather than of limitation.

[0066] Many modifications and variations of the invention are possible in light of the above teachings. Therefore, within the scope of the appended claims, the invention may be practiced other than as specifically described.

Claims

I claim:

1. A method for matching a donor with a recipient from a list of multiple recipients having a plurality of needs, the method comprising the steps of:

receiving a donation from the donor;

receiving a request for funds from a recipient having at least one identified need, the recipient providing information supporting the identified need;

matching the donation from the donor to funds requested from a recipient; validating the need of the recipient to receive the funds by creating proof of the identified need independent from the provided information from the recipient;

verifying the need and availability of funds; and

transferring the funds to the recipient.

2. A method as set forth in claim 1 including the step of providing information about the donor and the recipient to each other.

3. A method as set forth in claim 1 including the step of the donor selecting a recipient from the list of multiple recipients, and selecting a validator to validate the need of the recipient.

4. A method as set forth in claim 1 including the step of listing giving preferences for the donor and automatically matching a recipient from the list of multiple recipients with the donor based on the identified need matching the giving preference of the donor.

5. A method as set forth in claim 4 including the step of requesting a selected validator from a list of validators to be assigned to validate the need of the recipient and provide visual confirmation of the need.

6. A method as set forth in claim 5 including the step of the selected validator accepting or denying the assignment.

7. A method as set forth in claim 6 including selecting a validator based on geographical location near the geographical location of recipient.

8. A method as set forth in claim 7 including the selected validator creating a recipient profile including externally researched facts of the selected recipient.

9. A method as set forth in claim 8 including sending the recipient profile to a queue board, the queue board containing a plurality of recipient profiles with each profile including a status of at least pending or approved.

10. A method as set forth in claim 9 including assigning a verifier to a review profile listed as pending.

1 1. A method as set forth in claim 9 including allowing a verifier to select a recipient profile from the queue board having a status as pending.

12. A method as set forth in claim 1 1 including reviewing the recipient profile to substantiate need and approving the disbursement of funds to the recipient by updating the review profile to a status as approved.

13. A method as set forth in claim 1 1 including disbursing funds to the recipient when the review profile has a status changed to approved.

14. A method as set forth in claim 1 1 including creating a donor dashboard to be displayed to list history of donations and matched recipients.

15. A method as set forth in claim 14 including creating a recipient dashboard to be displayed in the computer system to list the need of recipient and personal information.

16. A method as set forth in claim 15 including creating a validator profile to be displayed in the computer system to list the contact information of the validator.

17. A method as set forth in claim 16 including granting access to the donor to view the validator profile and assign a selected validator to review the need of a selected recipient.

18. A method as set forth in claim 15 including creating a donor profile that lists a history of donations and the needs that funded the recipients.

19. A method for matching a donor from a list of multiple donors with a recipient from a list of multiple recipients having needs, the method comprising the steps of:

receiving a donation from the donor;

receiving a request for funds from the recipient having at least on identified need; matching the donation from the donor to funds requested from a recipient;

validating the need of the recipient to receive said funds;

transferring the funds to the recipient; and

creating a donor dashboard that lists history of donations and the needs that the donations funded for the donor.

20. A method for matching a donor from a list of multiple donors with a recipient from a list of multiple recipients having identified needs, the method comprising the steps of:

inviting the donor to identify a type of need selected in a giving preference; receiving a request for funds from the recipient having at least one identified need, the recipient providing information supporting the identified need;

matching the giving preference of the donor to funds requested from a recipient; validating the need of the recipient to receive the funds requested by creating proof of the identified need independent from the provided information from the recipient and creating a recipient profile; and

verifying the need and availability of funds independently.

21. A method as set forth in claim 20 wherein the donor donates the funds requested by the recipient when the donor reviews the match.

22. A method as set forth in claim 21 the funds are transferred to the recipient.