Customer enrollment in a stored value card program

CROSS-REFERENCE TO RELATED APPLICATIONS

0001This application is a continuation application of U.S. Patent application Ser. No. 11/139,211, entitled “Customer Enrollment in a Stored Value Card Program,” filed on May 27, 2005, now U.S. Pat. No. 7,387,238 which is a continuation-in-part application of U.S. patent application Ser. No. 10/685,277, entitled “System, Method and Apparatus for Providing Financial Services,” filed on Oct. 14, 2003, now abandoned which is related to U.S. patent application Ser. No. 10/645,949, entitled “System for Providing a Checkless Checking Account,” filed on Aug. 22, 2003 and U.S. patent application Ser. No. 10/646,150, entitled “System and Method for Dynamically Managing a Financial Account,” filed on Aug. 22, 2003, all of which are incorporated by reference in their entirety.

BACKGROUND

0002Throughout the years, a main focus of providing services to consumers has been convenience. It is quite clear to even the most simplistic marketing analyst that the more convenient you can make a service to the consumer, the more likely the consumer will partake in the service. It is on this foundation that the majority of Internet services are based.

0003The Internet is not always the final answer in providing convenience to the consumer. In some instances, consumers are simply reluctant to conduct business over the Internet due to a variety of reasons, such as fear of losing confidentiality, resistance to relying on modern technology and sometimes, just stubbornness. Thus, there has been, is and remains a need in the art for providing face to face, plain old ordinary customer service.

0004The banking and credit industry is particularly poised in this predicament. Consumers that are engaging in financial transactions or receiving financial services often times prefer to deal with an institution rather than the Internet. Thus, marketers are still challenged with increasing the convenience at which such services are offered.

0005One avenue that has been extensively explored for providing financial services is through merchants. Consumers typically are willing to trust a merchant that is offering a financial service. This is evident in the fact that nearly every department store offers a credit program to their customers.

0006Typically, merchants are limited to the types of financial services that they can provide. This limitation can be due to a variety of factors including the cost that the merchant must incur to provide the service, the technological complexities of providing the service, and the training required for the merchant's employees. However, anyone that has completed a marketing 101 class will agree that the more services a merchant can offer, the more foot traffic the merchant will generate and, thus, the higher probability the merchant will get a sale.

0007Thus, there is a need in the art for a solution that enables a merchant to provide multiple financial services to its customers, that is commercially feasible to the merchant, not overly complicated from a technological perspective, and that minimizes the training required for the merchant's employees.

SUMMARY

0008Various embodiments of systems, methods, computer programs, and merchant devices for providing customer enrollment for a stored value card program are provided. One embodiment is a merchant device that provides stored value card services. One such merchant device comprises: an input device that receives data from a stored value card; a customer enrollment module that enrolls a customer in a stored value card program, the customer enrollment module comprising: logic configured to identify information corresponding to an account associated with the stored value card; logic configured to determine that the account corresponds to a competitor's stored value card program; and logic configured to enroll the customer in a new stored value card program.

0009Another embodiment is a method for implementing a stored value card program. One such method comprises: advertising a new customer enrollment program for a stored value card program; initiating an enrollment process at a merchant device; confirming that the new customer has a stored value card account with an unaffiliated stored value card program; and enrolling the new customer in the stored value card program.

0010Another embodiment is a method for enrolling a customer in a stored value card program. One such method comprises: generating a list of unaffiliated stored value card programs; and when enrolling a new customer in a new stored value card program at a merchant device, determining whether the new customer has a stored value account with one of the unaffiliated stored value card programs.

0011Yet another embodiment is a system for providing stored value card services at a merchant device. One such system comprises: means for reading data from a stored value card of a customer; means for processing the data from the stored value card and determining that the stored value card corresponds to a first stored value card program associated with a competitor of a second stored value card program affiliated with the merchant device; and means for enrolling the customer in the second stored value card program.

0012A further embodiment is a computer program for enrolling a new customer in a stored value card program. One such computer program comprises: logic configured to read data from a stored value card associated with a first stored value card program; logic configured to identify a first account associated with the first stored value card program; logic configured to reconcile the balance in the first account; and logic configured to credit a second account associated with a second stored value card program with an amount based on the original balance in the first account.

BRIEF DESCRIPTION OF THE DRAWINGS

0013Other aspects, advantages and novel features of the invention will become more apparent from the following detailed description of exemplary embodiments of the invention when considered in conjunction with the following drawings.

0014<figref idref="DRAWINGS">FIG. 1</figref> is a diagram illustrating an exemplary embodiment of a device that facilitates the provision of a variety of financial services.

0015<figref idref="DRAWINGS">FIG. 2</figref> is a flow diagram illustrating an overview of the steps and components that can be utilized in conjunction with implementing various embodiments of the present invention.

0016<figref idref="DRAWINGS">FIG. 3</figref> is a flow diagram illustrating the processes involved in providing the exemplary financial service of issuing a cash card to a customer through the use of the device of the present invention.

0017<figref idref="DRAWINGS">FIG. 4</figref> is a flow diagram illustrating the operation of an exemplary embodiment of the present invention.

0018<figref idref="DRAWINGS">FIG. 5</figref> is a block diagram of an embodiment of system for providing stored value card services via a merchant device.

0019<figref idref="DRAWINGS">FIG. 6</figref> is a flow chart illustrating an embodiment of a method for implementing a stored value card program.

0020<figref idref="DRAWINGS">FIG. 7</figref> is a flow chart illustrating the general architecture, operation, and/or functionality of an embodiment of the customer enrollment module of <figref idref="DRAWINGS">FIG. 5</figref>.

0021<figref idref="DRAWINGS">FIG. 8</figref> is an overhead perspective view of another embodiment of a merchant device illustrating a user interface screen for selecting an account service.

0022<figref idref="DRAWINGS">FIG. 9</figref> illustrates the user interface screen of <figref idref="DRAWINGS">FIG. 7</figref> in which the “enroll” service is selected.

0023<figref idref="DRAWINGS">FIG. 10</figref> is an overhead perspective view of the merchant device of <figref idref="DRAWINGS">FIG. 7</figref> illustrating another user interface screen.

0024<figref idref="DRAWINGS">FIG. 11</figref> is an overhead perspective view of the merchant device of <figref idref="DRAWINGS">FIG. 7</figref> illustrating yet another user interface screen by which a customer is prompted to swipe a stored value card.

0025<figref idref="DRAWINGS">FIG. 12</figref> is a flow chart illustrating the architecture, operation, and/or functionality of another embodiment of the customer enrollment module of <figref idref="DRAWINGS">FIG. 5</figref>.

