US20230342439A1

US20230342439A1 - Disambiguation and authentication of device users

Info

Publication number: US20230342439A1
Application number: US18/059,841
Authority: US
Inventors: Steven Yin; Kevin Chen; Eric Haller; Alan Tsang; David Kerry; Derek Toub; Jack Yu; Zhixuan Wang; Christopher Wheeler; Sreeram Upendran
Original assignee: Experian Information Solutions LLC
Current assignee: Experian Information Solutions LLC
Priority date: 2016-08-24
Filing date: 2022-11-29
Publication date: 2023-10-26
Also published as: US20180060954A1; US10678894B2; US20180060546A1; US11550886B2; US20200349240A1; WO2018039377A1

Abstract

Features are described for efficiently and accurately identifying a user of an electronic device with limited user interaction. The features include receiving a mobile device identifier from the mobile device. The features include transmitting the mobile device identifier to a service provider associated with the mobile device. The features include receiving information identifying the user from the service provider. The features include identifying a set of candidates associated with at least a portion of the information. The features include generating a metric for the candidates included in the set of candidates. An individual metric indicates a degree of relatedness between a value for the user for the at least one data field and a value for a candidate for the at least one data field. The features include identifying the user as a specific candidate included in the set of candidates based on the metric corresponding to a threshold.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. Application No. 16/864,443, filed 1 May 2020 and entitled “Disambiguation and Authentication of Device Users,” which is a continuation of U.S. Application No. 15/684,590, filed 23 Aug. 2017 and entitled “Disambiguation and Authentication of Device Users,” which are hereby incorporated in their entirety herein. This application claims a priority benefit to U.S. Provisional Application No. 62/379,019, filed 24 Aug. 2016 and entitled “System and Method of Providing Mobile Location Based Content.” This application also claims a priority benefit to U.S. Provisional Application No. 62/459,919, filed 16 Feb. 2017 and entitled “System and Method of Providing Mobile Location Based Content.” Each of the foregoing applications and appendices thereto are hereby expressly incorporated by reference in their entirety. Furthermore, any and all priority claims identified in the Application Data Sheet, or any correction thereto, are hereby incorporated by reference under 37 C.F.R. § 1.57.

BACKGROUND

Field

The present application relates generally to identifying and providing content to specifically and dynamically identified mobile devices.

Background

Systems often require substantial inputs to accurately identify a user and content to provide to the user. In many cases, the users may access such systems using portable communication devices, which have limited resources. For example, the device may be a smartphone, which may have a small screen and limited input mechanisms as compared to, for example, a desktop computer. Such devices may also have power, bandwidth, processor time, or other limitations on the ability to process data. Each additional element to be processed by a mobile device may be accompanied by an incremental drain on such resources.
As more services are deployed and seek to interface with mobile devices, improvements in how users and content are identified are desirable.

SUMMARY

The methods and devices described herein may include one or more of several aspects, no single one of which is solely responsible for the desirable attributes of a particular embodiment. Without limiting the scope of this disclosure, some features will now be discussed briefly. After considering this discussion, and particularly after reading the section entitled “Detailed Description” one will understand how the features described provide advantages that include identifying and providing content to specifically and dynamically identified mobile devices, among other advantages.
Various embodiments of the present disclosure provide improvements to various technologies and technological fields. For example, existing authentication systems require significant personally identifiable information (“PII”) from a user to uniquely verify the identity of the user. Among other things, the present disclosure describes improvements to, and useful applications of, various computer systems and software that does not require collection, transmission, and processing of as much personal information of the user as in current identification and/or content provisioning systems.
Additionally, various embodiments of the present disclosure are inextricably tied to computer technology. In particular, various systems and methods discussed herein provide monitoring of electronic databases, processing of large volumes of data items, generation and transmission of electronic notifications, and the like. Such features and others are intimately tied to, and enabled by, computer technology, and would not exist except for computer technology. Further, the implementation of the various embodiments of the present disclosure via computer technology enables many of the advantages described herein, including more efficient processing of various types of electronic data.

BRIEF DESCRIPTIONS OF THE DRAWINGS

FIG. 1 is a block diagram showing an example environment for providing personalized content to a mobile device.

FIG. 2 is a flow diagram showing an example method of behavior initiated content provisioning.

FIG. 3 is a flow diagram showing an example method of user requested content provisioning.

FIG. 4 is a flow diagram showing an example method of identifying a user.

FIG. 5 is a messaging diagram showing example communications for providing personalized content to a mobile device.

FIG. 6A is a pictorial diagram showing example user interface transitions for requesting and receiving personalized content on a mobile device.

FIG. 6B is a pictorial diagram showing another example user interface transitions for requesting and receiving personalized content on a mobile device.

FIG. 7 is a block diagram showing example components of a location or behavior based content provisioning computing system.

FIG. 8 is a block diagram showing example components of an identity service for identifying a user of a mobile device.

DETAILED DESCIPTION

Features are described for using mobile device location history to identify an individual and provide content such as an offer of credit to the identified individual. In some embodiments, this includes predicting the identity of the user based at least in part on the location history for the user. Once a user is uniquely identified, the system and methods described may also collect personal information that may be used to determine whether an offer for credit should be provided to the user, such as from credit data of the user, and generate the offer of credit for transmission to the user, such as in real-time while the user is at a location where the credit may be used. Various embodiments may also pre-populate an online application for credit, initiate review of the credit application, and/or provide the user with information regarding the approved credit request. In certain embodiments discussed herein, additional features are included for confirming the predicted identity by asking a dynamically identified, limited set of questions that can solicit responses usable to uniquely identify the user.

Terms

To facilitate an understanding of the systems and methods discussed herein, certain terms are defined below. The terms defined below, as well as other terms used herein, should be construed to include the provided definitions, the ordinary and customary meaning of the terms, and/or any other implied meaning for the respective terms. Thus, the definitions below do not limit the meaning of these terms, but only provide exemplary definitions.
User: An entity, such as an individual or a group of individuals associated with some device, such as a computing device. For example, the various systems and methods discussed herein often refer to a user that is typically an individual consumer (e.g., a first consumer is John Doe) that operates a particular computing device (e.g., John Doe has an iPhone). In other embodiments, however, users may be groups of persons (e.g., a household of individuals, a married couple, etc.) associated with other computing devices or groups of computing devices (e.g., an entire household of mobile and stationary computing devices).
A content provisioning entity (also referred to herein as a “content provisioning system”, or simply “the system”) is generally an entity and/or associated computing systems that maintain and/or have access to regulated user data that is usable to identify users that qualify for a particular product or service. The content provisioning entity manages a computing systems and/or modules that receive publication criteria indicating user attributes that qualify users for an offer for a product or service from the offer provider.
Depending on the embodiment, the regulated user data may include credit data regulated by the Fair Credit Reporting Act (FCRA), which restricts sharing of the credit data from the content provisioning entity. Thus, in some embodiments the content provisioning entity is a credit bureau, a business unit of a credit bureau that maintains the credit data and enforces the FCRA access regulations, and/or another entity that is authorized to access the credit data. In other embodiments, the regulated user data may include other types of data, such as healthcare data regulated by the Health Insurance Portability and Accountability Act (HIPAA) or other data that is subject to external regulations (such as set by a government agency) that restrict access to user data that is useful in screening users for certain goods or services.
In the examples discussed herein, the content provisioning entity is configured to limit dissemination of any regulated and/or non-regulated user data, such as to reduce the risk that the regulated user data is used in a manner that may not meet the relevant regulations. For example, credit data (regulated user data) is subject to access restrictions of the FCRA that restrict use of user credit data in a different manner than regulations and/or sharing restrictions that may be imposed on marketing data of a content provisioning entity. Thus, even if the content provisioning entity is authorized to use the regulated user data, the pre-validation system may limit regulated user data provided to the content provisioning entity to reduce risks associate with data loss (whether intentional or fraudulent) at the content provisioning entity (which may not have the same level of data protection as the content provisioning entity). Depending on the embodiment, pre-validation processes discussed herein may include one or more prescreen and/or pre-qualification processes.
An offer provider (also referred to as an “offer provider entity”, “offer computing system”, or “offer system”) is generally an organization that offers goods or services to users (e.g., users), such as goods or services that introduce some risk of loss to the offer provider if the user fails to comply with terms of the agreement between the offer provider and the user. For example, the offer provider may be a credit card issuer that offers and issues credit cards to individuals. Prior to offering such financial services to users, the credit card issuer typically analyzes (or receives information from another entity regarding) financial information of the user to determine risk associated with offering a credit card to the user. For example, a risk score, such as a credit score, may be used as an indicator of risk that the user defaults on the credit card. In other embodiments, the offer provider may be an insurance provider, a mortgage broker, a product or service supplier/manufacturer/distributer, an intermediary for services and products, a marketing or public relations firm, or any other entity that offers products or services. In some embodiments, the offer provider identifies publication criteria that must be met for the offer provider to approve providing product or service offers to users. For example, a credit card issuer offer provider may determine publication criteria (associated with providing a firm offer of credit to consumers) indicating a minimum credit score (e.g., above 700) that is required for the credit card issuer to offer a particular credit card to a user.
A user device (also referred to herein as a “user device”) generally includes any device of a user, such as an electronic device through which an offer from an offer provider may be displayed (e.g., via software and/or a site of a digital display entity). User devices may include, for example, desktop computer workstation, a smart phone such as an Apple iPhone or an Android phone, a computer laptop, a tablet such as an iPad, Kindle, or Android tablet, a video game console, other handheld computing devices, smart watch, another wearable device, etc. In many embodiments discussed herein, the user device is a mobile device, such as a smart phone; however, other user devices (e.g., laptops, kiosks, etc.,) may be used.
Regulated user data generally includes information regarding users that is stored by an entity (e.g., a content provisioning entity) and is subject to external regulations (such as set by a government agency) that restrict how the user information may be used (e.g., accessed, updated, shared, etc.) outside of the storing entity. Regulated user data generally is useful in validating users to receive offers for certain goods or services, but may include sensitive user data that should be protected to a greater degree than publicly available user information. Thus, in some embodiments, dissemination, sharing, and/or any other access to regulated user data may be controlled closely by the storing entity to reduce risks associated with improper use of the regulated data, such as any sharing of regulated user data that violates the relevant regulations. Accordingly, while regulated user data may be optimal for determining certain characteristics or propensities of users, such as determining risks associated with issuing a credit account to users, sharing of regulated user data with offer providers, digital display entities, and/or others that might be involved in related marketing or communications to the user may be limited to include only the minimum required regulated user data or no regulated user data.
In one embodiment, regulated user data is credit data that is regulated by the Fair Credit Reporting Act (FCRA), which restricts use of the credit data, such as by limiting how credit data of users may be shared with marketing entities. Thus, in some embodiments the content provisioning entity is a credit bureau, a business unit of a credit bureau that maintains the credit data and enforces the FCRA access regulations, and/or another entity that is authorized to access the credit data. Accordingly, in such an embodiment, the content provisioning entity may limit the use or sharing of user credit data to reduce risk of disclosure or other use of the credit data outside of FCRA regulations, whether intentionally, inadvertently, or fraudulently. Regulated user data may include various regulated user attributes, such as information regarding lines of credit, debt, bankruptcy indicators, judgments, suits, liens, wages, collection items, mortgage loans, other loans, retail accounts, checking/savings/transaction data, late or missed payment data, other credit attributes, and/or derivatives/scores/ratings based on at least the credit information.
Personally identifiable information (also referred to herein as “PII”) includes any information regarding a user that alone may be used to uniquely identify a particular user to third parties. Depending on the embodiment, and on the combination of user data that might be provided to a third party, PII may include first and/or last name, middle name, address, email address, social security number, IP address, passport number, vehicle registration plate number, credit card numbers, date of birth, telephone number for home/work/mobile. User identifiers that are used to identify a user within a particular database, but that are not usable by third parties (e.g., other entities) to uniquely identify the user may not be considered PII. However, in some embodiments even user IDs that would be very difficult to associate with particular users might be considered PII, such as if the IDs are unique to corresponding users. For example, Facebook’s digital IDs of users may be considered PII to Facebook and to third parties.
Data Store: Any computer readable storage medium and/or device (or collection of data storage mediums and/or devices). Examples of data stores include, but are not limited to, optical disks (e.g., CD-ROM, DVD-ROM, etc.), magnetic disks (e.g., hard disks, floppy disks, etc.), memory circuits (e.g., solid state drives, random-access memory (RAM), etc.), and/or the like. Another example of a data store is a hosted storage environment that includes a collection of physical data storage devices that may be remotely accessible and may be rapidly provisioned as needed (commonly referred to as “cloud” storage).
Database: Any data structure (and/or combinations of multiple data structures) for storing and/or organizing data, including, but not limited to, relational databases (e.g., Oracle databases, mySQL databases, etc.), non-relational databases (e.g., NoSQL databases, etc.), in-memory databases, spreadsheets, as comma separated values (CSV) files, eXtendible markup language (XML) files, TeXT (TXT) files, flat files, spreadsheet files, and/or any other widely used or proprietary format for data storage. Databases are typically stored in one or more data stores. Accordingly, each database referred to herein (e.g., in the description herein and/or the figures of the present application) is to be understood as being stored in one or more data stores.
User Input (also referred to herein simply as “input”): Any type of input provided by a user that is intended to be received and/or stored by the system, to cause an update to data that is displayed and/or stored by the system, to cause an update to the way that data is displayed and/or stored by the system, and/or the like. Non-limiting examples of such user inputs include keyboard inputs, mouse inputs, digital pen inputs, voice inputs, finger touch inputs (e.g., via touch sensitive display), gesture inputs (e.g., hand movements, finger movements, arm movements, movements of any other appendage, and/or body movements), and/or the like. Additionally, user inputs to the system may include inputs via tools and/or other objects manipulated by the user. For example, the user may move an object, such as a tool, stylus, or wand, to provide inputs. Further, user inputs may include motion, position, rotation, angle, alignment, orientation, configuration (e.g., fist, hand flat, one finger extended, etc.), and/or the like. For example, user inputs may comprise a position, orientation, and/or motion of a hand and/or a 3D mouse.
Application Programming Interface (API): A set of routines, protocols, and/or tools for building a software application. Generally, an API defines a standardized set of operations, inputs, outputs, and underlying types, such that functionality is accessible via the API in an efficient way. A system provides an API by which a third party may access functionality of the system. Accordingly, the system advantageously abstracts away (from the third party’s perspective), much of the complexity that may be involved in the functionality of the system, and enables the third party to quickly and efficiently leverage functionality of the system to build other systems and services.

