Computer-Implemented Control Systems and Methods for Data Allocating of a Plurality of Sharing Database Files

Abstract

A peer-to-peer direct sharing system and method for efficient payment of medical expenses with funds from the other members and the receiving member's own contribution. A display device and user input device encourages member interaction and personal connection using geographic representation of sharing. The allocation component determines the sharing between members where the sending member sends a share amount to one or more receiving members. Allocation may proceed in multiple steps, over different time frames, to encourage rapid sharing from one member to another. Transfer approval may be contingent on member interaction to send funds directly from one member's virtual wallet to another member's virtual bill account. Paying providers is streamlined by bundling payments from multiple sharing members and an unsharable portion from the receiving member into a single payment.

Claims

1. A computer-implemented control system for processing sharing database files comprising: an allocating component for assigning a first share portion from a first share associated with a first user device from a shares database comprising a plurality of shares to an receiving item associated with a second user device from a receiving items database; a display device for displaying: a sending element displayed on the display device in a location-specific manner; a recipient element displayed on the display device in a location-specific manner; a share component moveably displayed on the display device and displayed initially adjacent to the sending element; and wherein movement of the share component to a position within a share region, wherein the share region encircles the recipient element on the display device, without entering the first share portion or identifying information related to the second user device, generates a transfer signal.

2. (canceled)

3. (canceled)

4. (canceled)

5. (canceled)

6. (canceled)

7. (canceled)

8. (canceled)

9. (canceled)

10. (canceled)

11. The computer-implemented control system of claim 1, wherein the allocating component is further configured to: receive a second receiving item associated with the second user device; load a plurality of receiving items into a receiving items database and a share amount for the plurality of sending devices into a shares analysis database; and proceed, starting with the shares analysis database and the receiving items database, to (1) select a first receiving item from the receiving items database, (2) select a selected share from the shares analysis database, and (3) assigning the selected share to the first receiving item submitted by the second user device, (4) if a selected share amount of the selected share exceeds a first need amount of the first receiving item, then assigning the selected share to the second receiving item submitted by the second user device, wherein substeps 1-4 are performed in an iterative manner until the earlier of (A) the share amount of the selected share is fully applied, and (B) any of the plurality of receiving items that were submitted by the second user device have been satisfied.

12. (canceled)

13. A computer-implemented method for processing sharing database files having a plurality of share amounts based on a plurality of requests from a plurality of receiving devices, the computer-implemented method comprising: receiving a plurality of receiving items on behalf of the plurality of receiving devices, wherein a first receiving item is associated with a first receiving device and a second receiving item is associated with the first receiving device; loading the plurality of receiving items into a receiving items database; loading a plurality of shares, each having a share amount, associated with each of the plurality of sending devices into a shares analysis database; and allocating, with a data allocating component and starting with the shares analysis database and the receiving items database, by (1) selecting the first receiving item from the receiving items database, (2) selecting a selected share from the shares analysis database, and (3) assigning the selected share to the first receiving item submitted by the first receiving device, (4) if a selected share amount of the selected share exceeds a first need amount of the first receiving item, then assigning the selected share to the second receiving item submitted by the first receiving device, wherein substeps 1-4 are performed in an iterative manner until the earlier of (A) the share amount of the selected share is fully applied and (B) any of the plurality of receiving items that were submitted by the first receiving device have been satisfied.

14. (canceled)

15. The computer-implemented method of claim 13 further comprising: determining a sharable amount that is less than the first receiving item and a remainder amount that corresponds to a difference between the first receiving item and the sharable amount; allocating a first set of the plurality of share amounts from the shares analysis database, wherein a sum of the first set of the plurality of share amounts is equal to the sharable amount; and allocating an amount equal to the remainder amount to the first receiving device.

16. (canceled)

17. (canceled)

18. (canceled)

19. (canceled)

20. (canceled)

21. The computer-implemented method of claim 13, wherein the first receiving item has an oldest date in the receiving items database and where the selected share has a selected share amount that is at least 65% of the first receiving item.

22. The computer-implemented method of claim 13, further comprising the step of: allocating, if a selected device associated with the selected share failed to respond to the allocating component within six days, a subsequent share from the selected device to a super wallet that does not require device interaction to respond to the allocating component.

23. The computer-implemented method of claim 22, wherein the steps of: allocating further comprises the steps of first, allocating funds from the super wallet to a plurality of priority receiving items; and then, allocating a plurality of remaining shares from the shares analysis database to the receiving items database in order of an oldest to a most recent.