0026<figref idref="DRAWINGS">FIG. 13</figref> is a block diagram illustrating another embodiment of a system for providing stored value card services.

DETAILED DESCRIPTION

0027In general, the present invention can be described as a novel system, method and apparatus for a merchant to conveniently provide a variety of financial services to a consumer. The exemplary embodiments described below are for illustrative purposes only and, a person skilled in the art will construe them broadly. It should be understood that the features and aspects of the present invention can be ported into a variety of systems and system/network configurations and any examples provided within this description are for illustrative purposes only. Referring now to the figures, in which like numerals refer to like elements throughout the several views, exemplary embodiments of the present invention are described.

0028<figref idref="DRAWINGS">FIG. 1</figref> is a diagram illustrating an exemplary embodiment of a device <b>100</b> that facilitates the provision of a variety of financial services. The device <b>100</b> is comprised of a processor <b>130</b>, a data interface <b>120</b> and a network interface <b>140</b>.

0029The data interface <b>120</b> is coupled both to the processor <b>130</b> and can interface to a data source <b>110</b>. One function of the data interface <b>120</b> is to extract session data from the data source <b>110</b> and transfer the session data to the processor <b>130</b>. Another function of the data interface <b>120</b> is transferring modified session data from the processor <b>130</b> to the data source <b>110</b>. Thus, in some embodiments, the data interface <b>120</b> can transfer data bi-directionally. The data interface <b>120</b> may be any type of interface capable of extracting and/or writing to a data source <b>110</b>. The data interface <b>120</b> may incorporate the hardware necessary to read/write to the data source <b>110</b> or may simply be an interface to a hardware device such as a bar code reader/writer, a magnetic reader/writer, a scanner, a templated scanner, a printer, a bio-metric identification device, a pass-through inlet/outlet, etc. Further, the data source <b>110</b> may consist of many different types of sources, including, but not limited to, a bar code, a magnetic-type card or magnetic storage device, scannable media, writable media, a fingerprint, a keyboard or keypad, a mouse, a light-pen, a touch pad, a display, or any other type of data device. The session data is data that may be utilized in a particular financial service transaction. The session data may be located on the data source <b>110</b>, or alternatively, may be inputted manually. The session data may include, but is not limited to, name, date of birth, address, telephone number, social security number, verified government identification, direct deposit account (DDA) information and number, savings account information and number, credit history, debt to credit ratio, asset information, a type of financial service, a transaction amount, card account number, etc.

0030The network interface <b>140</b> is coupled to the processor <b>130</b> and interfaces to a server <b>150</b>. One function of the network interface <b>140</b> is to provide session data to the server <b>150</b>. Another function of the network interface <b>140</b> is obtaining validation from the server <b>150</b> and providing it to the processor <b>130</b>. The server <b>150</b> validates all or a portion of the session data for a variety of different purposes depending on the particular financial service involved. The validation may include, but is not limited to, an approval for a financial service, a denial for a financial service, an available balance or fund verification, a credit worthiness verification, a billing address verification, etc.

0031The processor <b>130</b> is coupled to both the data interface <b>120</b> and the network interface <b>140</b>. One function of the processor <b>130</b> is processing the session data and executing or initiating the provision of a plurality of financial services. The processor <b>130</b> receives the session data from the data interface <b>120</b> and requests a validation from the server <b>150</b>, based at least in part on the session data, through the network interface <b>140</b>. Further, the processor <b>130</b> provides or initiates the provision of a plurality of financial services and in some embodiments, is capable of updating the session data stored on the data source <b>110</b> based at least in part on the provision of the particular financial service. The plurality of financial services may include, but are not limited to, purchasing pre-paid cards, pre-paid card acceptance, credit card acceptance, debit card acceptance, check acceptance, point of sale purchase, cash back on point of sale purchase, transfers, card-to-card activity, bill payment, loyalty acceptance, etc.

0032<figref idref="DRAWINGS">FIG. 1</figref> also illustrates the device <b>100</b> within a system for providing financial services <b>105</b>. The system <b>105</b> includes: the device <b>100</b>, a server <b>150</b> and one or more data sources <b>110</b>. In operation, the device <b>100</b> is provided to a merchant for use in store operation. The device <b>100</b> is interfaced to and granted access to the server <b>150</b>. The interface to the server <b>150</b> can be provided in a variety of fashions including, but not limited to, DSL, T1, broadband, wireless, telephonic and satellite connectivity. The device <b>100</b> is available to merchant employees in providing the financial services to customers. Depending on the desired financial service, a customer obtains and/or presents a data source <b>110</b> to the merchant in conjunction with selecting a financial service to be provided.

0033<figref idref="DRAWINGS">FIG. 2</figref> is a flow diagram <b>200</b> illustrating an exemplary embodiment of the present invention. The details of the operation of the flow diagram <b>200</b> may vary among various embodiments of the present invention. In general, the illustrated embodiment includes five main functions or components: the data collection component <b>210</b>, the decision engine <b>220</b>, the account creation component <b>230</b>, the account management component <b>240</b> and the transactional processing component <b>250</b>. It should be understood that the structure illustrated in this figure is for discussion purposes only and the various functions or components of the present system could be combined or split in many manners.

0034The data collection component <b>210</b> collects data or information relevant to: opening a credit account (e.g., account formation data), determining if an applicant can qualify for an account, the type of account to be opened (e.g., account option data), and other miscellaneous data. The information collected with regards to the account formation data may include, but is not limited to, the applicant's name, date of birth, mailing, residential and business addresses, telephone numbers, social security number or verified government identification number, direct deposit account (DDA) information and account number, savings account information and account number, credit history, debt to credit ratio, assets, marital status, employment history, etc.

0035Further information regarding the account formation data, the account option data and the account types (as well as other types of data) can be found in the related applications identified above and which have been incorporated by reference into this specification. After the data collection component <b>210</b> receives the necessary or the minimum amount of information, the decision engine <b>220</b> can be begin processing.

