System and method for providing extra lines of credit

BACKGROUND OF THE INVENTION

I. Field of the Invention

This invention relates to credit card products and to systems and methods for providing and using such products. More particularly, the invention relates to systems and methods for modifying an existing credit card product to provide one or more extra lines of credit and associating one or more vendors with one or more extra lines of credit on a credit card product. The invention also relates to systems and methods for editing vendor profiles associated with one or more extra lines of credit for existing and newly issued credit card products.

II. Background and Material Information

Credit card products have become so universally well known and ubiquitous that they have fundamentally changed the manner in which financial transactions and dealings are viewed and conducted in society today. Credit card products are most commonly represented by plastic card-like members that are offered and provided to customers through credit card issuers (such as banks and other financial institutions). With a credit card, an authorized customer or cardholder is capable of purchasing services and/or merchandise without an immediate, direct exchange of cash. With each purchase, the cardholder incurs debt to their credit card account, which the cardholder may thereafter pay upon receipt of a monthly or otherwise periodic statement. In most cases, the cardholder will have the option to either fully pay the outstanding balance or, as a matter of necessity or choice, defer at least a portion or the balance for later payment with accompanying interest or finance charges for the period during which payment of the outstanding debt is deferred (also referred to as a revolving charge credit line).

The spending power of a credit card (i.e., the maximum amount of funds that is financed to the cardholder for making purchases) is typically limited to a particular amount that is predetermined by the issuer of the card. This amount is commonly referred to as the “credit limit” of the credit card. The credit limit provides the cardholder with a line of credit (also referred to as a credit line). The size of the issuer-imposed credit limit is generally based on a number of non-exclusive factors, the most important of which are often the cardholder's earning capacity and the cardholder's credit history. When purchases are made or debts incurred with the credit card, the available portion of the credit limit is reduced by the purchase or debt amounts. In addition, interest and/or finance charges are also subtracted from the available portion of the credit limit on a periodic basis. The total debits on a credit card are referred to as the “outstanding balance,” while the remaining or available balance of the credit limit is typically called the “available balance” and reflects the dynamically adjusted current spending power of the credit card. The cardholder may increase the available balance up to the credit limit, by paying the outstanding balance to the issuer.

Credit card issuers usually provide general purpose credit cards that may be used for a plurality of different goods and services and with a wide variety of merchants. For example, a Visa, MasterCard, American Express, Dinner's Club are examples of general purpose credit cards. Since general purpose credit cards are intended for “general use” by a cardholder, they are typically not associated with a single merchant/vendor or limited in use.

Some credit card issuers or merchants issue private label credit cards (e.g., a Sears Charge Card) for use exclusively with a merchant's goods and/or services. Such private label credit cards may be issued to customers of the merchant to provide an incentive to purchase the goods and/or services of the merchant. Private label credit cards may be issued with different types of terms and conditions. For example, a private label credit card may include a private label credit line with a predetermined credit limit and the possibility of deferring payment on an outstanding balance with a finance or interest charge (e.g., a revolving credit line). A private label credit card may also include a charge account that requires the cardholder to pay the balance in full at the end of each month or the card may include an installment line of credit where the cardholder is required to make a fixed, periodic payment to the merchant (or the merchant's representative) until the installment debt is paid.

Private label credit cards have several disadvantages. For example, the credit line of a private label credit card may only be used to make purchases in connection with the merchant's goods and/or services. As a result, a private label credit card limits a customer's overall use of the credit card. Moreover, if the private label credit card includes a charge account that requires full payment of the outstanding balance at the end of the month, the cardholder tends to limit use of the merchant's credit card to an amount that can be paid at the end of the month.

To overcome the above mentioned disadvantages, credit cards have been created that offer dual lines of credit. Dual line credit cards include a general purpose credit line and a private label credit line. Dual line cards provide cardholders with the ability to purchase goods from a specific merchant or make general purchases for a wide variety of goods or services. Methods and systems for providing dual line credit cards are described in U.S. patent application Ser. No. 09/659,585, filed Sep. 11, 2000, which is expressly incorporated herein by reference in its entirety.

Although dual line credit cards provide advantages over conventional credit cards, they require credit card issuers to generate and issue new accounts or cards to customers. This requires customers to prepare new credit applications that card issuers have to process before a new card may be issued. Customers must therefore wait until the new credit card is received before they can use the dual line credit card. Furthermore, although the use of dual lines of credit on a single card provides versatility for customers and merchants, the resources used by the card issuer to generate such credit cards increases with each accepted application. Also, dual line credit cards are still limited in the sense that each private label credit line is associated with a specific merchant or vendor; and, thus restricts a customer's purchasing power with the private label credit line.

SUMMARY OF THE INVENTION

Methods, systems and articles of manufacture consistent with the principles of the present invention enable credit card issuers to offer selected customers with the option of obtaining extra lines of credit for their existing cards.

Consistent with the principles of the invention, a credit card issuer determines a selected customer base from which to offer additional lines of credit. Once the issuer sets up a database associated with each of these customers' accounts, offers are extended to these customers using a variety of communication channels. These channels may include conventional solicitation techniques, as well as on-the spot offers while customers are purchasing goods.

Consistent with the principles of the invention, credit card issuers in partnership with participating vendors may offer a customer one or more extra lines of credit that are each associated with a specific group of vendors. Vendor group credit lines may be selected by each customer or may be determined by the card issuer.

Consistent with the principles of the invention, credit card issuers may authorize transactions by customers attempting to purchase goods and/or services from specific vendors using their credit card product with extra credit. The credit card issuer may authorize transactions based on vendor lists associated with the customer. Furthermore, the card issuers may solicit and register new customers for the extra credit card products with multiple lines of credit during a transaction session, whether on-line or off line.

Methods, systems and articles of manufacture consistent with the principles of the present invention enable credit card holders to obtain additional credit lines on their existing cards, without having to wait for a new card. Furthermore, methods, systems and articles of manufacture consistent with the present invention enable customers and card issuers to chose vendors that may be associated with the extra lines of credit.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention, as described. Further features and/or variations may be provided in addition to those set forth herein. For example, the present invention may be directed to various combinations and subcombinations of the disclosed features and/or combinations and subcombinations of several further features disclosed below in the detailed description.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate various embodiments and aspects of the present invention and, together with the description, explain the principles of the invention. In the drawings:

<figref idref="DRAWINGS">FIG. 1</figref> illustrates an exemplary system environment in which the features and principles of the present invention may be implemented;

<figref idref="DRAWINGS">FIG. 2</figref> is an exemplary flowchart for offering and adding extra credit lines to existing credit card accounts, in accordance with the present invention;

<figref idref="DRAWINGS">FIG. 3A</figref> is an exemplary flowchart for processing responses to offers for extra credit lines, in accordance with the present invention;

<figref idref="DRAWINGS">FIG. 3B</figref> is an exemplary segment database for activating extra lines of credit, in accordance with the present invention;

<figref idref="DRAWINGS">FIG. 3C</figref> is an exemplary flowchart for processing edits to a customer's vendor profile, in accordance with the present invention;

<figref idref="DRAWINGS">FIG. 4</figref> is another exemplary system environment for providing a credit card with multiple lines of credit, in accordance with the present invention;

<figref idref="DRAWINGS">FIG. 5A</figref> is an exemplary flowchart for processing a purchase transaction, in accordance with the present invention;

<figref idref="DRAWINGS">FIG. 5B</figref> is an exemplary flowchart for authorizing a purchase transaction, in accordance with the present invention;

<figref idref="DRAWINGS">FIG. 6</figref> is another exemplary system environment for providing a credit card with multiple lines of credit, in accordance with the present invention;

<figref idref="DRAWINGS">FIGS. 7A and 7B</figref> are exemplary flowcharts for processing a purchase transaction in the exemplary environment shown in <figref idref="DRAWINGS">FIG. 6</figref>, in accordance with the present invention;

<figref idref="DRAWINGS">FIG. 7C</figref> is an exemplary offer for an extra line of credit, in accordance with the present invention; and

<figref idref="DRAWINGS">FIG. 7D</figref> is another exemplary offer for an extra line of credit, in accordance with the present invention.

DETAILED DESCRIPTION

Reference will now be made in detail to the invention, examples of which are illustrated in the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts.

Generally, the present invention is directed to a system and method for providing one or more extra lines of credit on existing credit cards. In accordance with one embodiment of the present invention, credit card holders are presented offers for obtaining extra line(s) of credit for their existing credit cards. These offers may be presented through conventional solicitation techniques, as well as during customer purchase transactions. The additional line(s) of credit may include, for example, one or more private label credit line(s) and a general purpose credit line. The private label credit line(s) may be associated with a variety of vendor partnership structures. That is, a customer may have a private label credit line associated with a single vendor, or with a group of vendors. Purchases to be charged to the private label credit line(s) may be only authorized at vendor sites associated with the vendor partnership structure. The general purpose credit line may also be provided to permit purchases for a variety of goods and/or services from merchants that accept the general purpose credit line.

Methods and systems consistent with the principles of the present invention permit a cardholder or consumer to obtain a credit card with multiple lines of credit without waiting for a newly issued card. Once the card issuer has authorized and processed a customer's acceptance of an extra credit plan, the customer may carry only a single credit card that can be used both as a general credit card and as a private label credit card. Moreover, a card issuer may offer customers a wide variety of options corresponding to the types of vendors the private label credit line(s) are to be associated with. Also, because the popularity of on-line shopping is increasing, card issuers may offer the same advantages to customers who shop at a card issuer's branded web site, as well as at specific vendor websites. Thus, the features of the present invention may be used to target existing credit card customers and promote or encourage on-line shopping at specific web site(s).

The present invention also relates to systems and methods for upgrading or modifying an existing credit card product with multiple lines of credit, wherein one or more lines of credit (such as a general purpose credit line) is embedded into a main line of credit (such as a private label line of credit). Each embedded credit line may permit the cardholder to make revolving credit charges for a wide variety of goods and services. The embedded credit lines may include, for example, different types of the credit lines (e.g., general purpose credit lines), with the main line of credit (e.g., the private label line of credit) providing an incentive to the cardholder to make purchases with specific merchant(s). Each embedded credit line (i.e., a general purpose credit line) may have a maximum credit limit that is greater than, equal to or less than the maximum credit limit for the main line of credit (i.e., the private label credit line). Any charge to the embedded credit line may cause a dollar-for-dollar reduction in the amount of available credit for the main credit line. For example, with a main credit line that is established as a private label credit line of $6,000, and an embedded credit line that is established as a general purposed credit line of $4,000, charges applied to the general purpose credit line will reduce the available credit under the private label credit line. For instance, a $1,500 charge to the general purpose credit line will reduce the available credit under the private label credit line by $1,500 to $4,500 (assuming there are no other outstanding charges). Such a charge will also reduce the available credit under the general purpose credit line by $1,500 to $2,500. Additionally, the private label credit line may be configured to have a credit line that is unaffected by charges applied to the general credit line.

