Patent Publication Number: US-7908179-B2

Title: Electronic gift linking

Description:
This application is a continuation of U.S. patent application Ser. No. 10/010,068, filed Dec. 6, 2001 now U.S. Pat. No. 7,266,533, entitled “ELECTRONIC GIFT GREETING”, which claims the benefit of U.S. patent Ser. No. 09/737,912 now abandoned entitled “ONLINE METHOD AND SYSTEM FOR ORDERING AND HAVING DELIVERED A PAPER GREETING MESSAGE AND PAYMENT INSTRUMENT,” and of U.S. Provisional Patent Application No. 60/256,127, entitled “ELECTRONIC GIFT GREETING,” both filed on Dec. 15, 2000; each of the above applications is hereby incorporated by reference in their entirety for all purposes. 
    
    
     BACKGROUND OF THE INVENTION 
     This invention relates in general to greeting cards and, more specifically, to electronic greeting cards. 
     Electronic greeting cards (eCards) are analogous to paper greeting cards, but are available only on computers in electronic form. These eCards are available from web sites such as BlueMountain.com™. An eCard is usually sent by an e-mail message that invites the recipient to execute a program or applet that displays a greeting that could be animated or could include a personalized message. 
     With paper greeting cards, the sender may accompany the card with a gift commensurate with the occasion as is customary in some cultures. It is known to also include cash, a check or gift certificate along with the paper greeting card to serve as the gift. Electronic greeting cards provide no mechanism for including a gift with the card. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The present invention is described in conjunction with the appended figures: 
         FIG. 1  is a block diagram of an embodiment of an on-line greeting and gift system; 
         FIG. 2  is a block diagram of an embodiment of an online money transfer system; 
         FIG. 3  is a block diagram of an embodiment of a payment enabler; 
         FIG. 4  is a block diagram of an embodiment of an electronic greeting card site; 
         FIG. 5  is a block diagram of an embodiment of an agent location; and 
         FIG. 6  is a flow diagram of an embodiment of a process for sending an electronic greeting card (eCard) that may include an electronic gift; 
         FIG. 7  is a flow diagram of an embodiment of a process for paying-in money to the payment enabler; 
         FIG. 8  is a flow diagram of an embodiment of a process for paying-out the electronic gift from the payment enabler; 
         FIG. 9  is a flow diagram of an embodiment of a process for configuring a user with an account for the online money transfer system; 
         FIG. 10  is a flow diagram of an embodiment of a process for transferring money from the sender to the receiver; and 
         FIGS. 11A and 11B  are a flow diagram of an embodiment of a process for moving money out of a stored value fund for a receiver. 
     
    
    
     In the appended figures, similar components and/or features may have the same reference label. Further, various components of the same type may be distinguished by following the reference label by a dash and a second label that distinguishes among the similar components. If only the first reference label is used in the specification, the description is applicable to any one of the similar components having the same first reference label irrespective of the second reference label. 
     DESCRIPTION OF THE SPECIFIC EMBODIMENTS 
     The ensuing description provides preferred exemplary embodiment(s) only, and is not intended to limit the scope, applicability or configuration of the invention. Rather, the ensuing description of the preferred exemplary embodiment(s) will provide those skilled in the art with an enabling description for implementing a preferred exemplary embodiment of the invention. It being understood that various changes may be made in the function and arrangement of elements without departing from the spirit and scope of the invention as set forth in the appended claims. 
     The present invention provides an apparatus and method for embedding electronic gifts in electronic greeting cards (eCards). A sender of the eCard can select the electronic gift during the eCard creation process. The receiver redeems the electronic gift after receiving it in the card. Electronic gifts could include a credit in a stored value fund, a foreign currency credit in the stored value fund, a prepaid credit or debit card, a prepaid phone card, promotional points, airline mileage credits, a gift certificate for one or more retailers, and a separately delivered negotiable instrument. The prepaid credit or debit cards are backed by a credit card company and are usable like a credit card for purchases up to a specified amount. For example, a $50 MasterCard™ prepaid credit card could be issued that is good for any goods or services offered by a merchant that accepts MasterCard™ until the $50 credit is spent. 
     Referring first to  FIG. 1 , a block diagram of an embodiment of an on-line greeting and gift system  100  is shown. Included in the system  100  are an eCard site  140 , an online money transfer system  190 , a sender  110 , and a receiver  130 . Respective computers  120  interface the sender  110  and receiver  130  to the Internet  150  or other wide area network such that they can interact with the eCard site  140  and the money transfer system  190 . Money handlers  160 , a payment enabler  170  and user interfaces  180  make up the money transfer system  190 . 
     The eCard site  140  is a web site on the Internet  150  and may include servers and other computers as is well known in the art. The sender  110  points their browser to the eCard site  140  to choose an eCard to send to the receiver  130 . Although this embodiment shows the eCard site  140  being separate from the money transfer system  190 , other embodiments could combine these into the same location or spread portions among any number of locations. 
     The transfer system  190  works in concert with the eCard site  140  to provide the electronic gift for embedding in the eCard. Also, the receiver  130  may interact with the transfer system  190  to payout the electronic gift. In some cases, the sender  110  chooses a type of electronic gift that does not require the receiver  130  to interact with the transfer system  190 , such as with a gift certificate. Money handlers  160  are used to payin money used for the electronic gift or payout gifts of money. The user interfaces  180  provide a variety of ways for the sender and receiver  110 ,  130  to interact with the transfer system  190 . 
     With reference to  FIG. 2 , a block diagram of an embodiment of an online money transfer system  190  is shown. In this embodiment, six handlers  160  and five user interfaces  180  are shown. Other embodiments could have more or less handlers  160  and interfaces  180 . Each of the handlers  160  allows a sender or receiver  110 ,  130  to add and/or remove money from the payment enabler  170 . Normally, the receiver  130  can choose the handler  160 , but in some circumstances, the sender  110  can choose the handler  160 . For example, the sender may specify a particular gift certificate handler  160 - 6  that only allows the certificate to be used at a particular store for merchandise and/or services. The user interfaces  180  allow interaction with the payment enabler  170  to transfer money to and from a stored value fund. 
     The promotion handler  160 - 1  allows adding and removing money in a form other than legal tender or negotiable instrument. Examples include airline mileage programs, prepaid phone cards. For example, a user could use money in their stored value fund to purchase airline miles with an airline mileage handler  160 - 1 . A conversion rate would be applied to convert the money to mileage credit. The promotion handler  160 - 1  may need special information from the payment enabler  170 , such as the user&#39;s promotion account number, etc. Some of the interfaces  180  used to gain access to the payment enabler  170  could be used to also gain access to the eCard site  140  to allow ordering a eCard with an embedded gift where a computer  120  may not be readily available to the sender  110 . 
     The credit and debit card handlers  160 - 2 ,  160 - 3  behave largely the same. Both can be used to add money into the payment enabler  170 . In other embodiments, these handlers  160 - 2 ,  160 - 3  can also be used to remove money from the payment enabler  170  also, for example, to purchase a prepaid credit/debit card, to pay down a balance on a credit card, or to add credit to a bank account associated with a debit card. To use these handlers  160 - 2 ,  160 - 3 , the payment enabler  170  stores the information for receiving money from credit or debit cards in the conventional way, such as the account number, expiration date, name, and/or PIN. Similar information may be used when paying-out money to a credit/debit card. 
     The bank handler  160 - 4  allows electronic funds transfer (EFT) of money to a bank account of the user. The user enters the account number and routing information into the payment enabler  170  with a user interface  180  to facilitate adding and removing of money from the payment enabler with this handler  160 - 4 . In one embodiment, an automated teller machine (ATM) could incorporate the bank handler  160 - 4  along with an ATM interface  180 - 1  to allow adding and removing funds along with interfacing with the payment enabler  170 . Another embodiment uses a bank handler  160 - 4  branch location as an agent interface  180 - 4  for interacting with the payment enabler  170 . Some embodiments could wire money into a bank account of the user instead of an EFT. 
     The agent handler  160 - 5  typically corresponds to an agent location  500  that may wire money, print money orders and/or cash checks. Money may be sent to the agent handler  160 - 5 , whereafter the user is issued cash or a negotiable instrument for that money. Money can be added to the system  100  by the agent handler  160 - 5  also. For example, the user may give cash to the agent who enters a credit into the payment enabler. The user could further specify to the agent a receiver who should get the money. An agent interface  180 - 4  at the agent location  500  is used by the agent to indicate to the payment enabler  170  that the money has been received from or by the user. Through an agent handler  160 - 5  a sender  110  could use the online money transfer system  100  without any knowledge of computers or without any debit/credit card or bank account. 
     Gift certificates are dispensed through one or more gift certificate handlers  160 - 6 . The gift certificate can be limited to merchandise and/or services from a single store or a group of stores. In some cases, the gift certificate is used only online by entering a code provided to the receiver or could be printed for use in a bricks and mortar store. Cash equivalents such as Flooz™, formerly available from Flooz.com, could also be provided to the receiver  130 . 
     As briefly discussed above, the ATM interface  180 - 1  allows interaction with the payment enabler  170 . The user may  110 ,  130  or may not have an affiliation with the ATM that is used to interface with the payment enabler  170 . Under this circumstance, the owner of the ATM may charge the user a fee for this service. The user  110 ,  130  can receive cash or deposit cash if the ATM is coupled to a bank handler  160 - 4 . In any event, the ATM interface  180 - 1  can be used to interface with the payment enabler  170  in the same way a user  110 ,  130  may interact through a web browser and computer  120  with the payment enabler  170 . If the ATM has a magnetic stripe or smart card reader, this could be used by to avoid entering credit or debit card information manually for the payment enabler  170 . 
     A kiosk interface  180 - 2  allows a user to interact with the payment enabler  170 , but typically does not allow adding or removing cash. The kiosk interface  180 - 2  may be a browser terminal available for general use. Some embodiments may include a check or money order printer for removing money from the system  100 . The kiosk interface  180 - 2  could be in an agent location  500  and linked to the other systems in the agent location  500  such that a payout could be provided by other systems in the agent location  500 . 
     An Internet interface  180 - 3  is typically implemented through a web browser. The browser downloads web pages from the payment enabler  170 . The Internet interface could be hosted by the computer  120  of the user. Some embodiments could host the Internet interface on a portable device such as a wireless phone or personal digital assistant (PDA). The Internet interface  180 - 3  may also be used by the ATM, kiosk and agent interfaces  180 - 1 ,  180 - 2 ,  180 - 4  in whole or in part. The Internet interface  180 - 3  uses encryption for the link to the payment enabler  170  in some embodiments. 
     The agent interface  180 - 4  allows for specialized interaction by an agent at the agent location  500 . Agents typically have special training and offer enhanced services over most interfaces  180  and handlers  160 . The agent can move money between senders  110  and receivers  130  at the direction of the user. Also, the agent can pay-in and pay-out money from the transfer system  100 . The agent interface  180 - 4  allows an agent to act on behalf of the user when manipulating the user&#39;s account. For security, the user&#39;s password or PIN may be entered during this manipulation. Further, the agent may verify the identity of the receiver  130  before disbursing the electronic gift. In one embodiment, a test question is provided by the sender  110  that the receiver  130  must answer before the electronic gift is paid-out. 
     Interaction with the payment enabler  170  may also be performed over a telephone  140  interfaced to the plain-old telephone system (POTS)  155 . The phone interface  180 - 5  provides voice prompts and recognizes the user&#39;s touch-tone or speech recognized input. Enhanced interaction with the phone interface  180 - 5  could be provided with wireless phones having wireless access protocol (WAP) and/or browser graphical user interfaces (GUIs). 
     Referring to  FIG. 3 , a block diagram of an embodiment of a payment enabler  170  is shown. The transfer of money between handlers  160 , stored value funds and users  110 ,  130  is controlled by the payment enabler  170 . The payment enabler  170  may be implemented on one or more computers in one or more locations where the various computers communicate over a network. Included in the payment enabler  170  are a payment controller  304 , handler interfaces  308 , a billing function  312 , a messaging function  316 , an enabler interface  320 , a user database  324 , a payment conversion function  328 , and an exchange rate database  332 . 
     The payment controller  304  manages operation of the payment enabler  170 . The handlers  160  and interfaces  180  along with user information and money conversion tasks are all choreographed by the payment controller  304 . The payment controller  304  is interconnected to the other portions of the payment enabler  170  by one or more networks. 
     The payment conversion function  328  allows converting between disparate forms of money as it is transferred through the transfer system  190 . An exchange rate database  332  holds conversion factors that allow determining the proper weight to give one form of money with respect to the others. In one example, the payment conversion function  328  may convert money in U.S. dollars to money in European Union Euros. In another example, a user may convert money into airline miles of eight miles for every dollar for a promotion handler  160 - 1 . The exchange rate database  332  is updated with conversion rates as often as practical using conventional methods. The conversion rate may accommodate a percentage service fee for the exchange, or instead of a conversion rate, a flat fee could be charged. 
     A billing function  312  monitors and charges for the services of the payment enabler  170 . There may be charges when transferring money, converting money, sending electronic gifts, printing and mailing negotiable instruments, using kiosks, ATMs or agent locations, etc. These charges are normally deducted from a transfer, but other embodiments could charge monthly fees. Some embodiments could recover a fee from the handler  160 , for example, a fee could be charged to the gift certificate target store instead of charging the sender  110 . The different types of handlers  160  may have different fees associated with them. For example, a credit card may have a three percent charge, but a bank transfer may only have a one percent charge. The sender and/or the receiver can be charged to transfer money between themselves. The transfer in or out of the system  100  may incur a separate charge. The billing function  312  may issue invoices for some users. 
     There are handler interfaces  308  to support the various handlers  160 . Each of these interfaces  308  may support a single handler  160  or a group of handlers. For example, a single interface may perform EFT both to and from all bank handlers  160 . When money is sent to or received from a handler  160 , the appropriate handler interface  308  passes the money and transfer information to the payment controller. In some embodiments, the cost of the transfer to or from the handler is reported by the handler interface  308  such that the billing function can recover those costs. 
     Information for the users of the system  100  is stored in the user database  324 . This information includes an address book of other users, money credit in the stored value fund, past money transfer information, account number, e-mail addresses, contact information, handler interface information, handler preference information, etc. The money credit is stored in a trust account for the benefit of the user according to the entry in the user database  324  corresponding to that user and interest may or may not be paid on that money credit. 
     The enabler interface  320  is used by the various interfaces  180  to interact with the user. The enabler interface  320  produces the form web pages and informational web pages to allow the user to create and maintain their account, transfer money, select electronic gifts, and learn to use the system  100 . The appropriate user interface  180  formats and processes the enabler interface information according to the device used to interface with the payment enabler  170 . For example, the Internet interface  180 - 3  takes the information from the enabler interface  320  and formats into hypertext mark-up language (HTML) appropriate for the computer  120  of the user. 
     A messaging function  316  is used with some configurations to notify the user of certain events. Requests for money are sent by the messaging function  316  along with acknowledgment and billing messages. These messages could be accessed using a web browser, an e-mail program, an instant messaging program, a pager, a WAP enabled device, etc. In some embodiments, the messaging function  316  may issue printed bills for users. The messaging function  316  is also used to communicate with agent locations  500  and with the eCard site  140 . 
     With reference to  FIG. 4 , a block diagram of an embodiment of an eCard site  140  is shown. The eCard site  140  works in concert with the money transfer system  190  to allow embedding electronic gifts for those senders wishing to include a gift with the eCard. The eCard site includes a site controller  404 , a web interface  408 , a user database  416 , a greeting card database  412 , and a payment enabler interface  420 . 
     The site controller  404  manages the functions of the eCard site  140 . The web interface  408  allows interaction with information in the greeting card database  412  and user database  416 . Both the sender and receiver  110 ,  130  interact with the web interface  408  to either send or receive the eCard. The possible eCards the sender might select are stored in the greeting card database  412 . Any account information on the sender and receiver  110 ,  130  is stored in the user database  416 . The user database  416  also stores the chosen eCard with any customizations for the benefit of the receiver  130 . When the receiver provides the e-mailed code to the web interface  408 , the eCard is retrieved and displayed. The code is used by the payment enabler to reference the electronic gift chosen by the sender  110 . In some embodiments, the code may embed details of the electronic gift or other information. 
     When the sender or receiver  110 ,  130  works with the electronic gift function, the web interface hands them off to the transfer system  190 . The enabler interface  420  facilitates the communication between the eCard site  140  and the transfer system  190  such that the user  110 ,  130  is provided with a seamless experience. User information is passed by the payment enabler interface  420  to the messaging function  316  of the transfer system  190 . Through that same pathway, information on the selected electronic gift is provided to the eCard site  140 . 
     Referring to  FIG. 5 , a block diagram of an embodiment of an agent location  500  is shown. Both the agent and kiosk interfaces  180 - 2 ,  180 - 4  are coupled to a wide area network  504  that is coupled to the payment enabler  170 . The agent location  500  may be used as an agent money handler  160 - 5  to accept and disperse money in the form of check, money order, cash, gift certificate, etc. 
     The kiosk interface  180 - 2  is primarily intended for users to interact with, and the agent interface  180 - 4  is primarily intended for agents to interact with. In some embodiments, both interfaces  180 - 2 ,  180 - 4  are used to perform a transfer. For example, the agent may use the agent interface  180 - 4  to perform the transfer while the kiosk interface  180 - 2  is used to monitor the agent&#39;s actions and enter a password or PIN that is kept secret from the agent. The kiosk interface  180 - 2  may also be used to perform a complete transfer in circumstances where the user  110 ,  130  is trained to use the system  100 , but does not utilize other interfaces  180  for whatever reason. 
     The agent interface  180 - 4  and kiosk interface  180 - 2  can output a negotiable instrument with a printer  512 . Examples of negotiable instruments include money orders, cashiers checks, tellers checks, certified checks, checks, gift certificates, coupons, etc. In some embodiments, each interface  180 - 2 ,  180 - 4  may have a separate printer. The printer  512  may also be used to print receipts and messages related to the transfer of money. 
     Money can be added to or removed from the system  100  at the agent location  500  with money distribution devices  508 ,  516 ,  520 . In the conventional manner, cash can be received by the cash register, credit or debit cards and be debited by the card terminal  508 , and checks can be confirmed with a check validation terminal  520 . Cash can be paid out from the cash register  516  or added to a credit or debit card by the card terminal  508  in a conventional fashion. These money distribution devices  508 ,  516 ,  520  all interface with the system  100  by way of the agent interface  180 - 4  such that pay-outs and pay-ins can be automatically recorded by the payment enabler  170 . 
     With reference to  FIG. 6 , a flow diagram of an embodiment of a process  600  for sending an eCard that may include an electronic gift is shown. The depicted portion of the process  600  begins in step  604  where the sender  110  interacts with the web interface  408  of the transfer system  190  to select the eCard. In step  608 , the sender  110  enters the e-mail address, name, and any customizations to the eCard. These entries are stored in the user database  416 . Where there is no electronic gift enclosed, the eCard is sent in step  624  and read in step  628 . 
     Where the sender decides to include an electronic gift in step  612 , processing continues to step  616  where the sender  110  is handed-off to the payment enabler  170 . Any user information is passed by the payment enabler interface  420  to the messaging function  316  of the payment enabler  170 . This information is used to pre-populate any forms presented to the sender or later to the receiver  110 ,  130 . In step  620 , the money is paid into the payment enabler  170  to pay for the electronic gift. If more work is required on the eCard, the sender  110  could be passed back to the eCard site  140 . 
     If the eCard creation process is complete, the eCard is sent by e-mail or other electronic methods to the receiver in step  624 . In step  628 , the receiver  130  opens the email message and clicks on a link in the e-mail to open a browser window directed at the web interface  408  of the eCard site  140 . If an electronic gift is included in the eCard as determined in step  632 , an icon or button appears in the eCard that is clicked to direct the receiver  130  to a screen that informs the receiver  130  of the gift. This screen could include another message, information on the electronic gift, advertisements, and/or other information. The screen may give all the information necessary for redeeming the electronic gift. For example, another button may be presented entitled “redeem your gift certificate” that would forward the user to the target merchant(s) for the gift certificate. To verify identity, the target merchant would require the e-mail address for the eCard be used to configure an account. Where money is available from a stored value fund on the payment enabler  170 , the receiver  130  is invited to create an account where there is none. 
     Referring to  FIG. 7 , a flow diagram of an embodiment of a process  620  for paying-in money to the payment enabler  170  is shown. To pay for the electronic gift, money is transferred from a money handler  160  of the sender  110  to a stored value fund  744  of the receiver  130 . The stored value fund may be used only once to pay for the present gift or could be used any number of times by the receiver  130 . The stored value fund is identified by the e-mail address of the receiver  130 , among other ways. If a fund already exists, it may be used for the present transaction. There are two ways in the process  620  to fund the payment enabler  170 . The first starts in step  704  and is done through the Internet  150  or other electronic means and the second starts in step  728  and is done at an agent location  500 . 
     Referring initially to the first way, which starts in step  704 , the sender  110  logs into the enabler interface  320  after being handed-off from the eCard site  140 . In some embodiments, the sender  110  may be automatically logged in based upon information from the eCard site  140 . Depending on the situation, the sender may or may not need to open an account with the payment enabler  170 . Where the sender doesn&#39;t need an account for the electronic gift, the sender is said to remain “external” to the transfer system  190 . If an account is required as determined in step  708 , an account is opened in step  712  if there is none. For external transactions, money handler information is provided in step  716 . 
     An identifier is entered for the receiver in step  720 , although this step could be automatically performed with information from the eCard site. The identifier in this embodiment is the e-mail address of the receiver  130 , but other identifiers could also be used in other embodiments. In step  724 , the sender is given options for the electronic gifts and the prices associated with each. The prices may include any service fees. The money is moved from the specified money handler  160  to the stored value fund of the receiver in step  744 . 
     The second way for the sender  110  to fund the stored value fund of the receiver begins in step  728  where money is given at an agent location  500 . The money can be in the form of a credit/debit card, negotiable instrument, cash, etc. If the eCard were already selected online and stored, the agent could access the eCard to add the electronic gift. More typically, the sender would select the eCard at the kiosk interface  180 - 2  in the retail location  500 . The agent is able to pull up the eCard transaction by the identifier of the receiver  130  or other information in step  732 . With the provided money, the agent enters the desired electronic gift and the amount associated with it. In step  744 , the money is moved to the receiver&#39;s stored value fund minus any fees. 
     With reference to  FIG. 8 , a flow diagram of an embodiment of a process  636  for paying-out the electronic gift from the payment enabler  170  is shown. This embodiment demonstrates four different payout examples: payment of money to the stored value fund of the receiver, printing of a negotiable instrument for pick-up at an agent location  500 , printing and delivery of a negotiable instrument to a specified address, and delivery of a gift certificate with a targeted retailer. The first option allows the receiver  130  to choose the money handler  160 , while the latter three options are called external payouts where the money handler  160  is specified by the sender. For example, the sender may specify a gift certificate where the money is limited to merchandise or services from specified retailer(s). 
     In any event, the depicted portion of the process  636  begins in step  804  where the types of external payouts are separated from the internal payout option. Step  806  is the start of the external payout option where a negotiable instrument is provided to an agent location  500 . After clicking on the button or icon in the eCard for the electronic gift a screen is presented with information on the electronic gift, or negotiable instrument in this case. That screen or a subsequent screen allows the receiver to find an agent location  500  that is conveniently located for pick-up of the negotiable instrument. In step  808 , that agent location is notified of the negotiable instrument and particulars on the receiver. These particulars may include a way to validate the identity of the receiver. For example, a test question and answer could be used to verify identity. In step  812 , the negotiable instrument is printed for the receiver  130  after any verification of identity. 
     The next external payout option involves mailing out a printed negotiable instrument. In step  816 , the sender  110  enters the delivery address for the receiver. The payment enabler  170  decides which money handler  160  to use to print the negotiable instrument. That money handler  160  prints and sends the negotiable instrument in step  820 . 
     In the final external payout option depicted, a gift certificate or store credit is forwarded to the target retailer(s) for the benefit of the receiver  130 . In some embodiments, he gift certificate could be redeemable at a number of retailers, such that one of those would only get credit if the receiver  130  spent the gift certificate at the one&#39;s store. In step  824 , the sender  110  enters the target retailer into the payment enabler  170 . The retailer is notified of the issuance of the gift certificate in step  828 . In step  830 , the credit is paid out to the retailer. 
     With an internal payout, the receiver  130  is given the equivalent of cash that can be used in a number of ways. When the electronic gift screen is opened from the eCard, the receiver  130  is invited to log into the payment enabler interface  420  in step  836 . As indicated in step  840 , the receiver  130  can log into an existing account or open a new account in step  712 . Once an account is logged into or created, the receiver moves the money out of their stored value fund in step  844 . 
     Referring to  FIG. 9 , a flow diagram of an embodiment of a process  712  for configuring a user with an account for the online money transfer system  190  is shown. Where the receiver  130  or sender  110  is not external to the system, an account with the payment enabler  170  is created. The depicted portion of the process  712  begins in step  904  where the user  110 ,  130  enters an e-mail address as the unique identifier for the account. The user  110 ,  130  may want to enter any other e-mail addresses that are aliases of the user and that may be used by counter parties to a transaction. Other embodiments could use any unique identifier for the user  110 ,  130 . 
     Once an e-mail address is given to the payment enabler  170 , it is verified. A message is sent to the e-mail address in step  908 . A code is provided and an URL such that the user can click on the URL to load a page where the code is entered to verify the e-mail address. In this embodiment, the code is a randomly generated set of alphanumeric characters. Other embodiments could use any number of methods to verify the e-mail address. 
     The user  110 ,  130  enters contact information in step  912 . This contact information could include address, phone number, pager address, instant message address, wireless phone address, contact e-mail address, etc. In step  916 , the user enters handler interface information. For example, the user might enter credit card information and bank transfer information. In step  920 , the information is verified with the handler  160  to the extent possible for that handler  160 . In step  924 , the process  512  can loop back to step  916  for entering and verifying additional handlers. 
     In step  928 , a default input handler  160  and a default output handler  160  can be chosen for transferring money into and out of the system  100 . These two handlers  160  may be different. In step  932 , the payment enabler  170  waits for verification at least one of the e-mail addresses before activating the account for sending and receiving money with that e-mail address in step  936 . 
     With reference to  FIG. 10 , a flow diagram of an embodiment of a process  744  for transferring money from the sender  110  to the receiver  130  is shown. The process  744  describes a transfer between a single sender  110  and a single receiver  130 , but a number of these processes  536  could be performed in parallel where there are a number of receivers  130 . For example, a corporation could distribute eCards with electronic gifts enclosed to a class of employees or clients. The depicted portion of the process begins in step  1004  where the receiver  130 , sender  110  and amount are determined for the money transfer. In step  1012 , it is determined if the stored value fund of the sender  110  has enough money to fund the transfer to the receiver  130 . 
     Where there is not sufficient funds in the stored value fund, processing continues to step  1016  to load funds. In step  1016 , the default pay-in handler  160  is determined. The information used to transfer money from the handler  160  into the payment enabler  170  is retrieved from the user database  324  in step  1018 . The sender  110  may be given an opportunity to change the default pay-in handler  160  for this transaction or for all further transactions. Presuming there are no changes, the default handler  160  is interfaced in step  1020  to transfer the money. If there is no stored value fund for the receiver  130 , a temporary fund is created in step  1024 . A temporary stored value fund can be used for a single transfer, but the receiver may want to make the temporary fund permanent by opening an account with the payment enabler  170 . 
     Regardless of whether new money is added or whether existing money is used, processing continues to step  1028  from both step  1012  and step  1024 . In step  1028 , the money is attributed to the receivers  130  stored value fund to the detriment of the sender&#39;s stored value fund in step  1028 . In some embodiments, the payment does not originate in the sender&#39;s stored value fund, but passes directly from the money handler  160  of the sender  110  to the stored value fund of the receiver  130 . In other embodiments, the sender can select a future time that payment is made such that the payment is configured now, but completed at the future time. 
     Referring to  FIGS. 11A and 11B , a flow diagram of an embodiment of a process  844  for moving money out of a stored value fund for a receiver  130  is shown. This embodiment allows paying-out money in at least six different ways, namely, by: pick-up at an agent location  500 , exchanging with some promotion, a credit to a debit or credit card, a credit to a bank account, mailing a negotiable instrument, and sending an electronic gift certificate. The depicted portion of the process  844  begins in step  1104  where the default pay-out handler information is retrieved for the receiver  130 . In step  1108 , a web page is presented that allows the receiver  130  to select a different handler  160  or to change information for the handler  160 . 
     A user may have a number of different currencies of money in their stored value fund. The user may select some or all of the different currencies for paying out. In many cases, the handler  160  only accepts money in a single currency or the user may simply wish to exchange money to another currency. In step  1110 , any currency is exchanged. The exchange rate database  332  is queried for the current rate that is applied by the payment conversion function  328 . 
     In step  1112 , processing branches in one of six directions depending on the type of handler the user has chosen. The first two directions are depicted on  FIG. 11A  and the remainder are depicted on  FIG. 11B . One branch beginning in step  1116  corresponds to the user visiting an agent location  500  to transfer out money with the assistance of the agent. In step  1116 , the user selects an agent location  500  that is convenient. The user visits the agent location  500  in step  1124  to either use a kiosk interface  180 - 2  or use the agent. In this embodiment, the user interfaces with the agent who uses the agent interface  180 - 4  to the payment enabler  170 . From the agent interface  180 - 4 , the agent can transfer the money to any handler  160 , can print a negotiable instrument or can provide cash to the user. The transfer is recorded by the payment enabler  170  in step  1132 . 
     In another branch that begins in step  1136 , a promotion program is chosen as the handler  160 - 1 . Either the promotion handler  160 - 1  or the exchange rate database  332  can be queried in step  1136  to determine the exchange rate for program credits or points. In step  1140 , the conversion rate is presented to the user for approval. Presuming the rate is approved, the promotion credits or points are purchased in step  1144  by interfacing with the promotion handler  160 - 1 . The payout of money to the promotion handler  160 - 1  is recorded in step  1132 . 
     In yet another branch that begins in step  1148  of  FIG. 11B  and is labeled “A,” a credit card or debit card is used to transfer out money from the system  100 . In step  1148 , a credit message is formulated for the card bank. In some embodiments, the identity of the card holder may be further verified by entry of a PIN or other verification method. The card bank is contacted in step  1152  for authorization of the credit. Authorization of the credit is performed in step  1156 . The payout is recorded with the payment enabler  170  in step  1132 . 
     In the branch labeled “B,” a bank transfer is used to payout money from the system  100 . In step  1160 , an EFT message is formulated for the handler bank  160 - 4 . The EFT message is sent to the handler bank  160 - 4  in step  1164 . Receipt of the EFT message is confirmed by the handler interface  308  in step  1168  and the transfer is recorded in step  1132 . 
     In the branch of  FIG. 11B  labeled “C,” a negotiable instrument is printed and sent to the receiver  130  or some other party. In step  1172 , the user enters the delivery address and a name to pay the negotiable instrument to. The user can send the negotiable instrument to herself or a third party. A delivery method for sending the negotiable instrument is chosen in step  1176 . In step  1180 , the negotiable instrument is printed or otherwise produced and sent. The payout is recorded in the user database in step  1132 . 
     In the last branch of  FIG. 11B  labeled “D,” a gift certificate is used to payout the credit in the receivers stored value fund. In step  1184 , a retailer(s) is chosen as a target for the gift certificate. The retailer is notified in step  1188 . In step  1192 , the money is paid-out to the retailer such that a store credit exists for the benefit of the receiver  130  or some other party chosen by the receiver. 
     While the principles of the invention have been described above in connection with specific apparatuses and methods, it is to be clearly understood that this description is made only by way of example and not as limitation on the scope of the invention.