0036The decision engine <b>220</b> receives raw or processed data from the data collection component <b>210</b> and, among other functions, integrates it with underwriting criteria <b>222</b> to determine if a customer qualifies for an account. The underwriting criteria <b>222</b> is initially determined using a collection of integrated algorithms, methods of work, business processes, and initial risk modules <b>224</b> that enable the analysis, issuance, distribution, and monitoring of an integrated credit product. The initial risk models <b>224</b> are compiled from a variety of different sources that vary by issuer. One skilled in the art is familiar with the type of information that is associated with them. In addition to determining if a customer qualifies for an account, the decision engine system <b>220</b> also determines if a customer qualifies for any applicable account option data selected in the data collection system <b>210</b>. For example, if a customer selected an overdraft option in the account option data, the decision engine <b>220</b> would determine if the customer qualified for that option and, if qualified, the amount of the overdraft limit. The decision engine <b>220</b> uses the account formation data to qualify the customer and perform a risk management processes. The customer is subjected to underwriting criteria <b>222</b> to determine qualification and some additional data or documents may be required for the process. In some embodiments, the customer provides information such as personal demographic information, which can include, but is not limited to, age, social security number, driver's license number, name, address, date-of-birth, mother's maiden name, etc.

0037Once a customer is qualified, the account creation component <b>230</b> proceeds to open an account. The account creation component <b>230</b> may perform different functions depending upon the account option data. Preferably, the account creation component <b>230</b> operates to create an account for the customer in a manner that is in compliance with all applicable local, state and federal laws. During the account creation, the account creation component <b>230</b> may utilize various procedures to support issuer risk mitigation requirements. The account creation component <b>230</b> also includes a plastic card creation component <b>235</b> that operates to generate a permanent card for the customer.

0038The procedures performed by the account creation component <b>230</b> may vary depending on the type of account being created. In the examples provided in the incorporated references identified above, the three account types include the instant issue card, the basic card and the basic card with overdraft protection. Other functions that may be performed by the account creation component <b>230</b> include the activation of the account the issuance of cards. The details of these functions are more specifically described in the incorporated references.

0039The account management component <b>240</b> manages the customer account by utilizing controllers to enable and disable certain functions and privileges of the account based on various factors. Some of the factors can include account risks and customer behaviors. In one embodiment, the account management component <b>240</b> can include the functions of fraud management model <b>242</b>, fee management model <b>244</b> and account behavior model <b>246</b>. The fraud management model <b>242</b> can utilize the operation of the account behavior model <b>246</b> to determine if any fraudulent activities are associated with the account. If any fraudulent activities are detected, the account management component <b>240</b> can be notified by the fraud management model <b>242</b> to suspend the account. The fee management model <b>244</b> determines and assesses any applicable fees to be charged against the account. For example, if the account is overdue, a late fee would be assessed to the account. In the various embodiments, additional fees can be assessed against the accounts. For instance, a one time fee may be assessed for the creation of the account or for the creation of certain accounts, such as accounts having an overdraft component <b>234</b>. In addition, the account may include a fixed number of transactions or a fixed number of transactions per fixed period (e.g., per month). Once the fixed number of transactions is exceeded, additional transactions can be assessed a transaction fee. In another embodiment, a monthly fee may be assessed on the account.

0040The account behavior model <b>246</b> examines account activity and looks for patterns in the account activity to determine possible actions to be taken (e.g., intervention to stop fraud). For example, if an account appeared to have sporadic spending or if the stored value became zero, the account could be turned off temporarily to ascertain if the account is being defrauded. The transactional processing component <b>250</b> processes and monitors the day to day transactions between the account and the financial transaction network <b>255</b>. The transactional processing component <b>250</b> is then compiled by the data aggregation module <b>252</b>.

0041The data aggregation module <b>252</b> may work on data related to the entire population of account holders, groups of populations based on factors such as age, occupation, areas of domicile etc. or even individuals. The data aggregation module <b>252</b> provides processed outputs to the risk models <b>224</b> and the account behavior <b>246</b> model.

0042An aspect of the present invention is found in the operation of the account management component <b>240</b>. The account management component <b>240</b> of the present invention enables the dynamic management and alteration of the financial account based on real-time and current information. Two controlling factors are applied to the account management component <b>240</b>. These controlling factors include the output of risk models <b>242</b> that have been run on the initial underwriting criteria collected by the data collection component <b>210</b>, as well as the output of the data aggregation module <b>252</b>.

0043The data aggregation module <b>252</b> refines and updates, preferably on a real-time basis, the various current trends of the accounts being managed. This information is then fed into the risk models <b>224</b> which determine new underwriting criteria <b>222</b>, and the account behavior <b>246</b> model. The data aggregation module <b>252</b> can feed information into the risk models <b>224</b> and the account behavior <b>246</b> model at periodic intervals, continuously, autonomously, on request, or on other bases. The account behavior model <b>246</b> can operate to alter the parameters of the operation of the credit account. The account behavior model <b>246</b> can base these alterations on the input from the aggregation module <b>252</b> and/or the risk models <b>224</b>. Thus, in operation, the data aggregation module <b>252</b> may identify trends for a particular subset of the population. This information in turn can be used by the risk models <b>224</b> to identify certain risks associated with the particular subset or related subsets of the population. This information, as well as the information directly provided from the data aggregation module <b>252</b> can serve as the basis for altering the parameters of the credit account. As a particular example, suppose that the data aggregation module <b>252</b> identifies an increase in transactions by customers identified as working in the airline sector and the risk models <b>224</b> indicate a decline in job stability in the transportation industry. The account behavior model <b>246</b> may utilize this information to decrease the lines of credit provided to customers working in the airline sector, increase fees associated with their accounts, provide a higher level of scrutiny on approvals of purchases, lock the account from further purchases, or the like. From a fraud perspective, the account behavior model can receive information from the data aggregation module <b>252</b> that may be an indication of fraudulent behavior. The account behavior module <b>246</b> can then take actions to limit or alleviate the risk of fraud.

0044Similarly, the risk models <b>224</b> can receive input from the data aggregation module <b>252</b> and/or the account behavior model <b>246</b>. The information fed to the risk models <b>224</b> is used as the basis for generating new underwriting criteria for qualifying new individuals for accounts. The new underwriting criterion provides more accurate real-time criteria that are not otherwise available when using underwriting criteria that has only been created at the initial stages of qualification.

0045<figref idref="DRAWINGS">FIG. 3</figref> is a flow diagram illustrating the processes involved in providing the financial service of issuing a cash card to a customer through the use of the device <b>100</b> of the present invention <b>300</b>. Initially a customer approaches a merchant that has a device. The customer selects, or with the help of the merchant, selects the financial option of the issuance of a cash card <b>310</b>. The customer is then prompted to provide valid identification <b>312</b> and funding for the cash card <b>314</b>.