24. (canceled)

25. (canceled)

26. (canceled)

27. The computer-implemented method of claim 13, wherein the step of allocating further comprises the step of: allocating shares from the shares analysis database that are associated with sending devices having a fastest speed sharing ratings to receiving items in the receiving items database in order of an oldest receiving item to a most recent receiving item.

28. The computer-implemented method of claim 13, further comprising the step of: calculating a time for a sending device associated with the selected share to respond to the allocating of the selected share.

29. The computer-implemented method of claim 28, further comprising the step of: displaying a share speed rating on the sending device related to the time for the sending device to respond to the allocating of the selected share.

30. (canceled)

31. The computer-implemented method of claim 13, further comprising the steps of: displaying on a selected sending device associated with the selected share; a sending element displayed on the display device in a location-specific manner; a recipient element displayed on the display device in a location-specific manner; a share component moveably displayed on the display and displayed initially adjacent to the sending element; and wherein movement of the share component to a position within a share region, wherein the share region encircles the recipient element on the display device, without entering the selected share amount or identifying information related to the first receiving device, generates a transfer signal.

32. (canceled)

33. (canceled)

34. A computer-implemented method of allocating a plurality of sharing database files based on a plurality of requests from a plurality of receiving devices, the method comprising: loading a plurality of receiving items into a receiving items database, where each of the plurality of receiving items is associated with a date and a receiving item amount; loading a plurality of shares for a plurality of sending devices into a shares analysis database; and allocating, using a data allocating component, from the shares analysis database and from a super wallet, wherein the super wallet does not require a response from a user device.

35. The computer-implemented method of claim 34, further comprising: selecting a selected share from the shares analysis database, where the selected share has a selected share amount; and assigning the selected share to a first receiving item that has an oldest date of the plurality of receiving items in the receiving items database and where the selected share has the selected share amount that is at least 65% of a first receiving item amount of the first receiving item.

36. (canceled)

37. The computer-implemented method of claim 34, further comprising the steps of: designating a first set of devices for assigning and allocating in a first week of the month; and designating a second set of devices for assigning of shares and allocating in a second week of the month.

38. (canceled)

39. (canceled)

40. The computer-implemented method of claim 35, further comprising: reassigning, if a sending device associated with the selected share failed to respond to the allocating, the selected share to the super wallet.

41. (canceled)

42. (canceled)

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Aspects are illustrated by way of example, and not by way of limitation, in the accompanying drawings, wherein:

[0018] FIG. 1 depicts an example of a display device and user interface for participating in the peer-to-peer sharing of medical expenses between members of a health care sharing ministry.

[0019] FIG. 2 is a flow chart depicting a method for a peer-to-peer direct sharing system comprising an allocation component.

[0020] FIG. 3 is a flow chart depicting a method for a peer-to-peer direct sharing system comprising an allocation component that assigns a sending member's excess share funds to a second bill associated with the same receiving member.

[0021] FIG. 4 is a flow chart depicting a method for a peer-to-peer direct sharing system comprising funding a bill account with funds from a plurality of sharing members and paying a medical bill using funds from the virtual bill account and funds from a second source.

[0022] FIG. 5 is a schematic workflow for managing the assignment of shares and payment of medical bills for members of a peer-to-peer direct sharing system.

[0023] FIG. 6 is a flow chart depicting a method for a peer-to-peer direct sharing system comprising funding a bill account with funds from a plurality of sharing members and paying a medical bill using funds from the bill account and funds from a receiving member.

[0024] FIG. 7 depicts an example of a display device and user interface for sharing funds related to a medical expense between members of a peer-to-peer, direct share health care sharing ministry.

DESCRIPTION OF EMBODIMENTS

[0025] A health care sharing organization can emphasize the community qualities of a mutual society with a direct sharing system for the peer-to-peer sharing of their medical expenses between the members. FIG. 1 shows an interface for a user, such as a member, to interact with a health care sharing community. Members of a health care sharing community send and receive funds when another member incurs a qualified medical expense. A method 200 for sharing with members in a direct sharing system comprises an allocation component is shown as a flow chart in FIG. 2. The allocation component is configured to assign a first share portion from a first share associated with a first member to a medical expense associated with a second member of the peer-to-peer direct-sharing community, as shown in step 202.

[0026] A display device 3 displays a sender element 10 and a recipient element 12. The sender element 10 and the recipient element 12 can be a generic graphic, as shown in FIG. 1, or can be a personalized image of the respective member.