The above-noted features and other aspects and principles of the present invention may be implemented in various environments. Such environments and related applications may be specially constructed for performing the various processes and operations of the invention or they may include a general purpose computer or computing platform selectively activated or reconfigured by program code to provide the necessary functionality. The processes disclosed herein are not inherently related to any particular computer or other apparatus, and may be implemented by a suitable combination of hardware, software, and/or firmware. For example, various general purpose machines may be used with programs written in accordance with teachings of the invention, or it may be more convenient to construct a specialized apparatus or system to perform the required methods and techniques.

The present invention also relates to computer readable media that include program instruction or program code for performing various computer-implemented operations based on the methods and processes of the invention. The program instructions may be those specially designed and constructed for the purposes of the invention, or they may be of the kind well-known and available to those having skill in the computer software arts. Examples of program instructions include for example machine code, such as produced by a compiler, and files containing a high level code that can be executed by the computer using an interpreter.

<figref idref="DRAWINGS">FIG. 1</figref> illustrates an exemplary system environment <b>1000</b> in which the features and principles of the invention may be implemented. As illustrated in <figref idref="DRAWINGS">FIG. 1</figref>, the system environment <b>1000</b> includes a plurality of customers (<b>1010</b>-<b>1050</b>), a response vehicle system <b>1100</b> including a plurality of different response vehicles (<b>1110</b>-<b>1150</b>), a credit card issuer <b>1200</b>, a central database <b>1300</b> and a communications channel <b>1400</b>.

Each customer in system environment <b>1000</b> is associated with a different customer category. For instance, customer(s) <b>1010</b> may be web site customer(s) that access and retrieve information through a web site. This web site may be a branded web site that is operated by one or more vendors, or may be a web site operated by the card issuer. Also, the web site may include web sites operated by vendors that are in partnership with the card issuer <b>1200</b>. Customer(s) <b>1020</b> may be telephone customers that access and receive information using conventional telephonic communication techniques and systems. This includes, for example, wireline and wireless telephony systems. Customer(s) <b>1030</b> may be conventional mail customer(s) that access and receive information by conventional mail techniques and services. This includes, for example, customer(s) that are part of a credit card issuer's mailing list. Customer(s) <b>1040</b> may be customer(s) that access and receive information using electronic mail services, and customer(s) <b>1050</b> may be point of sale customer(s) that perform purchase transactions and receive information at a vendor's point of sale terminal or physical store location. Customer(s) <b>1010</b>-<b>1050</b> may also represent entities (such as an individual, a group of individuals, corporate entities, or any combination thereof), that hold credit card accounts with the credit card issuer <b>1200</b>. The categories of customer(s) illustrated in <figref idref="DRAWINGS">FIG. 1</figref> are exemplary and should not be considered limiting. For example, a variety of different customer categories may also be implemented in environment <b>1000</b>, such as customers using kiosk computers or personal digital assistants (PDAs).

Response vehicle <b>1100</b> represents a system for handling communications between the customer(s) <b>1010</b>-<b>1050</b> and credit card issuer <b>1200</b>. Response vehicle <b>1100</b> may be part of a credit card issuer's network and, as shown in <figref idref="DRAWINGS">FIG. 1</figref>, include a plurality of response vehicles <b>1110</b>-<b>1150</b> that correspond to different category groups of customer(s) <b>1010</b>-<b>1050</b>. Each response vehicle is responsible for handling communications to and from a particular customer. For example, telephone response vehicle <b>1120</b> handles telephonic communications between the customer <b>1020</b> and credit card issuer <b>1200</b>. Thus, in the event credit card issuer <b>1200</b> wishes to solicit customers telephonically, response vehicle <b>1120</b> includes the necessary systems to support such operations. Response vehicle <b>1130</b>, on the other hand, includes the necessary systems and organizations to handle conventional mail processing to and from customer(s) <b>1030</b>. Response vehicle system <b>1140</b> includes the necessary systems and organizations to process electronic mail transactions with customer <b>1040</b>. Response vehicle <b>1150</b>, in turn, includes systems and organizations that enable communications with customers located at a point of sale (POS) terminal. Response vehicle system <b>1100</b> may receive responses from the customer(s) and forward them to card issuer <b>1200</b> for appropriate processing. Notifications to the customer(s) also are performed from issuer <b>1200</b> to the customer(s) through response vehicle <b>1100</b>.

Communication channel <b>1400</b> facilitates communications between the various customer(s) and response vehicle system <b>1100</b> illustrated in <figref idref="DRAWINGS">FIG. 1</figref>. Such communications may include communications related to offering and issuing extra lines of credit for existing credit cards. Communications channel <b>1400</b> may include, for example, a telephony-based network, a local area network (LAN), a wide area network (WAN), a dedicated intranet, the Internet, and/or a wireless network. Further, any suitable combination of wired and/or wireless components and systems may be incorporated into communications channel <b>1400</b>. Any suitable combination of point-to-point communications or networked communications may also be incorporated into communication channel <b>1400</b> to facilitate communication between the different entities illustrated in <figref idref="DRAWINGS">FIG. 1</figref>. Moreover, any part of communication channel <b>1400</b> may implemented through traditional infrastructures or channels of trade, to permit operations associated with the extra credit offers to be performed manually or in-person by the various entities illustrated in <figref idref="DRAWINGS">FIG. 1</figref>.

Credit card issuer <b>1200</b> receives communication information from response vehicle system <b>1100</b> and processes it using central database <b>1300</b>. Database <b>1300</b> may contain various information including credit information, potential customer lists, risk scores for potential extra credit customers, approved extra credit customers, private label credit limits for approved cardholders, general credit limits for approved cardholders, vendor tables including merchant identification numbers, customer information, purchase information, authorization information, and/or settlement information. Issuer <b>1200</b> also sends information to the response vehicle system <b>1100</b> for delivery to the appropriate customers. Credit card issuer <b>1200</b> is responsible for providing various credit cards and establishing associated accounts. Credit card issuer <b>1200</b> may include one or more of the following: a bank, an acquiring bank, a merchant bank, a merchant or any commercial institution capable of providing a credit card consistent with the features disclosed herein. Further, although <figref idref="DRAWINGS">FIG. 1</figref> only illustrates one credit card issuer <b>1200</b>, it is of course possible that more than one credit card issuer be provided in system environment <b>1000</b>.

<figref idref="DRAWINGS">FIG. 2</figref> illustrates an exemplary process associated with soliciting offers and processing responses for extra credit lines from credit card customers. According to an aspect of the invention, to issue additional lines of credit on existing credit cards, credit card issuer <b>1200</b> may identify specific customers to receive an extra credit line offer (Step <b>210</b>). To evaluate and identify specific credit card customers, several factors may be considered by the card issuer <b>1200</b>. Such factors may be based on credit information received from one or more credit information sources (i.e., sources that provide credit information to credit card issuer <b>1200</b>). Credit information may also be provided to credit card issuer <b>1200</b> when customers respond to credit card offers from issuer <b>1200</b>. Moreover, credit information may be requested by issuer <b>1200</b> while determining a target customer group to extend offers. Credit information may include credit history information and/or personal information (e.g., income, employment status, etc.) that is used when evaluating a customer's credit worthiness. Credit information sources may comprise commercial credit information source (such as TRW/Experian, Equifax and TransUnion or a similar commercial credit service bureau) and/or private credit information services. Credit information sources may also represent credit information that was provided by customers, such as when a customer applied for their existing credit card.

The credit information is analyzed to determine the credit worthiness or a level of risk associated with each cardholder. If a customer has sufficient credit for one or more extra credit lines, credit card issuer <b>1200</b> may approve the customer for inclusion in a target customer group. The target customer group includes all identified customers that card issuer <b>1200</b> will provide offers for extra line(s) of credit.

In accordance with the present invention, the extra line(s) of credit may be associated with private label credit lines. The extra line(s) of credit may include a single extra credit line or multiple extra line(s) of credit. For example, an existing credit card may include two lines of credit or “buckets”. The first “bucket”, may be a general purpose line of credit and the second “bucket” may be a cash advance line. Extra credit line(s) for this credit card may include a single “3^rdbucket” or additional “4^thand 5^thbuckets.” These buckets each may be dedicated to specific merchants or vendors, or groups thereof. Vendors may include merchants that offer goods and/or services to consumers. Each merchant may be a specific merchant of goods and/or services associated with private label credit line(s) of the present invention. Merchants may also include one or more merchants that offer goods and/or services that can be purchased through the general purpose credit line of the invention. In general, cardholders may make purchases from merchants with credit cards, including credit cards of the present invention that have been upgraded or modified to include multiple lines of credit.

Once card issuer <b>1200</b> has identified a target group of customers (which may be stored in central database <b>1300</b>) it generates offers for these selected customers. The offers may vary for each customer based on the credit worthiness determined in Step <b>210</b> (see <figref idref="DRAWINGS">FIG. 2</figref>). That is, a customer with a high credit risk may be offered an extra credit line with a relatively low available balance (e.g., $500). Another customer with a lower credit risk may be offered an extra line of credit with a relatively high available balance (e.g., $5000). Moreover, additional credit lines or buckets may be offered to customers with low credit risks, while higher risk customers may be limited to a single extra credit line. The options available to the card issuer <b>1200</b> may extend beyond these options as well. Specific types of vendors or vendor groups may be associated with selected buckets offered to particular customers. For example, a high risk customer may be offered an extra credit line that is associated with a single vendor, while a low risk customer may be offered a plurality of buckets, with each bucket associated with a plurality of vendors. These options and their processing are further described with reference to <figref idref="DRAWINGS">FIG. 3A</figref>.

In order to provide the versatility associated with vendor based credit line(s), a partnership may be established between one or more vendors and credit card issuer <b>1200</b>. That is, selected vendors may be included in a master vendor list maintained by card issuer <b>1200</b>, thus enabling customers of issuer <b>1200</b> to benefit from private label lines of credit associated with vendors. Vendors benefit from the additional business created by customers of issuer <b>1200</b> using their extra credit line(s) at their sites to purchase goods and/or services.