Location Based Content Offerings

Ensuring the proper content is presented to the right person at the right time can often mean the difference between getting a message to the person and being ignored in the avalanche of data received by the person. Examples of technologies for identifying the location of an electronic device include global positioning service (GPS), beacon, or access point location (e.g., WiFi presence detection; cellular tower connectivity; etc.). Geofencing allows provisioning of content based on proximity to a location. As a device enters a geofenced area, an information exchange may be performed whereby the device provides location information to the geofencing system and the geofencing system may provide information to the device if the location is associated with a geofenced area. The area may be defined by one or more identified geospatial points. The points may be identified using positioning technologies such as global positioning service (GPS), beacon, or access point location (e.g., WiFi presence detection; cellular tower connectivity; etc.).
GIMBAL™ is a commercially available beacon system that may be user in certain embodiments discussed herein to provide location based content offerings. In other embodiments, other proximity sensors may be used to provide information regarding location of a user (or, more particularly, a user’s mobile device) in relation to a designated area associated with a publication rule. For example, Bluetooth communication may detect a near range proximity of a user device and, accordingly, trigger processing of publication rules for a user of the device. In another example, geolocation information, such as from global positioning system (GPS) sensors of a mobile device, triangulation of data associated with cellular towers accessible by a user device, and/or location information determined based on proximity of the user device to one or more Wi-Fi nodes, may be used to determine location of a user, which may then be compared to a mapping of geofenced areas.
Currently, there are several methods of processing user information in order to determine risk of lending to the user. For example, a pre-screening process may occur in real-time without the user necessarily knowing that their credit is being accessed (without authorizing access to the user’s credit data from one or more credit bureaus), while a pre-qualification process may be performed in response to a user request for information regarding qualification for one or more credit products (and authorizing access to the user’s credit data from one or more credit bureaus). Such pre-screening and pre-qualification processes are generally referred to herein as pre-validation processes or prescreening processes. For instance, an entity may request pre-validation of a specific user for one or more credit products. A credit file for the specific user may be pulled, the credit data assessed based on publication criteria (or factors) and the requesting entity notified if the specific user met the publication criteria. Such pre-validation processes work well for providing offers (e.g., credit card offers) to known individuals. However, in the world of mobile devices and rapid movement of mobile device users, opportunities to provide offers to users via their mobile devices, such as at the time/location where the user really wants to receive a credit offer (e.g., for purchase of an automobile) are limited largely because of the technical difficulties in uniquely identifying (e.g., to the user level) particular users with enough certainty to provide pre-validated offers while the user is still at the desired location.
For example, if a user enters a geofenced area associated with a brick-and-mortar store, a wireless beacon may transmit a message identifying the beacon to the user’s mobile device (or the beacon may be continuously transmitting a broadcast signal requesting responses from devices within the geofenced area). The message may be a probe message alerting the mobile device to the presence of the beacon or an identifier for the beacon that can be used to look up a location and/or content associated therewith. The mobile device may respond to the beacon or another system with a message including the beacon identifier, an identifier of the mobile device, the user, and/or an application executing on the mobile device such as a standalone application or a context based application such as a web-browser or network content viewing application or a native application in the operating system of the device such as a payment application or wallet application. The content provisioning system may in turn identify content to provide to the mobile device. The particular content may be identified (from a collection of a plurality - thousands or millions - of available content items) and customized for the user based on attributes associated with the user that are determined based on the initial communication with a geofencing system or the content provisioning system. The user attributes may include attributes such as information from a mobile carrier (e.g., Verizon, Sprint, AT&T, etc.) regarding the user, information known to the offer provider (e.g., a financial institution that wants to provide credit offers to qualifying users) about the user, and/or information guarding the user that is accessed from one or more third party systems (e.g., credit data of the user that is received from a credit bureau). The content may include content which only prequalified users may receive. For example, a credit providing entity may transmit a credit offer specific to the user. In one embodiment, credit offers may be stored in a data storage medium accessible by the content provisioning system until the user is detected within a geofence. Once the user is detected by the geofencing system, the offer may be quickly transmitted to the user’s mobile device so that the user may, in some embodiments, immediately complete the credit application process and receive credit approval that may be used to complete a purchase at the location of the geofence (e.g., within a retail establishment).
As another example, a credit providing entity may transmit publication criteria indicating requirements for various types of credit that may be available to pre-validated users (e.g., users that meet the publication criteria). The publication criteria may be stored in a data storage medium accessible by the content provisioning system for application to user attributes of a user when the user is detected within an indicated geofence area (such as may also be included in the publication criteria provided by the offer entity). Once the user is detected by the geofencing system, the publication criteria may be re-applied to the user data (e.g., based on a fresh pull of credit data of the user) to determine whether an offer should be transmitted to the user’s mobile device.
As another example, the geofencing system or the content provisioning system may provide a message to the mobile device to invite a specific interaction. For example, the geofencing system may provide a message to cause the mobile device to execute an application on the mobile device. The application may provide a more secure and controlled environment to communicate with the user of the mobile device. The publication criteria may also include timing requirements for provision of offers to users. For example, a user that enters one or more particular geo-fenced areas (e.g., similar retail establishments) for a third time within one week may be provided a content offer (if the user also needs any other publication criteria), whereas the user may not be provided the content offer the first and second times the user entered the particular geofenced areas. As another example, the geofencing system may detect a mobile device circling a specific car in an auto dealership, which triggers transmission of a message to the user’s mobile device to initiate interactions with the user that may result in an offer of credit to the user for purchase of an automobile. For example, the geofencing system or the content provisioning system may provide a message such as “You’d look great in that car. Text 12345 for a top tier credit offer,” to the user device.
The content provisioning system may store content in conjunction with publication criteria. The publication criteria may include time periods when the content may be presented, specific users or groups of users to whom the content can be presented, preconditions for presenting the content (e.g., contact with a different beacon within the geofencing system; specific application on the mobile device; specific mobile device type; etc.), or other conditional logic to afford control over when, where, and to who the content is provided.

Intelligent User Identification

To identify the proper content to present to a user, the particular user should be identified. For example, a content provider may provide publication criteria indicating that users with a credit score of above 750, income level above $80,000, and are currently within a geofence of a particular car dealership and have visited that particular car dealership previously within the last 72 hours, are to be offered an automobile line of credit with certain terms. In one aspect, a predictive system can be included to accept location information for the target and predict the identity of the target. For example, a mobile device of a target may provide geo-location information identifying an address of an office, an address of a school, and an address of a grocery store. A historical record of location information may determine that these three locations are regularly visited by a target and, perhaps, in a specific sequence. The predictive system may identify the locations for the mobile device that correspond to the historical record and thus infer the identity of the target. For example, a reference data store may be included that stores locations for a device and durations of time at respective locations. A pattern of locations may be identified such as extended durations during evening hours at a first location (e.g., home) and extended durations during daytime hours at a second location on weekdays (e.g., work). These two locations may help identify a user of the device who works at the second location and resides at the first location.
As discussed elsewhere herein, the content provisioning system advantageously optimizes communications with user devices that are needed to reach a required authentication confidence level for a user of the user device (e.g., to be able to determine that the user of the device really is who they say they are). For example, the types and/or quantity of PII requested of a user may be reduced by the content provisioning system, when compared to conventional similar authentication requirements for offers of credit. Such optimizations may reduce the communication bandwidth and/or reduce the quantity of communications with the user device, while making the user experience less intrusive, such as by asking for less PII from the user than would normally be required to authenticate the user for a credit application, and also reducing risk of PII exposure to undesirable entities (e.g., hackers that monitor and intercept communications with mobile devices).
In some implementations, an optimized user identification and authentication process may be performed in substantially real-time by the content provisioning system in response to communication with a mobile user device. For example, a user may initially see a billboard encouraging the user to initiate communication with the content provisioning system, such as one that reads “text CARLOAN to 12345 to find out if you qualify for 0% financing of your dream car.” In another embodiment, the user may initially be contacted based on the content provisioning system detecting a mobile device entering a geo-fenced area. In other embodiments, communication between a user and the content provisioning system may be initiated in other ways such as through addressable media. For example, a communication device may be configured to present streaming media content. During streaming of the media content, it may be desirable to present personalized content to the specific communication device and/or user of the communication device. However, the content provisioning system may need to perform some authentication or identification of the user, such as by requesting PII from the user and/or requesting additional information associated with the user or user device from one or more internal or external databases, before the user can be considered for content offers (e.g., credit offers) or before content can be selected for the user.
In one embodiment, authentication of a user is performed by first determining an initial, narrow, set of potential users associated with the detected user device. In such instances, the system may be configured to identify a minimal set of questions to present via the mobile device of a target to accurately confirm the user’s identity. For example, if the location information (e.g., postal code) narrows the potential users to person A and person B, the system may then look for specific differences in attributes of person A and person B, such as may be stored in records for person A and person B (e.g., credit records of the two users). For example, if person A and Person B reside in different states, the system may determine that obtaining the state of residence from the user is sufficient to uniquely identify the user.
The level of authentication, and the corresponding types of user attributes that may be used to authenticate a user, may be based on the content being provided. For example, if the content is informational, security may not be as high of a priority and gender may be used to distinguish person A from person B. As another example, if the content is a credit offer having a predetermined maximum line of credit, more secure identification may be needed to ensure that any credit offers provided are to the intended user. In such situations, a more secure and personally attributable user attribute, e.g., the holder of the user’s mortgage, may be identified as a distinguishing attribute to request from the user.
The intelligent identification of user attribute(s) to request for authentication of a user can be particularly useful in limited resource environments. For example, without the features described, a user may be asked to provide responses to many questions to positively identify the user (before application of credit prequalification rules based on the user’s credit data). Each question requires the user device to expend valuable resources such as power, processing, memory, bandwidth, and the like, to receive, present, and respond to the question. Additionally, the requesting and collection of increased amounts of information may introduce user friction and increase the potential for an error in the requesting or collecting process. In contrast, the systems and methods described herein determine an optimized (e.g., minimal) set of questions that may be used to positively distinguish the actual user of a user device from other possible users of the user device. As discussed, the minimal set may be generated based on the content to be provided and/or a desired level of security.
Thus, one challenge in the mobile environment is to accurately identify an individual user without requiring significant data entry by the user. To accomplish this, an interactive technology that takes first/last name as its primary input may be provided. Analysis of the half billion identities, such as stored in a credit header file, indicates that virtually all identities in the US can be accurately determined by triangulating ZIP code, date of birth, and last four digits of a Social Security number (SSN). Moreover, the vast majority of individuals can be identified based on 1 or 2 of those elements.
The real-time, interactive process may begin by parsing the name to identify user records matching or fuzzy matching the name and establishing a minimum question set required to uniquely identify a user if more than one candidate is identified. The minimum question set may then be presented to the user, such as via a specifically designed and secure application or interactive messaging such as text messaging or interactive voice recognition, to collect user responses. Predicated on the responses, the identity may be verified and specific user information about the identified user may be retrieved using the identity. For example, the user information may be included as criteria to request additional information about the user, such from a 3^rd party aggregator that queries the mobile network user data store in real-time (e.g., at the time of determining the identity).
In an example embodiment, a user initiated text message from a user’s mobile device allows the system to obtain user attributes such as name, address, and/or ZIP code, from a service provider associated with the user device. For example, these user attributes may be automatically retrieved from a service provider, such as a mobile carrier, Internet service provider, social media provider, etc., based on the mobile device number from which the text message was received (e.g., caller ID information) and/or other device identifying information associated with the transmitted text message. Using these limited, but authoritative user attributes, the system may search a database which indexes the credit header file (CHF) of credit files for any users who match by name and zip code (or other combinations of user attributes in other embodiments). For example, if a user texts a specific term to a specified number associated with a content provisioning system, the system can receive the input information shown in Table 1 from the mobile carrier (such as via a data sharing arrangement that the content provisioning entity has with the mobile carrier).