[0027] The sender element and the recipient element can be displayed on the display device in a geographically representative manner, for example on a map 4 such as a map of the United States as shown in FIG. 1, and as shown in step 204 of FIG. 2. For example, the sender element 10 can be placed on a map 4 in a location generally corresponding to their physical location, home location, church location or another location affiliated with sending member. Likewise, the recipient element 12 can be placed on a map 4 in a location generally corresponding to their physical location, home location, church location or another location affiliated with receiving member. It may be preferable to place the marker element within a random set distance (for example, within a 5-, 10-, 20-, or 50-mile radius) away from the actual location of the member's location or their home. An offset distance may offer the members a sense of privacy, while effectuating a community feel based on the geographic representation. Alternatively, the sender element 10 and recipient element 12 may be placed in a geographic center of a zip code region, city, or state.

[0028] In order to activate a share transfer, a user input device 2 allows a sending member to activate a share approval component. The share approval component may be a button, text, graphic, or a share approval region 14 next to the recipient element 12, or a combination of these elements. The border of the share approval region 14 is shown by a dotted line in FIG. 1. The border of the share approval region 14 may be invisible.

[0029] Upon activation of the share approval component, a peer-to-peer transfer of funds in the amount of a first share portion is initiated. The sending member interacts with the share approval component in order to initiate the transfer of funds to the first member's virtual bill account, as shown in step 206. The allocation component provides the first share portion and identifying information related to the second member in order to transfer funds based on the first share portion to the second member. The display device 3 may display a share information section 5 containing information related to the share transfer, such as recipient name and share portion amount.

[0030] The allocation component may provide a data file to a share sending component, where the data file comprises the recipient name, the recipient account information, and the first share portion amount. The second member is not required to enter the first share portion amount or any required identifying information related to the second member in order to transfer funds based on the first share portion to the second member.

[0031] Activating a share approval component may require the sending member to move a transfer element 16 from a first position adjacent to the sender element 10 to a share approval region 14 near the recipient element 12. When the sender element and the recipient element are laid out geographically, the transfer element is moved by the sending member as if a package or envelope were being physically delivered. For example, the transfer element 16 can be moved from a position adjacent to the sender element 10 along path 18 to the share approval region 14. The sending member may release or place the transfer element within a radius around the recipient element 12 in order to trigger an approval signal to be communicated from the user input device 2 to the share sending component. Upon receipt of the approval signal by the share sending component, the transfer is initiated of the share amount from the sending member's account to the virtual bill account associated with one or more bills associated with the intended receiving member.

[0032] In order to efficiently connect sending members and receiving members, the allocation component can be configured to match a first sending member's share with multiple bills associated with a first receiving member, according to the method shown in FIG. 3. In certain circumstances, a single bill (or the remaining portion of a single bill after a partial allocation) may be less than the periodic fixed share amount that a sending member shares under the terms of the peer-to-peer, direct sharing organization. In these cases, it may be advantageous to match a single sending member with multiple bills from the same receiving member.

[0033] A plurality of medical expense bills are received on behalf of a plurality of receiving members, according to step 302. A first medical expense bill and a second medical bill are associated with a first member. The first and second medical bills are loaded into a bills analysis queue. The allocation component loads a share amount for each of a plurality of members into a shares analysis queue. The share amount is a dollar amount. The share amount may be determined by the guidelines, with a specific dollar amount that each member or group of members is responsible to send over a specific period of time.

[0034] An iterative process proceeds, as shown in step 306, which has several substeps. The iterative process runs until the earlier of (1) the share amount of a selected share associated with a sending member is fully applied to one or more medical expense bills, or (2) all of the medical expense bills submitted by a specific receiving member have been allocated.

[0035] The iterative process involves the following substeps. According to step 308, the first medical expense bill is selected from the bills queue. According to step 310, a selected share is selected from the shares analysis queue. According to step 312, the selected share is assigned to the first medical expense bill submitted by the first member. According to step 314, if the share amount of the selected share exceeds a first need amount of the first medical expense bill, then the selected share is assigned to the second medical expense bill submitted by the first member. The first need amount can be different from the first medical expense bill due to the member responsibility portion or due to the allocation of a previous share to the first medical expense bill or due to a negotiated discount or due to a repricing calculation.