0046The merchant's clerk working with the customer initiates the sell of a temporary card <b>320</b>. The clerk then receives the funding from the customer that will be used for loading value into the cash card <b>324</b>. Independently the merchant deposits the funds in a banking institution, transfers the funds to an appropriate account or issues a transaction against a credit card <b>326</b>. In addition, the clerk swipes the temporary card through the device <b>330</b>. The device <b>100</b> reads the magnetic strip on the back of the temporary card and extracts an identification number for the card. The clerk then enters the identification of the customer <b>332</b>. The identification can be obtained from the valid identification presented by the customer or through some other means. The clerk then follows one or more steps prompted by the device. In the illustrated embodiment, this is done through a touch screen on the device <b>334</b>.

0047The information collected at this point in the process is passed to a processor that first operates to enroll the customer and verify the information received from the customer <b>340</b>. The processor then conducts an OFAC check and validates other data provided by the customer <b>342</b>. An account record is then either created, or updated if this is a repeat customer, with the customer information <b>344</b>. The processor then operates to enroll the customer, load the provided funds onto a card and activate the card in conjunction with a host or server managing the processor <b>346</b>.

0048If the customer is approved, an activation response is provided to the device <b>350</b> and a card, terms and conditions and a PIN is provided to the customer <b>360</b>. At this point the customer is then able to use the temporary card. In some embodiments, a permanent card will then be created and mailed to the customer.

0049<figref idref="DRAWINGS">FIG. 4</figref> is a flow diagram illustrating the operation of an exemplary embodiment of the present invention. One aspect of the present invention is providing an entire suite of financial services that are available to a customer, or a customer working with a merchant <b>400</b>. The first step in providing the suite of financial services <b>400</b> is providing a device to a merchant <b>410</b>. In conjunction with this, the device can be integrated into the merchant's communication infrastructure as well as being connected to the server <b>150</b> that operates in conjunction with the device <b>100</b>. The device <b>100</b> is operable to provide the suite of financial services to a customer.

0050Once the device <b>100</b> or devices are installed and operational at the merchant location, the device <b>100</b> can be access by a customer and/or a merchant to initiate the provision of a financial service selected from the suite of financial services available.

0051One of the overall purposes of the present invention is to allow customers to have instant access to a suite of financial services at a variety of locations convenient to the customer. Thus, the service provider of the financial services equips multiple merchants with the device <b>100</b> equipment.

0052The suite of financial services can be accessed from the device <b>100</b> in a variety of manners. Thus, in an exemplary embodiment, a device <b>100</b> gives a service provider the ability to identify and process a customer requesting a financial service at a retail merchant point of sale. The device <b>100</b> operating in conjunction with the server <b>150</b> and other resources insures compliance with identification and qualification requirements established by competent authorities and/or the service provider. The merchant makes the device <b>100</b> available for use by a customer or the merchant operates the device <b>100</b> on behalf of the customer.

0053The financial service can include one of several financial services, such as purchasing a stored-value card, transferring of funds, wiring funds, obtaining cash in an ATM fashion, purchasing a pre-paid credit-type card, purchasing a pre-paid telecom card, stamps, etc. at the device. One aspect of the present invention is that a single device <b>100</b> can provide any and all of these financial services as well as other services.

0054In one embodiment a menu of services available can be displayed on a screen and selected by a customer and/or merchant. In another embodiment, the customer may swipe a card through the card reader of the device <b>100</b> and after identifying the customer or card identification, the device <b>100</b> can indicate the financial services available. In addition, it should be noted that the device <b>100</b> can operate in conjunction with the server <b>150</b> to determine the financial services available to the customer. Regardless of the method of indicating the services available or the method employed for selecting one of the suite of services, the device <b>100</b> receives a selection for a financial service <b>420</b>. The selection is made from the plurality of financial services available to the customer.

0055The selected financial service is performed <b>430</b>. This process can vary greatly depending on the selected financial service. However, in most situations, the customer is prompted to provide additional information that is entered into the device <b>100</b> in one of the various previous manners disclosed. Once the device <b>100</b> has sufficient information, the device <b>100</b> interacts with the server to determine if the financial service can be provided, if the customer qualifies and to verify the information is correct. This process may involve requesting additional information from the customer and/or the merchant. Ultimately, the financial service is provided to the customer.

0056A fee is collected from the customer for the provision of the financial service <b>440</b>. As has been described, this fee can be collected in a variety of manners including cash, credit cards, bank transfers or the like.

0057An aspect of the present invention is the step of compensating the merchant with a portion of the fee collected from the customer <b>450</b>. This varies from the current state of the art. Traditionally, merchants have paid a fee to have terminal equipment such as device <b>100</b> installed on their premises and/or paid a fee for certain transactions. The system implementation of the present invention utilizes various means for compensating the merchant for housing and operating the equipment at the merchant's location. In one embodiment, the merchant may simply be given a flat fee for each device <b>100</b>. In another embodiment, the merchant may be paid a fee based on the number of devices <b>100</b> and the number of transactions provided using the devices <b>100</b>. In yet another embodiment, the merchant may be compensated based solely on the number of transactions. In yet another embodiment, the merchant may be compensated based on a percentage value of the transactions. Those skilled in the art will appreciate that any of these compensation methods, as well as a combination of one or more of these methods maybe utilized and the present invention is not limited to any particular configuration.

0058The Suite of Services: The present invention can be utilized to provide a suite of financial services to a customer at a variety of merchant locations. The general descriptions of these financial services are provided below.

0059Stored-Value Card: For the financial service of purchasing a stored-value card, the customer purchases a pre-paid or stored-value magnetic-type card (the data source <b>110</b>), from the merchant. The detailed components for this financial service were described in conjunction with <figref idref="DRAWINGS">FIG. 3</figref>. The overall operation of this financial service enables the merchant to initiate and issue a stored-value card. The merchant can accept payment for the card in a variety of manners including cash, credit card, money transfer, check, etc. The merchant may supply and swipe the card through a magnetic card reader (the data interface <b>120</b>), interfaced to the device <b>100</b>. This process allows the device <b>100</b> to capture the account number of the card. The merchant may then enter a value for the card into the device <b>100</b> through the data interface <b>120</b>. As previously described, this information can be provided to the device <b>100</b> in a variety of manners including the use of a keyboard, scanner, magnetic card reader or the like. In one embodiment, the merchant may acquire certain additional information from the customer, such as the customer's name, date of birth, social security number, DDA number, etc.). The merchant may then enter this information into the data interface <b>120</b> of device <b>100</b>. Although this aspect of the invention is being described as a customer and merchant performing certain tasks, it should be understood that either of the participants could perform the tasks and some of the tasks could even be automated.