Once the offers are generated, they are sent to response vehicle system <b>1100</b> for distribution to the customers (Step <b>220</b>). Each response vehicle in vehicle <b>1100</b> processes the offers in order to provide them to the customers through the proper medium or communication channel. For instance, response vehicle <b>1110</b> formulates offers for generation and viewing on one or more web sites. These web sites may be associated with a card issuer's web site or sites that are operated by selected vendors. Response vehicle <b>1150</b>, on the other hand, processes the offers for presentation to customers who are performing a transaction at a point of sale terminal or at a vendor's site. Once each response vehicle has processed the offers, they are sent to the specified customers for response (Step <b>220</b>). Customers <b>1010</b>-<b>1050</b> respond to the offers using the medium associated with their category. The responses are sent back to response vehicle system <b>1100</b> (Step <b>230</b>), where they are processed for presentation to card issuer <b>1200</b> (Step <b>240</b>).

Based on the category of a customer, responses may or may not be processed immediately. For instance, responses may be received and processed instantaneously for customers <b>1010</b>, <b>1020</b> and <b>1050</b>, while responses from customers <b>1030</b> and <b>1040</b> may be delayed. For example, suppose a customer <b>1010</b> using a personal computer, views a web site operated by issuer <b>1200</b>. The site may include a designated page that is presented to the customer that displays the offer determined by issuer <b>1200</b>. The customer may decide to accept or decline the offer by merely selecting an icon representing their choice. The selection is then sent back to response vehicle <b>1110</b>. Response vehicle <b>1110</b> processes the response and prepares it for presentation to card issuer <b>1200</b>. The response is processed at card issuer <b>1200</b> and a notification message is sent back to customer <b>1010</b>, through response vehicle <b>1110</b> (Step <b>250</b>). The notification message indicates to the customer that their response to an offer has been processed and whether or not an additional credit line was approved and available for use. The notification messages may be displayed through the page that the customer was viewing when the offer was presented or on a separate page. Further description of how card issuer <b>1200</b> processes the responses is explained below with reference to the description of <figref idref="DRAWINGS">FIG. 3A</figref>.

As can be seen, a customer who has accepted an offer through a web site may receive immediate notification that an extra credit line for their credit card is available for use. On the other hand, a customer who has been solicited by conventional mail, such as customer <b>1030</b>, may respond to the offer by mailing back an acceptance form to the card issuer. The response form would be received and processed by response vehicle <b>1130</b>, and eventually processed by credit card issuer <b>1200</b>. Notification of the activation of an extra credit line may then be sent back to the customer using the same conventional mail process.

There may be a plurality of variations available to card issuer <b>1200</b> when communicating with customers. That is, a mail customer <b>1030</b> may wish to respond by telephone or through a web site. Additionally, customers may respond by one medium, and request notification by another. For instance, a customer <b>1030</b> who has received an offer in the mail, may respond by mail, yet request notification by email. Accordingly, a variety of user friendly options are available to customers for receiving and responding to the offers presented by card issuer <b>1200</b>. The above descriptions are for illustration purposes alone and should not be viewed as limitations to the present invention. One of ordinary skill in the art would realize that any number of combinations of communication techniques may be implemented without departing from the principles of the present invention.

<figref idref="DRAWINGS">FIG. 3A</figref> illustrates the functions performed by credit card issuer <b>1200</b> when processing customer responses. Prior to generating offers or receiving responses, card issuer <b>1200</b> prepares central database <b>1300</b> for receiving extra credit information for each account. Central database <b>1300</b> may include a plurality of tables that store account information for each customer holding credit cards issued from credit card issuer <b>1200</b>. One of these tables may be a main customer table that stores information reflecting each customer's account status. The main table may include “segments” that represent various information, such as the line(s) of credit available for a particular customer, outstanding and available balances, account numbers and any other cardholder data. To prepare central database <b>1300</b> for extra credit processing, card issuer <b>1200</b> creates additional segments in the main table that represent additional lines of credit for customers (Step <b>310</b>A). Thus, if credit card issuer <b>1200</b> is preparing to offer three additional lines of credit or buckets, three new segments are created. Alternately, card issuer <b>1200</b> may create a new database table exclusively for customers included in the target customer group determined in Step <b>210</b> of <figref idref="DRAWINGS">FIG. 2</figref>. The new table would include the new segments reflecting the extra buckets offered to the target customer group.

<figref idref="DRAWINGS">FIG. 3B</figref> illustrates an exemplary main table <b>300</b>B after a third segment has been added. Segment <b>1</b> (<b>310</b>B) may be associated with a general purpose credit line, while segment <b>2</b> (<b>320</b>B) may be associated with a cash advance credit line. In accordance with an aspect of the present invention, credit card issuer <b>1200</b> creates a new segment (<b>330</b>B) in main table <b>300</b>B associated with an extra line of credit. Each segment <b>310</b>B, <b>320</b>B and <b>330</b>B may include fields associated with a credit card customer's credit card account. For example, each segment in main table <b>300</b>B may include an available balance field (<b>340</b>B), an interest rate field (<b>350</b>B), a transaction fee field (<b>360</b>B) and an activation flag field (<b>370</b>B). Available balance filed (<b>340</b>B) may be associated with an available balance for each respective credit line. Thus, customer A in main table <b>300</b>B, has an available credit of $10,000, $2000 and $1000 for a general purpose credit line, cash advance credit line and an extra credit line, respectively. Field <b>350</b>B may represent the interest rate applied to the respective credit line. That is, the interest rate applied to the general purpose credit line associated with customer A is 16.5%. Field <b>360</b>B may represent a fee applied a particular customer's account for each transaction. Thus, for example, each time customer B uses his extra line of credit, a $2.50 fee is charged to his account. Field <b>370</b>B may represent a flag that is set when a particular segment is activated. As shown in <figref idref="DRAWINGS">FIG. 3B</figref>, the extra credit line for customers A and B has been activated, while customer C's extra line of credit is not. The fields shown in <figref idref="DRAWINGS">FIG. 3B</figref> are exemplary, and should not be considered limiting. Any number of fields may be added to each segment to allow a credit card issuer the versatility in maintaining a customer's credit card account.

Once the new segments are created in central database <b>1300</b>, card issuer <b>1200</b> filters customer responses received from response vehicle <b>1100</b>. The filtering process determines whether a customer has accepted or declined the offers sent by card issuer <b>1200</b> (Step <b>316</b>A). Card issuer <b>1200</b> generates notification messages for customers who have declined the extra credit offer, and sends the messages to response vehicle <b>110</b> for delivery to these customers. However, for customers who have accepted the offer, the appropriate segment(s) in the main table are activated (Step <b>318</b>A). Activation of the segments provide available credit balances for each buckets associated with an activated segment.

In an alternate aspect of the present invention, card issuer may decide to activate all new segments in database <b>1300</b> for each customer in the target customer group, prior to processing the responses. According to this aspect of the invention, credit card issuer <b>1200</b> activates the new segments when they are created (Step <b>312</b>A). Then, customers who have accepted the offers are filtered (Step <b>314</b>A). After filtering, the process is directed to Step <b>320</b>A described later. This alternate process may reduce processing time by eliminating the activation step when a response is received by a customer. However, by activating the segments prior to the filtering process, customers who have declined the offers will have activated segments. In this scenario, these customers will simply not be notified of the active buckets. A modification to this aspect of the invention may include using the results of the filtering process to deactivate all segments for customers who have declined the offers. Deactivation may be performed immediately, or at a later time such as when an expiration date is reached.

After filtering and activation, card issuer <b>1200</b> may determine whether it is implementing a customer profile option (Step <b>320</b>A). Customer profiles may be used by card issuer <b>1200</b> to obtain information related to a customer's interests. Profiles may be generated based on a variety of information, including past purchases, visited web sites and surveys. Customer profiles may also include demographic information collected from a variety of sources, such as Internet related sources. This may be performed by retrieving user identification information associated with a customer requesting selected web pages, using techniques well known in the art, such as cookies, and checking the identification information against a user profile resource. This process allows the customer, or a group of customers, to be associated with particular social, economic, educational and/or commercial interests. The process of utilizing customer or group profiles for classifying customers for target marketing is well known in the art, and the present invention can implement any number of these techniques. If it is determined that customer profiles are being used by card issuer <b>1200</b> (Step <b>320</b>A; YES), the profile for a selected customer is accessed (Step <b>322</b>A). Along with profiles, card issuer <b>1200</b> may also control whether the customer has a choice in selecting vendors for their extra line(s) of credit (Step <b>324</b>A). If card issuer <b>1200</b> denies selections by customers, the appropriate vendor groups may be selected automatically, based on the customer's profile (Step <b>326</b>A). This option, although limiting for the customer, has great versatility for the credit card issuer <b>1200</b>.

This versatility enables card issuer <b>1200</b> to provide a variety of regulated options for its customers, based on their profiles. For example, a customer who is a college student may have a profile that indicates not only personal interests but also the school attended by the customer. Card issuer <b>1200</b> may offer this customer extra credit lines that are strictly associated with the college or university attended by the customer. Card issuer <b>1200</b> may authorize transactions on a selected bucket only at vendor sites located at or near the university. These sites may include university operated bookstores, campus restaurants and other vendor sites that may be found on or near the college campus. This option gives student customers an incentive to accept the card issuer's offer, while at the same time allowing credit card issuer <b>1200</b> to offer extra buckets to what statistically may be a group of high risk customers. Card issuer <b>1200</b> may also limit a single vendor to a credit line, as in the above example, or group several vendors into vendor groups. These groups may be authorized for use with selected credit lines added to a customer's card.

Vendor groups may be created in a number of different ways. One such way may be to categorize vendors based on related goods or services that are offered. Examples of categories may include athletics, outdoor activities (fishing, camping, etc.), travel, music and electronics. Broader categories such as those directly associated with department stores and gas stations may be used as well. Card issuer <b>1200</b> may create predetermined vendor groups including vendors that offer goods and/or services related to the group. The created vendor groups may then be selected for a customer based on the customer's profile. Therefore, for a customer who has a profile that associates them with music, a vendor group that includes merchants that offer goods and/or services associated with music may be associated with the customer's newly created line of credit. Additionally, considering the previous example with the college student, card issuer <b>1200</b> may provide a vendor group including the college's merchants, as well as merchants that provide groceries, such as selected supermarkets. As can be seen, a number of options are available to card issuer <b>1200</b> for selecting vendors for target customers.

Once credit card issuer <b>1200</b> has selected the appropriate vendor to be associated the customer's new bucket(s), they may be added to a vendor table that is unique to the customer (Step <b>328</b>A). Vendor tables enable card issuer <b>1200</b> to track which vendors are associated with a particular customer. Card issuer <b>1200</b> maintains a master list stored in a vendor table corresponding to the issuer. The master list includes all vendors that have a partnership agreement with card issuer <b>1200</b>. The partnership enables customer's of card issuer <b>1200</b> to use the extra lines of credit at sites associated with these vendors, provided the customer is authorized to purchase goods and services at these sites. Vendor tables may be stored in database <b>1300</b>, or may be stored remotely. Thus, as can be seen, the invention can provide card issuer <b>1200</b> strategic control over the types of vendors associated with a customer's new credit lines. Once each selected vendor is added to the customer's vendor table, processing is forwarded to Step <b>348</b>A, described later.