[0036] In one embodiment, the allocation engine is a set of program instructions stored on a tangible computer-accessible storage medium in non-transitory form. The allocation engine operates by selecting a selected share. The allocation engine assesses the bills from the bills queue based by sorting the bills oldest to newest and prioritizing the oldest bill that can be mostly satisfied by the selected share. For example, the mostly satisfied threshold could be at least 70%, at least 80%, or at least 90% of the need amount of a bill. The oldest bill that is the right size is then selected for allocation. If remaining share portion satisfies the bill, then the allocation engine looks for additional newer bills in the available bills database that belong to the same membership.

[0037] Since multiple family members can be grouped a single membership, this preferential membership allocation could involve paying the medical expenses of multiple individuals. In such a circumstance, one selected share can pay the medical expenses of multiple individuals within the same household. For example, a single share could be sent to pay the medical expense bill for a father's broken leg and the additional share money is sent to the same membership for a bill related to the son's seizure treatment. If the first membership doesn't have additional bills, then remaining amount of share portion is assigned to another membership.

[0038] Sending a single share to a single membership based on multiple medical expense bills may minimize the number of financial transfers to separate individuals. This method also allows the health care sharing organization to better develop the interpersonal relationship between sending member and recipient member. Using this method, members may be more relationally connected and better enabled to pray and encourage their fellow member who may be undergoing serious medical treatment or medical expenses for multiple members of their family.

[0039] When a member is responsible for a portion of the medical expense bill, the direct sharing system may offer the receiving member the option to bundle funds from sharing members with funds from a second source in order to pay the whole entire medical expense bill in a single transaction, as shown in FIG. 4. Bundling health care sharing payments gives the receiving member the ability to bundle the gifts from other members and their own contribution, and then make a single payment to the provider that resolves the outstanding balance of the bill. This constitutes a dramatic improvement in convenience and efficiency and is an improvement on the traditional payment process in health care sharing and would constitute an improvement over traditional health insurance as well.

[0040] The health care sharing organization may require or permit the receiving member to have the ability to trigger an electronic funds transfer withdrawal from their bank account for the portion of the bill that is their responsibility. These funds would then be added to their Bill Account on the virtual share exchange. The output is a single payment, made up of funds contributed by sending members, and the funds contributed by the receiving member.

[0041] The health care sharing organization loads a plurality of share amounts corresponding to a plurality of members into a shares analysis queue, according to step 402. A first medical expense bill is received by the health care sharing organization from or on behalf of a first member of the plurality of members, according to step 404. The health care sharing organization determines a sharable amount that is less than the first medical expense bill, according to its guidelines, as shown in step 406. The health care sharing organization also determines a remainder amount that corresponds to the difference between the first medical expense bill and the sharable amount. This remainder amount may be the responsibility of the first member or may be the responsibility of a third party. The first medical expense bill amount may be a repriced amount based on fair bill repricing rather than the amount billed by the provider.

[0042] The health care sharing organization allocates a first set of the plurality of share amounts from the shares analysis queue in order to help the first member pay for their first medical expense bill. The allocation component continues to assign available shares to the first member until the sum of the first set of the plurality of share amounts is equal to the sharable amount, according to step 408. The members corresponding to the first set of the plurality of share amounts that are allocated to the first member are then responsible for sending their shares to the first member. These members transfer funds from their virtual wallet account to a virtual bill account, according to step 410.

[0043] The first member is able to initiate a payment of funds for the first medical expense bill comprising the sharable amount from the virtual bill account. The funds in the virtual bill account may not equal the total amount due for the first medical expense bill if there is a member responsibility portion. In that case, the first member cannot completely satisfy their bill without contributing additional funds. In order to streamline the process of receiving payments by the medical provider, the first member may provide the remainder amount from a second source to satisfy the first medical expense bill with a single payment, according to step 412.

[0044] In one embodiment, the allocation component selects a member's wallet. The allocation component assigns a share amount from the member's wallet to an oldest unmet bill in a bills payable database. Bill information can be stored in a bills payable database such as Mphasis™ Javelina™, which operates to receive bill information. A network connection is provided between the allocation component and the bills payable database. Upon request, upon initiation from another source, or according to a schedule, the bills payable database sends certain information from the bills payable database to the allocation component. The allocation component receives certain information from the bills payable database, which may include bill identification number, membership identification number, remaining bill amount required by the recipient member, and date the bill was created to determine age. The allocation component may also receive a date billed or a date that the bill was received by the health care sharing organization. In an alternative embodiment, the allocation component and the bills payable database are part of the same computer system.