0060Once the merchant has collected all of the information, or even during the information collection process, all or portions of the information are provided to the server <b>150</b> through the network interface <b>140</b>. The server processes the information in a manner that is familiar to those skilled in the art. The incorporated references provide further information regarding this process. The merchant then waits for the device <b>100</b> to receive authorization from the server <b>150</b>.

0061The funds for the stored-value card can be provided by the customer in a variety of manners. In one embodiment, the stored-value card may be funded directly from the customers direct deposit account (DDA), thus the limit of the pre-paid or stored value card is the amount taken from the account and placed on the card. In another embodiment, the stored-value can be funded based on a credit as authorized by the service provider, thus the limit of the card is limited by the amount of credit authorized. The stored-value card can also be funded by a direct cash transaction at the device <b>100</b>. Thus, the value of the stored-value card can be selected by the customer or merchant and as long as funds are available.

0062The authorization of the stored-value card can be based on a number of factors, including, but not limited to, credit worthiness, credit history, credit score, balances in customer accounts, etc. Once an authorization has occurred, the card is activated and a stored value or credit limit is associated with the card. In one embodiment, the activation process may include writing information out to the data source <b>110</b>, in this case the stored-value card. For instance, the value associated with the stored-value card, an expiration date, an authorized user name, PIN code, device <b>100</b> and/or merchant at which the card was activated, date of activation, or a variety of other information could be stored on the stored-value card. The customer may then make purchases from the merchant using the pre-paid or stored-value card.

0063In addition, once a financial service is provided, such as using the stored-value card, the device <b>100</b> can operate to update the session data after performing a financial service and sends the updated data to the data source <b>110</b>. The customer can then use the device <b>100</b> to view activity data, history data or other data associated with the data source <b>110</b>.

0064The process for issuing a stored-value card is also applicable to the purchasing a pre-paid credit-type card as well as a pre-paid telecom card.

0065Transferring of Funds: For the financial service of conducting a fund transfer, the customer initiates the transfer by selecting the appropriate feature from the device <b>100</b>. The present invention can be used to transfer funds from one account into another account, from a stored-value card to an account, or from an account to a stored-value card. For transferring funds from one card to another, the customer can simply swipe the card through the card reader of the device <b>100</b> and select an option to transfer the balance, or a portion thereof to another card. The balance can be transferred to another card held by the customer or to another card not even owned by the customer. In this case, the customer will be required to enter a card identification number, account number and/or customer identification information into the device <b>100</b>. The server <b>150</b> operates to receive the fund transfer request. If the transfer is a card to card transfer, the server <b>150</b> can communicate with the device <b>100</b> and instruct the customer to swipe the destination card or enter the necessary information to identify the destination for the transfer. If the transfer is to be made to a card not in the customer's possession, the server <b>150</b> can receive and maintain information regarding the transfer. Once the system is accessed by the destination card or a card associated with a customer or account destined to receive the transfer, the server <b>150</b> can initiate the completion of the transfer. If the finds are destined for an account, the server <b>150</b> can transfer the funds directly into the account once the appropriate information is entered. If the transfer request is to transfer funds from an account onto the card, the process is similar to that described in conjunction with the stored-value card financial service.

0066Wiring Funds: For the financial service of conducting a wiring fund transfer, the customer initiates the transfer by selecting the appropriate feature from the device <b>100</b>. Similar to the funding options for the stored-value card, the customer can utilize the same options for funding the wiring transfer. The device <b>100</b> collects the necessary information by prompting the customer for the information. In the alternative, the server <b>150</b> can cause the device <b>100</b> to prompt for specific information. In either case or using a combination of both, the information is collected and transferred to the server. The server then actuates the wire transfer.

0067Cash-back: For the financial service of providing access to cash, the customer initiates the service by selecting the appropriate feature from the device <b>100</b>. The funds to support cash access can be based on a credit card, money transfer, check, etc. The device <b>100</b> collects the necessary information by prompting the customer for the information. In the alternative, the server <b>150</b> can cause the device <b>100</b> to prompt for specific information. In either case or using a combination of both, the information is collected and transferred to the server. The server <b>150</b> then approves the financial service and gives in indication to the device <b>100</b>. This same approach can be applied in the purchase of stamps.

0068Check Acceptance: The device <b>100</b> can also be used to authorize or verify payments by check. The check can be scanned at the device <b>100</b>, and based on the account information, the server <b>150</b> can begin to process approval for the payment. The server <b>150</b> and or device <b>100</b> can request additional information from the customer to complete the financial service and the customer can enter that information at the device <b>100</b>.

0069Bill Payment: The device <b>100</b> can be utilized by a customer to pay bills. In operation, the customer enters information to identify the recipient of the bill, along with the amount, source of funds for making the payment, and the like. The device <b>100</b> and/or server <b>150</b> may interact with the customer to obtain additional information. The source of funds can be any of a variety of sources, or a combination of one or more sources, including but not limited to, a stored-value card, banking account, cash, check or the like.

0070Loyalty awards: The present invention also anticipates providing a loyalty awards program. In one embodiment, the merchant charges a fee for the financial service, a portion of which is supplied to the service provider. In another embodiment, the device <b>100</b> automatically assesses and extracts a fee for a give financial service and apportions the fee appropriately to the merchant and/or the service provider.

0071As mentioned above, a device <b>100</b> may be installed at a merchant location and accessed by a customer, merchant, etc. to initiate the provision of various financial services. For example, in one embodiment device <b>100</b> provides various services for managing a stored value card account associated with a stored value card. As known in the art, a stored value card program enables customers to access a money balance using a stored value card. The money balance may be stored directly on the card or maintained in a stored valued card account maintained by the card issuer, host, etc. The stored value card may be used at ATM locations to withdraw money against the balance. The stored value card may also be used to make purchases against the balance at the point-of-sale.

0072In this regard, <figref idref="DRAWINGS">FIG. 5</figref> illustrates a block diagram of a system <b>502</b> that supports the provision of various stored value card services to customer(s) <b>506</b> having a stored value card <b>508</b>. As mentioned above, stored value card <b>508</b> represents money stored in a stored value card account, regardless of whether the balance is stored locally on the card or in a stored value account. As illustrated in <figref idref="DRAWINGS">FIG. 5</figref>, system <b>502</b> comprises one or more merchant devices <b>504</b> that provide the stored value card services to customer(s) <b>506</b>. As the name suggests, merchant device <b>504</b> may be located at a merchant site where point-of-sale transactions occur. Therefore, a merchant device <b>504</b> may be associated with one or more merchant(s). Although not illustrated in <figref idref="DRAWINGS">FIG. 5</figref>, it should be appreciated that merchant device(s) <b>504</b> may be maintained by a merchant representative. Furthermore, it should be appreciated that the merchant representative may have access to cash via, for example, a typical cash register. In this manner, merchant device(s) <b>504</b> may be used in conjunction with—or in certain embodiments without—the merchant representative and cash register. Furthermore, in some embodiments, the merchant device <b>504</b> can include an automated teller machine (ATM) and/or computers and/or internet capable devices.