Although maintaining a customer's vendor selections may give strategic control to a card issuer, in order to promote use of the extra credit lines, customer-controlled, vendor selection may also be provided. Converse to having total control over a customer's vendor selection, a card issuer may allow customer input in choosing vendors. If this is the case, the customer may be presented with an option to select vendors (Step <b>330</b>A).

The process of presenting vendor options to a customer is based on the medium the customer is communicating with credit card issuer <b>1200</b>. Response vehicle system <b>1100</b> processes vendor option presentation information from credit card issuer <b>1200</b>, and forwards them to the customers through communications channel <b>1400</b>. For instance, customer <b>1010</b> may be presented with a web page including the vendor selection options. Response vehicle <b>1110</b> would send the page to customer <b>1010</b> after receiving the appropriate vendor information from credit card issuer <b>1200</b>. Additionally, if a customer is communicating with credit card issuer <b>1200</b> through convention telephonic channels, response vehicle <b>1120</b> would present the vendor options to customer <b>1020</b> using standard telephone techniques.

If the customer decides not to participate in the vendor selections (Step <b>332</b>A; NO), card issuer may select the vendors for the customer based on the customer's profile (Step <b>326</b>A). On the other hand, card issuer <b>1200</b> may also apply each vendor in the master list to the customer's vendor table, (Step <b>346</b>A), enabling the customer full access to all participating vendors. If the customer decides to participate in vendor selections (Step <b>332</b>A; YES), card issuer may offer the customer selected vendor groups for selection (Step <b>334</b>A). Using this option, although the customer is selecting vendors, the card issuer still maintains some control over vendor selections based on the vendor groups it offers to the customer. For example, if card issuer <b>1200</b> determines that a customer has a higher credit risk than other profiled customers, the vendor groups offered to the high risk customer may not include vendors that are offered to the lower risk customers. Vendor groups may be categorized for different customer risk profiles depending on various factors, including the type or average cost of goods and services offered by the vendors. This option enables credit card issuer <b>1200</b> to control vendor relationships with selected customers while still providing options to the customer. Once the selections are made by the customer, they are processed such that the selected vendors in the selected vendor groups are added to the customer's vendor table (Step <b>336</b>A). Processing then continues to Step <b>348</b>A, described later.

Referring back to Step <b>320</b>A, in the event card issuer <b>1200</b> does not implement customer profiles, (Step <b>320</b>A; No), customers may still have the option to participate in vendor selections. If card issuer <b>1200</b> supports this option (Step <b>338</b>A; YES), the customer is presented with the entire master list of vendors in partnership with card issuer <b>1200</b> (Step <b>340</b>A). A customer may select from the list and the selections are appropriately added to the customer's vendor table (Steps <b>342</b>A and <b>344</b>A). Processing is then forwarded to Step <b>348</b>A. However, in the event card issuer does not support customer input for vendor selections (Step <b>338</b>A; NO), every vendor in the master list is added to the customer's vendor table (Step <b>346</b>A), and processing is passed to Step <b>348</b>A.

Once credit card issuer <b>1200</b> has received and processed all the responses from the customers regarding vendors and acceptance of the extra credit line, notification messages are generated (Step <b>348</b>A). As indicated before, the notification messages are passed to the customer's through the appropriate response vehicle and indicate to the customers that their extra credit line is now available. The notifications may indicate to the customers the available balance, the vendors associated with each new credit line, as well as other known credit card information.

It should be noted that although the steps illustrated in <figref idref="DRAWINGS">FIG. 3A</figref> may be related to those customer categories where the customer may respond immediately to offers, the steps may be applied to the other customer categories as well. That is, for conventional mail customers, the offers presented in the mail product from issuer <b>1200</b> may include predetermined vendor groups that the customer may select. Alternatively, the offer may designate vendors for the extra credit line(s). Accordingly, when the customer accepts the offer, either the predetermined vendor selections made by issuer <b>1200</b> would be activated or the selections indicated in the customer's response would be activated.

In addition to associating one or more vendors to one or more extra lines of credit when these credit lines are established, features of the present invention enable a customer to dynamically edit the vendor profile associated with their credit card account. <figref idref="DRAWINGS">FIG. 3C</figref> illustrates an exemplary process for editing a vendor profile for a customer's extra credit line(s). Once extra credit line(s) are established for a customer's credit card account, the customer may edit the vendor(s) associated with these credit lines. To edit a vendor profile, a customer contacts the credit card issuer <b>1200</b> through the appropriate response vehicle associated with the medium the customer chooses to use (i.e., website, email, telephone, etc.) (Step <b>310</b>C). From there, the customer indicates to the credit card issuer <b>1200</b> that they wish to edit their vendor group profile (Step <b>312</b>C). The customer may then indicate whether they want to add or delete vendors to/from the vendor profile (Step <b>314</b>C). If the customer decides to delete vendors their vendor profile (Step <b>314</b>C; DELETE), the customer may be queried to select the vendor(s) they want removed. This removal process may be performed in a number of different manners. One way would be for credit card issuer <b>1200</b> to provide the list of vendor(s) associated with a customer's designated extra credit line. The customer may then select specific vendors to be removed from the list. Alternately, the customer may simply provide to credit card issuer <b>1200</b> the vendor(s) when want removed from their vendor profile. Once credit card issuer <b>1200</b> receives the vendor(s) the customer selected fro removal (Step <b>316</b>C), credit card issuer <b>1200</b> delete these selected vendors from the vendor table associated with the designated extra credit line (Step <b>318</b>C). From there, the customer may be queried whether there are any more changes they wish to make to their vendor profile (Step <b>340</b>C). If not (Step <b>340</b>C; NO), processing ends (Step <b>342</b>C). However, if the customer decides to make additional changes (Step <b>340</b>C; YES), the edit process is looped back to Step <b>314</b>C for further processing.

Returning to Step <b>314</b>C, if the customer decides to add vendor(s) to a selected extra credit line (Step <b>314</b>C; ADD), credit card issuer <b>1200</b> accesses the master vendor list and the vendor table associated with the customer (Step <b>330</b>C). Once the vendor information is accessed, credit card issuer <b>1200</b> determines whether a customer profile option has been implemented (Step <b>332</b>C). In the event card issuer <b>1200</b> does not implement customer profiles, (Step <b>332</b>C; NO), the customer may still have the option to participate in vendor selections. If card issuer <b>1200</b> supports this option (Step <b>360</b>C; YES), the customer is presented with the entire master list of vendors in partnership with card issuer <b>1200</b> (Step <b>334</b>C). The customer may select from the list of vendors and the selections are appropriately added to the customer's vendor table (Steps <b>336</b>C and <b>338</b>C). Processing is then forwarded to Step <b>340</b>C to determine whether the customer wishes to make more changes to their vendor profile. However, in the event card issuer does not support customer input for vendor selections (Step <b>360</b>C; NO), every vendor in the master list is added to the customer's vendor table (Step <b>362</b>C), and processing is passed to Step <b>340</b>C.

Referring back to Step <b>332</b>C, if it is determined that customer profiles are being used by card issuer <b>1200</b> (Step <b>332</b>C; YES), the profile for the customer is accessed (Step <b>344</b>C). Along with profiles, card issuer <b>1200</b> may also control whether the customer has a choice in selecting vendors for their extra line(s) of credit during the editing process (Step <b>346</b>C). If card issuer <b>1200</b> denies selections by customers, the appropriate vendor groups may be selected automatically, based on the customer's profile (Step <b>348</b>C). Once credit card issuer <b>1200</b> has selected the appropriate vendor to be associated the customer's designated extra credit line(s), they may be added to the customer's vendor table (Step <b>350</b>C). Accordingly, a customer may allow credit card issuer <b>1200</b> to automatically update their vendor profile, thus ensuring any vendors that have been approved for the customer's extra credit line(s), based on the customer's profile, are added to the customer's vendor profile. Of course, credit card issuer may also modify a customer's vendor profile without customer interaction. In another aspect of the present invention, credit card issuer <b>1200</b> may periodically perform credit worthiness checks on a customer's credit card account, and based on these worthiness checks, vendors may be added or deleted from a customer's vendor profile associated with the extra line(s) of credit. The customers may be notified of the changes to their vendor profiles through the various mediums supported by the response vehicle <b>1100</b>. Once the selected vendor(s) are added to a customer's vendor table, processing is directed to Step <b>340</b>C to determine if the customer wishes to make more changes to their vendor profile.

Returning back to Step <b>346</b>C, in the event credit card issuer <b>1200</b> does allow customer input in choosing vendors (Step <b>346</b>C; YES), the customer may be presented with an option to select vendors from the master list or designated vendor groups presented based on the customer's profile information (Step <b>352</b>C). The process of presenting vendor options to a customer is similar to the features described with reference to the process shown in <figref idref="DRAWINGS">FIG. 3A</figref>.

If the customer decides not to participate in the vendor selections (Step <b>354</b>C; NO), card issuer may select the vendors for the customer based on the customer's profile (Step <b>348</b>C). On the other hand, card issuer <b>1200</b> may also apply each vendor in the master list to the customer's vendor table, (Step <b>362</b>C), enabling the customer full access to all participating vendors. If the customer decides to participate in vendor selections (Step <b>354</b>C; YES), card issuer may offer the customer selected vendor groups for selection (Step <b>356</b>C). Once the selections are made by the customer, they are processed such that the selected vendors in the selected vendor groups are added to the customer's vendor table (Step <b>358</b>C). Once the appropriate vendors are added to the customer's vendor table, processing then continues to determine whether additional changes to the customer's vendor profile is requested (Step <b>340</b>C).

Once credit card issuer <b>1200</b> has received and processed all the responses from the customer regarding the modification to their vendor profile, a notification message may be generated to indicate the respective changes to the customer. As discussed before, the notification message may be passed to the customer through an appropriate response vehicle. The notification may also indicate to the customer the available balance, the vendors associated with each extra credit line, as well as other known credit card information.

<figref idref="DRAWINGS">FIG. 4</figref> illustrates another exemplary environment <b>400</b> in which features and principles of the present invention may be implemented. <figref idref="DRAWINGS">FIG. 4</figref> may be implemented with a plurality of vendor sites and web servers, as well as a number of credit card issuers and associated web servers. Environment <b>400</b> includes customer <b>410</b>, network <b>412</b>, vendor web server <b>414</b>, vendor backend system <b>415</b>, vendor site <b>416</b>, acquiring bank <b>418</b>, interchange network <b>420</b>, credit card issuer <b>422</b>, and credit card issuer web server <b>424</b>.