TABLE 1

Data Field	Value
First Name	James
Last Name	McCoy
Billing ZIP Code	92110

In some implementations, the user may initiate the application of publication criteria, including an initial user authentication process, by transmitting a multimedia message (MMS) that includes media such as audio, an image, or video. In the case of audio input, the system may include audio processing (e.g., speech recognition) to convert the audio into text for further processing. In the case of image input, the system may include image processing such as object recognition to recognize an item shown in the image or facial recognition to identify the person shown in the image. When image data includes an item, the item information may be used to drive offers, terms, rewards, or other content relevant to not only the individual who transmitted the image, but to the image itself. For example, if the image includes a car, the system may identify the specific car shown, a license plate shown, or other vehicle identification information (e.g., vehicle identification number (VIN)) and tailor the offer terms based on the specific car and, in some instances, provide additional information about the car such as mileage, condition, location, model year, trim level, accessories, etc. In some implementations, the terms may be based on an existing financing option for the item shown (e.g., an existing mortgage on a home shown in an image, an existing lease or auto loan for a car shown in an image). In the case of video input, the audio and/or images included in the video input may be processed to obtain additional information about the user and/or item or service of interest. The image may include an identifier for the item such as a vehicle identification number, Universal Product Code, text, etc. that can be used as a key to identify additional details about the item.
Media files may include metadata such as time recorded, author, person who recorded the media, location where the media was recorded, and the like. Such metadata may be extracted from an input media element and used to further distinguish the identity of the user and/or the offer, content, reward, etc. they are interested in. Such metadata may be used to determine a device fingerprint, which may then be matched against a database of device fingerprints associated with fraud to predict fraudulent intentions of the user and take appropriate action.
While the implementations discussed thus far rely on SMS or MMS or other messaging, in some implementations, the user may initiate the process by scanning an identifier. For example, if the user is browsing a car dealership, a QR code or other scannable identifier (e.g., barcode, radio frequency identification tag, near field communication tag, beacon, etc.) may be scanned or otherwise detected using the user’s mobile device Upon detection, the mobile device may initiate a software application which thereby transmits information to the content provisioning system for application of publication criteria of one or more offer providers, such as a credit pre-qualification process that initially requires user authentication. For example, when a QR code is scanned by a mobile device, the QR code may include information to initiate the SMS feature of the mobile device. The decoded QR code information may include a “TO” number and a message to send. In some embodiments, the message is automatically sent by the user device to the content provisioning system, while in other embodiments the message may be automatically generated and the user only needs to send the pre-populated message (e.g., my pushing a “send” button on the user device). In implementations including beacons, a beacon signal may enable an automated (e.g., push) type notification to the mobile device. In the case of a beacon, the system may previously know some information about the user of the mobile device by virtue of the presence information (e.g., current location, previous location, duration at a given location, etc.) presented during the interaction between the beacon and the mobile device. In some implementations, the QR code may launch a web browser and direct it to a specific web address. In some implementations, the QR code may activate an application installed on the mobile device. The features described may be applied using SMS, web browser, installed application, operating system function/application, or other initiation mechanisms that allow the mobile device to transmit at least an identifier for a service accessed by the mobile device of a user thereof.
Returning to the example shown in TABLE 1, using these three data fields, the system may query the database of indexed CHFs or other identity information data store to identify a candidate list of individual users matching the already known data attributes, as well as additional attributes about each candidate user. This query may be a “fuzzy” matching, which searches for alternatives of the user information, such as expanded to include fuzzy matches such as misspellings, phonetic variations, typographic variation (e.g., “rom” being a typographic variant for “tom” due to proximity of the letter “r” to “t” on a standard keyboard), stemming, nicknames, or the like. The level of fuzziness of this initial inquiry may be adjusted depending on the implementation. Table 2 shows an example of a response from such a query of the database based on the inputs from Table 1.

TABLE 2

Record #	First Name	Last Name	ZIP Code	Date of Birth	Last	4 SSN
1	Jay	McCoy	92110	Jan. 1, 1980	1111
2	Jimmy	McCoy	92110	Feb. 1, 1968	2222
3	James	McKoy	92110	Oct. 1, 1972	2222
4	Jaime	McCountinosh	92110	11/1/1951	8888

In some implementations, the system may sacrifice specificity in the original query, such as by returning records based on a fuzzy, stem search that matches only a few leading characters from each field (e.g., First Name begins with “J”, Last Name begins with “McC”, ZIP Code begins with 921). Because the quick search does not require detailed analysis of the entire value for a given data field, the results may be obtained faster than if a full analysis were performed, and in those implementations, disambiguation applied to the returned candidate records (such as using the techniques described below) may be used to determine a confidence level in the user’s identity.
In some implementations, the result set returned by the initial query (e.g., the records in Table 2) may be processed by the content provisioning system to determine whether there is a perfect match within the result set. For example, if the result set included another Record # 5 for James McCoy in ZIP code 92110, the system may determine that record five is an exact match to the provided user information and further disambiguation (such as using the techniques described below) are not performed. Rather, with a single perfect match identified, the system may confirm identity of the user and provide the appropriate offer content to the user. In situations where a perfect match is not included in the candidate list or to or more perfect matches are included in the candidate list, further disambiguation may be performed.
The system may then evaluate the candidate list and eliminate candidate users having a probabilistic fuzzy match below a certain threshold. For example, “Jaime McCountinosh” may be eliminated because of the degree of difference between the user attributes received from the mobile carrier and attributes of that particular candidate from the credit header database (and/or other databases in other embodiments). For the remaining candidate users in the candidate list, the system may rank order the candidates based on the similarity to the user attributes from the carrier. In the example provided, there are 2 possible high quality matches in view of the significant match of CHF attributes of the three users with the user attributes from the mobile carrier (e.g., “Jay McCoy” and “Jimmy McCoy”). With this overlap in remaining candidate users, attributes shared by the candidate users may be used to interact with the user in a personalized way. For example, the system may present a greeting to the user such as “Hello, Mr. McCoy” but let the user know that they might need to do some additional validation.
In the above example, record numbers 1 and 2 would be kept because they are seen as high confidence matches with the first and last name provided by the service provider. In implementations where address information (e.g., ZIP code, street address, etc.) is received from an authoritative source (e.g., the mobile service provider), the system may compare the address of any candidate users with and the incoming address information from the service provider. In some embodiments, the address information from the service provider may be compared to one or more historical addresses of the candidate users from the CHF (and/or other data sources) of the candidate users. Similarly, other attributes provided by the mobile carrier may not only be compared to current attributes of the candidate user from other data sources (e.g. CHF), but also to historical attributes of the candidate user’s. The system may be configured to automatically select a single authenticated user if the carrier provided user attributes match only a single user’s CHF data, thereby ending the search.
When more than one possible candidate remains without a perfect match, the system may apply additional profiling to determine which disambiguation questions can be asked to arrive at a single candidate. Assuming the above example has three unique candidates, the system may determine if asking for the date of birth, month of birth, year of birth, or last four SSN or some combination thereof will uniquely identify only one of the three candidates. In the very rare case where the system cannot distinguish between two or more candidates, even with additional PII provided by the user, the process may provide an indication that the identity cannot be confirmed without further authentication procedures. In some embodiments, the further authentication procedures may be initiated at that time by the content provisioning system, such as by directing the user’s mobile device to an out of wallet authentication site, such as may be provided by a credit bureau, to ask the user for information regarding particular credit data items (e.g., balances of particular loans/mortgages, previous residence addresses, etc.). In some embodiments, further processing of publication criteria for offers requiring a higher level of user authentication, e.g., credit offers or insurance quotes, may be terminated when the identity of the user cannot be confirmed. This safeguards the system from making an offer to the wrong person.
The various processes, hardware configurations, and variations of such, for identifying (or verifying an identity of) a specific user may be referred to herein as SmartPIN or Smart Lookup.
In some embodiments, device-level fraud analysis may be integrated into the various user identification processes. For example, in some embodiments, script code (e.g., JavaScript) may be included on a landing page to which the user is directed after initiating an identity validation process (e.g., in response to the user completing a call to action, such as sending a specific text message to a particular telephone number to receive a prequalified offer). The script code may be configured to determine characteristics of the mobile device and/or user based on metadata associated with the URL request, and in some implementations by requesting further identification information from the mobile device without notifications to the user. For example, the script code may determine a “device fingerprint” that can be compared to one or more lists of device fingerprints associated with high risks of fraud. Thus, a likelihood of potential fraud by the particular user device may be determined and used to determine how to further interact with the user (e.g., to close the connection with the user device based on a high likelihood of fraud or continue the communication with the user device).

Comparison / Scoring Process

The ability to uniquely identify a user (from a set of multiple possible users sharing a set of user attributes) based on minimal additional information requests from the user optimizes the user identification process. The determination as to whether a given candidate is a “match” presents a non-trivial problem for computer-implemented systems. To generate a value that can be compared to the threshold for matching, a scoring process may be implemented.
In one example scoring algorithm, a minimum cutoff to qualify for consideration (e.g., to remain on a candidate user list) may be a 0.4 Jaccard index score (scaled from 0 to 1.0). Equation (1) below shows one expression of a Jaccard index for the similarity between two data sets A and B.
$Equation (1)$
The system may use a bi-character Jaccard index for the fuzzy matching algorithm. This minimum cutoff is selected to be loose enough to allow for possible name variations. The system may implement further constraints to ensure validity. A nickname table may be included to enhance the candidate list and prevent the system from missing common name variations. The candidate list may be processed for relevant matches to the original input (e.g., from the service provider) as well as nicknames.
Whether the input information to the process is received from a service provider by the user, the system may look for candidate records that have at least a Jaccard score of 0.4 or higher. If more than one candidate has a Jaccard score greater than or equal to 0.7, the system may initiate a disambiguation process. The disambiguation process may be skipped if a perfect match for the name is identified based on the Jaccard score and the candidate record has a perfect match to the provided address information.
If the system has more than one candidate remaining and/or lacks the address information confirmation, the disambiguation process begins. In one implementation, the disambiguation may first parse the list of date of births from the remaining candidates and determine if each candidate in the list has a unique birthdate. If every remaining candidate has a unique date of birth (DOB), the system can ask the user for date of birth and, based on this information, one match can be identified. For the candidates shown in Table 2, DOB will provide a unique identification for any one of the candidates. If the DOB received by the system is not one of the candidate DOBs, the system may provide an indication that the identity cannot be confirmed and further processing terminated. The system also may also determine that other candidate information (e.g., Last 4 SSN) is not unique. In such instances, the system would not prompt the user to provide this information.
The system may include two or more paths to the identification. For example, the identification inputs may be provided automatically via the service provider or directly from the user. The system may include features to prevent displaying any information that the user did not provide. For example, the system may require a candidate have at least 0.9 or higher Jaccard score before displaying a candidate’s information simply because it matches to the input name provided by the service provider. Table 3 shows some examples of the Jaccard score for various candidate comparisons.

TABLE 3

Candidate 1	Candidate 2	Jaccard score
“James Mcoy”	“James McCoy”	0.7273
“John Smith”	“Jonh Smith”	0.5
“John Smith”	“Johhn Smith”	0.9
“Bob Grey”	“Bob Gery”	0.4

Thus, even for a comparison having a 0.4 Jaccard score, the names may be visibly very similar. Thus, the disambiguation process may increase the clarity on distinguishing between facially related candidate by collecting information using follow-up questions that identify one and only one candidate. The system may be configured to prevent further activity until the user provides all the correct information that is required to positively identify the user.

Additional Analysis

Based on automated and manual analysis of research data, user authentication based on only credit header file data may be able to get 96% unique identifications from the full name and zip code (such as may be provided by the mobile carrier through which the user sends an initial text message to initiate a prequalification process). Further, if the system also considers the date of birth and/or last four SSN, a unique identification can be identified more than 99.8% of the time. For the remaining 0.2% of the time or if the user is a no-hit (e.g., not found in the data stores accessible by the system), the system may simply default by not making any offer and terminating any further processing (e.g., decline to provide an offer, content, or other good/service).
While the discussion has highlighted the features for identifying and providing authenticated user information based on a limited set of inputs in the context of credit offers, the identification process may be applicable in other fields. For example, when selling a home or other object, it is typical for the seller to place a sign advertising the availability of the item. This sign may include an active (e.g., user prompt; QR code; barcode) or passive (e.g., beacon, RFID, NFC) indicator. This indicator may cause a mobile device associated with a user interested in the item to send a text message or other initiation message to start the identification process. For example, a location indicator may detect presence of a user near a house that is for sale and initiate communications with the user regarding the house. In this example, the user may not provide any proactive request for the information, but rather the information is provided based on the user’s proximity to the house for sale. In some embodiments, other criteria may be assessed before initiating communication with the user, such as the user’s predicted interest in purchasing a house. In another example, the location indicator may detect presence of the user near the house that is for sale and directly communicate to the user device (e.g. via Bluetooth communication) information on how the user can initiate a prequalification process and/or receive further information on the house (and/or related houses for sale or other similar real estate information), such as by providing a short code that can be selected by the user to send a text message to the content provisioning system 150. Thus, message content provided to the user may be associated with the specific item (e.g., the particular house for sale) such that the location and specific terms for the process (e.g., mortgage lending, credit lending, insurance rating, etc.) may be identified not just for the user but also for the specific item of interest.

