Patent Application
20240403876
As consumer expectations evolve, the ability for issuers to offer compelling value propositions that align with the experience consumers expect has become an even more important differentiator in driving customer loyalty. Currently, credit account issuers offering value propositions for their credit account programs are often unable to clearly identify transactions at a merchant level when made through merchant aggregators (e.g., Ticketmaster, Seatgeek, StubHub, PayPal, Square, etc.). That is, the merchant aggregator behind the transaction is identified to a credit account provider when a purchase is made, but the actual merchant (or sub-merchant) providing the transacted for goods is not usually identified by the merchant aggregator. This inability to clearly identify a merchant (or sub-merchant) used by the merchant aggregator facilitating the transaction creates a significant limitation in the ability to offer accelerated rewards earn on specific categories of transactions (merchants) processed through these aggregators.
The accompanying drawings, which are incorporated in and form a part of this specification, illustrate various embodiments and, together with the Description of Embodiments, serve to explain principles discussed below. The drawings referred to in this brief description should not be understood as being drawn to scale unless specifically noted.
Reference will now be made in detail to embodiments of the subject matter, examples of which are illustrated in the accompanying drawings. While the subject matter discussed herein will be described in conjunction with various embodiments, it will be understood that they are not intended to limit the subject matter to these embodiments. On the contrary, the presented embodiments are intended to cover alternatives, modifications and equivalents, which may be included within the spirit and scope of the various embodiments as defined by the appended claims. Furthermore, in the Description of Embodiments, numerous specific details are set forth in order to provide a thorough understanding of embodiments of the present subject matter. However, embodiments may be practiced without these specific details. In other instances, well known methods, procedures, components, and circuits have not been described in detail as not to unnecessarily obscure aspects of the described embodiments.
Unless specifically stated otherwise as apparent from the following discussions, it is appreciated that throughout the present Description of Embodiments, discussions utilizing terms such as “selecting”, “outputting”, “inputting”, “providing”, “receiving”, “utilizing”, “obtaining”, “updating”, “accessing”, “changing”, “deciding”, “determining”, “interacting”, “searching”, “pinging” or the like, often refer to the actions and processes of an electronic computing device/system, such as a desktop computer, notebook computer, tablet, mobile phone, and electronic personal display, among others. The electronic computing device/system manipulates and transforms data represented as physical (electronic) quantities within the circuits, electronic registers, memories, logic, and/or components and the like of the electronic computing device/system into other data similarly represented as physical quantities within the electronic computing device/system or other electronic computing devices/systems.
In the following discussion, the term “retailer” is used to define a company or conglomeration that includes one or more brands. The term “brand” refers to a specific section of the retailer that includes a number of stores. The term “store” refers to a single sales location, a store could be a physical store (e.g., brick and mortar) or it could be a virtual store (e.g., a location that is accessed via the web).
The term “customer” is used herein to describe an actual or potential consumer of the retailer's goods and/or services.
The term “co-branded account” is used herein to describe a general purpose open-end revolving line of credit which is established by a credit provider for an accountholder pursuant to the terms of a credit agreement and in accordance with credit account association rules and regulations, and marketed with retailer's mark and the trade names and/or logos of a credit account association. In one embodiment, a co-brand credit card has a major/well-known credit card provider bug in conjunction with a brand specific emblem. The co-brand credit card can be used anywhere (or almost anywhere) a credit card can be used. There can be rewards, offers, financing, etc. as customer incentive. It is an open-ended, revolving credit product. There is often a credit limit, you can purchase as long as there is credit available, it is paid down by the customer making payments (monthly, minimum, in-full, overtime, etc.), and it remains an open account indefinitely, e.g., until canceled by customer or by credit account provider.
In one embodiment, the co-branded credit account can have an associated physical card, e.g., a credit card that is carried by a customer and includes the credit account information required for a purchase. In one embodiment, the co-branded credit account can have an associated virtual card that can be stored in a mobile wallet or otherwise digitally stored by the customer and includes the credit account information required for a purchase. In one embodiment, the co-branded credit account can have both a physical card and a virtual card.
The term “private label credit card” (PLCC) is used herein to describe a credit account that is intended for use at a specific brand of stores. The PLCC is a type of revolving credit plan managed by a bank or commercial finance company. The PLCC is often issued without an expiration date. In one embodiment, a branded credit card or (PLCC)) is a brand specific credit account. It can be used at any store under the brand/retailer. In one embodiment, there may be lower credit limits than a co-branded credit card. In one embodiment, branded credit cards can include rewards, offers, financing, etc. as customer incentive. It is an open-ended, revolving credit product. There is often a credit limit, you can purchase as long as there is credit available, it is paid down by the customer making payments (monthly, minimum, in-full, overtime, etc.), and it remains an open account indefinitely, e.g., until canceled by customer or by credit account provider.
In one embodiment, the PLCC account can have an associated physical card, e.g., a credit card that is carried by a customer and includes the credit account information required for a purchase. In one embodiment, the PLCC account can have an associated virtual card that can be stored in a mobile wallet or otherwise digitally stored by the customer and includes the credit account information required for a purchase. In one embodiment, the PLCC account can have both a physical card and a virtual card.
In one embodiment, a PLCC can be part of a “universal PLCC” (UPLCC) which is a private label account that issues with an association logo on the back of the associated credit card, the UPLCC usually has limited use. In some cases, the UPLCC can be a part of a conglomerations of different brands that utilize the same card association. For purposes of clarity, in the following discussion the term PLCC is used to describe both the PLCC and the UPLCC.
The terms “cardholder” and “account holder” are used herein to describe a customer that has at least one credit account. As discussed herein, the cardholder could be a customer with a physical card, a virtual card, or both a physical and a virtual card that can be used to facilitate transactions with the credit account.
The following discussion provides a novel approach for automatic sub-merchant Identification number (SMID) ingestion that automatically identifies a sub-merchant that provided the transacted for goods in a merchant aggregator transaction.
For example, many credit account value propositions are based on some sort of 3-2-1 point structure (or the like) that results in the customer earning gift cards that can be used at the brand. E.g., 3% back at the brand, 2% at some fixed and/or adjustable category, and 1% on everything else. Such a format tends allows the credit account provider to modify the middle category (e.g., the 2%) of the value proposition process for promotions, time periods, events, and the like. By providing a dynamic category (or categories) the credit account program can be used to drive promotions, events, customer specific rewards, and the like.
Importantly, the various embodiments of the present invention do not merely implement an existing processes on a computer. Instead, the present embodiments, as will be described and explained below in detail, provide a novel approach for automatic SMID ingestion that automatically identifies a sub-merchant that provided the transacted for goods in a merchant aggregator transaction and utilizes network relationships, communications, and interactivity to identify and provide a proffered reward to the appropriate customers. By using the aspects discussed herein, the operational network demands of the credit provides computer system is also reduced as the channels for requests, reviews, and rewards are moved from customer and sub-merchant and replaced with the operation of SMID ingestion and customer identification and reward being identified during the transaction authorization request.
Moreover, the embodiments do not recite a mathematical algorithm; nor do they recite a fundamental economic or longstanding commercial practice. Instead, they address a challenge to a credit account the top of wallet card, in a “what have you done for me lately” environment that has been created and continues to rapidly evolve in the Internet-centric connected world.
Thus, the embodiments do not merely recite the performance of some business practice known from the pre-Internet world along with the requirement to perform it on a computing device. Instead, the embodiments illustrate a novel, clearly applied, specific solution to maintain and promote customer loyalty in the realm of real-time offers from different credit account providers, which cardholders are continuously bombarded with, in the growing digital environment.
Referring now to
In one embodiment, a merchant aggregator 10 is an entity such as (e.g., Ticketmaster, Seatgeek, StubHub, PayPal, Square, etc.) that provides customer 36 with a single transaction location but which includes one or more merchants (hereinafter “sub-merchants”) providing the transacted for goods.
For example, a ticket merchant aggregator 10 might contract with a number of different sub-merchants such as a racetrack, an arena, a stadium, a pavilion, and the like. In so doing, the ticket merchant aggregator 10 would be able to provide customer 36 with a ticket to one or a number of events. In one embodiment, the events could be shows, races, concerts, and the like.
In one embodiment, the merchant aggregator 10 behind the transaction is identified as the party requesting authorization from the credit account provider 200 when a transaction is made, while the sub-merchant is paid by the merchant aggregator 10 and therefore does not need to obtain the purchase authorization from the credit account provider 200. As such, the credit account provider 200 will need to perform the unique automated process disclosed herein to identify the sub-merchant used by the merchant aggregator 10 and credit the customer with the appropriate reward based on the customer's reward system maintained by the credit account provider 200.
In one embodiment, merchant aggregator 10 includes a computing system with one or more components similar to the computing system described in
In one embodiment, sub-merchant A 20, B 23, and n include one or more components of a computing system similar to the computing system described in
In one embodiment, customer 36 is a customer's computing system such as a mobile device, laptop, desktop, tablet, or the like. In one embodiment, customer 36 uses a computer system with one or more components similar to the computing system described in
In one embodiment, credit account provider 200 include one or more components of a computing system similar to the computing system described in
With reference now to
In general, customer 36 identifies the customer associated with the transaction. Merchant aggregator 10 identifies the specific merchant aggregator 10 associated with the transaction. Date 75 is a date of the transaction (it could be the date of actual occurrence of the transaction, the date of transaction recordation, a combination of the two, or the like.). Sub-merchant ID n is the identifier used by merchant aggregator 10 to identify the sub-merchant associated with the transaction. In one embodiment, the sub-merchant ID n is an alphanumeric identifier. Cost 77 indicates the amount spent on the transaction. Item 84 is the good and/or service acquired during the transaction. Other 93 refers to other data that could be included in the transaction authorization request 201 data such as, but not limited to, a transaction location (e.g., internet/in-store/address/store-identifier code, etc.), a transaction type (plastic card, digital wallet, etc.), a SKU (or other item identifier), a size, a description of the item, etc.
Referring now to
In one embodiment, credit provider system 200 can be a single machine, a virtual machine, a distributed system, a plurality of machines, or the like utilizing a network 226 connection between one or more of the components, the database 227, or the like. In one embodiment, network 226 is the Internet, a secure network, local area network, cellular network, a hybrid of two or more different networks, and the like.
Database 227 could be a local database, a virtual database, a cloud database, a plurality of databases, or a combination thereof. In one embodiment, database 227 includes customer information such as, but not limited to, shopping preferences, credit account(s), shopping history, and the like.
In one embodiment, transaction request receiver 225 receives the transaction authorization request 201 from the merchant aggregator 10.
In one embodiment, merchant identifier 230 obtains the sub-merchant ID n from the transaction authorization request 201 and accesses database 227 to perform a search to identify the sub-merchant. In one embodiment, merchant identifier 230 may use other of the pieces of data from transaction authorization request 201 in conjunction with (or in place of) sub-merchant ID n to perform the identification of the sub-merchant.
In one embodiment, customer identifier 235 obtains the customer account information from the customer 36 information provided in the transaction authorization request 201 and accesses database 227 to search and identify the customer's credit account.
In one embodiment, reward identifier 240 utilizes the identification of the sub-merchant, the customer account information from the customer 36 information, and/or any other purchase information (e.g., cost 308, item 310, date 305, other 312, and/or the like) provided in the transaction authorization request 201 to search database 227 and identify and/or determine the appropriate reward 250 for the customer 36.
Credit provider system 200 then provides the appropriate reward 250 to the customer 36. In one embodiment, the appropriate reward is posted to the customer's account. In one embodiment, the appropriate reward is provided to the customer.
Referring now to
With reference now to
Referring now to
For example, in one embodiment, the merchant aggregator 10 will assign a sub-merchant with a specific ID. In one embodiment, the sub-merchant ID n will be a constant for the sub-merchant regardless of the merchant aggregator facilitating the transaction. In one embodiment, the sub-merchant ID n will be a constant for the sub-merchant for a given merchant aggregator 10 facilitating the transaction but may change between different merchant aggregators.
In one embodiment, client provider system 200 will store merchant aggregator 10 identifiers in the database. In one embodiment, the sub-merchant IDs for one, some, or all of the merchants used by merchant aggregator 10 will be related to the merchant aggregator 10 in the database. In one embodiment, the merchant aggregator 10 will provide the sub-merchant IDs to the credit provider system 200 for storage in database 227.
In one embodiment, the merchant aggregator 10 will provide the sub merchant ID n as part of the transaction authorization request 201.
In one embodiment, if the merchant aggregator 10 does not provide the sub merchant ID n as part of the transaction authorization request 201, the credit provider system 200 will automatically query the merchant aggregator 10 to get the sub merchant ID n. In one embodiment, the query is sent prior to the authorization of the transaction. In one embodiment, the response from the merchant aggregator 10 is required before the transaction is authorized.
In one embodiment, if the merchant aggregator 10 does not provide the sub-merchant ID n as part of the transaction authorization request 201 (or does not identify their sub-merchant ID's), the credit provider system 200 will utilize other aspects of the transaction authorization request and/or other transaction information about the merchant aggregator 10 to automatically determine the identity of the sub-merchant. For example, if the transaction authorization request 201 provides an item 310 description (e.g., ZZ top tickets and a show date (or town, etc.)), the merchant identifier 230 of the credit provider system 200 could search database 227 for any other ZZ top tickets with the same show date (or town, etc.). If another transaction is identified as being provided by a sub-merchant (e.g., Awesome Stadium), the merchant identifier 230 would identify the sub-merchant as Awesome Stadium.
In one embodiment, if the merchant identifier 230 of the credit provider system 200 cannot identify the sub-merchant then no additional reward would be provided to the customer 36. However, if the customer 36 contacted the credit provider system 200 and identified the purchase as being from a sub-merchant (e.g., Awesome Stadium) that should have incurred a reward for the customer 36, in one embodiment, the merchant identifier 230 of the credit provider system 200 will update the identification system to now identify that purchase (e.g., ZZ top tickets and a show date (or location, etc.)) as being provided by sub-merchant (e.g., Awesome Stadium). In so doing, the merchant identifier 230 will then be able to identify any other transactions (e.g., ZZ top tickets and a show date (or town, etc.)) for any other customers as being provided by the now identified sub-merchant. Moreover, in one embodiment, the merchant identifier 230 could add information such as concerts at a given town, (or other location identifier), would likely be at a venue such as “Awesome Stadium”, which would allow the merchant identifier 230 to have a narrowed list of possible sub-merchants based on information provided in the transaction authorization request 201.
Thus, the merchant identifier 230 would build a “living” database that would grow in the realm of automated sub-merchant identification capabilities as the merchant identifier 230 learned from each piece of obtained data. As such, the capabilities of merchant identifier 230 would operate as an artificial intelligence (AI) that would continually learn from data provided by pluralities of merchants, merchant aggregators, customers, and the like until the merchant identifier 230 would become capable of automatically identifying (or making an educated guess) as to the underlying sub-merchant based on information gleaned from the transaction authorization request 201.
With reference now to
Referring now to
With reference now to
Computer system 500 of
Computer system 500 also includes computer usable non-volatile memory 510, e.g., read only memory (ROM), coupled to bus 504 for storing static information and instructions for processors 505A, 505B, and 505C. Also present in computer system 500 is a data storage unit 512 (e.g., a magnetic disk drive, optical disk drive, solid state drive (SSD), and the like) coupled to bus 504 for storing information and instructions. Computer system 500 also can optionally include an alpha-numeric input device 514 including alphanumeric and function keys coupled to bus 504 for communicating information and command selections to processor 505A or processors 505A, 505B, and 505C. Computer system 500 also can optionally include a cursor control device 515 coupled to bus 504 for communicating user input information and command selections to processor 505A or processors 505A, 505B, and 505C. Cursor control device may be a touch sensor, gesture recognition device, and the like. Computer system 500 of the present embodiment can optionally include a display 518 coupled to bus 504 for displaying information.
Referring still to
Computer system 500 is also well suited to having a cursor directed by other means such as, for example, voice commands. Computer system 500 also includes an I/O device 520 for coupling computer system 500 with external entities. For example, in one embodiment, I/O device 520 is a modem for enabling wired or wireless communications between computer system 500 and an external network such as, but not limited to, the Internet or intranet. A more detailed discussion of the present technology is found below.
Referring still to
Computer system 500 also includes one or more signal generating and receiving device(s) 530 coupled with bus 504 for enabling computer system 500 to interface with other electronic devices and computer systems. Signal generating and receiving device(s) 530 of the present embodiment may include wired serial adaptors, modems, and network adaptors, wireless modems, and wireless network adaptors, and other such communication technology. The signal generating and receiving device(s) 530 may work in conjunction with one (or more) communication interface 532 for coupling information to and/or from computer system 500. Communication interface 532 may include a serial port, parallel port, Universal Serial Bus (USB), Ethernet port, Bluetooth, thunderbolt, near field communications port, WiFi, Cellular modem, or other input/output interface. Communication interface 532 may physically, electrically, optically, or wirelessly (e.g., via radio frequency) couple computer system 500 with another device, such as a mobile phone, radio, or computer system.
Computer system 500 is only one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of the present technology. Neither should the computing environment be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the example computer system 500.
The present technology may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform particular tasks or implement particular abstract data types. The present technology may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer-storage media including memory-storage devices.
The foregoing Description of Embodiments is not intended to be exhaustive or to limit the embodiments to the precise form described. Instead, example embodiments in this Description of Embodiments have been presented in order to enable persons of skill in the art to make and use embodiments of the described subject matter. Moreover, various embodiments have been described in various combinations. However, any two or more embodiments may be combined. Although some embodiments have been described in a language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed by way of illustration and as example forms of implementing the claims and their equivalents.