Network <b>412</b> may represent any known communication network that allows the exchange of information electronically. For example, network <b>412</b> may represent the Internet or a combination of local area networks or public networks connecting to the Internet.

Customer <b>410</b> may be a customer who has a credit card account with credit card issuer <b>422</b> or another credit card issuer. Customer <b>410</b> connects to network <b>412</b> with a personal computer (PC) or other device (e.g., wireless phone, PDS, thin client, etc.) to access web sites operated by web servers <b>414</b> and <b>424</b>. Customer <b>410</b> may also be a customer who is physically at vendor site <b>416</b> performing purchase transactions at a point of sale terminal.

Vendor site <b>416</b> may be a merchant's location, such as an outlet store, where customers purchase goods and/or services directly from the merchant. Vendor site <b>416</b> processes a large number of purchase transactions from a variety of customers, including customer <b>410</b>. Vendor web server <b>414</b> operates a retail web site where customers may purchase goods and/or services offered by vendor <b>415</b> on-line through network <b>412</b>. Vendor backend system <b>415</b> processes purchase transactions received at the vendor's web site from vendor web server <b>415</b>, and forwards the transactions to acquiring bank <b>418</b>.

Acquiring bank <b>418</b> may represent an institution that processes all financial transactions for vendor site <b>416</b> and web server <b>414</b>. Acquiring bank <b>418</b> receives a great number of transactions from each of the vendor sites for a diverse group of customers. The customers may purchase goods and/or services using credit cards issued from different credit card issuers including credit card issuer <b>422</b>. Acquiring bank forwards these credit card transactions to interchange network <b>420</b> for processing.

Interchange network <b>420</b> may be a commercially available interchange network, such as a VISA or MASTERCARD network. Interchange network <b>420</b> processes transaction information received from acquiring bank <b>418</b>. Network <b>420</b> filters the transactions based on the type of credit cards used by customers initiating the transactions at vendor sites <b>416</b> and <b>414</b>. Network <b>420</b> may also filter transactions originating from vendor sites that are accessed from card issuer <b>422</b>'s branded web sites. Interchange network <b>420</b> forwards the filtered transaction information to the appropriate credit card issuer, including credit card issuer <b>422</b>.

Credit card issuer <b>422</b> issues credit cards to customers and maintains each customer's account. Card issuer <b>422</b> receives and authorizes transaction information from interchange network <b>420</b> and web server <b>424</b>. Card issuer <b>422</b> also generates and presents offers for extra credit lines to specified customers.

Web server <b>424</b> operates web sites for issuer <b>422</b>. The web sites includes retail sites from which customer <b>410</b> may purchase goods and/or services. Server <b>424</b> exchanges information with issuer <b>422</b> for processing these purchase transactions. Web server <b>424</b> may also process purchase transactions from customers who are not holders of credit cards issued by issuer <b>422</b>. Web sites operated by web server <b>424</b> may include sites that offer goods and/or services directly from card issuer <b>422</b>. These sites may also be sites that are operated by a vendor web server, but branded as a web site offered by card issuer <b>422</b>.

<figref idref="DRAWINGS">FIG. 5A</figref> illustrates an exemplary process associated with authorizing a charge made by customer <b>410</b> in environment <b>400</b>. The features of <figref idref="DRAWINGS">FIG. 5A</figref> maybe implemented in connection with credit cards of the present invention, including multi-line credit cards and credit cards with embedded credit line(s). For purpose of illustration, <figref idref="DRAWINGS">FIG. 5A</figref> will be described below with reference to a credit card that is upgraded with an extra line of credit. <figref idref="DRAWINGS">FIG. 5</figref>, however, may also be implemented in connection with credit cards including credit cards with multiple lines of extra credit.

As illustrated in <figref idref="DRAWINGS">FIG. 5A</figref>, customer attempts a purchase transaction at either vendor site <b>416</b> or a web site operated by web servers <b>414</b> or <b>424</b> (Step <b>510</b>A). If the transaction is at vendor site <b>416</b>, the customer may present their credit card at a point of sale (POS) terminal to complete the purchase. Personnel at site <b>416</b> may process the credit card by “swiping” the credit card through a credit card processing instrument at the POS terminal. The POS terminal then generates transaction information specific to the attempted purchase, including the customer's credit card information. The POS terminal sends the transaction information to acquiring bank <b>418</b> through an electronic link (Step <b>520</b>A). If the transaction is attempted at a web site, the customer would present their credit card information to web server <b>414</b>, <b>424</b> using a web browser or another application. Web server <b>414</b> forwards the customer's credit card information, along with the purchase data, to backend system <b>415</b> for processing. Backend system <b>415</b> processes all purchase transactions received at web server <b>414</b>. Web server <b>424</b> may similarly use a backend system (not shown) to perform similar operations. The transaction information, including the customer's credit card data, is packaged and may be sent to acquiring bank <b>418</b> for vendor based transactions. Transactions associated with web server <b>424</b> may also use similar acquiring banks (not shown) that would operate in a manner consistent with bank <b>418</b>.

Acquiring bank <b>418</b> processes the transaction information and forwards it to interchange network <b>420</b> (Step <b>530</b>A). Once received, interchange network <b>420</b> filters the transaction information from other transactions received from other vendor sites. The purchase transaction from customer <b>410</b> would be filtered and maybe aggregated with other transactions involving credit cards issued from card issuer <b>422</b>. Interchange network <b>420</b> then sends the transaction information to issuer <b>422</b> for authorization (Step <b>540</b>A).

Credit card issuer <b>422</b> receives the transaction information, and determines whether the purchase should be authorized (Step <b>550</b>A). Details regarding the authorization process is described with reference to the description of <figref idref="DRAWINGS">FIG. 5B</figref>. Card issuer <b>422</b> then sends the results of the authorization process back to interchange network for distribution to vendor sites <b>414</b>, <b>416</b> or to web server <b>424</b> (Step <b>560</b>). Vendor sites <b>414</b>, <b>416</b> and server <b>424</b> either completes or denies the transaction based on the results of the authorization process.

<figref idref="DRAWINGS">FIG. 5B</figref> illustrates an exemplary process associated with card issuer <b>422</b> checking the validity of the purchase transaction of customer <b>410</b>. As shown in <figref idref="DRAWINGS">FIG. 5B</figref>, card issuer <b>422</b> receives transaction information associated with customer <b>410</b> from interchange network <b>420</b> (Step <b>51</b>OB). After performing well known security checks regarding the customer's account, (i.e., verifying the customer's account number), card issuer <b>422</b> then determines whether customer <b>410</b> has an extra line of credit (Step <b>512</b>B). If it is determined that the customer does not have additional buckets associated with their account, processing is forwarded to step <b>514</b>B.

At step <b>514</b>B, card issuer <b>422</b> may generate an offer to customer <b>410</b>, in accordance with features and principles of the present invention. At this point, card issuer <b>422</b> may provide an option to credit card holders to obtain extra credit on their existing card. Prior to presenting the offer to customer <b>410</b>, credit card issuer <b>422</b> determines whether customer <b>410</b> is “eligible” for such benefits. The process may mimic the functions previously described with reference to <figref idref="DRAWINGS">FIG. 3A</figref>. If customer <b>410</b> is not eligible, no offer will be presented, and processing will continue at Step <b>522</b>B. However, if the customer is determined to be eligible, an offer for extra credit is sent to the appropriate site for delivery to the customer. The manner in which the query may be presented to the customer may be based on the site accessed by customer <b>410</b>. For instance, in the event customer <b>410</b> is located at a POS terminal at vendor site <b>416</b>, the query may be presented by a clerk operating the POS terminal. Alternately, if the customer has accessed a web site to purchase goods, web servers <b>414</b> and <b>424</b> may present and process the customer's response automatically.

Several options may be available to card issuer <b>422</b> in the event the customer is performing a transaction at vendor site <b>416</b>. The message maybe displayed at the clerk's POS terminal, flagging them to present the offer to customer <b>410</b>. Upon receiving the customer's response, the clerk may select to notify card issuer <b>422</b> using the POS terminal. The clerk's notification may follow the normal channels of communications indicated in <figref idref="DRAWINGS">FIG. 4</figref>. Alternately, another option may be to direct the customer to the vendor's customer service desk or a kiosk computer located at the vendor's site. This option may be less obtrusive to customers waiting in lines at the vendor's POS terminals. The processing of the customer's decision to accept extra credit may be performed at these locations after the purchase has been completed. Another option may be to print the offer on a purchase receipt. The receipt may include a telephone number or URL that the customer may use to obtain extra credit line(s) for their existing card. As can be seen, a wide variety of options are available for card issuer to present its query to customer <b>410</b>, and are not limited by the above examples.

In order to process and present the offer to a customer, the POS terminals may include the necessary software and hardware required for communicating with credit card issuer <b>422</b>. For instance, the extra credit offer or message may be appended to a transaction authorization message issued by credit card issuer <b>422</b>. The POS terminal would receive the information from credit card issuer <b>422</b> and filter the extra credit offer from the authorization message. The offer may subsequently be displayed on a terminal or it may be printed on a sales receipt, as indicated above.

Once the customer responds to the offer, the response is sent to issuer <b>422</b> (Step <b>516</b>B). If the customer accepted the offer, the customer's account is modified to reflect the new credit lines in accordance to the principles of the invention. Processing is then forwarded to Step <b>528</b>A. In the event customer <b>410</b> declined the offer, the purchase is checked for authorization against the customer's general purpose credit line (Step <b>522</b>B).

However, in the event customer <b>410</b> does have extra lines of credit on their existing credit card, a check is made to determine whether the vendor associated with the transaction has a partnership agreement with card issuer <b>422</b> (Step <b>520</b>B). The vendor associated with the transaction may be associated with a site that is accessed from card issuer's branded web site operated by server <b>424</b>. In order to determine if the vendor is included in card issuer's master vendor list, vendor identification information included in the transaction information sent from interchange network <b>420</b> may be compared to those stored in card issuer's master vendor list.

In the event that the vendor is not included in the master vendor list (Step <b>520</b>B; NO), issuer <b>422</b> may decide to apply the attempted purchase to customer <b>410</b>'s general purpose line of credit. In such a case, the general credit line is analyzed to determine whether the are sufficient funds to complete the transaction (Step <b>522</b>B). If there are sufficient finds, credit card issuer <b>422</b> validates the transaction, applies the purchase amount to the balance of the customer's general purpose credit line and sends notification of the authorized transaction to interchange network <b>420</b> for delivery to the appropriate vendor site (Step <b>524</b>B). However, if the purchase amount exceeds the available balance associated with customer <b>410</b>'s general line of credit, the transaction is not authorized (Step <b>526</b>B). Notification of the unauthorized transaction is forwarded to interchange network <b>420</b> for delivery to the vendor site.