[0045] The allocation component also receives information from a wallets-available database related to the availability of funds associated with members of the health care sharing organization. The wallets-available database may include the membership identification number, the wallet balance (a numeric value for the currency (dollars) that the membership has available in their virtual account for sharing), and the member's share schedule. The allocation component may receive upon request, upon initiation from another source, or according to a schedule the following data: membership identification number, current wallet balance, and the member's share schedule.

[0046] The member's share schedule may be used when a plurality of members share during different weeks of the month. For example, a first set of members are designated for allocation and sharing in the first week of the month. A separate set of members are designated for allocation and sharing in a second week of the month. In this way, members who submit a bill for payment do not have to wait until a monthly allocation cycle date. The recipient member can receive assistance from other members based on the weekly allocation.

[0047] The allocation component can be configured to prevent matching a sending member with a receiving member if a medical expense bill is being shared for a second time due to a failure to receive a share and the sending member has failed to send a share payment in a timely fashion. By requiring member interaction in order to send the share, there is the chance that a sending member will fail to timely send the share. In order to prevent a situation where a particular receiving member experiences repeated failures receiving a share, the health care sharing organization can track how timely a sending member sends their shares. For example, the sending member may have a 24-, 48-, 72-, 120-, or 168-hour window to approve the sending of their share. If the sending member fails to send their share within the selected window of time, then the sending member's share is not allocated to a receiving member whose need is being reallocated because of a failure to receive a timely payment. The health care sharing organization may also prioritize the sharing of a member's medical expense bill for those members who have consistently sent their share within the selected window.

[0048] The health care sharing organization can assign sharing speed rankings to members. The health care sharing organization may incentivize rapid sharing by preferentially matching members who have a history of rapidly completing the member interaction requirement to initiate the transfer approval. Members with fast sharing speed rankings may be preferentially matched with a member who had a need that went partially unpaid from a previous allocation in order to get the receiving member's bill paid as soon as possible. The display device may also be configured to show the sending member their sharing speed rankings or a sharing speed rate. This gamification of sharing may incentivize rapid sharing, adding another fun and personalized feature to further improve peer-to-peer sharing.

[0049] The allocation component may perform a pre-calculation to determine the ability of the members to assist with the submitted needs. The allocation component can take a sum of bill amounts due from the bills payable database and compare the amount with the sum of the wallet balance from the wallets-available database. A percent is calculated based on the sum of all of the wallets balance for the membership needed to pay all of the bills in the Bills Payable database at the fair billing price. For example, if the sum of the Bills Amount Due was $80,000 and the sum of the Wallets Balance is $100,000, then the wallet portion percentage for this exemplary period would be 80%. 80% of each wallet is then assigned to bills from the bills payable database.

[0050] If the sum of bills amount due exceeds the sum of the Wallets Balance, then the allocation engine proceeds to assign wallet amounts to bills until there is no additional balance in any of the virtual wallet accounts. The remaining bills would be shared in the next allocation cycle in a subsequent period. Those bills may then be prioritized as an oldest bill to expedite sharing. The member's automatic funding amount for their wallet may be increased when bills are not funded for multiple allocation cycles.

[0051] The allocation component tracks an assignment of membership shares, for example, member 0001 to member 0002 for bill 0003. Each assignment may have a unique assignment identification number. The member interaction to generate a transfer approval signal (as discussed below) may be associated with unique assignment identification number. The allocation component also tracks share portion amount. For example, a share portion amount for a particular assignment identification number may be $100 for a month. This is the amount of money that the sending member gives to other members. The allocation component creates a series of assignments. Each assignment identification represents a potential funds transfer from a first membership wallet to a bill associated with a second membership. The member interaction event that generates the transfer approval signal may be associated with multiple assignment identification numbers.

[0052] In order to fund the virtual wallet accounts with a wallet balance, the member may set up an automatic electronic funds transfer into the virtual account with a predetermined contribution amount on a regular cycle. The predetermined contribution amount can depend on family size, average age of the members of the household, maximum age of a member of the household, location, income, employment status, health metrics, and determination of qualification for charitable assistance.

[0053] In addition to sending funds from the virtual wallet account to assist with another member's medical care, the member may send funds from the member's virtual wallet account for administrative overhead to the health care sharing organization.

[0054] Funds that are not shared with another member or designated for administrative overhead can be built up for the member to share during a subsequent allocation. In this way, the member builds up a savings account that is available for that member to increase the capacity of the health care sharing organization to administer sharing to other members.

[0055] In order for a sending member to send a share, the health care sharing organization may require member interaction. One example of member interaction is swiping an icon to share, called Swipe-to-Share™ sending method. Sharing ministries allow a member to share in the needs of another member, specifically to help with the costs of receiving health care.