0073In the embodiment illustrated in <figref idref="DRAWINGS">FIG. 5</figref>, merchant device <b>504</b> comprises a card reader <b>512</b>, a stored value card management system <b>501</b> (which includes a customer enrollment module <b>500</b>), a processor <b>514</b>, a user interface <b>518</b>, and a network interface <b>516</b>. In general, processor <b>514</b> controls the functional operation of various (although not necessarily all) aspects of card reader <b>512</b>, user interface <b>518</b>, network interface device <b>516</b>, and stored value card management system <b>501</b>. Card reader <b>512</b> comprises a hardware device configured to read stored value card <b>508</b>. As illustrated in <figref idref="DRAWINGS">FIG. 5</figref>, stored value card <b>508</b> may comprise a magnetic strip <b>510</b> which may be read by card reader <b>512</b>. It should be appreciated, however, that card reader <b>512</b> may comprise other types of input devices such as, but not limited to, keypads and the types of input devices can depend on the manner in which data is stored on stored value card <b>508</b>.

0074User interface <b>518</b> comprises a display functionality that enables merchant device <b>504</b> to interactively communicate with consumer(s) <b>506</b>. As described in more detail below, user interface <b>518</b> may provide a customer service menu by which customer(s) <b>506</b> may select various types of services, input various types of information, etc.

0075Network interface <b>516</b> comprises any device configured to communicate with a remote computer (e.g., issuing host) via a communications network <b>522</b>. In this regard, it should be appreciated that various aspects of the services provided by merchant device <b>504</b> may be provisioned by a back-end processing functionality. The back-end processing system (e.g., host processing <b>524</b>—<figref idref="DRAWINGS">FIG. 5</figref>) may include one or more service providers, hosts, financial institutions, etc. Therefore, it should be appreciated that the back-end processing system may include an automated clearing house component for exchanging electronic transactions among participating depository institutions. The back-end processing system may include various other components for exchanging funds between accounts, reconciling accounts, settling accounts, etc.

0076As further illustrated in <figref idref="DRAWINGS">FIG. 5</figref>, merchant device <b>504</b> includes a stored value card management system <b>501</b> which includes a customer enrollment module <b>500</b>. Stored value card management system <b>501</b> may include various logical functions, software components, etc. for controlling the provision of financial services. Many of these operations, features, etc. are described above with respect to device <b>100</b>. In the embodiment illustrated in <figref idref="DRAWINGS">FIG. 5</figref>, stored value card management system <b>501</b> includes a customer enrollment module <b>500</b> which controls functional process(es) by which customer(s) <b>506</b> are enrolled in a stored value card program.

0077As illustrated in <figref idref="DRAWINGS">FIG. 5</figref>, merchant device <b>504</b> may be affiliated with one or more stored value card programs <b>526</b>. There may, however, be several other stored value card programs with which merchant device <b>504</b> is not affiliated (i.e., unaffiliated stored value card program(s) <b>528</b>). One of ordinary skill in the art will appreciate that it may be advantageous to provide a marketing program for encouraging customer(s) <b>506</b> of unaffiliated stored value card programs <b>528</b> to join the affiliated programs. In this regard, <figref idref="DRAWINGS">FIG. 6</figref> illustrates an embodiment of a method for implementing a stored value card program. At block <b>602</b>, a new customer enrollment program for a stored value card program may be advertised. The new customer enrollment program may be specifically targeted at customer(s) <b>506</b> of the unaffiliated stored value card programs <b>528</b>. For example, the new customer enrollment program may encourage customer(s) <b>506</b> of the unaffiliated stored value card programs <b>528</b> to switch to one of the affiliated stored value card programs <b>526</b>. At block <b>604</b>, a customer <b>506</b> of one of the unaffiliated stored value card programs <b>528</b> may initiate an enrollment process at merchant device <b>504</b>. At block <b>606</b>, merchant device <b>504</b> may confirm that customer <b>506</b> has a stored value card account with one of the unaffiliated stored value card programs <b>528</b> (e.g., competitor stored value card programs). The confirmation process may be as simple as inquiring with customer <b>506</b>. However, as described below in more detail, the confirmation process may be automated. After confirming that the customer <b>506</b> is a competitor's customer or associated with an unaffiliated stored value card program <b>528</b>, at block <b>608</b>, the new customer <b>506</b> may be enrolled at merchant device without charging a transaction fee.

0078For instance, one or more of the affiliated stored value card programs may charge customers <b>506</b> a transaction fee when funds are initially loaded to the card or when funds are re-loaded to the card. Under the enrollment program described above, the new customers may be enrolled without paying these transaction fees. In other words, in exchange for enrolling in one of the affiliated stored value card programs <b>526</b>, a typical transaction fee may be waived. In this manner, customer(s) <b>506</b> may be encouraged to join an affiliated stored value card program <b>526</b> and, thereby, increase market share.

0079It should be appreciated that the enrollment program may be offered with a number of alternative incentive mechanisms. Furthermore, the transaction fee need not be waived. Rather, an aspect of the enrollment program is that competitor's customers <b>506</b> are identified and enrolled in an affiliated stored value card program <b>526</b> using a different enrollment procedure than for existing customers <b>506</b>. Furthermore, it should be appreciated that in some embodiments, the customer can be enrolled virtually instantaneously or in a matter of minutes.

0080Having described the general components of system <b>502</b> and an exemplary marketing program, various embodiments of customer enrollment module <b>500</b> will be described. <figref idref="DRAWINGS">FIG. 7</figref> is a flow chart illustrating the architecture, operation, and/or functionality of an embodiment of customer enrollment module <b>500</b> for enrolling competitor's customers in an affiliated stored value card program <b>526</b>. At block <b>702</b>, customer enrollment module <b>500</b> initiates a process for enrolling a new customer <b>506</b> in an affiliated stored value card program <b>526</b>. It should be appreciated that the enrollment process may be initiated by a new customer <b>506</b> via user interface <b>518</b>.