Referring back to step <b>520</b>B, if it is determined that vendor site <b>416</b>, <b>414</b> (or a vendor associated with a web site operated by server <b>424</b>) is included in the vendor master list (Step <b>520</b>B; YES), an analysis is performed to determine whether customer <b>410</b> has an extra credit line that is associated with vendor groups (Step <b>528</b>B). If the vendor group option is associated with the customer's account, processing is forwarded to Step <b>546</b>B, described later. If the customer's account is not associated with vendor groups (Step <b>528</b>B; NO), card issuer <b>422</b> analyzes the customer's extra credit line(s) for vendor associations and balance amount(s) (Step <b>530</b>B). This analysis may include determining whether the customer has more than one extra credit line and the association of the extra credit line(s) with the vendor. For example, if customer <b>410</b> has two extra credit lines, card issuer <b>422</b> may determine which bucket the purchase at site <b>414</b>, <b>416</b> and <b>424</b>, is to be applied. As indicated previously, for purposes of illustration of the process described in <figref idref="DRAWINGS">FIG. 5A</figref>, it is assumed that customer <b>410</b> has only one additional bucket associated with their credit card account.

Once analysis of the customer's account is complete, and card issuer <b>422</b> determines that the purchase amount does not exceed the available balance for the customer's extra credit line, the transaction is authorized (Steps <b>532</b>B; NO and <b>534</b>B). Credit card issuer <b>422</b> validates the transaction, applies the purchase amount to the customer's extra credit line balance and sends notification of the authorized transaction to interchange network <b>420</b> for notification to the appropriate vendor site. However, in the event the purchase amount exceeds extra credit line's available balance (Step <b>532</b>B; YES), the customer may be queried to apply the purchase to their general purpose credit line (Step <b>536</b>B). Alternately, card issuer <b>422</b> may deny authorization for the extra credit line, and automatically apply the purchase to the customer's general credit line (Step <b>537</b>B). In the event the customer does not accept the offer to use their general credit line for the purchase (Step <b>538</b>B; NO), the transaction is not authorized and notification is sent to interchange network <b>420</b> for appropriate delivery to the customer. But, if customer <b>410</b> accepts the offer to use their general credit line (Step <b>538</b>B; YES), card issuer determines whether a credit line sharing option is activated for the customer's account (Step <b>542</b>B). Credit line sharing may be an option offered to customers that allows purchases applied to one bucket to be shared by other buckets. This option is demonstrated with the example presented in Table I. In particular, Table I illustrates an exemplary scenario associated with customer <b>410</b> attempting to purchase goods at vendor site <b>416</b>.

<tables id="TABLE-US-00001" num="00001"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE I</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Example of Credit Line Sharing</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="offset" colwidth="42pt" align="left" /><colspec colname="1" colwidth="42pt" align="center" /><colspec colname="2" colwidth="63pt" align="center" /><colspec colname="3" colwidth="70pt" align="center" /><tbody valign="top"><row><entry /><entry /><entry>1^stBucket Available</entry><entry>2^ndBucket Available</entry></row><row><entry /><entry>Purchase</entry><entry>Balance-General</entry><entry>Balance-Extra</entry></row><row><entry /><entry>Amount</entry><entry>Purpose Credit Line</entry><entry>Credit Line</entry></row><row><entry /><entry namest="offset" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="1" colwidth="42pt" align="left" /><colspec colname="2" colwidth="42pt" align="char" char="." /><colspec colname="3" colwidth="63pt" align="char" char="." /><colspec colname="4" colwidth="70pt" align="char" char="." /><tbody valign="top"><row><entry /><entry>$0</entry><entry>$1000</entry><entry>$100</entry></row><row><entry>Option 1</entry><entry>$200</entry><entry>$800</entry><entry>$100</entry></row><row><entry>Option 2</entry><entry>$200</entry><entry>$900</entry><entry>$0</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

The 1st bucket is associated with customer <b>410</b>'s general purpose credit line and the 2^ndbucket with an extra credit line implemented as a private label credit line associated with vendor site <b>416</b>. In the example of Table I, customer <b>410</b> attempts to make a $200 purchase at vendor site <b>416</b>. Option <b>1</b> illustrates the process where the credit line sharing option is not activated for customer <b>410</b>. As shown, the $200 purchase is applied entirely to the 1^stbucket (reducing the available balance from $1000 to $800) leaving the 2^ndbucket's balance intact (at $100). Option <b>2</b> illustrates the process where the credit line sharing option is active and available to customer <b>410</b>. In this option, the purchase amount is first applied to the 2^ndbucket's available balance, with any remaining amount then applied to the 1^stbucket. As shown, the $200 purchase is applied to the 2^ndbucket credit line, leaving $100 of the purchase to be covered by the 1^stbucket. As a result, the remaining balance for the customer's 1^stand 2^ndbuckets is $900 and $0, respectively. As can be seen, the credit line sharing option allows credit card issuer <b>422</b> to offer customers versatility in the use of their credit card balances, while still maintain control over the customers' accounts. Card issuer <b>422</b> may selectively offer the sharing option to customers automatically, or elect to have customers decide whether they want to implement this option.

Therefore, if the credit line sharing option is activated (Step <b>542</b>B; YES), the process associated with credit line sharing is performed (Step <b>544</b>B). In the event the sharing option is not activated for customer <b>410</b> (step <b>542</b>B; NO), the purchase is automatically applied to the customer's general purpose credit line or 1^stbucket (Step <b>522</b>B).

Along with checking the authorization of transactions performed by customer <b>410</b>, credit card issuer may allow interactive operations with customer <b>410</b> to take place during the transaction process. For example, card issuer <b>422</b> may allow customer <b>410</b> to edit their vendor group profile associated with their extra credit line. Steps <b>546</b>B through <b>556</b>B of <figref idref="DRAWINGS">FIG. 5B</figref> illustrates this option. Referring back to Step <b>528</b>B, in the event customer <b>410</b> has vendor groups associated with their account (Step <b>528</b>B; YES), credit card issuer access the vendor table associated with customer <b>410</b> (Step <b>546</b>B). As previously described with reference to <figref idref="DRAWINGS">FIG. 3A</figref>, the customer's vendor table may be stored in a central database operated by card issuer <b>422</b>. Card issuer <b>422</b> then determines whether vendor site <b>414</b>, <b>416</b> or the vendor site associated with server <b>424</b>, is included in the customer's vendor table (Step <b>548</b>B). If the vendor is in the vendor table, processing may proceed to authorize the transaction for the customer's extra credit line (Steps <b>548</b>B; YES, <b>530</b>B). However, in the event the vendor is not in the customer's vendor table (Step <b>548</b>B; NO), the customer may be queried to add the vendor to its vendor group (Step <b>552</b>B). The manner in which the query may be presented to the customer may depend on the vendor site accessed by customer <b>410</b>.

In particular, as previously indicated in the description of Step <b>514</b>B, in the event customer <b>410</b> is located at a POS terminal at vendor site <b>416</b>, the query may be presented by a clerk operating the POS terminal. Alternately, if the customer has accessed a web site to purchase goods, web servers <b>414</b> and <b>424</b> may present and process the customer's response automatically. The message may be displayed at the clerk's POS terminal, flagging them to present the question to customer <b>410</b>. Upon receiving the customer's response, the clerk may notify card issuer <b>422</b> using the POS terminal. Alternately, the customer may be directed to the vendor's customer service desk or a local kiosk computer located at the vendor's site. The editing of the customer's vendor group table may be performed at these locations after the purchase has been completed. Another option may be to print the request on the purchase receipt. The receipt may include a telephone number or web site URL that the customer may use to edit their vendor group. As can be seen, a wide variety of options are available for card issuer to present its query to customer <b>410</b>, and are not limited by the above examples.

Referring back to Step <b>552</b>B, if customer <b>410</b> accepted the option to edit their vendor group table, (Step <b>554</b>B; YES), vendor <b>414</b>, <b>416</b> or the vendor associated with server <b>424</b>, is added to the customer's vendor table (Step <b>556</b>B). Processing is then forwarded back to Step <b>530</b>B to continue the authorization process.

Allowing a customer to edit their vendor groups may be an option that customers and card issuer <b>422</b> decide to implement. However, the security of activated vendor groups may be an area of concern for card issuer <b>422</b> and customers alike. Therefore, the dynamic editing of vendor groups may be removed by merely bypassing the query process, and automatically denying transactions with vendors that are not included in a customer's vendor group (Step <b>550</b>B).

As described, the present invention allows customer's who access vendor sites physically or through other channels, such as the Internet, the versatility of using their extra credit lines, as well as have existing credit cards modified to include additional lines of credit.

Credit card issuer <b>422</b> may operate their own web sites for the sales of goods and/or services. The card issuer's web sites may be financial based sites that offer the credit cards and other financial services. Additionally, these sites may provide goods and/or services from vendors either directly or through a vendor operated site that is branded as a card issuer's site. Allowing card holders to purchase goods and/or services through a card issuer's branded web site may present a safer environment for on-line purchasing. That is, card issuers may target and offer extra credit lines to groups of customers who are hesitant to purchase goods and/or services on-line for security reasons. These customers may have a concern that their credit card numbers may be stolen by unauthorized individuals who eavesdrop such transactions. A card issuer that operates its own branded sales site may appeal to these hesitant customers. A customer may feel more secure in purchasing such goods and/or services from a site that is operated by the credit card issuer that has issued the credit cards that they hold.

There are a variety of ways card issuers can process transactions occurring at card issuer branded web sites. Transactions from customers who access a web site operated by card issuer web server <b>424</b> may be processed in the same manner as described in <figref idref="DRAWINGS">FIGS. 5A and 5B</figref>. Additionally, other methods and environments may be implemented.

<figref idref="DRAWINGS">FIG. 6</figref> illustrates an exemplary environment <b>600</b> in which purchase transactions from extra credit card holders may be implemented, in accordance with another aspect of the present invention. Environment <b>600</b> includes a customer <b>610</b>, web server <b>612</b>, credit card issuer's web site product database <b>618</b>, customer registration database <b>616</b>, credit card issuer's management information system (MIS) <b>620</b>, secondary web server <b>622</b>, secondary backend system <b>624</b>, master product database <b>626</b>, vendor/manufacturer site <b>628</b>, interchange network <b>630</b>, credit card issuer authorization system <b>632</b> and credit card issuer bucket system <b>634</b>.

Customer <b>610</b> represents a customer who may use a personal computer (PC) or other device (e.g., wireless phone, PDA, thin client, etc.) computer system with a network interface to access a web site operated by web server <b>612</b> through the Internet (not shown). Customer <b>610</b> may hold an existing credit card issued from a credit card issuer or issued from another credit card issuer.