Example Implementations and Architectural Features

FIG. 1 is a block diagram showing an example environment for providing personalized content to a mobile device. As discussed, the resources available to a mobile device 102 may be limited. The limitations may be physical, such as display size or input means for providing information. These limitations can present a barrier to viewing or otherwise interacting with content presented via the mobile device 102. The limitation may be a computing resource such as power, processing speed, network bandwidth, network connectivity, or the like. It may be desirable to conserve these resources to ensure longer operational time for the mobile device 102. Each message transmitted or received requires resources to process. Accordingly, the ability to accurately identify a user of the mobile device 102 in a way that limits the number of resources can improve the overall speed at which the user can be identified but also improve the resource utilization for the mobile device 102 during the identification or content provisioning process.
In the embodiment of FIG. 1 , the mobile device 102 is shown as a smart phone. The mobile device 102 may be implemented as a tablet computer, a wearable device (e.g., smartwatch, smart glasses), or other communications device configured to transmit and receive messages. The mobile device 102 may include one or more transceivers (not shown) to transmit and receive such messages. The messages may be transmitted to or receive from one or more communication systems 110 such as a satellite 112, an access point 114 (e.g., cellular access point), or a wide area network router 116 (e.g., WI-FI®). Other examples of communication systems 110 include BLUETOOTH® systems, ZIGBEE™ systems, Z-WAVE® systems, GIMBAL™ systems, near field communication systems, or other wired or wireless systems. The communications may provide data communication path to a network 120 such as the Internet, cellular networks, or combinations of networks. The communications may provide services such as location services. For example, a beacon may transmit location information that can be received by the mobile device 102 and used to identify a location of the mobile device 102. The geofencing information may include an identifier of the beacon which can then be used to look up a location associated with the beacon. In some implementations, the location services may include a global positioning service (GPS). The GPS signals provide a way for the mobile device 102 to identify its current location. Location may also or alternatively be determined based on the access point 114 location or address information (e.g., IP address) of the wide area network router 116.
A personalized content provisioning system 150 may be included in the environment 100. The personalized content provisioning system 150 may include an identity confirmation device 155, a publication manager 160, and a content generator 170. The identity confirmation device 155 may be included to authenticate the identity of a user, such as using the various systems and methods discussed herein. In some implementations, authentication of a user may be referred to as Smart Lookup. The identity may be based on information provided by the mobile device 102 or an application executing thereon. For example, the mobile device 102 may include a device identifier in messages transmitted to the personalized content provisioning system 150. Examples of a device identifier include an IP address, a telephone number, a tax identifier, a media access control (MAC) address, and a mobile equipment identifier (MEID). The information may be configuration information for the mobile device 102 such as home address, username, account number, or the like. In some implementations, a software application such as an offer identification application, may be installed on the mobile device 102 and used to interact with the content provisioning system to identify any offers for the user. The offer identification application, such as an application provided by a credit bureau or other entity that has access to regulated data of users, may receive user input values through a user interface such as name, mailing address, email address, birthdate, etc. One or more of the user input values may be included in the information transmitted to the personalized content provisioning system 150.
In some implementations, the information provided to the identity confirmation device 155 may not be sufficient to uniquely identify a user of the mobile device 102. In such instances, the identity confirmation device 155 may be further configured to cause presentation of a user interface to collect one or more additional elements of information to identify the user as described herein.
The publication manager 160 may be configured to receive content and publication criteria that must be met for the content to be provided to a user. The content may include offer content or instructional content. The content may be associated with location criteria such that the content can be published to users at or associated with a specified location. In some implementations, the content may be associated with user behavior. The behavior may include historical locations, time between visits to one or more locations, mobile device behavior (e.g., logging into an application, executing a feature of an application), interactions with the personalized content provisioning system 150, messages (e.g., text messages) received (e.g., specific message content or specific message destination), or the like. The content and criteria may be stored in a publication information data store 184.
The content generator 170 may be assessing the publication criteria received by the publication manager to determine, for specific behavior or requests, whether and when to respond to the mobile device 102. A user request processor 172 may be included to process user initiated requests for content. For example, a user may activate a control element on an application executing via his mobile device. The control element may transmit a request to view current content offerings.
In some implementations, the content generator 170 may include identified information for a user to prefill content such as a form or other interactive interface. An identity data types may be mapped to specific fields and, if available for an identified user, included in the content. The prefilled content may be provided for display or printing such as via a kiosk. In some implementations, the prefill may be performed without presentation to the user. For example, consider an implementation where the user transmits a text message including “more info” to a predetermined destination. The user may be identified using information from the mobile carrier and, based on the identification information, additional user information such as address, gender, or the like may be received. This additional user information may be used to transmit a request to produce a physical mail item including the additional information. In this example, the user did not need to provide address or other information to complete the request. The additional user information may be provided via a machine interface such as an application programming interface configured to receive a device identifier or a limited set of user values (e.g., name and postal code) and return a set of additional user information if a user can be identified. The set of information may be accompanied by a confidence score indicating the likelihood that a given set of information is associated with input the user information. In some embodiments, third parties (e.g., entities that require consumers to provide PII to determine eligibility or enroll in a service) may leverage the prefill technology using an API that facilities direct communication with the content generator 170, such as to verify identity of a user based on a minimal set of user information (as discussed thoroughly herein) and then provide back more extensive user PII once the user’s identity is verified (such as from the identity information database 188 and/or other internal or external databases of user information).
In some implementations, the content may include an authorization token such as an optical scancode (e.g., barcode, QR code). For example, if the user is identified and authorized for a specific line of credit, the mobile device may display an interface including the optical scancode to complete a transaction at a point of sale against the line of credit.
A behavior detector 174 may be included to generate and transmit content based on user behavior. In some implementations, this may be referred to as a content “push.” The behavior detector 174 may receive behavior information associated with the mobile device 102. The information may be received from the mobile device 102 (e.g., included in a message transmitted from the mobile device 102 to the personalized content provisioning system 150. The information may be received from a service provider such as an application service provider or communication service provider (e.g., satellite, cellular, internet service provider). The behavior information may be stored in a user history data store 182.
The behavior detector 174 may monitor the user history data store 182 for user records that include behaviors associated with content. Once a behavior condition is met, the behavior detector 174 may initiate generation of content for the mobile device 102 associated with the behavior.
Whether in response to a user request or a detected behavior, generating content may include identifying the user of the mobile device 102. The identification may be performed using the identity confirmation device 155. Generating the content may include customizing the content to include specific values for the user in the content. For example, it may be desirable to insert the user’s first and last name to personalize the message. The personal information may be retrieved from an identity information data store 188. The identity information data store 188 may be queried using at least a portion of the user information associated with a request for personalized content. One example of an identity information data store is a credit header database (and/or other databases in other embodiments). In some implementations, content may include variable features such as a prequalified line of credit. This value may be generated for the specific user based on their personal information.
For tracking purposes, it may be desirable, as part of generating the content, to maintain a record of the content provided. A content history data store 186 may be included to store an identifier for a personalized content item provided to the mobile device 102 and/or the authenticated user to which the content item was targeted. The content history data store 186 may include an identifier of the mobile device 102 and an expiration date for the content. In some implementations, one or more custom values generated for the content may be stored in association with the identifier for the personalized content item (e.g., prequalified line of credit, contact information of agent included for accepting or inquiring about the content, etc.).
An ID-device binding data store 180 may also be included in the environment 100. The binding data may store an association of device identifiers and an identifier for a specific user. In some implementations, the identifier for a specific user may be a personal identifier that uniquely identifies the user within the environment 100 or at least in the context of the personalized content provisioning system 150.

Example Implementations and Architectural Features — Behavior Provisioning

FIG. 2 is a flow diagram showing an example method of behavior initiated content provisioning. The method 200 may be implemented in whole or in part by the personalized content provisioning system 150. The method 200 illustrates an example method in which user behavior, such as location behavior, can be used to provide personalized content to a user. Consider the case where a user visits a car dealership on Monday. The system may detect a mobile device associated with the user at the dealership. Later in the week, the same user is detected at the dealership (or a related dealership). Based on an interaction with a sensor at the dealership or entering a geofenced area, which may or may not require any affirmative input from the user (as discussed in the various embodiments herein), an alert may be transmitted to the mobile device indicating that the user is prequalified for a loan to purchase a car at the dealership. Depending on the embodiment, the method of FIG. 2 may include fewer or additional blocks and the blocks may be performed in an order that is different than illustrated.
At block 202, a location of a device associated with a user may be detected such as by a presence system or a behavior detector. The detection may be based on information transmitted from the device. For example, a presence detection system may be implemented to identify where a mobile device is located, when it arrived at the location, and, in some implementations, how long it was at the location. The identification may be based on transmitting a beacon identifier from the mobile device to the presence detection system. In some implementations, the information may be transmitted by a service accessed by the device such as accessing the WI-FI® network at a location.
At block 204, the personalized content provisioning system 150 may determine whether the location of the device is associated with content. The determination may include querying a publication information data store for content associated with the location. In some implementations, the association may be based on an area. For example, a content element may be associated with an entire city block. If the location of the device is within that city block, then the location may be deemed associated with the area. In some implementations, a threshold distance may be associated with an area. Thus, if the device location is determined to be within the threshold distance of a geographic area, the device location may be deemed associated with the area.
If the determination at block 204 is negative, the method 200 may return to block 202 to detect another location for the device. If the determination at block 204 is affirmative, then content may be associated with the location. At block 206, the personalized content provisioning system 150 may receive a publication rule for the content associated with the location. The publication rule may identify user attributes required for delivery of the content to the user. For example, the publication criteria may indicate that the user has visited a particular location two or more times in one week.
At block 208, the personalized content provisioning system 150 applies the remaining publication criteria (e.g., pre-validation criteria for a credit card offer) to user attributes (e.g., from third party data sources and/or directly Received from the user device) to determine if content (e.g., a credit card offer) should be provided to the user. The determination may include retrieving behavior data from a user history data store.
If the determination at block 208 is negative (the user attributes identified by the system did not meet the publication criteria), the method 200 may return to block 202 and continue as described above. If the determination at block 208 is affirmative and the behavior meets a publication criterion, the method 200 may continue to block 210. At block 210, information about the user associated with the device may be received by the personalized content provisioning system 150. Receiving the information may include retrieving user information from the user history data store. Receiving information may include receiving information from the device or application executing thereon. In some implementations, it may be desirable to obtain consent of the user before requesting and receiving personal information. For example, information may be received from a service provider that provides a service to the user or the device. Before requesting such information, the user may be prompted such as via a graphical user interface to consent to data gathering. A response confirming the consent may be received to permit requesting and receipt of this information.
At block 212, a message including the content for the user may be generated by the personalized content provisioning system 150. Generating the content may include generating one or more values to include within the content. For example, a maximum line of credit may be identified based on the user information or a metric therefor. For example, the metric may be a score based on prior transactions. The score may indicate how reliable the user performed one or more prior transactions. In some implementations, the metric may be used to select a version of content for a user associated with the metric or other user data. For example, if the user is associated with a mailing address in California, a version of the content tailored to California residents may be selected. The content generation may include generating an identifier that uniquely identifies the personalized content provided to the user. For example, it may be desirable to maintain a record of the terms or conditions included in the content. The content may be associated with an expiration date. The expiration data may be selected based on the current date, a date when the offer was first presented, a promotion end date, or a combination thereof.
At block 214, the personalized content provisioning system 150 may transmit the message to the device. The message including the personalized content may be transmitted via wired, wireless, or hybrid wired and wireless means such as via one or more of the communication systems 110 and/or the network 120 shown in FIG. 1 . The message may cause the device to activate and/or initiate an application that is configured to present the content.
For example, in certain implementations, an alert indicating a product offer to a user may be automatically transmitted to the mobile device 102 in response to determining that personalized content should be provide to the user (e.g., in block 214), such as in real-time as the user is at the location triggering the content analysis (e.g., at block 204). Such alert communications may be automatically transmitted to the user in one or more modes of communication, such as, for example, direct to a mobile application, electronic mail, text messaging (e.g., SMS, MMS, or other), to name a few. In certain modes of communication, the communication may be configured to automatically operate on the user’s electronic device. For example, upon receipt of an alert, a software application installed on the user’s mobile device may be automatically activated to deliver the communication to the user (e.g., a SMS viewer or application may automatically display information from the alert communication when received by the device or when the device is connected to the internet). Alternatively, the alert communication may activate a web browser and access a web site to present the alert communication to the entity. In another example, a communication may be transmitted to the user’s email account and, when received, automatically cause the user’s device, such as a computer, tablet, or the like, to display the transmitted communication or a link to take the entity to a webpage with additional information regarding the selected publication content (e.g., product or service offer).
FIG. 2 describes a method of providing personalized content based on detected behaviors. In some implementations, it may be desirable to provide personalized content on demand such as in response to a user request.

Example Implementations and Architectural Features — Requested Provisioning

FIG. 3 is a flow diagram showing an example method of user requested content provisioning. The method 300 may be implemented in whole or in part by the personalized content provisioning system 150. The method 300 illustrates an example method wherein a user can request that information regarding the user be obtained and a determination of eligibility for content be performed. Consider the case where a user visits a car dealership while walking home. The dealership may include a sign saying “Text ‘credit’ to 333333 to drive home today.” In such implementations, the act of submitting a text message with a specific keyword (e.g., credit) can be sufficient to identify the user and determine that the user is qualified to receive particular content, such as a credit prequalification offer that is tailored to the user. Depending on the embodiment, the method of FIG. 3 may include fewer or additional blocks and the blocks may be performed in an order that is different than illustrated.
At block 302, a message requesting offer content may be received from a user device. The message may be received in response to a location alert (e.g., behavior based), such as a message sent to the user device as the user walks into the car dealership and requests a reply back from the user. The message may be received without direct solicitation via the user device such as by a user seeing a sign or hearing a radio advertisement, creating the message, and transmitting the message. In some implementations, the message may be generated via an application executing on the user device. For example, a bank may provide its users a custom application. The custom application may include a user interface element that, when activated, causes transmission of a message to the content provisioning system requesting identification of current credit offers for the use. It will be appreciated that the example method in FIG. 3 discusses credit offers, but the method 300 may be applicable for requesting and providing other types of personal content such as educational content, informational content, bank cards, mortgages, job applications, government forms, auto loans, retail loans, loyalty programs, pre-fillable content, timeshare or other eligibility based content, comparison service, or the like.
The message may include a keyword such as “credit.” In some implementations, the message may include an image such as an image of a car the user is thinking about purchasing. The message may be transmitted along with information about the user and/or the user device such as a device identifier, phone number, sender email address, IP address of the device, current location of the user device, or other identifying information for the user and/or user device.
At block 304, the personalized content provisioning system 150 may determine that the message received at block 302 is associated with content. The determination may include querying a publication information data store for content associated with the location of the user device or other attribute included in the request. For example, where the request includes a text message, the determination at block 304 may include identifying content associated with the destination number and specific message included. For example, a car dealership may be associated with a particular message destination code (e.g., a phone number or other short message code). The same dealership may have different promotions or content that can be served. In such implementations, each campaign may be associated with a different keyword. In some implementations, the code may be associated with date information indicating when the code is “active” for providing content. Table 1 below provides one example of how codes may be associated with different content (e.g., different campaigns, different credit levels (e.g., standard versus preferred), or different user types (e.g., individual versus business)).

TABLE 1

Destination Number	Code	Content Identifier	Description
444444	“credit”	prequal-2017	2017 user credit prequalification campaign (standard)
444444	“accord rebate”	accreb-39275	Mfg. Accord rebate program 39275
444444	“fleet fi”	b2b-prequal-2017	2017 business credit prequalification campaign
888888	“credit”	prequal-2017	2017 user credit prequalification campaign (preferred)

If the determination at block 304 is negative, the method 300 may return to block 302 to receive another message from the user device. In the negative case, it may be that the destination number and/or code received at block 302 are no longer valid or are not yet active. If the determination at block 304 is affirmative, then content may be available for the user.
At block 306, information about the user associated with the device may be received by the personalized content provisioning system 150. Receiving the information may include retrieving user information from the user history data store. Receiving information may include receiving information from the device or application executing thereon. In some implementations, it may be desirable to obtain consent of the user before requesting and receiving personal information. For example, information may be received from a service provider that provides a service to the user or the device. Before requesting such information, the user may be prompted such as via a graphical user interface to consent to data gathering. A response confirming the consent may be received to permit requesting and receipt of this information.
At block 308, the personalized content provisioning system 150 may receive a publication rule for the available content. The publication rule may identify a user behavior to provide the content. For example, the user behavior may include visiting the location two or more times in one week. The publication rule may include consideration of user information. For example, demographic information (e.g., mailing address, age, gender, etc.) may be used to determine whether content is available for the user.
If the determination at block 308 is negative, the method 300 may return to block 302 and continue as described above. If the determination at block 308 is affirmative and the user information or behavior meets a publication criterion, the method 300 may continue to block 310.
At block 310, a message including the content for the user may be generated by the personalized content provisioning system 150. Generating the content may include generating one or more values to include within the content. For example, a maximum line of credit may be identified based on the user information or a metric therefor. For example, the metric may be a score based on prior transactions. The score may indicate how reliable the user performed one or more prior transactions. In some implementations, the metric may be used to select a version of content for a user associated with the metric or other user data. For example, if the user is associated with a mailing address in California, a version of the content tailored to California residents may be selected. The content generation may include generating an identifier that uniquely identifies the personalized content provided to the user. For example, it may be desirable to maintain a record of the terms or conditions included in the content. The content may be associated with an expiration date. The expiration data may be selected based on the current date, a date when the offer was first presented, a promotion end date, or a combination thereof.
At block 312, the personalized content provisioning system 150 may generate a message including offer content for the user and then at block 314 transmit the message to the device. The message including the personalized content may be transmitted via wired, wireless, or hybrid wired and wireless means such as via one or more of the communication systems 110 and/or the network 120 shown in FIG. 1 . The message may cause the device to activate and/or initiate an application that is configured to present the content.

Example Implementations and Architectural Features — Intelligent Identification

FIG. 4 is a flow diagram showing an example method of identifying a user. Some implementations, such as the methods shown in FIGS. 2 and 3 , may include uniquely identifying a user based on limited information. FIG. 4 provides one way to efficiently identify a user of a device. Depending on the embodiment, the method of FIG. 4 may include fewer or additional blocks and the blocks may be performed in an order that is different than illustrated.
The method 400 may begin at block 402 by receiving, e.g., at the identity confirmation device 155 of the content provisioning system 150 (FIG. 1 ), first information identifying a user of a device from a service accessed by the device. For example, the first information may be user input to an application executing on the device. As another example, the first information may be a phone number or device identifier assigned by a service provider (e.g., mobile network operator) to the device, or even user information associated with the phone number provided by the service provider. If the first information is a phone number, a reverse lookup may be performed to identity user data associated with the phone number. The user data may include first name, last name, and mailing address information such as a ZIP code. In some implementations, the user data may include historical user data such as previous addresses or names (e.g., due to a change in marital or adoption status).
At block 404, the system may query a user data source using at least a portion of the first information. For example, a credit data base including header files associated with different users may be queried using the first name, last name, and ZIP code identified by the first information.
A set of user data for different users corresponding to the first information may be received at block 405. As discussed above, some users may have the same first name or last name. Such user records may correspond to the first information. In some implementations, the correspondence may be based on fuzzy logic or phonetic matching. Similarity may also be based on current user information or historical user information (e.g., prior address, name, etc.). Because there may be discrepancies between the received first information and the specific users identified from the user data source, the method 400 may further process the received records to identify a record for a unique user included in the set of users. In some embodiments, if a “perfect match” is included in the candidate identity records returned from the query at block 404, the system may forgo the remainder of the matching process by identifying that user as the authenticated user. In some embodiments, this short-circuiting of the matching process may only be performed if a single perfect match exists in the returned candidate identity records, where a perfect match may be defined as exact matching of all user provided data (e.g., exact match of first name, last name, ZIP code provided by the user), or in some embodiments could include variants of certain identity data (e.g., a perfect match could be identified for a candidate record for “Joe Jones” in response to the user providing the name of “Joseph Jones”), or as defined by the offer provider (e.g., based on the needed level of identity verification).
At block 406, the system may generate a similarity metric identifying, for each of the candidate users, how closely the user data for a respective candidate user matches the first information. One example of a similarity metric is a Jaccard score. The degree of relatedness may be used to identify whether any candidate users may be identified as the user and to what level of confidence. In cases where historical information for a user is included, a weight may be applied to discount values occurring further from the current time. For example, if a user moved in the last six months, the prior address may be considered with a higher weight than a previous address for a person who moved thirteen years ago. The weighting may be dynamically specified for each data type (e.g., a first weight may be applied for names while a second weight may be used for ZIP code). The weighting applied for a data type may be identified in a configuration accessible by the system.
At block 408, the system may determine whether at least one of the candidate users is associated with a metric that meets or exceeds a matching threshold. For example, it may be desirable to identify a “match” only when the Jaccard score exceeds a minimum threshold, such as to ensure that credit offers provided to a user are based on that same user’s unique credit data that qualifies the user for the credit offers. This may ensure a minimal degree of relatedness. If the determination at block 408 is negative, the user data store may not include records with sufficient level of relatedness to identify the user. In such instances, the method 400 may proceed to block 430 to identify a default user. Identifying a default user may include collecting generic user information that can be presented to any user. For example, in the context of credit offers, the user may be provided with generic invitations to apply for credit, rather than being provided with an offer of credit that may be provided only to qualifying authenticated users. This may include identifying no user information and providing a request to provide a more robust set of information than provided via the first information.
While the default user is a helpful fail-safe, it is envisioned that the determination at block 410 will match at least one user. Based on experiments, it has been determined that many users may be uniquely identified on the basis of first name, last name, and ZIP code. Accordingly, the default identification at block 410 may apply to a small percentage of the users submitted for identification.
In the case where at least one user is identified at block 410, the method 400 may continue to block 412 to determine whether only one user exceeds the threshold. The determination at block 412 may be affirmative when only one user is identified with a similarity metric above the matching threshold. In such cases, the method 400 may proceed to block 440 to positively identify the user as the candidate user associated with the metric. The positive identification may include providing additional information about the user retrieved from the user data source. One example of such additional information may include user information for processing credit inquiries.
Returning to block 412, if more than one candidate user is associated with a metric that exceeds the threshold, it may be that a unique user cannot be associated with the first information. In such instances, the method 400 may compare the remaining candidate users’ information to identify a data type or field (e.g., first name, date of birth, last four of the Social Security Number, previous street address, etc.) that may be used to distinguish all candidate users. For example, consider the three example candidate user records shown in Table 4 below.

TABLE 4

Candidate No.	First Name	ZIP code	Street	House No.
1	Pat	92212	Main St.	146
2	Pat	92212	Garden St.	735
3	Pat	93102	Lincoln Blvd.	33982

In Table 4, the example candidates have the same first name, so the data type or field associated with first name cannot distinguish the candidate users. Similarly, the data type or field associated with ZIP code cannot distinguish all of the candidate users as two the three candidates are associated with the same ZIP code. The street address information can distinguish the candidate users as each user can be uniquely identified based on the house number. Accordingly, the data type or field associated with house number may be identified for the example shown in Table 4.
At block 414, the system may transmit a request to the user device requesting a value for the data type or field identified at block 412. It will be appreciated that the method 400 requires only this single value for distinguishing the candidate users. This ensures a limited collection and exchange of information between the system and the device to attain a unique identification. The request transmitted at block 414 may cause the display of a data collection user interface to receive and transmit a value for the requested data type or field to the system.
At block 416, the value may be received from the user device. The value may be compared to the candidate user values to ensure the received value is in fact associated with one of the candidate users. In the case where the received value is not associated with any of the candidate users, the method 400 may proceed to block 440 as described. However, it is expected that the received value will match one of the candidate users thereby providing a unique identification of the user.
Once the user is uniquely identified, user information for the user may be provided for additional processing. For example, as discussed, personalized content may be provided based on the identity of a user. In some implementations, such personalization may require specific user information to identify or generate the content. One specific example is a prequalified credit offer. In some implementations, a model may be included. The model may accept a set of input values representing specific user information such as age, income, credit score, etc. These values may only be provided if the user is uniquely identified such as via the method 400. Generating the content may include generating one or more values to include within the content. For example, a maximum line of credit may be identified based on the user information or a metric therefor. For example, the metric may be a score based on prior transactions. The score may indicate how reliable the user performed one or more prior transactions. In some implementations, the metric may be used to select a version of content for a user associated with the metric or other user data. For example, if the user is associated with a mailing address in California, a version of the content tailored to California residents may be selected. The content generation may include generating an identifier that uniquely identifies the personalized content provided to the user. For example, it may be desirable to maintain a record of the terms or conditions included in the content. The content may be associated with an expiration date. The expiration data may be selected based on the current date, a date when the offer was first presented, a promotion end date, or a combination thereof.
FIG. 5 is a messaging diagram showing example communications for providing personalized content to a mobile device. FIG. 5 shows messages exchanged between a user device 502, a short code provider 506, a decisioning service 508, and a service operator 510 (e.g., mobile carrier, internet service provider, application service provider, etc.). The messages in FIG. 5 are shown as being exchanged directly between entities. It will be appreciated that intermediaries such as security devices, routers, gateways, network switches, and the like may be included. These intermediaries have been omitted to focus the reader on certain features of providing personalized content. Additionally, in some embodiments functionality of two or more devices illustrated in FIG. 5 may be performed by a single entity and/or single device.
A user of the user device 502 may receive a call to action. For example, the user device 502 may transmit a message including device information, such as a location of the user device 502 or a signal detected by the user device 502 such as a beacon identifier. In response, the user device 502 may receive a message including a short code. The message may be a text message indicating that the short code may be used to request personalized content. The message may include instructions to adjust a graphical user interface of the user device 502 to display the short code for requesting personalized content. In some implementations, the message may include a URL that directs the user to a web portal (e.g., by launching a browser on the user’s mobile device) to provide further identity verification information and/or perform other actions to prequalify for an offer. In some embodiments, the content provisioning system 150 includes a URL shortening logic that generates short URLs (e.g., <20 characters) that are redirected to the corresponding full URL (e.g., 80+ characters). Longer URLs may not work on certain mobile devices (e.g., may result in an error code on the user device) and/or are not user-friendly (e.g., may fill the entire mobile device display with irrelevant information to the user). Thus, providing of shortened URLs by shortening logic at the content provisioning system may reduce the occurrence of technological challenges and/or errors in interacting with users. The URL shortening logic may include code, e.g., python code that generates the shortened URLs and stores them in association with the full URL on a web services server (e.g., Amazon’s web services or AWS). In some embodiments, an external URL shortening service may be called to provide shortened URLs that may then be included in message content by the content provisioning system 150.
The user of the user device 502 may decide to request the content offered by activating a control element on the user device 502 to transmit a short code message 524 to the short code provider 506. In some implementations, the short code message 524 may be manually input by the user such as based on information collected from a sign or other promotional material. The short code provider 506 may translate the short code received in the short code message 524 to identify a process or service to respond to the request. The short code message 524 may include information identifying the user device 502 such as a phone number, mobile equipment identifier, username, or account number. This identifying information may be transmitted in a message 526 to the decisioning service 508. The decisioning service 508 may implement the personalized content selection and generation features described such as in FIGS. 2, 3, or 4 .
The decisioning service 508 may request consent from the user of the user device 502 to retrieve additional information about the user such as performing a reverse lookup for personal information about the user based on the device identifier. In such implementations, a consent request message 528 may be transmitted to the user device 502. The consent request message 528 may include a link that can be activated via the user device 502 to provide consent and continue the process. The link may include a token or other temporary credential to associate the consent with a particular session. In some implementations, the consent request message 528 may request return of a password, personal access number, or other verification information.
As shown in FIG. 5 , the consent may be provided in the form of a short code message 530. The message 530 is received by the short code provider 506 and provided in turn to the decisioning service 508 via message 532. The message 532 may include consent information such as a password or token along with the device identifier. The decisioning service 508 may then associate the consent with a particular device and thus set of personal information. The decisioning service 508 may transmit a message 534 to the service provider 510 to retrieve additional user information for the user associated with the user device 502. For example, the service provider 510 may be a cellular service provider for the user device 502. Using a phone number, additional information about the user account associated with the phone number may be retrieved via message 536. The user data collected, or a portion thereof, may be transmitted via message 538 to the decisioning service 508. In some implementations, the service provider 510 may be an application service provider, credit service provider, merchant, retailer, government, or other entity to whom users have identified themselves. In some implementations, more than one service provider 510 may be included and queried for user information. The user information received from respective providers may be different or may be the same, in which case, a comparison may be performed between values for a given data field to generate a confidence in the identification result.
In some implementations, the service provider 510 may be a social media or other online media provider. For example, the content provisioning system 150 may request user PII from a social media server in response to the user indicating a desire to be prequalified for a particular offer (e.g., for an auto loan). Similar to embodiments discussed herein where a wireless service provider (e.g., Verizon, AT&T, Sprint, etc.) provide initial user identification information (e.g., name and ZIP Code), a social media server may provide similar and/or additional information regarding users that may then be used in a user verification process and determination of eligibility for the particular offer.
In some embodiments, a call to action may be presented via a social media service such as via a textual or image post. An interaction with the call to action (e.g., click, like, download, display, button press) may cause initiation of one or more of the identification and content provisioning features described. For example, a user may see content on their social media feed (on a mobile, portable, or desktop device) regarding prequalification for credit (which may be provided to the user based on analysis of the user’s profile and recent posts that indicate the user is searching for a new car, house, etc.) that, when selected, initiates any of the identity verification processes discussed herein.
At this point, the decisioning service 508 has at least two sources of information to help identify the user of the user device 502 namely the information provided by the user device 502 during the communication session and the information provided by the service provider 510. Via messaging 540, the decisioning service 508 may identify the user based on the collected information. In some instances, the identification may include querying an additional user data source such as credit header files or other personal information data stores. In some instances, the collected data may not be sufficient to uniquely identify a specific user. In such instances, messaging 542 may be included to request and receive additional identity data to distinguish amongst multiple candidate users, such as discussed with reference to Table 4 above.
Once the user of the user device 520 is uniquely identified, via message 544, the personalized content may be generated. Generating the content may include generating one or more values to include within the content. For example, a maximum line of credit may be identified based on the user information or a metric therefor. For example, the metric may be a score based on prior transactions. The score may indicate how reliable the user performed one or more prior transactions. In some implementations, the metric may be used to select a version of content for a user associated with the metric or other user data. For example, if the user is associated with a mailing address in California, a version of the content tailored to California residents may be selected. The content generation may include generating an identifier that uniquely identifies the personalized content provided to the user. For example, it may be desirable to maintain a record of the terms or conditions included in the content. The content may be associated with an expiration date. The expiration data may be selected based on the current date, a date when the offer was first presented, a promotion end date, or a combination thereof. Having identified and generated the personalize content, the decisioning service 508 may transmit a message 548 including the content or information that the user device 502 may use to access the content such as a network location (e.g., URL) of the content.
FIG. 6A is a pictorial diagram showing user interface transitions for requesting and receiving personalized content on a mobile device. A welcome interface 602 provides a welcome message. The welcome message may be generated by an application executing on the user device, such as one provided by a bank, a car dealership, a car manufacturer, or an online retailer or a general purpose application such as a web-browser, dynamic media streaming application, or other network content viewing application. The welcome interface 602 may include personalized content such as the user’s name “PAT SMITH.” The welcome interface 602 includes a textual control element (“Not me?”) that, when activated, may cause the user interface to collect user information for a different user. The welcome interface 602 includes a button control element (“Get Offer Content”) that, when activate, transmits a message to request content. The request may be transmitted to a personalized content provisioning system.
If the user submitting the request can be uniquely identified, such as via the method 400 shown in FIG. 4 , the interface may receive information to for a first transition 610 from the welcome interface 602 to a content presentation interface 608. The content presentation interface 608 may include personalized content selected based on the user data received in the message as well as any user information identified from one or more service providers. The content presentation interface 608 may include navigation arrows to allow viewing of different content for which the user is qualified to receive. The content shown on the content presentation interface 608 may include a personalized message. The personalized message may include name (“PAT SMITH”) or custom generated values (“$25,000”) based on the user data. The content presentation interface 608 also shows an expiration date for the content and a unique identifier for the content. The content presentation interface 608 also includes a button control element (“Begin Enrollment”) that, when activated, transmits a message to a network service to begin a process associated with the content. As shown in FIG. 6A, the process may be an enrollment process to accept the prequalified credit offer described in the received content. The message may include the offer identifier to facilitate expedited collection of the required information for the process.
Returning to the welcome interface 602, if the user cannot be uniquely identified but a limited set of candidate users correspond to the user data provided, a second transition 612 may present a clarification interface 604. The clarification interface 608 may be generated to collect one or more elements of identity data that can uniquely distinguish the limited set of candidate users. As discussed, there may be one data type (e.g., month of birth, house number, street name, numeric day of birth, previous city of residence, etc.) that can distinguish all users in the limited set. In such implementations, a value for this data type may be the only requested information. As shown in FIG. 6A, the clarification interface 604 is requesting only the last four digits of the user’s social security number.
The clarification interface 604 may include input control elements (shown as boxes) for receiving user input values such as respective digits of a social security number. The clarification interface 604 also includes a control element (“submit” button) that, when activated, causes transmission of the input values to the system. If the provided information narrows the identity of the user to a unique user, transition 620 may provide the personalized content via the content presentation interface 608 as described above. If the provided information fails to uniquely identify a user, transition 622 may cause presentation of a user information input interface 606.
The user information input interface 606 may include one or more input control elements to receive respective values for a set of data types such as first name, last name, last four digits of the social security number, home address ZIP code, and the like. An input control element may be prepopulated with known values, such as a first name common to the set of candidate users identified based on the initial request. The user information input interface 606 may include a control element such as a “submit” button that, when activated, causes transmission of the input values to the system. In some implementations, the interfaces shown in FIG. 6A may be provided within an application such as a web browser or custom built application. Upon submission of valid values, transition 624 may cause presentation of the content presentation interface 608 as described above.
Transition 614 from the welcome interface 602 to the user information input interface 606 may be initiated when the candidate list of users cannot be distinguished based on a single data type or field or no candidate users are found. In such implementations, the user information input interface 606 may prepopulate some fields with user values common to members of the candidate list and leave fields empty for those values which cannot be distinguished.
In some embodiments, the user identification and offer provision systems as discussed herein, such as with reference to FIG. 6A, may be implemented in an online marketplace environment, wherein the user may be provided with multiple offers for which they are prequalified, rather than a single particular offer. For example, upon identification of a user (e.g., using some or all of the identity verification process of FIG. 4 ), the user may be directed to a marketplace (e.g. via a shortened URL to the marketplace that is sent to the user’s mobile device as a text message or application-direct message) that displays multiple offers for exploration by the user (e.g. in a browser or standalone application provided by the content provisioning system 150). In the context of credit card offers, for example, the marketplace may identify multiple (two, three, four, five, or more) credit card offers for which the user is prequalified that are perhaps sorted to identify the prequalified offers with the most advantageous terms (e.g., lowest interest rates, best rewards programs, etc.) -or to display up all of the prequalified offers in some embodiments. The user may then be given the opportunity to filter the prequalified offers (e.g., by interest rate, rewards program features, etc.) and identify a particular offer for which the user would like to complete an application. Depending on the implementation, the offers may be selected from a plurality of offer providers, such that the user could potentially be provided with prequalified offers from multiple offer providers. In the example context of credit card offers, this means that are user could be provided with credit card offers from multiple financial institutions (e.g., a first credit card from big bank A, a second credit card from big bank B, etc.). As noted elsewhere, example implementations, such as in particular vertical markets (e.g., credit card offers) are provided for ease of explanation and do not limit the scope of any associated systems and methods to other vertical markets.
FIG. 6B is a pictorial diagram showing another example user interface transitions for requesting and receiving personalized content on a mobile device. An eligibility initiation interface 652 may be presented on a user device. The eligibility initiation interface 652 may be presented in response to a message received from the personalized content provisioning system 150. For example, the message may cause execution of an application on the user device to present the eligibility initiation interface 652. In some implementations, the application may be executed by the user via the user device. In such instances, the eligibility initiation interface 652 may be presented without remote communication (e.g., to the personalized content provisioning system 150).
The eligibility initiation interface 652 may include input control elements (shown as boxes) for receiving user input values such as first name, last name, or postcode. In some implementations, the application presenting the eligibility initiation interface 652 may pre-populate the fields with a value for one or more of the input control elements. For example, if the user previously provided name or postcode information as a configuration for the application, these values may be retrieved from the configuration storage and displayed in respective input control elements. The eligibility initiation interface 652 may include additional control elements such as a checkbox to indicate user’s consent to process his or her personal information. In some implementations, an additional control element may be provided that, when activated, shows additional details about the processing, what information may be collected, how the information may be used, etc. The eligibility initiation interface 652 shown in FIG. 6B also includes a control element (e.g., button “check eligibility”) that, when activated, submits the user input values for further processing. For example, the user input values may be transmitted via a network for further processing such as to the personalized content provisioning system 150.
After submission, a transition 660 may cause presentation of a status interface 654. The status interface 654 may provide an indicator of the progress of the eligibility processing. The indicator shown in the status interface 654 comprises a progress bar. The progress bar may be updated based on one or more messages received from the system processing the eligibility request such as the personalized content provisioning system 150.
The result of the processing may be that the user is identified and is eligible for particular content. In such instances, a transition 662 may cause presentation of a content offer interface 656. The content offer interface 656 may include a personalized greeting (e.g., “Pat” is the name of the user and is used in the message shown). The content offer interface 656 may include an estimate of a likelihood of obtaining the content referenced on the content offer interface 656. For example, in a credit prequalification context, the prequalification decision may not be a firm offer of credit, but rather an indicator of what credit terms might be offered to the user. An actual offer may be contingent on additional verification or information not available at the prequalification stage.
As shown in FIG. 6B on the content offer interface 656, a percentage chance of acceptance is included. As discussed above, the content may be generated from a content template which includes a field for the likelihood information. The likelihood may be generated by the content generator 170.
The content offer interface 656 may include additional text summarizing the terms of the offer. In some implementations, the content offer interface 656 may include an additional control element, such as hyperlinked text or a button, that, when activated, causes presentation of the full terms of the offer. The presentation may include retrieving the terms from a network location or displaying additional information received from the source system. The content offer interface 656 may include a control element (e.g., button), that, when activated, begins the enrollment process. The control element may submit a session identifier to an enrollment system for continued processing. The session identifier may be used by the enrollment system to access user information collected by the prequalification process and/or the content offer identified.
In some implementations, once a user is approved for an offer, the approved offer information may be automatically provided to the offer provider, such as by pre-populating the offer provider’s online eligibility service with the user’s information. For example, the user may be provided with an option to perform a further approval process by selecting a link to the offer provider’s online eligibility service, which will be pre-populated (or auto-populated as the service is opened) with the user’s information. Additionally, the user information may be provided to other applications or entities. In the context of credit card offers, for example, once a user is approved for a particular credit card, the credit card information may be automatically (or after authorization by the user) provided to a mobile wallet on the user’s mobile device. Mobile wallets may be included as part of an operating system (e.g., Apple pay on iPhones) or third-party mobile payment applications (e.g., Google pay). Thus, a credit card could be applied for, approved, and available for use by a user within a significantly shortened time, and without the user ever receiving a physical credit card in some implementations.
In some implementations, the user is presented with an option to receive a follow-up text or email (e.g., if they supply address) at some future time (e.g., 1 day, 1 week, or 1 month later - which may be determined automatically by the system or may be selectable by the user in some embodiments), that includes the link to the digital application process (e.g., either the same link as already provided or a modified link for identifying the user visit as responsive to a follow-up message).
Another result of the processing may be that the user cannot be positively identified. In such instances, one or more additional interfaces may be presented to receive user input values to identify and distinguish the user from other candidate users. Examples of these interfaces are shown in FIG. 6A, such as the interfaces 604 and 606.
In some instances, a content offer may not be identified. The failure to identify an offer may be because the user cannot be identified, because the user cannot be distinguished from other candidate users, because the user does not qualify for any available content offers, or because of a system failure (e.g., unavailable data source, system, etc.). In such instances, a transition 664 may cause the status interface 654 to be replaced with an error interface 658. The error interface 658 may include a description of the error identifying what caused the eligibility check to fail.
Design of computer user interfaces “that are useable and easily learned by humans is a non-trivial problem for software developers.” (Dillon, A. (2003) User Interface Design. MacMillan Encyclopedia of Cognitive Science, Vol. 4, London: MacMillan, 453-458.) The present disclosure describes various embodiments of interactive and dynamic user interfaces, such as the mobile user interfaces discussed above with reference to FIGS. 6A-6B, that are the result of significant development. This non-trivial development has resulted in the user interfaces described herein which may provide significant cognitive and ergonomic efficiencies and advantages over previous systems. The interactive and dynamic user interfaces include improved human-computer interactions that may provide reduced mental workloads, improved decision-making, reduced work stress, and/or the like, for a user. For example, user interaction with the interactive user interface via the inputs described herein may provide an optimized display of, and interaction with, image data (including medical images) and may enable a user to more quickly and accurately access, navigate, assess, and digest the image data than previous systems.

Example Hardware Architecture

FIG. 7 is a block diagram showing example components of a location or behavior based content provisioning computing system 150. The computing system 700 includes, for example, a personal computer that is IBM, Macintosh, or Linux/Unix compatible or a server or workstation. In one embodiment, the computing system 700 comprises a server, a laptop computer, a smart phone, a personal digital assistant, a kiosk, or a media player, for example. In one embodiment, the exemplary computing system 700 includes one or more central processing unit (“CPU”) 705, which may each include a conventional or proprietary microprocessor. The computing system 700 further includes one or more memory 732, such as random access memory (“RAM”) for temporary storage of information, one or more read only memory (“ROM”) for permanent storage of information, and one or more mass storage device 722, such as a hard drive, diskette, solid state drive, or optical media storage device. Typically, the components of the computing system 700 are connected to the computer using a standard based bus system 790. In different embodiments, the standard based bus system could be implemented in Peripheral Component Interconnect (“PCI”), Microchannel, Small Computer System Interface (“SCSI”), Industrial Standard Architecture (“ISA”) and Extended ISA (“EISA”) architectures, for example. In addition, the functionality provided for in the components and modules of computing system 700 may be combined into fewer components and modules or further separated into additional components and modules.
The computing system 700 is generally controlled and coordinated by operating system software, such as Windows XP, Windows Vista, Windows 7, Windows 8, Windows Server, Unix, Linux, SunOS, Solaris, iOS, Blackberry OS, or other compatible operating systems. In Macintosh systems, the operating system may be any available operating system, such as MAC OS X. In other embodiments, the computing system 700 may be controlled by a proprietary operating system. Conventional operating systems control and schedule computer processes for execution, perform memory management, provide file system, networking, I/O services, and provide a user interface, such as a graphical user interface (“GUI”), among other things.
The exemplary computing system 700 may include one or more commonly available input/output (I/O) devices and interfaces 712, such as a keyboard, mouse, touchpad, and printer. In one embodiment, the I/O devices and interfaces 712 include one or more display devices, such as a monitor, that allows the visual presentation of data to a user. More particularly, a display device provides for the presentation of GUIs, application software data, and multimedia presentations, for example. The computing system 700 may also include one or more multimedia devices 742, such as speakers, video cards, graphics accelerators, and microphones, for example.
In the embodiment of FIG. 7 , the I/O devices and interfaces 712 provide a communication interface to various external devices. In the embodiment of FIG. 7 , the computing system 700 is electronically coupled to one or more networks, which comprise one or more of a LAN, WAN, and/or the Internet, for example, via a wired, wireless, or combination of wired and wireless, communication link. The networks communicate with various computing devices and/or other electronic devices via wired or wireless communication links, such as the credit bureau data source and financial information data sources.
In some embodiments, information may be provided to the computing system 700 over a network from one or more data sources. The data sources may include one or more internal and/or external data sources that provide transaction data, such as credit issuers (e.g., financial institutions that issue credit cards), transaction processors (e.g., entities that process credit card swipes at points of sale), and/or transaction aggregators. The data sources may include internal and external data sources which store, for example, credit bureau data (for example, credit bureau data from File One(SM)) and/or other user data. In some embodiments, one or more of the databases or data sources may be implemented using a relational database, such as Sybase, Oracle, CodeBase and Microsoft® SQL Server as well as other types of databases such as, for example, a flat file database, an entity-relationship database, an object-oriented database, solr database, and/or a record-based database.
The content data storage 708 may be included to support the identification of users and/or provisioning of content to a user. For example, the content data may include content templates, content models, content publication rules, and the like.
In general, the word “module,” as used herein, refers to logic embodied in hardware or firmware, or to a collection of software instructions, possibly having entry and exit points, written in a programming language, such as, for example, Java, Lua, C or C++. A software module may be compiled and linked into an executable program, installed in a dynamic link library, or may be written in an interpreted programming language such as, for example, BASIC, Perl, or Python. It will be appreciated that software modules may be callable from other modules or from themselves, and/or may be invoked in response to detected events or interrupts. Software modules configured for execution on computing devices may be provided on a computer readable medium, such as a compact disc, digital video disc, flash drive, or any other tangible medium. Such software code may be stored, partially or fully, on a memory device of the executing computing device, such as the computing system 700, for execution by the computing device. Software instructions may be embedded in firmware, such as an EPROM. It will be further appreciated that hardware modules may be comprised of connected logic units, such as gates and flip-flops, and/or may be comprised of programmable units, such as programmable gate arrays or processors. The modules described herein are preferably implemented as software modules, but may be represented in hardware or firmware. Generally, the modules described herein refer to logical modules that may be combined with other modules or divided into sub-modules despite their physical organization or storage.
In the example of FIG. 7 , the modules 710 may be configured for execution by the CPU 705 to perform any or all of the processes discussed above with reference to FIGS. 2-4 , the messaging shown in FIG. 5 , or to generate and/or present the interfaces shown in FIG. 6A or FIG. 6B. Depending on the embodiment, certain processes, or in the processes, or groups of processes discussed herein may be performed by multiple devices, such as multiple computing system similar to computing system 700. For example, depending on the embodiment, certain of the processes described herein may be performed by a computing system that identifies content, while other processes are performed an identification system that determines a user’s identity.

Further Identity Detection Features

In the description, some implementations of the identity detection (e.g., Smart Lookup) features have been described with reference to providing personalized content. The identity detection features may be used in additional or alternative implementations where an efficient and accurate identification of a user based at least in part on a communication device associated with the user is desired. Such implementations may include test taking systems, personal account systems (e.g., banking, insurance, email, or loyalty programs), inquiry systems (e.g., credit inquiry, education record inquiry, government record inquiry), content prefilling services, monitoring services (e.g., credit monitoring), login/authentication services, or the like.
FIG. 8 is a block diagram showing example components of an identity confirmation device for identifying a user of a mobile device. A request processor 802 included in the identity confirmation device 155 may receive an access request message from the user device 102. The access request message may be received directly from the user device 102 or from a service that is being accessed or used by the user device 102. The access request message may include user information such as first name, last name, ZIP code or postcode, or an identifier that can be used to obtain the user information such from a service provider. The request processor 802 may present a machine interface such as an application programming interface or web service interface to receive messages from other services requesting identity confirmation and/or information. The interface may receive machine readable messages such as access request messages and return user information related thereto.
The request processor 802 may retrieve digest data from a user data digest data store 804. The digest data store 804 may store a limited set of user information for user and an associated custom identifier (e.g., PIN) for the user. The digest data store 804 may be a look up table indexed by the user information expected to be included in the access request. This provides a quick lookup of the custom identifier and other user information for the user. For example, the access request may include first name, last name, and postal code. The digest data store 804 may include a record for a user with the same first name, last name, and postal code. The record may also include address information (e.g., street address), date of birth, and the custom identifier.
In some implementations, the digest data store 804 may be generated based on information that does not include consideration of events that occurred since the last digest was generated. When dealing with hundreds of thousands of users who each may be associated with hundreds or thousands of events, it is not uncommon for a digest to lag behind current events by several days. Such events may impact identity decisioning or other downstream modeling based on user value inputs.
To mitigate the risk of stale or misidentification of a user, the digest data may be provided to a real-time user data retrieval 806. The real-time user data retrieval 806 may receive all or a portion of the digest data retrieved for the access request. Using the digest data, the real-time user data retrieval 806 may initiate a separate request for user information from a real-time user data storage 808. The real-time nature of the real-time user data storage 808 indicates that the user information included in the real-time user data storage 808 is based on events as processed by the system rather than a digested snapshot from a past point in time.
The real-time data may include first name, last name, postal code, address information (e.g., street address), date of birth, and a custom identifier. An identity reconciler 810 may compare the real-time data with the digest data to confirm the identity of the user. The confirmation may include comparing the custom identifiers (e.g., PINs) included in the real-time data and the digest data.
If the identifiers do not match or if there are multiple matches (e.g., several candidate users matching the digest data or several candidate users identified in the digest data), the identity reconciler 810 may transmit a clarification request to a clarification collector 812. The clarification collector 812 may be configured to identify what information is needed to identify a single user. For example, the clarification collector 812 may identify an identity data type that distinguishes all the candidate users. The clarification collector 812 may then retrieve the clarification data. Retrieving the clarification data may include causing presentation of an interface on the user device 102 to receive a user input including the clarification data. Retrieving the clarification data may include querying an additional service or data store for the clarification data. For example, the service that is to be accessed by the user device 102 may store user profiles which may include additional information that can be used to clarify the identity of the user of the user device 102. The received clarification data may be provided to the identity reconciler 810 for further consideration and analysis to identify the user.
If these identifiers included in the real-time and digest data match or if the clarification data singles out one user, then the identity reconciler 810 may confirm the identity of the user by transmitting identity data. The identity data may include transmitting additional user information such as address, date of birth, or other user information received from the real-time user data storage 808. In some implementations, the identity data may include a binary result indicating that the user is identified. This may be an efficient way to indicate to a service whether the user of the mobile device is authenticated and/or authorized to access the service. The identity information may then be used, in certain implementations, to automatically initiate additional processes based on the additional information regarding the now-authenticated user. For example, as discussed elsewhere herein, once the user’s identity is authenticated, a form fill process may be initiated using information pulled from one or more databases accessible by the content provisioning system, such as PII included in a credit report (e.g., full residence address, age, credit score, etc.) of the authenticated user. In this form fill example, the user information may be encoded and transmitted to the user device for auto population of a form (e.g., a house/apartment rental application, online account registration, car rental application, credit application, etc.), or in some embodiments may be transmitted directly to the offer provider. The user information may be included with the initial data indicating results of the identity verification process or may be included in a subsequent data transmission to the requesting entity. Advantageously, this identity validation process may be used by any third-party entity that desires identity determination and/or identity verification.

Additional Embodiments

Each of the processes, methods, and algorithms described in the preceding sections may be embodied in, and fully or partially automated by, code modules executed by one or more computer systems or computer processors comprising computer hardware. The code modules may be stored on any type of non-transitory computer-readable medium or computer storage device, such as hard drives, solid state memory, optical disc, and/or the like. The systems and modules may also be transmitted as generated data signals (for example, as part of a carrier wave or other analog or digital propagated signal) on a variety of computer-readable transmission mediums, including wireless-based and wired/cable-based mediums, and may take a variety of forms (for example, as part of a single or multiplexed analog signal, or as multiple discrete digital packets or frames). The processes and algorithms may be implemented partially or wholly in application-specific circuitry. The results of the disclosed processes and process steps may be stored, persistently or otherwise, in any type of non-transitory computer storage such as, for example, volatile or non-volatile storage.
The various features and processes described above may be used independently of one another, or may be combined in various ways. All possible combinations and sub-combinations are intended to fall within the scope of this disclosure. In addition, certain method or process blocks may be omitted in some implementations. The methods and processes described herein are also not limited to any particular sequence, and the blocks or states relating thereto can be performed in other sequences that are appropriate. For example, described blocks or states may be performed in an order other than that specifically disclosed, or multiple blocks or states may be combined in a single block or state. The example blocks or states may be performed in serial, in parallel, or in some other manner. Blocks or states may be added to or removed from the disclosed example embodiments. The example systems and components described herein may be configured differently than described. For example, elements may be added to, removed from, or rearranged compared to the disclosed example embodiments.
Conditional language, such as, among others, “can,” “could,” “might,” or “may,” unless specifically stated otherwise, or otherwise understood within the context as used, is generally intended to convey that certain embodiments include, while other embodiments do not include, certain features, elements and/or steps. Thus, such conditional language is not generally intended to imply that features, elements and/or steps are in any way required for one or more embodiments or that one or more embodiments necessarily include logic for deciding, with or without user input or prompting, whether these features, elements and/or steps are included or are to be performed in any particular embodiment.
As used herein, the terms “determine” or “determining” encompass a wide variety of actions. For example, “determining” may include calculating, computing, processing, deriving, generating, obtaining, looking up (e.g., looking up in a table, a database or another data structure), ascertaining and the like via a hardware element without user intervention. Also, “determining” may include receiving (e.g., receiving information), accessing (e.g., accessing data in a memory) and the like via a hardware element without user intervention. Also, “determining” may include resolving, selecting, choosing, establishing, and the like via a hardware element without user intervention.
As used herein, the terms “provide” or “providing” encompass a wide variety of actions. For example, “providing” may include storing a value in a location of a storage device for subsequent retrieval, transmitting a value directly to the recipient via at least one wired or wireless communication medium, transmitting or storing a reference to a value, and the like. “Providing” may also include encoding, decoding, encrypting, decrypting, validating, verifying, and the like via a hardware element.
As used herein, the term “message” encompasses a wide variety of formats for communicating (e.g., transmitting or receiving) information. A message may include a machine readable aggregation of information such as an XML document, fixed field message, comma separated message, or the like. A message may, in some implementations, include a signal utilized to transmit one or more representations of the information. While recited in the singular, it will be understood that a message may be composed, transmitted, stored, received, etc. in multiple parts.
As used herein, “receive” or “receiving” may include specific algorithms for obtaining information. For example, receiving may include transmitting a request message for the information. The request message may be transmitted via a network as described above. The request message may be transmitted according to one or more well-defined, machine readable standards which are known in the art. The request message may be stateful in which case the requesting device and the device to which the request was transmitted maintain a state between requests. The request message may be a stateless request in which case the state information for the request is contained within the messages exchanged between the requesting device and the device serving the request. One example of such state information includes a unique token that can be generated by either the requesting or serving device and included in messages exchanged. For example, the response message may include the state information to indicate what request message caused the serving device to transmit the response message.
As used herein, “generate” or “generating” may include specific algorithms for creating information based on or using other input information. Generating may include retrieving the input information such as from memory or as provided input parameters to the hardware performing the generating. Once obtained, the generating may include combining the input information. The combination may be performed through specific circuitry configured to provide an output indicating the result of the generating. The combination may be dynamically performed such as through dynamic selection of execution paths based on, for example, the input information, device operational characteristics (e.g., hardware resources available, power level, power source, memory levels, network connectivity, bandwidth, and the like). Generating may also include storing the generated information in a memory location. The memory location may be identified as part of the request message that initiates the generating. In some implementations, the generating may return location information identifying where the generated information can be accessed. The location information may include a memory location, network locate, file system location, or the like.
As used herein, “activate” or “activating” may refer to causing or triggering a mechanical, electronic, or electro-mechanical state change to a device. Activation of a device may cause the device, or a feature associated therewith, to change from a first state to a second state. In some implementations, activation may include changing a characteristic from a first state to a second state such as, for example, changing the viewing state of a lens of stereoscopic viewing glasses. Activating may include generating a control message indicating the desired state change and providing the control message to the device to cause the device to change state.
Any process descriptions, elements, or blocks in the flow diagrams described herein and/or depicted in the attached figures should be understood as potentially representing modules, segments, or portions of code which include one or more executable instructions for implementing specific logical functions or steps in the process. Alternate implementations are included within the scope of the embodiments described herein in which elements or functions may be deleted, executed out of order from that shown or discussed, including substantially concurrently or in reverse order, depending on the functionality involved, as would be understood by those skilled in the art.
All of the methods and processes described above may be embodied in, and partially or fully automated via, software code modules executed by one or more general purpose computers. For example, the methods described herein may be performed by the computing system and/or any other suitable computing device. The methods may be executed on the computing devices in response to execution of software instructions or other executable code read from a tangible computer-readable medium. A tangible computer-readable medium is a data storage device that can store data that is readable by a computer system. Examples of computer-readable mediums include read-only memory, random-access memory, other volatile or non-volatile memory devices, CD-ROMs, magnetic tape, flash drives, and optical data storage devices.
It should be emphasized that many variations and modifications may be made to the above-described embodiments, the elements of which are to be understood as being among other acceptable examples. All such modifications and variations are intended to be included herein within the scope of this disclosure. The foregoing description details certain embodiments. It will be appreciated, however, that no matter how detailed the foregoing appears in text, the systems and methods can be practiced in many ways. As is also stated above, it should be noted that the use of particular terminology when describing certain features or aspects of the systems and methods should not be taken to imply that the terminology is being re-defined herein to be restricted to including any specific characteristics of the features or aspects of the systems and methods with which that terminology is associated.
These and other embodiments relating to the systems and methods disclosed herein are detailed in the Appendices included in the priority applications, the entirety of which are bodily incorporated herein and the entirety of which is also incorporated herein by reference. The Appendices provides only examples of certain systems and methods that may be performed in accordance with the discussion above and does not limit the scope of alternative uses and implementations of such systems and methods.
Acronyms that may referenced in this application or an incorporated document include:

PPOI - Person places of interest
ID - identifier
HL - home location or home locator
SSN - social security number
DaaS - data as a service
DL - data labs
FN / LN - first name / last name
KBA - knowledge based authentication
API - application programming interface
SDK - software development kit
EXPN - Experian
GPS - global positioning system
WiFi - IEEE 802.11 family (e.g., c, d, e, n, g) of standards based wireless networking
PIN - personal identification number
FI - financial institution
UX - user experience

Claims

1. (canceled)

2. A computer-implemented method of identification of a user of a mobile device, the method comprising:

under control of one or more computing devices configured with specific computer-executable instructions,

receiving first information identifying a user of the mobile device from a service associated with the mobile device;

querying, based on a fuzzy matching of at least a portion of the first information, a database which indexes credit header files of a plurality of users for a set of candidate users having the largest quantity of identity data values that matches user information from the credit header files;

determining a degree of difference between the identity data values of candidate users of the set of candidate users and the first information;

determining a degree of relatedness between the identity data values and the user information;

removing users from the set of candidate users based on the degree of difference and based on the degree of relatedness;

for each user included in the set of candidate users, identifying an identity data type associated with different identity data values that distinguish between the candidate users;

receiving an input identity value from the user; and

identifying the user in the set of candidate users based on the received input identity value.

3. The computer-implemented method of claim 2 further comprising determining that the identified user qualifies for an offer for a line of credit.

4. The computer-implemented method of claim 2 further comprising transmitting instructions to be received at the mobile device to request the input identity value of the identified identity data type from the user.

5. The computer-implemented method of claim 2, wherein the service comprises at least one of an internet service, an application service, a cellular service, or a merchant service.

6. The computer-implemented method of claim 2, wherein generating the metric indicating the degree of relatedness between the identity data values and the user information comprises:

generating a count of identity data types included in identity data having corresponding identity data types included in the user information; and

for an identity data type having a corresponding identity data type included in the user information, generating a comparison value indicating how closely the identity data value matches a user information value for the corresponding identity data type included in the user information, wherein the metric is based at least in part on the count and the comparison value.

7. The computer-implemented method of claim 2, wherein generating the metric indicating the degree of relatedness between the identity data values and the user information comprises:

identifying a historical weight for the identity data value based on a difference between a current time and a time when identity data was collected; and

generating a comparison value indicating how closely the identity data value matches a user information value for a corresponding identity data type included in the user information, wherein the comparison value is weighted based at least in part on the historical weight.

8. The computer-implemented method of claim 2, wherein the first information is included in a request for personalized content, and wherein the computer-implemented method further comprises transmitting at least a portion of the user information and at least one of the identity data values of the one candidate user to a personalized content service.

9. The computer-implemented method of claim 2 further comprising:

receiving second information identifying a second user of a second mobile device from a second service associated with the second mobile device;

requesting candidate user information from the database using the second information; and

in response to receiving no candidate user information results, transmitting instructions to the second mobile device to request input values to identify the second user.

10. The computer-implemented method of claim 2 further comprising:

causing, in response to receiving the first information, a consent request to be received at the mobile device; and

receiving a consent response in response to causing the consent request, wherein said querying is based in part on the consent response.

11. A system comprising:

a computer-readable memory storing executable instructions; and

one or more computer processors in communication with the computer-readable memory, wherein the one or more computer processors are configured to execute the executable instructions to at least:

receive first information identifying a user of a device from a service provider, the first information based on a device identifier associated with the device;

query, based on a fuzzy matching of at least a portion of the first information, a database which indexes credit header files of a plurality of users for a set of candidate users having the largest quantity of identity data values that matches user information from the credit header files;

determine a degree of difference between the identity data values of candidate users of the set of candidate users and the first information;

determine a degree of relatedness between the identity data values and the user information;

remove users from the set of candidate users based on the degree of difference and based on the degree of relatedness;

for each user included in the set of candidate users, identify an identity data type associated with different identity data values that distinguish between the candidate users;

receive an input identity value from the user; and

identify the user in the set of candidate users based on the received input identity value.

12. The system of claim 11, wherein the one or more computer processors are further configured to execute the executable instructions to determine that the identified user qualifies for an offer for a line of credit.

13. The system of claim 11, wherein the one or more computer processors are further configured to execute the executable instructions to transmit instructions to be received at the mobile device to request the input identity value of the identified identity data type from the user.

14. The system of claim 11, wherein the one or more computer processors are further configured to execute the executable instructions to:

identify the specific candidate and a second candidate having metrics corresponding to the threshold;

identify a differentiation data field, wherein a value for the differentiation data field for the specific candidate is different from a value for the differentiation data field for the second candidate;

receive input from the device for the differentiation data field; and determine the input corresponds to the value of the differentiation data field for the specific candidate.

15. The system of claim 11, wherein the one or more computer processors are further configured to execute the executable instructions to transmit at least a portion of the device identifier and at least one of the values of the specific candidate to a personalized content service.

16. The system of claim 11, wherein identifying the set of candidates comprises querying a database storing information regarding a plurality of users, wherein the set of candidates include one or more users having the largest quantity of identity data values matching the first information.

17. Non-transitory, computer-readable storage media storing computer-executable instructions that, when executed by a computer system that comprises one or more hardware processors, configure the computer system to perform operations comprising:

receiving an input identity value from the user; and

18. The non-transitory, computer-readable storage media of claim 17, wherein the computer system is further configured to determine that the identified user qualifies for an offer for a line of credit.

19. The non-transitory, computer-readable storage media of claim 17, wherein the computer system is further configured to transmit instructions to be received at the mobile device to request the input identity value of the identified identity data type from the user.

20. The non-transitory, computer-readable storage media of claim 17, wherein the computer system is further configured to generate an individual metric for each of the candidates included in the set of candidates, wherein the individual metric indicates the degree of relatedness.

21. The non-transitory, computer-readable storage media of claim 17, wherein the computer system is further configured to:

determine the set of candidates includes no candidate users;

in response to receiving no candidate user information results, cause instructions to be received at the mobile device to request input values;

generate a custom candidate user based on received input values; and

add the custom candidate user to the set of candidates.