0081As illustrated in <figref idref="DRAWINGS">FIG. 8-11</figref>, customer enrollment module <b>500</b> may support an interactive menu functionality that enables customers to select various services. <figref idref="DRAWINGS">FIG. 8</figref> illustrates a perspective view of an embodiment of merchant device <b>504</b> which includes a display controlled by user interface <b>518</b>. In <figref idref="DRAWINGS">FIG. 8</figref>, an enrollment screen <b>802</b> is displayed which enables a customer <b>506</b> to select one or more services via buttons displayed on the screen. For example, in the embodiment of <figref idref="DRAWINGS">FIG. 8</figref>, customer enrollment module <b>500</b> displays an “enroll” button <b>804</b>, a “reload” button <b>806</b>, an “account balance” button <b>808</b>, and an “other” button <b>810</b>. Reload button <b>806</b> enables customer <b>506</b> to initiate a reload process whereby stored value card <b>508</b> may be loaded with additional finds. Account balance button <b>808</b> enables customer <b>506</b> to initiate an account balance inquiry process for checking the current balance associated with stored value card <b>508</b>. Customer <b>506</b> may select other button <b>810</b> to access any of a variety of other services offered by merchant device <b>504</b>.

0082As illustrated in <figref idref="DRAWINGS">FIG. 9</figref>, customer <b>506</b> may initiate an enrollment process by selecting enroll button <b>804</b>. <figref idref="DRAWINGS">FIG. 10</figref> illustrates another screen <b>1002</b> which prompts customer <b>506</b> to specify whether he/she has an existing account for an unaffiliated stored value card program <b>528</b>. Referring again to <figref idref="DRAWINGS">FIG. 7</figref>, at block <b>704</b>, customer enrollment module <b>500</b> may prompt new customer <b>506</b> to swipe a stored value card <b>510</b>. <figref idref="DRAWINGS">FIG. 11</figref> illustrates an example of a screen <b>1102</b> for prompting new customer <b>506</b>. As further illustrated in <figref idref="DRAWINGS">FIG. 11</figref> and mentioned above, merchant device <b>504</b> comprises a card reader <b>512</b> for reading data from stored value card <b>510</b>. In the embodiment illustrated in <figref idref="DRAWINGS">FIG. 11</figref>, card reader <b>512</b> includes a slot (indicated by the down arrow) for inserting and swiping stored value card <b>508</b>. In some embodiments, the customer enrollment module <b>500</b> may also prompt the new customer for information such as personal demographic information, which can include, but is not limited to, age, social security number, driver's license number, name, address, date-of-birth, mother's maiden name, etc. The customer uses the user interface <b>518</b>, which may include a keypad, to provide the information.

0083Referring again to the flow chart of <figref idref="DRAWINGS">FIG. 7</figref> illustrating an embodiment of customer enrollment module <b>500</b>, at block <b>706</b>, data is read from stored value card <b>508</b>. As known in the art, magnetic strip <b>510</b> (<figref idref="DRAWINGS">FIG. 5</figref>) may include various tracks of data containing information related to the customer and the corresponding stored value card account. For instance, stored value card <b>508</b> may include a card number, an account number, a bank identification number, etc. It should be appreciated that customer enrollment module <b>500</b> may not necessarily read all of the data from stored value card <b>508</b>. For instance, customer enrollment module <b>500</b> may be configured to read only the data needed to confirm that customer <b>506</b> has a stored value account with an unaffiliated stored value card program.

0084Therefore, in one embodiment, customer enrollment module <b>500</b> may determine (at block <b>708</b>) a bank identification number (BIN) associated with stored value card <b>508</b>. As known in the art, the bank identification number may correspond to a unique identifier associated with the card issuer, stored value card program, etc. The BIN (or other information read from stored value card <b>508</b>) may be used to determine whether customer <b>506</b> has an existing stored value account with a competitor or an unaffiliated stored value card program <b>528</b>. As illustrated in the embodiment of <figref idref="DRAWINGS">FIG. 7</figref>, customer enrollment module <b>500</b> may determine, at block <b>710</b>, whether the BIN corresponds to an unaffiliated stored value card program <b>528</b>. In this regard, merchant device <b>504</b> may include competitor data <b>712</b> which comprises information about unaffiliated stored value card programs <b>528</b>. Customer enrollment module <b>500</b> may access competitor data <b>712</b> to determine whether the BIN (or other information) is listed and, thereby, identifies customer <b>506</b> as having a stored value account with one of the unaffiliated stored value card programs <b>528</b>.

0085It should be appreciated that competitor data <b>712</b> may be created by generating a list, record, database, etc. of stored value card programs that are not affiliated with merchant device <b>504</b>. Competitor data <b>512</b> may then be stored at merchant device <b>504</b> or elsewhere. For example, in an alternative embodiment, competitor data <b>712</b> may be stored at a remote location on communications network <b>522</b> (e.g., host processing <b>524</b>, etc.).

0086If customer <b>506</b> cannot be confirmed as having an account with an unaffiliated stored value card program <b>528</b>, at block <b>714</b>, customer enrollment module <b>500</b> may enroll new customer <b>506</b> using a standard enrollment procedure. For example, new customer <b>506</b> may be charged a standard transaction fee. However, if customer <b>506</b> is confirmed as having an account with an unaffiliated stored value card program <b>528</b> (block <b>716</b>), at block <b>718</b>, customer enrollment module <b>500</b> may enroll new customer <b>506</b> using an alternative enrollment procedure. As described above, new customer <b>506</b> may be enrolled without being charged a typical transaction fee. It should be appreciated, however, that various alternative enrollment procedures may be employed. An aspect is that customers <b>506</b> of unaffiliated stored value card programs <b>528</b> may be identified by customer enrollment module <b>500</b>. And, once they are identified, customer enrollment module <b>500</b> may employ various enrollment procedures which are consistent with the objectives of the particular marketing program. In this manner, merchant device <b>504</b> may be appropriately configured to complement the marketing program by offering customizable enrollment procedures for existing customers, new customers, existing customers of unaffiliated stored value card programs <b>528</b>, etc.