Web server <b>612</b> operates a web site that offers good and/or services to customers. for purposes of illustration, the web site may include a branded web site that include logos and identifying features of the credit card issuer. The web site may include, but is not limited to, a home page that include links to web pages that offer goods and/or services to customers. In accordance with one aspect of the invention, web server <b>610</b> is maintained and controlled through a secondary web server <b>622</b> that brands the web site as a credit card issuer web site.

Customer registration database <b>616</b> includes customer information related to credit card accounts, including extra credit lines added to each customer's existing credit card account. Web site product database <b>618</b> includes information related to the types of goods and/or service offered by the credit card issuer, at the web site operated by server <b>612</b>.

Management information system (MIS) <b>620</b> processes the information stored in database <b>616</b>, including extra credit line account numbers. MIS system <b>620</b> also performs an offer decisioning process, such as that described with reference to <figref idref="DRAWINGS">FIG. 7A</figref>.

Secondary web server <b>622</b> may be a server that manages the operations performed by server <b>612</b>. This includes the management of the types of information displayed at the web site and the exchange process of orders received at the site. Secondary backend system <b>624</b> processes received orders, creates authorization requests and receives results of the authorization requests, billing functions and customer service operations. Backend system forwards the selected information to an appropriate entity it has a link to. For instance, customer service transactions could be forwarded to entities that are designed to handle such transactions.

Master product database <b>626</b> receives updates on product information and uploads it to server <b>612</b>. Vendor/manufacturer site <b>628</b> receives processed orders from secondary backend system <b>624</b>. Site <b>628</b> fills the orders and ship goods that customer <b>610</b> may have ordered from web server <b>612</b>.

Interchange network <b>630</b> receives authorization requests from secondary backend system <b>630</b>, and filters the request based on the type of credit card used to purchase orders at the web site operated by server <b>612</b>. Network <b>630</b> sends requests associated with customers using credit cards issued by credit card issuer to authorization system <b>632</b>. System <b>632</b> performs transaction authorization operations for the credit card issuer, including extra credit line authorizations. Credit card issuer bucket system <b>634</b> performs account settlement functions associated with the orders processed by backend system <b>624</b>.

Details of the features and operations of the elements illustrated in <figref idref="DRAWINGS">FIG. 6</figref> will be described with reference to <figref idref="DRAWINGS">FIGS. 7A and 7B</figref>.

<figref idref="DRAWINGS">FIG. 7A</figref> illustrates an exemplary process associated with a purchase transaction attempted at a web site branded by a credit card issuer. The branded web site may target customers who have an extra credit line added to their existing credit cards issued by the credit card issuer. However, the goods and/or services offered at the web site may be purchased by customers using a variety of different credit cards, including cards not issued by the card issuer hosting the site. A customer may be attracted to the branded web site by offers for extra lines of credit generated by a credit card issuer.

<figref idref="DRAWINGS">FIG. 7C</figref> shows an exemplary offer <b>710</b>C for an extra line of credit. Offer <b>710</b>C represents an offer that may be sent to a customer using conventional mail techniques or by other communication techniques, such as email. Similar offers may also be presented through a banner advertisement or web page. The offer <b>710</b>C may instruct the customer to visit the credit card issuer's branded web site to obtain an extra line of credit. The offer may also include the amount of credit that is available to the customer. As shown in the exemplary offer of <figref idref="DRAWINGS">FIG. 7C</figref>, the customer is offered an extra line of credit of $250.00. The offer <b>710</b>C may also indicate to the customer that the extra line of credit is restricted to purchases from the credit card issuer's branded web site. However, as described previously, the extra line of credit may also be associated with a plurality of vendors or vendor groups. The offer illustrated in <figref idref="DRAWINGS">FIG. 7C</figref> is exemplary, and should not be considered limiting. Any number of offers may be presented, with various terms and conditions associated with the extra line of credit offered to the customer. For instance, the offer <b>710</b>C maybe adjusted seasonally. That is, the terms and conditions associated with offer <b>710</b>C may be based on a holiday season, such as Christmas. The $250.00 extra line of credit offered to the customer in offer <b>710</b>C may be reduced after the holiday season. Accordingly, credit card issuers may vary their offers based not only on a customer's credit worthiness, but the time of year as well. A number of factors other than the time of year may also contribute to the adjustment of an offer and are not limited to those described above.

Referring again to <figref idref="DRAWINGS">FIG. 7A</figref>, the process begins when customer <b>610</b> access the web site using standard network accessing techniques (Step <b>710</b>A). For instance, customer <b>610</b> may access the web site by entering a selected URL with their local browser. Additionally, customer <b>610</b> may have selected a link that was presented at another web page previously viewed by the customer. The customer may then browse the web site, selecting items and links that may direct the customer to other web pages that offer selected goods and/or services for purchase (Step <b>712</b>A). As the customer browses and shops at the web site, they may select goods that are added to a virtual shopping cart. The virtual shopping cart acts as a normal supermarket shopping cart, whereby goods off shelves are held while shopping. The customer may remove items from the virtual shopping cart just as if they were shopping at a physical vendor site. Features of the virtual shopping cart may include a running tally of total purchases in the shopping cart. Also, individual items in the cart may be reviewed at the customer's leisure. A customer may save the shopping cart, such that in the event the customer leaves the web site without purchasing any goods and/or services, the items in the cart will remain until the site is again visited by the customer.

Once the customer has completed shopping at the web site, the customer may decide to check out. The customer may select an icon or button bar that initiates the check out process. (Step <b>714</b>A). A billing information page is then presented to the customer, where credit card information is requested. For this example, the customer may hold a credit card issued by the credit card issuer branded at the web site. The customer enters the appropriate billing information (Step <b>716</b>A), including their credit card data and attempts to complete the transaction by selecting an appropriate icon or button bar.

Server <b>612</b> recognizes the customer's request to complete the transaction and redirects processing to a credit card issuer offer decision processes (Step <b>718</b>A). The offer decisioning process may be performed at credit card issuer management information system <b>620</b> or at other credit card issuer systems that have access to customer account information. The session with customer <b>610</b> and server <b>612</b> is maintained while the decisoning process is performed. Once management information system receives the appropriate credit card information, it analyzes the card information against data stored in customer registration database <b>616</b> (Step <b>720</b>A). Based on the analysis, system <b>620</b> determines whether the customer has previously been offered an extra credit line through the credit card issuer's branded web site (Step <b>722</b>A). This may be determined by server <b>612</b> maintaining information in database <b>616</b> regarding which customers were presented a selected page including the extra credit offer from the credit card issuer.

In the event the customer has received the offer previously (Step <b>722</b>A; NO), system <b>620</b> determines whether the customer accepted any extra credit lines presented in the previous offer (Step <b>724</b>A). In the event the customer did accept the offer (Step <b>724</b>A; YES), a reminder message is presented the customer indicating that their extra credit line would be used for the attempted purchase. Processing is then forwarded to Step <b>734</b>A, described later. However, if the customer did not accept the offer (Step <b>724</b>A; NO), an extra credit line indicator is set to “N”, and processing is directed back to the web site operated by server <b>612</b> (Step <b>736</b>A).

Referring back to Step <b>724</b>A, in the event the customer has not been offered an extra credit line, (Step <b>722</b>A; YES), an extra credit line offer page is generated and presented to the customer (Step <b>728</b>A). The offer may be generated based on the features previously described herein. The offers may also be generic and directed to all customers of the card issuer hosting the web site. Additionally, the offers may be tailored for customers who are not holders of credit cards issued by the card issuer hosting the web site. The offer may allow the credit card issuer to obtain new customers by advertising the benefits of owning a credit card with multiple lines of credit. If the customer is not a holder of a credit card issued by the card issuer, the customer would be issued a new card with multiple lines of credit or a new card with a general purpose credit line and the option to add extra lines of credit at a later time.

<figref idref="DRAWINGS">FIG. 7D</figref> shows an exemplary web page including an offer <b>710</b>D for an extra line of credit. Offer <b>710</b>D represents an offer that may be presented to a customer shopping at the credit card issuer's branded web site. As shown in <figref idref="DRAWINGS">FIG. 7D</figref>, the offer may include the amount of credit that is available to the customer, as well as the terms and conditions of the extra credit line. This may include interest rate information, activation fees and minimum payment information (not shown). The offer may instruct the customer to select an icon or button bar to accept the terms and conditions of the offer for an extra credit line. The offer <b>710</b>D may also indicate to the customer that the extra line of credit is restricted to purchases from the credit card issuer's branded web site. The offer illustrated in <figref idref="DRAWINGS">FIG. 7D</figref> is exemplary and should not be considered limiting. Any number of offers may be presented, with various terms and conditions associated with the extra line of credit offered to the customer. Additionally, the graphically representation of the offer is not limited to that shown in <figref idref="DRAWINGS">FIG. 7D</figref>. Of course, any number of graphical and textual variations to the offer <b>710</b>D may be chosen by a credit card issuer and presented in the offer web page.

Once the customer's response to the offer is captured (Step <b>720</b>A), system <b>620</b> determines whether the customer accepted the offer or not (Step <b>732</b>A). In the event the customer declined the offer, an extra credit line indicator is set to “N”, and processing is redirected back to the web site operated by server <b>612</b> (Step <b>736</b>A). However, if the customer did accept the offer (Step <b>732</b>A; YES), the extra credit line indicator is set to “Y”, and processing is directed back to the web site operated by server <b>612</b> (Step <b>734</b>A).

Processing of a customer's acceptance to include an additional line of credit on an existing credit card may be processed a plurality of ways. For example, the extra credit line indicator being set to “Y” may initiate an updating operation at credit card issuer bucket system <b>634</b>. System <b>634</b> may update a central database in order to edit the customer's account to include an additional bucket for the extra line of credit. This process may be implemented by using additional segments in a central database, similar to the process previously described with reference to <figref idref="DRAWINGS">FIG. 3A</figref>. Once updated, authorization system <b>632</b> and management information system <b>620</b> are updated with the new account information. Once the customer's account is updated with the new bucket, processing is then directed to the web site hosted by the credit card issuer.

Once the web site receives the information from management information system <b>620</b>, it determines if the offer was successfully completed (Step <b>738</b>A). In the event the offer was not successfully completed (Step <b>738</b>A; NO), an error message is displayed to the customer and a retry option is presented (Step <b>742</b>A). If the customer decides not to retry the order (Step <b>744</b>A; NO), the order is not completed and the purchase transaction is ended (Step <b>746</b>A). However, if the customer decides to retry the order (Step <b>744</b>A; YES), processing is forward back to Step <b>718</b>A for another attempt at processing the order.

