Crowdsourcing allows an entity to collect funds for a cause. Such crowdsourcing (crowdfunding) typically requires the services of a third party (e.g., Kickstarter, Indiegogo) to help raise awareness of the cause and to ultimately raise funds for the cause. The third party relies upon responses to advertising of the cause and volunteers that are willing to donate to the cause.
An existing network is enhanced to collect donations to fulfill a donation request. The donation request, received via a cloud interface from a requestor, contains a request amount that is divided into smaller portions (split amount) and requests for these smaller portions are sent out to potential donors of the existing network. Donations are received via the existing network, and when the collected total of donations matches the requested amount, the requested amount is sent to the requestor.
In one embodiment, a computer-implemented method fulfills a request through an online structure. The request for a request amount is received within the online structure from a requestor. The request amount is divided by a split amount to determine a chosen number of potential donors from which to request donations. The chosen number of potential donors are selected from a pool of potential donors. A request for the split amount is included within a communication based upon a protocol of the online structure and transmitted via a network of the online structure to each of the selected chosen number of potential donors. A response is received from each of the selected chosen number of potential donors via the network and using another communication of the protocol. When the response includes the donation amount, the donation amount is collected as received donations within the online structure. The received donations are sent to the requestor when the requested amount is fulfilled.
In another embodiment, a system fulfills a request through an online structure. The system includes a network implementing a protocol, an application programming interface (API) for communicating with a mobile device to receive a donation request from a requestor, an evaluator for evaluating legitimacy of the donation request, a pool of donor records, where each donor record identifies a potential donor, and a manager implemented as machine readable instructions that when executed by a processor of the system are capable of (a) determining a chosen number of potential donors based upon the donation request and a split amount, (b) selecting the chosen number of potential donors from the pool, (c) sending a request for the split amount to each of the selected potential donors, (d) collecting donations from the selected potential donors; and (e) sending the collected donations to the requestor.
In another embodiment, a non-transitory computer readable medium has computer executable instructions stored thereon that, when executed by a digital processor, perform the method of fulfilling a request through an online structure. The non-transitory computer readable medium includes instructions for receiving, within the online structure, a request from a requestor for a request amount, instructions for dividing the request amount by a split amount to determine a chosen number of potential donors from which to request donations, instructions for selecting the chosen number of potential donors from a pool of potential donors, instructions for including a request for the split amount within a communication based upon a protocol of the online structure, instructions for transmitting the communication via a network of the online structure to each of the selected chosen number of potential donors, instructions for receiving, via the network and using another communication of the protocol, from each of the selected chosen number of potential donors, a response, instructions for collecting a donation amount as received donations within the online structure when the response includes the donation amount, and instructions for sending the received donations to the requestor when the requested amount is fulfilled.
Network 101 facilitates secure collecting of donations to fulfill a request and is formed in part by one or more of the Internet, wireless networks, wired networks, local networks, and so on. Network 101 provides remuneration interaction between a plurality of resources 110, via associated acquirers 106, and a plurality of consumers 112, via associated issuers 108. For the examples shown herein, resources 110 and consumers 112 have indicated their willingness to make donations through structure 102.
Using a protocol 104, network 101 and structure 102 cooperate to fulfill agreements between resources 110 (via an associated acquirer 106 of the resource) and consumers 112 (via an associated issuer 108 of the consumers). For example, network 101 may include a network switch that handles communication between acquirers 106 and issuers 108. In one embodiment, structure 102 represents a network, such as MasterCard® and Visa®, that operates a scheme for, e.g., debit or credit cards, that are linked to accounts of the resources 110 and consumers 112, and where protocol 104 is implemented as defined by ISO 8583. In one embodiment, structure 102 and protocol 104 implement a tokenization service (e.g., MasterCard Digital Enablement Service) that improves security of the agreements. In
When consumer 112 enters into an agreement with resource 110 (which can be, for example, a merchant or a service provider), structure 102 uses protocol 104 to implement messaging (e.g., a transaction) between resource 110, acquirer 106, issuer 108, and consumer 112 to fulfill an obligation (e.g., remuneration) of the agreement. For example, the agreement may result from consumer 112 requesting goods or services from resource 110, wherein the obligation is for consumer 112 to remunerate resource 110 for the cost of the goods or services. However, these schemes, as previously known, do not facilitate soliciting and collection of donations.
In embodiments, to facilitate such donations, structure 102 includes an application programming interface (API) 120 that provides an external interface (e.g., a cloud interface to the Internet) that allows an external or remote computer 132 to communicate securely with structure 102. In one embodiment, API 120 is implemented as JavaScript Object Notation (JSON) FRE-API, and may implement a mutual transport layer security (TLS) protocol, as known in the art.
Computer 132 includes a digital processor 133 that is communicatively coupled with a memory 135. Processor 133 represents one or more digital processors and memory 135 represents one or more of volatile memory (e.g., RAM) and non-volatile memory (e.g., ROM, FLASH, magnetic media, optical media, and so on). In one embodiment, computer 132 is a mobile computer, such as one of a laptop, notebook, tablet, and smartphone, that is used by a requestor 130. In another embodiment, computer 132 is a stationary computer, such as a desktop computer, that includes a web browser, wherein API 120 provides a web interface that facilitates creation of request 136 by requestor 130. Requestor 130 is for example a person or entity in need of funds, such as for funding a startup company, or is someone looking for funding for survival due to hardship. Requestor 130 downloads an app 134 onto computer 132 that enables computer 132 to communicate securely with structure 102 via API 120. App 134 is software, stored in a non-transitory portion of memory 135, that includes machine readable instructions that are executed by processor 133 to improve functionality of computer 132 and to allow communication with structure 102 via API 120. Requestor 130 interacts with app 134 to generate a request 136 that is uploaded to structure 102 via API 120. In one embodiment, app 134 provides a graphical user interface that prompts requestor 130 to enter the necessary data to prepare request 136. API 120 thereby allows any computer running app 134 to generate and send request 136 to structure 102. Request 136 defines a request amount (see request amount 304 of
Structure 102 also includes a manager 150 that operates to fulfill request 136. Manager 150 is implemented within software 109 of structure 102 and includes machine readable instructions stored within memory 105 and executed by a digital processor 103 to provide the functionality described herein.
Each resource 110 and consumer 112 (which, as contemplated herein, could also be an entity such as a charitable organization) indicates consent to receiving donation requests (e.g., a solicitation for a donation amount) from structure 102, and manager 150 adds a donor record 142 to pool 140 identifying each consenting resource or consumer as a potential donor. In one embodiment, during creation of an account associated with one of acquirer 106 and issuer 108, a corresponding one of resource 110 and consumer 112, respectively, provides information to complete donor record 142. In another embodiment, resources 110 and consumers 112 consent to receiving donation requests (e.g., a solicitation for a donation amount) from structure 102 after their associated accounts have been formed. Advantageously, structure 102 may thereby utilize the existing network of resources 110 and consumer 112 to fulfill request 136.
In one embodiment, structure 102 includes two pools 140, one corresponding to resources 110 that consent to receiving donation requests, and one corresponding to consumers 112 that consent to receiving donation requests, thereby allowing one or both of requestor 130 and structure 102 to choose from which pool 140 requestors are selected. In another embodiment, donor record 142 indicates a type of the consenting donor (e.g., resource 110 or consumer 112), thereby allowing one or both of requestor 130 and structure 102 to choose the type of donor to select.
Structure 102 may include an evaluator 160, implemented as machine readable instructions stored within memory 105 and executed by processor 103, that evaluates and validates request 136. In one example of operation, manager 150 receives request 136 from computer 132, and invokes evaluator 160 to evaluate whether request 136 is genuine and should be fulfilled by structure 102. In one embodiment, evaluator 160 interacts with an administrator of structure 102 to determine whether request 136 is genuine and is eligible to be fulfilled by structure 102. In another embodiment, legitimacy of request 136 is based upon pre-authorization of requestor 130 and/or based upon at least one card from participating issuers. Manager 150 then, based upon request amount 304 of request 136, determines a split amount 152 (e.g., one-hundred dollars). In one embodiment, split amount 152 is preconfigured. In another embodiment, split amount 152 is determined based upon donor records 142 within pool 140. Manager 150 then divides the requested request amount 304 by split amount 152 to determine a chosen number 154 of the number of donors required to fulfill the request. For example, where request amount 304 is ten-thousand dollars, and split amount 152 is determined to be one-hundred dollars, manager 150 calculates chosen number 154 as one-hundred donors. Manager 150 then selects chosen number 154 potential donors from pool 140 based upon donor records 142, and sends a request message 156 for the split amount 152 to each donor via acquirer 106 and/or issuer 108. In response to request message 156, each potential donor sends a response message 157 containing the donated amounts, these amounts are collected as received donations 158 within structure 102. Response message 157 is transported within network 101 using protocol 104, and thereby facilitates secure transfer of donated funds. For example, information of request messages 156 and response messages 157 may be added to existing messaging of protocol 104, thereby utilizing the existing network 101 of structure 102, acquirer 106, and issuer 108.
Where selected donors decline to donate, additional donors are selected from pool 140, and request messages 156 are sent to request split amount 152 therefrom. Once received donations 158 contains sufficient funds to fulfill request 136, manager sends received donations 158 to computer 132 via API 120, where they may be stored within a wallet 138 of computer 132 for example. In one embodiment, manager 150 transfers received donations 158 to an account of requestor 130 that may be defined within request 136 for example.
In one embodiment, where received donations 158 is insufficient to fulfill request 136, after a predefined period, structure 102 sends the insufficient received donations 158 to an account of requestor 130. In another embodiment, where received donations 158 is insufficient to fulfill request 136, after a predefined period, structure 102 returns the donated amounts to the donors.
Request messages 156 and response messages 157 are implemented through protocol 104 and network 101. In the embodiment where protocol 104 implements ISO 8583, split amount 152 may be added to a data element of a communication sent from structure 102 to one of resources 110 and consumers 112 using protocol 104 and network 101, to form request message 156. Similarly, the donation may be added to the data element of another communication sent from the resource or the consumer to structure 102 using protocol 104 and network 101, to form response message 157.
In one embodiment, where resource 110 is a retail store (e.g., a grocery store), resource 110 may collect donations from customers. For example, a cashier of resource 110 may ask customers whether they are willing to donate to the request. If the customer responds affirmatively, the donation amount is added to a checkout total, such that the customer's final charge includes the donation. For example, if the checkout total is ten dollars, and the donation amount is two dollars, then the customer's final charge is twelve dollars. In one embodiment, a point of sale device (as used by the cashier for example) of resource 110 is configured to send the donation amount, using protocol 104 (i.e., within the data element of the ISO 8583 protocol) to structure 102, wherein structure 102 charges the consumer the total amount (e.g., twelve dollars), manager 150 adds the donation amount to received donations 158, and the balance (e.g., ten dollars) forms the customer's payment to resource 110.
In another similar embodiment, where resource 110 is a retail store (e.g., a grocery store), resource 110 receives a request for split amount 152 (e.g., $100) from structure 102 and collects donations for smaller amounts (e.g., $2) from customers. For example, a cashier of resource 110 may ask customers whether they are willing to donate a small amount to the request. If the customer responds affirmatively, the donation amount is added to a checkout total, such that the customer's final charge includes the donation. Resource 110 accumulates donated amounts and when the accumulated amount reaches split amount 152, resource 110 sends the accumulated amount to structure 102. Structure 102 may also specify a time constraint for returning split amount 152 to structure 102. Where resource 110 has not collected the full amount within the specified time constraint, the resource sends any collected amount to structure 102. Structure 102 may then select an additional potential donor from pool 140 and send request message 156 for the remaining portion of split amount 152 to the additional potential donor.
In one embodiment, when registering a credit/debit card with issuer 108, each consumer 112 agrees to donate a small amount each time that the card is used. For example, consumer 112 may agree to donate one dollar each time they user a credit card for a purchase. Issuer 108 accumulates these donated amounts and, when the accumulated amount reaches the split amount 152, issuer 108 sends the accumulated amount to structure 102.
In step 402, method 400 receives a request for a donation amount. In one example of step 402, manager 150 receives request 136 via API 120. In step 404, method 400 evaluates the request. In one example of step 404, manager 150 invokes evaluator 160 to evaluate request 136 and to decide if request 136 is genuine and should be fulfilled.
Step 406 performs a decision. If, in step 406, method 400 determines that the request is eligible for fulfillment, method 400 continues with step 408; otherwise, method 400 terminates, optionally sending a message to requestor 130 indicating the rejection of the request.
In embodiments envisioned by step 408, method 400 determines a split amount based upon the request amount and donor records within the donor pool. In one example of step 408, manager 150 determines split amount 152 based upon request amount 304 of request 136 and amount 204 of donor records 142 within pool 140. In step 410, method 400 determines a chosen number of potential donors and identifies potential donors from a pool. In one example of step 410, where request amount 304 is ten-thousand dollars and split amount 152 is one-hundred dollars, manager 150 determines chosen number 154 as one-hundred and selects chosen number 154 (one-hundred) potential donors from pool 140 based upon donor records 142.
In step 412, method 400 sends requests to the selected potential donors. In one example of step 412, manager 150 utilizes protocol 104 to send request messages 156 to each selected donor via the corresponding acquirer 106 or issuer 108 to solicit a donation. In the example of
In step 414, method 400 receives potential donor response. In one example of step 414, manager 150 receives response messages 157 from resources 110 and consumers 112 that each received one request message 156.
Step 416 performs a decision. If, in step 416, method 400 determines that a donation was received within the response, method 400 continues with step 418; otherwise, method 400 continues with step 424. For example, where response message 157 includes a donation amount, method 400 continues with step 418. Where response message 157 declines to donate (i.e., the donation amount is zero), method 400 continues with step 424.
In step 418, method 400 adds the donation amount within response message 157 to received donations 158. Step 420 performs a decision. If, in step 420, method 400 determines that request 136 is fulfilled, method continues with step 422; otherwise, method 400 continues with step 414 to receive further response messages 157. In step 422, method 400 sends the donation to the requestor. In one example of step 422, manager 150 sends received donations 158 to computer 132 via API 120, where computer 132 stores the donation in wallet 138. Method 400 then terminates.
In step 424, method 400 identifies additional potential donors. In one example of step 424, manager 150 selects an additional potential donor from pool 140 based upon donor records 142. In step 426, method 400 sends a request to the additional potential donor. In one example of step 426, manager 150 sends request message 156 to resource 110 via acquirer 106. Method 400 then continues with step 414.
Steps 414 through 426 repeat until request 136 is fulfilled and the received donations 158 are sent to requestor 130. Method 400 then terminates.
Steps of method 400 may have alternate structure and be performed in a different order without departing from the scope hereof. For example, the identifying of potential donors, sending of requests, and receiving of donations may be grouped. In another example, structure 102 may receive donation amounts within response messages 157 that are different from split amount 152, wherein manager 150 determines an amount for solicitation from subsequent potential donors based upon a remaining amount required to fulfill request 136.
It should thus be noted that the matter contained in the above description or shown in the accompanying drawings should be interpreted as illustrative and not in a limiting sense. The following claims are intended to cover all generic and specific features described herein, as well as all statements of the scope of the present method and system, which, as a matter of language, might be said to fall therebetween.