Patent Application
20210398179
The invention relates to technology, in a platform for matching donors with donees (e.g., victims of natural and man-made disasters, crises, economic plight/uncertainty and other events or other donees), for verifying the claims and needs of the donees and avoiding fraud.
Many people suffer from natural and man-made disasters and other events for which they need resources from donors. These victims have a variety of needs. Many organizations (e.g., public, private, for-profit, non-profit and other organizations) are focused on obtaining donations of money and other resources for these victims. Unfortunately, for various reasons, not all of the donated resources make it to the actual victims. Additionally, some unscrupulous people falsely claim to be victims, when they are not. Some are true victims but overstate their needs.
There are also market inefficiencies and limited transparency, between the needs of individuals impacted by a disaster (natural and man-made) and the good will of donors who aim to provide relief. This results in excessive in-kind waste, mis-direction of monetary funds, untapped human talent, and prolonged recovery. One of the greatest inefficiencies is with the matching the needs of people impacted and the good will of donors who want to provide relief. There's a common misconception that because people have lost everything, they must need everything, so donors send everything. Approximately 60% of individual in-kind donations are believed to go to waste.
Changes in communications and other technology have already made significant improvements in emergency management, yet there is still no way to holistically track people's needs, whereabouts, and state of recovery. Information asymmetry exists across the relief supply chain.
Some organizations have developed websites and other online resources to attempt to use technology to facilitate the identification of victims and the receipt of donations. However, an inherent problem with the use of online technology is that users can create fake accounts and fraudulently claim to be victims or overstate any actual needs. This is a problem that results from the difficulty of ensuring that users that create accounts are who they claim to be and that they have the needs they claim to have.
Another problem is that many people refrain from asking for help as they are embarrassed and uncomfortable, particularly with respect to asking for help from neighbors. These and other problems exist with known systems.
One aspect of the invention relates to a technology platform for matching victims (or other donees) and donors that leverages technology and various algorithms to perform victim (or other donee) validation and needs verification. As used herein, donee is intended to broadly cover recipients of donations, financial aid or other economic benefit, relief from economic plight or uncertainty, debt or other relief of financial obligations and/or recipients of other assistance. The events leading to need is intended to broadly cover natural and man-made disasters, crises, economic plight/uncertainty and/or other events that adversely impact one or more individuals.
According to some embodiments, the invention comprises a connective platform that enables real-time relief, ensuring that the right resources get to the right people at the right time. One aspect relates to validating that those who claim to be victims are legitimate and that the claims they make regarding needs are verified. In part, this prevents the use of fake identities via the internet or the falsification of actual needs.
The validation may be done on individuals, their specific claimed needs and/or on alleged disasters or other events giving rise to needs of individuals. The validation may also be done on multiple individuals, families, groups, companies and other people or entities claiming a need for a donation of resources.
The validation(s) may be performed using a detection and decisioning algorithm (and/or an aggregate of sub-algorithms that are calculated based on provided and unprovided variables about the requester, claims and events). This may include automatically obtaining and/or updating data from the victim and other information from a variety of sources and applying a variety of algorithms to generate an Access Validity Score (AVS) used to assess a given individual's integrity/truth/worthiness for a specific requested good or service. The outcome of the AVS will be a continuous number yet may be used in a binary fashion to determine whether the relationship of a specific request is valid or invalid in accordance with a stored set of rules.
The metric can be used by a provider of a service or product, or access to an entity (rideshare/home/etc.) which potentially could be provided at discounted cost. Examples are provided below.
Some implementations of the system include a marketplace for matching victims and donors. The platform may include an ecommerce component for enabling victims to create an electronic shopping basket with specific items that the victim needs. Donors can identify a victim in need and purchase specific items on the victim's behalf through a trusted third party retailer who is validated as part of accessing the platform. Other implementations are feasible and the invention is not limited to this implementation.
Another aspect relates to resource verification and tracking. This enables verification and/or validation of resources (e.g., products, services and other resources). Another aspect relates to disaster (and other event) tracking and monitoring to enable verification and categorization of events and profiling their impact. Another aspect relates to an analytics component with machine learning component to enable quantitative and qualitative data capture and analysis, the creation of impact, needs and recovery scores and transaction and operations performance management and optimization.
User (impacted and donor) validation is a core platform functionality. Fraud and risk scores may be used to ensure genuine resources are applied to qualified individuals. To facilitate this, the system may store a set of rules for generating a needs score and/or other scores (e.g., Impact score, recovery score).
For companies, individuals or other entities that want to help, but do not know how to leverage their products, services, talent and/or other resources, the platform enables them to recommend or offer public and private resources so they can be added to the platform.
The system of the invention has many advantages as set forth herein and others as will be apparent from the description contained herein. In addition to those mentioned elsewhere, the advantages include transparency in donee claims, donor resources and the actual distribution of money and resources to people and other entities who claim a need.
In some scenarios, it may be desirable to protect the anonymity of the recipient while still preventing fraud. To accomplish this the system may enable the capability of connecting donees and donors while keeping protecting the verified identity of the donee. This may be done using a variety of known or hereafter developed technologies that enable online platforms to connect two or more parties anonymously.
These and other objects, features, and characteristics of the system and/or method disclosed herein, as well as the methods of operation and functions of the related elements of structure and the combination thereof, will become more apparent upon consideration of the following description and the appended claims with reference to the accompanying drawings, all of which form a part of this specification, wherein like reference numerals designate corresponding parts in the various figures. It is to be expressly understood, however, that the drawings are for the purpose of illustration and description only and are not intended as a definition of the limits of the invention. As used in the specification and in the claims, the singular form of “a”, “an”, and “the” include plural referents unless the context clearly dictates otherwise.
The present disclosure, in accordance with one or more various embodiments, is described in detail with reference to the following figures. The figures are provided for purposes of illustration only and merely depict typical or example embodiments.
It will be appreciated by those having skill in the art that the implementations described herein may be practiced without these specific details or with an equivalent arrangement. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the implementations of the invention.
The event management module 106 for managing supported events may enable the creation of events to be supported by the system. One or more event templates may be created, stored and used to provide a consistent set of information and rules for various event types. Examples of some events are shown in
The resources/needs matching component 108 may comprise a set of graphical user interfaces that may enable donees to identify their needs and publish this information through the system and graphical user interfaces that may enable donors to find the donees, view their needs, select a donee and make resources available to meet the donee's needs. Examples of sample interfaces are provided below.
The system may also include a set of APIs 116 to an ecommerce platform and/or other systems for obtaining other resources. For example, an API may connect to an ecommerce system of a validated partner (e.g., an online retailer) such that donees can select available resources (e.g., products or services) that they need and add them to an ecommerce basket. When a donor elects to provide some or all of the resources to the donee, the donor may select the basket (and/or portions thereof) and buy the items through the online retailer. The system APIs facilitate the ability for donors select the items and automatically be connected to the ecommerce platform.
According to another aspect of the invention the system may include a rules engine 110 for creating and storing rules relating to needs verification and a scoring module for generating needs scores. The rules may be electronically stored rules relating to validating events and a donee's stated needs. Examples of some of the type of rules are described below. The scoring module 114 may be used to generate one or more scores by applying the rules for a given event type using data about the event and the individual donee. Examples of some of the types of scores are described below.
According to another aspect of the invention the system may include a data management module 118 for obtaining, managing and storing data needed by the system. The data may include data about events, donors, donees, resources, and partners, among other types of data. The data may include data entered into the system by system administrators, donors, donees and partners. It may also include data automatically obtained by the system, including for example, data obtained about donee's from publicly available sources to verify the claimed needs of donees.
With reference to
According other technical aspects of the invention, the system may include a resource filter module 108 that includes programming instructions to determine the suitability of resources for a selected event, e.g., the goods and services based on the likely needs of donees based on a variety of factors, including for example, the event characteristics, the locale of the event and/or other factors. Additionally, the system may include programming instructions 104 to calculate a needs score for different donees and provide a relative ranking to determine the donees most in need. Based on the ranking, the system may include programming instructions to display the donees with greater need in a higher ranked position. Other techniques may be used to ensure that the resources flow to those individuals most in need first.
By way of example the system may include programming instructions to make a determination of the suitability of needs to determine whether a set of available goods and services are suitable for the donee, prior to the donee explicitly requesting support (e.g., placing the goods or services in their basket) for a said item. Similar to the financial sector where a customer is assessed for “suitability” of a loan or financial aid, a suitability micro-score may be generated to determine the needs of a donee based on a variety of factors. The needs micro-score may be used by programming instructions to determine what is displayed and/or accessible to the donee on the platform. The programming instructions may be configured such that the platform does not display or make available to the donee resources (e.g., goods or services) that are not deemed within reason for the donee's impact claim and/or where the good or service benefit does not outweigh the cost. By way of example, the score may take into account information about the donee prior to the event, the impact of the event and the likely current needs of the donee based on the event. In the case of a loan, a loan for 250K would not be rendered to an individual on the platform who has debt of 100K, and no secured assets that exceed the value of the loan.
By way of further example the system may include programming instructions to make a determination of the, the calculation of the score may take into consideration various factors, including for example:
By way of example the system may include programming instructions to make a determination of the relative ranking of needs scores. For example, the system may calculate a stack ranking of donees from most urgent and eligible to least urgent and eligible. Based on urgency and/or eligibility, donees request may be stacked rank (e.g., similar to the result set from a google search), validating that donees with the most urgent needs (e.g., food, water, pharmacy) are met first. Once basic needs are met, prioritization may be determined based on the categorization of necessary and discretionary human needs. The platform 100 may systematically, and continuously rank each donee and/or donee request as new information is provided and the population of events and donees evolve. The algorithm may create a relative ranking taking into consideration, for example, the following:
Similar to student financial aid, donees will be ranked, continuously, allowing for the individuals with the most urgent needs to be surfaced and fulfilled first, accelerating a faster path to recovery.
As shown for example in
As shown for example in
As shown for example in
As shown for example in
An important technology tool that the system may use is a validation module 122 (
By way of example, the tables below show some of the variables and micro-scores. While the AVS may be an aggregate score of a collection of micro-scores; micro-scores will be generated to inform the AVS and/or to be used independently. The term AVS is used for convenience of reference only. The scores may include a variety of types of scores that are generated according the rules stored in the system.
To facilitate this, according to another aspect of the invention, the system may include a rules engine 110 for creating and storing rules relating to needs verification and a scoring module for generating needs scores. The rules may be electronically stored rules relating to validating events, donee's stated needs, donors resources, and/or other items to be validated. Examples of some of the type of rules are described below. The scoring module 114 may be used to generate one or more scores by applying the rules for a given event type using data about the event and the individual donee and other factors as desired. Examples of some of the types of scores are described below. Application of the scores may be determined by use case, context, and economic value of request.
Nodes of related variables which could be used to derive a particular AVS score may include but are not limited to, type of request, the context surrounding request, explicit data inputs, inferences, known fraud scores to validate or invalidate the claim when triangulated around what is a known truth, i.e., did an event in said location occur and was the individual impacted in such a manner as to be rendered in need of help.
EXAMPLE: Calculating the access verification score that a family of X living in Y city lost all belongings in a Z disaster. Result set is a score that would validate that said family's need for critical resources.
The output of AVS will be used to decision and approve the request of the individual in accordance with rules stored in the system (e.g. that the score is greater than some threshold).
The following are examples of variables that may be used. This is not a comprehensive list. Other variables may be used. This also shows an example of a source for the information and the variable type. For the variable types stored in the system, the system may store and use the source to identify from where the system may obtain the data.
Use case 1: Guest request use of a home on AirBnB under the claim that they are impacted by the California wildfires.
Use case 2: Individual(s) request a basket of goods via a Branded Website [Everest—Walmart] to support their basic needs during after being impacted by COVID-19
Use case 3: Individual(s) are burdened by medical debt and list their outstanding bills as a need with the goal of getting help paying it off. This assumes that access to help with medical bills is more of a critical need than providing cash or basic goods; medical bills provide relief in perpetuity vs. 1× relief.
The description of the functionality provided by the different instructions described herein is for illustrative purposes, and is not intended to be limiting, as any of instructions may provide more or less functionality than is described. For example, one or more of the instructions may be eliminated, and some or all of its functionality may be provided by other ones of the instructions. As another example, processor(s) 112 may be programmed by one or more additional instructions that may perform some or all of the functionality attributed herein to one of the instructions.
The various instructions described herein may be stored in electronic storage, which may comprise random access memory (RAM), read only memory (ROM), and/or other memory. In some implementations, the various instructions described herein may be stored in electronic storage of one or more components of system 100 and/or accessible via a network (e.g., via the Internet, cloud storage, and/or one or more other networks). The electronic storage may store the computer program instructions (e.g., the aforementioned instructions) to be executed by processor(s) 112 as well as data that may be manipulated by processor(s) 112. The electronic storage may comprise floppy disks, hard disks, optical disks, tapes, or other storage media for storing computer-executable instructions and/or data.
Implementations of the disclosure may be made in hardware, firmware, software, or any suitable combination thereof. Aspects of the disclosure may be implemented as instructions stored on a machine-readable medium, which may be read and executed by one or more processors. A machine-readable medium may include any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computing device). For example, a tangible computer readable storage medium may include read only memory, random access memory, magnetic disk storage media, optical storage media, flash memory devices, and others, and a machine-readable transmission media may include forms of propagated signals, such as carrier waves, infrared signals, digital signals, and others. Firmware, software, routines, or instructions may be described herein in terms of specific exemplary aspects and implementations of the disclosure, and performing certain actions.
Although illustrated in
The various components illustrated in
The one or more databases described herein may be, include, or interface to, any suitable electronic data storage system and may comprise one or more such databases that reside in one or more physical devices and in one or more physical locations. The one or more databases may store a plurality of types of data and/or files and associated data or file descriptions, administrative information, or any other data in accordance with various data schemas.
For purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the description. It will be apparent, however, to one skilled in the art that implementations of the disclosure can be practiced without some of these specific details. In some instances, modules, structures, processes, features, and devices are shown in block diagram form in order to avoid obscuring the description. In other instances, functional block diagrams and flow diagrams are shown to represent data and logic flows. The components of block diagrams and flow diagrams (e.g., modules, blocks, structures, devices, features, etc.) may be variously combined, separated, removed, reordered, and replaced in a manner other than as expressly described and depicted herein.
Reference in this specification to “one implementation”, “an implementation”, “some implementations”, “various implementations”, “certain implementations”, “other implementations”, “one series of implementations”, or the like means that a particular feature, design, structure, or characteristic described in connection with the implementation is included in at least one implementation of the disclosure. The appearances of, for example, the phrase “in one implementation” or “in an implementation” in various places in the specification are not necessarily all referring to the same implementation, nor are separate or alternative implementations mutually exclusive of other implementations. Moreover, whether or not there is express reference to an “implementation” or the like, various features are described, which may be variously combined and included in some implementations, but also variously omitted in other implementations. Similarly, various features are described that may be preferences or requirements for some implementations, but not other implementations.
The language used herein has been principally selected for readability and instructional purposes, and it may not have been selected to delineate or circumscribe the inventive subject matter. Other implementations, uses and advantages of the invention will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. The specification should be considered exemplary only, and the scope of the invention is accordingly intended to be limited only by the following claims.
This application claims priority to U.S. Provisional Patent Application Ser. No. 63/040,143, filed Jun. 17, 2020, entitled “DONEES AND DONORS MATCHING PLATFORM WITH DONEE VALIDATION AND NEEDS VERIFICATION”, which is hereby incorporated herein by reference in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| 63040143 | Jun 2020 | US |