Referring back to Step <b>738</b>A, in the event the offer process did complete successfully (Step <b>738</b>A; YES), a check out process is initiated, such as that described below with reference to <figref idref="DRAWINGS">FIG. 7B</figref>.

<figref idref="DRAWINGS">FIG. 7B</figref> illustrates an exemplary check out process that may be performed at a credit card issuer's branded web site. If the customer attempts to check out and the offer decisioning process was successfully completed (Step <b>710</b>B), server <b>612</b> checks the extra credit line indicator to determine whether the purchase transaction is related to a customer's extra credit line (Step <b>714</b>B). If it is not (Step <b>714</b>B; NO), processing is forwarded to Step <b>723</b>B to check the authorization of the general purpose credit line. However, if the purchase is an extra credit line transaction (Step <b>714</b>B; YES), web server <b>612</b> forwards the appropriate billing information to secondary web server <b>622</b>, which then forwards the information to secondary backend system <b>624</b>. Secondary backend system <b>624</b> then generates an authorization request based on the extra credit line information received in the customer's order, and sends the request to interchange network <b>630</b> for authorization by the credit card issuer.

Once credit card issuer authorization system <b>632</b> receives the transaction information, it performs authorization checks against the customer's extra credit line. This may include checking balances, account information, expiration date information and any other known authorization functions needed to ensure the purchase is valid. Authorization system <b>632</b> produces an authorization result, and sends the result back to secondary backend system <b>624</b> through network <b>630</b>. Secondary backend system passes the results data back to the secondary web server <b>622</b> for continued processing. If the result received from system <b>632</b> indicates a valid transaction (Step <b>716</b>B; YES), the check out process may continue (Step <b>724</b>B). Thereafter, the customer's order is completed and a completion page is presented to the customer indicating the results of the purchase (Step <b>728</b>B).

In the event authorization system <b>632</b> did not authorize the extra credit line purchase attempted by customer <b>610</b>, an authorization denial page is displayed to the customer (Step <b>718</b>B). Additionally, the customer is presented with an offer to utilize their general line of credit. If the customer declines to use their general credit line (Step <b>720</b>B; NO), an order failure page is displayed to the customer indicating that the purchase was not processed. In one aspect of the invention, the customer may also be provided with a link to try and use another credit card issued from a different card issuer than the one hosting the web site (Step <b>722</b>B).

Referring back to step <b>720</b>B, in the event the customer accepted the offer to use their general credit line (Step <b>720</b>B; YES), authorization of the general credit line is determined. As previously indicated, extra credit system <b>632</b> determines whether the customer's general credit line may be used for the attempted purchase. If authorization failed (Step <b>723</b>B; NO), an order failure page is displayed to the customer indicating failure of the attempted purchase. In one aspect of the invention, the customer may also be provided with a link to try and use another credit card issued from a different card issuer than the one hosting the web site (Step <b>722</b>B). However, if the general credit line was authorized (Step <b>723</b>B; YES), the check out process may continue (Step <b>724</b>B). Thereafter, the customer's order is completed and a page is presented to the customer indicating the results of the purchase (Step <b>728</b>B).

The versatility offered to customers in activating and using extra credit lines allows credit card issuers to provide user-friendly credit card products, while maintaining control over credit processing operations. Also, customers of the credit card issuer are given versatility in terms of payment options with multiple credit lines.

Payments made by a customer to a credit card issuer are based on an account statement. The account statement may be issued each billing cycle and indicate, for example: the available balance for each credit line; previous transactions applied to specified credit lines; outstanding balances for each credit line; minimum payment due; and the date the payment is due. Of course, other information may be included in each account statement (i.e., interest rate(s), contact information, etc.) as well. A customer may pay the credit card issuer by making a payment that is anywhere between an amount equivalent to the minimum payment due and the outstanding balance due. Once a credit card issuer receives payment, it is normally applied to the general purpose credit line or cash advance line, depending on the terms of the credit agreement established with the customer. However, with credit card accounts that include extra credit lines associated with the features of the present invention, additional payment options may be available to the customer and credit card issuer.

For example, a credit card issuer may apply a payment first to a general purpose credit line and then to multiple credit lines proportionally or by fixed amount. Alternatively, payments received by a customer may be applied proportionally to each credit line that has an outstanding balance. In either case, the exact manner by which a credit card issuer will apply payments will be indicated to a customer in a credit card agreement offered to the customer. Proportional payments allow credit card issuer to divide a payment into sub-payments for application to the credit lines with outstanding balances. For instance, if a customer has three credit lines (a general purpose credit line, a cash advance credit line and a extra credit line), payment from the customer may be distributed proportionally among the credit lines. On the other hand, the payment may be applied at a fixed amount to a selected credit line, until the outstanding balance of the selected credit line is reduced to zero. These payment options are demonstrated below with the example presented in Table II, which illustrates exemplary payment options for a customer who has three credit lines.

<tables id="TABLE-US-00002" num="00002"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="294pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE II</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Example of Payment Options</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="8"><colspec colname="offset" colwidth="21pt" align="left" /><colspec colname="1" colwidth="35pt" align="center" /><colspec colname="2" colwidth="42pt" align="center" /><colspec colname="3" colwidth="42pt" align="center" /><colspec colname="4" colwidth="35pt" align="center" /><colspec colname="5" colwidth="42pt" align="center" /><colspec colname="6" colwidth="35pt" align="center" /><colspec colname="7" colwidth="42pt" align="center" /><tbody valign="top"><row><entry /><entry /><entry>1^stBucket</entry><entry>1^stBucket</entry><entry /><entry /><entry>3^rdBucket</entry><entry /></row><row><entry /><entry /><entry>Available</entry><entry>Outstanding</entry><entry>2^ndBucket</entry><entry>2^ndBucket</entry><entry>Available</entry><entry>3^rdBucket</entry></row><row><entry /><entry /><entry>Balance-</entry><entry>Balance-</entry><entry>Available</entry><entry>Outstanding</entry><entry>Balance-</entry><entry>Outstanding</entry></row><row><entry /><entry /><entry>General</entry><entry>General</entry><entry>Balance-</entry><entry>Balance-</entry><entry>Extra</entry><entry>Balance-</entry></row><row><entry /><entry>Payment</entry><entry>Purpose</entry><entry>Purpose</entry><entry>Cash</entry><entry>Cash</entry><entry>Credit</entry><entry>Extra Credit</entry></row><row><entry /><entry>Amount</entry><entry>Credit Line</entry><entry>Credit Line</entry><entry>Advance</entry><entry>Advance</entry><entry>Line</entry><entry>Line</entry></row><row><entry /><entry namest="offset" nameend="7" align="center" rowsep="1" /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="8"><colspec colname="1" colwidth="21pt" align="center" /><colspec colname="2" colwidth="35pt" align="center" /><colspec colname="3" colwidth="42pt" align="center" /><colspec colname="4" colwidth="42pt" align="center" /><colspec colname="5" colwidth="35pt" align="center" /><colspec colname="6" colwidth="42pt" align="center" /><colspec colname="7" colwidth="35pt" align="center" /><colspec colname="8" colwidth="42pt" align="center" /><tbody valign="top"><row><entry /><entry /><entry>$800</entry><entry>$200</entry><entry>$500</entry><entry>$0</entry><entry>$100</entry><entry>$100 </entry></row><row><entry>Opt</entry><entry>$200</entry><entry>$900</entry><entry>$100</entry><entry>$500</entry><entry>$0</entry><entry>$200</entry><entry> $0</entry></row><row><entry>1</entry></row><row><entry>Opt</entry><entry>$250</entry><entry>$1000 </entry><entry> $0</entry><entry>$500</entry><entry>$0</entry><entry>$150</entry><entry>$50</entry></row><row><entry>2</entry></row><row><entry namest="1" nameend="8" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

In the example of Table II, the 1^stbucket is associated with the customer's general purpose credit line, the 2^ndwith cash advances, and the 3^rdbucket with an extra credit line. In this example, assume that the customer makes a $200 payment to a credit card issuer. Option <b>1</b> (Opt. <b>1</b>) illustrates the process where the payment is proportionally applied to each of the customer's three credit lines. In this instance, the credit card issuer has established a payment ratio that is equivalent for all three credit lines. That is, a customer's payment may be separated into equal sub-payments that are applied to each credit line. Of course, the credit card issuer may establish a variety of payment rations that are not symmetrical to the number of credit lines a customer has activated. In the example of Table II, because there is no outstanding balance for the 2^ndbucket, the customer's payment is split into two equal sub-payments (i.e., two $100 payments) that are applied to the general purpose credit line and extra credit line, respectively. As shown, one $100 sub-payment is applied to the 1^stbucket (reducing the outstanding balance from $200 to $100 and increasing the available balance from $800 to $900). The remaining $100 sub-payment is applied to the 3^rdbucket (reducing the outstanding balance from $100 to $0 and increasing the available balance from $100 to $200).

Option <b>2</b> (Opt. <b>2</b>) in Table II illustrates the process where the payment is applied to the three credit lines at fixed amounts. In this option, the payment amount is first applied to the 1st bucket's outstanding balance. As shown, the $250 payment is applied to the 1st bucket outstanding balance (reducing the outstanding balance from $200 to $0 and increasing the available balance from $800 to $1000). The remaining $50 of the customer's payment is then applied to the 3^rdbucket (reducing the outstanding balance from $100 to $50 and increasing the available balance from $100 to $150). Thus, with a fixed payment option, payments may be first applied to the general line of credit until the outstanding balance is reduced to zero, and remaining payments may be subsequently applied to the remaining credit lines.

As can be seen, payment option(s) allow versatility in the processing of credit card account payments received from customers. The examples illustrated in Table II are exemplary and should not be considered limiting. A number of additional payment options may also be instituted by credit card issuer. For instance, the ratios used in the proportion payment option may be adjusted to a number of different values. Additionally, in the fixed payment option, the extra credit line may have a payment applied until its outstanding balance is reduced to zero prior to applying payments to the general credit line.

As described, the present invention enables credit card holders to obtain extra lines of credit without waiting for new cards to be issued by a credit card issuer. The present invention also provides purchasing advantages to customers though the use of multiple lines of credit. Other embodiments of the invention will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the invention being indicated by the following claims. For example, in addition to associating selected vendor(s) with extra line(s) of credit that have been added to an existing credit card product, the features of the present invention may also be implemented with newly issued credit cards with extra credit lines. That is, customers who have been authorized to receive a new credit card from the credit card issuer <b>1200</b>, may also have the advantages of vendor profiles associated with extra line(s) of credit. These customers may be given the opportunity to select and edit the vendor profiles just as the customers who have had extra credit lines added to their existing credit cards. The same extra credit line procedures previously described may be followed to offer and customize a newly issued credit card with extra lines of credit with associated vendor profiles for customers.