[0056] One advantage to health care sharing ministries over a health insurance company is the personal community connection. Traditionally, that community connection has been accomplished by personal letters expressing sympathy and prayers being sent along with a physical check to the receiving member. Automated electronic payments may be appealing to members because the automated electronic payment can be accomplished quickly, without much thought, and without a postage stamp. Requiring member interaction to initiate an electronic payment through a digital user interface provides a member experience that is simple and efficient as well as being personal and purposeful.

[0057] All fields may be determined during the allocation process and pre-populated into a mobile application as presented to the user via a display device. Fields may include recipient's name, receiving account information, and share portion amount. The recipient's location may be the street address, zip code, state, or other location identifying information. Non-Required fields may include prayer request from recipient and a field for response from sender. Another non-required field may include the recipient's profile picture.

[0058] The sending member may receive a notice from the mobile application that the share is ready for sending. The notification may be through email, popup, text message, sound alert, or the appearance of a symbol or logo. In order to emphasize the personal connection, a sender element and recipient element may be graphically displayed on a map.

[0059] The sending member may initiate sending the item to the recipient by moving a visual transfer element from the sender element to the recipient element. The transfer element represents the funds being transferred from the sending member's virtual wallet account to the recipient's wallet. The sender may then be prompted to pray for and write a note of encouragement to the recipient. Completion of the member interaction triggers a transfer approval signal. The user input device may send the transfer approval signal. Upon receipt of the transfer approval signal, the health care sharing organization or a partner transfers funds from the sending member's virtual wallet account to the receiving member's virtual bill account. The money in the virtual bill account is available to the receiving member to pay the medical bills. The member application can be as simple as an interactive button. Alternatively, the member interaction can be a swipe-to-share interaction with a user input device by the member with the transfer element as displayed on a display device. In this case, the member is able to physically use his or her finger to move the transfer element from the sender element to the recipient element, making the transfer a purposeful and intentional act of giving. The recipient sees that someone has sent money to them and they also receive an optional encouragement from the sender.

[0060] During allocation, a single sending member may have their share portion assigned to multiple bills. A primary recipient member may be identified. A primary recipient may be determined by the health care sharing organization as a minimum threshold for sharing with another member. For example, the health care sharing organization may determine that each member must share at least 65%, 75%, 80%, or 90% of their total share amount to a primary recipient. The primary recipient is displayed as the recipient member on the display device. And the prayer request is associated with that recipient member. In order to send all of the share portion to other members, the remainder portion of the share may be associated with a secondary recipient member. The display device may not display the secondary recipient. Alternatively, information related to a secondary recipient may be accounted for in a detailed accounting window.

[0061] A virtual wallet account may also be associated with the health care sharing organization, rather than an individual member, to facilitate certain sharing events. This virtual wallet account associated with the health care sharing organization may be referred to as a super member wallet. A bill may also be associated with the health care sharing organization, rather than an individual member, and be referred to as a super bill.

[0062] The super bill and super member wallet may be used to facilitate certain sharing events. For example, when multiple members are contributing to a bill, especially a larger bill, there is a chance that one or more assigned sending members will fail to initiate the sending of their share portion for a given period. This failure leaves the recipient member with an only partially funded virtual bill account.

[0063] Memberships who fail to initiate the sending of their share portion for a given period prior to a due date may be put into probation. Share portions from memberships in probation may be assigned to a probation bill, a type of super bill. The probation bill is not associated with a recipient member. The probation bill allows for the creation of a member funded account from members who missed one or more deadlines for sharing with an assigned recipient member. The funds paid toward the probation bill are transferred to a probationers' wallet, a type of super member wallet that is a virtual account controlled by the administrator of the sharing organization rather than an individual member. The probationers' wallet becomes available for a subsequent allocation. The probationers' wallet can be prioritized as a first share portion for rapid distribution to satisfy oldest bills. Funds from the probationers' wallet may be transferred automatically, without delay, since those funds are subject to probation rules and not otherwise restricted to be released upon a member interaction. By matching the funds from the probationers' wallet with oldest bills, bills that were not fully funded during a previous cycle are most quickly funded.

[0064] The super member wallet may also be used to process refunds from providers. Medical billing often involves negotiated discounts. It is possible that a virtual bill account can be over funded when a negotiated price is lower than the calculated fair billing price. In some circumstances, the excess funds can be directed from the virtual bill account to a super member wallet to make the funds available to members during a subsequent allocation cycle.