0087With reference to <figref idref="DRAWINGS">FIGS. 12 and 13</figref>, an alternative embodiment of customer enrollment module <b>500</b> will be described. As mentioned above, customer enrollment module <b>500</b> may employ various enrollment procedures for customers that are identified as having a stored valued account with an unaffiliated stored value card program <b>528</b>. In one embodiment, customer enrollment module <b>500</b> may be configured to facilitate the transfer of the balance on the unaffiliated card to the new stored value card. In this regard, <figref idref="DRAWINGS">FIG. 12</figref> illustrates the architecture, operation, and/or functionality of an alternative embodiment of customer enrollment module <b>500</b>. At block <b>1202</b>, customer enrollment module <b>500</b> reads the stored value card associated with the unaffiliated stored value card program. At block <b>1204</b>, customer enrollment module <b>500</b> identifies the transaction account for the unaffiliated stored value card. At block <b>1206</b>, customer enrollment module <b>500</b> reconciles the transaction account for the unaffiliated stored value account.

0088It should be appreciated that the process of reconciling the transaction account may be performed via communications network <b>522</b> with appropriate service provider(s) (e.g., host processing <b>524</b>, an automated clear house, etc.). For example, customer enrollment module <b>500</b> may initiate an electronic payment, deposit, etc. to reconcile or otherwise pay-off the balance in the transaction account for the unaffiliated stored value account. It should be appreciated that a variety of electronic payments, deposits, etc. may be employed. For instance, customer enrollment module <b>500</b> may employ a master account from which the reconciliation funds originate. Thus, customer enrollment module <b>500</b> may initiate a transfer from the master account to the transaction account for the unaffiliated stored value account. The amount of the transfer may be in the amount of the balance on the unaffiliated stored value card or, in alternative embodiments, may be less than the balance to account for any processing fees, transaction fees, etc.

0089Referring again to <figref idref="DRAWINGS">FIG. 12</figref>, at block <b>1208</b>, customer enrollment module <b>500</b> may establish a second stored value account associated with the new, affiliated stored value card program. At block <b>1210</b>, customer enrollment module <b>500</b> may credit the affiliated stored value account with an amount based on the previous balance on the unaffiliated stored value card. In one embodiment, the amount credited to the affiliated stored value account equals the original balance on the unaffiliated stored value account. In other words, the affiliated stored value account is established without charging any processing fees, transaction fees, etc. As mentioned above, however, the affiliated stored value account may be established in a variety of alternative ways to complement the particular marketing program being employed.

0090<figref idref="DRAWINGS">FIG. 13</figref> is a block diagram illustrating an embodiment of an exemplary method for converting the unaffiliated stored value card to an affiliated stored value card. In the embodiment of <figref idref="DRAWINGS">FIG. 13</figref>, the processing occurs at the back-end processing system (e.g., host processing <b>524</b>). It should be appreciated, however, that various aspects of the account management process may occur at merchant device <b>504</b> or other service provider(s) attached to communications network <b>522</b>. As illustrated in <figref idref="DRAWINGS">FIG. 13</figref>, unaffiliated stored value card program <b>528</b> has an associated stored value account <b>1302</b> containing an account balance <b>1306</b>. As part of the enrollment process, customer enrollment module <b>500</b> confirms that stored value account <b>1302</b> is associated with an unaffiliated stored value card program <b>528</b>. If account <b>1302</b> is unaffiliated with merchant device <b>504</b>, customer enrollment module <b>500</b> may initiate, facilitate, or otherwise control the transfer of account balance <b>1306</b> (as well as account information <b>1308</b>) from unaffiliated account <b>1302</b> to a new stored value account <b>1304</b> associated with an affiliated stored value card program <b>526</b>. It should be appreciated that, where there are multiple affiliated stored value card programs <b>526</b>, customer enrollment module <b>500</b> may be further configured to automatically determine the appropriate stored value card program in which to enroll the new customer.

0091One of ordinary skill in the art will appreciate that stored value card management system <b>501</b> and customer enrollment module <b>500</b> may be implemented in software, hardware, firmware, or a combination thereof. Accordingly, in one embodiment, stored value card management system <b>501</b> and customer enrollment module <b>500</b> are implemented in software or firmware that is stored in a memory and that is executed by a suitable instruction execution system (e.g., processor <b>514</b>).

0092In hardware embodiments, stored value card management system <b>501</b> and customer enrollment module <b>500</b> may be implemented with any or a combination of the following technologies, which are all well known in the art: a discrete logic circuit(s) having logic gates for implementing logic functions upon data signals, an application specific integrated circuit (ASIC) having appropriate combinational logic gates, a programmable gate array(s) (PGA), a field programmable gate array (FPGA), etc.

0093It should be further appreciated that the process descriptions or functional blocks related to <figref idref="DRAWINGS">FIGS. 1-13</figref> represent modules, segments, or portions of logic, code, etc. which include one or more executable instructions for implementing specific logical functions or steps in the process. It should be further appreciated that any logical functions may be executed out of order from that shown or discussed, including substantially concurrently or in reverse order, depending on the functionality involved, as would be understood by those reasonably skilled in the art.

0094Furthermore, stored value card management system <b>501</b> and customer enrollment module <b>500</b> may be embodied in any computer-readable medium for use by or in connection with an instruction execution system, apparatus, or device, such as a computer-based system, processor-containing system, or other system that can fetch the instructions from the instruction execution system, apparatus, or device and execute the instructions. In the context of this document, a “computer-readable medium” can be any means that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. The computer-readable medium can be, for example but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, device, or propagation medium. More specific examples (a nonexhaustive list) of the computer-readable medium would include the following: an electrical connection (electronic) having one or more wires, a portable computer diskette (magnetic), a random access memory (RAM) (electronic), a read-only memory (ROM) (electronic), an erasable programmable read-only memory (EPROM or Flash memory) (electronic), an optical fiber (optical), and a portable compact disc read-only memory (CDROM) (optical). Note that the computer-readable medium could even be paper or another suitable medium upon which the program is printed, as the program can be electronically captured, via for instance optical scanning of the paper or other medium, then compiled, interpreted or otherwise processed in a suitable manner if necessary, and then stored in a computer memory.

0095In the description and claims of the present application, each of the verbs, “comprise” “include” and “have”, and conjugates thereof, are used to indicate that the object or objects of the verb are not necessarily a complete listing of members, components, elements or parts of the subject or subjects of the verb. scope and range of equivalents of the invention. the invention is not limited to those embodiments. Rather, a person skilled in the art will construe the appended claims broadly, to include other variants and embodiments of the invention, which those skilled in the art may make or use without departing from the

0096Although this disclosure describes the invention in terms of exemplary embodiments, the invention is not limited to those embodiments. Rather, a person skilled in the art will construe the appended claims broadly, to include other variants and embodiment of the invention, which those skilled in the art may make or use without departing from the scope and range of equivalents of the invention.