Patent Application
20160321658
Payment card systems are in widespread use. A prominent payment card system is operated by the assignee hereof, MasterCard International Incorporated, and by its member financial institutions.
Assuming that all is in order, the issuer FI 110 transmits a favorable authorization response to the point of sale terminal 104 through the payment card network 108 and via the acquirer FI 106. (The path of the authorization response from the issuer FI 110 to the POS terminal 104 is traced by arrows 118, 120, 122.) The transaction at the point of sale terminal 104 is then completed and the customer leaves the store with the goods. A subsequent clearing transaction initiated by the merchant results in a transfer of the transaction amount from the customer's payment card account 124 to an account that belongs to the merchant. The customer's payment card account 124 may be, for example, either a debit card account or a credit card account. In the former case, the clearing transaction results in the funds being debited directly from the account 124. In the latter case, the clearing transaction results in a charge being posted against the account 124, and the charge subsequently appears on the customer's monthly credit card statement.
The foregoing description of the typical transaction may be considered to be somewhat simplified in some respects. For example, a merchant processing system (not shown) may be interposed between the POS terminal and the acquirer FI. As is familiar to those who are skilled in the art, a merchant processing system may be operated by or on behalf of the merchant to form part of the communications path between the acquirer FI and a considerable number of POS terminals operated by the merchant. It is also often the case that a third party transaction processing service, such as a payment services provider (PSP), may operate to handle payment card transactions on behalf of the acquirer and on behalf of a large number of other like financial institutions.
Many consumers/cardholders currently carry and/or use two or more payment card products, including credit, debit and pre-paid cards. The payment card products, and by extension, associated accounts, may be sponsored by one or more issuer FIs. A cardholder may choose to use different cards for different types of transactions based on, for example, a rewards incentive system or credit terms offered for a particular card, in addition to other points of differentiation. For example, a cardholder may use one card product to collect premium rewards for gas purchases, while another card may be used to collect “cash back” rewards for non-gas purchases. However, cardholders who use multiple card products may not like carrying so many cards, and may have difficulty remembering which card they prefer to use for a particular purchasing transaction. For example, a particular rewards credit card product issuer may offer 5% cashback reward on gasoline purchases and 1% cashback reward on all other purchases, while another card product issuer offers 3% cashback on all purchases. The cardholder may want to take advantage of these rewards, but may not remember which card product is associated with each reward.
The present inventors have recognized that there is a need for methods and/or systems to automatically select a particular payment card product from a cardholder's collection of payment card products, based on prior input from the cardholder.
Embodiments of the invention provide methods and/or systems to leverage different payment card products to maximize the cardholder value for a card product holder during a purchase transaction, without the card product holder having to remember parameters for each card product. In some embodiments, the methods and/or systems function to automatically select or extract a particular payment card product from a cardholder's collection of payment card products, based on prior input from the cardholder, and automatically forward an authorization request and account information associated with this selected payment card product to the issuer of the payment card product, without further input from the cardholder.
A number of terms will be used herein. The use of such terms is not intended to be limiting, but rather is used for convenience and ease of exposition. For example, as used herein, the term “cardholder” may be used interchangeably with the term “consumer” and “card product holder” and are used herein to refer to a consumer, individual business or other entity that has been issued (or authorized to use) a financial account such as a credit or debit account. The financial account may be accessed by use of a “payment card” or “payment card product” or “payment device” such as a traditional plastic or embossed magnetic stripe card, a chip card (such as an EMV card) or an RFID card (such as a PayPass™ or MasterPass™ payment card.) Pursuant to some embodiments, as used herein, the term “payment card” or “payment device” may also include a mobile device (such as a mobile telephone or table computer) operating a payment application that includes stored payment account information. As used herein, the term “card product” and “financial account associated with the card product” may be used interchangeably.
In some embodiments, a cardholder or customer registers for a card product leveraging service by providing information concerning the payment accounts (such as credit card accounts, debit card accounts, and/or gift card accounts) the cardholder wants to register to a card product leveraging computer system. In some embodiments, a cardholder or customer who owns a payment enabled mobile device (such as a smartphone, a mobile telephone, a tablet computer, a laptop computer, a personal digital assistant (PDA) and the like) registers for a card product leveraging service by providing information concerning the payment accounts (such as credit card accounts, debit card accounts, and/or gift card accounts) in his or her digital wallet to a card product leveraging computer system. When the registered cardholder enters into a purchase transaction at a retail store, or at an online store, purchase transaction information may be transmitted from a merchant's device (such as a point of sale (POS) terminal), in the retail store, or the merchant's computer in the online store, to the card product leveraging computer system for use thereby. The purchase transaction information may include data such as an amount due for the purchase, a merchant identifier, a time and date of transaction, transaction location, and product identification details such as descriptions and/or identifiers for each item being purchased (and its associated purchase price). In some embodiments, a card product leveraging module of the card product leveraging system selects at least one card product to use in the purchase transaction, as further described below, and transmits this selected card product account information to the card product issuer for authorization. The card product selection(s) may be at least partially based on the purchase transaction information and/or other information supplied by the cardholder and/or other entities.
In some embodiments, the card product leveraging computer system includes a card product leveraging module operable to analyze account information to determine and select one or more card product accounts for use in the purchase transaction. The module may utilize the purchase transaction information along with additional data to generate the selection of the card product to be used for that particular purchase transaction. When the card product leveraging module determines two or more card product accounts are available for selection, the card product accounts may be ranked in an order based on the preferences that were preselected by the cardholder such that only one card is selected, per cardholder preferences (e.g., the cardholder preference was not to split the transaction between multiple card product accounts). In other embodiments, the ranking may be made by the module (which may be based on additional data). In some embodiments, the card product leveraging computer system transmits the selected card product account information directly to the card product account issuer. Standard purchase transaction processing may then occur in order to consummate the purchase transaction. However, in some implementations, if the card product account issuer does not authorize the purchase transaction, the denial may be returned to the module, and the module may select another card product to participate in the purchase transaction.
In some embodiments, a cardholder registers for the card product leveraging service by visiting a card product leveraging website and providing requested data, or provides data in some other manner to the system. For example, the cardholder may register for the card product leveraging service by providing data to a customer service representative, by completing a form that is then received by a mail processing center, or via a third-party (e.g., by opting-in where a participating issuing bank passes the information to the card product leveraging service).
In one or more embodiments, the card product leveraging system is associated with a payment network. In one or more embodiments, the merchant's acquirer financial institution (FI) contacts a payment network with a purchase transaction request and the payment network applies the leverage module to select one of the card product accounts for use in the purchase transaction. Then the payment network identifies the cardholder's issuer financial institution (FI) and then forwards an authorization request for the purchase transaction to the issuer FI. If all is in order, the issuer FI authorizes a transfer of funds from that selected card product account to the merchant's payment account in the acquirer FI. The vehicle for the funds transfer may therefore be a conventional payment transaction of the type now supported by at least one payment card system. Upon authorization and/or completion of the payment transaction, the acquirer FI may confirm to the merchant that the funds transfer has occurred (or is assured to occur subsequently during conventional clearing operations). In response to receiving the funds transfer confirmation, the merchant then transfers ownership of the goods to the cardholder, or may accept the confirmation as payment for services rendered or to be rendered to the cardholder. Is should be understood, however, that the processes described herein may utilize a conventional payment network, and/or the internet, and/or any other network and/or payment channel.
The transaction handling system 200 includes a merchant device 202 which may be, for example, a POS terminal or a merchant website. If the merchant device is a POS terminal, such as a cash register in a retail store location, it may be configured to operate for the most part in a conventional manner, or it may have functionality that actively contributes to the transaction flow illustrated in
The transaction handling system may include an acquirer financial institution (FI) 204 that issued a merchant financial account (not shown), which may be, for example, a payment card account, a payment network 206 (for routing transactions, for example, from the issuer FI 208 to the acquirer FI 204). While only one issuer FI 208 is shown herein, a plurality of issuer FIs may be included in the system 200, each of which may represent banks, for example, that issued one or more cardholder accounts to the cardholder, such as cardholder account 210). The transaction handling system 200 may also include a card product leveraging system 212, which in some embodiments includes a card product leveraging module 214 (“leverage module”). In one or more embodiment, the card product leveraging system 212 may be part of the payment network 206. In one or more embodiments, the system 212 may be part of at least one of the other components of the system 200 shown in
As part of a purchase transaction, arrows 201-211 represent communications between the components of the transaction handling system 200. As part of a purchase transaction, the merchant device 202 transmits 201 a purchase authorization request to the merchant's acquirer FI 204. In one or more embodiments, purchase transaction information may include a merchant identifier, a transaction amount and product identification data. The merchant acquirer FI 204 receives the purchase transaction authorization request and then transmits 203 the authorization request to the payment network 206 (which includes one or more computers and/or computer systems). The payment network 206 receives the purchase transaction authorization request and determines whether the cardholder's payment account number (PAN) falls within a range of PANs corresponding to proxy or “dummy” account numbers provided by the card product leveraging system 212. The “dummy” account number may be for a composite account registered with the card product leveraging system 212, wherein the composite account includes a collection of two or more card products. When the PAN does not match a “dummy” account number, the purchase transaction continues per conventional processes. When the PAN is matched to a “dummy” account number, the payment network 206 then applies the card product leveraging system 212 for processing. The card product leveraging module 214 utilizes this transaction data (and in some cases, additional data) to determine one or more card product accounts to use in that particular purchase transaction, for example, to maximize value for the cardholder. Maximizing value for the cardholder may be based on preferences provided by that cardholder that do not necessarily equate to saving the most money or earning the maximum number of points in a rewards system. For example, the parent of a college student offers to pay for 50% of all grocery purchases. As such, purchases in the grocery category are split evenly between the parent's credit card and the student's debit card. As will be further described below, the card product leveraging module 214 then selects an account associated with at least one card product to process the purchase transaction. The payment network 206 then identifies the issuer bank for the selected card product as the issuer FI 208 and then routes 205 the authorization request to the issuer FI 208. If all is in order (i.e., the cardholder has adequate credit to pay for the purchase), then the Issuer FI 208 transmits 207 a positive or acceptance authorization response to the payment network 206 which routes 209 the authorization acceptance response to the acquirer FI 204 that may include authorization of a payment transfer from the cardholder's cardholder account 210 to the merchant account. If all is not in order (e.g., the cardholder does not have adequate credit to pay for the purchase), then the Issuer FI 208 transmits 207 a negative or decline authorization response to the payment network 206, which routes the decline to the card product leveraging system 212. In the case of decline, the card product leveraging module 214 may iteratively select another card product to provide to the Issuer FI 208 until an authorization acceptance response is provided by the Issuer FI 208 or an end condition is achieved. In one or more embodiments, the cardholder has indicated a particular other card product to provide as a default card product in the event the selected card product is declined. In some embodiments, the merchant's acquirer FI 204 then transmits 211 the authorization response to the merchant device 202 to inform the merchant of the status of the purchase transaction (e.g., authorized or denied). When the merchant device 202 receives a positive authorization confirmation message the merchant may allow the sale or other exchange of value to be completed. Except for the card product leveraging system aspect, such a purchase transaction process may be entirely conventional.
It should be understood that, in practice the transactions system 200 may include numerous Issuing FIs and a plurality of Acquirer FIs all connected to the payment network 206 and a large number of merchant devices 202.
In one or more embodiments, prior to beginning process 300, a cardholder pre-registers two or more of their existing card product accounts with the card product leveraging system 212. In one or more embodiments, the pre-registration process may be via a web interface, a customer service representative, a form received by a mail processing center, or by a third party (e.g., a cardholder opts-in to participate/register with the card product leveraging system 212 via a participating issuing bank that provides one of the existing card product accounts. The issuing bank may then pass the information to the card product leveraging system 212.) In other or more embodiments, the card product leveraging system 212 is administered and maintained by the payment network or processor 206 (e.g., MasterCard®). Other suitable pre-registration methods may be used.
The data collected during the pre-registration process may include for example, for each card product registered with the system, at least one of card product account details (e.g., card number, expiration date, etc.), an account nickname, a credit limit, balance information, an interest rate, currency conversion fees/rates, an account type (e.g., business vs cardholder, credit vs debit vs. prepaid), and usage preferences. Other suitable data may be collected.
The usage preferences may include one or more preferences or rules for the card product leveraging module 214 to apply to the request for authorization to select the appropriate card product. When registering with the card product leveraging system 212, the cardholder may select usage preferences based on that cardholder's goals and/or priorities in terms of benefits associated with the two or more card products. For example, when registering, the cardholder may select user preferences directed towards increasing cash back, earning air-line miles, having zero liability or better warranty protection when making purchases, travel benefits and/or receiving rebate and/or receiving discounts, or any other suitable goals.
A usage preference may include, for example, an indication of whether the card is the default card. For example, a default card may be the card that is used when there are no rules specified for a particular transaction. In one or more embodiments, the default card may also be used as a back-up to a preferred card should the preferred card be denied for any reason. In one or more embodiments, the default card indication may be captured as a flag (Y/N) or as an ordered ranking (e.g., use Card A first and Card B second, etc.). The usage preferences may also include processing preferences (e.g., an indication of whether the card should be used as a debit card or a credit card) and an indication of categories or particular merchants that should be billed to the card. In one or more embodiments, this information may be indicated by merchant category code (MCC) or other suitable classification. For example, a cardholder has a business account and a personal account. The cardholder wants to use the business account for all travel and entertainment purchases, and their personal account for all other purchases. Other usage preferences may include:
transaction type (e.g., recurring payments and/or returns) to be billed to the card. For example, a cardholder has a number of recurring payments set up through the “dummy” account. An advantage of one or more embodiments is if, for example, one of the cards linked to the “dummy” account is stolen, the cardholder simply updates the “dummy” account with their updated card number, when they receive the replacement card, and the recurring payments continue to bill the dummy account without any need for the cardholder to notify the merchants that bill recurring payments;
maximum amount to be billed to a card. For example, a cardholder is carrying a balance on a card and has another card that they pay in full each month. For everyday purchases under $100, the cardholder specifies to use the zero-balance account. For larger ticket purchases (greater than $100, and returns), the cardholder specifies to use the account with a balance;
split logic whereby the purchase is split among two or more cards. For example, for purchases greater than a threshold amount, bill a particular percentage or absolute amount of a purchase to card A, and the remaining percentage or absolute amount to card B. As another example, a small business owner uses a percentage share to differentiate between work related vehicle expenses (75%) and personal vehicle expenses (25%). All vehicle related purchases (e.g., maintenance, lease, gasoline) are split between two accounts to aid with accounting. As another example, a gift card is registered. The gift card amount is $100. Once the $100 of the gift card is used, the remaining charges may be sent to a default card. As yet another example, a per diem is imposed on a corporate card. Once the cumulative daily purchases exceed $100 on the corporate card, all other purchases will be applied to the cardholder's personal card. As another example, a parent will pay for their child to charge up to $25 for restaurant purchases on the parent's credit card. Any charges beyond $25 will be applied to the child's personal debit card;
time preference (day of the week, time or period of day) when purchases may be billed to the card (e.g., weekday, 9-5 purchases are billed to card A; Monday and Wednesday lunchtime dining purchases are billed to card A);
geography of the purchase location preferences (e.g., international purchases billed to card A; out-of-state purchases billed to card A); and
currency preferences (e.g., non-United States Dollar (USD) purchases billed to card A; non-USD purchases billed to the card with the cheapest currency conversion fees, as specified by the cardholder's preferences). For example, a cardholder has a card that has no rewards but offers a low fee for currency conversion. For domestic purchases or any purchases that use USD, the cardholder specifies to use a rewards card that offers airline miles for purchases, and for any non-USD purchases specifies to use the card that has low fees for currency conversion, as specified by the cardholder's preferences.
The cardholder may also note other usage preferences such as payment card restrictions, payment card balances, and payment card maintenance fees. In one or more embodiments, the cardholder may rank these preferences in an order from most important to least important, and thus in some embodiments may be prompted to assign a weight to each selected preference. It is noted that any combination of preferences may be selected for a particular card.
The data may be stored in one or more databases 213. As shown in
As part of the pre-registration process, the card product leveraging system 212 may provide the cardholder with a “dummy” or proxy account number, and in some embodiments a “dummy” card product that may be used to access all of the registered card products. The “dummy” account number or “dummy” PAN may be for a composite account registered with the card product leveraging system 212, wherein the composite account includes a collection of two or more card products. The use of a single account that stores all of the cardholder preferences may enable a cardholder to more easily leverage the different card products without having to remember all of the details associated with each card product. For example, a cardholder likes to constantly alternate between card accounts to leverage different offers (e.g., rewards, interest rates, balance revolving, paranoia about having a longstanding account with a single entity, etc.). The cardholder wants to carry a single card that may allow them to use a persistent account number despite constantly changing the cards they use. In one or more embodiments, the cardholder may use the “dummy” account as a proxy for whatever card they prefer. In one or more embodiments, the “dummy” account may reduce the instances of declines for a payment product in that a back-up account may be designated in the event of an authorization decline. Another advantage provided by embodiments is the ease of implementation in that without the single card, it may be difficult and/or unpleasant to ask the merchant to divide the purchase amount between different cards. As another example, a cardholder may have a plurality of prepaid cards. Another advantage provided by embodiments is the ease of fully defunding prepaid/gift cards. For example, the cardholder wants to use up balances of their prepaid cards without having to consciously monitor their balances or try to spend small remainders on cards. In some embodiments, the cardholder registers all the prepaid cards with the card product leveraging system 212, and specifies that purchases may span multiple card products (e.g., a $250 purchase may use up two $50 prepaid cards, and the remaining balance may be applied to a debit card).
Referring again to
The card product leveraging module 214 receives the transaction authorization request including the data associated with the purchase transaction at S314. Then in S316, the card product leveraging module 214 accesses the database 213 and analyzes the composite account data, including the usage preferences and rules associated with the card products, to determine at least one card product to process the purchase transaction. In one or more embodiments, the card product leveraging module 214 may access the rules driven logic processing module 216 during the analysis of the composite account data stored in the database 213. Then at S318 the card product leveraging module 214 selects one or more card products to process the purchase transaction based on the analysis. In one or more embodiments, the payment network 206 identifies the issuer bank for the selected card product as the issuer FI 208. The leverage processor module 214 then initiates one or more payment transactions on the payment product account(s) by transmitting the selected card product to the issuer FI 208 via the payment network 206 in S320.
As described above, if all is in order (i.e., the cardholder has adequate credit to pay for the purchase), then the Issuer FI 208 transmits a positive or acceptance authorization response to the payment network 206 which routes the authorization acceptance response to the acquirer FI 204. The acceptance authorization response may include authorization of a payment transfer from the cardholder's cardholder account 210 to the merchant account. In some embodiments, the merchant's acquirer FI 204 then transmits the authorization response to the merchant device 202 to inform the merchant that the purchase transaction has been authorized. When the merchant device 202 receives the authorization acceptance confirmation message the merchant may allow the sale or other exchange of value to be completed. Except for the card product leveraging system aspect, such a purchase transaction process may be entirely conventional
If all is not in order (e.g., the cardholder does not have adequate credit to pay for the purchase), then the Issuer FI 208 transmits 207 a negative or decline authorization response to the payment network 206. The payment network 206 then, which may route the decline to the card product leveraging system 212. In the case of decline, the card product leveraging module 214 iterates steps S316 and S318 to select at least one other card product to use in the purchase transaction. In one or more embodiments, the cardholder may specify a particular “other” card to use as a default card when a selected card has been declined. In one or more embodiments, the card product leveraging module 214 may follow additional cardholder preference logic regarding cascading authorizations, for example, whereby one or more authorizations may be run on other payment product accounts that may be authorized for purchases in the event a previously selected card product is unavailable. For example, if the selected card product does not have sufficient balance, the card product leveraging module 214 may, based on user preferences, select another card for the payment (e.g., either for the full amount of the payment or the “spillover amount”—the difference between what is available from the first selected card and “another” card). In one or more embodiments, when a purchase transaction is split between multiple cards, an authorization may be run on each payment product account, and both authorizations may need approval before the transaction is submitted. However, the merchant may consider this one transaction, even though multiple authorizations may be conducted in the background. In one or more embodiments, the card product leveraging module 214 reconciles this “one-to-many” relationship within its data infrastructure. In one or more embodiments, when a purchase transaction is split between multiple cards, a merchant transaction identifier may be generated that captures split payments as belonging to the same purchase interaction. In one or more embodiments, the card product leveraging module 214 iterates steps S316 and S318 to select a card product to provide to the Issuer FI 208 until an authorization acceptance response is provided by the Issuer FI 208 or an end condition is achieved. When an authorization acceptance response is provided by the Issuer FI, the process continues as described above, and the merchant is informed of the acceptance authorization. In one or more embodiments, the end condition may be when the card product leveraging module 214 determines other card products are unavailable to process the purchase transaction, or the card product leveraging module 214 has failed to provide another card product in a pre-determined amount of time. If an end condition is achieved, the payment network 206 transmits a decline authorization response to the merchant via the merchant's acquirer FI 204 to inform the merchant that the purchase transaction has been declined.
Note that the embodiments described herein may be implemented using any number of different hardware configurations. For example,
The processor 410 also communicates with a storage device/memory 430. The storage device 430 may comprise any appropriate information storage device, including combinations of magnetic storage devices (e.g., a hard disk drive), optical storage devices, mobile telephones, and/or semiconductor memory devices. The storage device 430 stores a program 412 and/or card product leveraging platform logic 216 for controlling the processor/module 410. The processor/module 410 performs instructions of the programs 412, 216, and thereby operates in accordance with any of the embodiments described herein. For example, the processor 410 may receive a purchase authorization request which may then be analyzed by the processor 410 to automatically determine which card product to use in the transaction.
The programs 412 stored by the storage device 430 may include a cardholder registration application 460 that manages a process by which cardholders or customers (i.e., cardholders) may register or enroll themselves with the card product leveraging system 400. As described above, in some embodiments, the cardholder enrollment process may allow the cardholders to enroll themselves by accessing a suitable web page hosted by the card product leveraging system 400, or by other enrollment methods. The information obtained from the cardholder during the enrollment process may include one or more payment card account numbers, one or more mobile telephone numbers (or other mobile identifiers), preference data and/or other information concerning the cardholder's payment card accounts. In one or more embodiments, the enrollment process may also require the cardholder to select a PIN (personal identification number) to be used for security purposes in connection with purchase transactions to be initiated by the cardholder, and/or for use by a cardholder to login and change one or more preference settings, for example. Other security measures may also be put in place, including industry-standard cardholder security processes and/or procedures.
The programs 412, 216 may be stored in a compressed, uncompiled and/or encrypted format. The programs 412, 216 may furthermore include other program elements, such as an operating system, a database management system, and/or device drivers used by the processor 410 to interface with peripheral devices.
As used herein, information may be “received” or “retrieved” by or “transmitted” to, for example: (i) the Card Product Leveraging Platform 400 from another device; or (ii) a software application or module within the Card Product Leveraging Platform 400 from another software application, module, or any other source.
In some embodiments (such as shown in
Referring to the card product database in
Turning to
When the cardholder registers the cards with the card product leveraging system 212, the cardholder indicates that the business card is to be used for purchases during a weekday (e.g., Monday through Friday) up to a certain spending amount per day, otherwise the personal card is to be used, as indicated for Dummy PAN ending in “890” in
The cardholder initiates a transaction per the process described above with respect to
In S602, the card product leverage module 214 determines, based on the information in the Table 500, whether the transaction is during a weekday. If the transaction is during a weekday, the method proceeds to S604 and the card product leverage module 214 determines, based on the information in Table 500, whether the transaction amount exceeds the per diem threshold. If the transaction amount does not exceed the per diem threshold, the card product leverage module 214 selects Card Product 1 (business card) to use in the transaction in S606.
If in S602, the card product leverage module 214 determines the transaction is not during a weekday (e.g., Saturday or Sunday), the method proceeds to S608, and the card product leverage module 214 selects Card Product 2 (personal card) to use in the transaction.
Similarly, if the card product leverage module 214 determines in S604 that the transaction amount exceeds the per diem threshold, the card product leverage module 208 selects Card Product 2 (Personal Card) to use in the transaction.
Referring again to the example, for the gas purchase of $60, the card product leverage module 214 applies the method 600 described in
As will be appreciated by one skilled in the art, aspects of the present invention may be embodied as a system, method or computer program product. Accordingly, aspects of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Furthermore, aspects of the present invention may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.
The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
It should be noted that any of the methods described herein can include an additional step of providing a system comprising distinct software modules embodied on a computer readable storage medium; the modules can include, for example, any or all of the elements depicted in the block diagrams and/or described herein; by way of example and not limitation, a card product leveraging module. The method steps can then be carried out using the distinct software modules and/or sub-modules of the system, as described above, executing on one or more hardware processors 410 (
This written description uses examples to disclose the invention, including the preferred embodiments, and also to enable any person skilled in the art to practice the invention, including making and using any devices or systems and performing any incorporated methods. The patentable scope of the invention is defined by the claims, and may include other examples that occur to those skilled in the art. Such other examples are intended to be within the scope of the claims if they have structural elements that do not differ from the literal language of the claims, or if they include equivalent structural elements with insubstantial differences from the literal languages of the claims. Aspects from the various embodiments described, as well as other known equivalents for each such aspects, can be mixed and matched by one of ordinary skill in the art to construct additional embodiments and techniques in accordance with principles of this application.
Those in the art will appreciate that various adaptations and modifications of the above-described embodiments can be configured without departing from the scope and spirit of the claims. Therefore, it is to be understood that the claims may be practiced other than as specifically described herein.