[0065] The allocation component can be configured to work with the super member and super bill. The allocation component can be run in multiple stages. For example, the super member wallet can be funded in a first allocation cycle from those members who are assigned to probation. In this example, all probationer's wallet share amounts are assigned to the super member wallet. In the next allocation phase, the funds from the super member wallet are allocated to priority medical expense bills. Priority medical expense bills can include bills where the receiving member did not receive all allocated shares during a previous allocation. Priority medical expense bills may also include bills that have received discounts based on early or timely payment. If the super member wallet has insufficient funds to provide for all of the priority medical expense bills, then the allocation engine may also prioritize allocating member wallet amounts from the members having the fastest speed sharing ratings. A third round of allocation involves regular member wallets (non-special member wallets) being allocated to regular bills (non-priority medical expense bills).

[0066] While reference is made to receiving or recipient members, in one embodiment of the health care sharing organization each member shares with another, even the recipient or receiving member. Also, as used in this disclosure, health care sharing ministries are considered the same as references to health care sharing organizations.

[0067] The operation of sending member shares portions can be divided between the members 502, the sharing organization 504, an allocation engine 506, and a communication portal 508, as shown in FIG. 5. The allocation provides certain allocation information 510 to the sharing organization 504. The allocation information 510 may include a sending member identification number, a receiving member identification number, a bill identification number, a unique assignment identification number, a share portion amount, a sharing speed ranking, and a sharing speed rate. The sharing organization processes the allocation information, according to step 512. Members are notified according to step 514. The member receives the notice, according to step 516. The notification can be received through the communication portal 508 or through a variety of notification methods. The member is prompted to agree to sharing, according to step 518, such as using the Swipe-to-Share™ sending method described above. If the member agrees to send the share, then the member is prompted to pray for and send a message of encouragement to the receiving member, according to step 520. The Sharing Organization receives an approval signal. If the sending member agrees to send share within 3 days, according to step 522, then the member may receive a reward, according to step 524. For example, the member may be notified that their sharing speed ranking has improved. In another example, the sending member's annual unshared amount may be reduced as a reward for rapid sharing. If the member fails to agree to share within 3 days (or some other time frame), then the member is not entitled to the reward of step 524. In either case, the sharing organization processes permission and transfers the share portion funds, according to step 526. The member wallet amount is updated through the communication portal 508. The member sharable amount is also updated, such as by updating the virtual bill account to reflect the receipt of funds which can be displayed through the communication portal 508 to the receiving member, according to step 528.

[0068] The sending member may not agree to share at step 518. When the sending member has failed to agree to send the share for more than 3 days (or other time based on time gate 530) or less than 6 days (or other time based on time gate 532), then the member is notified, according to step 514. If the member has failed to agree to a share for greater than 6 days, then the member is reassigned another member to share with according to step 534 as long as the sending member reassignment is less than 6 weeks (or other time based on time gate 532). If the sending member has failed to send a share for greater than 6 weeks (or other time based on time gate 532), then the sending member is inactivated, according to step 536.

[0069] The first share portion can be collected into a bill account, such as a virtual bill account. The virtual bill account funding is shown in flow chart form in FIG. 6. The sending members 602 who have been assigned to send shares send their funds 606. The sending members share the portion of the bill that is sharable according to the guidelines, according to step 608, and as determined by the allocation step. Once all of the sending members have completed the share sending process, then the virtual bill account is funded with the total shared amount, step 622. The receiving members 610 may also contribute funds 612 to the virtual bill account in the amount they are responsible for, according to the guidelines and step 614.

[0070] Receiving members 610 make a payment of funds 612 for the first medical expense bill to bill account 620. The amount of funds 612 from the plurality of receiving members 610 corresponds to the total sharable amount. The payment of funds from the bill account 620 to the provider 624 can depend on the receiving member triggering a single payment for the full amount of the bill, according to step 622. The step of making a payment of funds can also occur without member interaction after a predetermined period of time after a threshold amount of the funds are received into the bill account 620. For example, the payment can be initiated when the plurality of share amounts received from sending members 602 are received into the virtual bill account, the provider payment can be triggered to be sent. In this situation, the receiving member may be responsible to make a payment of funds from the bill account 620 and the remainder amount from a second source. The second source may be a bank account from which the receiving member has authority to initiate an electronic funds withdrawal. The bill account 620 may be owned by the first member. In another example, the payment can be initiated when the plurality of share amounts received from sending members 602 are received into the bill account 620 and the amount that the receiving member is responsible to contribute is received into the bill account 620, then the provider payment can be triggered to be sent. Upon fully funding the bill account, the payment of the funds from the bill account 620 to the provider 624 may be delayed for a predetermined amount of time. The user interface or the sharing program may allow the receiving member to prevent the payment of funds within that period of time.

