Patent Application
20150161742
Vehicle information associated with a person may be of interest to various entities. For example, an insurance or advertising company might want to know how many miles per week a person typically drives to determine products and/or services that might be of interest to that particular person. Similarly, the type of vehicle currently being operated by a person may be of interest. For example, an automobile manufacturer might want to know which residents in a particular city currently drive hybrid gasoline/electric vehicles. Attempting to manually determine vehicle information for a group of people, such as by conducting a telephone or online survey, can be an expensive, time-consuming, and error prone task, especially when a substantial number of people are involved. As a result, systems and methods to automatically determine vehicle information may be desired.
Vehicle information associated with a person may be of interest to various entities. For example, an insurance or advertising company might want to know how often a person drives a relatively long distance (e.g., over 200 miles in a single week). Similarly, the type of vehicle owned by a person may be of interest. For example, a marketing firm might be interested in finding out who owns European automobiles. Attempting to manually determine vehicle information for a group of people, such as by conducting a telephone or online survey, can be an expensive, time-consuming, and error prone task, especially when a substantial number of people are involved. It would therefore be desirable to provide accurate and efficient systems and methods to automatically determine vehicle information.
The analyzer platform 150 might be, for example, associated with a Personal Computer (PC), laptop computer, an enterprise server, a server farm, and/or a database or similar storage devices. The analyzer platform 150 may, according to some embodiments, be associated with a credit card company.
According to some embodiments, an “automated” analyzer platform 150 may facilitate the determination of vehicle information. For example, the analyzer platform 150 may automatically output a list of people who drive relatively infrequently. As used herein, the term “automated” may refer to, for example, actions that can be performed with little (or no) intervention by a human.
As used herein, devices, including those associated with the analyzer platform 150 and any other device described herein, may exchange information via any communication network which may be one or more of a Local Area Network (LAN), a Metropolitan Area Network (MAN), a Wide Area Network (WAN), a proprietary network, a Public Switched Telephone Network (PSTN), a Wireless Application Protocol (WAP) network, a Bluetooth network, a wireless LAN network, and/or an Internet Protocol (IP) network such as the Internet, an intranet, or an extranet. Note that any devices described herein may communicate via one or more such communication networks.
The analyzer platform 150 may retrieve transaction information from the transaction database 110. The transaction database 110 might be associated with, for example, payment accounts, such as credit card or bank accounts. The transaction database 110 may be locally stored or reside remote from the analyzer platform 150. As will be described further below, the transaction database 110 may be used by the analyzer platform 150 to generate vehicle information. According to some embodiments, the analyzer platform 150 communicates vehicle information to an external device 160, such as by transmitting an electronic file to an email server, a workflow management system, etc. In other embodiments, the analyzer platform 150 might store vehicle information in a vehicle information database 170.
Although a single analyzer platform 150 is shown in
In accordance with some embodiments, the systems and methods described herein provide a framework to determine vehicle information based on transaction information associated with payment accounts. For example, a payment card may presented by a cardholder (e.g., the account owner) to make a payment. By way of example, and without limiting the generality of the foregoing, a payment card can be a credit card, debit card, charge card, stored-value card, or prepaid card or nearly any other type of financial transaction card. Further, as used herein in, the term “issuer” or “attribute provider” can include, for example, a financial institution (i.e., bank) issuing a card, a merchant issuing a merchant specific card, a stand-in processor configured to act on-behalf of the card-issuer, or any other suitable institution configured to issue a payment card. As used herein, the term “transaction” can be associated with, for example, a merchant, a merchant terminal, an automated teller machine (ATM), or any other suitable institution or device configured to initiate a financial transaction per the request of the account owner.
The information in the transaction database 110 may be associated with, for example, a “payment card processing system” or “credit card processing networks”, such as the MasterCard® network that allows account owners to use payment cards issued by a variety of issuers to shop at a variety of merchants. With this type of payment card, a card issuer or attribute provider, such as a bank, extends credit to an account owner to purchase products or services. When an account owner makes a purchase from an approved merchant, the card number and amount of the purchase, along with other relevant information, are transmitted via the processing network to a processing center, which verifies that the card has not been reported lost or stolen and that the card's credit limit has not been exceeded. In some cases, the account owner's signature is also verified, a personal identification number is required or other user authentication mechanisms are imposed. The account owner is required to repay the bank for the purchases, generally on a monthly basis.
The transaction database 110 may further store a “business classification,” which is a group of merchants and/or businesses, by the type of goods and/or service the merchant and/or business provides. For example, the group of merchants and/or businesses can include merchants and/or business, which provide similar goods and/or services. In addition, the merchants and/or businesses can be classified based on geographical location, sales, and any other type of classification, which can be used to associate a merchant and/or business with similar goods, services, locations, economic and/or business sector, industry and/or industry group.
The transaction database 110 may also store a “merchant category code” or “MCC,” which is a four-digit number created by MasterCard® or VISA® and assigned to a business by the acquirer when the business first starts accepting one of these cards as a form of payment. The MCC is used to classify the business by the type of goods or services it provides. For example, in the United States, the merchant category code can be used to determine if a payment needs to be reported to the IRS for tax purposes. In addition, Merchant Category Codes (or “MCCs”) are used by card issuers to categorize, track or restrict certain types of purchases.
In accordance with some embodiments, data associated with payment card transactions is stored within the transaction database 110. The data may include, for example, a listing of sales amount for each payment card transaction including the type of goods and/or services sold, a total number of goods and/or services sold in each transaction, a total sales amount for each transaction (e.g., gross dollar amount). In addition, for each merchant and/or business, the data associated with each transaction may include a point-of-sale or point-of-purchase (e.g., location of each payment card transaction). The point-of-sale or point-of-purchase provides that for merchants and/or businesses having one or more locations, the location of the merchant and/or business, which generated the sale can be identified.
At S210, transaction information associated with payments made via a payment account, associated with an account owner, may be retrieved from a transaction database. The payment account may be associated, for example, a credit card account, a debit card account, a bank account, a pre-paid card account, or any other type of payment account. The transaction information may include, for example, an account identifier, a merchant identifier, a date, a time of day, a payment amount, a payment description, or any other type of transaction information.
At S220, the retrieved transaction information may be analyzed to automatically determine “vehicle” information associated with the account owner. As used herein, the term “vehicle” might refer to, for example, an automobile, a truck, a construction vehicle, a motorcycle, a boat, a snowmobile, and/or an airplane. Moreover, the phrase “vehicle information” may refer to estimated driving information, predicted vehicle ownership information, or any other type of vehicle information. At S230, the automatically determined vehicle information may be output. For example, the vehicle information might be displayed on a computer monitor, transmitted in a computer file, and/or stored in a database.
In this way, transaction information may be analyzed to automatically determine vehicle information. Note that the embodiments described herein may be implemented using any number of different hardware configurations. For example,
The processor 310 also communicates with a storage device 330. The storage device 330 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 330 stores a program 312 and/or analyzer platform logic 314 for controlling the processor 310. The processor 310 performs instructions of the programs 312, 314, and thereby operates in accordance with any of the embodiments described herein. For example, the processor 310 may retrieve transaction information associated with payments made via a payment account (e.g., a credit card account), associated with an account owner, from a transaction database. The retrieved transaction information may then be analyzed by the processor 310 to automatically determine vehicle information associated with the account owner. For example, estimated driving information or predicted vehicle ownership information might be automatically determined by the processor 310.
The programs 312, 314 may be stored in a compressed, uncompiled and/or encrypted format. The programs 312, 314 may furthermore include other program elements, such as an operating system, a database management system, and/or device drivers used by the processor 310 to interface with peripheral devices.
As used herein, information may be “received” by or “transmitted” to, for example: (i) the analyzer platform 300 from another device; or (ii) a software application or module within the analyzer platform 300 from another software application, module, or any other source.
In some embodiments (such as shown in
Referring to
The account identifier 402 may be, for example, a unique alphanumeric code identifying a payment account, such as a Primary Account Number (“PAN”). The transaction identifier 402 may be associated with a particular transaction (e.g., a purchase at a gas station). The date and time 406 may indicate when the transaction occurred, and the amount 408 may indicate the monetary amount of the transaction. The description may indicate what was purchased in the transaction (e.g., a general indication that a credit card was used at a gasoline pump, a type of goods or services typically offered by the merchant, etc.).
Referring to
The merchant identifier 502 may be, for example, a unique alphanumeric code identifying a merchant and may, or may not, be associated with the merchant identifier 404 in the transaction database 400. The merchant description 504 may be associated with, for example, an MCC or other data indicating the type of goods and/or services offered by the merchant. The location 506 may, for example, comprise an address, a ZIP code, a latitude and longitude, or any other information associated with the merchant's geographic location.
Referring to
The account identifier 602 may be, for example, a unique alphanumeric code identifying a payment account and may, or may not, be associated with the account identifier 402 in the transaction database 400. The estimated driving information 604 may, for example, indicate how far the account owner typically drives over a given period of time (e.g., miles-per-week or miles-per-year). The predicted vehicle ownership information 606 may, for example, indicate a type or model of vehicle that may be owned (including, for example, via a rental lease) by the payment account owner.
At S740, it is determined whether predicted vehicle ownership information is known for the account owner (e.g., as described with respect to
Note that a single payment account may be used by more than one person. For example, multiple member of a family or business may use a payment account. Note that embodiments described herein may generate an estimated amount of miles driven by an account owner, an account owner's household, and/or an account owner's business. Moreover, the specific rules and logic of
Note that a single payment account may be used by more than one person. For example, multiple member of a family or business may use a payment account. Note that embodiments described herein may generate predicted vehicle ownership information for an account owner, an account owner's household, and/or an account owner's business. 10. Moreover, the specific rules and logic of
Note that rules and logic described with respect to
The predictive model generator 1050 may look for patterns in the historical transaction information to identify relevant factors and/or associated weights. For example, account owners who have transactions with a HARLEY-DAVIDSON store might be identified as being highly likely to drive a motorcycle.
Thus, according to some embodiments, vehicle information may be based at least in part on rules created by a predictive model trained with historical transaction information. According to some embodiments, a predictive model utilizes different groupings associated with different sets and/or weights of relevant factors. For example, depending on high level grouping, different variables may be significant and/or relevant and the weightings of common variables may be different.
In general, and for the purposes of introducing concepts of embodiments of the present invention, a computer system may incorporate a “predictive model.” As used herein, the phrase “predictive model” might refer to, for example, any of a class of algorithms that are used to understand relative factors contributing to an outcome, estimate unknown outcomes, discover trends, and/or make other estimations based on a data set of factors collected across prior trials. Note that a predictive model might refer to, but is not limited to, methods such as ordinary least squares regression, logistic regression, decision trees, neural networks, generalized linear models, and/or Bayesian models. The predictive model is trained with historical transaction information, and may be applied to current or test transactions to determine vehicle information.
The predictive model generator 1050 may operate generally in accordance with conventional principles for predictive models, except, as noted herein, for at least some of the types of data to which the predictive model component is applied. Those who are skilled in the art are generally familiar with programming of predictive models. It is within the abilities of those who are skilled in the art, if guided by the teachings of this disclosure, to program a predictive model to operate as described herein. The predictive model generator 1050, in various implementation, may include one or more of neural networks, Bayesian networks (such as Hidden Markov models), expert systems, decision trees, collections of decision trees, support vector machines, or other systems known in the art for addressing problems with large numbers of variables. According to some embodiments, the predictive model(s) are trained on prior data and vehicle types known to the credit card company. The specific data and outcomes analyzed may vary depending on the desired functionality of the particular predictive model. The particular data parameters selected for analysis in the training process may be determined by using regression analysis and/or other statistical techniques known in the art for identifying relevant variables in multivariable systems.
The present invention has been described in terms of several embodiments solely for the purpose of illustration. Persons skilled in the art will recognize from this description that the invention is not limited to the embodiments described, but may be practiced with modifications and alterations limited only by the spirit and scope of the appended claims.
