Abstract:
System and method for providing participants, and in particular employees, a choice of how to allocate their non-typical benefits, i.e. earned reward amounts or incentives of an employee wellness program, and to manage these additional benefits in conjunction with other employee benefit programs such as health benefits, retirement benefits, 401(k) plans etc. in a manner that provides maximum benefit, interaction, and understanding of selected benefit allocation. The system provides increased user control to increase the perceived value of the rewards earned as well as increase to the participants&#39; engagement in the behavior being incentivized. The system also provides a way to integrate various benefit programs providing a more user friendly and efficient system that encourages employee interaction and understanding.

Description:
CROSS REFERENCE TO RELATED APPLICATION 
     This application claims the benefit of and priority to U.S. Provisional Patent Application No. 61/590,214, filed Jan. 24, 2012, the entire disclosure of which is incorporated herein by reference. 
    
    
     FIELD OF INVENTION 
     The technology relates generally to allocation of financial incentives for employee wellness programs, and, more particularly, to systems, methods, and computer program products for implementing an allocation procedure. 
     BACKGROUND 
     Typically, an employer offers employees benefits such as health insurance, health savings and reimbursement accounts, defined contribution retirement accounts, etc. Recently, employers have also started offering non-traditional benefits, such as wellness programs, discounts and various memberships. Wellness programs are offered to employees for various reasons, such as to improve employee health, reduce employee sick days and health related conditions, reduce employee absenteeism reduce employee health care costs overall, improve employee at-work productivity and to continue to be able to provide affordable health care coverage to employees. Wellness programs can include offering incentives or rewards to employees that participate in wellness activities or achieve certain wellness criteria. Incentives can be offered for completing such activities as health risk assessments, prevention activities, behavior modification programs, chronic condition management (management of diabetes or other conditions) or participating in health education programs (e.g., health fairs, seminars, individual or group counseling, and even online health resources). Prevention activities can include such activities as visiting doctors regularly or using risk identification tools such as biometric screenings including blood-pressure, cholesterol levels, body mass index, etc., or imaging technologies. Behavior modification programs can include health coaching, tobacco cessation, weight management, nutrition and diet, joining a gym, regular exercise, and workplace competitions/contests, etc. An incentive can be tied to indicators of success such as an employee&#39;s participation in, progress during, and/or completion of a program, or an employee attaining a certain health benchmark. For many employers, these same types of wellness programs have also been made available to the employee&#39;s spouses as well so that their activities can earn corresponding incentives as well. 
     Employers have generally provided for the systematic administration of typical benefits, allowing employees to sign up for each individual benefit separately, and/or allowing employees to manage each benefit via the benefit&#39;s particular system or website. As employers have started to provide non-traditional types of benefits, such as the ability to earn incentives described above, employers have yet to provide an efficient approach for administering these benefits and/or an approach that gives the employees sufficient interaction and control. Such non-traditional benefits, generally are paid out as cash or as a health care premium reduction, suffer issues of haphazard administration by employers and under-utilization by employees. Additionally, employers and/or plan sponsors do not currently give participants a choice of how to allocate their earned reward amounts or incentives. These shortcomings are also enhanced by the fact that current processes lack the ability to be customized to match the needs or interests of each particular employee. There is a need to give participants a choice of how to allocate their earned reward amounts or incentives to both increase the perceived value of the reward as well as to increase the participants&#39; engagement in the behavior being incentivized. In addition, there is a need for an efficient system that allows the employee to manage his/her incentives in conjunction with other employee benefit programs such as health benefits, retirement benefits, 401(k) plans etc. in a manner that provides maximum benefit, appreciation, interaction, and understanding of a selected allocation of benefits. 
     SUMMARY OF THE INVENTION 
     The apparatus and methods consistent with this invention overcome the shortcomings and issues of typical systematic administration of benefits in the prior art by providing, in various embodiments, a system and process for allocating financial incentives for employee wellness programs. Allocation can be made to a pre-tax vehicle, such as a retirement plan or a health savings account (HSA), as well as other vehicles including cash, cash equivalent rewards, or health care premium reductions. Such additional allocation options provide the employee with the advantage of choosing which option is most valuable to the employee. For instance, one employee may choose to use earned incentives for their retirement plan while another employee may choose to obtain cash for their incentives to pay for health care costs such as co-pays or deductibles. 
     Defined contribution retirement plans include, but are not limited to, 401(k)&#39;s, ROTH 401(k)&#39;s, 403(b)&#39;s and traditional IRA&#39;s. Health savings and reimbursement accounts can include, but are not limited to, HSAs, health reimbursement account (HRAs), retiree health reimbursement accounts (RHRAs), retiree medical accounts (RMAs), and flexible spending accounts (FSAs). Eligibility for the HSA contributions is limited to employees enrolled in a high-deductible health care plan (HDHP). Furthermore, employee wellness programs, generally, do not provide employees with the control to select to which vehicle to assign their incentives. Instead, the vehicle is typically mandated by the employer&#39;s plan design rules. The technology herein alternatively enables the employee to control which vehicle(s) to assign their incentives. The terms “employee,” “participant,” “client” and “user” are used interchangeably throughout. The terms “reward” and “incentive” are used interchangeably throughout. The terms “system” and “tool” are used interchangeably throughout. 
     In one embodiment, a computing device can receive input about an employee receiving financial incentives for completing a wellness activity or about their eligibility to receive a financial incentive. Completing a wellness activity can include the employee&#39;s participation in an activity, progress within an activity, completion of a wellness activity, or attainment of a health benchmark associated with a wellness activity. The input received by the computing device can include an amount of the employee&#39;s financial incentive, salary information, tax rate information, retirement plan contribution information, HSA contribution elections, estimates for medical expenses, employer match information, a growth rate, age, years to retirement or other benefits program information. The computing device can also receive an indication of eligibility for vehicles to which a financial incentive can be assigned. The vehicles can include a pre-tax vehicle and at least one other vehicle. The pre-tax vehicle can be a retirement plan or a health savings account. In some embodiments, the pre-tax vehicle is a retirement plan, and the other vehicle is a health savings account, an after-tax retirement plan, a cash reward or cash equivalent, or a health care premium reduction. 
     The computing device can then determine the advantages of allocating the incentives to one vehicle or another. To do so, the computing device determines to which vehicles the financial incentive can be applied based on the indication of the employee&#39;s eligibility. In certain embodiments, the indication of eligibility is calculated by the computing device based on the input. In other embodiments, the indication of eligibility is provided via input about the employee&#39;s selected benefit programs and/or contribution information. In certain embodiments, a user interface can include a selection tool for assigning the financial incentive to the pre-tax vehicle or the at least one other vehicle. In other embodiments, the selection tool on the user interface can additionally divide the financial incentives between the pre-tax vehicle and the at least one other vehicle. The selection tool can be a slider, a series of radio buttons, or other means for receiving user input. Selection via the selection tool applying the financial incentives to vehicle are received by the computing device and in some embodiments can be provided to a benefits manager so that the financial incentives can be applied to the vehicle or vehicles as selected. The user interface can include a first section or window of the user interface for the selection tool and a second section or window of the user interface to provide information to the user indicating advantages for selecting each vehicle such as tax savings, and matching contributions. In certain embodiments, the user interface can also limit incentives being allocated to a certain account based on the plan rules and regulatory limits for limiting contributions to those accounts. In certain embodiments, the user interface includes a link that can be activated by the user. The link can provide information indicating advantages for selecting each vehicle. In one embodiment, the link can be a roll-over link that causes a pop-up window to appear, which includes text explaining the advantage. 
     In some embodiments, the advantages can be quantified, and the computing device can utilize the input to determine the advantages. An advantage can include a statement regarding potential growth of the amount of the financial incentive if the particular vehicle is selected and can include after-tax take home for the incentive. 
     In some embodiments, in addition to receiving, via the selection tool, a selection for applying the financial incentive, the computing device can receive updates to employee contributions for various vehicles in which the employee is participating. In one embodiment, such updated contribution selections can also be transmitted to a benefits manager so the contribution selections can be applied to the selected vehicle or vehicles. The benefits manager can be an employee of the employer, or can be benefits program management partner, such as an outside vendor. In other embodiments, such updated contribution selections can be transmitted to a record keeping system maintained by the corresponding benefit program. 
     In some embodiments, the computing device can receive input about the eligibility of an employee and receive an anticipated financial incentive amount for completing a wellness activity. The computing device can also receive an indication of eligibility for vehicles to which the anticipated financial incentive can be assigned. The vehicles can include a pre-tax vehicle and at least one other vehicle. The pre-tax vehicle can be a retirement plan or a health savings account. In some embodiments, the pre-tax vehicle is a retirement plan, and the other vehicle is a health savings account, an after-tax retirement plan, a cash reward or cash equivalent, or a health care premium reduction. The computing device can then determine which vehicles the anticipated financial incentive could be applied based on the indication of eligibility received. To do so, the computing device determines to which vehicles the financial incentive can be applied based on the indication of the employee&#39;s eligibility. In certain embodiments, the indication of eligibility is calculated by the computing device based on the input. In other embodiments, the indication of eligibility is provided via input about the employee&#39;s selected benefit programs and/or contribution information. In certain embodiments, the computing device provides a user interface that can include a selection tool for viewing the anticipated financial incentive as allocated to the pre-tax vehicle or the at least one other vehicle. In other embodiments, the selection tool on the user interface can additionally divide the anticipated financial incentives between the pre-tax vehicle and the at least one other vehicle. The selection tool can be a slider, a series of radio buttons, or other means for receiving user input. 
     Other aspects of the invention will become apparent from the following detailed description, taken in conjunction with the accompanying drawings, illustrating the principles of the invention by way of example only. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The foregoing and other objects, features, and advantages of the present invention as well as the invention itself, will be more fully understood from the following description of various embodiments, when read together with the accompanying drawings. 
         FIG. 1  is an overhead data flow diagram of one embodiment of the invention for updating and preserving data and employee selections. 
         FIG. 2  is a block diagram of one embodiment of the invention. 
         FIG. 3  is a detailed data flow diagram of another embodiment of the invention. 
         FIG. 4  shows an exemplary table of results, i.e. calculated possible outcomes by the computing device, given input received via an employee selection and/or vehicle databases. 
         FIG. 5A  illustrates one embodiment of the user interface with a sliding bar, in which the sliding bar is set to maximize the employee&#39;s take home pay and provides the calculated result based on input. 
         FIG. 5B  illustrates one embodiment of the user interface with a sliding bar, in which the sliding bar is set to maximize the employee&#39;s take home pay and a roll-over link is provided causing a pop-up window to appear, which explains the advantage of this vehicle selection. 
         FIG. 6A  illustrates one embodiment of the user interface with a sliding bar, in which the sliding bar is set to pay for the employee&#39;s out of pocket medical expenses and provides the calculated result based on input. 
         FIG. 6B  illustrates one embodiment of the user interface with a sliding bar, in which the sliding bar is set to pay for the employee&#39;s out of pocket medical expenses and a roll-over link is provided causing a pop-up window to appear, which explains the advantage of this selection. 
         FIG. 7A  illustrates one embodiment of the user interface with a sliding bar, in which the sliding bar is set to pay for the employee&#39;s medical expenses as well as save for retirement and provides the calculated result based on input 
         FIG. 7B  illustrates one embodiment of the user interface with a sliding bar, in which the sliding bar is set to pay for the employee&#39;s medical expenses as well as save for retirement, and a roll-over link is provided causing a pop-up window to appear, which explains the advantage of this selection. 
         FIG. 8A  illustrates one embodiment of the user interface with a sliding bar, in which the employee has selected to update contribution elections independent of benefit input received from a record keeping system thereby locking the sliding bar. 
         FIG. 8B  illustrates one embodiment of the user interface with a sliding bar, in which the employee has selected to update contribution elections independent of benefit input received from a record keeping system and additionally selected to model the employee&#39;s projected retirement balance. 
         FIG. 8C  illustrates one embodiment of the user interface with a sliding bar, in which the employee has de-selected to update contribution elections independent of benefit input received from a record keeping system thereby un-locking the sliding bar. 
         FIG. 9A  illustrates one embodiment of the user interface with a sliding bar, in which the sliding bar is set to maximize the employee&#39;s savings for retirement and provides the calculated result based on input. 
         FIG. 9B  illustrates one embodiment of the user interface with a sliding bar, in which the sliding bar is set to maximize the employee&#39;s savings for retirement, and a roll-over link is provided causing a pop-up window to appear, which explains the advantage of this selection. 
     
    
    
     DETAILED DESCRIPTION 
       FIG. 1  shows a high level data flow  100  according to one embodiment of the invention. The system gathers various inputs from various sources, including but not limited to, the user interface, selected databases, and/or other memory locations, with a goal of pre-calculating a set of results based on employee or user selections on a browser based application or user interface (UI) tool  270  for allocation of financial incentives and benefit contributions. When the tool is initiated by an employee, a signal is sent to the server  130  to gather data from connected benefit sources to provide financial incentives and benefit contribution information to the user via the user interface  270 . Once the data is gathered, financial incentives, benefit contribution, and matching contributions, are calculated for the employee. There is a finite number of calculations to be made based on the data gathered, which in turn provides a finite number of results. In one embodiment, these results are formulated into a table  400  that is then sent down to the browser  140 , where it can be loaded into the browser&#39;s  140  memory and cached so the results are then readily and easily accessible. In another embodiment, these results can be calculated and saved onto the user&#39;s computer to then be read from the user&#39;s computer memory. In this embodiment, as updates on the user interface  270  are made, results from the table  400  are sent to the browser  140 . In another embodiment, these results can be calculated and saved onto the employer&#39;s or benefit provider&#39;s resources. In this embodiment, as updates on the user interface  270  are made, results from the table  400  are again sent to the browser  140 . In any of these embodiments, as the user changes between scenarios on the user interface  270 , the browser can update information on the user interface  270  via information pulled from the table  400 . 
     In one embodiment, as the user updates fields that correspond to a selected scenario, such as a contribution amount, the browser  140  sends message updates to the cloud server  130  to update edited fields within the corresponding record keeping system  120 . These message updates subsequently result in an update transaction to the field&#39;s record on the record keeping system  120 . In one embodiment, the records are kept securely, i.e. the cloud server request to update a field must go through a back end server  110  to the record keeping system  120  as an extra layer of protection for stored personal data related to the user. After the record is updated in the record keeping system  120 , a message regarding a successful or unsuccessful update is sent back to the cloud server  130 , which in turn passes the message to the browser  140 . The browser  140  then displays the message regarding the success of the update to the user. As the actual data or records are kept on the record keeping system  120 , any edited data in a field on the user interface  270  that is not updated and recorded back to the record keeping system  120  is lost or deleted when the user exits the user interface  270  and/or the browser  140 . 
       FIG. 2  shows an in-depth overview  200  of one embodiment of the invention. As shown, the user interface  270  communicates with an optimization engine  260 . The optimization engine  260  gathers the data from the available sources  210 ,  220 ,  230 ,  270  to provide financial incentives and benefit contribution information to the user on the user interface  270 . It is understood that other sources of data may be available (i.e. may be incorporated into the system and interact with the tool) in addition to the databases  210 ,  220 ,  230  and user interface  270 . Once the optimization engine  260  gathers the data, the optimization engine  260  iterates through the possible scenarios given the data gathered (i.e. completes the finite number of calculations based on the data gathered) and produces a finite number of results. These results are loaded into a table to be provided (at  272 ) to the user interface  270  on the browser  140 . Inputs can be stored and/or retrieved from a database, or can be received as user input. In some embodiments, user input is received at the user interface  270  and sent (at  261 ) to the optimization engine  260  for determination of next action, calculations and/or storage. Outputs  272  from the optimization engine  260  are received at and displayed on the user interface  270 . The optimization engine outputs  272  include a combination of relayed inputs  241 ,  251  received from interacting databases  210 ,  220 ,  230  and calculations based on inputs  241 ,  251 ,  261  received from interacting databases  210 ,  220 ,  230  and the user interface  270 . The user interface  270  has the capability of requesting information (at  261 ) from the optimization engine  260 . Likewise, the optimization engine  260  has the capability of requesting information (at  272 ,  273 ,  274 ) from the databases  210 ,  220 ,  230  and the user interface  270 . 
     In one embodiment, inputs  250  from the Health and Welfare Administration Systems (HWAS) database  230  are collected (at  231 ) for the particular user and provided (at  251 ) to the optimization engine  260 . Such inputs can include information on an employee&#39;s healthcare plan type, healthcare plan details for single or family options, number of dependants, cost of plan per period, qualified payment amounts to healthcare providers, other benefit plan types, pensions, payroll, long term care insurance, life insurance, or any other healthcare or benefit information the employee has or has elected that is not otherwise kept in another database. Additionally, such inputs collected (at  231 ) from within the HWAS database  230  can be financial incentive information, anticipated financial incentive information based on eligibility, or rewards information such as total reward potential, type of reward earned, or amount of reward earned. Further, such inputs collected (at  231 ) from within the HWAS database  230  can be any prior election regarding healthcare or benefits information previously elected via the employee&#39;s scenario choices or customizations on the user interface  270  and saved back (at  261 ,  273 ) to the originating record keeping system  120  and/or the record keeping system  120  containing similar records for the user, i.e. the HWAS database  230 . 
     In one embodiment, inputs  240  from the Defined Contribution database (DC database)  220  are collected (at  221 ) for a particular employee and provided (at  241 ) to the optimization engine  260 . Such inputs  240  can include information from both the Defined Contribution Indicative Data (DCID)  223 , and the Contribution Limit Handler (CLH)  222 . Information in the DCID  223  can include the employee&#39;s individual participant data such as the employee&#39;s current 401(k) contribution and current Roth 401(k) contributions, i.e. the employee&#39;s 401(k) contribution elections. Information from the DCID  223  is provided to the CLH  222  in addition to being provided (at  241 ) to the optimization engine  260 . Additionally, any incentive information provided (at  251 ) to the optimization engine  260  is in turn relayed (at  274 ) to the CLH  222 . The CLH  222  further receives (at  211 ) information from the Plan Matching Rules database (PMA)  210  regarding the employee&#39;s contribution and matching rules. 
     In some embodiments, the PMA  210  provides the employee&#39;s specific contribution limitations as well as any rules or limitations imposed by the employee&#39;s plan or employer. Such rules can be with regard to the employee&#39;s potential incentives, matching contributions to the employee&#39;s own contributions as well as matching contributions to the employee&#39;s earned incentives. For example, the PMA  210  might provide (at  211 ) information such as the user&#39;s enrollment in a HDHP, the user&#39;s eligibility for HSA contributions dependant on the user&#39;s enrollment in a HDHP, the maximum allowable HSA amount based on the current knowledge of HSA deferral elections, HSA federal limits, the maximum allowable retirement amount based on retirement account limits, the matching potential of the user, i.e. the amount(s) that stop additional matching by the employer including any corresponding tier system, matching rules for other contributions, plan eligibility requirements, reward or incentive options, reward eligibility requirements, reward limitations, percentages taxable that are defaulted but can be altered by the user, and projected percentages for contributions that again are defaulted but can be altered by user selection. The CLH  222  in turn takes the input from the PMA  210 , the DCID  223  and/or the optimization engine  260  and calculates the matching contributions to the employee&#39;s existing 401(k) contributions, the matches to the employee&#39;s incentive amounts, and any other calculations relating to the limitations of such contributions or matches. Calculations from the CLH  222  as well as the information from the PMA and the DCID are collected (at  221 ) and provided (at  241 ) as DC Database inputs  240  to the optimization engine  260 . 
       FIG. 3  is a detailed flow diagram  300  of another embodiment of the invention. The flow diagram  300  demonstrates the user allocation process from user log-in  301  to user log-out  311 . It is understood that other sources of data for this process may be available (i.e. may be incorporated into the system and interact with the tool) in addition to the depicted databases  210 ,  220 ,  230  and user interface  270 . As shown more clearly in the flow diagram  300 , other databases  324  within the available databases  320  can be interconnected and interact with the system to provide additional data to the CLH  222  to calculate limits and matches  335  and/or can be interconnected and interact with the optimization engine  260  to calculate scenario results  336 . 
     In some embodiments, when the user logs into the web browser application  140  via the graphical user interface (GUI)  301 , the GUI  270  requests  302  data for display from the browser  140 . The browser  140  checks  303  whether the client has data loaded into the browser table from the record keeping system  120 . When the user initially logs in  301 , any data previously on the browser  140  was deleted when the previous user exited  311  the user interface  270 . Thus, no data exists at this stage of the process, and the request is relayed to the optimization engine  314  to request the client&#39;s data from the databases  320 . The optimization engine  260  then requests  314  data from the databases  320 , such as the HWAS database  230 ,  321 , the DC Database  220 ,  322 , the PMA  210 ,  323 , and any other interconnected and interacting databases  324 . Upon such request  314 , the databases  320  individually pull the related information for the client from their records  330 ,  331 ,  333 ,  334 . In some embodiments, this means the HWAS database  321  pulls healthcare plan data and incentive data for the client  330 ; the DC database  322  pulls contribution data for the client  331 ; the PMA  323  pulls the rules and matching limitations for the client  333 ; and the CLH  222  receives the client rules and limitations from the PMA  332  and calculates the limitations and matching potentials based on the rules from the PMA  335 . Relevant data for the client as pulled or calculated  330 ,  331 ,  333 ,  334 ,  335  is then provided to the optimization engine  260 , which calculates the possible results given the provided input  336 . These results are then formulated into a table and saved to the browser  337 . Receiving the table, the browser then provides the table to the GUI  270  for display on the GUI  304 . The GUI or user interface  270  reloads to display the new data  305 . The client can view the data and make scenario selections or edit fields as available within various scenarios. 
     In one embodiment, if the client makes a scenario selection  307 , the possible results have already been calculated  336  for the client via the data pulled from the databases  320 . As such, the data for the selected scenario can simply be retrieved from the browser table. Thus, upon a scenario selection, the browser locates the saved table  303  and sends the data for the scenario selected to the user interface  304 . The user interface is reloaded  305  to display the new scenario and corresponding data. If the user then selects to update their elections based on the selected scenario  308 , this selection  306  must be written back to the originating database(s) handling the election  312 . Thus, a selection to update given a selected scenario  306  can be relayed through the optimization engine  313  to the appropriate database  320 . If, however, the user selection  306  is an edit to a field within a scenario  309 , such as a contribution amount or incentive amount, this user edit requires the recalculation of data within the table  336 . Such a user selection  306  editing a field within the scenario sends the new field value back through the optimization engine  312  to the databases  320  for recalculation  335  given the newly edited field data. The new data is fed to the optimization engine again for recalculation of the results  336  and the table is reloaded to the browser  337 . The user interface is reloaded with the new results  303 - 305  to display the new data corresponding to the scenario and updated field value. 
     In this embodiment of  FIG. 3 , if the user selection  306  is not a scenario selection  307 , an update  308 , or a field edit  309 , the system assumes the selection is the client&#39;s selection to log out  310  and the client is logged out  311 . It is understood, however, that other user selections may be available on the user interface than those provided in the flow diagram  300 . Additionally, it is understood that in other embodiments, the system need not assume the selection is the client&#39;s selection to log out  310  if no other selection is apparent. 
       FIG. 4  shows an exemplary table  400  created by the optimization engine  260  and saved to the browser  337 . In addition,  FIG. 4  provides an example of data saved in the table as well as the functions or calculations performed by the optimization engine  260  according to one embodiment. The optimization engine  260  can be configured to perform any number of calculations  336  relating to allocation of financial incentives and benefit contributions. In one embodiment, the optimization engine  260  performs at least several functions, including using incentives to maximize take home pay, using incentives to pay for out of pocket medical expenses, using incentives to pay for medical expenses, apportion incentives to pay for medical expenses while also saving for retirement, and using incentives to maximize savings for retirement. 
     The function of maximizing take home pay provides the user with a scenario that maximizes the amount of money received from an incentive or reward. In one embodiment, this maximizing take home pay calculation can be configured to determine the amount of applicable taxes and provide the user with an amount of maximized take home pay that reflects the amount received after tax. The function of paying for out of pocket medical expenses provides the user the ability to apply their incentive or reward amounts toward various medical expenses. In some embodiments, this paying for out of pocket medical expenses can be configured to allocate the incentive towards deductibles, co-pays, co-insurance payments, or a combination of such payments. The optimization engine  260  can also provide the user the ability to apply incentives toward medical insurance or other insurance premiums as seen in the example table  400 . The function of paying for medical expenses while saving for retirement can be configured to apportion a percentage of the reward amount to cover medical expenses with the remaining percentage being applied to a retirement account. In one embodiment, the optimization engine  260  can be configured to calculate  336  the most beneficial percentages to apportion the retirement account and medical expenses based on the inputs from the databases  320  for this particular user. In another embodiment, the function of paying for medical expenses while saving for retirement can be configured to apportion equal percentages to the retirement account and to medical expenses. The function of maximizing the user&#39;s savings for retirement provides the user the ability to allocate their incentives to an HSA account, retirement account or some combination of such accounts. In one embodiment, the optimization engine  260  may provide the user the capability of allocating incentives towards their elected HSA contributions or 401(k) elected contributions. These functions, or additional ones, are calculated by the optimization engine  260  for the possible data entries, i.e. a finite number of calculations, the results of which are loaded into a table  400  and provided to the browser  304  for the user interface&#39;s ease of access upon user scenario selections. 
       FIGS. 5A-9B  provide views of an exemplary user interface for implementing the process for allocating financial incentives for employee wellness programs. One set of example data is used throughout these exemplary views. The financial incentive earned by the participant and available for allocation in this example is $250. In one embodiment, the user interface includes a scenario selection tool in the form of a slider bar which allows the user to select between scenarios, i.e. vehicles for allocation. Vehicles available are at least the optimization engine functions described above and are labeled in  FIGS. 5A-9B  as 1) Maximize My Take Home Pay, 2) Pay for Out-of-Pocket Medical Expenses, 3) Pay for Medical Expenses &amp; Save for Retirement, and 4) Maximize My Savings for Retirement. 
     In another embodiment, the user interface can be user friendly to encourage active participation from employees. In one such embodiment, the user interface can be user friendly by providing easy access to explanations of the different scenarios selectable by the user. For example,  FIG. 5A  shows a rollover link labeled “Explain this Scenario.” This rollover link can be configured to provide the user with easy access to an explanation of the scenario currently selected. In  FIG. 5B , the link has been activated and explains advantages of making the current scenario selection, i.e. explains the advantages of selecting Maximize My Take Home Pay. In this embodiment, the user interface is also user friendly by calculating the take home reward amount after-tax for this incentive allocation as shown in  FIGS. 5A-5B . When the user has viewed the vehicle&#39;s advantages and wishes to select the scenario  306  and save that scenario to their records  308 , the user can update their records by selecting the “Choose This Scenario” button as shown in  FIG. 5A-9B . 
       FIGS. 6A and 6B  show the scenario selection tool moved to “Pay for Out-of-Pocket Medical Expenses.” Upon the user&#39;s selection  306  via the sliding bar, the user interface  270  requests (at  272 ) new data corresponding to the selection  307 . The data previously saved into the browser table  337  by the optimization engine  260  is accessed  304 , and the user interface is reloaded  305  with data corresponding to the new scenario selection, i.e. the Pay for Out-of-Pocket Medical Expenses scenario given the data provided. As explained by the user friendly “Explain this Scenario” rollover link, activated in  FIG. 6B , the user uses this vehicle to maximize the payment of their medical expenses by contributing the earned incentive of $250 to their HSA. 
       FIGS. 7A to 7B  show the scenario selection tool moved to “Pay for Medical Expenses &amp; Save for Retirement.”  FIG. 7A  specifically shows how incentives allocated to the retirement savings result in a company match. Upon the user&#39;s selection  306  via the sliding bar, the user interface  270  requests (at  272 ) new data corresponding to the selection  307  of scenario Pay for Medical Expenses &amp; Save for Retirement. The data previously saved into the browser table  337  by the optimization engine  260  is accessed  304 , and the user interface is reloaded  305  with data corresponding to the new scenario selection given the data provided. As explained by the user friendly “Explain this Scenario” rollover link, activated in  FIG. 7B , the user has contributed the earned incentive of $250 by allocating half of their incentive, or $125, to their medical expenses via their HSA and the other half of the user&#39;s incentive to the user&#39;s retirement savings via the user&#39;s 401(k). Moreover, as shown in  FIG. 7A , the user&#39;s contribution of $125 to their retirement savings has resulted in an employer match of $125 such that the total amount allocated to the retirement savings is $250.  FIG. 7B  also shows the calculated value of the employer&#39;s match to the user&#39;s 401(k) contribution, which is made available to the user by apportioning part of the user&#39;s incentive to the user&#39;s retirement savings. In one embodiment, the user interface is informative by providing the user a projected growth model of the allocation to retirement for the user&#39;s contribution given a projected retirement age and projected growth rate. In one such embodiment, exemplified in  FIG. 7B , the user interface is user friendly by allowing the user to select, via a radio button, whether the user wants to view the projected retirement balance and allows the user to input their desired retirement age and growth rate percentage.  FIG. 7B  shows this radio button, entitled “Model My Projected Retirement Balance,” selected such that the projected retirement balance, retirement age, and projected growth rate are viewable by the user.  FIG. 8A  shows this Model radio button being unselected such that the projected retirement balance, retirement age, and projected growth rate are no longer viewable to the user. 
       FIGS. 8A-8C  show use of the “Let me select for myself” (i.e., select myself) radio button. In another embodiment, the user interface can be made more user friendly and engage the user further by allowing the user to determine how much of their incentive to allocate to each vehicle. By allowing the user to select these values themselves, i.e. inputting contributions amounts directly into the system via the user interface rather than the values being provided by the databases  320 , the user further benefits from the system by viewing the direct results of increasing or decreasing their contribution amounts to various vehicles. As shown in  FIG. 8A , when the user selects the select myself radio button, the slider bar is locked on the selected scenario and the allocation boxes for Premium Reduction, HSA Contribution and 401(k) Contribution become editable so the user can adjust these amounts directly for this scenario. Additionally, as shown in  FIG. 8B  this select myself radio button selection also allows the user to adjust the retirement age and growth rate, if the Model radio button is also selected. When the select myself radio button is selected  306 , and the user independently inputs the incentive amounts allocated to each vehicle  309 , the user must update these values  308 , via the “Choose This Scenario” button, to save these elections  312 - 313 . If the inputs are not updated, the inputs may be lost if the user exits the browser or user interface  310 ,  311 , in which case the values on the user interface  270  when the user logs into the system again  301  are the previous or defaulted values pulled from the databases  330 - 334 . If, however, the user selects to update these values  309  to their records  308  via the “Choose This Scenario” button, these values  309  are written back to the corresponding database  312 . The next time the optimization engine  260  accesses data from the databases  314 - 320 , the data pulled  330 - 335  is the updated data saved back to the databases  320 . 
     When the select myself radio button is again deselected, as shown in  FIG. 8C , the user interface unlocks the slider bar so that the user can again select amongst the various vehicles for allocating their incentives. Additionally, the contribution amounts become un-editable and are again determined by the data pulled from the table stored on the browser  337 . 
       FIGS. 9A and 9B  show the selection tool moved to “Maximize My Savings for Retirement.”  FIG. 9A  again shows that an employer match is available if at least a portion is allocated to retirement. Using this vehicle, the user only contributes to retirement accounts as seen by the $0 amounts in the medical HSA and take home pay fields. In  FIG. 9A , the Model radio button is selected so that the projected retirement age and growth rate are shown and used to calculate the projected growth model of the allocation to retirement. In  FIG. 9B , the rollover link has been activated and the advantages of this scenario selection are displayed for the user to aid in the user&#39;s understanding of this selection. 
     The above-described techniques can be implemented in digital and/or analog electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. The implementation can be as a computer program product, i.e., a computer program tangibly embodied in a machine-readable storage device, for execution by, or to control the operation of, a data processing apparatus, e.g., a programmable processor, a computer, and/or multiple computers. A computer program can be written in any form of computer or programming language, including source code, compiled code, interpreted code and/or machine code, and the computer program can be deployed in any form, including as a stand-alone program or as a subroutine, element, or other unit suitable for use in a computing environment. A computer program can be deployed to be executed on one computer or on multiple computers at one or more sites. 
     Method steps can be performed by one or more processors executing a computer program to perform functions of the invention by operating on input data and/or generating output data. Method steps can also be performed by, and an apparatus can be implemented as, special purpose logic circuitry, e.g., a FPGA (field programmable gate array), a FPAA (field-programmable analog array), a CPLD (complex programmable logic device), a PSoC (Programmable System-on-Chip), ASIP (application-specific instruction-set processor), or an ASIC (application-specific integrated circuit), or the like. Subroutines can refer to portions of the stored computer program and/or the processor, and/or the special circuitry that implement one or more functions. 
     Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital or analog computer. Generally, a processor receives instructions and data from a read-only memory or a random access memory or both. The essential elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and/or data. Memory devices, such as a cache, can be used to temporarily store data. Memory devices can also be used for long-term data storage. Generally, a computer also includes, or is operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks. A computer can also be operatively coupled to a communications network in order to receive instructions and/or data from the network and/or to transfer instructions and/or data to the network. Computer-readable storage mediums suitable for embodying computer program instructions and data include all forms of volatile and non-volatile memory, including by way of example semiconductor memory devices, e.g., DRAM, SRAM, EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto-optical disks; and optical disks, e.g., CD, DVD, HD-DVD, and Blu-ray disks. The processor and the memory can be supplemented by and/or incorporated in special purpose logic circuitry. 
     To provide for interaction with a user, the above described techniques can be implemented on a computer in communication with a display device, e.g., a CRT (cathode ray tube), plasma, or LCD (liquid crystal display) monitor, for displaying information to the user and a keyboard and a pointing device, e.g., a mouse, a trackball, a touchpad, or a motion sensor, by which the user can provide input to the computer (e.g., interact with a user interface element). Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, and/or tactile input. 
     The above described techniques can be implemented in a distributed computing system that includes a back-end component. The back-end component can, for example, be a data server, a middleware component, and/or an application server. The above described techniques can be implemented in a distributed computing system that includes a front-end component. The front-end component can, for example, be a client computer having a graphical user interface, a Web browser through which a user can interact with an example implementation, and/or other graphical user interfaces for a transmitting device. The above described techniques can be implemented in a distributed computing system (e.g., a cloud-computing system) that includes any combination of such back-end, middleware, or front-end components. The above described techniques can be implemented as a Software-As-A-Service (SaaS) model or using a multi-tiered approach. 
     Communication networks can include one or more packet-based networks and/or one or more circuit-based networks in any configuration. Packet-based networks can include, for example, an Ethernet-based network (e.g., traditional Ethernet as defined by the IEEE or Carrier Ethernet as defined by the Metro Ethernet Forum (MEF)), an ATM-based network, a carrier Internet Protocol (IP) network (LAN, WAN, or the like), a private IP network, an IP private branch exchange (IPBX), a wireless network (e.g., a Radio Access Network (RAN)), and/or other packet-based networks. Circuit-based networks can include, for example, the Public Switched Telephone Network (PSTN), a legacy private branch exchange (PBX), a wireless network (e.g., a RAN), and/or other circuit-based networks. Carrier Ethernet can be used to provide point-to-point connectivity (e.g., new circuits and TDM replacement), point-to-multipoint (e.g., IPTV and content delivery), and/or multipoint-to-multipoint (e.g., Enterprise VPNs and Metro LANs). Carrier Ethernet advantageously provides for a lower cost per megabit and more granular bandwidth options. 
     Devices of the computing system can include, for example, a computer, a computer with a browser device, a telephone, an IP phone, a mobile device (e.g., cellular phone, personal digital assistant (PDA) device, laptop computer, electronic mail device), and/or other communication devices. The browser device includes, for example, a computer (e.g., desktop computer, laptop computer, mobile device) with a world wide web browser (e.g., Microsoft® Internet Explorer® available from Microsoft Corporation, Mozilla® Firefox available from Mozilla Corporation). 
     One skilled in the art will realize the technology may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. The foregoing embodiments are therefore to be considered in all respects illustrative rather than limiting of the technology described herein. All changes that come within the meaning and range of equivalency of the claims are therefore intended to be embraced therein.