[0071] FIG. 7 shows a second example interface for a user, such as a member, to interact with a health care sharing community. A user input device 702 having a display 703 displays a sender element 710 and a recipient element 712. The sender element 710 and the recipient element 712 are shown as a personalized image of the respective member, including the individuals of the member. The sender element and the recipient element can be displayed on the display device in a geographically representative manner, for example on a map 704 such as a map of the United States. For example, the sender element 710 can be placed on a map 704 in a location generally corresponding to their physical location, home location, church location or another location affiliated with sending member. Likewise, the recipient element 712 can be placed on a map 704 in a location generally corresponding to their physical location, home location, church location or another location affiliated with receiving member.

[0072] In order to approve a share transfer, the user input device 702 allows a sending member to activate a share approval component. The share approval component may be a button, text, graphic, or a share approval region 714 next to the recipient element 712, or a combination of these elements. The border of the share approval region 714 is shown by a dotted line. The border of the share approval region 714 may be invisible.

[0073] The display device 3 may display a share information section 705 containing information related to the share transfer, such as recipient name and share portion amount. The display 703 may display a prayer request related to the medical expense.

[0074] Activating a share approval component may require the sending member to move a transfer element 716 from a first position adjacent to the sender element 710 to a share approval region 714 near the recipient element 712. When the sender element and the recipient element are laid out geographically, the transfer element is moved by the sending member as if a package or envelope was being physically delivered. For example, the transfer element 716 can be moved from a position adjacent to the sender element 710 along path 718 to the share approval region 714. The sending member may release or place the transfer element within a radius around the recipient element 712 in order to trigger an approval signal to be communicated from the user input device 702 to the sharing organization.

[0075] It is understood that the invention is not confined to the particular construction and arrangement of parts herein described. That although the drawings and specification set forth a preferred embodiment, and although specific terms are employed, they are used in a description sense only and embody all such forms as come within the scope of the following claims.

[0076] The present disclosure is not to be limited in terms of the particular embodiments described in this application, which are intended as illustrations of various aspects. Many modifications and variations can be made without departing from its spirit and scope. Functionally equivalent methods and apparatuses within the scope of the disclosure, in addition to those enumerated herein, are possible from the foregoing descriptions. Such modifications and variations are intended to fall within the scope of the appended claims.

[0077] Generally, a computer-accessible medium may include any tangible or non-transitory storage media or memory media such as electronic, magnetic, or optical media—e.g., non-volatile memory chip, disk or compact disc (CD)/digital versatile disc-read only memory (DVD-ROM) coupled to computer system via bus. The terms “tangible” and “non-transitory” are intended to describe a computer-readable storage medium (or “memory”) excluding propagating electromagnetic signals, but are not intended to otherwise limit the type of physical computer-readable storage device that is encompassed by the phrase computer-readable medium or memory. For instance, the terms “non-transitory computer-readable medium” or “tangible memory” are intended to encompass types of storage devices that do not necessarily store information permanently, including for example, random access memory (RAM). Program instructions and data stored on a tangible computer-accessible storage medium in non-transitory form may further be transmitted by transmission media or signals such as electrical, electromagnetic, or digital signals, which may be conveyed via a communication medium such as a network and/or a wireless link.

[0078] For the convenience of the reader, the above description has focused on a representative sample of all possible embodiments, a sample that teaches the principles of the invention and conveys the best mode contemplated for carrying it out. Throughout this application and its associated file history, when the term “invention” is used, it refers to the entire collection of ideas and principles described; in contrast, the formal definition of the exclusive protected property right is set forth in the claims. The description has not attempted to exhaustively enumerate all possible variations. Other undescribed variations or modifications may be possible. Where multiple alternative embodiments are described, in many cases it will be possible to combine elements of different embodiments, or to combine elements of the embodiments described here with other modifications or variations that are not expressly described. A list of items does not imply that any or all of the items are mutually exclusive, nor that any or all of the items are comprehensive of any category, unless expressly specified otherwise. In many cases, one feature or group of features may be used separately from the entire apparatus or methods described. Many of those undescribed variations and modifications are within the literal scope of the following claims, and others are equivalent.